The OD process

The cycle

OD is a cycle, not a project. Each intervention changes the system and therefore invalidates part of the original diagnosis.

Entry → Contracting → Diagnosis → Feedback → Planning →
Intervention → Evaluation → Institutionalize or exit
                    ↑                              |
                    └──────────────────────────────┘

Underneath sits action research, Kurt Lewin's method: knowledge about a social system is produced by trying to change it, with the members of the system as co-researchers rather than as subjects. His summary: "No action without research; no research without action."

Participation is not politeness; it is a method claim. People in the system hold data no outsider can obtain. People implement what they helped design. And the act of collecting and discussing data is itself an intervention — which is why "let's just do a survey first" is never neutral.

See topics/od-process-cycle and topics/action-research.

Entry and contracting

Contracting is the stage practitioners most often skip and most often regret skipping.

Do not accept the presenting problem at face value. "We need team building" usually means "two directors are at war." "We need a new tool" usually means "our process is undefined and we hope the tool will define it." Write down the presenting problem verbatim; state your own hypothesis separately; revisit both after diagnosis.

A contract must settle:

• Sponsor vs. client system. The sponsor pays and authorizes; the client system is the group whose behavior must change. If the sponsor is not in the client system, the diagnosis will eventually implicate someone who never agreed to be examined.
• Scope and boundaries, and what happens when diagnosis points outside the boundary. It usually does.
• Access: who you may interview, what data you may see, what you may observe.
• Confidentiality: what is attributable, what is aggregated, what the sponsor will and will not be told.
• Decision rights: who decides which interventions proceed. If the answer is "we'll see", the answer is "nobody".
• Your role: expert, pair of hands, or collaborator (Peter Block's three modes). Most OD work should be collaborative; most clients initially want a pair of hands; most practitioners default to expert.
• Success criteria and exit conditions, including the condition that the work is not working.

Say the wants and offers out loud. What I want from you: access, time, candor, a decision forum, an executive who will act on unwelcome findings. What you can expect from me: a diagnosis you may not like, feedback to participants before leadership, no surprises in public, and an honest statement when an intervention has failed.

Red flags at entry: the sponsor names the intervention before the diagnosis; the sponsor excludes themselves from scope; a specific conclusion is off-limits; the real decision-maker will not meet you; the timeline is set by an announcement already made; you are being hired to validate a decision already taken.

Health care: name the clinical governance route, the information governance rules for patient data, and the fact that patient-safety findings cannot be withheld — before you start. Software: settle whether you may read the issue tracker, the deployment telemetry, and the incident history; this data is usually more honest than the interviews. Executive: when the client system is the executive team, the contract must state that the CEO's own behavior is in scope, and how feedback to the CEO will be delivered. Agree this before you hear anything.

See topics/entry-and-contracting.

Diagnosis and data gathering

Diagnosis has two parts: choosing a frame (see Part 3) and gathering data to populate it.

Methods, with their biases:

Triangulate. Any finding that appears in only one method is a hypothesis. Findings that appear in interviews, in observation, and in telemetry are findings.

Interview practice. Twelve to twenty interviews usually reaches saturation in a single unit — you stop hearing new things. Open with an explicit confidentiality statement including its exceptions. Ask for stories and specifics, not opinions: "tell me about the last time that happened" beats "what do you think of our communication?" Ask what surprised them in their first month. Ask what they would tell a friend considering joining. Ask what everyone knows and nobody says.

The best free instrument available: ask people in week three of their employment what surprised them. They can still see the culture, and they have not yet learned not to mention it.

Observation practice. Watch the actual work. 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.

Health care: observe a drug round, a handover, and a ward round before forming any view. Clinicians will accept observational data about their own process and will reject an opinion. Software: read the last twenty incident reviews and the pull request history before interviewing anyone; you will know where the friction is. Executive: attend three executive meetings as a silent observer. Record who speaks first, how long until convergence, and how many decisions are revisited. That data set is usually the whole diagnosis.

Feedback

Give the data back to the people it came from, before you give it to the sponsor.

This is a founding OD practice with an empirical basis. The Michigan survey feedback studies found that units where managers discussed results with their own teams improved, and units that received the same report without discussion did not. Collecting data changes nothing; feeding it back and working with it does.

The cascade. Feed back top-down in family groups — each manager with their own team, starting at the top. Each group sees its own data plus the aggregate above, interprets its own data, and commits to what it will change within its own control.

Why the sequence matters: senior leaders confront their own data first, which is the credibility test; each manager must discuss uncomfortable results with their own team, which is where behavior changes; and escalation is filtered, so only genuine organization-level constraints travel upward.

Rules:

• Give each group its own data, not just the organizational average.
• The group interprets. An analyst who arrives with conclusions has taken the ownership that produces the change.
• Actions must be within the group's control.
• Close the loop visibly — "you said, we did", including honest refusals with reasons. The honest refusal preserves more trust than silence.

The damage of doing it badly: surveying without feedback measurably reduces trust below the pre-survey baseline. Do this three times and you have taught your workforce that disclosure is pointless.

See topics/survey-feedback-method.

Intervention design

Convert diagnosis into hypotheses, and hypotheses into interventions with named owners, dates, and measures.

Write a theory of change for anything substantial:

Inputs → Activities → Outputs → Outcomes → Impact

Build it backwards: state the impact, ask what outcomes must occur, what outputs would produce them, what activities produce those, what inputs are required. Then — the part that matters — write the assumption between each pair of boxes, and rate your confidence in it. The assumptions are the falsifiable content, and they are where programs fail.

Outputs are not evidence of success. "We trained 400 people" is an output. Whether anyone behaves differently 90 days later is an outcome.

See theory of change and topics/theory-of-change.

Implementation

Three rules that govern most of the difference between programs that work and programs that do not.

1. Start where credibility is cheapest to earn. A visible, small, fast win that the sponsor did not have to force. Credibility is the currency you spend on the difficult intervention later.

2. Do not stack changes. One major intervention per group at a time. Two simultaneous transitions do not resolve faster than one; they resolve slower and with more damage. See Satir change model.

3. Expect and plan for the dip. Every change requiring new competence makes people temporarily worse at their jobs. Reduce other demands during the dip, shorten feedback loops, and say publicly that the dip was expected and has an end.

Evaluation

Compare what happened against what you predicted — including the possibility that nothing changed or something got worse. See Part 8.

Evaluation is a decision point, not a report. The decisions available are: adopt, adapt, or abandon. A program that has no abandon condition is not being evaluated.

Sustaining and exit

A change is complete when a person joining next month does the new thing without being told.

Institutionalization mechanisms, in order of durability:

1. Selection and promotion criteria. Who gets hired and who gets promoted is the strongest long-run lever, because it changes who "we" are.
2. What leaders attend to and measure routinely.
3. Rewards and resource allocation.
4. Systems, tooling, and defaults. Make the new way the path of least resistance. If the right thing is harder than the wrong thing, exhortation will not close the gap.
5. Onboarding and documentation.
6. Stories and rituals.

Changes that depend on one enthusiastic person are not changes; they are that person. Before exit, ask: what happens to this if the sponsor leaves next quarter? If the honest answer is "it stops", the work is not finished.