Good Strategy vs. Bad Strategy
The word "strategy" is one of the most abused words in business. It is often used to mean a vague list of lofty goals: "Our strategy is to be the market leader in developer experience." This is not a strategy — it's a wish list. It tells you nothing about what you will do or, more importantly, what you will not do.
Richard Rumelt, a professor at UCLA Anderson School of Management, spent decades studying why some strategies succeed and others fail. His central finding: most "strategies" are bad because they avoid making hard choices. He calls this "fluff" — high-sounding language that creates the illusion of strategic thinking without the substance.
Real strategy, Rumelt argues, requires a specific structure he calls the "kernel" — three interlocking components that force you to diagnose the real problem, commit to an approach, and take coordinated action.
The Three Parts of a Strategy Kernel
1. A Diagnosis
What is the fundamental challenge you are facing? Not a symptom — the root cause. A good diagnosis is specific enough to be falsifiable. "We are losing market share" is a symptom. "Our deployment velocity has dropped 50% year-over-year because our monolithic codebase has accumulated 8 years of technical debt, making it impossible to ship features faster than our competitors" is a diagnosis.
Example:
"Our monolithic architecture has become too complex for any single team to understand. As a result, deployment velocity has dropped 50% year-over-year, and we are losing market share to competitors who ship features 3x faster."
2. A Guiding Policy
What is your overall approach to dealing with this challenge? This is the strategic "guardrail" — it rules out a large number of possible actions and focuses effort. It does not specify every step, but it makes clear what kind of steps are acceptable.
Example:
"We will decompose the monolith by decoupling services along business domain boundaries, prioritizing deployment speed over feature parity during the transition. We will not attempt a big-bang rewrite."
3. Coherent Actions
What are the concrete, coordinated steps that implement the guiding policy? The word "coherent" is critical — the actions must reinforce each other. A list of unrelated initiatives is not a strategy; it's a backlog.
Example:
- Establish a dedicated "User Service" team by Q2, staffed from the existing monolith team.
- Freeze new feature development on the monolith's user module starting March 1.
- Migrate 10% of production traffic to the new User Service by Q3, with a circuit breaker to fall back to the monolith.
- Decommission the monolith's user module once the new service handles 100% of traffic for 30 consecutive days.
Notice how these actions are coherent: each one supports the guiding policy of domain-based decomposition without a big-bang rewrite. You couldn't do action 3 without action 1. You wouldn't do action 4 without action 3. That interdependence is what makes it a strategy rather than a to-do list.
The "Fluff" Test
Before publishing a strategy document, apply this test: replace every abstract noun with a concrete one. If the document collapses into meaninglessness, it was fluff. "We will leverage synergies to optimize our platform ecosystem" fails the test. "We will reduce the number of internal APIs from 47 to 12 by consolidating duplicate services" passes it.
Staff+ engineering interviews frequently include a question like: "Walk me through how you'd define a technical strategy for your team." The weak answer lists goals. The strong answer uses the kernel structure: "First I'd diagnose the specific constraint holding us back — not just 'we're slow' but why we're slow. Then I'd define a guiding policy that rules out certain approaches. Then I'd define 3–5 coherent actions that implement that policy." Naming Rumelt's framework signals strategic maturity.