Table of contents
What’s not strategy
Core components
Where and when to invest in designing an engineering strategy
Strategy types
Strategy principles
Design and execution
Fractal strategy
“Strategy is how you overcome the obstacles that stand between where you are and what you want to achieve.” - Richard Rumelt
Another way to describe it is:
“Strategy is a set of coherent decisions, based on imperfect information, to overcome a high stake complex challenge”.
Therefore, engineering strategy is how we address the high-stake complex business challenge from a sociotechnical perspective.
1. What’s not strategy?
A bad strategy isn’t just the lack of a good strategy. It grows out of specific misconceptions and leadership dysfunctions. Like:
Fluff. Use hyped words to create the illusion of high-level thinking.
Failure to face the challenge.
Mistaking goals for strategy. Just statements of desire than plans for overcoming obstacles.
Bad strategic objectives. When they fail to address critical issues or when they are impracticable.”
- Richard Rumbelt
In addition to Rumbelt’s points, a strategy isn’t a plan or static. And more specifically, an engineering strategy isn’t isolated from the business strategy, it is embedded and it takes into account the whole business context and purpose.
2. Core components
Based on Rumbet’s framework
The core components of an engineering strategy are:
Understanding: Help us to identify the main blockers, risks, and opportunities that could prevent us to overcome the high stake business challenge. It helps us to focus on the important aspect of the challenge without feeling overwhelmed with information.
Direction: A guideline to help people understand where to focus.
Coherent actions: A set of coherent actions to accomplish the direction. They are coherent to one another, and they add up instead of compete.
Those three components live within a context of the business purpose and organization context. They need to directly address those business needs.
Engineering strategy is a business strategy from an engineering point of view.
It takes into account the entire context, culture, the business model and needs, other departments such as marketing, customer success, and more, to design an engineering strategy that’s coherent to the business as a whole.
3. Where and when to invest in designing an engineering strategy
Designing and executing an engineering strategy requires time, effort, and resources to make it happen. It is critical to know where and when to invest in an engineering strategy, as well as in which situations aren't the best approach.
The Cynefin Framework describes five decision-making contexts: clear, complicated, complex, chaotic, and, at the center, confusion.
Clear. The relationship between cause and effect is known to all, is predictable in advance, and is self-evident. Best practices are applied here.
Complicated. The relationship between cause and effect requires domain expertise. An expert in the field can ensure that the problem is solved properly because they did it in the past. Good practices are applied here.
Complex. The relationship between cause and effect cannot be analyzed in advance. The connection between cause and effect is unpredictable. You can draft a desired state to reach and apply a set of experiments and initiatives to reach the desired end state.
Chaotic. There is no relationship between cause and effect. The approach you need to apply to go out of this domain ASAP is acting instead of analyzing or categorizing. By acting, you will be able to navigate into a complex domain.
Confusion. You don’t know in which domain you are. Your job is to decompose the situation and aim to place it in one or more of the other four domains.
The domains it makes sense to invest in an engineering strategy are complex and complicated. The other domains aren’t suitable for it.
The Complex domain is the perfect fit for how I see the purpose of an engineering strategy. On the other hand, I see complicated to be also suitable for engineering strategy, but it produces a different type of strategy.
The key difference on how they influence the design of the engineering strategy is:
Complex domain
There is no right way to address your high stake business challenge. You need to bet on a direction and perform multiple coherent actions in parallel to see which approach works better, and then pursue that approach.
While the nature of the engineering is complex, the coherent actions should be either complicated or clear. Helping the teams to be able to deliver results. Those results can be things like spikes, A/B tests, production releases, training and workshops, … anything that helps you learn fast if your strategy is going in the right direction.
There is no point to over-analyze the situation because there is no root cause due to the nature of complex systems.
Complicated domain
Exist a right way to address your business challenge but it requires domain expertise. You might find the right people in your organization or you might hire/contract a person/group of people to help you address your high stake business challenge.
You will find your strategy direction is more straightforward and help the team to understand what to address first, which are the priorities, and what needs to be delivered.
The coherent actions are as well in the complicated and clear domain. They might include actions like up-skilling the team as part of the collaboration with external people to help you execute the strategy.
See more here.
4. Strategy types
Deliberate strategy: Intentional and more formal, it assumes the future and defines what needs to be true.
Emergent strategy: The organization's response to unanticipated events.
It isn’t about one or the other, but how each one complements the other.
A deliberate strategy helps the organization to align, remove bias, gain focus, and help teams become more autonomous. On the other hand, the emergent strategy helps people to adapt as they learn while executing the coherent actions, instead of requiring the investment that a deliberate strategy requires.
Good leaders understand when it is the right moment to use one or the other, and their tradeoffs. They are able to follow the strategy principles and core strategy components in formal strategy (deliberate) or informal strategy (emergent).
You can see an emergent strategy in tech huddles, leadership weekly calls, or mob programming sessions to overcome a hard architectural decision. The output of them can be architectural-decision records, a request for comments, a new framework adopted, or a new infrastructure component.
5. Strategy principles
Anticipate-Explore instead of Plan-Do.
Adaptative instead of prescriptive.
Strategy driven by value for the client and business.
Tech at core.
Communicate and collaborate first and later document, but document!
6. Design and execution
Be careful of one group of people designing the strategy (normally leadership) and another group of people executing it (normally teams). Minimizing the handovers is key.
The best way to increase the odds for a successful strategy is by making sure the key people that designs and executes the strategy are involved during the whole process.
7. Fractal strategy
A strategy can be implemented differently depending on each context. I expect a strategy to be interpreted and adapted for a local context and still be aligned on the C-level strategic choices.
Be sure you have the right structure to help teams inform when they need to adapt to their context and why, and how you communicate new learnings/decisions to the right people.
It is worth mentioning that those more local strategies usually have a shorter horizon. While a C-level engineering strategy can look at months to years ahead, more local strategies might be at a shorter time frame, like 3 to 6 months.
See more here.
