Why AI Adoption Fails for Leadership Reasons

Google's DORA research program has been measuring software delivery performance for over a decade. When they turned that instrument on AI adoption, they found something uncomfortable: higher AI adoption is associated with increases in software delivery throughput and in instability, at the same time. Teams get faster and less stable together.

Their explanation is the sentence every engineering leader should sit with. In DORA's own words, AI's primary role in software development is that of an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.

That reframes the whole problem. The interesting question was never "is AI good for engineering teams." It's "what does AI amplify about my team," and that answer is different for every organization, which is exactly why two companies buying identical licenses get opposite outcomes.

Amplification, not transformation

Think about what an amplifier does. It doesn't change the signal. It makes the existing signal louder.

If your code review process is thorough, AI-generated code gets caught and corrected faster than a human could have written it in the first place. If your review process is a rubber stamp, AI-generated code ships broken at a rate no human team could previously achieve. The tool is identical. The outcome is opposite, and the variable was never the tool.

The same pattern repeats everywhere:

• Clear priorities get executed faster. Unclear priorities produce more wasted work, faster.
• Good delegation scales, because people who know how to specify outcomes can specify them to an agent too. Bad delegation becomes bad delegation at machine speed.
• Teams that surface problems find AI's failure modes early. Teams that hide problems accumulate hidden AI failures until something breaks publicly.

This is why DORA found AI improving outcomes at nearly every individual level while degrading system stability. Individual engineers genuinely do get more capable. The system around them, the review capacity, the deployment safety, the shared understanding of what's being built, does not automatically scale to absorb it.

The bottleneck moves, it doesn't disappear

AI accelerates code generation. It does not accelerate code review, deployment safety, incident response, or the human agreement about what should be built. So the constraint moves downstream and gets tighter.

A team that could produce ten pull requests a week and review ten pull requests a week was balanced. Give that team tooling that lets it produce thirty and the review capacity is now the binding constraint. Nobody planned for that. Nobody staffed for it. What usually happens instead is that review quality quietly degrades to keep pace, because the alternative is visibly blocking your colleagues.

The failure is invisible for a while. Throughput looks great. Stability erodes underneath it, which is precisely the pattern in the data.

What this means for how you lead

The instinct when adoption goes badly is to buy better tooling or write a stricter policy. Both are usually the wrong lever, because the tool was never the variable.

The useful questions are about your system, not your software:

1. Where is our real bottleneck now? If generation got three times faster and nothing downstream changed, name what's about to break. It's usually review or verification.
2. What did we stop doing to keep up? Teams under pressure quietly drop the least visible practice first. Find out what got dropped before you find out the expensive way.
3. What does this amplify about us specifically? Every team has a known weakness. Whatever yours is, assume AI is making it faster too.
4. Can we still tell whether it's working? If your measurement was already weak, AI makes it weaker, which is the subject of the next session.

Why this is a leadership problem, not a technical one

It's worth being blunt about this, because a lot of money is currently being spent on the assumption that AI adoption is a tooling decision.

Every one of the amplified failures above existed before the tools arrived. Weak review standards, unclear priorities, poor delegation, teams that don't surface bad news. Those are the exact problems the rest of this curriculum is about. AI didn't create any of them. It removed the slack that was hiding them.

That's genuinely good news, if you're willing to hear it that way. It means the work is work you already know how to do. It also means the organizations that will struggle most are the ones treating this as a procurement exercise, because no license fixes a review culture.