Assemble the Community · The Agentic Awakening

Skip to content

Contents

Download

Exit full screen

The Agentic Awakening

IBuild the Churches

IIConvert the People

IIIAssemble the CommunityThe 50% Ceiling<br>The PM-to-Engineer Ratio Inverts<br>The Squad Is the Unit That Ships<br>Four Chiefs at the Helm<br>The Engineering Org Tree Gets Shorter and Wider<br>When Building Leaves Engineering<br>Where You Stand, Where We Go from Here

Sources

Part III

Assemble the<br>Community

Part I built the infrastructure. Part II converted the people. Yet a recurring pattern ran through the<br>study: organizations that did both (with individuals accelerating 10&times;+ on their own work)<br>still couldn’t push organization-level productivity past roughly 50%.

Without the org changes that come next, it’s like upgrading a sedan to a sports car and then stopping at<br>every stoplight: the speed is real, the organization just won’t let you use it.

Capturing the rest takes a new shape: requirements become the bottleneck, so the PM-to-engineer ratio<br>breaks to an extreme; product-minded engineers organize into smaller autonomous squads; four<br>experienced chiefs hold company-wide architecture, product, design, and security direction across<br>them; and the org tree gets shorter and wider. The same building capacity then spreads beyond<br>engineering into the wider organization. If your structure hasn’t changed, you haven’t really<br>absorbed the first two parts.

&ldquo;Adapt or die.&rdquo;<br>– Moneyball (2011)

Part III &middot; Organizational Throughput<br>Local Speed, Organizational Drag

The 50% Ceiling

Parts I and II make individual engineers dramatically faster. They do not, by themselves, make<br>the organization move at the same rate. That gap between local velocity and organizational<br>throughput is the central finding of Part III.

The pattern first surfaced at one of the study’s most advanced companies: agentic for more than<br>a year, with 85–90% of production code generated by agents and a strong infrastructure layer.<br>If any company should have translated local velocity directly into company output, it was this<br>one. It could not.

“We accelerated code generation by close to 10×. But the actual end-to-end productivity gain<br>from intent to deployed value) never crossed 50%. Most of the time it sat closer to 25–30%.”<br>– Head of engineering, late-stage company, on the moment the bottleneck shifted

The Ferrari at every stoplight

The analogy lands instantly with every CTO who has hit this wall. Replace an old, slow sedan<br>with a sports car: the acceleration is sharper, the top speed is higher, and every measure of the<br>vehicle improves. Then drive it along the same city route, with a red light every 200 meters.<br>You arrive only slightly sooner. The same bottleneck appears in outside data. Across more than<br>400 companies, DX found median pull-request throughput rising 7.76% as AI adoption increased<br>65%, meaning much of the local acceleration was absorbed before it reached wider organizational<br>output.

A Ferrari stopped by organizational bottlenecks<br>A fast red sports car approaches five red lights representing product reviews, product manager handoffs, review queues, long planning cycles, and legacy ownership lines.

Productreviews

PMhandoffs

Reviewqueues

Month-longplanning

Legacyownership

The cars got faster. Now we need to redesign the roads.

This is what happens when an organization installs AI-native engineering inside a pre-AI org shape.<br>Some controls still protect quality and safety; others are habits inherited from the old speed.<br>The answer is not to run every red light. It is to redesign the route: remove unnecessary stops,<br>automate controls that can operate at machine speed, and create high-throughput lanes for agentic<br>work. Product reviews, PM handoffs, review queues, month-long planning, human-paced status meetings,<br>and legacy ownership boundaries all have to be reconsidered.

The lights were gone. He still stopped.

I spoke with an engineer who had been given a new project and an explicit mandate to work in AI<br>mode. The organization had cleared away the normal approval gates and told him to move fast. Yet<br>at each meaningful decision (architecture, scope, product tradeoffs), he still went looking for<br>permission. The stoplights had been switched off; he kept stopping at the junctions.

Decades of product and software management taught the same sequence: define, align, review,<br>approve, and only then build. That discipline made sense when code was expensive and rework was<br>slow. It also trained engineers to seek permission before deciding, protect work once written,<br>and treat discarded code as waste.

Agentic work asks for different instincts: make more reversible decisions, test them in software,<br>and throw work away without ceremony when the evidence changes. Removing the gates is only half<br>the transformation; people must learn to move without waiting for them.

When two AI-pilled engineers outpace your fifty.

The danger isn’t only your own ceiling....