Technology Strategy Patterns, a Review
Why I read this book
Ask 10 people what is in a Technical Strategy and you will get 12 different answers [1].
Each strategy development process I have contributed to has been different. Sometimes we used a framework like Playing to Win. Sometimes we used templates developed in house. Other times, we used tools and visualizations that a staff member brought from another organization.
Two things have been fairly consistent across my experiences:
Many Strategy frameworks focus on the business and product the aspects, leaving some important technical concepts and models to other frameworks. As a result, I have I have found I often introduce the components to represent Technology aspects of the Strategy.
While I have access to lots of tools to communicate strategic plans, I never felt I had a coherent overview of what should be in a Technical Strategy. Moreover, I have found resources on this subject to be thin or bespoke.
I discovered Technology Strategy Patterns (TSP) when researching for a recent strategy exercise. I found an excerpt of a chapter in this blog post where the author, Eben Hewitt, described and diagramed the interplay between Strategy, Culture, and Execution. I found the article compelling enough to purchase and read.
Strategy, Culture and Execution. Hewitt, Eben. Technology Strategy Patterns: Architecture as Strategy. O'Reilly Media. Kindle Edition.
What is it about?
This book is a step-by-step guide for creating a general technical strategy. It provides practical, well-trodden tools to distill your technical plans and ideas into clear and consumable documents for executives, stakeholders, and teams. It has three parts:
Context: Architecture and Strategy
Creating the Strategy
Communicating the Strategy
The meat of the content is in Part 2 where the author weaves patterns from the Business and Technology industries into a holistic framework. Rather than a linear format, it is presented as a layered set of tools that cover different scopes of a strategy spanning the "World" to your "Department".
Strategy Patterns. Hewitt, Eben. Technology Strategy Patterns: Architecture as Strategy. O'Reilly Media. Kindle Edition.
He uses an analogy of "patterns" as a means of relating strategy development to a concept that engineers know well. It is also used to imply flexibility in how you apply them. You could easily substitute the word "templates" for "patterns" in many cases. An example pattern is the Ansoff Growth Matrix to help you decide how to grow your business.
Ansoff Growth Matrix. Hewitt, Eben. Technology Strategy Patterns: Architecture as Strategy. O'Reilly Media. Kindle Edition.
Along with the patterns themselves, Eben provides advice on how to use principles of formal logic along with common sense to ensure your strategy is consistent and comprehensive.
What this book isn't
Wishy-washy. It has opinions throughout. He doesn't prescribe any particular philosophies, but through his experience the author has developed a toolbox of what has worked well for him. He references or execution frameworks like Agile, but those are usually orthogonal.
If you are not making statements that someone could reasonably argue with, you are not making a meaningful or impactful statement, you're not making a choice and putting a stake in the ground to forge a new future.
Technical. If you are looking for large scale system design, architecture, or discussion of technologies, look elsewhere. This is not a deeply technical book and it isn't trying to be.
People focused. Aside from communicating strategy with people and involving them in the strategy development process, this book does not address cultural or people management. However, there are a few helpful nuggets like:
Hero culture is a disaster for a business that's trying to scale and grow. Without dismantling that, you can't scale your business, and it will be hard to see why it continues to be unable to break through.
Engineering practices. It covers aspects of strategy all the way down to the point where you need to develop practices. But it largely assumes you have tools that you have created for this purpose or learned elsewhere.
What stood out the most
The application of Mutually Exclusive, Collectively Exhaustive (MECE) is a technique that now pervades my daily thinking. Ensuring each of my lists contain "equivalent items" and "span the entire domain" is a simple, yet powerful organizational tool. When a list of options which is MECE, it is much easier to understand the tradeoffs and impacts of the choice.
The included diagrams add a lot of clarity. Example drawings and tables were used extensively to show how to create each deliverable.
Synthesizing data into insights and hypotheses. Hewitt, Eben. Technology Strategy Patterns: Architecture as Strategy. O'Reilly Media. Kindle Edition.
The comprehensiveness of the strategy patterns make the book and framework very understandable. He contextualizes the patterns in a visual model that shows how they relate to each other and defines several helpful layers: Analysis, World, Industry, Corporate and Department. This grouping really resonates with me. As the Author would say: This list is MECE.
The patterns themselves fit together well. You can clearly see the space the purpose of each and how they each contribute to a complete strategy. While some patterns are familiar, like a RACI, others I hadn't used before, like a PESTEL analysis.
The background on philosophy and logic is intellectually interesting. While it felt dry or tangential a few times (more on that below), it was a nice reminder to leverage these millennia-old techniques to make a coherent strategy.
What didn't work for me
Portions of Part 3: Communicating the Strategy had an odd structure to me. It does contain what you would expect: techniques on building decks, story telling, delivering concise answers, and tips on change management. But it also contains several patterns like Build/Buy/Partner, Priority Map, and Use Case Map which would feel much more at home within Part 2: Creating the Strategy.
A few patterns didn't seem to fit anywhere, such as Deconstruction and Scalable Business Machines:
Deconstruction was about general problem solving, decomposition and brief dive into Semiotics, which are useful, but covered to a depth that I didn't feel added much value.
Scalable Business Machines leaned more into creating a healthy organization to execute on a strategy. This is useful, but feels outside of the scope of the book - and while it was a longer section, I think this subject can be more fully explored in other texts.
The section on Hypothesis dives into logic and propositions. The reminder on Logical Fallacies was helpful as was warnings about false precision. It did the job of communicating the rigor that the author employs, but like Deconstruction, I found the detail covered within Conjunct of Propositions and Bayesian Probability to be more than I was looking for.
A few times the author referenced a concept or deliverable to use as a tool, but did not cover how to create it. For example, I have seen many definitions of Capabilities Mapping and would have appreciated seeing how the author would have approached this himself. This was also true of Concept Models.
Tone and readability
Conversational. Eben's casual writing helps to lighten up would could be a dry instruction manual. He uses just enough story telling to get the point across in a way that doesn't put you to sleep.
Medium-Dense. Some strategy books like this can be filled with case-studies, fluff, or repetition of the same points in a different way. This is not the case for TSP where chapters are mostly concise descriptions of tools and how to apply them.
Opinionated. He has a clear definition of what should be in a "good strategy". He writes from the perspective of a Technology Leader with a lot of real world experience, which is evident from all practical tips and lessons interwoven into the discussion of the patterns.
Who should read this?
If you are responsible for developing Technical Strategy, or what to learn how, this book is for you. The author assumes a technical background, and that your main questions are around communication with leaders and non-technical stakeholder
If you are an Principal Engineer or Architect, and want to understand how to use widely understood business tools in the technology context, this is a great guide. Not because it is earth-shattering, but because it is eminently practical.
The book spends time and effort coming at this from a point of view of a Technologist learning to talk to the Business to get funding, people, and alignment. If this describes you, then I would recommend giving this a quick read.
Listen, read, reference, or blink?
I read the Kindle version, and did a lot of highlighting. This book wants to be used visually! For myself, I distilled the major concepts into a mind map so that I can refer to them and use later.
If you are pressed for time, reading Part 2 will provide you with most of the value of this book. I recommend reading the whole thing, at least to a depth where you have a high level understanding of the patterns and how they fit together so that you can reference them later. I found enough helpful tips in this book that make it worth the full read.
I couldn't find many deep reviews or summaries of this book (ping me on LinkedIn or Twitter if you do!). If you are looking for more information, you can try these links:
How I want to use what I learned
I feel this book directly addresses the gap I wanted to fill: It lays out a comprehensive framework with clear ideas on what should be in a technical strategy and how to organize it. While I have seen and used some of the presented patterns before, I had never seen them assembled into a single, cohesive whole. This book dealt with both business and technology aspects of strategy in a way where neither felt tacked on.
I don't expect to just copy the patterns from this book into templates and never think about the structure of my strategies again. BUT, combining this with some other tools I have used (such as Wardley Maps), I do expect to have a default pattern to address most strategic questions in the future.
I also feel confident in sending this book to other leaders in order to create alignment on "What is a Technical Strategy and what should it contain". This book doesn't feel so prescriptive that I would be concerned that leaders will feel a loss of autonomy in creating a strategy. Instead, I think the framework can help remove consternation over format and allow people to focus on the substance. And it intentionally leaves a lot of space for customizing for your organization and domain.
Part of being a strategist is knowing your toolset and being able to pull out the right tool for the task at hand. After reading this book, my 🧰 has several new tools and is a lot more organized.
[1] I stole this line from my neurosurgeon, who used a similar phrasing to describe the number of options neurosurgeons will give you for spinal surgery… but that is another story.