Everything above is framework by framework. This part runs whole scenarios end to end, so you can see how the pieces connect — including the parts where the practitioner got it wrong first, which is the part most case studies omit.

The three scenarios are composites, not reports of specific organizations. The mechanisms and failure modes are the ones documented throughout this guide; the particulars are illustrative.

Tutorial: your first diagnosis

If you have never run an OD engagement, do this one. It takes about three weeks of part-time effort and it teaches the whole cycle at low risk.

Choose a scope you can actually see. One team, one recurring problem, one sponsor who can authorize changes to that team. Resist starting at department level; you will not be able to observe the work.

Week 1 — contract, then read.

  1. Have the contracting conversation out loud, using the checklist in Part 11. Write down the presenting problem verbatim, and your own hypothesis separately, on the same page.
  2. Ask the sponsor the uncomfortable question: "if the diagnosis points at something you control, what happens?" Their answer determines what kind of engagement this is.
  3. Read the last year of whatever this team produces as a record of its troubles: incident reviews, complaints, survey results, retrospective notes, board papers. You will form a hypothesis. Write it down so you can later discover it was wrong.

Week 2 — interview and observe.

  1. Interview six to ten people. Open every one with the confidentiality statement, including its exceptions. Ask for stories, not opinions: "tell me about the last time that happened" beats "what do you think of our communication?"
  2. Ask everyone the three highest-yield questions: what surprised you in your first month here? what would you tell a friend considering joining? what does everyone know and nobody says?
  3. Observe the actual work for at least two sessions. Count things: who speaks and for how long, how many times a task is interrupted, how long work waits between steps. Counting converts an impression into a finding that survives challenge from someone senior.

Week 3 — frame, feed back, and pick one thing.

  1. Choose a diagnostic frame. If you are unsure, use Weisbord six-box — six boxes, ninety minutes, formal system on the left and informal on the right.
  2. Before proposing anything, rule out the three boring causes in order: workload, incentives, decision rights. Most problems presented as cultural are one of these. If you skip this step you will propose a workshop for a staffing problem.
  3. Feed the data back to the people it came from, before the sponsor. Let them interpret it. Your job in that room is to present what you saw and then be quiet.
  4. Agree one intervention, with a named owner, a date, a written prediction of what will change and by how much, and a balancing measure. One, not five.
  5. Run it small. Compare the result against your prediction. Decide: adopt, adapt, or abandon.

What you should expect to happen. Your week 1 hypothesis will be partly wrong — that is the exercise working, not failing. The real constraint will usually be more boring and more structural than the presenting problem suggested. And the feedback session will be the moment the engagement either earns trust or loses it.

Case study: a hospital ward

Presenting problem. A 28-bed medical ward reports rising medication administration errors over two quarters. The clinical director's request: "we need to retrain the nurses."

Contracting. The practitioner records the presenting problem verbatim, and notes separately that a retraining request arriving with the diagnosis already made is a red flag at entry. Contracting establishes access to incident reports, permission to observe drug rounds, and — critically — agreement in advance on what happens if the finding touches staffing levels, which the director does not control. The director agrees to take such a finding to the divisional board rather than bury it. That agreement is what makes the rest of the work possible.

Diagnosis. Three methods, triangulated.

  • Documents: 14 incident reports over six months. Ten involve a different nurse each time. This alone largely rules out an individual competence explanation — see the substitution test.
  • Observation: four drug rounds watched end to end. The practitioner counts interruptions. The mean is 11 per round, from doctors, families, phones, and the ward clerk. Two rounds are interrupted mid-calculation.
  • Interviews: nine staff. Every nurse describes the same workaround — pre-preparing medications to avoid interruption during the round. Nobody has written this down anywhere. Two nurses say they have stopped reporting near-misses because a colleague was "performance managed" after one.

The frame. Burke-Litwin, because the question is causal. Performance (12) is down. Tracing upstream: motivation (11) is fine — these are committed clinicians. Task requirements and skills (9) are fine — the substitution test says peers would err identically. The breakdown is at systems (7): an interruption-dense process with no protected time; and at work unit climate (8): reporting suppressed by fear. Both are transactional. The intervention does not need to be a culture programme.

What the practitioner got wrong first. The initial hypothesis was understaffing, which was the loudest theme in interviews. The observation data did not support it: error clustering did not track shift fill rates. Staffing was a genuine grievance and not the cause of this problem. Saying so, having raised it, cost some credibility with staff and preserved the finding.

Feedback. The ward team sees the interruption count first, before the director. Their reaction is recognition rather than surprise — they knew, and had never counted. The team itself proposes the intervention.

Intervention. Two changes, both technostructural, plus one climate change.

  1. A protected drug round: tabards, a redirection protocol for the ward clerk, and a phone diverted for 40 minutes. See force field analysis — this removes a restraining force rather than adding exhortation.
  2. Prediction, written in advance: interruptions per round fall from ~11 to under 4 within six weeks; administration errors fall over two quarters.
  3. Climate: the ward manager states publicly that near-miss reports will be thanked, and the clinical director separates the learning review from any disciplinary process, in writing. See just culture.

Measurement, and the trap. Interruptions fall to 3.2 per round by week five. Medication errors do not fall in the first quarter — reported errors rise by 40%. This is the reporting-rate paradox, and it was pre-agreed with the board at contracting, in writing, precisely because it was predictable. Without that agreement the programme would have been read as having made things worse and stopped. Severity-weighted harm is flat and then declines over the following two quarters, which is the signature of a system getting healthier.

What sustained it. The tabard protocol entered the ward induction pack. That is the institutionalization step: rotating junior staff now learn it without anyone deciding to teach them.

Case study: a platform team

Presenting problem. An engineering organization of about 90 people reports that delivery has slowed. The CTO's request: "we need to hire more engineers, and maybe adopt a different agile framework."

Contracting. Access is negotiated to the deployment pipeline telemetry, the pull request history, and the incident record — data that is more honest than interviews and cheaper to gather. The CTO agrees that the finding may implicate the architecture and the approval process, both of which they own.

Diagnosis. DORA metrics first, because they are instrumented and fast.

  • Deployment frequency: every two weeks, batched.
  • Lead time for changes: 19 days median.
  • Change failure rate: 23%.
  • Time to restore: 6 hours.

Decomposing lead time is the whole diagnosis: coding is 1.5 days of the 19. Code review waits 4 days. A manual approval board meets weekly, adding up to 7. The release window is fortnightly, adding up to 10 more. Almost all of the lead time is queueing, and none of it is typing.

Interviews add the human half: four teams share one deployment pipeline and one approval board. Engineers describe batching changes to "make the release worth it", which raises change size, which raises failure rate, which justifies the approval board. A textbook reinforcing loop — see systems thinking.

The frame. Conway's law and team topologies. Four stream-aligned teams are coupled through a shared platform operated as a ticket queue, converting X-as-a-Service into permanent Collaboration. Adding engineers, the CTO's proposal, would increase contention on the constraint. This is the shifting the burden archetype.

What the practitioner got wrong first. The initial read blamed the approval board, which is the satisfying villain. But the board existed because change failure rate was genuinely high, and the board was catching real defects. Removing it first would have raised incidents and ended the engagement. The correct sequence was to make changes smaller and safer first, and let the board become visibly redundant.

Intervention. Sequenced deliberately, over two quarters.

  1. Cut the test suite from 2 hours to 12 minutes, so review and integration stop queueing behind it. Unglamorous, and it unblocks everything else.
  2. Change review assignment so pull requests have a named reviewer within 4 working hours.
  3. Only then: replace the approval board with automated policy checks for the two service classes that now demonstrate a low change failure rate. The board remains for the rest. This is a safe-to-fail experiment with a defined blast radius, not a big-bang removal.
  4. Give the platform team a self-service mandate and an explicit X-as-a-Service interaction mode, with a date by which the ticket queue closes.

Measurement. Lead time 19 days to 3. Deployment frequency fortnightly to daily for the two lead services. Change failure rate 23% to 9% — falling while speed rose, which is the DORA finding that speed and stability move together. Balancing measure: on-call pages per engineer per week, watched to make sure velocity was not being bought from the on-call rotation. It fell.

The organizational finding. No one was hired. The CTO's presenting problem — insufficient people — was the most expensive available answer to a queueing problem. See Part 10, anti-pattern 12: what looked like a capacity problem was a structure problem.

Case study: an executive team

Presenting problem. A CEO of a 400-person organization reports that "we lack accountability" and asks for a leadership development programme for the executive team.

Contracting. This is the hardest contract in the guide, because the client system is the executive team and the sponsor is in it. The practitioner establishes explicitly, before hearing anything: the CEO's own behavior is in scope; feedback to the CEO will be delivered privately first and then, in summary, to the team; and the engagement ends if that becomes unacceptable. The CEO agrees. Getting this in advance is what makes the finding survivable later.

Diagnosis. Observation is the primary method, because executive interviews are heavily managed.

  • Observation: three executive meetings, attended silently. The practitioner records who speaks first on each item, elapsed time to convergence, and whether each decision is revisited later. The CEO speaks first on 11 of 14 items. Median time to apparent agreement is 90 seconds. Six of 14 decisions reappear at a later meeting.
  • Interviews: all seven executives, individually. Every one describes the same thing without prompting: real disagreement happens after the meeting, in pairs, in the corridor.
  • Documents: two overlapping remits — two executives both believe they own pricing.

The frame. Two, layered. Lencioni names the observable chain: no vulnerability-based trust, so no real conflict, so compliance rather than commitment, so decisions are revisited, so nothing feels accountable. Accountability, the presenting problem, is the fifth-level symptom of a first-level cause. Argyris supplies the sharper instrument: the espoused theory is "we want challenge"; the theory-in-use, inferred from behavior, is "challenge is not offered when the CEO has already spoken."

What the practitioner got wrong first. The initial plan was a facilitated team offsite on trust. It would have failed: the structural problem — two people genuinely both owning pricing — meant executives had a rational reason to avoid open conflict, because the conflict had no resolution mechanism. Structural clarity had to come before trust work. People cannot be candid about a game whose rules are undefined. See dosage and sequencing.

Feedback. The CEO receives the "speaks first on 11 of 14 items" data privately, first. This is the engagement's pivot. The CEO's response — curiosity rather than defensiveness — is what makes the rest possible, and it was made more likely by having been contracted for in advance.

Intervention. Three changes, sequenced.

  1. Structural first: decision rights mapped and published for the twelve decision types that actually recur, including pricing. Ambiguity resolved by naming a single owner each, in writing.
  2. Process: the CEO speaks last on any item they have not explicitly framed as already decided. A rotating designated challenger role. Dissent recorded in the minutes, so disagreeing is a documented professional act rather than a social risk. See crew resource management — this is graded assertiveness for a boardroom.
  3. Only then, behavioral: the CEO opens a meeting with a specific account of a decision they got wrong and what it cost. See psychological safety — the leader modelling fallibility, done specifically rather than ritually.

Measurement. Deliberately behavioral rather than perceptual, because an engagement survey would not move for a year. Decisions revisited fell from 6 in 14 to 1 in 15 over two quarters. Time-to-convergence rose from 90 seconds to about 6 minutes — this was the intended direction, agreed in advance, because 90-second agreement was the symptom. Executives naming a peer disagreement openly in the room rose from 0 observed instances to 4 in a single meeting.

The finding the CEO did not ask for. The accountability problem was not a capability gap in the executive team, and a leadership development programme would have been an expensive way to avoid it. It was the CEO's own speaking order plus two undefined remits. Both were cheap to fix and uncomfortable to name — which is why the contract, agreed at entry, was the most important part of the engagement.

What the three have in common

Five patterns recur across all three, and they are the guide compressed:

  1. The presenting problem named the intervention, and was wrong every time. Retrain the nurses. Hire more engineers. Develop the executives. In each case the requested intervention was the most expensive available answer, and in each case it addressed a symptom.

  2. Counting beat opinion. Interruptions per round. Days of lead time by stage. Who speaks first, and how often decisions are revisited. Each engagement turned on a number that nobody had bothered to collect, and that nobody could argue with once collected.

  3. The practitioner's first hypothesis was partly wrong, and finding that out was the value. Understaffing, the approval board, a trust offsite. Being willing to discard your own hypothesis in public is most of the skill.

  4. The contract, agreed before any data existed, is what let the finding survive. The board pre-agreeing the reporting-rate interpretation. The CTO accepting that the architecture was in scope. The CEO accepting that their own behavior was. In all three, the engagement would have collapsed at the feedback stage without it.

  5. Structure and workload were the causes; culture was the symptom. Every scenario began as a request for people-change and ended in a change to process, decision rights, or the physical conditions of work. That ordering is not a coincidence, and it is the most reliable single heuristic in this guide: rule out workload, incentives, and decision rights before you diagnose culture.

Organizational Development — a comprehensive practitioner's guide to OD for health care professionals, software engineers, and senior executives. Every framework says what the evidence is, and where it is weak.

Source and contributions: github.com/organizational-development. Built with the Lily Design System™.