Diagnostic frameworks

Choosing a diagnostic framework

You do not need all fourteen. You need to pick one in five minutes.

A recommended default sequence: run 7S or six-box first as a rapid screen to locate friction. When a specific performance breakdown or deep resistance is flagged, run Burke-Litwin to trace it upstream and determine whether the problem is transformational or transactional. Then choose the intervention family.

McKinsey 7S framework

Created in the late 1970s by Tom Peters and Robert Waterman with Richard Pascale and Anthony Athos, and published in In Search of Excellence. An organization is a web of seven interdependent factors that must be aligned.

Hard elements — explicit, visible, directly manageable:

1. Strategy — the plan to allocate resources and secure advantage.
2. Structure — hierarchy, reporting lines, how roles are grouped.
3. Systems — daily procedures, workflows, IT platforms, budgeting, performance monitoring.

Soft elements — abstract, culture-rooted, harder to change:

4. Shared values (center) — core beliefs and norms that anchor everything else. Originally "superordinate goals".
5. Style — how leadership actually behaves, not what it preaches.
6. Staff — the talent pool, demographics, recruitment, development.
7. Skills — the distinctive capabilities of the workforce and enterprise.

Use when: evaluating internal alignment during strategy execution or a process-heavy transformation.

The core insight: there is no hierarchy among the seven. Change any one and the other six require adjustment. Most failed change happens because leaders pull the hard levers — restructure, announce a strategy — while ignoring the soft ones.

Limitations: a static snapshot; omits the external environment entirely; establishes no cause-and-effect ordering, so it tells you where friction is but not what to fix first.

Health care: Strategy says "integrated, community-first care"; Structure is still organized by acute specialty; Systems still count admissions; Skills and Style are trained for acute episodes. Every S except the strategy points the old way, which is why the strategy does not move. Software: a "you build it, you run it" Strategy against a Structure with a separate operations team and Systems that require an approval board is not an execution failure — it is a misalignment across three S's. Executive: the fastest use is a leadership team rating all seven independently and comparing. Where the executive team's own scores diverge most is where they have not agreed on something they believe they agreed on.

See topics/mckinsey-7s-framework and the questionnaire in Part 11.

Burke-Litwin causal model

W. Warner Burke and George Litwin, 1992. Twelve dimensions arranged as an input-throughput-output cascade with explicit causal direction. The most analytically powerful diagnostic in common use.

Input

1. External environment — markets, regulation, competitors, technology. The ultimate trigger.

Transformational factors — change these and the organization's character changes:

2. Mission and strategy
3. Leadership
4. Organizational culture

Transactional factors — everyday operational mechanisms:

5. Structure
6. Management practices
7. Systems (policies and procedures)
8. Work unit climate
9. Task requirements and individual skills
10. Individual needs and values
11. Motivation

Output

12. Individual and organizational performance, which feeds back to the environment.

The distinction that makes this model worth the effort: transformational vs. transactional. Transformational problems require changes to mission, leadership, or culture. Transactional problems are fixed by adjusting structure, systems, practices, or climate.

Applying a transactional fix to a transformational problem is the most common expensive failure in organizational life. Restructuring to fix a culture problem. Buying a tool to fix a strategy problem. Running a training program to fix a leadership problem. Each of these consumes a year, produces motion, changes nothing, and burns the organization's willingness to try again.

Motivation as mediator. Motivation sits near the bottom as a clearinghouse: how people experience the upstream structure, climate, and management practices determines motivation, which determines performance. Low motivation is therefore almost never treated at the motivation layer.

Use when: performance is declining and you need to find the root cause; during deep cultural change; when previous fixes have not worked.

Limitations: data-heavy and slow; requires significant stakeholder consultation; twelve interacting factors is more than most groups will hold.

Health care: falling performance on a pathway traced upstream typically lands at Management practices and Work unit climate — not at Individual skills, where retraining would have been aimed. Software: delivery slowdown traced upstream usually lands at Structure and Systems (coupling, approval gates), not at Motivation, where the engagement program would have been aimed. Executive: the model's chief executive value is preventing you from authorizing a restructure to solve a leadership problem — including when the leadership problem is yours.

See topics/burke-litwin-causal-model and the questionnaire in Part 11.

Weisbord six-box model

Marvin Weisbord, 1976. The fastest useful diagnostic: six boxes, one question each, plus an environment ring.

1. Purpose — what business are we in? Does agreement hold under pressure?
2. Structure — how do we divide the work? Does it fit the purpose?
3. Relationships — how do we manage conflict between people, between units, and between people and their technology?
4. Rewards — is there an incentive for doing all that needs doing? What is actually rewarded, as opposed to stated?
5. Leadership — does someone keep the boxes in balance?
6. Helpful mechanisms — adequate coordinating technologies: planning, budgeting, measurement, information systems, meetings?

The key move: for each box, examine both the formal system (what the documents say) and the informal system (what actually happens). The gap is the diagnosis. A team with a documented escalation path nobody uses has a Relationships and Leadership problem, not a documentation problem.

Running it: ninety minutes, mixed-level group of 8–12. One flip chart per box, formal on the left, informal on the right. Silent writing first, then round-robin — this prevents the loudest voice anchoring the group. Dot-vote the box with the biggest formal/informal gap.

Health care: Purpose is usually strong — clinicians agree on patient care. Rewards is usually the weak box: activity targets push against the stated purpose, and staff feel the contradiction daily. Software: Helpful mechanisms is the box most often mistaken for the problem ("we need a better tracker") while Structure and Relationships are the real gaps. Ask what the tracker is being asked to compensate for. Executive: the Leadership box asks whether anyone is holding the balance. In many executive teams every member owns a box and nobody owns the fit between them.

See topics/weisbord-six-box-model.

Nadler-Tushman congruence model

David Nadler and Michael Tushman, 1980. Performance comes from the fit between components, not from the quality of any one.

Inputs: environment, resources, history, and strategy.

Transformation process — four components:

1. Work — the tasks, their flow, their uncertainty and interdependence.
2. People — skills, expectations, preferences.
3. Formal organization — structure, processes, systems, metrics, rewards.
4. Informal organization — culture, norms, networks, actual power.

Outputs at system, unit, and individual level.

Diagnosis means examining all six pairwise fits: Work↔People, Work↔Formal, Work↔Informal, People↔Formal, People↔Informal, and Formal↔Informal. The last pair is usually where the diagnosis lands.

The central claim: a world-class component that does not fit the others reduces effectiveness. This is why hiring excellent people into a badly designed system produces frustration rather than performance.

Health care: Work is high-uncertainty and highly interdependent; Formal organization is designed for standardized throughput. That single misfit explains a large share of clinician frustration and workaround behavior. Software: an org adopts autonomous product teams while retaining centralized annual funding and approval. Autonomy is announced; dependency is preserved; teams correctly conclude the change was cosmetic. Executive: a strategy shift toward long-horizon investment, against a quarterly bonus system and a hero culture that rewards firefighting. The strategy is not wrong; it is incongruent.

Limitation worth stating: congruence can mean comfortable stagnation. An organization perfectly aligned to a market that no longer exists is perfectly congruent. Fit is necessary, not sufficient.

See topics/nadler-tushman-congruence-model.

Galbraith star model

Jay Galbraith's framework for organization design. Five policy areas, all controlled by leadership, all of which must point the same way.

1. Strategy — determines the design criteria. Without it, design arguments are unresolvable.
2. Structure — where power sits: specialization, shape (spans and layers), distribution of power, departmentalization (function, product, geography, customer, or matrix).
3. Processes — information and decision flows. Vertical processes (planning, budgeting) allocate resources; lateral processes (teams, integrator roles, networks) coordinate across units without escalation.
4. Rewards — goals, metrics, evaluation, compensation, promotion. The most commonly forgotten point, and the one that silently vetoes the others.
5. People — recruitment, selection, development, rotation.

The governing rule: change one point and you must reconsider the other four. A structure change without matching processes, rewards, and people development produces new boxes, identical behavior, and a claim that "the reorganization didn't work."

Galbraith's cheap lever: lateral processes. Most coordination problems presented as structural can be solved with an explicit integrator role, a standing cross-unit forum, or a shared metric — at a fraction of the cost of a restructure.

Design practice: write three to five design criteria from strategy, including what the design is allowed to sacrifice. Generate two or three genuinely different options. Score each, naming the tradeoff it accepts. Design the lateral processes, rewards, and people moves before announcing the structure. Name what will get worse — every design has a downside, and unnamed downsides become surprises.

Health care: service line vs. professional hierarchy is a classic matrix. A cancer service crossing surgery, oncology, radiology, and nursing works or fails almost entirely on whether the lateral processes and rewards were designed, or whether only the box was drawn. Software: moving to product-aligned teams without changing funding, performance criteria, and career ladders means engineers keep optimizing for their functional manager. Executive: the highest-leverage question in an executive design discussion is "which dimension gets primacy — function, product, geography, or customer?" Refusing to answer produces a matrix in which every conflict escalates to the CEO.

See topics/galbraith-star-model.

Leavitt diamond model

Harold Leavitt, 1965. The ancestor of the later models, and still the fastest check on second-order effects. Four interacting variables: Task, People, Structure, Technology.

For any proposed change, ask what it does to the other three.

Leavitt's own point: change agents choose a favorite point of entry — technologists change technology, HR changes people, executives change structure — and are then surprised by effects at the other three.

Health care: adding a digital triage tool shifts decision authority from experienced nurses to an algorithm (Structure), devalues a skill built over years (People), and changes what triage means (Task). All four move; one was planned. Software: adopting infrastructure as code changes who can deploy and makes some operations roles obsolete while creating new ones. Executive: a shared services consolidation is presented as a Structure and cost change; it is also a Task change for every unit that had local support, and those units will invent shadow capability.

Use it as a 30-minute checklist, not as a serious diagnostic. It has no environment term.

See topics/leavitt-diamond-model.

Maturity models

A maturity model assesses people and culture, processes and structures, and objects and technology against a series of levels of sophistication.

Typical levels:

• Level 0: Not applicable / none
• Level 1: Initiate, investigate, informal, individual
• Level 2: Develop, describe, duplicate, departmental
• Level 3: Standardize, specify, scale, service-oriented
• Level 4: Manage, measure, mainstream, mission-oriented
• Level 5: Orchestrate, optimize, originate, opportunity-oriented

Well-known examples: CMMI, P3M3, TOGAF maturity, agile fluency, the Dreyfus model of skill acquisition, the DDaT capability framework.

Two design approaches. Top-down: fix the levels first, then find characteristics that fit them. Bottom-up: identify characteristics first, then cluster them into levels. Bottom-up produces models that fit your organization; top-down produces models that compare across organizations.

Use when: you need a shared vocabulary for current capability and a direction of travel; when building a career framework or a capability roadmap.

Do not use when: the level becomes the goal. A maturity model is descriptive — it describes levels and their items. It does not prescribe how a team moves between them, and progression up levels does not reliably predict outcomes.

The rebuttals are worth reading. James Bach, Michael Bolton, and Barry O'Reilly have argued that maturity models impose a single linear notion of "better", reward conformance over judgment, and measure the wrong thing. The steelman: a maturity model is a communication device for a capability conversation, and it fails when treated as a scorecard tied to funding.

Health care: clinical competency frameworks and improvement maturity assessments are pervasive; their risk is level-chasing for accreditation rather than capability. Software: engineering maturity models are useful for identifying missing practices and dangerous when used to rank teams. Prefer DORA for delivery capability, which measures outcomes rather than practice conformance. Executive: use maturity models to allocate investment across a portfolio, and never to compare units with different constraints.

See topics/maturity-models and https://github.com/joelparkerhenderson/maturity-models.

Force field analysis

Kurt Lewin's model of the current state as a quasi-stationary equilibrium: a balance between driving forces pushing toward change and restraining forces holding the status quo. The apparent stability is a stalemate.

The central insight: most change efforts add driving force — more urgency, more communication, more incentives, more executive pressure. Removing restraining forces is usually more effective, because added driving force raises tension and provokes counter-pressure. Push harder and you get compliance plus resentment; remove the obstacle and you get movement.

How to run it: state the target state; list and rate driving forces 1–5; list and rate restraining forces; draw opposing arrows sized by rating; for each restraining force ask whether it can be removed, weakened, or converted; only then consider adding driving force. Do this with the people who will be restrained, not about them — the restraining forces list written by leadership alone is nearly always wrong.

Typical restraining forces: loss of status, autonomy, or identity; a reward system that pays for the old behavior; genuine capability gaps nobody will admit; prior failed changes; physical and technical constraints; and workload with no slack. The last is the most common and the least often addressed. People are not resisting; they have no capacity.

Health care: hand hygiene compliance. Driving: audits, posters, professional duty. Restraining: dispensers positioned wrong, gloves slower, skin damage, understaffed shifts. Moving the dispenser beats another poster. Software: trunk-based development. Driving: faster delivery. Restraining: a two-hour test suite, a manual approval board, and one person who owns release and likes owning it. Address the test suite first. Executive: a return-to-office mandate. Driving forces are asserted (collaboration, culture); restraining forces are concrete (commute cost, caregiving, desk shortage, teams hired remote). Mandates that ignore concrete restraints produce attrition rather than presence.

Assign every restraining force a named owner and a date, or the analysis is decorative.

See topics/force-field-analysis.

SWOT and PESTLE

SWOT sorts factors into Strengths and Weaknesses (internal), Opportunities and Threats (external). It is the most widely used and most widely abused strategy tool, because it produces four unranked lists and no decision.

Make it useful with the TOWS step — convert the grid into options:

Discipline rules: cap each quadrant at five forced-ranked items; require evidence and a comparison point for every item; hold the internal/external line firmly; time-stamp it.

PESTLE scans the macro-environment: Political, Economic, Social, Technological, Legal, Environmental. It supplies the external input that 7S omits and Burke-Litwin requires.

Make it decision-grade by adding columns for direction and horizon, impact 1–5, confidence 1–5, and owner. Then plot impact against confidence: high impact and high confidence means plan now; high impact and low confidence means assign a named watcher, a specific indicator, and a threshold that triggers action. That cell is what earns the exercise.

Health care: Political and Legal dominate — funding settlements, workforce regulation, inspection regimes. Social factors like an ageing population have a decade-long, highly predictable impact that is routinely under-planned. Software: Technological and Legal dominate — AI capability shifts, data protection, accessibility law, sector security rules. Executive: use PESTLE to force the board past the current quarter, and specifically to name which external factors would invalidate the strategy. A strategy with no stated invalidation condition is a wish.

See topics/swot-analysis and topics/pestle-analysis.

Cynefin framework

Dave Snowden's sense-making framework helps a group decide what kind of situation they are in, and therefore what response is appropriate.

The central lesson for OD: culture change, leadership behavior, and most organizational change are Complex, and are routinely managed as if they were Complicated.

That mismatch produces detailed multi-year change plans, business cases promising specific culture scores, consultants selling a known answer, and programs that cannot adapt because the plan is the deliverable. The correct response in a complex domain is a portfolio of small, parallel, safe-to-fail experiments with fast feedback.

Safe-to-fail experiment design requires, in advance: a coherent hypothesis; a way to tell early whether to amplify or dampen; a stop condition and a way to reverse; and a blast radius small enough that failure is survivable.

Health care: sepsis protocol compliance is Complicated — analyzable, with a right answer. Improving team communication across a merged department is Complex — try three approaches on three wards and keep what emerges. Software: a production outage begins Chaotic, becomes Complicated during root cause analysis, and the prevention work is Complex. Treating the whole incident as one domain is why post-incident actions often fail to stick. Executive: a merger's legal and financial integration is Complicated; the cultural integration is Complex. Running both under one program plan guarantees the cultural half is judged by the wrong criteria and declared complete when it is not.

See topics/cynefin-framework.

Viable system model

Stafford Beer's cybernetic model specifies five functions any organization must perform to remain viable, recursively at every level.

• System 1 — Operations: the units doing the primary work.
• System 2 — Coordination: damping oscillation between System 1 units. Schedules, standards, shared protocols. Anti-oscillatory, not commanding.
• System 3 — Control: day-to-day management of the whole; resource allocation; the inside and now.
• System 3* — Audit: sporadic direct inspection that bypasses the normal reporting line.
• System 4 — Intelligence: outside and future. Environment scanning, strategy, adaptation.
• System 5 — Policy: identity, purpose, values, and balancing System 3 (now) against System 4 (future).

Requisite variety (Ashby's law): only variety can absorb variety. Organizations fail either by attenuating variety badly (ignoring signals) or by trying to handle all of it centrally (overwhelming the center).

Diagnostic questions: is there a real System 2, or do units coordinate by escalating to a manager? Does System 3 dominate System 4? Does System 3* exist, or does leadership see only filtered reports? Has System 5 collapsed into System 3?

Health care: System 4 is usually weakest — service development crowded out by operational pressure. System 3* exists as audit and inspection but is experienced as punitive, which corrupts the channel. Software: platform teams are System 2 when they provide standards that reduce friction, and become bottlenecks when misused as System 3 control. Naming which is intended settles a lot of arguments. Executive: a board that spends every meeting on this quarter's numbers has collapsed System 5 into System 3. Nobody is holding identity or the now/future balance.

See topics/viable-system-model.

Organizational network analysis

ONA maps the informal structure: who actually goes to whom for information, advice, decisions, and trust.

Different questions produce different networks. The trust network — "who would you tell about a mistake before it became public?" — is usually the smallest, the least like the org chart, and the most predictive of whether a change will take hold.

Roles the map reveals: central connectors (often overloaded, often not senior, often invisible to leadership); brokers who connect otherwise separate clusters and whose departure disconnects the organization; peripheral nodes; silos with dense internal and sparse external ties; and bottlenecks.

Method: prefer survey-based with explicit consent over passive analysis of email, chat, and calendar data. Passive ONA without informed consent is surveillance and will be experienced as such the moment it becomes known.

Ethics rules, non-negotiable: informed consent with genuine opt-out; never report individual-level maps to managers about their reports; report roles and patterns, not named rankings; never use ONA output in performance, promotion, or redundancy decisions.

Health care: ONA reliably finds that a small number of senior nurses are the real information hubs of a ward, outranking the formal hierarchy. Change programs that recruit them succeed; programs routed only through consultants and managers stall. Software: code review networks are a ready-made dataset. One reviewer approving most changes across many repositories is simultaneously a bus-factor risk and a delivery constraint. Executive: six months after an acquisition, ONA shows whether the organizations actually merged. Two dense clusters with three thin links means integration exists only on paper.

See topics/organizational-network-analysis.

Team topologies

Matthew Skelton and Manuel Pais's design vocabulary for knowledge work, built on Conway's law and cognitive load.

Four team types:

1. Stream-aligned — aligned to a single valuable flow of work: a product, a service, a patient pathway. The default; most teams should be this.
2. Enabling — helps stream-aligned teams acquire a capability, then leaves. Explicitly time-boxed. Fails when it becomes a permanent consulting group.
3. Complicated-subsystem — owns a part requiring deep specialism. Justified only when the specialism is genuinely scarce.
4. Platform — provides internal services that reduce cognitive load, consumed as self-service. A platform that gatekeeps is not a platform; it is a bottleneck.

Three interaction modes: Collaboration (high bandwidth, deliberately temporary, for discovery), X-as-a-Service (low bandwidth, the target steady state), and Facilitating (time-boxed helping). Name the mode explicitly for each interacting pair, and name when it should change. Permanent collaboration is a design failure, not a virtue.

Cognitive load is the central constraint. Minimize extraneous load — the accidental complexity of tooling, environments, and process — so capacity goes to the domain. Practical test: ask a team to list everything it is responsible for. If they cannot enumerate it, or the list spans unrelated domains, the boundary is wrong. Adding people does not fix an over-broad boundary.

Health care: an integrated care team around a pathway is stream-aligned; a specialist radiology reporting unit is complicated-subsystem; an improvement team that embeds for eight weeks and withdraws is enabling — and one that never withdraws becomes a permanent dependency. Software: the native domain; the frequent error is a platform team operating as a ticket queue. Executive: ask of every team, which type is it and who decided? Teams with no clear type usually have no clear owner.

See topics/team-topologies.