Managing and Eliminating Cross-team Dependencies
Cross-team dependencies can be the source of immense pain and friction, resulting in all kinds of organisational dysfunctions and politics. Missed deadlines, non-stop meetings, chaotic context switching, we’re all familiar with the side-effects of undesirable dependencies.
What we’re not so familiar with, however, are the plethora of strategies available to us for minimising the pains of cross-team dependencies, and even eliminating them.
We can reshape organisational boundaries, use inner sourcing and dynamic reteaming to create resilience, and bring the people to the work. And we can also anticipate and prepare for dependencies that will arise.
We also have to be pragmatic. Sometimes teams will be blocked because their work is low priority and more strategic initiatives cannot be interrupted. Rather than be concerned, we can use these situations to our advantage.
In this post I’ll talk you through these different approaches so you can deal with dependencies more effectively.
I want to be clear that cross-team dependencies are not inherently bad. Quite the opposite. We don’t want an organisation comprised of fully autonomous teams. We want to deliver rich user experiences comprised of cohesive capabilities provided by multiple teams. If there is no interaction between teams, we will have an overly-fragmented user experience.
The challenge is finding the right balance. The more time our teams spend collaborating the less time they spend delivering. It’s risky to sit at either extreme.
Eliminating Dependencies through Organisation Design
The best way to deal with the cost of dependencies is to not have to. If we can achieve the same benefits minus the costs then we would be crazy not to jump at the opportunity.
This should be our default approach when dealing with cross-team dependencies: can we eliminate the dependency altogether?
There are a variety of evolutionary organisation design patterns we can lean on including Slice and Scatter and Slice and Merge.
Using Slice and Scatter, we break up a bottleneck capability (a team and their technical components) and distribute them among the capabilities that depend on them.
Using Slice and Merge, we identify the sub-parts of multiple capabilities that co-change and merge them into a new capability owned by a new team.
A common example of Slice and Merge is moving from activity-oriented teams (frontend, backend, DBA, etc) to vertically-sliced capability teams.
Minimising Cross-team Coordination Costs by Creating Resilient Organisations
We can’t eliminate all dependencies and sometimes they are short-lived in nature so it wouldn’t make sense to restructure our organisation anyway.
Instead, we can focus on creating resilient organisations which can comfortably deal with cross-team dependencies rather than allowing them to cause pain and politics.
Increasing Resilience with Inner Sourcing
To increase organisational resilience, we can take the people to the work. If Team A needs Team B to make changes, but Team B has other priorities and Team A is blocked, Team A can make changes to Team B’s code and submit a pull request.
Referred to as inner sourcing, this is based on the model of open source development. I’m seeing this technique gaining popularity in organisations of all sizes and it’s being talked about more on social channels and at conferences.
Inner sourcing has worked effectively each time I’ve seen it in practice. But we do have to accept some of its challenges. Generally, the team accepting the request can still end up having to dedicate time to support and deal with the request, while the team submitting has to incur learning costs, especially when teams use completely different technologies.
Optimising for Resilience and Inner Sourcing with Regular Rotation
My experience has been that regular rotation (along with technology standardisation) potentiates the benefits of inner sourcing and reduces the costs.
Regular rotation involves moving people between teams on a frequent basis so that individuals have a wider understanding beyond what they are currently working on. When a cross-team dependency occurs, both knowledge of that teams systems and strengthened personal relationship due to rotating will reduce the frictions of inner sourcing.
In Dynamic Reteaming, Heidi Helfand presents a number of case studies indicating 2–3 months to be a common number. This is consistent with my experience too. Every 3 months, at-least one person in each team should have rotated.
Temporary Pairs and Other Resilience Patterns
When building on a foundation of regular rotation, other resilience patterns also become available to us. For example, we can create a temporary pair. A person from Team A and a person from Team B can temporarily team up to deal with the dependency.
Looking beyond the practices, we essentially have a range of dials we can tweak, trading off coordination costs, learning costs, opportunity costs, duplication costs, etc for the different teams involved so there are a whole range of patterns available to us.
For example, when we’re trying to do something innovative that cuts across multiple teams in large organisations, we can form a short/mid-term discovery team composed of multiple people from each team.
In this scenario, we’re optimising for speed of innovation on the new capability because we have a single team which can move fast, but we’re sacrificing alignment with team members who didn’t get moved into the temporary team.
This pattern is known as an enterprise discovery context and fits within the broader category of isolated innovation patterns.
Another pattern I’m hearing more about is the micro teams pattern, where overall teams are larger, and within them people continuously form and re-form sub-teams based on the available work.
Anticipating Cross-team Dependencies
In my experience, it’s always sensible to anticipate ahead of time dependencies that are likely to arise. However, there is a huge difference between shallow and deep anticipation.
Shallow Anticipation
If we think that certain dependencies may arise, we can put in place lightweight controls that enable us to better respond if those dependencies do arise.
For instance, when rotating people between teams, we might encourage rotation between teams which are likely to have dependencies in future. Accordingly, we would strive for higher levels of rotation within a layer 2 capability or a tribe in Spotify Model lingo.
To help us anticipate likely dependencies, we can use visualisation techniques such as EventStorming, value stream mapping, and portfolio kanban boards.
Deep Anticipation
Sometimes, the cost of dependencies is so high and the likelihood of them arising is so certain that we need to anticipate them in advance and actively coordinate the work of multiple teams. Deep anticipation is at the heart of scaled agile frameworks like SAFe.
Waterfall is at the extreme end of deep anticipation. And we’re all aware that waterfall struggles because it relies on big up front predictions and long-term stability whereas software development is highly complex and unpredictable.
Deep anticipation is another dial we can adjust to our specific needs. It’s not inherently good or bad. But the more we crank it up, the closer we are to waterfall, regardless of the fancy name we call our process.
Accepting Compromise
Finally, there’s a hard truth we all have to accept: not all work is equal. Sometimes teams are blocked and it makes business sense for them to stay blocked so that high priority initiatives are not disrupted.
I’ve faced this situation in my career, and I can assure you it wasn’t a nice feeling. We have our team goals, but we are completely powerless to achieve them. But I grew to accept the decisions — in one situation, the business was fighting to stay competitive and it had to throw its effort behind a key initiative.
We should stop worrying about teams being blocked. And we shouldn’t worry when 100% of our people are not 100% utilised. When being blocked makes business sense, use the opportunity to improve organisational resilience.
A Heuristic for Managing Dependencies
When leading teams and advising clients, my heuristic is to optimise for resiliency and strive to eliminate bottlenecks, relying on deep anticipation only as a last resort.
I want every person in every team to feel free to solve problems in the best way they see fit. When we start anticipating the future and putting controls in place, we start eroding autonomy and handing control back to higher layers of the organisation. That’s counter intuitive to all of the high performing teams I’ve worked with.
If you’d like to learn more about the patterns and practices in this post, I’ll be speaking at various conferences this year and running workshops in Denver and Berlin. You can also contact me directly if you have any private training or consulting requirements or speaking requests.
