Designing an Engineering Strategy

https://github.com/aleixmorgadas/awesome-engineering-strategy

I divided the topic into four posts:

1. Part I. What the is Strategy? [This post]

2. Part II. Understanding the high-stake problem.

3. Part III. Giving direction and coherent action.

4. Part IV. Executing an Engineering Strategy

5. Engineering Strategy Template

You can check the Guides section for more focused posts like this one.

Engineering Strategy Guide - Introduction

---

Strategy is 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.

Today, I’m still learning what Strategy is. So, challenge what I say in this post and don’t take things for granted! Yet, I’m sharing with you what I have learned so far. 😄

Understanding what a Strategy is

There’s a lot written about Strategy, yet almost everything I have found is superficial or refers to something that’s not a strategy. I guess it is because strategy targets the 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.

This definition resonates with me, maybe because now I’m not lost on strategy expectations.

Now that we know what Strategy is, we need to adapt this to Engineering Strategy.

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

Imagine 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 is served, for example, in a SaaS model, using a subscription, built by many teams, which are impacted by the pandemic and now need to be fully remote…

Engineering Strategy is how we address a High-Stakes Business Problem from the Engineering Perspective, which can be multiple things, like:

• The time to market for new features is high, such as six months of Go-To-Market.

• The company has to buy hardware in advance to supply customer needs, creating a bottleneck and being unable to serve our scalable needs on-demand.

• The pandemic hit, and our ceremonies, infrastructure, and ways to ship software are highly coupled to teams being in the same room.

• The mobile team grew by a lot, but they cannot ship with a good tempo, being unable to deliver on customer needs.

Those High-Stakes 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 work from home.

• The need to re-architect a mobile application to allow team growth while touching the same monolithic repository.

Yet, we always start with 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-stakes problems

• What could prevent us from achieving the business goals?

• What are the current risks, both internal and external?

• What are the barriers that are impeding us from reaching our goals?

• Where do we have more friction?

• Where are the bottlenecks?

• How is Conway’s Law affecting us?

• Is our communication optimized for a fast flow of change?

• Do we have close collaboration between domain experts and engineering o make knowledge available to 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?

• What is the maturity of the service based on the 24 capabilities?

• How are the teams performing based on the 4 key metrics of Accelerate?

• What are the interactions between teams?

• What are the value streams?

• What is the cognitive load of the teams?

...but what happens when the high-stakes situation is resolved?

The Strategy has served its purpose, and you start again. ✅

With several gains, such as:

• Increased organizational knowledge.

• An increase in organizational resilience toward that high-stakes problem.

• People becoming better at Strategy due to the experience acquired.

Do not confuse …

… Engineering Vision with Engineering Strategy

If Engineering Strategy is about a high-stakes 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.

… 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 a good Strategy over the last few 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 was Strategy, and therefore what a good Strategy looks like.

Then, identifying fluff or a bad strategy is more accessible than I thought. Just question it:

• What do you aim to solve with this Strategy?

• How can I see this Strategy being implemented, its outcomes, and its impact on 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 and pick three focused actions that you think will address that problem. Done. Specific actions for a problem are better—and you will learn about Strategy in the meantime—than 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 to

It’s somewhat expected that depending on your responsibilities and the information you’re exposed to, you will create one Strategy or another. There’s nothing bad about this as long as leadership is aligned toward the same objective.

A good strategy drives direction and focuses on the high-stakes situation, rather than deviating from it.

I found it interesting to combine OKRs to drive focus with an Engineering Strategy per leadership level. You can see more easily if your engineering strategy aligns and has a high impact correlation with the OKRs.

What’s next?

In Part II: Understanding the high-stakes 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 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

In Part III: Giving direction and coherent action, I will explain how to use the insights you got on the high-level stakes problems and drive direction and coherent actions to overcome those obstacles using:

• Domain-Driven Design

• Evolutionary Architecture

• Team Topologies

• Effective Communication

An engineering strategy example

---

Thank you a lot for reading this post 😄.

I love to read your feedback and opinions to help me improve. You can DM at my LinkedIn or just leave a comment using the following links:

• 😍 Awesome

• 😐 Okey

• 😨 Bad

License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.