When and when *not* to do an engineering strategy
A guideline to understand your context and act based on your specific situation
I still recall the first strategy I proposed when I had a position in an organization that should think strategically.
Our strategy is Lean. We will innovate for our clients by creating mobile and responsive web applications through Domain-Driven Design, Continuous Integration and Test-Driven Development.
Using Scrum and open source technologies, we deliver value to our clients quickly and efficiently, allowing us to have a small but effective team.
It took us a year to realize that the strategy wasn’t impactful enough, so we evolved it.
Our strategy is Lean. We will innovate for our clients by creating mobile and responsive web applications through Domain-Driven Design, Continuous Delivery, Test-Driven Development and AWS.
Using Kanban and open source technologies, we deliver value to our clients quickly and efficiently, allowing us to have a small but effective team.
Not much better right?
I did a lot of things wrong back then, I will highlight two:
Not knowing what’s strategy nor how to formulate one.
Not knowing when it is needed to do one.
I did a four-post on designing and executing an engineering strategy for the first point. For the second point, this post will address that specific concern.
Check the first post on designing an engineering strategy here 👇
Imagine that you start doing engineering strategies for everything, for small stuff and the big stuff, for very chaotic stuff, … are you using it as a silver bullet solution to all your problems?
Designing and executing an engineering strategy is expensive for an organization. As a tech leader, you must know when to invest in making one and which areas consider your specific context.
I will aim to share an approach that will help you to sense if you should invest time in designing one or if you need to act and execute.
Intro Cynefin Framework
The Cynefin Framework, by Dave Snowden, says there are five domains (adapted definitions by me).
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 needs 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.
Domains illustrated
I like to imagine those domains as I’m in point A and want to reach my desired state B.
Clear. Going from A to B is straightforward.
Complicated. Going from A to B isn’t straightforward. It takes more time to reach, but with people knowing the path, it’s achievable.
Complex. Going from A to B is a matter of experimentation. You need to try multiple experiments, desirable in parallel, to know which one helps you be closer to the desired outcome state.
Chaotic. Your goal is to move away from Chaotic ASAP, probably going from the Chaotic domain into the Complex domain.
Using Cynefin to assess if I need or not to do an engineering strategy
Based on my experience, I found that engineering strategy as I described in the posts on how to design and execute it works well in Complex and Complicated.
If you are in a Chaotic or Clear domain, don’t do an engineering strategy and start doing what needs to be done.
Why do I mark Complex as ✅ and Complicated as ❓?
I believe the Complex domain is the perfect fit for how I see the purpose of an engineering strategy.
While Complicated, certain scenarios might apply depending on your domain experience in your organization. Domain experts exist in the market, but you cannot reach them for different reasons. You might want to apply an engineering strategy to address the high-stake business problem and learn fast about this domain area.
Those are my guidelines for an engineering strategy or jumping directly into action.
Execution eats strategy for breakfast.
You might hear this sentence in your company, and I resonate with it. This post somehow highlights that if you don’t know when to do strategy, execution is a better reliable option.
Because execution applies better to three of the four Cynefin domains.
The possibility is that applying execution over thinking a strategy has more odds of being a better decision when ignoring in which domain you are.
After reading this post, I hope you can choose more carefully when investing in designing and executing an engineering strategy or just jumping into execution.
Supporting visuals
Meme for you
