Part 1
Foundations
What organizational development is
Working definition:
Organizational development is a planned, system-wide effort, managed from the top, to increase organizational effectiveness and health through planned > interventions in the organization's processes, using behavioral science > knowledge.
Richard Beckhard's classic definition, still the clearest. Four things follow from it:
- Planned. OD is deliberate, not the accumulation of ad hoc management decisions.
- System-wide. The unit of analysis is the system, even when the intervention is local. An improvement in one unit that exports harm to another is not an improvement.
- Effectiveness and health. Both. A high-performing organization that burns its people is not developed; it is borrowing.
- Behavioral science knowledge. OD claims an evidence base. It is obliged to behave as if that claim is true. See evidence-based practice.
The core distinction that runs through the whole field:
- Organization design is structural: operating models, reporting lines, decision rights, processes, metrics. It answers "how is the work divided and coordinated?"
- Organization development is behavioral: values, norms, team dynamics, ways of working, capability. It answers "how do people here actually behave, and what would make them able to do better?"
Both are necessary. Programs that do only design produce new boxes and identical behavior. Programs that do only development produce goodwill that dissipates against unchanged structural constraints.
What organizational development is not
| OD is not | What that is | Where they differ |
|---|---|---|
| Change management | Moving a defined population from state A to state B | Change management assumes the destination is known. OD builds the capacity to adapt, including to destinations not yet identified. |
| Organization design | Structure, decision rights, operating model | Design changes the box diagram; development changes what happens inside it. |
| HR | Employment lifecycle: hiring, pay, relations, compliance | OD often sits in HR and is not HR. HR administers the system; OD changes it. |
| Learning and development | Building individual skills | L&D is one OD intervention among many, and is the intervention most often misapplied to non-skill problems. |
| Process improvement | Lean, six sigma, value stream mapping | Technostructural interventions are part of OD's toolkit; OD additionally addresses culture, leadership, and human process. |
| Culture programs | Values statements, engagement campaigns | Values statements are the weakest culture lever available. See how to actually change culture. |
The training reflex. The most common misapplication in all three audiences: a problem is identified, and the response is training. Training is the correct response only when the barrier is genuinely a knowledge gap. It is the wrong response when the barrier is desire, ability under real conditions, incentives, workload, or structure — which it usually is. See ADKAR, whose main practical value is identifying exactly this.
The values and ethics of OD
OD is unusual in having an explicit value base, and the values create real conflicts rather than resolving them.
Core values of the tradition:
- Humanism: people are ends, not merely means to productivity.
- Participation: those affected help shape the change.
- Transparency: data is fed back to those it came from.
- Client self-sufficiency: the goal is a system that no longer needs you.
- Whole-system view: harm exported elsewhere is not improvement.
The standing conflicts, which you should expect rather than be surprised by:
Who is the client? The sponsor pays; the workforce is affected. When findings implicate the sponsor, the only thing protecting the work is the contract you made at entry.
Consent under power asymmetry. An employee invited to a "voluntary" session by their own director has not freely consented. Design real opt-outs and never report participation lists.
Surveys as extraction. Asking about problems you have no intent or authority to fix is harmful, and reliably lowers trust below the pre-survey baseline.
Confidentiality vs. duty to disclose. Patient safety risk, harassment, fraud, and regulatory breach cannot be held in confidence. State the exceptions before every interview, not after one occurs.
Anonymity that is not anonymous. Demographic cuts on small teams re-identify people. Set a minimum reporting threshold — commonly five to ten responses — and hold it when an executive pushes.
Manufactured consent. Consultation theater — sessions run after the decision is made — does more damage than not consulting, because it teaches people that participation is fake.
Data handling: collect the minimum, separate identifiers early, state and honor retention periods, know your regime (GDPR/UK GDPR, HIPAA, works council and union agreements), and check processing terms before putting employee free text into any external tool.
The practical test. Before acting, ask: would I be comfortable if every participant read the full contract, the raw method, and the report to the sponsor? If not, change something — usually the contract.
See topics/od-ethics.
Evidence-based practice
Evidence-based management means combining four sources of evidence, none sufficient alone:
- Scientific evidence — research findings, preferably meta-analyses.
- Organizational evidence — your own data: turnover, incidents, cycle time, survey trends.
- Stakeholder evidence — the values, concerns, and knowledge of those affected.
- Practitioner expertise — your judgment, treated as evidence to check rather than as authority.
The six steps: Ask an answerable question, Acquire evidence, Appraise its quality, Aggregate the sources, Apply, Assess the result.
Evidence strength across popular models. Practitioners are rarely told which of their tools are supported. A rough guide, used throughout this document:
| Model | Evidence | Note |
|---|---|---|
| Psychological safety | Strong | Large literature; robust link to learning and error reporting |
| Self-determination theory | Strong | Decades of experimental support |
| Job characteristics model | Strong | Meta-analytically supported |
| Goal setting theory | Strong | Among the best-supported findings in the field |
| Rogers diffusion attributes | Strong | Hundreds of empirical diffusion studies |
| Westrum typology | Good | Validated and linked to delivery and organizational performance |
| Transformational leadership | Moderate | Real effects, contested measurement |
| Kotter 8-step | Weak | Practitioner-derived; rarely tested as a whole |
| ADKAR | Weak | Useful checklist; little independent validation |
| Tuckman stages | Weak | Memorable; groups do not reliably proceed in order |
| Lencioni five dysfunctions | Weak | A business fable, not research |
| Situational leadership | Weak | Style-matching prescriptions repeatedly unconfirmed |
| Maturity models | Weak | Descriptive; level progression rarely predicts outcomes |
| Herzberg two-factor | Mixed | Two-factor structure likely a method artifact |
| Maslow hierarchy | Weak | Categories plausible; strict ordering unsupported |
| Hofstede dimensions | Contested | Influential; criticized on method and level of analysis |
| Kübler-Ross applied to change | Very weak | Derived from bereavement; never validated for organizations |
| Learning styles | Refuted | Do not build interventions on this |
| MBTI for selection or development | Weak | Low test-retest reliability; avoid for consequential decisions |
Weak evidence does not mean useless. A weakly supported model can be a good communication device: a shared vocabulary that helps a group discuss a real problem. The error is treating it as a causal claim and predicting outcomes from it.
Practical habits:
- Ask "what would change my mind?" before launching an intervention.
- Distinguish "no evidence of effect" from "evidence of no effect".
- Beware the consultant's citation chain: a claim repeated in ten blog posts that cite each other is one claim, not ten.
- Beware benchmark envy: "Google does it" is not evidence it will work at a 200-bed district hospital.
Health care: clinicians already practice evidence-based medicine and will hold management claims to the same standard. This is an advantage — bring the effect size. Software: engineers respond to instrumented internal evidence far more than to external frameworks; show the pipeline data. Executive: the highest-value use is challenging an expensive committed decision with "what evidence would tell us this worked?"
See topics/evidence-based-practice.
Systems thinking
Systems thinking explains recurring behavior by structure rather than by character. Core concepts:
- Stocks and flows. Stocks accumulate — backlog, staff, trust, technical debt — and change slowly. Most impatience in change programs is impatience with a stock.
- Reinforcing loops amplify; balancing loops resist and seek a goal. Most resistance to change is a balancing loop doing its job, protecting something the system values.
- Delays cause overshoot, oscillation, and abandonment just before success.
- Leverage points. Donella Meadows ranked them: low leverage is parameters and targets; high leverage is rules, information flows, goals, and paradigm. Most management attention goes to the lowest-leverage end.
System archetypes worth recognizing:
| Archetype | Pattern | Example |
|---|---|---|
| Fixes that fail | Quick fix works short term, worsens long term | Adding people to a late project |
| Shifting the burden | Symptomatic fix atrophies fundamental capability | Contractors instead of internal skill |
| Limits to growth | Reinforcing engine hits a constraint | Growth stalls not because the engine broke |
| Tragedy of the commons | Shared resource depleted by rational local use | Platform team consumed by every team's urgent request |
| Success to the successful | Resources flow to the current winner regardless of merit | Budget follows last year's budget |
| Escalation | Two parties respond to each other, both lose | Two departments each adding approval gates |
| Eroding goals | Standards lowered to match performance | The four-hour target quietly becomes six |
Health care: emergency department crowding is not caused by slow triage; it is a flow problem in which ward discharge timing sets the ceiling on admission. Optimizing the front door while the back door is blocked is a textbook fix that fails. Software: "we need more developers" against a codebase whose review and deployment path is the constraint is shifting the burden — added developers increase contention on the constraint. Executive: annual budget cycles create a reinforcing loop where units spend to protect next year's allocation. The behavior is rational; the rule produces it, and changing the rule is higher leverage than exhorting restraint.
Sociotechnical systems and Conway's law
Two structural findings that predict a great deal of organizational behavior.
Sociotechnical systems. From the Tavistock Institute's 1950s coal mining studies: a new mechanized method raised technical efficiency, destroyed the small self-managing teams the old method depended on, and productivity fell. The principle is joint optimization — the social and technical systems must be designed together, or optimizing either alone degrades the whole.
Related principles: minimal critical specification (specify no more than necessary), variance control at source (handle problems where they arise), multifunctional workers (redundancy of function beats redundancy of parts), and boundary location (draw team boundaries around whole tasks).
Every digital transformation is a sociotechnical intervention whether or not it is framed as one. Electronic health records, CI/CD pipelines, workflow tools, and AI assistants all reallocate authority, attention, and status along with tasks. Deployments that treat this as a training problem fail predictably.
Conway's law. Melvin Conway, 1967: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
The system you build mirrors how your teams talk. The inverse Conway maneuver exploits this: choose the architecture you want, then organize teams to match. A reorganization is an architecture decision whether or not anyone in the room knows it.
Signals Conway's law is operating: a module no team owns; an API shaped like a reporting line rather than a domain; a coordination layer that exists only to bridge two org units; integration bugs concentrated at team boundaries.
Health care: a patient pathway crossing four departments produces four records, four handovers, and four opportunities for information loss — the pathway mirrors the departments, not the patient. Integrated care teams are an inverse Conway maneuver on clinical services. Software: microservice boundaries that do not match team boundaries produce either constant cross-team coordination or de facto shared ownership. Executive: a product customers experience as fragmented was built by units that do not talk; adding a "customer experience" function adds a fifth silo.