The Decisions Never Stayed Closed. I Was the Only Thing Holding Them Shut.

September 28, 2026

The Decisions Never Stayed Closed. I Was the Only Thing Holding Them Shut.

The same decision would come back to me days later, sometimes weeks after I thought it was closed. Not because anyone disagreed with the call. Because a different set of people happened to be in the room the second time, and none of them had ever heard the decision made the first time. I would explain it again, close it again, and wait to see how long it held this time.

I knew from experience this would not hold. Fifteen direct reports plus consultants, spanning software engineers, QA, DevOps, technical writing, business analysts, and a scrum master. No middle layer between me and any of it, and no budget to add one. Every escalation routed to me, not because I believed that was the right shape, but because promoting or hiring into a management layer was not funded.

What actually wore me down was not the volume of decisions. It was making the same one repeatedly, watching it dissolve back into an open question the moment I stepped out of the room that had settled it. There was no artifact holding anything closed. There was only me, present, holding it shut by being there, and the moment I was not, it reset. Nothing had ever been built for the team to hold state in, so nothing held except my own continuous presence.

Conventional wisdom says stay lean. Add layers only when you are forced to, because hierarchy is overhead and flat moves fast, and it treats that as confidence, a deliberate choice made because lean works. Mine was not confidence. It was a budget line that would not move, and knowing the structure would not hold did not change what it could hold.

The same belief governs how companies fund infrastructure one level up: invest in the system, and the headcount running it can stay as lean as the investment allows, because that is supposedly what the investment buys. Every technical leader who has held a flat structure past the point where it actually worked, whether by choice or because nobody funded the alternative, knows some version of my repeating reset. Almost none of them name it while it is happening.

Flat was not the failure. Bloated is not the fix either; I have watched leaders overcorrect into six layers of management and drown just as thoroughly, only slower and with more meetings. The actual failure sits underneath both directions: nobody derives the ratio between what is being carried and what it takes to carry it, on purpose, as scope changes, and seeing that the ratio is wrong is not the same as anyone owning what to do about it.

I saw it. I did not have the budget to act on what I saw, and nobody above me was assigned to reconcile that gap either. The ratio simply held, by default, until it broke, and nothing forced anyone, at any level, to notice the crossing.

The missing capacity does not disappear when the ratio breaks. It gets absorbed. On my team, it was absorbed by me, personally re-closing the same decisions on a loop. At a much larger scale, it gets absorbed differently.

Oracle's own FY2026 filing shows roughly 141,000 employees against about 162,000 the year before, with research and development taking the sharpest cut of any function, from 50,000 down to 43,000, while capital expenditures rose from $21.2 billion to $55.7 billion, attributed to data center expansion. Nobody in that filing claims those two numbers are connected, and they should not be read as cause and effect. What the filing actually shows is that the asset being built and the population sized to operate it are two separate decisions, running on two separate clocks, with nobody assigned to reconcile them.

That gap is what I call Coordination Debt: work that should move once moving multiple times, because the capacity to close it structurally was never installed. It does not show up on a headcount chart or a capex chart. Both only show what was spent or cut, never what had to be redone. Press reports describe Oracle beginning another round of cuts in September, though the company has confirmed no specific number. Whatever that figure turns out to be, the more durable fact already sits in the filing: infrastructure and operating capacity are moving on separate schedules, and nobody owns the space between them.

The leaders who get this right do not run leaner than everyone else. They stopped trusting last year's ratio just because it worked last year, and started asking the question on purpose, before growth answered it for them.

The system does not need fewer layers or more headcount by default. It needs someone who treats the ratio between scope and capacity as something that expires, not something that is proven. The same growth that made the old ratio work is the growth that ends it, and nothing forces anyone to notice the crossing except a decision to look.

Someone has to own re-deriving that ratio on a cadence, before it breaks. Right now, for most teams and most companies, that ownership does not exist. Silence gets inherited and mistaken for a system that is holding.

Name the last time your team or your organization grew, in scope or in what it is carrying. Now ask who re-derived the capacity needed to operate that new scope, on purpose. If the honest answer is nobody, you are running on an inherited ratio, and you will not know it is wrong until it breaks.

LeadershipOS™ has the full architecture for owning that re-derivation on purpose, including the cost of skipping it, Coordination Debt, mapped end to end: http://TheLeadershipOSBook.com

Anthony S. Jackson

Anthony S. Jackson

Anthony S. Jackson has spent 30 years inside technical organizations. He is the author of the Architecture Protocol Series: three books on the structural problems technical leaders were never told they would face. He writes the LeadershipOS™ Inner Circle, a monthly printed newsletter for CTOs and engineering managers who design teams that hold under pressure.

LinkedIn logo icon
Back to Blog