There’s usually one engineer who gets there first.

They start by experimenting quietly, then more openly. Over time, the way they work begins to change. They spend less time writing code from scratch and more time directing agents, reviewing outputs, and moving at a higher level of abstraction. The volume of work they produce changes. So does the shape of it.

And then the process catches up with them.

The review queue starts to build. Not because the work is poor, but because the volume and pace are beyond what the rest of the process was designed to handle. That engineer is now working in a fundamentally different way to the people reviewing their output. Neither side can quite explain why things feel slower and heavier than they should.

That’s usually when I start hearing about it in coaching conversations.

Code review is often where it becomes visible first, but the underlying issue is wider than that. When part of a team has moved to an agentic way of working and the rest hasn’t, they’re not just using different tools. They’re operating with different assumptions about how work gets done, how quickly decisions should move, and what review even means at that pace.

The friction that follows is predictable. Assumptions get missed. Coordination gets heavier. People start working at cross-purposes without fully understanding why.

Most CTOs diagnose this as an AI adoption problem. The team just needs to move faster. But the engineers who haven’t made the transition aren’t lagging behind. They’re working exactly as they were hired to work. The problem is that the context around them has changed faster than the structure has.

A lot of engineering organisations are still built on a sequence that used to make sense. Product defines. Design shapes. Frontend picks it up. Backend takes its part. Infrastructure supports the release. Work moves through the team in stages, with handoffs acting as the mechanism for control and quality.

The engineer working agentically doesn’t move through that same sequence. They move across it. They can go from customer problem to prototype to implementation to refinement in a much tighter loop, often with agents supporting different parts of that flow.

That doesn’t just change speed. It changes how the work wants to be organised.

The issue isn’t simply that one engineer is moving faster than the others. It’s that the organisation is still built for a relay race while part of the team is now running a very different event.

A team running two ways of working doesn’t run at the average of the two. It runs at the speed of the friction between them.

The first cost is visible in delivery. Reviews take longer. Decisions stall. The engineers who have made the transition feel slowed down by a process that no longer fits the work. The engineers who haven’t transitioned feel pressure they don’t fully understand, because expectations around pace and output have started to change without ever being clearly reset.

The second cost is managerial. The CTO can usually see both sides. One part of the team is operating in a new model. Another is still working in the old one. So the work becomes managing tension rather than resolving it.

What tends not to resolve on its own is the underlying question: are we actually committing to this way of working, or are we trying to preserve two models at once?

The CTOs I’m working with who have moved their teams through this fully, rather than partially, are finding something they didn’t expect on the other side.

The backlog clears. Not just the routine work, but the difficult, deferred, too-risky-to-touch items that had been sitting there for months. With a small team of agentic engineers working across the full stack, the throughput is high enough and the flexibility is broad enough that work finally starts moving again.

And then something more interesting happens.

Once the team is no longer drowning in process overhead, the conversation changes. The question stops being “what do we need to build?” and becomes “what would genuinely serve this customer right now?” The work becomes more responsive and more directly connected to what the product actually needs.

More than once, I’ve heard CTOs say the same thing when they reach this point:

“Work is fun again.”

That isn’t nostalgia. It’s what happens when capable people are solving real problems again instead of spending most of their time navigating the machinery around them.

The move to agentic engineering doesn’t just change how work gets done. It changes what kind of team can work well.

When each engineer is managing multiple agents, the total output goes up fast. So does the surface area of the work. The coordination challenge does not disappear just because the coding gets faster.

That’s why the teams that seem to be working best in this model are small by design. Not because they are constrained, but because the structure fits the work. The goal is no longer to scale the old team shape into a new environment. It is to build a team that matches how work is actually happening now.

Most organisations aren’t there yet. They’re somewhere in the middle: a few engineers working in the new way, most still working in the old one, and a process that fits neither.

That’s not really a transition.

It’s a decision that hasn’t been made yet.

The teams moving through this well didn’t wait for complete consensus before they acted. They noticed the engineer who had already found a better way of working, paid attention to what that revealed, and started rebuilding the team around the realities of the new model rather than the assumptions of the old one.

The mixed model feels temporary when you’re in it. In practice, it tends to persist until someone makes a clear call about which way the team is actually going to work.

👉🏼 Where in your team are two ways of working still running in parallel — and what decision are you postponing by calling it a transition? I’d love to hear your thoughts.

Talk soon,
Adam.

This week on The CTO Playbook, I’m joined by Loïc Houssier to explore what real engineering velocity looks like beyond speed theatre. From slow decision-making and misaligned incentives to over-focusing on code, he shares a pragmatic approach to moving faster using product thinking, aligned autonomy and sharper organisational design.

🎧 Tune in on your favourite podcast platform or listen on the podcast page.

Build the habits, systems, and focus to step beyond execution, and grow with influence, alignment, and real strategic impact.

The March cohort kicked off a couple of weeks ago. Join the waitlist to be the first to hear when the next cohort opens. Sign up for your waitlist-only discount.

If you’re ready to scale your leadership, influence, and impact, let’s talk about my premium 1:1 coaching for strategic, high-impact leadership. CTO Ascent works as a standalone engagement or alongside CTO Basecamp or CTO Elevate. Book your call with me here.