TBM 262: Dependencies In Fast(er) Growing Companies (Part 2)
This post is Part 2 of my Dependencies In Fast(er) Growing Companies series. The focus of this series is, as the name implies, an exploration of dependency wrangling in faster-growing companies. You can read Part 1 here, where we more broadly set up the problem.
Part 2 offers two key ideas:
An increase in dependencies requires an expanded frame of reference.
The challenge of managing dependencies is a) often about surrounding context, and b) efforts to manage dependencies can make things worse.
As Dependencies Increase…
When the number of dependencies in your company increases, you will need:
An increasingly formalized mechanism for making "tie-breaking" decisions. Should team A help team B or team C? This mechanism can be a system—an apples-to-apples prioritization heuristic, for example—or it can be a person or group of people (or both).
To start thinking about limiting work in progress across an increasingly larger boundary of teams, groups, and departments. An independent team can focus locally on its work-in-progress limits and utilization rates. When things go wrong, the impact is local. As teams become increasingly dependent, you must think about flow and utilization at the team-of-teams or organization-wide level; otherwise, things can get out of control very quickly. In effect, you have one big team.
To start thinking about capacity allocation and return on investment on an org-wide level. Imagine you have 100 independent teams. With 100 independent teams, you can ask questions like "How much do we pay team X, and how much money did they make us?" Even with a moderate number of dependencies, limits on flow, throughput, and impact start to take on a more global flavor. An uncomfortable high % of all money spent on salaries is going to context switching, handoffs, teams being blocked, and meetings about surfacing, advocating for, coordinating, and re-coordination dependencies.
In short, as dependencies increase, so does the need to treat the web of dependencies as a single entity (a "team of teams") and not as a bunch of smaller, independent teams. This dynamic does not stop at the boundary of product development. You have the same challenge when you have centralized GTM, product launch, legal, and product marketing teams that must touch all the work.
Finally, the curve is not linear. As the number of dependencies increases, you get a rapid rise in the demand for more global prioritization, reducing WIP on the global level and thinking about overall capacity allocation vs. team-level capacity. There is an inflection point beyond which the dependency graph explodes, and basically, every team connects to another team through one or more hops.
There are more graceful and less graceful ways to address the challenge, but the challenge is real.
Next…
How We Make Things Worse (and Easier)
One of the biggest issues with dependencies is not the dependencies themselves. Rather, it is how companies respond to the dependencies. The very tactics that some companies use to manage dependencies ultimately make the dependencies unmanageable (and negatively impact customer outcomes).
For example, in response to dependencies, many teams:
Force premature convergence on solutions (to guide estimates and planning)
Ratchet up playing Tetris and chasing high utilization rates.
Increase work in progress, handoffs, context switching, etc.
Increase planning inventories and make decisions before the last responsible moment (note the amount of dependency wrangling that takes place during annual planning for things that are very unlikely to pan out as expected)
Force middle managers into traffic cop/dependency coordinator mode vs. allowing them to spend time managing and coaching their teams.
Create perverse incentives to propose "high-profile big projects."
Encourage elaborate "horse trading" activities far removed from the people on the hook to work on the work.
Let's explore this in two “counter” examples—settings where the above doesn’t happen.
The Existential Crisis
To make the point here, I want you to imagine a team of 150 people and 18 teams. The business is experiencing an existential crisis requiring several large, cross-cutting projects. There is no time for politics or performative planning activities to secure budgets to grow individual teams. There's no time for elaborate spreadsheet math based on allocation %s pulled from a magician's hat. Roadmap cleared. Backlogs cleared. Teams form and reform to address the need at hand. Need to work together? Work together. Need to deep-dive and spike the problem so you understand it better? Go for it. Is a team blocked? Help them.
If you have ever been in a situation like this, you've felt first-hand the difference between the inherent challenges that dependencies present and the challenges they present in the context of other things like local incentives, planning approaches, budgeting, "business as usual", etc.
Remove these, and consider what you're left with.
Flow and Slack
OK. That's an extreme example. Let's try another one.
There is no existential crisis, but the eighteen teams are generally good at limiting work in progress, finishing vs. starting, managing planning inventories, taming debt and drag, and maintaining a suitably detailed roadmap (clearer in the near term, directional in the longer term). The work is generally flowing, and the ratio of non-work drag to work-related effort favors work, making predicting when things will land easier.
When dependencies pop up, the system has enough slack for teams to wait until the last responsible moment to surface, understand, and work on them. If close collaboration is required, teams have the flexibility (and the trust and confidence of the org) to make it happen. The team is also very clear about priorities and how they relate to work across the full spread of teams. They don't need executive tie-breaking. It's pretty clear what "wins" regarding urgency and value.
There's a lot of nuance in this example. Still, the big takeaway is that many of the pains related to dependencies again have less to do with dependencies and more with the surrounding situation. If an org incentivizes extremely high WIP, it doesn't matter how you try to approach dependencies. If things are going slow and trust is low, you'll just propagate that into any work you attempt. If teams are already burning 50% of their time around debt, adding dependencies will crush their productivity. If teams can't say "no, " they'll keep starting without finishing their dependency work.
Hopefully, these two examples prove a point: dependencies are hard, but the context surrounding them and how we try to manage them play a huge role (often make things worse).
To Summarize
As the number of dependencies increases, so does the need to have mechanisms for prioritization, reducing WIP, and thinking about capacity allocation on the global level
There are managing dependencies and managing the context around dependencies.