Life at the intersection of finance and technology

So who decides when someone has to?

In my previous (long) post I talked about navigating potential conflicts that can emerge in Agile planning when a company has an inter-related set of products. I suggested that product owners have a valuable role to play in navigating these collisions by facilitating communication, articulating trade-offs, recognizing leverage opportunities, and offering a wider perspective. I also made clear that responsibility for each of these four areas must be embraced by all members of the development teams including designers, architects, coders, testers, and product managers. I further made the (bold? naive?) statement that in an Agile environment that values open communication and collaboration across self-organizing and empowered teams everyone involved strives to navigate the inevitable collisions that occur across team plans without appealing to position, power, or expertise as trump cards to force compliance. This all sounds nice in theory, but how do such ideals stack up against the real world of product development?

Here I must admit that my answer to this is partly shaped by my good fortune in being part of an organization that values striving for ideals. Founded on principles and consciously pursuing multiple bottom lines, the company in which I currently serve as a product owner challenges every employee to be the best versions of ourselves and to seek the best ways to face and resolve conflicts within and across teams. In a company where we seek to recruit, hire, and retain people based on character and values as well as skill sets we can both expect a higher level of adherence to the ideals I upheld in my last post and legitimately hold people accountable for doing so. We certainly aren’t perfect, but we may have a higher than average willingness to seek ideal solutions in our honest pursuit of our goal to make a difference and not just a profit.

Of course, in truth it’s not simple. We don’t always act or think in accordance with our stated ideals, and even when we do we still have different perspectives and sometimes conflicting agendas. As each product team also has to be conscious of its own bottom line and not simply what might seem best for the company as a whole, there can be an understandable element of game theory that emerges around product decisions. If one team builds a new feature first then that team will likely bear the higher cost (both financially and in terms of development time) and so it might be ‘cheaper’ to leverage someone else’s development than to collaborate and share the costs together. If cross-team projects can be broken into their own separate development ‘threads’ with separate resources then the normal product teams can get more done by keeping ‘their’ developers working on ‘their’ priorities while a separate team of developers can be assigned to some cross-team projects. And since every team worries about controlling its expenses all teams can fall into arguments about the proper ways to allocate the costs associated with projects that benefit multiple teams or the company as a whole based on how much they ‘wanted’ these projects or when they would have prioritized them on their own. In spite of our shared base of common ideals we have yet to find an easy way to sort through these complexities and continue to search for the best approach to resolving the conflicts that arise from them.

While it doesn’t solve all of these difficulties, perhaps a metaphor might shed some light on one good way to frame the issues. As usual, I will probably stretch this metaphor close to its breaking point so please bear with me.

In an orchestra each member and each section seeks to do its best both to play its own parts and to harmonize with the whole. In an orchestra each person seeks to be the best she can be in full collaboration with other members and in overall pursuit of the music itself. Each recognizes the valuable contributions that others can make and knows that the most beautiful music comes not from dominating others but from playing well together. While at some times and in some pieces certain parts of the orchestra might gain more prominence, all together know that their unifying goal is to thrill the overall client base and keep them coming back (and paying) for more.

Agile principles and corporate strategy set the music we strive toward as we look to build the best products we can in the best ways to fulfill our purposes and achieve our multiple bottom lines. Product owners, product managers, coders, testers, designers, architects, DBAs – all strive both to be the best they can at their roles and to collaborate effectively. Working in concert with each other and our principles puts our potential conflicts into a broader context and motivates us collectively to pursue the best experience for our clients consistent with serving them sustainably and profitably. Thinking along these lines certainly won’t eliminate conflicts, but it creates the right mindset for navigating them when they arise.

The context for working things out when well-meaning people pursuing the same overarching goals have different perspectives on the best way forward involves some forum for mutual conversation and decision making (think of this forum as the conductor of the orchestra if that doesn’t stretch the metaphor too far). Some team of people meeting regularly to assess overall product strategy and help assess if each team is making wise choices can keep the entire product organization abreast of best practices. A cohort of product managers and product owners must surely be a key part of that decision making team when clarity about the best path forward does not emerge organically from the teams themselves. However such a group would likely also benefit from the valuable contributions of design, development, and architecture leads as well whose technical knowledge and development wisdom could offer helpful perspective in crafting product portfolio priorities. Ideally – and in my experience this ideal is realized more often than you might expect – decisions about product direction rarely need the intervention of such a group; instead their regular discussions serve to foster a broadly collaborative environment in which solutions to potential conflicts emerge from those most directly involved and impacted. But knowing that such a team can be appealed to when necessary provides helpful boundaries for resolving conflicts because in truth it’s not that simple.