Notes on Technology Strategy Patterns
Technology Strategy Patterns by Eben Hewitt is a methods-based approach to engineering strategy, with a particular focus on the methods wielded by McKinsey consultants, software engineering mainstays like Thoughtworks, and philosophy. A valuable read for anyone looking to build their own theory of engineering strategy.
In June, 2019, I bought a copy of Technology Strategy Patterns by Eben Hewiit. A the time, I was trying to argue against a large, proposed migration to Java at Stripe, collecting thoughts that became Reclaim unreasonable software. Skimming through Patterns, I didn’t quite find what I was looking for, and I largely forgot about it for the next few years.
Fast-forwarding to 2023, I’ve been spending more time thinking about engineering strategy, including reading The Value Flywheel Effect for its view on engineering strategy, and I remembered Patterns. Well, I remembered that Patterns existed, and that I hadn’t really read it the last time I picked up a copy, so this time I decided to dig into it a bit deeper.
If I had to quote one section of thise book to capture its core essence, it would be Hewitt talking about how to write slides to explain your strategy:
Execute all the applicable creation patterns of this book…
Collect your output from doing so…
Do a MergeSort of the output…
Now you have a terrific strategy
This reminds me Rumelt’s Good Strategy, Bad Strategy, where a sufficiently good diagnosis leads to a very boring set of guiding policies. If you sufficiently understand any problem, then the solutions for addressng it tend to become self-evident. It also reminds me of a belief Wardley mapping, which is that the process of mapping reveals the structure of your circumstances and how strategy might improve it.
Patterns, like many software books leans heavily on the concept of patterns established in Christopher Alexander’s A Pattern Language, with a particular focus on patterns used by McKinsey consultants, Thoughtworks adjacent technology ideas like running a technology radar, and Hewitt’s personal experience.
If you believe that methods for exploring your situation lead to strategy–which most writers on strategy seem to have shared conviction around–then these methods are the foundation of strategy, and they are the part of the book that resonates most with me.
There are certainly other aspects that resonated as well:
- Explicitly decoupling development of strategy from presentation of strategy, and having a structured approach for how to do different kinds of strategy presentations (strong McKinsey vibe here, in the best possible way, of having clear patterns for communication)
- Broad set of tools for exploring your situation: MECE, logic trees, PESTEL, SWOT, and so many more. These are not the mechanisms I have generally used, which is why I find them so interesting
- Explicit acknowledgement of different contexts (world, industry, corporate and department) and how you have to think about all of these in different ways to think about different altitudes of strategy
- A great summary of an architect’s primary goals:
- Contain entropy
- Specify the non-functional requirements
- Determine trade-offs
Altogether, another very interesting read for anyone thinking about engineering strategy. There are a lot of ideas here, and they’re the best sort of ideas: those that are clearly Hewitt’s that he’s developed over a prolonged career.