When Coordination Overhead Starts Slowing You Down
Every portfolio has a moment when the delivery dates start slipping and nobody can say exactly why. The projects are staffed. The people are capable. The plans looked sound. Yet the whole thing is running slower than it should, and the calendar keeps moving in the wrong direction.
The standard response is to add coordination. More status meetings. A tighter reporting cadence. A new dashboard. A programme manager to pull it all together. It feels responsible, and for a while it even helps.
Then, past a certain point, it stops helping and starts hurting. The extra coordination overhead, the time and attention spent not on doing the work but on keeping all the work aligned, begins to consume more capacity than it saves. Delivery gets slower, and the natural conclusion is that you need still more coordination. That loop is one of the most expensive traps in multi-project organisations, and this piece is about how to recognise it and step out of it.
Why coordination feels like the answer
When work slips, the visible symptom is nearly always a coordination failure. A handoff was late. Two teams assumed different things. A dependency surfaced that nobody had flagged. A decision sat waiting for a meeting that was three days away.
Each of those is real, and each looks fixable with more coordination. So you add a sync, a checkpoint, an owner. The next miss gets its own mechanism. Coordination accretes one sensible decision at a time, and no single addition ever looks like the problem.
The trouble is that you are treating the symptom of a loaded system as though it were the cause. The missed handoffs are not happening because coordination is too light. They are happening because there is too much work in flight for the number of connections that work creates. More coordination manages the symptom. It does nothing about the load, and the load is what generates the symptoms in the first place.
Why coordination overhead grows faster than the work
Here is the part almost nobody puts numbers to.
When you add a project, you add its work. But you also add relationships, and relationships do not grow in a straight line. They grow with the square.
Two projects sharing people and dependencies have one relationship to manage. Three have three. Four have six. Five have ten. By the time you are running ten concurrent projects on a shared pool of people, there are forty-five possible pairs that can collide, wait on each other, or need aligning. The work roughly doubled from five projects to ten. The coordination surface more than quadrupled.
That is why coordination overhead behaves so treacherously. At low load it is almost invisible, because there are few connections to manage. Each new project seems nearly free. Then the connection count climbs faster than headcount ever can, and the same coordination that used to cost an hour a week starts costing a day.
Nobody decided to spend that day. It arrived unnoticed, one reasonable meeting at a time, as a mathematical property of running many things at once.
The Coordination Ceiling
There is a name for the point where this turns. Flow Economics calls it the Coordination Ceiling: the level of concurrent work past which adding another project reduces the total the portfolio delivers, rather than increasing it.
Below the ceiling, more projects mean more output. Above it, the marginal project consumes more coordination and more contested capacity than it contributes, so throughput, the rate at which the organisation actually finishes valuable work, starts to fall even as more work is pushed in.
The unsettling thing about the ceiling is that you cannot see it in any single project. Every project on the list can be individually justified, well run and on a sensible plan, and the portfolio as a whole can still be above the ceiling and losing ground. This is a version of what Flow Economics calls the Project Illusion, the belief that a portfolio of well-managed projects must be a well-performing portfolio. It is not, and coordination overhead is one of the clearest reasons why. The fuller treatment lives in the Coordination Ceiling framework.
Why more governance eats the constraint
There is a second cost, and it lands in the worst possible place.
Coordination is not free labour drawn from a spare pool. It is paid for by the same people the work depends on, and disproportionately by the scarcest of them. Your most senior engineer, your one architect who understands the platform, your lead clinician, whoever sets the pace for everything else, is exactly the person pulled into the alignment meetings, the escalations and the status reviews.
Flow Economics calls that person, or team, the constraint: the scarce resource that governs how fast the whole portfolio can deliver value. Every hour the constraint spends being coordinated is an hour it is not spending doing the work that only it can do. So the coordination you added to recover the schedule is drawn straight from the one resource whose time determines the schedule.
This is how well-intentioned governance makes delivery slower. Not through waste in the ordinary sense, but by spending the most valuable hours in the organisation on managing the consequences of having started too much.
The move most organisations skip: take work out
The way back under the ceiling is not better coordination. It is less to coordinate.
If the coordination surface grows with the square of the work in flight, then removing work is the highest-leverage move available, because you are not subtracting one project's effort, you are subtracting all of its connections at once. Take two projects out of a portfolio of ten and you do not remove a fifth of the coordination load. You remove far more, because you delete every pairing those two projects were part of.
In practice this means running the portfolio deliberately below the ceiling. Decide how many projects the constraint can genuinely carry, hold the number of active projects at or under that limit, and make new work wait in a visible queue rather than starting it the moment it is approved. Fewer things in flight, more things finished, and a coordination load that stays proportional to the value being produced rather than exploding past it.
It feels like slowing down. It is the opposite. A portfolio that finishes its work sooner frees its people sooner, and a smaller set of concurrent projects is far cheaper to keep aligned. Less started, more delivered.
The question worth asking instead
The reflex to add coordination is not wrong because coordination is bad. It is wrong because it treats a load problem as an alignment problem, and the two have opposite cures. When delivery is slipping and the meetings are multiplying, the most useful question is not how to coordinate the work better. It is how much of it should be in flight at all.
If your organisation is somewhere on that curve and not sure where it sits, the Flow Economics framework sets out how to find the ceiling and run beneath it.