Book Review: \"Good Strategy / Bad Strategy\" by Richard Rumelt

I first read "Good Strategy / Bad Strategy" by Richard Rumelt in 2019. I've re-read it twice since. It's the kind of book that gets sharper every time because you keep recognizing its patterns in your own decisions — especially the bad ones.

Rumelt's core argument is deceptively simple: most of what passes for strategy is not strategy at all. It's goals dressed up in aspirational language. It's vision statements on a slide deck. It's a list of priorities so long that nothing is actually prioritized. And in the startup world, where "strategy" gets thrown around in every board meeting and all-hands, this problem is endemic.

If you lead an engineering team, manage a product, or run a startup, this book will change how you think about decisions. Here's why.

The Kernel of Good Strategy

Rumelt defines good strategy as having three parts — what he calls the kernel:

1. Diagnosis: What's the real challenge?

The diagnosis is an honest assessment of the situation. Not what you wish were true. The actual problem.

I've sat in strategy meetings where the diagnosis was "we need to grow faster." That's not a diagnosis — that's a desire. A real diagnosis: "Our trial-to-paid conversion is 4%, half the industry benchmark, because onboarding drops 60% of users before they see core value."

In engineering terms, a good diagnosis: "Our deployment cycle takes 3 weeks because we have no automated testing, a manual QA process, and a single-branch release strategy." Specific. Actionable. Names the actual constraint.

A bad diagnosis: "We need to ship faster." Everyone nods. Nobody knows what to do.

2. Guiding Policy: The approach

The guiding policy is the overall approach to the diagnosed challenge. Not a specific action — the direction that constrains your actions.

Rumelt's analogy: a guiding policy is like a guardrail on a mountain road. It doesn't tell you where to steer, but it keeps you from driving off the cliff.

For the deployment example: "We will invest in automation to make deployments self-service and eliminate manual coordination." That doesn't specify which CI/CD tool or how you handle migrations. It sets direction.

The key characteristic of a good guiding policy is that it makes choices. It says "we will do this, not that." If your "strategy" doesn't rule anything out, it's not a strategy.

3. Coherent Action: Coordinated steps

The third element is a set of coordinated actions that implement the guiding policy. Not a wish list. Not 47 initiatives. A focused set of moves that reinforce each other.

For our deployment problem: (1) introduce feature flags to decouple deployment from release, (2) set up CI with automated test suites for the two highest-traffic services, (3) move to trunk-based development. These three moves are coherent — each one supports the others, and together they address the diagnosed problem.

Coherence is what separates strategy from a to-do list. A list of unrelated improvement projects isn't a strategy. A set of mutually reinforcing actions aimed at a specific challenge is.

Bad Strategy Is Everywhere

Rumelt's taxonomy of bad strategy hit me like a freight train because I recognized every pattern in companies I'd worked with:

Fluff. Inflated language that says nothing. "We will leverage our synergistic platform capabilities to unlock value across the ecosystem." Strip away the jargon and there's nothing underneath.

Mistaking goals for strategy. "Our strategy is to be the market leader in developer tooling." That's a goal, not a strategy. Where's the diagnosis? Where's the guiding policy?

Not making choices. The most damaging pattern. A company that lists 12 "strategic priorities" has zero strategic priorities. Strategy means deciding what you will NOT do. If your engineering team is simultaneously rewriting the backend, building three features, migrating to a new cloud, and reducing tech debt by 40%, you have a fantasy, not a strategy.

Ignoring the challenge. Jumping straight to goals and actions without identifying what's actually hard. The result is generic playbooks that don't address specific constraints.

Why Most OKRs Are Not Strategy

This is where Rumelt's framework really stings for the tech world. OKRs — Objectives and Key Results — are excellent execution tools. But they are not strategy, and treating them as if they are is one of the most common mistakes I see.

An OKR like "Increase platform reliability to 99.95% uptime" is an objective with a measurable result. It tells you what success looks like. It does not tell you:

• Why reliability is the most important challenge right now (diagnosis)
• What approach you'll take to improve it (guiding policy)
• Which specific, coordinated actions you'll execute (coherent action)

OKRs sit downstream of strategy. They operationalize it. But if you set OKRs without a strategy, you end up with a collection of measurable goals that don't connect to each other and don't address your core challenge. Every team hits their OKRs and the company still doesn't move forward, because nobody asked the hard question: "What is the most important problem we need to solve, and what are we going to do about it?"

Applying Rumelt to Engineering Decisions

Here's where the book becomes intensely practical for anyone leading engineering:

Architecture decisions. Should you rewrite or refactor? Rumelt's framework forces you to start with the diagnosis. What is the actual problem? If it's "the monolith is slow to deploy," the guiding policy might be to extract the highest-churn modules into services — not a full rewrite. The coherent actions follow: identify the top 3 modules by change frequency, define service boundaries, implement one extraction as a proof of concept.

Build vs. buy. "We build everything in-house" isn't a strategy — it's a default. A good diagnosis: "We spend 30% of engineering time maintaining commodity infrastructure." Guiding policy: "Buy managed services for non-differentiators; build only where we have unique advantage." Now every future decision has a filter.

Team scaling. "Hire 20 engineers" is a goal. The strategy version: "Delivery speed halved because two teams are stepping on each other in a shared codebase." Guiding policy: "Establish domain ownership before adding headcount." Coherent actions: define bounded contexts, split the codebase, create team APIs, then hire into the new structure.

The Hard Part: Making Choices

The most uncomfortable truth in this book is that good strategy requires saying no. Not "not right now." No.

If you're a startup with 8 engineers and you're trying to build a mobile app, a web app, an API platform, and an AI feature simultaneously, you don't have a strategy. You have FOMO. Rumelt would tell you to diagnose your actual competitive advantage, pick the one thing that matters most, and execute it with coherence.

That means telling someone — a co-founder, a board member, a customer — that you're not going to do the thing they want. That's why bad strategy is so much more common than good strategy. Bad strategy lets you avoid conflict. Good strategy demands it.

At Conectia, we see this pattern constantly with the startups we work with. Founders come to us needing engineers, but the real conversation often starts with "what should we build first?" When we embed senior engineers into a team, they don't just write code — they ask the diagnostic questions that sharpen strategy. What's the real bottleneck? What should we stop doing? Where does adding capacity actually solve the problem vs. just making the chaos faster?

That's what experienced engineers bring: not just execution, but judgment about what to execute.

---

Building your engineering team and want people who think strategically, not just write code? Talk to a CTO — we embed senior LATAM engineers who ask the right questions before writing the first line.