Skip to main content

Diagnosis, Guiding Policy, Coherent Action (Rumelt)

What This Concept Is​

Richard Rumelt, in Good Strategy/Bad Strategy, defines strategy precisely. The kernel of a strategy has three components in this exact order:

  1. Diagnosis. A clear-eyed description of the nature of the challenge. Names the crux: what is actually hard, what is the binding constraint, where the system is failing. Not a list of problems. A theory of the problem.
  2. Guiding policy. The overall approach chosen to cope with the challenge. Rules out whole classes of action. Chooses an angle of attack. Not a vision statement. A constraint on future moves.
  3. Coherent action. The set of concrete, mutually reinforcing moves that follow from the guiding policy. Resources committed, tradeoffs made, projects killed. Not a wish list. Actions that would not make sense under a different guiding policy.

A strategy is bad when any of these is missing or when the three do not derive from each other. Most documents labeled "strategy" are a vague ambition followed by a wish list.

Why It Matters Here​

Engineering strategy documents without this structure produce two predictable failures:

  • Wish-list strategy. A list of good-sounding initiatives with no diagnosis. Everything is a priority; nothing is actually prioritized; the first budget cut reveals the absence of a ranking principle.
  • Slogan strategy. "We will be customer-obsessed and move fast." No diagnosis, no guiding policy, no action. Testable with: rewrite the document for a different company in the same sentence. If it still makes sense, it is not a strategy.

Learning Rumelt's kernel is the fastest way to stop producing either. Every engineering strategy you write or review from here on should be checked against the three-part structure.

Concrete Example​

Problem: "Our platform team is not shipping. Three teams depend on them and are blocked."

Bad strategy (wish list). "We will invest in the platform team. Priorities: performance, reliability, developer experience, migration support, documentation, and onboarding."

Rumelt-structured strategy.

  • Diagnosis. The platform team ships slowly because 60% of their time goes to one-off consulting requests from product teams. The crux is not staffing; it is that the team is operating as a help desk, not a platform.
  • Guiding policy. We will shift the platform team from reactive consulting to a paved-road model. Product teams self-serve via golden paths; the platform team is unblocked from unplanned interruptions.
  • Coherent action.
    1. Publish a paved-road catalog by end of Q2.
    2. Route platform questions through a tier-1 rotation held by product teams for 30 days before platform eng sees them.
    3. Kill the "embedded platform engineer" program (it caused the interruption pattern).
    4. Add a monthly "paved-road adoption" metric to the team's review.

Notice: the four actions do not make sense under a different guiding policy (e.g., "invest more in the platform team"). They derive.

Common Confusion / Misconception​

"Diagnosis means listing the problems." No. A diagnosis names the problem - the crux. A list of ten problems is often evidence that the diagnosis has not been done yet. Rumelt calls this "soup": lots of ingredients, no theory of what is actually wrong.

"Guiding policy is the vision statement." No. Vision is where you want to end up. Guiding policy is how you will get there and, more importantly, what you will not do on the way.

"Coherent action is a to-do list." No. A to-do list has no guiding-policy backing. Coherent action must be derivable from the policy - that is what "coherent" means. If two actions undercut each other, the set is not coherent.

"Strategy means ambition." No. Ambition without diagnosis is daydream. Many "bold" strategies are bad strategies.

"Engineering strategy is just a roadmap with a nicer cover." No. A roadmap is a schedule of work. A strategy explains why that work and not some other work. If you can swap the roadmap for a different roadmap without changing the strategy document, the document has no real strategy in it.

"The kernel is enough." Diagnosis, guiding policy, and coherent action are the kernel of a strategy - necessary but not sufficient. A complete strategy document adds scope, success signals, and review triggers around the kernel. The kernel is what keeps it honest.

Diagnosis vs Analysis vs Storytelling​

Three activities are frequently mistaken for diagnosis and each produces a different failure mode:

  • Analysis is collecting and ordering facts. "Latency is 2x our target; error budget is exhausted; team velocity is down." Analysis is input to diagnosis, not diagnosis. A report that stops at analysis names no crux.
  • Storytelling is narrating causation. "We missed the last launch because the platform team was under-staffed and morale was low." Storytelling is plausible and often half-true; it is diagnosis only if the named cause is also the binding constraint you could move.
  • Diagnosis names the crux: the single load-bearing fact that, if flipped, would resolve or reframe the problem. Rumelt's heuristic: the diagnosis is correct if removing it makes the strategy incoherent.

Senior engineers who stop at analysis produce reports. Those who stop at storytelling produce narratives. Only diagnosis enables a guiding policy. The test: can you write the guiding policy without the diagnosis you named? If yes, the diagnosis was decorative.

How To Use It​

When drafting or reviewing a strategy, apply this test in order:

  1. Find the diagnosis. If there is none, stop. The document is not ready.
  2. Check the guiding policy rules something out. If it rules nothing out, it is a slogan, not a policy.
  3. Check each action against the policy. If an action would still appear under a different policy, it is contamination.
  4. Check the actions for mutual reinforcement. Do they make each other more likely to succeed?

Check Yourself​

  1. State Rumelt's three kernel components in order, with one sentence each, without looking.
  2. Take a "strategy" document you have seen recently. Which of the three parts is strongest? Which is missing?
  3. Why is "we will be customer-obsessed" a slogan rather than a guiding policy?

A Worked Counter-Example: Strategy That Sounds Right and Is Not​

Consider this widely-circulated "strategy" from a real late-stage startup's all-hands deck:

"In 2026 we will double down on developer productivity. We will invest in platform, ship faster, and delight our customers. Every team will own quality. We will move with urgency."

Applied to Rumelt's test: no diagnosis (what is actually wrong? nothing is named), no guiding policy (what is being ruled out? nothing), and the "actions" are slogans, not commitments. It is entirely substitutable - paste "At ACME Corp" at the top and it fits any engineering organization.

The honest rewrite would start: "Our platform team ships one third as fast as comparable teams because 60% of its time is consumed by reactive consulting. Our diagnosis is that the intake model is wrong, not the staffing. Our guiding policy is paved-road-over-consulting - we will stop providing embedded integrations." That is a strategy. The first version is a pep talk.

Staff+ engineers learn to spot the pep-talk shape in about six months of practice and to refuse to execute against it until someone does the kernel work. Refusing gracefully is a separate skill (Concept 9) but the diagnosis that the artifact is empty comes first.

Mini Drill or Application​

Pick one real problem your team faces. Draft a one-page strategy with three sections:

  • Diagnosis (100 words): name the crux, not the symptoms.
  • Guiding policy (80 words): state the angle and what it rules out.
  • Coherent action (200 words): 3-5 actions that do not make sense under a different policy.

Then pressure-test it: rewrite the guiding policy as its opposite. Do the actions still fit? If yes, the actions were decorative. Rewrite them.

Extension drill: take any "strategy" deck you have been shown in the last six months. Count the diagnoses (how many of the document's claims are about "what is actually hard"). If the count is zero, the document is not a strategy regardless of its title. Practice rewriting the first page as a proper kernel and notice how much of the original survives. (Usually ~10%.)

Transfer / Where This Shows Up Later​

Rumelt's kernel is the spine that the rest of this cluster wraps:

  • Strategy documents (Concept 5). Diagnosis / guiding policy / coherent action are the core of the strategy doc; scope, anti-scope, tradeoffs, and review triggers are the scaffolding around that core.
  • Roadmaps (Concept 6). The coherent-action set is where roadmap items come from. Roadmap items with no parent guiding policy are the symptom of a missing strategy upstream.
  • Influence (Concepts 7-9). RFCs and ADRs cite the guiding policy; stakeholder walks are easier when stakeholders can see what is being ruled out; disagree-and-commit is healthier when the decision is anchored in a named diagnosis.
  • Communication (Concepts 10-12). An exec summary is a one-paragraph Rumelt kernel. An architectural story is a kernel plus consequences.
  • Personal strategy (Concept 15). Your own career planning applies the same kernel: diagnose where you actually are, pick a guiding policy for the next 18 months, name the 3-5 actions that derive from it.
  • Across Semester 8. M1's interview preparation is a personal Rumelt exercise (diagnose weakest dimension, policy, 3 practice moves). M2 decomposition decisions use it at the architecture level. Semester 10 M5 on staff+ careers returns to the kernel for long-horizon planning.

Read This Only If Stuck​

No local book chunk covers Rumelt's kernel directly; the closest local chunks frame the underlying thinking style: