Span of Control Breaks Long Before the Org Chart Admits It

Fifteen direct reports. An offshore consulting team of the same size sitting alongside them. For a stretch last year, no product owner in the seat, so a piece of that work landed on me too. Somewhere around thirty people were operating in my coordination radius at any given moment, and every one of my one-on-ones during that time ran shorter than the person on the other end actually needed.

I have spent years building the operating model for exactly this problem. Communication, Cadence, Coaching, Culture, and Continuity: the five layers of the LeadershipOSâ„¢ Stack. I can walk into someone else’s organization and diagnose a broken decision architecture in twenty minutes. I still hit a point last year where I did not have full context on everything moving through my own team, because the amount of context required to hold it all had grown past what one person can carry, no matter how good that person is at the job. That is the detail that stayed with me: not the missed deadline, not the escalation, but the quiet moments in one-on-ones where I knew, in real time, that I did not have what the person across from me actually needed, because I had spent the context somewhere else that week.

The conventional answer right now is to flatten. Cut the management layer, push decisions down, trust the team. That advice is not wrong, exactly; it is incomplete. Organizational design swings between centralizing coordination and distributing it, and whichever direction is currently fashionable gets treated as the permanent fix instead of one side of a cycle that will swing back the moment its own failure mode becomes visible.

Here is what flattening never answers: where the coordination work actually goes when the layer holding it disappears, or was never installed. In my case it went three places at once. Some of it landed back on me, decisions and context sitting until I personally had bandwidth to route them. Some of it was picked up informally by senior people who started coordinating dependencies and information flow that was never in their job description, doing the work with no title and no recognition for it. Some of it simply did not happen: things dropped, not from carelessness, but because no one owned the surface where they were supposed to be caught.

That is Coordination Debt: the cost of removing coordination capacity, or never building it, without redesigning where those functions go. The org chart looks lean. Delivery continues. Underneath it, someone, usually the most senior and least protected person in the system, is absorbing an undesigned load that never shows up on a dashboard until the moment they cannot carry it anymore.

The leaders who get out of this are not the ones who find more hours or perform more Heroics. They stop treating the strain as proof they are working hard enough, and start asking what part of this coordination work was ever actually designed to be held by a system, instead of by me.

Span of control is not a headcount number. It is a coordination-capacity threshold, and where that threshold sits depends on how much of your coordination infrastructure is actually installed versus how much still routes through you as a person. Most leaders never find out where it sits until they are already past it, because the warning signs get absorbed instead of named. A shortened one-on-one looks like a busy week, a senior engineer quietly picking up coordination work looks like a good teammate stepping up, and a dropped decision looks like an oversight.

None of it looks structural, because the leader is the one absorbing it, and absorbing it feels like the job. Adding a layer does not fix that by itself. If the new manager is not paired with real Decision Boundaries, a working Cadence, and Shared State the team can operate from without you, that person becomes a second body absorbing the same undesigned coordination surface you were absorbing alone.

Before you add a layer or flatten one away, ask yourself one question: if you were unreachable for forty-eight hours this week, would the decisions that need to move still move? If the honest answer is no, the org chart is not the constraint you think it is.

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOSâ„¢: http://TheLeadershipOSBook.com

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you're reading this outside the daily email, subscribe free: https://technicalleader.coach/daily-email