AI News

The Organisational Coordination Layer Is Being Dismantled. AI Made Builder Culture Scalable.

Falk Brauer

— 12 min read
The Organisational Coordination Layer Is Being Dismantled. AI Made Builder Culture Scalable.

In this article:

A developer named Nathan Cavaglione spent 14 days building a functional replica of approximately 95% of Slack's core product using LLM agents. Slack was built by thousands of engineers over more than a decade.

Nathan's prototype is not production software. It does not have SOC 2 certification, enterprise SSO, data residency controls, or the compliance infrastructure Slack's paying customers require. Senior practitioners will spot this immediately, and they are right to.

None of that changes the point.

This is not only a product company problem. Every enterprise implementation project: the SAP rollout, the Salesforce migration, the custom integration. All of them run the same coordination layer around the same expensive execution work.

The point is not what the AI did. The point is what Nathan did.

One head, no handoffs

He did not just write code fast.

He decided what to build and in what order. He broke the product into work that agent tooling could execute. He made the tradeoff calls (what to cut, what to approximate, what to defer) without a product review or a committee sign-off. He shipped without a sprint ceremony, a retrospective, or a stakeholder alignment meeting.

Product. Architecture. Project decomposition. Execution. All of it, in the same head, without a coordination layer between any of it.

That is the full picture. And it is the picture that makes the large codebase flip from asset to weight: when replication time compresses from years to weeks, the moat narrows with it.

Built for expensive execution

Enterprise software development spent roughly twenty years building infrastructure to coordinate large groups of people doing expensive execution work.

Product managers to translate business needs into requirements. Project managers to track progress and manage dependencies. Line managers to allocate people and run performance cycles. Architecture review boards to align technical decisions. Sprint ceremonies to synchronise work across teams. Stakeholder alignment meetings to make sure the right people knew what was being built.

None of this was bureaucracy for its own sake. It existed because execution was genuinely hard, handoffs were unavoidable, and the cost of misalignment was enormous.

A team building the wrong thing for three months represented a write-off no coordination layer could recover. The coordination layer was the right solution to that problem.

The problem has changed.

When execution gets cheap

When one person with good tooling can do in two weeks what previously required ten people over months, the coordination layer does not automatically shrink. It is full of people who are good at it, whose jobs depend on it existing, and who have no organisational incentive to question whether it still serves the output.

Look at your own org. Count the people whose primary function is coordinating work rather than doing it. Count the meetings whose purpose is synchronising decisions that used to require synchronisation because execution was slow and parallel workstreams needed alignment.

Now ask: if execution compresses by 10x, how much of that coordination is still load-bearing?

The answer for most engineering organisations is: less than half. But the layer stays the same size because no one is measuring it against the problem it was built to solve.

In large organisations, the problem is more acute. A 5,000-person engineering org does not just have more coordination roles — it has an ecosystem built around them: implementation partners, systems integrators, and consulting practices whose value proposition is managing the complexity that large software orgs generate. SAP CEO Christian Klein, in April 2026, compared the AI transition to the cloud migration in scale: "Transitioning to the cloud required a significant overhaul of products, sales approaches, and how we operated internally." The same overhaul is now due for the coordination layer. The difference is that in large organisations, the layer is not just an internal headcount question. It is embedded in contracts, partner ecosystems, and revenue models that predate the current tooling by a decade.

Role compression is not enough

In early 2026, Satya Nadella described what Microsoft had done at LinkedIn: combined four traditional roles, Product Manager, Designer, Frontend Engineer, and Backend Engineer, collapsed into one. He called them full-stack builders. His framing: not layoffs, "role compression driven by better software."

That is a structural acknowledgement that the coordination overhead was real and the problem had changed. It is a meaningful step.

Shopify made a parallel move. In April 2025, CEO Tobi Lütke published an internal memo: "Before asking for more headcount and resources, teams must demonstrate why they cannot get what they want done using AI." Shopify had already reorganised in 2024 to fix what it called an "unhealthy" ratio of managers to crafters (its term for individual contributors who build things).

Both moves point at the same problem. Neither goes to the root of it.

The Nadella frame asks: how many roles can one person absorb? The Lütke frame asks: can AI do this before we hire? The right question is neither. It is: what does leadership actually look like when building is cheap, and is the coordination layer still serving the output?

Combining four roles into one full-stack builder and then putting that person inside the same sprint ceremonies, the same roadmap planning cycles, and the same stakeholder alignment structures is role compression without coordination compression. The work gets smaller. The overhead does not.

The efficiency misread

The response most large organisations will reach for is straightforward: use AI to reduce engineering headcount, lower the cost base, and report the productivity gains to the board. The coordination layer stays. Fewer engineers sit beneath it. The deck says AI-first. The org still runs on coordination logic.

This is the wrong harvest from the right crop.

The productivity gain is real. But taking it as a cost-saving opportunity misses what is actually on offer. AI does not just make existing work cheaper. It makes different work possible, and the composition of the team changes with it.

The agent manager is not a project manager with a new title. They design, configure, monitor, and improve a layer of AI systems doing work that previously required a team of specialists. The marketing engineer is not two roles compressed into one. They build the tooling, write the logic, and ship the output that used to require a handoff chain between four people. The implementation architect at an enterprise software firm is no longer the person who manages the delivery plan. They are the person who redesigns the implementation pattern entirely around what AI can now execute in weeks rather than months.

These are not compressed versions of existing roles. They are genuinely new ones. And they require a different kind of leader above them: someone who can recognise what those roles need, protect them from the coordination overhead that will try to absorb them, and build the conditions for the new model to compound.

The organisations that take the efficiency reading will have a leaner version of the same structure. The savings are real. The transformation is not. Three years from now they will have spent the productivity dividend on margin improvement and will be facing the same structural disruption from outside that they declined to run from inside.

The organisations that take the transformation reading will look structurally different: smaller coordination layer, new role types in the team, builder-leaders setting the direction. The work that previously required a steering committee happens in days. That is not a cost improvement. It is a different organisation.

One in a thousand

The person who can do what Nathan did is not a full-stack builder in the role-compression sense. They are something rarer: a systems thinker who can hold the product logic, the architectural decisions, the agent orchestration, and the execution quality in the same frame simultaneously.

Most organisations have one of these people. Some have none. They are not always the most senior person in the room. They are not always the person with the most impressive CV.

They are often recognised only in retrospect, when something ships unusually fast and someone asks how.

The question of what you do with that person is the most important talent question your engineering org has right now.

Where the org routes this person

The builder trap. The person ships fast. Output is high and visible. The organisation points them at the next hard problem and the one after that.

The knowledge stays concentrated in one person. The rest of the team does not compound. You have created a key-person dependency on your most capable person, and when they leave, the capability leaves with them.

The enabler trap. The person builds the scaffolding: agent configurations, architectural patterns, decision frameworks, tooling that raises the ceiling for the broader team. The leverage is real but invisible. It does not show up in velocity metrics or sprint reviews.

In most organisations, it does not have a career path. The person does the work, gets less recognition than the builders, and eventually stops.

The coordination path. The person gets promoted. They are good, visibly so, and the organisation does what organisations do with good people: gives them more responsibility. A team to manage. A product area to own. A seat in the quarterly planning process.

These roles exist for good reasons. But they were designed for an environment where execution was expensive and coordination was the scarce resource. Each step up the ladder moves them further from the work that now matters most, into roles that have not yet been redesigned for the new environment.

Most organisations default to this path because it has a title, a salary band, and a clear career path. The alternative does not. Yet.

When the layer becomes optional

The coordination layer does not get dismantled by a reorg or a strategy deck. It collapses when a true technical AI leader shows up and simply does not need it.

They make the product decision. They break down the work. They build it. The scaffolding that existed to coordinate ten people doing that job in sequence becomes invisible, not because it was removed, but because it is no longer load-bearing.

That person is the threat that does not appear on any risk register. Not a competitor. Not a technology. Someone inside or outside your organisation who renders the coordination structure optional by demonstrating that the output does not require it.

The organisation that routes that person into the coordination layer loses them to the very structure they were capable of replacing.

What scale actually requires

The conventional argument for keeping the coordination layer in large organisations is intuitive: more complexity requires more coordination. A 5,000-person engineering org cannot run like a 15-person startup. Compliance requirements — data residency, audit trails, security certifications — justify a substantial oversight function.

This is true. But it conflates necessary governance with optional coordination overhead. The compliance layer is real and load-bearing. Most of the coordination layer is not.

Stanford labour economist Edward Lazear studied 5,000 GSB alumni and found that the further up an organisation you go, the more generalist the skills required. Respondents who had held five or more roles had an 18% chance of reaching C-level; those who had held two or fewer had a 2% chance. "The higher you get in an organisation, the more likely you are to encounter problems from a variety of different areas," Lazear concluded. "A good CEO is someone who's very good, possibly not excellent, but very good, at almost everything."

David Epstein's 2019 book Range documented the same pattern across fields. In complex, unpredictable environments, generalists consistently outperform specialists. As AI handles an increasing share of specialist execution, the premium on breadth at the top only grows.

The most successful large technology companies are led by people who actively compressed the coordination layer rather than adding to it. Nvidia employs more than 30,000 people. Jensen Huang has 60 direct reports and runs no one-on-one meetings. He has described himself as "allergic to hierarchy and corporate silos." The flat structure is not a quirk — it is how a builder-as-leader operates at scale: direct access to the organisation, minimal buffering, information flowing without the management phone tree.

Stripe operates on the same principle: small teams, high trust, talent density over organisational sprawl. Patrick Collison has described the goal as curating environments where small groups solve hard problems without committees.

The contrast with the incumbents is not subtle. The companies now facing structural pressure from AI — whose switching costs are eroding, whose barriers to entry are collapsing — are largely those where coordination-type leaders have been in place for years. SAP CEO Christian Klein, in April 2026, compared the AI transition to the cloud migration in scale and pain. The cloud transition took a decade. The organisations that navigated it fastest were not the ones that coordinated their way through it.

The builder-as-leader has a structural advantage at scale: they can see across the whole system, make calls without the committee process, and demonstrate directly what is now possible. That last part — demonstrating, not just describing — is what the coordination-type leader cannot do. In an environment where the tools are changing faster than the org chart, demonstration is what makes the new economics legible to everyone else.

The builder as leader

The title is less important than the mentality.

The leader this environment rewards is not primarily a coordinator. They build. They understand how the tools work because they use them. They can make the product call and then execute on it. And crucially, they do not hoard that capability. They build the conditions for everyone around them to compound.

That is the shift. The old model rewarded leaders who could manage complexity: align stakeholders, protect the team from distractions, translate between business and engineering. Those skills still matter. But they are no longer sufficient.

The new model rewards leaders who can do the work and raise the ceiling simultaneously. Who build the scaffolding (agent configurations, architectural patterns, decision frameworks) that make the whole team faster. Who measure their impact not by what they personally shipped but by how much faster the organisation ships after they showed up.

This applies across functions. A product leader who understands agent orchestration well enough to decompose work into executable pieces. An engineering leader who builds the tooling others use. A delivery leader who redesigns the process around the new economics instead of defending the old one.

Jensen Huang named the shift at the World Government Summit: "Everybody in the world is now a programmer. This is the miracle of artificial intelligence." At London Tech Week he was more specific: "The new programming language is called human."

That is a redefinition of who can build. The threshold has moved. Building is no longer a credential conferred by the ability to write code. It is a disposition: the willingness to understand the tools well enough to direct them, and the judgment to know what is worth building.

The uncomfortable test: if needed, could the leaders in your organisation rebuild a core piece of your product in two weeks with current AI tooling? Not delegate it. Not architect it for someone else to build. Build it.

Sources

Read more