CHAPTER DEEP READ · ACCELERATE · CH 11

Leaders and Managers

Accelerate: The Science of Lean Software and DevOps · Ch 11 · Forsgren, Humble & Kim · 2018

What is this chapter about?

Wherever you work, there is a boss. How much does how well your team does actually have to do with that one person?

Two popular answers point in exactly opposite directions. One says: not much — the work is done by the people below, and the best a boss can do is stay out of the way. The other says: everything — a team's ceiling is its leader's ceiling.

This chapter comes from a book that argues with surveys and statistics. It doesn't pick a side. It measures the question. And the answer turns out to be neither.

An analogy: two orchards

Picture two orchards planted with the same variety of tree.

The owner of the first walks the rows every day, shouts at whoever picks slowly, and pays a bonus by the crate at year end. The owner of the second barely touches the trees. He spends money getting the irrigation channel working, replaces the ladders and shears with ones that don't fight you, and every week asks one question — "what got in your way this week?" — and then actually goes and removes the thing.

The second orchard yields more. But the part worth noticing is different: if the irrigation had never been fixed, the second owner could be as warm and as visionary as he liked and the fruit still would not grow. He is not the one who produces fruit. He is the one who makes the ground able to produce it. That distinction is the whole chapter.

Why the old world made this hard

Talk about leadership has historically been talk about temperament: charisma, presence, someone who holds steady when things go wrong. That kind of description has a fatal flaw — you cannot measure it and you cannot teach it. So organizations end up doing only two things about leadership: pick someone who looks the part, then hand them authority over people.

At the other end sits the backlash of the last decade: engineering teams should be autonomous, and the less a boss interferes the better. Half of that is right — micromanagement really does hurt. The broken half is the assumption that a boss can only ever be an obstacle, which quietly deletes the question "so what should a boss actually do?" Both stories leave the thing unmeasurable.

The core mechanism: five things you can see

The chapter's move is almost disappointingly plain. Instead of asking "is this a good leader?", it asks whether employees can point at five specific things:

He can say clearly where we are headed three to five years out;
The way he talks makes people want to come along, not call in sick;
He pushes you to rethink an old problem, not just to hurry up;
He cares about your situation as a person, not only about what shipped;
When you do good work, he says so, to your face.

All five are behaviors, not temperament. Behaviors can be asked about, scored, and practiced.

The first half of the result is clean: the teams that perform best have leaders who score highest on all five; the teams that perform worst have leaders who score lowest.

The second half is the real point of the chapter: a high-scoring leader does not mean a good team. Why? Because a leader does not produce the result — a leader produces the conditions under which a result can grow. Which is the orchard sentence again.

So what do you do

What the chapter asks of managers is unglamorously concrete: make the walls between departments lower; put real money into a learning budget and make sure people actually have time to spend it; and let the people doing the work pick their own tools instead of having procurement pick for them.

The most common mistake runs the other way: buy a thing — a tool suite, a new department, a kickoff meeting — and then wait for results. None of those three changes any of the conditions above, which is why they usually change nothing at all.

One line to keep

To judge a leader, don't listen to how well they talk — ask the people who report to them whether they can give you a concrete example of each of those five things. A leader does not produce results; a leader produces the conditions in which results can grow — which also means no amount of good leadership substitutes for the team doing the work. The honest cost: what this chapter measures is employees' perception of a leader, and between perception and actual behavior there is always a layer.

Want the five dimensions defined, the causal chain, the comparison tables and the industry evidence? → Switch to the deep read

In one sentence

You think leadership is either mystique — charisma, vision, something you can't pin down — or irrelevant, because autonomous teams are enough. This chapter turns it into a measurable variable and then lands a conclusion sharper than either camp: transformational leadership does not produce high performance directly; it produces the conditions in which high performance can grow. It is necessary but not sufficient — weak leadership all but guarantees you will not get a high-performing team, while strong leadership guarantees nothing at all. The technical practices, architecture, culture and lean management of the previous ten chapters are the mediating layer leadership must pass through, and skipping that layer to demand results straight from the leader is exactly the mistake this chapter exists to stop.

Glossary

Transformational leadership — a leadership style that changes how people see their work through vision, inspiration, intellectual challenge and personal support, rather than through an exchange of rewards and punishments. The chapter's object of measurement.
Transactional leadership — its counterpart: "do X and I'll give you Y", driven by targets, appraisals, bonuses and correction. Not a bad thing, but a low ceiling.
Rafferty & Griffin model — the instrument the chapter adopts (Alannah Rafferty and Mark Griffin, 2004), which decomposes transformational leadership into five separately scored dimensions.
Delivery performance — the four key metrics defined in Chapter 2: deployment frequency, lead time for changes (commit to production), change failure rate, and time to restore service. Every result in the book regresses onto these four numbers.
Generative culture — the best band of the Westrum model from Chapter 3: information flows freely, risk is shared, and failure is treated as a chance to learn rather than a chance to assign blame.
Continuous delivery (CD) — the set of practices that keeps software releasable at any moment: version control, automated testing, and a deployment pipeline (the build/test/deploy gates that run automatically after a commit). The subject of Chapter 4.
Lean management — the subject of Chapters 7 and 8: limiting work in progress, making work visible, delivering in small batches, and lightweight change approval instead of an external approval board.
Cross-functional collaboration — development, test, operations, security and product pushing work through on shared goals and direct conversation rather than tickets and handoffs.
Enabler / mediator — statistically, the B in "A does not affect C directly; A affects B, and B affects C". The chapter's central claim is a statement about mediation.
Latent construct — something like "leadership" or "culture" that can't be measured directly, only inferred from a set of questions. How well it is measured depends entirely on how the questions are written.
Likert scale — the "strongly disagree → strongly agree" 1–7 rating that is standard in social-science surveys. All five dimensions here are asked this way.
Correlation ≠ causation — two things moving together does not mean one causes the other. The book uses a voluntary survey plus inferential statistics, not a randomized controlled trial, and every conclusion should be read at that resolution.
eNPS (employee Net Promoter Score) — "how likely are you to recommend this as a place to work", often used as a rough proxy for organizational health.
Psychological safety — the state in which someone on the team can say "I don't know" or "I broke it" without fearing punishment.
Platform engineering — packaging shared capabilities (deployment, monitoring, environments, secrets) into an internal platform that product teams use self-service. The term postdates the book, but it is today's answer to "what should a manager invest in".

Where it sits

This is the closing chapter of Part I, the research findings. The previous ten chapters measured process (the four delivery metrics), culture (Westrum), technical practices (CD), architecture (loose coupling), security (shifting left), management practice (lean), product development, sustainability and employee satisfaction — all variables at the level of teams and systems. This chapter lifts the camera and asks the last, most-skipped question: where in that causal structure do the people who give the orders, approve the budgets and set the appraisals actually sit?

It follows from Chapter 3 (culture) and Chapter 4 (technical practices) — what it sets out to prove is precisely that leadership works through them. It leads into Part III's transformation chapters (including the ING Netherlands case study): Part I only establishes where leaders stand; how you actually move an organization is left for later.

In today's terms, this chapter is upstream of two live threads: platform engineering and internal developer platforms, which are one concrete answer to "where should a manager put the money"; and engineering-effectiveness measurement (DORA, SPACE, DevEx), which turned "is leadership accountable for delivery performance?" into a question with a dashboard.

What the chapter is trying to solve

Start with a concrete scene rather than an abstraction.

An 800-engineer retailer. The CTO announces at the all-hands that the DevOps transformation will be complete in two years. The moves are decisive: stand up a 12-person DevOps platform department, buy a commercial CI/CD suite on a seven-figure annual contract, require all 40-odd teams to report an "automation coverage" number quarterly, and wire that number into every manager's performance review.

Review at 18 months: deployment frequency has gone from monthly to fortnightly — which, on the bands DORA has published year after year, is still low-to-medium (the elite band deploys on demand, multiple times a day). Lead time for changes is still measured in weeks. Change failure rate hovers around 30%. Time to restore service after a production incident is measured in days. Meanwhile those teams' leaders score perfectly respectably in the internal 360 reviews. Nobody is slacking. Nobody is against the transformation.

The money was spent, the department exists, the slogan was delivered, leadership genuinely does care — and four numbers barely moved. Where did it go wrong?

That is the chapter's problem: leadership has been stuck for decades between two equally useless extremes.

Extreme one: leadership as temperament. "Has vision", "can carry weight", "knows how to lead people" — all plausible, all unmeasurable, unteachable, unfalsifiable. Every failed transformation can be explained by "leadership wasn't strong enough", and every successful one credited to "strong leadership". A variable that explains everything explains nothing.
Extreme two: leadership as noise. The DevOps and agile backlash says autonomous teams, minimal interference. Half right — micromanagement is genuinely harmful. The broken half assumes leaders can only subtract, which deletes the question of what leaders should positively do. In reality, training budgets, permission to work across departments, and the right to choose your own tools are none of them things a team can approve for itself.

What happens if this stays unsolved? The scene above repeats: organizations spend their leadership capital where it is easiest to spend — tools, departments, kickoffs — which is exactly where this book's data shows the least movement. Worse, after it fails the organization usually learns the wrong lesson — "execution was weak" — and the next round tightens the appraisals, taking away what autonomy was left.

So the chapter asks two things: can leadership be decomposed into measurable behaviors? And if it can, what path does it take to results — direct, or only by detour?

The core content, properly

1) First move: swap the adjective for a set of behaviors

The methodological hinge of the chapter is that the authors do not invent their own scale. They adopt an instrument already validated in organizational psychology: Rafferty and Griffin's (2004) model of transformational leadership. It looks like a footnote and it decides whether the chapter stands up: had they written a few questions of their own asking "is your leader good?", what they would have measured is satisfaction, not leadership.

The model's design idea is that it never describes what kind of person the leader is, only what a subordinate can observe. Every dimension corresponds to a statement a report can rate. The five:

Vision — the leader has a clear sense of where the organization is going and where it should be in five years, and the people below can state it. Why this one exists: without a direction, every prioritization contest is won by whoever is loudest, and the team re-fights the same argument at every trade-off.
Inspirational communication — says things that make people proud to be part of this, and frames changing conditions as opportunity rather than threat. Why: the first six months of any technical transformation feel worse, not better (the automation hasn't taken over yet and the old process has already been dismantled). What carries a team through that stretch is meaning, not arithmetic.
Intellectual stimulation — challenges the team to rethink old problems in new ways and to question assumptions. Why: practices like continuous delivery are, at bottom, the demolition of assumptions that used to be true ("releases require downtime", "testing comes last"). A leader who only chases the schedule and never permits an assumption to be overturned welds the team to the old way.
Supportive leadership — genuine care and consideration for people's needs and feelings, not just for output. Why: this connects straight to psychological safety in Chapter 3 and burnout in Chapter 9. Without it nobody carries bad news upward, and an organization whose bad news doesn't travel learns nothing.
Personal recognition — specific, by-name acknowledgement of good work and of improvements in quality. Why: improvement work — refactoring, backfilling tests, fixing the pipeline — never gets the applause a feature gets. If nobody looks at it deliberately, a rational engineer stops doing it.

Read together, the five share a property: each is aimed at a specific failure mode rather than at a personality type. That is why they can be taught, practiced, and written into a management curriculum — and it is exactly what separates them from "charismatic".

2) The first half of the result: the direction is clean

Put the five scores next to the four delivery metrics from Chapter 2 and the first conclusion is unambiguous: leaders of the high-performing group score highest on all five dimensions, the low performers lowest, the middle group in between. The direction is consistent; no dimension is an exception.

That result isn't surprising in itself. What deserves a pause is what it rules out: it contradicts the fashionable "leadership is noise, autonomous teams don't need it" position outright. In the data, environments with weak transformational leadership almost never yield high-performing teams. The reason isn't mysterious. Training budget, authority to work across department lines, the freedom to choose tools and decide architecture — those are precisely the gates a team cannot open for itself, and only a manager can release.

3) The second half of the result: the chapter's actual contribution

If that were all, the chapter would be a correct platitude. Its weight is entirely in the second half: the relationship between transformational leadership and delivery performance is not a "more is better" straight line. Within the group with high leadership scores there is a substantial population of low-performing teams.

The book's explanation is the line to keep: transformational leadership is an enabler, not an engine. It doesn't produce performance. It removes constraints, supplies direction and absorbs risk, so that the things that do produce performance — continuous delivery, loosely coupled architecture, lean management, a generative culture — have room to grow. If none of those has been built, all the leadership in the world just keeps everyone cheerful while nothing changes.

There is a very practical corollary: "our leadership is supportive" is not evidence of anything. Support is a precondition, not progress. Whether a transformation is real is visible only in the four delivery metrics and in whether the technical practices actually exist.

Fig 1 · The chapter's structure: transformational leadership acts only through three mediating paths — technical practices, lean management and culture. Skipping the middle column and demanding metrics from the leader is the classic failed transformation.

4) What "necessary but not sufficient" looks like

Plot both halves together and you get a shape that is easy to remember: the top-left corner is empty; the bottom-right is not.

Horizontal axis, transformational leadership, low to high. Vertical axis, delivery performance, low to high. Top-left empty — teams with weak leadership and strong delivery are essentially absent. Bottom-right occupied — teams with a genuinely strong leader and genuinely bad numbers exist, in quantity. That is what "necessary but not sufficient" looks like as a picture.

The shape doubles as a diagnostic. If you land bottom-right (great boss, terrible numbers), what you are missing is engineering capability and process, not support — the fix is test coverage, a deployment pipeline, architectural decoupling, not another kickoff. If you land on the left half at all, don't start with a technical proposal, because every single thing you need requires someone who can approve a budget and lower a wall.

Fig 2 · The shape of "necessary but not sufficient" (schematic, not the original data points): almost no samples top-left, a real population bottom-right — a good leader does not automatically buy good numbers.

5) From leaders down to managers: three levers you can pull tomorrow

The second half of the chapter trades abstraction for three concrete things — and this is its most usable part. What the three share: each requires a manager's position to do. A team cannot do any of them for itself.

Lever one: enable cross-functional collaboration. Concretely — build trust with your counterparts in other departments rather than corresponding via tickets; encourage practitioners to rotate between departments; make other teams' work visible. Why this is a manager's job: walls between departments are a product of org structure, and only a manager can change structure. Two engineers admiring each other across a boundary cannot repeal "this needs a ticket and an approval".
Lever two: create a climate of learning. Concretely — establish and then defend a real training budget; give people time for informal learning and exploration; make failure safe; create venues for sharing (weekly lightning talks, monthly lunch-and-learns, hack days). The word that matters is "defend": the usual death of this lever is the budget getting cut and the time getting eaten by delivery pressure — and a manager is the only one positioned to block that.
Lever three: use tools effectively. Two concrete tests — can teams choose their own tools (Chapter 4 already showed this correlates with delivery performance: the people using a tool know better than the people procuring it), and is monitoring treated as a priority — infrastructure and application monitoring as a precondition for finding problems proactively, not a patch applied after launch.

Hold the three against the failure scene above and the diagnosis is immediate. That company centrally bought a CI/CD suite and appraised managers on automation coverage, which simultaneously inverts lever three (it removed tool choice) and lever two (it swapped learning time for form-filling), while lever one was never touched. The money went into the one direction that does nothing.

Fig 3 · The manager's three levers. They don't move the metrics directly; they change what the team is able to do — which is what "enabler" means in practice.

Trade-offs and choices

The trade-off in this chapter isn't a technology choice. It is where the same unit of management attention and budget gets spent. Three tables pull it apart.

Table 1 · Three leadership styles: mechanism, where each genuinely fits, honest cost

Style	Mechanism	Where it genuinely fits	Cost / failure mode
Transformational	Vision, inspiration, intellectual challenge, support and recognition change how people see the work	Change that requires overturning existing assumptions: continuous delivery, decoupling, shifting security left — anything that feels worse before it pays back	Slow, and it does not certify itself. You can do all five and still see flat metrics (the bottom-right population). Misused, it degrades into pure vision-talk with no constraint actually removed
Transactional	Targets plus appraisal plus reward — "hit X and you get Y"	Clear goals, known path, precisely measurable repetitive work; short-term stabilization	You get what you measure, and not one thing more. Appraise automation coverage and you get gamed coverage. It also suppresses bad news by design, which puts it in direct conflict with a generative culture
Laissez-faire / "autonomy is enough"	The manager steps back and leaves everything to the team	Where the team already has the engineering capability and already holds budget and tool authority, stepping back really is optimal	It mistakes "can't subtract" for "can't add". Training budget, lowering department walls and tool authority are not in the team's hands — stepping back means none of them ever gets approved

Table 2 · The five dimensions: how to land each, and what faking it looks like

Dimension	The failure mode it blocks	Concrete action	Overdone / faked
Vision	Priorities decided by volume; every trade-off re-argued	Write down and publish a 12–24 month direction; each quarter use it to explain one thing you cut	A new vision every year; or a beautiful vision never used to cut anything — then it is a poster
Inspirational communication	The team doesn't survive the worse-before-better stretch	Frame change as opportunity; say out loud "the next six months will be harder"	Good news only. A good-news culture delays bad news until it is past saving
Intellectual stimulation	The team stays welded to assumptions that used to be true	Regularly have the team challenge one existing constraint ("must a release take downtime? go verify")	Challenging others but never accepting challenge; or turning "rethink it" into an endless design forum
Supportive leadership	Nobody carries bad news up; the organization stops learning	Blameless incident reviews; treat being paged five times a night as an incident to investigate, not a badge	Confusing support with lowered standards; or emotional support that never moves a structural obstacle
Personal recognition	Improvement work — refactoring, tests, pipelines — stops happening	Name people for specific quality improvements, not only for shipping under pressure	Turning it into rankings and bonuses — at which moment it has become transactional leadership

Table 3 · The same transformation budget: five ways to spend it, and which ones move the numbers

Spend	What it actually changed	Supported by the book's data?	Honest cost
Centrally buy one CI/CD suite	The brand of the tool. Not who gets to choose	Weak. Chapter 4 supports "teams choose their own tools", not "the tool was expensive"	Removing tool choice actively pulls the other way; and the tool becomes the next scapegoat
Stand up a separate DevOps department	One more wall and one more handoff	No. Directly conflicts with lever one	Looks like progress short term (someone owns it now); long term it moves accountability off the teams
Put "automation coverage" in the appraisal	Swapped transformational leadership for transactional	No. Textbook "you get what you measure"	You get a gamed number; real change failure rate doesn't move, and bad news stops travelling
Give teams tool authority + fund monitoring	Changed what the team can do	Strong. Both tests of lever three	Messier on paper short term (stack divergence); converge it by paving roads, not by policing
Defend the training budget and exploration time	Changed what the team knows how to do	Strong. Lever two	The first line item cut when business gets tight; defending it costs a manager real capital and pays back several quarters late

Why it matters / in real systems

In architecture reviews and technology decisions, this chapter hands you a legitimate argument against "buy the tool first": demand that the budget be translated into the three levers. If a spend gives the team no additional tool authority, no monitoring capability and no learning time, it has most likely just changed vendors.

In interviews and promotion packets, this chapter is the skeleton of a good answer to "how did you drive improvement?" Don't say "I convinced leadership to care". Say "I moved X from requires cross-department approval to the team can just do it". The first is an impression; the second is a change in constraints.

In organizations today, the chapter's most direct heir is platform engineering: an internal developer platform is precisely the act of pushing outward the boundary of what a team can do unaided — lever three as it grew up after 2018.

INDUSTRY EVIDENCE · WHO CONFIRMED IT, WHO HIT THE WALL

Google / DORA: culture and people, not tooling, are the strongest predictors. The official post announcing the 2023 DORA report states: "Culture is foundational to building technical capabilities, igniting technical performance, reaching organizational performance goals, and helping employees be successful." With magnitudes attached — teams with a generative culture show 30% higher organizational performance, and user-centric teams 40% higher. That is this chapter's "leadership works through culture", confirmed downstream.
Source: Google Cloud, "Announcing the 2023 State of DevOps Report" (2023) · cloud.google.com
Google / DORA: the counter-evidence — good leaders can't outrun a moving target. The 2024 DORA announcement contains a line that reads like a footnote written for this chapter: "Instability in priorities, even with strong leadership, comprehensive documentation, and a user-centered approach — all known to be highly beneficial — can significantly hinder progress." In plain terms: strong leadership, thorough documentation and user focus, all three together, will not save an organization that changes direction every month. That is the bottom-right corner of Fig 2, restated.
Source: Google Cloud, "Announcing the 2024 DORA report" (2024) · cloud.google.com
Google / DORA 2025: new technology amplifies the existing state, it does not repair it. The 2025 report applies the same logic to AI — "AI doesn't fix a team; it amplifies what's already there": strong teams get stronger with it, struggling teams have their problems magnified. The same report notes that 90% of organizations have adopted at least one internal platform, and ties internal platform quality directly to whether an organization can realize AI's value. Substitute "DevOps tooling, 2018" for "AI" and you have this chapter's enabler-not-engine sentence, replayed.
Source: Google Cloud, "Announcing the 2025 DORA Report" (2025) · cloud.google.com
Microsoft: middle managers are stuck holding accountability without the gates. The 2022 Work Trend Index (31 markets, 31,102 full-time workers) reports two numbers: 54% of managers say leadership at their company is out of touch with employee expectations, and 74% say they don't have the influence or resources they need to make changes on behalf of their team. That explains why the three levers won't budge in so many organizations — not because managers don't want to pull them, but because the gates aren't theirs. When this chapter hands responsibility to "leaders and managers", it assumes that position actually carries power.
Source: Microsoft, "Great Expectations: Making Hybrid Work Work", 2022 Work Trend Index Annual Report · microsoft.com

Pitfalls and open arguments

The most common misreading: taking this as "leadership decides everything". It argues the opposite. The structure is mediation — leadership → practices and culture → performance — and the middle link cannot be skipped. An organization that only swaps in a better leader is predicted to get better morale and four unchanged metrics.
The second most common: equating transformational leadership with charisma. None of the five dimensions is "a magnetic personality"; all five are observable behaviors. Charisma can even be harmful — an organization where one person's force of personality drives all improvement loses that capability when they leave, which is the opposite of the book's insistence that capability belongs to the organization, not the individual.
Be clear about the method. As with the rest of the book, this is a voluntary survey plus inferential statistics, not a randomized controlled trial. More importantly, transformational leadership is a perception scale rated by subordinates, not an objective observation of behavior. A high score strictly means "the people below experience them this way" — and on a high-performing, high-morale team people are already inclined to rate their leader well, so causality is very likely bidirectional.
The chapter doesn't answer "how do we change". It shows leadership matters and names three levers, but how an organization moves from a low-leadership state is entirely absent from Part I — that's Part III (and the ING Netherlands case). Reading this chapter as a playbook will disappoint.
It assumes the manager holds the gates. All three levers need budget authority, structural authority and permission to delegate tool choice. Microsoft's 74% above says many managers have none of these. The right move then is to read the chapter one level up: the problem isn't this manager, it's how the layer above them designed the delegation.
Rafferty & Griffin is one model among several. Organizational psychology also offers Bass's full-range model, servant leadership and others, and results shift with the instrument. The book chose this one because it is mature, compact and models cleanly alongside the other variables — a choice, not the only answer.
Limits of its moment. Written in 2018, before large-scale remote and hybrid work, platform engineering and AI-assisted development changed what a manager can pull. The five dimensions still hold, but "make other teams' work visible" in a fully remote setting isn't covered. And DORA 2025's "AI only amplifies what's there" suggests the direction of travel: each new tooling wave makes this chapter's conclusion harder, not more obsolete.

Takeaways

1. The core claim: transformational leadership is an enabler, not an engine. It does not produce delivery performance; it produces the conditions performance grows in — necessary, never sufficient.

2. The methodological hinge: describe not what kind of person the leader is, but what subordinates can observe — hence an established instrument (Rafferty & Griffin, 2004) rather than homemade questions.

3. The five dimensions: vision, inspirational communication, intellectual stimulation, supportive leadership, personal recognition. Each aims at a specific failure mode, which is why they can be taught, practiced and checked.

4. First half of the result: leaders of high performers score highest on all five, low performers lowest — a direct refutation of "autonomy is enough, leadership is noise".

5. Second half (the real contribution): high leadership does not guarantee high performance. Drawn out, it is "top-left empty, bottom-right occupied" — good leader plus bad numbers is a real and common combination.

6. Hence the most useful test in the chapter: "our leadership is supportive" is not evidence of anything. Whether a transformation happened shows up only in the four delivery metrics and in whether the practices exist.

7. The manager's three levers, all sharing one property — a team cannot pull them: enable cross-functional collaboration, build and defend a climate of learning, use tools effectively (team choice plus monitoring).

8. The classic misdirected spend: centrally buying a tool suite, standing up a separate DevOps department, appraising on automation coverage — three moves that invert the levers at once and shift accountability off the teams.

9. Outside evidence lines up: DORA 2023 "culture is foundational" (generative culture, 30% higher organizational performance), DORA 2024 "even with strong leadership, unstable priorities significantly hinder progress", DORA 2025 "AI amplifies what's already there"; the countervailing reality is Microsoft's 74% — most managers do not hold the three gates.

10. How to hold it: voluntary survey plus inferential analysis, causality likely bidirectional; leadership here is subordinate perception, not observed behavior; and the chapter answers only where leaders stand, leaving "how to actually change an organization" to Part III.