Designing an Engineering Strategy. Part I
Discover more from Aleix's Learnings
Designing an Engineering Strategy. Part I
I divided the topic into four posts/emails.
Part I. What the is Strategy? [This post]
Strategy, a word used for everything and more when you’re in a higher role in the hierarchy. Strategic meeting, strategic team, strategic initiative, strategic tweet, strategic pricing model, given a point, everything is Strategy, and when everything is, then nothing is.
<irony>Example of strategic tweet 👇</irony>
Today, I’m still learning what is Strategy. So, challenge what I say in this post and don’t take things for granted! Yet, I’m sharing with you what I learned so far 😄
Understanding what’s a Strategy
There’s a lot written about Strategy, yet almost everything I found is superficial or refers to something that’s not a strategy. I guess because strategy targets C-level and it’s good for SEO and SEM 🤷
This is the definition of Strategy that helps me have more impact on the business.
“A strategy is a coherent set of analyses, concepts, policies, arguments, and actions that respond to a high-stakes challenge” - Good Strategy Bad Strategy by Richard Rumelt.
Richard Rumelt follows with
The kernel of a strategy contains three elements: a diagnosis, a guiding policy, and coherent action.
It resonates with me this definition, maybe because now I’m not lost on the strategy expectations.
Now that we know what’s Strategy is, we need to adapt this to Engineering Strategy.
Engineering Strategy
Image the whole business as a square. What’s inside the square is everything the business does to serve the clients, operate, build teams, be financially sustainable, and more.
Now, part of the business is done using software, which it’s served, for example, in a SaaS model, using a subscription, built by many teams, which they are impacted by the pandemic which now needs to be fully remote…
Engineering Strategy is how we address a High Stake Business Problem from the Engineering Perspective, which can be multiple things like:
The time to market for new features is high, like six months of Go To Market.
The company has to buy hardware in advance to supply the customer needs, creating a bottleneck and being unable to serve our scalable needs on-demand.
The pandemic hit, and our ceremonies, infrastructure, and way to ship software are highly coupled to teams in the same room.
The mobile team grew by a lot, but they cannot ship with a good tempo, being unable to ship the customer needs.
Those High Stake Business Problems can translate into engineering as:
A Big Ball of Mud that doesn’t allow us to move fast enough to serve our clients needs
The need to move from on-demand hardware to the cloud
Creating the proper infrastructure, ceremonies, and support for the teams to be working from home
The need to re-architecting a mobile application to allow team’s growth to touch the same monolithic repository
Yet, we always start from a business problem, understand it, and then frame it as an Engineering Strategy. If an Engineering Strategy isn’t linked to a business problem resulting in a good outcome. Is it a good engineering strategy?
Questions that help me find the high-stake problems
What could prevent us from achieving the business goals?
Which are the current risks? Internal and external?
Which are the barriers that are impeding us from reaching our goals?
Where do we have more friction?
Where are the bottlenecks?
How Conway’s Law is affecting us?
Is our communication optimized for fast flow of change?
Do we close collaboration with domain experts and engineering to make the knowledge available for all team members?
Do we know our customers, their needs, and their journeys?
Are we measuring outcomes? How do we know we are on track?
Will our architecture support the next 2x growth?
Can we recover from a disaster like an AWS region going down for several hours?
How is the maturity of the service based on the 24 capabilities?
How are the teams performing based on the 4 key metrics of Accelerate?
Which are the interactions between teams?
Which are the value streams?
Which is the cognitive load of the teams?
.. but what happens when the high-stake situation is resolved?
The Strategy served its purpose, and you start again ✅
With several gains as:
Increased organizational knowledge
Increase in organizational resilience toward that high-stake problem
People become better at Strategy due to the experience acquired
Do not confuse …
… Engineering Vision with Engineering Strategy
If Engineering Strategy is about a high stake business problem, then Engineering Vision addresses the whole Business Vision.
It should serve as a guideline for people to make business-engineering aligned decisions daily so that we don’t create many high-stakes situations.
… ~bullsh*t~ a fluff with Strategy
Fluff is superficial restatement of the obvious combined with a generous sprikling of buzzwords. [Richard Rumelt]
I have become better at identifying good a Strategy over the last years. The main reason is that I had the privilege to work with extraordinary people who are great strategists.
I was able to see how a well-defined strategy had the problem well-framed. They come with a good direction and concrete actions to overcome high-stakes situations. Then I knew that’s Strategy, and therefore good Strategy looks like.
Then, identifying a fluff or a bad strategy is more accessible than I thought. Just question it.
What do you aim to solve by this Strategy?
How can I see this Strategy being implemented, its outcomes, and impacting the problem you described?
You will be surprised at how easy it is to spot a bad strategy. They lack foundations and are unable to articulate meaningful, focused actions.
Identifying a bad strategy and ignoring it is more productive than just following it because you don’t have a better alternative.
My recommendation is that if you’re unable to come up with a good strategy, pick the most significant business problem pick three focused actions that you think will address that problem. Done. Better specific actions though a problem and learn meanwhile about Strategy that a bad Strategy just for the sake of Strategy.
So, a bad strategy is…?
Quoting again Richard Rumelt
Bad strategy is not simply the abscence of good strategy. It grows out of specific misconceptions and leadership dysfunctions. A sort of:
Fluff. It uses buzzwords and apparently esoteric concepts to create the illusion of high-level thinking.
Failure to face or recognize the challenge.
Mistaking goals for Strategy. Being just a statement of desire rather than plans for overcoming obstacles
Bad strategic objectives. When they fail to address critical issues or when they are impracticable.
Strategy depending on the information you’re exposed
It’s kind of expected that depending on your responsibilities and information you’re exposed to. You will create one Strategy or another. There’s nothing bad about this as long as leadership is aligned towards the same objective.
A good strategy drives the direction and focuses on the high-stake situation, not deviates it.
I found it interesting combining OKRs to drive focus with an Engineering Strategy per leadership level. You can see easier if your engineering strategy aligns and has a high impact correlation with the OKRs.
What’s next?
In Part II. Understanding the high-stake problem, I will explain how to gain insights, understand the problem, and analyze some indicators to design an engineering strategy for higher success.
I will share some Miro templates I use to run some workshops to collect insights collaboratively.
You will find that I take advantage of:
Team Topologies
Domain-Driven Design
Measuring Cognitive Load
Wardley Mapping
Measuring the 4 Key Metrics of Accelerate and 24 Capabilities
Sociotechnical Systems (architecture + team communications)
Conway’s Law
Value Streams
Lead Inception to capture Product and Business Goals
Business OKRs
Part III. Giving direction and coherent action, I will explain how to use the insights you got on the high-level stake problems and drive direction and coherent actions to overcome those obstacles.
Using Domain-Driven Design
Evolutionary Architecture
Team Topologies
Effective Communication
Books
In Staff Engineer: Leadership beyond the management track, you will find a specific section about Engineering Strategy and Vision. I do think it’s an excellent reference to start, but you might feel lost since the chapter doesn’t give you the “how.”
It helped me better frame Engineering Strategy and reflected during this post.
Good Strategy, Bad Strategy has been a good discovery. I can tell this person knows his stuff and how to communicate it. Even though it doesn’t apply specifically to Engineering, I think it’s a good source if you want to go deeper on Strategy.
Meme for you
Index
Part I. What the heck is Strategy? [This post]
License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.