BOOK DEEP-READ · ACCELERATE · CH 16
Accelerate · Ch 16 · Forsgren, Humble & Kim · 2018
The first fifteen chapters read like a health report: using tens of thousands of survey responses, they tell you what a fast-and-stable company looks like. But the sharpest question is still unanswered — how do I get there from where I actually am? This is the only chapter in the book that answers it. And its answer is counterintuitive: don't draw a roadmap.
Most people start getting fit by buying a twelve-week plan. But the plan was written for somebody else's body — your real weak link might be sleep, and the plan has you adding mileage. What actually works looks like this: check where you are today, commit only to what next week should look like, try one small change, swap it if it doesn't move anything. The path gets walked, not drawn in advance. This chapter takes that and applies it to an entire company.
Corporate change has two default scripts. The first is hire someone to draw a roadmap: five levels, we're at three, two years to reach five. The trouble is the ladder is written for the industry average, and every company is stuck somewhere different — somebody else's level three may not be your bottleneck at all, so climbing it is massaging a part that doesn't hurt.
The second is the big reorg: new reporting lines, new org chart, a kickoff. The seats change, but how people actually work at nine in the morning doesn't — and within six months the old habits grow back along the new chart.
The core of the chapter is splitting "improvement" across three kinds of people, and splitting it strictly:
The people at the top do exactly two things — say where we are going (a direction on a multi-year scale, not a task list), and then clear the road: fund it, kill the approvals that block it, and keep priorities from changing every week. They do not hand down solutions.
The people in the middle coach, daily — and only by asking: what does it actually look like right now? What should it look like next? What are you going to try? What did last time teach you? They hold no correct answer; their job is to force the other person's answer out.
The people who change how the work is done are the people doing it — only they know which step hurts. Improvement isn't a separately funded "transformation project"; it's part of the day job.
One more rule: commit to the next small target only, never plan the whole path. Nobody knows how to get from "today" to "what next month should look like" — you can only try a step, look, and try again.
The book's example is the Dutch bank ING, whose most famous move was exactly a dramatic reorg: several thousand head-office staff left without a position, everyone reapplying. But the chapter's point is not "go do a reorg" — it is that the reorg only set the conditions; what made it fast was the small stuff that happened afterwards, every day: business and engineering sitting in one squad, work no longer handed across desks, managers on the floor asking those four questions.
One honest caveat: this chapter rests on one story about one bank, not on the tens of thousands of survey responses behind the earlier chapters. It's experience worth having — it is not statistical evidence.
Getting better can't be done off a roadmap: the top sets direction and clears obstacles, the middle coaches by asking and never answering, and the changes are made by the people doing the work. Commit to one small target at a time and discover the rest by experiment. There is no day the transformation is finished — the improvement habit you drilled is the output.
Want the mechanisms, the comparison tables and the diagrams? → Switch to the deep read
The first fifteen chapters established what a high-performing organization looks like. Chapter 16 is the only chapter that answers "so how do I become one" — and its answer is: not a roadmap, but a routine everyone practices daily. Leaders set direction and create conditions; managers coach by asking on the floor; the improving itself belongs to the people doing the work. ING Netherlands is the book's only full case study.
This is the only chapter of Part III, "Transformation" — and the only chapter written by outside authors, the Lean IT practitioners Steve Bell and Karen Whitley Bell. It follows Part I's statistical findings (Ch1–11) and Part II's research methodology (Ch12–15), and is followed by the book's conclusion. Its real-world counterpart is concrete: any organizational change that starts with the words "we're going to do a DevOps transformation".
The first fifteen chapters deliver a correlation map: continuous delivery, loosely coupled architecture, lean management, generative culture, transformational leadership — all correlate with the four key metrics. The trouble is that correlation doesn't tell you where to put your foot. A CTO finishing Chapter 15 holds two dozen capabilities. What does she do first thing Monday?
Reality offers two default answers, and this chapter convicts both.
The first is the maturity-model roadmap. Buy a five-level ladder, run an assessment, schedule two years. Its fatal flaw is that it fixes the order: the ladder is built on industry averages, while every organization is stuck somewhere different — climb it and you may spend twelve months on a capability that was never your bottleneck. Worse, it implies a finish line, and the book's central claim is that there isn't one.
The second is the big reorg. The chart does change overnight, but how people prioritize at nine in the morning, how a change reaches production, who gets called when it breaks — none of that daily behaviour moves, and within months the old habits regrow along the new chart.
What happens if you don't solve it? The common ending: the metrics get dressed up (deployment frequency lifted by slicing meaningless releases thinner), the transformation office turns from catalyst into a new approval gate, and two years later you hand in a "transformation complete" report and an organization much like the one you started with.
The chapter's hardest structural claim is that improvement splits across three layers, strictly — each layer does only its own part, and crossing the line is where it breaks.
Leaders do two things: set direction and create conditions. The direction is a multi-year challenge ("any change can reach production safely within a day"), not a task list. Creating conditions means funding it, killing the external approvals in the way, and the most underrated one — keeping priorities stable. Chapter 11 already measured this: transformational leadership creates conditions but not results — weak leadership all but guarantees low performance, strong leadership guarantees nothing. So the move a leader should fear most is stepping in with the solution.
Managers coach on the floor, daily, and only by asking. Four questions, over and over: what is the current condition, in data rather than impressions? What is the next target condition? What will you try? What did the last experiment teach you? A coach's value is not in knowing the answer but in forcing the other person's answer out — the moment the coach supplies solutions, the learning stops with him and never enters the team.
Improvement belongs to the people doing the work, because only they know which step hurts. The corollary is sharp: improvement should not be a separately funded "transformation project" or a centre of excellence; it is part of the day job. Outsourcing it to a dedicated team announces that the people on the floor need not think.
So what does "improve daily" concretely look like? The model the book recommends is Mike Rother's Improvement Kata, distilled from Toyota — a four-step loop:
11 days at the median and 39 days at p90, of which 8 days sit in a manual change-approval board.The soul of the thing lives between ② and ③: the path from the current condition to the target condition is genuinely unknowable in advance. Roadmap-driven transformation errs by pretending it is knowable and filling two years with it. The kata's move is to admit you don't know, commit only to the next target condition, and walk the path out through a chain of small experiments. That is what "kata" means — something drilled until it becomes instinct, not a template to fill in.
ING Netherlands is famous for its extreme 2015 reorganization: thousands of head-office staff placed without a position and required to reapply, the organization rebuilt into squads, tribes and chapters. But reading this chapter as "go do a reorg" is the most common misreading. The reorg only set the conditions; performance came from what landed in the daily work afterwards:
Separating these four from the reorg matters: the reorg was one-off and barely transferable; these four are continuous, and you can start a little of each tomorrow.
The easiest line to skip and the most consequential: there is no day on which the transformation is finished. A maturity model suggests you graduate at level five; a capability model means the environment keeps moving — yesterday's bottleneck is cleared and tomorrow grows a new one. The output is not a metric hitting a number but an organization that has acquired the habit of getting better by itself: any team handed a new bottleneck knows how to read reality, set the next target condition, and experiment its way across.
That also gives a useful self-check: if your transformation has a closing report and a celebration, you probably built a project rather than a capability.
Table 1 · Four forks in the road, and what each costs
| Fork | Option A | Option B | How to choose (with the honest cost) |
|---|---|---|---|
| Map for improving | Maturity model: five levels, fixed order, two-year plan | Capability model: a set of capabilities, attack your own weakest | The book backs B. A's only merit is that it reports well to a board and budgets cleanly; the cost is an order fixed on industry averages, so the first year may go into something that was never your bottleneck — plus a false finish line |
| Who improves | Dedicated transformation team / CoE | The people on the floor, with managers coaching | The book backs B. A starts faster, is easy to fund, and works as a temporary seed when internal capability is genuinely absent; made permanent it declares that the floor needn't think, and readily decays into a new approval gate |
| How to move | Big bang reorg: change the whole shape at once | Small pilots, then spread | A can break entrenched functional walls in one cut (ING's route), but the cost is severe — attrition and a visible trough — and it survives only under real existential pressure with the top fully committed. Most organizations should take B; either way, both must be followed by daily improvement or the old habits regrow within months |
| How to coach | Give the answer: I've done this, do it this way | Ask only: reality? target? experiment? learning? | The book backs B. A is faster in a fire and with raw beginners, but the learning stops with the coach and leaves when he does. B is slower and demands that managers bite their tongue — the hardest thing on this list to train |
Table 2 · Is your target condition written correctly? A side-by-side you can edit against
| Written badly | Written well | |
|---|---|---|
| Form | A task list: "introduce a pipeline tool, write automated tests, run training" | A state: "low-risk changes go through automated approval, with no review board" |
| Measurable | "improve delivery efficiency" | "median lead time for changes goes from 11 days to under 3" |
| Time box | "this year", "ongoing" | 2–4 weeks — short enough to be falsified, long enough to change something |
| Path | Every week's work scheduled in advance | Only the target is committed; the path is left blank and filled by experiment |
| Who sets it | Issued by the transformation office | The team sets it; the coach only challenges whether it is testable |
This chapter is the bridge from "research findings" to "what I do on Monday morning". It pays off in three places: designing organizational change (stop handing in five-level roadmaps), the daily behaviour of a management job (coaching questions are trainable, concrete acts, not the slogan "show leadership"), and interviews and architecture reviews (asked "how did you drive an improvement", a repeatable reality → target condition → experiment chain lands far harder than "I rolled out the XX platform").
3,500 head-office employees were placed on "mobility" and required to reapply for a role; the new organization was 13 tribes and about 350 nine-person squads; selection weighted culture and mindset above knowledge and experience. These numbers give the order of magnitude of the "reset the conditions" side of the chapter — and a reminder of what it costs. Source: McKinsey Quarterly, "ING's agile transformation", January 2017, interviewing then-COO Bart Schlatmann and CIO Peter Jacobs of ING Netherlands (the domain is unreachable from this site's fetch environment, so the citation is text-only)① The only "how" chapter in the book (Part III's sole chapter), written by outside authors Steve Bell and Karen Whitley Bell, with ING Netherlands as the case.
② Core claim: improvement can't run off a roadmap; it runs off a routine everyone drills daily — because the path from here to the target is unknowable in advance.
③ Three layers: leaders set direction and create conditions, managers coach by asking and never answering, improvement belongs to the people doing the work. Any layer crossing the line stops the learning.
④ The four-step kata: direction (years) → grasp the current condition (in data) → next target condition (2–4 weeks, a state not a task list) → small experiment (days/hours) → back to reality.
⑤ Maturity model vs capability model: the first fixes the order and implies a finish line; the book backs capabilities — go at your own weakest link first.
⑥ What transfers from ING is not the reorg but four things: end-to-end squads, engineering leaders who are engineers, a self-service platform, and improvement happening on the floor.
⑦ Transformation has no completion date: the output is not a metric hitting a number but an organization that improves itself. A closing report usually means you built a project.
⑧ Honest boundary: this is an n=1 case narrative, weaker evidence than the preceding fifteen chapters. Cargo-culted squad/tribe names and coaches becoming a new approval layer are the two most common implementation accidents.
⑨ External corroboration: DORA 2021 measured generative culture halving burnout; DORA 2024 measured unstable priorities cancelling out strong leadership. Both point at one sentence: a leader's output is conditions.