I was recently re-reading a book called "Strategy in Action - Marrying Planning, People, and Performance", which introduced eight fallacies of why strategies generally fail. While this book is very "business strategy" oriented (dealing with generating a game plan for businesses to succeed), I began to wonder about how these would apply to engineering strategies. Merriam-Webster.com defines "Strategy" as:
the art of devising or employing plans toward a goal
For application purposes, an engineering strategy is then (personally) further defined as:
a set of principles and practices to achieve a goal that targets business impact, culture, or efficiency of an engineering (team|product|organization)
According to "Strategy In Action", 6 of the 8 fallacies are: reification, control, linearity, path-dependency, people = things, and the hard/soft fallacies. The below explanations and takeaways are my own experiences of them.
6 Reasons Engineering Strategies Might Fail
1. The Reification Fallacy
"Reification" is when you want to treat something immaterial (fear, happiness, culture, strategy) as material. Some see engineering strategies as a document, or process that is finished once "the pen is put down". This mental model works for something that has a finite end and beginning, which is exclusive to an engineering strategy. I have seen this in practice when engineering leaders get together and work hard to come up with a document or spreadsheet that outlines what they feel would be the best plan/direction; only to see fallout and confusion when enacted. This especially rings true when, after working through this strategy, it isn't revisited by that same group.
My takeaway: Put in the effort to build a strategy with your teams, but always include time for feedback from those impacted. Leave room for iteration.
2. The Control Fallacy
This fallacy explains moments when engineering leaders determine a strategy at the top; then have their direct reports go off and execute on their behalf. This approach gives leaders control and direction of the execution of the strategy, but it leaves valuable insight from their team and does not foster ownership with the people who the strategy was intended to help.
My takeaway: Hack on these openly with not only your peer leadership, but those whom it affects. If possible, take an active role in living out the strategy for multiple levels of the organization. Also remember number 1 above ;-)
3. The Linearity Fallacy
This fallacy is the notion that a strategy is a step by step process which is predictable and known. With engineering strategies this would be akin to something like:
- Assemble a team of talented people
- Send them off to design an overall architecture or proof of concept
- Operationalize the PoC for sale
While the above leaves a lot of gray areas in how we know each step is successful, the linearity fallacy illuminates the need to understand the environmental and human conditions surrounding the strategy. Oftentimes this is easier to see in more drastic scenarios, like when a new product comes out that completely renders another business or product useless. When this happens, it is usually due to not understanding the technical advances or market changes as they happen, so the older product can adjust accordingly.
My takeaway: As leaders, we should execute on strategies with openness to change the methods in which our strategy lays out. Moreover, it's our responsibility to aggressively try to uncover and resolve what is threatening to undermine the engineering strategy's goals.
4. The Path-Dependency Fallacy
"It worked before, it will work again", or "It's easier this way because we did this also in A,B, or C" are common statements that could hint at this fallacy. "Path-Dependency" is the mental model that what has happened in the past tends to make hold on what the future can be. Most engineering strategies include structure, processes, tech, etc, which can be biased due to what the team has done in the past. Sometimes this is good, sometimes it holds back the innovation the team really needs to improve.
My takeaway: Ensure to always reflect and discuss your engineering strategies on "first principles". This can help either validate the good things your teams are already doing, or break the mold to unlock more potential and creativity.
5. The "People = Things" Fallacy
You might be experiencing this fallacy if you hear a variant of these sayings during planning meetings across your engineering organization:
- We have to get X done. Which resources have the skill and knowledge of this sub-system that we could deploy to put out this fire?
- Over the last few weeks, engineering leadership has decided we will be moving to Y model, which will mean moving more reqs to our offshore office
- Pleasure to meet you manager Z! Fun fact about me is that you're my Nth manager here.
- This team is like a swiss army knife, they know all the systems, have worked on all the projects, etc
While the above statements are not always bad, as our teams might have some great technical talent for example, this fallacy reveals that in strategy: The described people or teams are not the emphasis, but the business machine they support.
My takeaway: To be a successful software/product company, you just need smart, empowered, engineering teams. Those teams will find the right way to move the business forward as an artifact of that. Put people and their teams first by enabling them, unblocking them, and helping them find the right problems to solve.
6. The Hard/Soft Fallacy
Engineering strategies often include technical decisions, structure, and processes (sometimes exclusively). Those would all be known as "Hard" traits, whereas "Soft" traits would be things like cultural or practice principles which would inform and align people rather than tech. These are sometimes avoided because their issues are hard, messy, and unpredictable. According to the authors, these are often the root cause of strategies failing.
My takeaway: Ensure that your engineering strategy doesn't just champion the tech or business, but also champions your people, both at team and individual levels.
Be strategic about strategy
Engineering strategies should be able to align and enable engineers, their teams, and the business they support. Maybe these fallacies might help you, like they helped me, determine how to take steps toward being principally driven, building great teams, and championing good people. This is all in effort of helping everyone to do amazing things.