The Dependency Mathematics Of Scaling

Every scaling conversation eventually reduces to dependencies. The frameworks differ in vocabulary and ceremony, but each of them is fundamentally a mechanism for making dependencies visible early enough that they can be sequenced rather than discovered at integration. That is a worthwhile thing to do. It is also, almost always, the second-best available move.

The reason is arithmetic, and it is worth being precise about because the imprecise version — "more teams means more coordination" — is true but too weak to change any decisions. The strong version is that coordination cost grows super-linearly in team count while delivery capacity grows at best linearly, which means there exists a team count beyond which adding another team reduces total throughput. Most organisations discover this empirically, interpret it as a management failure, and respond by adding coordination capacity, which moves the threshold in the wrong direction.

What follows is the shape of the curve, a taxonomy of what you are actually counting, how to measure it in a way that survives contact with a steering committee, and the strategies that remove dependencies rather than administering them.

Why the curve bends

Take n teams that all need to talk to each other. The number of pairwise channels is n(n−1)/2 — three teams have three, six teams have fifteen, twelve teams have sixty-six. Doubling the team count roughly quadruples the channels. This is the familiar part, and on its own it would be manageable, because most pairs of teams do not in fact need to talk.

The part that bites is what happens to each individual dependency once it exists. A dependency is not a line on a diagram; it is a queue. Team A needs something from Team B. Team B has its own backlog, its own sprint boundary, its own priorities set by someone who does not report to A's stakeholder. So the request waits: first for B's next planning boundary, then for B's queue to clear, then for A's next boundary to pick the result back up. The elapsed time is dominated by waiting, not by the work, which is the same argument made in why-busy-teams-are-slow-teams and it compounds here.

Now chain them. If a piece of work requires something from three teams in sequence, its lead time is not the sum of three pieces of work but the sum of three queueing delays, each of which is a random variable with a long right tail. The expected duration of a chain is the sum of the expectations, but the variance accumulates too, and delivery dates are set against the tail rather than the mean. This is why programmes with many cross-team dependencies do not merely run late; they run unpredictably late, which is organisationally far more damaging because it destroys the ability to plan anything else around them.

There is a third compounding factor. Because organisations that fund teams fully tend to fill them fully, the queueing delay on each dependency sits in the non-linear region of the utilisation curve. So the per-dependency cost rises as the organisation gets busier, at the same time as the dependency count rises with team count. Two multiplying effects, neither visible on a Gantt chart.

Three kinds of dependency, three different fixes

Treating all dependencies as one category is the reason dependency management processes fail. They are not the same thing and they do not respond to the same intervention.

Knowledge dependencies. Team A cannot proceed because only Team B understands the domain, the system, or the decision. Nothing needs to be built by B; something needs to be known. These are the cheapest to remove and the most frequently mismanaged, because the standard response is to schedule a meeting rather than to transfer the knowledge. Fixes are documentation with a genuine owner, pairing across team boundaries, rotation, and architectural decision records. A knowledge dependency that recurs more than twice is a training gap masquerading as a coordination problem.

Resource dependencies. Team A needs a specific person or a scarce shared asset — the one database administrator, the security reviewer, the integration environment, the person who holds production credentials. These are queueing problems in the purest form, and they exhibit the worst behaviour under load because a single shared resource serving many teams saturates quickly. Fixes are self-service (turn the person into a paved road), capacity duplication where the skill can be taught, or explicit prioritisation with a visible queue so that the cost is at least legible. Adding a coordination process to a saturated resource does nothing; it schedules the queue more politely.

Task dependencies. Team A cannot finish until Team B builds something. This is the expensive category and the one that genuinely reflects system structure. If A needs B to build something, then the boundary between A and B is in the wrong place for this class of work. Fixes are architectural: move the boundary, move the ownership, or introduce a stable interface so that A can proceed against a contract rather than against B's delivery.

The taxonomy earns its keep the moment you sort a census by type, because the distribution tells you which intervention to fund. Knowledge-dominated is a staffing and documentation problem. Resource-dominated is a platform problem. Task-dominated is an architecture problem, and no planning cadence will touch it.

Coordinated versus eliminated

There is a persistent framing in scaled environments that treats a well-managed dependency as a solved dependency. It is not. A dependency that has been identified at quarterly planning, sequenced, agreed between two teams and tracked on a board is still a dependency. It still imposes a queue, still carries variance, still requires two sets of people to hold context about each other's work, and still breaks when either side's priorities change — which they will, because the planning horizon is longer than the horizon over which priorities are stable.

The cost difference is stark. A coordinated dependency costs a recurring fee: planning time, tracking overhead, escalation when it slips, rework when the interface assumption turns out to be wrong, and the continuing cognitive load on both teams. An eliminated dependency costs a one-off engineering or organisational investment and then nothing, forever.

	Coordinated dependency	Eliminated dependency
Cost profile	Recurring, every planning cycle	One-off investment
Lead time effect	Queue delay remains, with tail risk	Removed entirely
Failure mode	Silent slip, discovered at integration	None; the coupling is gone
Cognitive load	Both teams carry context about the other	Each team carries only its own
Scales with team count	Yes, super-linearly	No
Visible to governance	Highly — looks like progress	Barely — looks like refactoring

That last row is the trap. Dependency coordination is legible: it produces boards, matrices, red-amber-green statuses and a satisfying sense of control. Dependency elimination produces a quieter organisation and a smaller programme office, which is harder to claim credit for. Organisations systematically over-invest in the visible option.

Measuring what you have

You cannot argue this case without numbers of your own, and the numbers are obtainable in a week.

The dependency census. Take every substantial item delivered in the last two quarters. For each, record the originating team and every other team that had to change code, make a decision, grant access, review something or be waited on. Classify each link as knowledge, resource or task. You now have a directed graph and a type distribution. Look for the teams with high in-degree — they are your bottlenecks — and for the pairs with the highest link count, which are your candidates for merging or re-bounding.

Cross-team ticket counts. Most tracking tools can report how many items in a team's backlog were created outside the team, and how long those waited before being started. That ratio, tracked per team over time, is the cleanest available proxy for coordination load. A team whose externally-originated queue is growing is heading for bottleneck status regardless of how it feels about its own velocity.

Blocked time as a share of lead time. For each item, elapsed time in any state meaning "waiting for another team", divided by total lead time. This is the number that changes executive minds, because it converts an abstract structural argument into a share of the calendar, and it is the number framework-compliance reporting never produces.

Dependency survival. Of the dependencies identified at the start of a planning cycle, how many were resolved as planned, how many slipped, and how many turned out to be wrong? A low survival rate is not a planning-quality problem. It is evidence that the planning horizon exceeds the stability horizon.

Strategies that remove rather than manage

Bounded contexts as team boundaries. Domain-Driven Design's central organisational claim is that a bounded context has a single model, a single ubiquitous language and a clear interface, and that these properties make it ownable by one team. Drawing team boundaries on context boundaries means most changes are local by construction. This is Conway's Law used deliberately — the inverse manoeuvre — rather than suffered. It is the highest-leverage move available and also the slowest, because it usually implies both an architectural and an organisational change at once.

Platform services with self-service interfaces. Convert the teams that everyone depends on from request queues into products with APIs, documentation and sensible defaults. The test is whether a stream-aligned team can get what it needs without a conversation. Anything that requires a ticket to a human has not been platformised; it has been renamed. This is the highest-return fix for resource dependencies specifically.

T-shaped staffing and deliberate skill spread. Many dependencies exist because exactly one person can do a thing. Rotation, pairing and an explicit expectation that every team can perform its own testing, deployment and basic data work removes a large class of resource and knowledge dependencies. It costs short-term throughput and buys long-term autonomy, which is precisely the trade that quarterly pressure prevents organisations from making.

Ownership transfer. Where Team A repeatedly needs small changes in Team B's code, give A the right to make them — with B as reviewer rather than implementer. An internal open-source model with clear ownership, contribution standards and review rights converts a task dependency into a knowledge dependency, which is an order of magnitude cheaper. This is usually available immediately and is blocked by policy rather than by engineering.

Interface contracts and stubs. Where the dependency genuinely cannot be removed, agree the contract early and let the consuming team build against a stub. This does not eliminate the dependency but it decouples the schedules, which removes most of the queueing cost, and it is the best available option when the other team is external to the organisation.

Why "improve dependency management" is usually the wrong answer

When a programme is struggling with cross-team coordination, the proposal that surfaces is nearly always procedural: a better dependency board, a weekly dependency forum, a RAID log with sharper ownership, a dedicated dependency manager. These interventions are cheap, fast, and visibly responsive, and they do produce a small improvement — a dependency that is known about three weeks early is genuinely better than one discovered at integration.

But they address the symptom while leaving both multiplying terms untouched. The count of dependencies is a function of architecture and funding. The cost per dependency is a function of queueing, which is a function of utilisation and batch size. A dependency forum changes neither. What it does change is the organisation's tolerance for the underlying condition, by making it survivable. That is the real damage: a good dependency management process converts an acute, visible structural problem into a chronic, managed one, and chronic managed problems do not get fixed because nobody is in enough pain.

There is a second, subtler cost. Dependency management creates roles whose purpose is the continued existence of dependencies. Nobody involved is acting in bad faith, but the incentive gradient runs the wrong way, and after two years the coordination layer is the part of the operating model with the clearest constituency.

The defensible position is to do both, asymmetrically: manage the dependencies you have this quarter, while explicitly funding the removal of the top few every quarter, with the removal work protected from the delivery pressure that will otherwise consume it. If your programme has a dependency board but no dependency-removal backlog, you have chosen the chronic condition.

What to do on Monday

Pull the last two quarters of delivered work and build the census. Originating team, every team touched, type of each link. Two hours with a spreadsheet and three people who were there gets you eighty percent of the value.

Rank the links by frequency. Take the top five and, for each, write a single paragraph answering one question: what would have to be true for this dependency not to exist? Not how to manage it better — what would make it disappear. The answers will be one of a small set: a boundary in the wrong place, a capability only one team has, a piece of infrastructure that needs a self-service interface, or a policy that forbids someone from changing something they are perfectly capable of changing.

Then take the cheapest one — usually the policy or the knowledge gap — and remove it this quarter. Measure blocked time as a share of lead time before and after. One removed dependency with a measured before-and-after is worth more in the argument about your operating model than any number of maturity assessments, because it converts a structural claim into a local, verified fact.