Inter-Team Dependencies Chapter 1: Genesis
Sriram Narayan
Impact Intelligence | Product/Digital/Tech Performance | Author: Agile Org Design (Pearson)
When you deliver initiatives with semi-autonomous digital product teams, you might find it challenging to manage inter-team dependencies. Compared to delivering initiatives with project teams, you might experience greater coordination and negotiation overhead in the management of inter-team dependencies.?
Before seeing how to reduce the overhead, it’s important to be clear about why it arises.?
Before Product-Centric
Inter-team dependencies wouldn't arise if the whole engineering organization was one big team. But that doesn't scale, it gets unmanageable.? Therefore, teams have traditionally been set up? on the basis of one or more of the following:
This is illustrated below. The only inter-team dependencies are those between project teams and back-end teams.
Project to Product
How does the dependency situation change in a product-centric operating model? Digital product teams are usually organized by domain area and sometimes, additionally by architectural tier. Here’s a simplified e-retail example to illustrate domains and tiers.
And here’s a typical setup of 11 digital product teams comprising front-end capabilities, a business API platform, and some back-end platforms.
领英推荐
This set up naturally results in more inter-team dependencies because the typical initiative might require contributions from teams in all three tiers. The overhead increases if the same initiative also spans multiple domains.
Overhead vs. Benefit
The overhead of extra inter-team dependencies is a small price to pay for the benefits of a product-centric operating operating model, namely, the ability to reorient quickly, the ability to stay long enough to solve problems than to merely deliver functionality, domain and codebase knowledge retention, better team dynamics, and the ability to contain technical debt and preserve architectural integrity. At least, that's the theory. But these benefits might take a year to materialize while the overhead of extra dependencies might be felt promptly.
Unless you recognize this, you might be tempted to minimize inter-team dependencies by reorganizing your teams to match the initiatives of the season. That’d be a reversion to project teams.
Minimizing the Overhead
As it turns out, you don’t have to simply put up with the dependency negotiation and coordination overhead of a product-centric operating model. In the next couple of posts, I’ll share some ways to address it.
Until next time, take care and prosper.
Sriram
p.s. Background Reading: My 2017 experience report, published by Martin Fowler, contrasting the products way of working with projects.
Update: Chapter 2. Ontogenesis
Executive Director, Information Technology, The Hong Kong Jockey Club
2 年Thanks Richard James, I think there's an interesting parallel to the reverse-Conway law here (organistions form to reflect the systems they have) - as we've decomposed software into loosely coupled systems of services and microsevices integrated through a mesh of APIs, then our software has become a collaboration of dependent components. We can't get away from this without reverting to monolithic applications once more. So as humans, to make this work, we need our teams to recognise that the dependencies between them are a part of the solution, and not a problem which can be eliminated. And IMHO the lifetime value of a loosely coupled architecture outweighs the additional cost of managing the dependencies.
Director, Technology Portfolio Management at Informa | Transformation Leader | Strategic Execution
2 年Thanks for the insightful post, Sriram Narayan . I would be curious to see any parellels or divergences from Team Topologies model that Manuel Pais (Team Topologies) ???? and Matthew Skelton articulated.
Managing Director, Technology Transformation @ Accenture | Client Lead for UK South-West Region
2 年Simone Steel Gary Delooze - timely, as per convo earlier on not demeaning 'dependencies' :-)
I would add a box to your center stack of team attributes. That is that each team is a reliable link in the chains of trust in which it is a vital link. Systems and product complexity are such that for many things, the number of people one would have to assemble in one room to have present a complete understanding of how something works can be several thousand, An ability to trust the work of other teams has become more critical than ever before. Unfortunately, our legal and leadership systems have not matured adequately to support or nurture these chains of trust. Thus planes crash, and so on.