The tools are ready. Your team is not.

This is the third and final post in a series, and it builds on the two before it. If you are landing here first, it is worth starting at the beginning: You were paid to write code. That’s the problem now. is about why letting go of the code is an identity problem before it is a technical one, and Stop reviewing code. Start defining “done”. is about the guardrails that make letting go safe rather than reckless. This one is about what happens when you try to do that with a whole team.

One thing before I start. Some of what follows is not a report on something I have finished. It is where I think this is heading, and what I am trying to get right with my own team. I am in the middle of it, not on the other side.

The way I picture it, there is a river of innovation running right now. You can stand against it, you can let it carry you wherever it wants, or you can swim with it and steer a little. I am trying to do the third one. I do not always get it right.

So read this as one person’s view, not a playbook. Every team and every org is different, and the parts that matter most are the parts I am least sure about.

Both of the first two posts were things you can do alone. You can change your own mind. You can put guardrails on your own repo. This post is about the part you cannot do alone, and it is the part I have found hardest.

I ended the last post on a line I keep coming back to: the tools are usually ready before the team is. I meant it as a warning. It turned out to be the biggest part of the job.

The bottleneck moved

Almost every hard problem I expected in this work was a building problem. Almost every hard problem I actually had was a people problem.

Capability was rarely the thing that slipped. Something would be ready and working, clearly faster than the old way, and then sit there. Meanwhile the estimates in planning still assumed a person typing every line, because that is how the team still worked, and because the whole process around them was built for that.

This part is easy to underestimate. You cannot get the value out of a faster builder if CI/CD is slow, if review queues sit for days, or if releases wait for a window. The old habits then kick in without anyone deciding anything. You sit in planning and hear the same timelines you heard two years ago, as if none of the new tools existed.

That is worth sitting with, because we have spent years pushing on the wrong limit. Faster builds, better tooling, smaller PRs, tighter feedback loops - all of it aimed at how quickly an engineer can write and ship code. That limit is going away. And when the ability stops being the scarce thing, the scarce thing becomes whether people want to work differently. That is not something you can build. It is something you have to lead.

In the previous post I said you already trust thousands of lines of code you never read, in every framework and library you use. It is worth asking how that trust got there. Nobody sat down and decided to trust the ecosystem. It built up: standards, conventions, package registries, scanning, and a lot of public failures that people survived and then defended against. It took the industry decades.

You do not have decades. Your teams need to get to that kind of settled trust in months.

So adoption is not a training plan, and it is not change management. It is trust, and trust is built on evidence. The job is to produce evidence faster than doubt.

Which is why I think this deserves your attention even if you are still unsure about the tools themselves. Empowering people through this change, supporting them through it, and at times mandating it, is one of the better things you can do for your teams, for the individuals in them, and for yourself. Not because agents are the point, but because it gets everyone used to moving. More change is coming, and sooner than any of us expect. Myself included.

What I had to let go of

The two posts before this one asked engineers to give up control of the code. Here is what I had to give up.

The idea that a good enough capability sells itself. It does not. Not to busy people with a roadmap or an on-call rotation. I have had genuinely ready things sit unused while teams estimated multi-week jobs that the ready thing did in an afternoon. That is not the engineers failing. That is me failing to make the case where the work actually gets planned.

Control over the order. I had a tidy sequence in my head: this team, then that one, in whatever order made sense on my plan. What actually moved things was letting teams pull it when they had a real reason. A migration they were dreading. A test suite nobody wanted to write. A deadline that made the old way look worse than the new one.

And the biggest factor of all: find the champions. There are always a few people already curious, already trying things on their own. Back them. Give them room, give them cover, and give them real time to do it properly rather than squeezing it around delivery. They will carry this into their teams further than I ever could from where I sit, because it lands differently coming from a peer.

I want to be careful here, because the easy version of this point is wrong. Mandates do work, up to a point. Tell a team this is how we work now, and most of them get there. They build the muscle. The new way becomes the normal way.

What I noticed is what happens next. Teams reach the expectation, and then they stop. It is not a slide back to the old ways, they hold the new bar. The growth just slows, and I think there is a lot more available above that bar than most teams end up taking. A mandate seems to raise the floor and leave the ceiling where it was. There are exceptions, people who keep pushing on their own. But most of us pause somewhere.

That is the part I have not solved. Pull is slower at the start and looks, on any weekly update, like nothing is happening. A mandate gives you a number that moves. I am not convinced it gives you the thing above the number.

Hand over work in steps

Handing over work is not a switch, and the failures I have seen come from treating it like one, in either direction.

One direction is easy to spot. Nothing gets handed over, because nothing ever feels safe enough.

The other is quieter and worse. You take the brakes off, a lot of code gets produced, and the trouble does not arrive as one loud failure. It arrives as bugs going up across the board. Or it lands on QA, because we are used to having someone whose job is to catch things, and suddenly far more is arriving than they can get through. The pipe clogs. The team that was supposed to get faster is now slower than it was. And I can easily picture the loud version too: no real controls on a new process, a huge amount of work piled on top of it, and when it breaks the mess sets you back months.

Take the boring route. Start where the blast radius is small and where “done” is easy to define.

Build the process in small pieces. Each piece simple enough to understand on its own, each one useful on its own, and each one so easy to use that skipping it costs an engineer more than using it. That last part matters more than the plan does. People adopt what is convenient, not what is announced.

Make it very easy to do things like this. Keep dependencies up to date. Run a security review over a change. Fix a small bug, with a reproducing test that proves it is fixed. Add an endpoint against a contract that already exists. Backfill tests on the module everyone avoids. Chase down a flaky test. Add the logging you always wish you had at three in the morning. Replace a deprecated library call across a dozen repos. Write the repo docs nobody has ever had time to write.

These are good first jobs not because they are small, but because they are verifiable. Success is not a matter of opinion, and a mistake is cheap and obvious. They are also mostly work nobody enjoys, which helps. The quickest way to get someone to try a new way of working is to take something off their plate that they were dreading.

Keep the other end human-driven for now. Architectural change, anything crossing system boundaries, anything near money or customer data. Not forever. For now.

Then move the line on purpose, and say so out loud. Not “we trust agents more this quarter”, but “we are moving this kind of work over, because it has worked the last several dozen times, and here is how we know.” Trust given against evidence survives the first failure. Trust given by decree does not.

And be willing to move the line back. A leader who will not undo a decision like that is not managing risk, just hoping.

Ship rough, then let real use decide

I have watched this one play out more than once. Past a certain point, more design is avoidance. It is more comfortable to keep polishing a plan than to find out the plan was wrong. I catch myself doing it with strategy documents. Engineers do it with a branch they keep tidying instead of putting it up for review. Same instinct, different artifact.

The better move has been to put things in people’s hands while they are still rough. Call it an alpha, mean it, and let real use decide what happens next. The first runs are embarrassing. They are also the only information that counts, because the step people actually get stuck on has never once been the step I predicted.

One caveat, and it is the reason this is not reckless. Shipping rough works because the guardrails from the previous post are already there. Rough with strong verification is an experiment. Rough without it is an incident.

Measure outcomes, not activity

The easiest way to fool yourself here is to measure adoption. Seats, prompts, sessions, percentage of code written by AI. Every one of those goes up whether or not anything got better, and some go up fastest when things are going worst.

I made the same point about test counts in the last post. The moment a number becomes the target, it stops telling you anything. Publish an org-wide AI usage figure and people will start managing the figure.

Measure whether work is reaching customers faster and holding up once it is there. Delivery, stability, rework, how much time engineers spend on toil instead of on problems. And if agents are doing real work, measure that work on its own terms rather than folding it into the humans’ numbers, because it is a different kind of work with different ways of going wrong.

These numbers are boring, harder to move, and they lag. Adoption numbers give you something to report every week. Outcome numbers move in quarters. Holding your nerve through that gap is a lot of the job.

What does not change

After a whole series about letting go, the thing worth being loudest about is what does not move.

A person defines what done means. A person verifies the result. A person owns the merge. That does not get handed over - not at Level 3, not at Level 4, not when the models get better. It is the fixed point the whole thing balances on.

Letting go of the keyboard is not letting go of ownership. It is closer to the opposite. The only reason it is safe to stop reading every line is that someone is still answerable for the outcome, with the evidence to back it up.

That is the series in one sentence. The shift is not from doing to not doing. It is from proving correctness by writing the code to proving it by checking the result. The standard did not drop. The evidence changed.

The tools are ready. Getting a team there is the real work, and I am still learning how to do it.

---

That is the last of three. Thanks to everyone who pushed back along the way, a few of these arguments are sharper because of it. I am in the middle of this rather than out the other side, so I would like to hear what is working where you are, and what is quietly not.