For most of the last century, the challenge of organizing large groups of people around shared work produced a consistent answer: the hierarchy. Not because anyone designed it to be optimal, but because coordination problems needed solving and this arrangement solved them. The factory needed foremen because work was physically sequential and human-carried: one person's output was the next person's input, and someone had to manage the handoffs. The office replicated the pattern because decisions could not execute themselves: someone had to carry intent from the person who owned it to the person who needed to act on it. When software engineering industrialized in the 1990s and 2000s, it did not invent a new model. It inherited the one that was already there.
The result was an org chart that most engineering organizations treat as a given, as natural as gravity. It is not. It is a solution to a specific set of problems that existed at a specific moment in the history of coordination. Understanding what those problems actually were turns out to matter now, because some of them are changing.
Five Problems, One Structure
Hierarchy did not persist because it served power, though it served power well enough. It persisted because it was doing at least five things simultaneously, and no simpler structure could do all five at once.
Three of those functions were operational: concerned with how work and its consequences traveled through the organization. The first was serialization: decisions needed a human carrier between the person who held authority and the person who needed to act. The manager was the routing layer, the node through which intent traveled on its way to execution. The second was risk distribution: hierarchy created a named person at every level who owned the outcome when something went wrong, which was not just political theater but a genuine mechanism for aligning incentives. The person two levels up had real skin in the decisions made below them. The third was information compression: raw operational reality is noise, and the team lead who summarized for the manager, who summarized for the director, was functioning as a trust-weighted filter. The executive did not receive ten thousand data points. They received a judgment made by someone who had processed those data points and was accountable for the compression.
The remaining two were social and institutional: concerned with how decisions acquire the force to bind people. The fourth was coordination under genuine uncertainty: when the environment was ambiguous and no one knew the right answer, hierarchy provided a tie-breaker, the person with the most context and the authority to commit. Democratic consensus fails under time pressure. Hierarchy resolves deadlock. The fifth, and most underrated, was political legitimacy: decisions made through the recognized structure carry authority that decisions made outside it do not. The org chart is a shared fiction that people have agreed to act as though is real. That fiction does real work.
These are five distinct problems. Fusing their solutions into a single person was not elegant design. It was the cheapest available option at the time.
The important point is not that hierarchy solved all five problems permanently. It is that these problems are separable. If new conditions weaken some of them without touching the others, the structure built to solve them all at once begins to come apart.
What Engineering Built on Top
This brings us to what the software industry did with that inheritance. When software development industrialized, it did not just adopt the management hierarchy. It extended it into something more elaborate. The coordination overhead grew with every wave of workforce expansion, driven by pressures that compounded with scale: weak alignment across larger teams, hidden cross-team dependencies, limited system visibility, uneven ownership, real compliance and release risk, and a motivation profile that shifted as the field industrialized. Teams that were intrinsically motivated could absorb many of these frictions themselves, self-aligning around problems without being managed toward them. Teams that could not, or that operated at a scale where self-alignment was no longer sufficient, required formal structure to compensate.
Much of the architecture of modern software delivery, Scrum, sprint ceremonies, architecture review boards, change advisory boards, program management layers, story point estimation, grew in response to all of these pressures simultaneously.
In large engineering organizations, the ceremony layer extends further still. A program management function exists to hold the view that no individual team can hold: who is building what, in what sequence, with what dependencies, reporting status upward until someone at the top has a synthesized picture of where everything stands. The roadmap fragments into team backlogs and reconstitutes into executive updates. The Scrum master coordinates what self-organizing teams would coordinate themselves. The change advisory board confers legitimacy on deployments that could be released without a board if the deployment criteria were written down somewhere.
Much of this ceremony persists not because it produces better decisions, but because decisions need to travel through the right nodes to acquire authorization, even when the ceremony's direct contribution to decision quality is marginal.
The ceremony is the routing mechanism made visible. It is what serialization looks like at scale.
What We Found When We Removed It
We ran an experiment internally that we called Pathfinder. The purpose was to understand what agentic development capabilities could mean for engineering team structure: not in theory, but empirically, with real teams building real things. We took work that could run autonomously, not tightly intertwined with the larger code complex, and organized it into small teams of three to five engineers. No dedicated manager. Instead, we designated a former manager as what we called the roadblock remover: available when teams could not find their own path forward, but not directing the work from above.
What we found was more precise than I expected. The teams did not stall because they lacked authority. They stalled because they could not navigate to information that already existed. The deployment rules were documented. The exit gate criteria were written down. The process descriptions were there, in policy guides and handbooks and wiki pages distributed across the organization. The problem was never that the knowledge was missing. The problem was indexing: the organization had encoded its procedures across dozens of documents with no clear path from question to answer. The manager, it turned out, had been managing that navigation function. Not making judgment calls on the process questions, but serving as a human index, knowing where to look and routing teams to the right answer quickly enough that the underlying indexing problem had never needed to be solved.
There was a second pattern running alongside the indexing problem. Some teams struggled initially not because self-navigation was genuinely difficult, but because the organizational system had never required them to do it. The manager had always been available. Asking a human had always been faster than finding the document. That is not structural incapacity. It is muscle memory: a learned default that the experiment disrupted. Teams that worked through that initial friction found their footing. The capability was there. The habit had simply never been tested.
The roadblock remover confirmed the indexing finding from the other direction, while also revealing a second distinct function. Some interventions were operational clearing: impediments that crossed team scope and could not be resolved unilaterally, shared tooling access, licensing, resource questions that affected multiple teams simultaneously. These are the kinds of things a Scrum Master would handle at the team level, and they remained genuinely useful. The other category was judgment and legitimacy: contention with other parts of the organization, decisions that crossed team scope, moments when someone needed to commit on behalf of the group with recognized authority. Those are structurally different problems from retrieval, and different again from operational clearing.
Pathfinder drew lines that the org chart had always obscured. Memory is codifiable. Operational clearing is episodic and bounded. Judgment at the boundary is not.
What Changes When Agents Can Execute
The next part of the argument follows directly from what Pathfinder found. Three distinct functions had been bundled into the management role: memory retrieval, operational clearing, and judgment at the boundary. The first is codifiable. The second is episodic and bounded. The third remains irreducibly human. The question becomes what happens to an organization's structure when agents can hold the first, and pools of human expertise can handle the second on demand.
An agent can hold institutional memory. The deployment rules, the exit gate criteria, the process descriptions, the interface contracts between teams: all of it can be encoded, and once encoded, retrieved without a human in the path. The serialization function, decisions waiting in a queue for an authorized human to pass them through, contracts sharply when execution no longer requires a human carrier. The queue thins.
The program management layer undergoes a similar transformation. Its primary function was informational: tracking what teams were building, sequencing the work, surfacing dependencies, compressing status upward. Many of those are specification problems, but not all of them. Some coordination overhead exists because information is missing or badly encoded: the dependency that was never declared, the process criterion that existed in a document no one knew to look for, the interface contract that was assumed rather than specified. Some coordination overhead exists because goals genuinely conflict, priorities shift, or resources are constrained in ways no specification resolves in advance. Agents and specification reduce the first substantially. They do not eliminate the second. Where interfaces between teams are defined in advance, the dependency graph is always current because it is always the architecture. The grand view is not a report someone produces. It is the specification itself. The funneling-up problem contracts when the information is encoded rather than carried.
Conway's Law does not disappear in this world. It transforms. Organizations which design systems are constrained to produce designs which mirror their communication structures. In the traditional org, communication structure meant reporting lines: teams talked to each other through their managers, so the architecture broke along the same lines as the org chart. In an agent-driven world, more coordination becomes mediated through specification: what agents expose to each other, what the interface contracts say, where the dependency boundaries sit. The architecture still mirrors the organizational structure. But the organizational structure is now expressed in code and specification rather than in headcount and reporting lines, even as the authority to define and change that specification remains irreducibly human.
This has one hard precondition. The interfaces must be identified before execution begins. If two teams have a dependency that is not in the specification, no agent coordination resolves it. You get a runtime collision, surfacing late, without a clear owner. The weight of the entire model rests on the upfront clarity of the architectural specification. Not planning in the old sense of Gantt charts and resource allocation. Architectural specification: where the boundaries fall, what the contracts say, which boundaries are owned by whom. That work is harder than program management. Program management tracks what is happening. Specification design decides what is possible.
What remains when the ceremony contracts is not less organization. It is organization expressed differently. Risk does not disappear when hierarchy thins: it concentrates at the interface specification layer, where one design decision governs everything an agent executes within its envelope. Specification, in this sense, is frozen authority: the decisions about what agents may do, under what conditions, and within what constraints are governance decisions, not technical ones. Political legitimacy does not disappear when the org chart thins. It migrates upward into whoever defines and governs the specification. Empty ceremony fades. Explicit governance hardens.
Management does not disappear either: it becomes a discipline rather than a permanent assignment, a pool of human judgment available at the boundaries where agent execution meets conditions the specification could not anticipate, where two autonomous teams arrive at a genuine impasse, where priorities shift and someone needs to decide what the new truth is, not to manage the work, but to resolve what specification cannot resolve. The nodes that remain in the org chart are the ones that were always doing the irreducible work. They were simply harder to see when they were surrounded by ceremony.
This argument is deliberately scoped to coordination mechanics in contexts where work is sufficiently codifiable. The human functions that managers also carried, coaching, career development, team cohesion, are real and do not encode. How organizations hold those responsibilities as structures thin is a genuine and important question. This piece does not attempt to answer it.
The Thread That Connects
This is the organizational consequence of the same shift argued elsewhere in this series: once intent must be explicit, once clarity is what makes speed trustworthy, once implementation becomes cheaper than the thinking that precedes it, the shape of the organization changes with it.
This piece is the organizational corollary. The ceremony was built to manage a workforce that could not self-coordinate, routing decisions through human nodes because decisions could not travel any other way. As the conversion work automates, that routing problem changes shape. Memory moves into specification. Serialization contracts. What remains is the judgment that specification cannot encode: at the edges, at the boundaries, in the cases the architecture did not anticipate.
The workshop became a factory. The factory needed foremen, and the foremen needed ceremony. The ceremony quietly accumulated until it became the dominant texture of large engineering organizations, the thing you navigated rather than the thing you built.
AI is dismantling the factory floor. The workshops are opening again, not as a return to artisanal informality, but on top of explicit specification, encoded governance, and machine-scale execution. And the organization that survives the transition is the one that understands what the ceremony was actually compensating for, and builds something more deliberate in its place.
