Strategy resources

One of the hardest parts of learning about engineering strategy is finding useful resources on a topic where so much is kept private. This appendix highlights some of the public resources that I’ve found valuable during my learning experience.

My prior writing

• Writing an engineering strategy is a chapter from The Engineering Executive’s Primer on setting engineering strategy as an executive
• Write five, then synthesize is a chapter from Staff Engineer on driving engineering strategy without executive authority (primarily through documentation)

Books

In addition to my own Staff Engineer and The Engineering Executive’s Primer, both of which have chapters on engineering strategy, related books that I would encourage reading are:

• Architecture Modernization by Nick Tune with Jean-Georges Perrin – covers much of the same topics as Technology Strategy Patterns and The Value Flywheel Effect, but often with more recent examples and references given its later publication date
• Enterprise Architecture as Strategy by Jeanne Ross, Peter Weill, and David Robertson — an interesting read from 2006 on the evolution of software (e.g. IT in that era’s vernacular) maturity within businesses, and deciding among strategies for coupling and integration across business units
• Technology Strategy Patterns by Eben Hewitt – a method-focused book on creating and communicating engineering strategy
• The Phoenix Project by Kim, Behr, and Spafford – a modern retelling of Goldratt’s The Goal, which shows how to model and resolve problems using constraint optimization. Previously, I would not have considered this a strategy book, but as my opinion on what strategy is evolves (mapping plus guiding policies), I think it demonstrates a useful mapping strategy
• The Value Flywheel Effect by Anderson, McCann, and O’Reilly – an introduction to Wardley maps via an exploration of Liberty Mutual’s rationale for serverless
• Wardley Maps by Simon Wardley explains how to use Wardley Maps to understand and improve strategy

Additionally, I’d recommend these general books. They don’t focus on engineering strategy, but I’ve found them quite useful:

• Good Strategy, Bad Strategy by Richard Rumelt – the most helpful strategy book that I have ever read, because it actually provides a usable definition of strategy
• *How Big Things Get Done by Bent Flyvbjerg and Dan Gardner – a fascinating look at why some megaprojects fail so resoundingly and why others succeed under budget and under schedule. Connects to many related topics, such as how benchmarking can help evaluate guiding policies within a strategy
• The Crux by Richard Rumelt – another good book by Richard Rumelt, this one more oriented on how to create strategies and why strategy creation often fails. (And less structurally focused on documenting strategies than Good Strategy, Bad Strategy.)
• Thinking in Systems: A Primer by Donella Meadows – a book on systems thinking, which for a long time was my sole tool for mapping things around me. This is not a software engineering book, but provides a lens into a useful mapping mechanism that you can apply to software and software development (Why limiting work-in-progress works is one example of me using systems thinking to model a software system)

Case studies

Every discussion of engineering strategy includes a weary remark about how few strategies are publicly documented. Acknowledging that concern, some case studies that I’ve found helpful:

• Magnitudes of exploration documented a public version of Stripe’s Engineering strategy
• The Value Flywheel Effect (linked under “Books” header above) is a good case study of Liberty Mutual’s engineering strategy, and additionally includes case studies for A Cloud Guru, Workgrid, and BBC
• Run less software by Rich Archbold – a fantastic writeup of a cornerstone of Intercom’s engineering strategy
• How Big Technical Changes Happen at Slack by Adams and Rodgers – this is not quite Slack’s engineering strategy, but it has many components of their engineering strategy within it
• The difficult teenage years: Setting tech strategy after a launch by Anna Shipman – a look at FT’s engineering strategy, particularly one that wasn’t really defined until somewhat late in the lifecycle (which is an extremely common occurrence, even if we don’t admit it)

A few more resources that are either case study-ish or engineering-ish, so they don’t quite fit in the above list, but are nonetheless relevant reads:

• BoringTechnology.club by Dan McKinley – a guiding principle that many engineering strategies include
• GitLab Strategy – ok, it’s actually the GitLab company strategy. but given they’re a technology company that builds technology for technologists, it’s an interesting read despite being at a slightly higher altitude than an engineering strategy

The internet is an unruly place, and I’m sure by the time that you’re reading this, many more excellent writeups will exist as well.