I read The Mythical Man-Month and I lived it.
Fred Brooks published that book in 1975. He wrote it out of pain — watching IBM's OS/360 project collapse under its own weight. The insight was deceptively simple: adding people to a late project makes it later. More engineers meant more coordination cost. More coordination cost meant more drag. More drag meant slower output. The math never worked in your favor. Ten more workers gets you ten more widgets. Ten times more programmers does not get you ten times more software.
Brooks knew this from the inside. He wasn't theorizing. He was watching it happen in real time on one of the most ambitious technology programs ever attempted — and he named what he saw with precision.
I watched the same thing play out across thirty years of enterprise technology work. The pattern was consistent. A project falls behind. Leadership's instinct: add people. More developers, more testers, more managers to coordinate the expanded team. The result, almost without exception: the project slows down further. New people need onboarding. Existing people stop building to train them. Requirements get re-explained, misunderstood, re-explained again. The communication surface area grows faster than the output does.
The industry's answer was to build scaffolding around it. Agile frameworks to coordinate the work and allow changes to flow through the system faster. Cross-functional teams to reduce handoff latency. Sprint ceremonies to keep requirements visible and alignment current. Monitoring stacks to detect the bugs that miscommunication introduced. Requirements management tools to keep specifications from drifting. SAFe and its variants to coordinate the coordination.
The requirements were misunderstood. The organizational inertia was real. The coordination overhead was the actual constraint. We built an entire industry apparatus to work around it.
For fifty years, no one found a way through it. Brooks's Law became the foundational constraint of every software company that followed. The ceiling. The invisible law governing how fast technology organizations could actually move.
Then, in 2022, something changed.
Why Brooks Broke
Martin Casado at a16z and Abhishek Nagaraj at Berkeley published a Fortune piece declaring Brooks's Law broken. They're right.
The argument is clean: AI shifted the production function away from human coordination and toward compute. Smaller teams. Bigger budgets. Output that scales with data and infrastructure, not headcount. Their internal data shows the largest AI companies running nearly three times the revenue per employee of traditional software firms.
But here's what the numbers don't fully capture — and what thirty years of practitioner experience makes visible:
The tools now remember the changes. They track the requirements. They hold the context across sessions, across contributors, across time. The thing that made the communication tax so expensive — that every handoff was a lossy transfer, that every new team member started from near zero, that every sprint was partly about reconstructing shared understanding — that tax is gone.
The scaffolding built to manage the human coordination tax is no longer load-bearing.
Which means the ceiling Brooks described is gone. Casado and Nagaraj are right about that.
What they didn't name is what's left when you remove the ceiling and the scaffolding simultaneously.
What's left is organizational drag. Inertia. The weight the scaffolding was also hiding.
The Alibi
Here's what happened when the ceiling broke.
For fifty years, organizations could point to engineering complexity as the reason transformation was slow. The coordination tax was real. The Mythical Man-Month was real. When a technology initiative stalled, when a transformation program delivered less than promised, when digital strategy failed to translate into competitive advantage — there was always a credible technical explanation. You couldn't scale engineering fast enough. The complexity made it hard. Brooks said so.
That alibi is gone.
AI removed the technical constraint. Capital can now be deployed at speed. Small teams can build generation-defining companies. The supply-side problem Brooks identified — you simply couldn't build great software companies fast enough — has been largely solved.
What remains is the truth about organizational readiness.
The inertia was always there. The broken processes, the territorial boundaries, the undocumented decisions, the cultural failures — they were survivable at human speed. When every initiative moved slowly by default, organizational drag was invisible. It blended into the background noise of normal.
You can't hide organizational failure at AI speed.
The Bottleneck Migrated
When a constraint breaks in a system, the system doesn't become unconstrained. The pressure moves. Water finds the next crack.
Casado and Nagaraj described the supply-side unlock precisely. What they didn't answer is: who can absorb the transition?
That's a different question. And in 2026, it's the more consequential one.
Because the majority of organizations that need to transform aren't building frontier models. They're not OpenAI or Anthropic or Cursor. They're enterprises with decades of operational history, inherited infrastructure, and workforces that have never operated in an intelligence-native environment. They're mid-market lenders. They're manufacturers. They're the organizations running platforms the tech press has been declaring dead for thirty years — and that still process more commercial transactions daily than most people realize.
For those organizations, the binding constraint isn't compute budget. It's not team size. It's not tooling.
It's distance.
The bottleneck didn't disappear. It migrated — from engineering coordination to organizational readiness. Brooks governed the production of software. The new law governs the adoption of intelligence.
The Knowledge Distance Problem
I named this in May 2026, but I've been watching it operate for years.
The Knowledge Distance Problem describes the gap between where an organization currently operates and where it needs to operate to leverage AI at speed. It has three distinct dimensions — and most organizations are only aware of one.
This is what Brooks's Law was masking. The coordination ceiling he identified was real — but it was also functioning as a pressure valve. It kept organizations from moving fast enough to expose what was underneath.
AI removed the valve. The KD Problem is what was always underneath.
What Closes the Distance
More capital doesn't close it. More tooling doesn't close it. Another framework layered on top of existing inertia doesn't close it.
What closes knowledge distance is readiness architecture — the deliberate work of measuring and closing the gap across all three dimensions before the distance becomes permanent. Human readiness: do your people have the mental models to operate in an intelligence-native environment? Operational readiness: are your processes structured to surface knowledge rather than bury it? Technical readiness: is your infrastructure positioned to compound AI rather than merely tolerate it?
This is what the HOT framework is built to diagnose. Not a maturity model. Not a checklist. A way to see the distance clearly — across all three layers, at the same time — so the work can be sequenced rather than scattered.
comes first
runs alongside
serves the first two
The organizations that do this first don't just make a successful AI transition. They build a structural advantage that compounds. Because in the world Casado describes — where capital deploys faster, where small teams produce outsized output, where the coordination ceiling is gone — the organizations that close distance fastest set the tempo for everyone else.