Introduction

Organizational development is a planned, systematic, evidence-informed approach to improving an organization's capability, effectiveness, and long-term health, through the alignment of its strategy, structure, culture, and people.

It draws on psychology, sociology, systems theory, and improvement science. Its distinguishing commitment is that organizations are human systems: they are changed by working with the people in them, not by issuing instructions to them.

Who this is for

This guide is written for knowledge workers in three settings.

• Health care: doctors, nurses, allied health professionals, administrators, clinical directors, improvement leads.
• Software: designers, developers, testers, architects, engineering managers, product leaders.
• Senior executives: CEO, CIO, CTO, CHRO, and their equivalents in public and non-profit organizations.

These settings look different and share more than they differ. All three are characterized by:

• High autonomy. The work cannot be fully specified in advance, and the person doing it knows more about it than their manager does.
• High interdependence. Individual excellence is insufficient; outcomes are produced by handoffs, coordination, and shared systems.
• High consequence of error, whether measured in harm, in money, or in reputation.
• Professional identity that outranks organizational identity. A physician is a physician before they are an employee of this hospital. A staff engineer is an engineer before they are an employee of this firm. This is the single most important fact for anyone attempting change in these settings: change that threatens professional judgment will be resisted by competent, committed, well-intentioned people, and no amount of communication will resolve it.

Wherever a framework is explained below, examples show how it lands in each of the three settings.

How to use this guide

• If you have a problem and need a diagnosis, start with Part 2, then Part 3.
• If you have a diagnosis and need an intervention, go to Part 7.
• If a change is failing and you don't know why, go to Part 10, then Part 4.
• If you need to justify or evaluate a program, go to Part 8.
• If you are new to the field, read Parts 1 and 2, then skim the rest.

Using this guide with Claude Code

This repository ships two Claude Code skills, in skills/, that put the guide to work inside an agent session instead of leaving it as prose to search by hand.

• organizational-development-skill — for anyone applying the guide to a real situation. It navigates to the right framework family, opens the specific topic file rather than answering from memory, leads with the evidence rating unprompted, and returns the example matched to the reader's audience: health care, software, or executive.
• organizational-development-maintainer-skill — for anyone extending or correcting the guide itself. It routes a task to the matching playbook in AGENTS/, enforces the five invariants, and runs bin/audit before and after an edit.

Copy either folder into .claude/skills/ in your own project, or point Claude Code at this repository directly.

The ten things that matter most

If you read nothing else:

1. Diagnose before you intervene. The most expensive error in the field is selecting an intervention — a reorganization, an offsite, a values launch, a tool rollout — before establishing what is wrong.

2. Distinguish transformational from transactional problems. A structural fix will not solve a cultural problem, and a culture workshop will not solve a queueing problem. See Burke-Litwin.

3. What looks like a people problem is usually a situation problem. Before attributing failure to attitude or capability, examine the workload, the incentives, the tooling, and the decision rights.

4. Remove restraining forces before adding driving force. Pushing harder raises tension and provokes counter-pressure. Removing the obstacle is cheaper and more durable. See force field analysis.

5. Psychological safety is the highest-leverage team variable, and it is destroyed by one badly handled piece of bad news. See psychological safety.

6. Feed data back to the people it came from, before you report it upward. This is both an ethical commitment and the mechanism by which data produces change.

7. Never run a survey you cannot act on. An unactioned survey leaves trust lower than before you asked.

8. Expect the performance dip. Every change that requires new competence makes people temporarily worse at their jobs. Programs are abandoned in the dip, one week before they would have worked.

9. Measure with a baseline, a prediction, and a balancing measure, or you are not measuring, you are narrating.

10. Not all models are equally supported. Psychological safety, motivation theory, and work design have strong evidence. Kotter, ADKAR, Tuckman, and Kübler-Ross do not. Weakly supported models can still be good vocabulary; they are not good predictions.