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, 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  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

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.