Nobody adopts a new way of working on the same Tuesday.

That’s the whole problem, and it’s the one nobody warns you about. The pitch for going agentic is a clean before-and-after: the team learns to conduct, throughput multiplies, everyone’s happy. What actually happens is messier and slower and — for a stretch you’ll wish were shorter — worse. Because a team is not a single object that moves up the stack in one motion. It’s twenty people, and on any given week some of them have learned to conduct a room full of agents and some of them are still, heads down, playing the instrument by hand. That gap is not a rounding error. It’s a fault line, and the org tears along it.

I called this a rope team once — in The Team Dimension — and the image holds, so let me use it again. A rope team climbs a mountain roped together, on purpose, so that no one falls alone. The catch is that a rope team only moves as fast as its slowest climber lets it, and if one person sprints ahead the rope doesn’t make everyone faster. It just goes taut. That’s what an uneven adoption feels like from the inside: not a team gliding upward, but a rope pulled tight across people climbing at wildly different speeds, and the tension has to go somewhere.

The split runs through the team first

Start inside a single engineering team, because that’s where you feel it first and it’s the easy version.

Half the team has crossed over. They’ve stopped typing most of their code and started directing it — writing intent, spinning up parallel work, reviewing output instead of producing it. Call them the conductors. The other half hasn’t, and here’s the part that matters: it is not because they’re worse engineers. Some of your sharpest people are the most reluctant, because they’re the ones with the most hard-won skill to feel like they’re setting down. Call them the soloists. They’re still excellent. They’re just excellent at the thing the job is quietly ceasing to be about.

Now put them on the same standup, measured by the same board. The conductor closes a week’s worth of stories in two days and reaches for the next thing. The soloist is doing careful, real work at the pace careful real work has always taken. On the burndown chart, one of them looks like a machine and the other looks like they’re dragging. That reading is a lie — the soloist is often producing the more durable thing — but it’s the reading the chart hands your leadership, and charts are persuasive. So the fast half starts wondering why they’re roped to the slow half. The slow half starts feeling the thing I named in The New Caste System: the quiet dread that the ground has shifted under a skill they spent a decade earning, and that the shift is being scored against them in real time. Resentment one direction, fear the other. That’s not a personality clash. That’s what a fault line feels like when you’re standing on it.

You can manage this. It’s uncomfortable and it’s human and it resolves — people cross over, the rope slackens, the team re-forms at the higher altitude. It’s a coaching problem, and I’ll spend the next post on how to lead it. I’m walking you through it here because it’s the survivable version of the disease. The lethal version doesn’t run through your team. It runs between two of them.

The seam that actually kills you: dev races ahead of intent

Here’s the one that doesn’t self-heal.

Engineering goes agentic. Genuinely, all the way — the team learns to conduct, and their execution capacity goes vertical. What used to be a two-week build is a two-day one. The bottleneck that defined software for thirty years — it takes time to write the code — just quietly stopped being the bottleneck. Great. Except the org didn’t move as a unit. Product management, the people whose job is to decide what gets built, are still working the way they worked in 2020: one carefully-groomed spec at a time, on a cadence tuned to how long it used to take engineering to consume one.

So now you have a team of engineers and their agents that can execute a well-specified idea in an afternoon — sitting idle, waiting for someone to tell them which idea is worth the afternoon. The constraint didn’t disappear. It moved. It moved to whoever writes the intent, exactly as I argued in Intelligence Moves Up the Stack: make one layer cheap and the whole system’s scarcity relocates to the layer above it. Execution got cheap. Intent didn’t. And the layer that produces intent is now running at a fraction of the speed of the layer that consumes it.

That gap has a cost, and the cost has a name.

Intent starvation is not a productivity dip. It’s the specific, structural failure of a two-speed org, and it feels like abundance right up until it doesn’t. The engineers aren’t blocked on a hard technical problem — those they can chew through faster than ever. They’re blocked on a decision that lives in another function. And an idle team of expensive conductors and their meters-running agents is a far more costly thing to have sitting around than an idle team used to be, because you built all that leverage precisely so it would never sit around.

Watch what people do when they’re starved for intent, because this is the tell. They don’t wait quietly. They build something — the nearest plausible thing, the feature they can imagine well enough to spec themselves, the refactor nobody asked for. Motion is more comfortable than idleness, so a starved team manufactures its own intent, badly, at machine speed. Now you’re shipping unvalidated guesses faster than product can evaluate whether any of them should exist. This is the failure mode I warned about in Anatomy of a Spec, run in reverse and at scale: there, a thin spec let an agent confidently build the wrong thing. Here, the absence of a spec lets a whole team do it — and each one of them is holding a tool that turns a vague guess into shipped code before lunch. The burndown chart has never looked busier. Almost none of it is pointed anywhere.

What the two-speed org actually costs

Line up what you’ve got. One function that can execute nearly anything, nearly instantly. One function still deciding what to execute at its old, human, one-at-a-time pace. A board that measures both as if the constraint were still execution — so it rewards the starved team for manufacturing motion and quietly penalizes the product manager for being the “slow” one, when the product manager is now the single most leverage-bearing person in the building and the least resourced to act like it.

The instinct is to fix this by hiring more engineers. It’s the exact wrong move — you’d be pouring more capacity into the side of the dam that’s already overflowing. The org isn’t short on execution. It’s short on intent, and no amount of additional conducting talent produces a single clear decision about what’s worth building. If anything it makes the starvation worse, because now you’ve got more idle leverage per unit of decision.

And here’s why this seam is the one that kills you while the within-team split merely hurts: the within-team gap closes on its own as people learn. Nobody has to decide to fix it; the slow climbers become fast climbers and the rope slackens. The cross-function gap does the opposite. Left alone, it widens — every week engineering gets faster at consuming intent while product stays exactly as fast at producing it, so the ratio between supply and demand gets worse, not better, precisely because your agentic investment is paying off. The thing you’re most proud of is the thing pulling the org apart. That’s the cruelty of it. Success on one axis, unmanaged, becomes failure across the whole.

This is the same lesson from the hiring post — Acquiring Talent in the Age of AI — pushed up to the org level. There, the argument was that the scarce skill in a person is judgment, not output. At the scale of a company it’s the same rotation: the scarce function is the one that produces intent, not the one that produces code. If your org chart, your headcount plan, and your metrics all still assume execution is the bottleneck, you’ve drawn a map of a company that no longer exists — and you’ll keep reinforcing the overflowing side of the dam while the starved side idles, and call it investment.

None of this is an argument against going agentic. It’s an argument against going agentic in one department and calling it a transformation. You didn’t transform the org. You gave one function a rocket and left the other one on foot, roped them together, and told them to summit. The rope’s already taut. You can feel it.

So the question I’d sit with before the next planning cycle is this one: in your org, who writes the intent — and are they resourced to feed a team that can now execute faster than they can decide? If you’re not sure, the honest move is to go find out before you hire another engineer. Because if the constraint has already moved and your plan hasn’t, you’re not scaling a transformation. You’re widening a fault line and funding the wrong side of it.

Which is the whole reason the next post exists. Diagnosing the tear is the easy half — you can feel a rope go taut. Leading a real organization through the transition, so both halves arrive at the higher altitude together instead of one dragging the other, is the actual job. That’s next.

---

This is Part 5 of Leadership in the Agentic Era. Next: 6 · Leading the Change — empathy, foundations, and a shared language for taking the whole org up the stack together.