Adopting This Without Breaking the Team

Adopting This Without Breaking the Team is the sequencing chapter, and sequence is most of the intervention. Every change in this book is reasonable on its own and several of them are unacceptable if introduced first, because each one asks the team to give something up before it can see what it buys.

Key takeaways

• DORA's 2025 report found that a clear and communicated AI stance determines AI's impact on organisational performance, and that it measures clarity and awareness rather than the specific content of the stance.
• DORA names the two failure modes a stance prevents: developers acting too conservatively, using AI less than they could for fear of overstepping, and developers acting too permissively. Neither, DORA says, is optimal.
• Reversal comes before triage. Asking a team to stop reading some changes before undoing one is cheap is asking them to accept risk you have not paid for.
• DORA also found that in the absence of a user-centric focus, AI adoption can hurt team performance. A delivery programme with no user outcome attached is worse than no programme.
• Faros AI, which sells engineering-productivity analytics, recommends repurposing engineering capacity rather than reducing it, warning that the engineers being considered for cuts are often the ones absorbing the quality gap.

Read this last, and read it beside Chapter 13, whose apprenticeship pipeline this sequence has to protect. Chapter 1's three starter numbers are step two, and Chapter 8's revert path is step four for a reason that this chapter makes explicit.

The all-hands announces the new review policy. Risk-based triage, size limits, mandatory gates, effective next sprint.

Three senior engineers stop listening at the second slide. What they heard is that the organisation which caused the queue now has rules about how they work, and that the rules arrived without evidence and without anything being taken off their plate.

They are not being difficult. The change was introduced in an order that made resistance the rational response, and the order was chosen for the convenience of the person presenting.

Sequence is most of the intervention

The changes in this book fall into two groups, and the grouping decides the order. Some give something to the team immediately. Some ask something of it first.

Measurement, standing context, tests and the revert path all give. They reduce recurring annoyances, remove repeated review comments, and make a bad night shorter.

Triage, size limits and ownership all ask. They constrain how people work, and their benefit is indirect and arrives later.

The rule is simply to spend the first group before drawing on the second. A team that has already seen three things get better will extend credit for the fourth. A team that is asked first will correctly read it as cost with no return.

A clear and communicated stance, and its two failure modes

Before any process changes, publish where the organisation stands. DORA's State of AI-assisted Software Development 2025, published 24 September 2025 from 4,867 respondents and 78 interviews, puts a clear and communicated AI stance among its seven named AI capabilities, and reports that it determines AI's impact on organisational performance while moderating its impact on individual effectiveness, friction and throughput.

The finding has an unusual and liberating property. DORA is explicit that the capability measures the clarity and awareness of the stance rather than its specific content, so organisations can make their own determinations about what is appropriate given their industry, role and data infrastructure.

DORA also names what the absence produces, from its interviews. Developers acting too conservatively, using AI less than they could because they are afraid of overstepping the organisation's parameters of acceptable use. And developers acting too permissively, using AI in ways they should not. Neither of these cases is optimal, DORA writes.

So the stance is a short document, not a policy programme. What is encouraged, what requires a named approval, what is prohibited, and who to ask. One page, signed, dated, and revisited.

Step one: publish the stance. Step two: measure

Measurement comes before any change to how work flows, for a reason that is political as much as technical. You cannot argue for a constraint without evidence that something is broken, and an argument without evidence is heard as an opinion about people.

Three numbers, from Chapter 1, at team level only. Time from pull request opened to first substantive human comment, at the median and the ninetieth percentile. The share of merged changes that received no human review. And default-branch success rate with time to recover when it goes red.

Publish them where engineers can see them, and say plainly what they are for. They are diagnosing a queue. They are not evaluating anybody.

Hold them for a quarter before changing anything. That waiting period is uncomfortable and it is what makes every later step defensible, because you will be able to show the before.

Step three: fix authoring, because nobody will fight it

The authoring work from Chapters 2, 3 and 4 is the only part of this book that reduces work for everybody involved without asking anything in return.

Start with the standing context, because it is the cheapest and most visible win. Take the three review comments your seniors are tired of writing and turn them into rules and checks. The people who were writing those comments will notice within two weeks, and the people receiving them will notice sooner.

Then the test contract, then the specification discipline, in that order, because the test contract is enforceable and the specification discipline is a habit. Faros AI, which sells engineering-productivity analytics, argues that the fix is upstream and that the goal should be fewer mistakes arriving at review rather than more humans deployed to catch them. This step is where you agree with them in public.

The reason to lead with this is not just that it works. It is that it establishes the direction of travel as removing friction rather than adding process, which is the frame every later step inherits.

Step four: make reversal cheap, before you triage anything

This is the step most likely to be skipped and the one whose omission causes the fight.

Time your revert path, per Chapter 8, and fix whatever it reveals. Exempt reverts from the review queue with an incident record as the compensating control. Add a reduced pipeline path. Make flags routine for anything with a risk marker.

Then, and only then, propose triage. The proposal now reads completely differently: we are going to stop reading some low-risk changes, and here is the twenty-minute reversal path we built first. CircleCI's report of 18 February 2026, with median recovery to green at 72 minutes, is a useful external reference point for why this is not theoretical.

I have seen the reverse order attempted more than once. It reads as gambling with production, and the engineers are right.

Step five: triage and size limits, introduced together

These two belong in the same change, because each one softens the other. Triage without size limits sends large changes to humans and they stay slow. Size limits without triage make more pull requests for the same queue.

Introduce them with three things stated at the same time. The written risk predicate from Chapter 6, including who signed it. The size limits from Chapter 7, with the exclusions for generated and lock files so the limit is not noise. And the post-merge sampling rates, so nobody believes the automated paths are unwatched.

Give it a review date and mean it. A three-month checkpoint where the predicate can be tightened or loosened based on escapes found in the sample is what turns this from a rule into a control the team part-owns.

The named queue owner from Chapter 5 has to exist before this lands. Otherwise the policy has no one whose job it is to notice when it is wrong.

Step six: ownership, security and cost

The last three are administrative in feel and consequential in effect, and they go last because they are the hardest to justify without the earlier evidence.

Ownership, from Chapter 9, is the one to do next, and framing decides its reception. It is a guarantee that somebody can answer for a path at three in the morning, not an audit of who wrote what. Run it as an exercise where each owner writes the three runbook answers, because that exercise finds missing off switches.

Security, from Chapter 10, follows naturally once ownership exists, because the records it needs are mostly the records ownership produced. Move the four weakness-class checks to the point of authoring and record findings where work is scheduled.

Cost, from Chapter 12, comes last on purpose. Publishing the reviewer-hour and incident-cost lines before the earlier steps have moved them invites exactly the conclusion Faros AI warns against, which is cutting the people absorbing the quality gap.

The sequence, and the objection each step disarms

The table below is the whole chapter, and the right-hand column is why the order is what it is.

Two things about that table are load-bearing. Nothing in step five appears before step four, and nothing in step six appears before the numbers from step two have moved. Every row is a promise you can be held to.

The objection: I have a quarter, not a year

The objection is that this sequence takes twelve to eighteen months and the pressure is now. It is the most reasonable objection in the book.

Three parts to the answer. Steps one to three can be done inside one quarter by a small number of people, and they are the steps with the largest effect, so a compressed programme should compress the later steps rather than the earlier ones. Step four is a platform task with a scope you can bound to a few weeks if you accept a reduced pipeline path rather than a perfect one. And step five can be piloted on one team rather than rolled out, which buys evidence far faster than an argument.

What I would not compress is the order. Doing step five in month one is not a faster version of this programme, it is a different and worse programme, and it costs you the trust that the rest of it needs.

DORA offers a framing for the longer arc that is worth borrowing, distinguishing augmenting existing systems so they can carry the gains from evolving towards workflows native to how AI operates. Steps one to six are augmentation. Everything after them is evolution, and nobody gets to skip to the second part.

One more finding belongs here, because it is the constraint on the whole programme. DORA reports that in the absence of a user-centric focus, AI adoption can hurt team performance. A delivery programme with no user outcome attached is not neutral. It is negative, on DORA's own evidence.

Chapter summary

Sequence is most of the intervention, because the changes in this book divide into those that give something to the team immediately and those that ask something of it, and spending the first group buys the credit for the second. Publish the stance first: DORA's report of 24 September 2025 found that a clear and communicated AI stance determines AI's impact on organisational performance, that it measures clarity and awareness rather than specific content so each organisation can choose its own position, and that its absence produces two failure modes, developers acting too conservatively for fear of overstepping and developers acting too permissively, neither of which DORA calls optimal. Then measure three team-level numbers for a quarter without changing anything, because a constraint proposed without evidence is heard as an opinion about people. Then fix authoring, leading with the standing context, since turning three tired review comments into rules and checks is visible within a fortnight and establishes the direction of travel as removing friction. Then make reversal cheap, before proposing any triage, because triage introduced first reads as gambling with production and the engineers are right. Then introduce triage and size limits together with the signed predicate, the exclusions, the sampling rates and a named queue owner, plus a real review date. Then ownership, security placement and cost, in that order, with the cost lines published only after the earlier steps have moved them, since Faros AI warns against cutting the people absorbing the quality gap. A compressed programme compresses the later steps, never the order. And DORA's finding that AI adoption can hurt team performance in the absence of a user-centric focus is the constraint on all of it.

That is the book. Its argument in one line: authorship stopped being the constraint, so the organisation has to move its expensive attention upstream to specification, standing context and an executable test contract, treat review as a capacity with a number and an owner, gate baseline correctness mechanically and triage the rest by a written risk predicate, keep each change small enough to be read and each queue short enough to move, make reversal cheaper than a careful read before triaging anything, assign answerability for code nobody typed, put security controls where the agent works, and measure delivery with two dated instruments rather than one confident number, while paying for the two cost lines that never appear on an invoice and rebuilding the apprenticeship that used to happen by accident. The measure of whether it worked is not that merge rate went up. It is that the third row of Chapter 1's table, the median time to a first human read, went down while the fourth row, throughput on the branch that actually ships, went up.