Organisational slowdowns usually get read as people problems. Teams aren’t collaborating well. Decisions are taking too long. I’ve watched this play out more than once, but nowhere more clearly than in a large scaling program over several years. More people joined. Delivery slowed. Decision quality degraded. Leaders asked for better alignment, more dependency tracking, more upfront planning. The program didn’t recover. It froze.
What was happening wasn’t a failure of collaboration or culture or willingness. It was something more structural, and because it was structural, every behavioural intervention made it worse. I started calling it coordination paralysis.
The core idea
Coordination paralysis occurs when the cost of aligning across team boundaries grows faster than the value that alignment creates.
Every shared dependency between teams requires synchronisation. Every synchronisation is overhead. Overhead produces commitments that shift. Commitments that shift produce more tracking, more meetings, more pre-planning sessions to resolve what couldn’t be resolved in the last ones. Eventually developers sit at the end of this chain, inheriting dependencies they have no mandate to resolve.
The visible symptom is commitments nobody can keep. The less visible one is more damaging: good decisions stop being made, because the coordination cost exceeds what the decision is worth. Proposals don’t get rejected. They get acknowledged as good ideas, then suspended indefinitely. Engineers and product leads stop pushing for improvements, not because they lack courage or conviction, but because they’ve learned what pushing costs.
In the program I observed, a tech lead proposed a simple architectural change that would have removed a dependency between two teams. Technically sound. Some agreed it was worth doing. Others thought it too small to matter, that it didn’t address the larger issues. For the team that would carry the implementation, it looked like a burden; for the team that would benefit, it looked like a fix. Too many decision forums involved, too many layers, too many nodes with a stake or a veto. The proposal never made it beyond the state of a proposal. Nobody could make it happen, not even the two teams most directly affected, together. The tech lead kept pushing. After months of friction, they stopped, and started wondering if the problem was them.
It wasn’t.
This is not a coordination failure
When delivery slows, the instinct is to diagnose a coordination failure: teams aren’t talking enough, boundaries aren’t clear enough, people aren’t aligned enough. The fix is more governance: dependency tracking, status reporting, synchronisation rituals.
This diagnosis is wrong, and the governance fix makes things worse.
Coordination paralysis is not what happens when coordination breaks down. It’s what happens when the system was designed, or allowed to drift, into a state where coordination is the default mode of operation. The problem isn’t how teams coordinate. It’s that the boundaries between them require constant coordination to function at all, until the cognitive load of the teams involved is exceeded and coordination quietly stops happening.
More governance adds a new dependency: to a governance body, its rules, its cadence. It consumes the time and attention that would otherwise go toward removing the underlying dependencies. Less time on structural work, more misalignment, stricter governance — a death spiral.
The socio-technical slice
Modern org design aims at aligned autonomy: teams that can move independently while staying directionally coherent. It’s a reasonable goal. Coordination paralysis is what happens when that goal isn’t properly designed into the system, or isn’t adapted as the organisation scales and changes.
The word I keep returning to is slice. The fundamental boundaries come from how you slice the socio-technical system: teams, domains, systems, responsibilities, decision rights. Those boundaries determine what requires coordination. Coordination that isn’t designed tends to become blocking. Blocking dependencies determine your delivery cadence, which defaults to the slowest team in any dependency chain. Always.
The problem isn’t usually that someone drew the boundary carelessly. It’s that boundaries that worked at one scale or one phase of a product’s life stop working as things change, and nobody goes back to redraw them. The slice drifts out of alignment with reality. Coordination costs accumulate quietly, below the surface, until they exceed the value they’re supposed to enable.
What culture is actually doing
If the structural problems were this severe, you might wonder how anything shipped at all.
Culture. People worked harder. They found workarounds. They took on coordination costs personally rather than letting features stall. They absorbed the friction.
The cultural read of these situations is almost always wrong. Leaders see misalignment and conclude the culture needs fixing. What they’re actually seeing is culture doing its job: keeping a broken system operational.
Culture isn’t the problem. It’s what kept the program running despite the problem.
It absorbs the damage, and in doing so, masks it.
Culture is also finite. The goodwill and extra effort that compensate for badly drawn boundaries don’t regenerate indefinitely. When it runs out, the structural problems become very visible — by then, a lot has been lost.
Dependencies can be designed
The alternative to managing coordination is removing or pre-resolving the coordination need. Dependencies between teams don’t have to be blocking or synchronous. That’s a design choice, often an implicit one, but a choice.
Some of this lives in the technical system. CI/CD pipelines encode release coordination into automation. API and data contracts with versioning allow teams to evolve independently without synchronising on every change. Event-driven architectures let a producing team emit and a consuming team subscribe, with no blocking handoff between them. Deliberately duplicating data to give a team autonomy, even at the cost of some consistency, is sometimes the right call. Accepting redundancy to remove a blocking dependency is a trade worth making explicitly.
Some of it lives in product and organisational design. Independent roadmaps with published interfaces define what a team will deliver and what others can depend on. They replace jointly planned roadmaps that create mutual blocking. Async RFC formats with a response deadline replace synchronous alignment sessions. Explicit decision rights, documented per domain, mean a team doesn’t need sign-off to move. In design, a shared design system serves the same function: teams consume and contribute without synchronising on every component decision.
Two categories are worth separating. Tools that support synchronous and asynchronous collaboration — shared documents, design tools, messaging platforms — reduce the friction of coordination. They don’t remove the dependency. Two teams still need to reach a decision together; they just do it in a shared doc rather than a meeting. That’s useful, but it’s optimisation. The more powerful moves encode coordination into a system, so the teams don’t need to meet at all.
When to re-slice
The governance reflex when delivery slows is understandable. It’s visible, actionable, and feels responsible. But before reaching for it, the more useful question is: is this a people problem, or a boundary problem?
There are signals, though none is diagnostic alone. Commitments drift repeatedly, always explained as one-offs, never examined as structural. Good ideas stop surfacing from engineers and product leads, not from lack of ambition, but because the last person who pushed something cross-boundary learned what that costs. Teams build workarounds and local solutions that leadership reads as misalignment; it’s usually self-preservation. And when velocity decouples from headcount, with more people joining but delivery not accelerating, coordination overhead is often eating the capacity gain.
The question each signal should prompt is: is this behaviour a response to a structural constraint?
If delivery has slowed, it’s worth asking whether dependencies and boundaries can be redesigned before adding governance. If things have come to a halt, adding tracking, roles, or process to fix the symptoms is almost certainly wrong. The right move is to re-slice: to look at domains, teams, systems, decision rights, and responsibilities together as a socio-technical system, and redraw the boundaries to reflect how the work actually needs to flow.
Re-slicing is multi-dimensional. Looking at only the org chart, or only the technical architecture, will likely break the other dimensions. Domain-Driven Design, Team Topologies, slicing strategy, role definition. These need to be in the same room. The exercise is harder than adding a governance layer, and it takes longer to see results.
Naming it matters
Coordination paralysis. Not a motivation problem, not a culture problem, not a failure of individual teams. A structural consequence of where the boundaries were drawn, and of what happened when those boundaries stopped fitting the work.
Naming it doesn’t fix it. But it changes the conversation. It shifts the question from “why aren’t people collaborating better?” to “what did we design that made collaboration this expensive?” That’s a harder question. It’s also the right one.
Aligned autonomy is the goal. Coordination paralysis is what that goal produces when the slice hasn’t been thought through, or when the world changed and the slice wasn’t updated. It tends to emerge quietly, sustained by the culture absorbing what the structure can’t handle, until there’s nothing left to absorb.