A number of large enterprises have started saying the same thing out loud this year: the org chart is slowing us down.
Charles Lamanna, who leads Copilot, Agents and Platform at Microsoft, made the clearest version of this case in August. His piece, “Changing How We Build,” describes a real shift inside his own organization: engineers who used to hand-write every line of code now direct an “agentic coding machine” instead, and the bottleneck that used to sit in typing has moved to judgment — architecture, strategy, and knowing whether what got built is actually good. His org restructured around that shift with small “super teams” organized around agentic coding, and shipped products like Copilot Cowork and Microsoft Scout from concept to general availability in months. Near the end of the piece he writes the line worth sitting with:
“I’ve started treating the evolution of our teams and structures as my main work product as a leader.”
That’s a real, well-earned claim, not a talking point. Redesigning how a team works is genuinely harder, and more consequential, than shipping the next feature — and saying so publicly, as a leader at that scale, is a legitimate thing to be proud of.
It’s also a diagnosis that isn’t new, and I don’t say that to take anything away from it.
I’ve watched this movie before
Before project and capital governance, I worked in construction management, where this exact hybrid has been standard practice for longer than anyone currently writing about “agentic coding” has been alive.
A construction site team — the project manager, the superintendent, the field engineers — is anchored to one job for its entire duration. They don’t split time across projects. They live at that site until it closes out, then get reassigned to the next one. But a whole layer of roles never leaves the home office and flows across every active job at once instead: estimating, safety, equipment and fleet dispatch, procurement, scheduling and project controls. One project controls team routinely supports several active jobs at the same time, because that discipline doesn’t need to live on-site to do its work. Some roles anchored to a problem, some roles flowing to where they’re needed — that’s not a new invention. That’s a construction site in 1985. It’s also, in the more academic language of organizational design, somewhere between a strong matrix and a fully projectized structure — a spectrum that’s been mapped and named since long before anyone called it a “work chart.”
And construction already has the exact failure mode this essay is about. It has a name: closeout. When a job finishes, the site team scatters to the next project almost immediately, because the next job needs them now. The thing that’s supposed to survive that scattering — as-built drawings, the final punch list, the record of why a design deviated from the original plan — is famously the first casualty of that speed. Everyone in the trade knows it. As-builts get rushed or reconstructed from memory weeks later, after the people who actually knew why a decision got made are already three states away on the next job.
Lamanna didn’t invent the org chart’s replacement. He described a pattern that construction, and organizational-design theory more broadly, worked out decades ago. What’s actually new is the clock speed — and the fact that a discipline running this pattern for the first time doesn’t yet seem to know it needs its own version of closeout.
The org chart was doing two jobs
Hierarchy — in construction, in software, anywhere — was always doing two different things at once, and most leaders have only ever noticed the first one.
The first job was routing: getting information and a decision to whoever could act on it. That’s the job Lamanna’s piece is squarely about, and the job construction’s site-team model already solved well: fast, direct, dedicated authority for the duration of the work.
The second job was custody: preserving who decided what, on what evidence, so someone could reconstruct it later. Construction’s answer to that job is closeout, and closeout is also the part everyone already knows gets skipped. Software’s version of “super teams” has the same structure and, so far, nothing playing the role closeout is supposed to play at all.
Redesign the org around speed and judgment without redesigning what happens to that second job, and it doesn’t get fixed along with the first one. It just goes quiet — faster than it used to.
Trust in the artifact isn’t trust in the decision
Lamanna’s piece actually spends real effort on an adjacent version of this tension. His central argument is that once a small team can ship dramatically more, the temptation is to ship more stuff — and the discipline that matters instead is investing the surplus in trust: fewer incidents, fewer support tickets, fewer critical escalations, the same outcomes leadership cared about before AI, not new vanity metrics. That’s the right instinct, and the numbers he cites back it up.
But that’s trust in the artifact — is the code good. It’s not the same question as trust in the decision — can anyone, later, reconstruct why the team built it this way instead of the alternative it didn’t choose. Construction learned that distinction the hard way too: a building can pass inspection with excellent workmanship and still leave the owner with no record of why a load path was rerouted mid-project, because the as-builts were rushed.
Picture the software version: a small, fast team ships something in months that used to take years, then disbands because the people are needed on the next “super team.” Eighteen months later, someone asks why that team made a specific call — why it built the feature the way it did, why it walked away from an alternative, why it accepted a piece of debt that’s now someone else’s problem. The honest answer is often: ask the two or three people who happened to be in the room, if you can still find them, and hope they remember correctly. That’s not a flaw in what Lamanna built. It’s the part his own frame doesn’t claim to answer, because it was never the question he was asking.
The evidence problem doesn’t go away. It just changes address
Once a team dissolves, this stops being an org-design question and becomes a decision chain-of-custody question: who decided this, on what evidence, under what authority, with what uncertainty accepted at the time — and can the enterprise still answer that after the team that made the call no longer exists in that form?
The instinct here is usually to solve it by centralizing — one shared system, one dashboard, one model context that captures everything every team produces. That instinct is understandable and it’s also a mistake. A central repository of everything a team produced doesn’t automatically know which record was authoritative, which conclusion was superseded, or which piece of context turned an ordinary technical note into the reason a project changed direction. Centralizing raw output creates the appearance of memory without the discipline that makes memory usable — a warehouse full of unlabeled as-builts is not a closeout process.
The alternative isn’t centralizing everything, or accepting that nothing survives. It’s deciding, deliberately, what has to travel with a decision when the team that made it moves on — and keeping that requirement small enough that a fast team will actually produce it: a minimum governed output. The smallest, proportionate record of what was decided, on what evidence, by what authority, with what alternatives considered, that a later reviewer would need to reconstruct the decision without having been in the room. Not a status report. Not a full audit trail. Just enough that the decision survives the team that made it.
The redesign that actually holds up
Lamanna is right that the bottleneck moved, and right that the answer is redesigning the system around the new tool instead of bolting it onto the old one. That’s real, and it’s rarer than it sounds — most organizations are still wiring electricity into a factory built for steam, to use his own comparison.
But treating team structure as your main work product as a leader has to include the structure’s memory, not just its speed. Construction figured out the anchored-and-flowing org chart generations ago and still hasn’t fully solved what happens at closeout. Software just inherited the same structure at a faster clock speed, with no closeout process at all yet. The org chart is the easy redesign, and the one getting all the attention this year. The harder one is what has to survive after the team that made the decision doesn’t.
Speed was never the scarce resource. A reconstructable decision is.
This is the exact architecture question the Federated Governance model in Forensic Capital Governance was built to answer — not by centralizing every team’s work, but by defining what has to survive it. Forensic Capital Governance, my book on evidence-based capital stewardship, arrives September 2026. More at forensicgovernance.com