Inter-Team Dependencies: Chapter 3

Dealing effectively with increased inter-team dependencies is one thing, but can you do something to limit the increase even as you adopt a product-centric operating model? The answer is yes, but the changes required are harder than what’s required to cope with the increase.

Set-up Teams Aligned to Change Clusters

Conceptually neat approaches to defining the boundaries and scope of digital product teams might not always gel with the reality of work. For example, we might think that loyalty and promotions are best set up as two different teams, but the nature of demand (for functionality) and the shape of underlying codebases might be such that the two teams cannot work independently. In such situations, inter-team dependencies can be avoided by recognizing the overlap and not having a single team. 

You might think this is a cop out. After all, the inverse Conway maneuver suggests that decoupling teams is the first step to decoupling systems. Yes, in theory. In practice, it depends on, (a) How much the teams realize the need to decouple and are willing to act on it, and (b) How much delivery pressure the teams are under.  In practice, with team separation alone, the monolith turns into a hairier monolith. The only decoupling that’s achieved is the decoupling of practice from theory.

So in general, it is pragmatic to identify change clusters—adjacent systems that typically change together—and set up teams aligned to these clusters.

Reshape Initiatives to Fit the Team Design

At first blush, this might feel like the tail wagging the dog. Initiatives come from strategy, you might say, they are not to be shaped by the configuration of teams. Well, that’s the kind of thinking that led to the ‘projects’ way of funding and organizing teams with its attendant complications. 

The more interesting question is whether initiatives should come from upfront strategy or emergent strategy. If you agree that the latter is more suited to the digital age, then you have the opportunity to avoid the mega-program initiative syndrome. In the spirit of build-measure-learn, you could conceive and execute smaller initiatives that are also aligned with how digital product teams are set up. It greatly reduces inter-team dependencies, increases the odds of timely delivery, and allows you to learn before executing the next slice.

Reassurance for  Product Leadership

If you are a Product leader in an organization that is strongly divided into product and engineering teams, you might have trouble coming to terms with the suggestions in this series of posts. You might think they fuss too much over inter-team dependencies. Fuss or not, they are a real problem. Left unattended, they choke delivery and nothing of consequence ever gets done in a reasonable timeframe. That affects your credibility with the business as well.

You might feel outrage at being asked to reshape your initiatives to better fit the engineering organization—not that you came up with them in the first place—business leaders did, but you probably had a hand in shaping them. But reshaping goes hand in hand with moving from projects to a product-centric operating model. With projects, we shaped the work first and then shaped the teams to match the work. It’s the other way round in a product-centric operating model. We match the work to pre-existing teams. 

Appreciate Your Partner in Digital Product Development

In a recent interview, Marc Andreessen, the one who wrote in 2011 how software is eating the world, shared his thoughts on what ails the classic enterprise. He said that the true technologists are not the primary people there, they are not treated as first-class citizens.

This is actually a two-level problem. Business leaders don’t consider digital product leaders, who they interface with, as equals and the latter don’t consider engineering leaders as equals. This is a self-defeating mental model. It comes from assuming that one group is upstream and the other is downstream. That's a flawed, linear model. No group is upstream or downstream of the other when they jointly execute build-measure-learn iterations.

The suggestions here about inter-team dependencies are worth taking seriously in this light. It isn’t constructive if you as a product leader brush them aside saying, “we just need to work more collaboratively”. There’s a lot going on under the hood of what appears to be the product. Your engineering colleagues’ job is to build functionality that not only looks right, but is also performant, resilient, secure, compliant with regulations, observable, and easily changeable. They are the ones who are on call for incidents and outages. It’ll serve you well to better understand their world and to accommodate some adjustments to the way your team operates. I know, it’s not easy when you have impatient business stakeholders breathing fire down your neck. But it is necessary for your own sake.

Here’s one way of understanding engineering better. Ask technology leaders to take you on a tour of the engine room. Ask them for a sufficiently detailed map of systems and subsystems. At every opportunity, e.g. when discussing new functionality, ask your team to trace the flow of functionality through these systems. They’ll begin to see where dependencies come from.

You’ll find other opportunities as you start down this path. Slowly but surely, a true partnership can be forged.

Until next time, take care and prosper.

Sriram

agileorgdesign.com