Is good engineering strategy typically boring?

Jason Yip
2 min readFeb 3, 2024
Tweet from Camille Fournier: “I kind of think writing about engineering strategy is hard because good strategy is pretty boring, and it’s kind of boring to write about. Also, I think when people hear “strategy” they think “innovation”. If you write something interesting, it’s probably wrong. This seems directionally correct, certainly most strategy is synthesis and that point isn’t often made!”
Camille Fournier on X: “@Lethain I kind of think writing about engineering strategy is hard because good strategy is pretty boring, and it’s kind of boring to write about. Also I think when people hear “strategy” they think “innovation”” / X (twitter.com)

The point of strategy is not innovation; the point is addressing a high stakes challenge.

I’m not sure I agree that good strategy needs to be boring per se. I do agree that strategy is not equivalent to innovation. Good strategy is problem solving when faced with a high stakes challenge. If that high stakes challenge can be addressed with something boring and mundane, this is obviously better. Boring and mundane tends to be more reliable. However, given that it’s a high stakes challenge, sometimes innovation is required.

Clarity is more important than inspiration; practicality is more important than audacity.

Treating strategy as innovation leads to an emphasis on inspiration, ambition, audacity. Treating strategy as problem solving leads to an emphasis on clarity and practicality.

Clear and practical is not necessarily boring.

Strategy is not equivalent to doctrine.

Rumelt’s kernel for strategy consists of a diagnosis, guiding policy, and coherent actions. “Guiding policy” refers to the guiding principles that we believe will address the high stakes challenge.

Not every challenge facing an engineering organization is high stakes, per se. Will Larson provides a useful list (a few examples below):

  1. How do we review, merge, deploy, and release code?
  2. What are our approved technologies for new projects?
  3. When and how do we deprecate user-facing functionality?
  4. When and how do we deprecate internal tools?
  5. How do we document our software and process?

I wouldn’t call the policies to answer these questions, “strategies”, so much as “doctrine”, that is, (paraphrasing NATO) “fundamental principles by which we guide our actions in support of objectives”. It does seem that most places use the term “strategy” loosely to refer to responses to both general and high stakes challenges. Given “doctrine” isn’t really popular outside of the military context, I’d propose “general policies” or “operating principles” instead.

Doctrine is more likely to be boring than strategy.

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl