Strategy – how to be strategic, and how to be seen as strategic – is one of my ongoing obsessions. Years ago, I read Good Strategy/Bad Strategy, and it’s guided my thinking ever since.
One of the things that book helps clarify is that being strategic and being seen as strategic can work against each other – good strategy is obvious, and usually it is executed on more than it’s talked about. An ongoing frustration for other under indexed people in tech I talk to, as we build products and organizations without drama, whilst being told we’re just “not strategic” enough. The strategy required to sidestep problems that never happen or that creates optionality to quickly resolve is somehow invisible.
But I think as w…
Strategy – how to be strategic, and how to be seen as strategic – is one of my ongoing obsessions. Years ago, I read Good Strategy/Bad Strategy, and it’s guided my thinking ever since.
One of the things that book helps clarify is that being strategic and being seen as strategic can work against each other – good strategy is obvious, and usually it is executed on more than it’s talked about. An ongoing frustration for other under indexed people in tech I talk to, as we build products and organizations without drama, whilst being told we’re just “not strategic” enough. The strategy required to sidestep problems that never happen or that creates optionality to quickly resolve is somehow invisible.
But I think as we rise up the org chart, strategy is the job. Strategy defines your job, and evolves it to meet the organizational need. Not just one strategy, but multiple strategies that need to fit together and be coherent.
Your product strategy. Your technical strategy. Your team strategy. Your you-as-a-leader-but-also-a-human-being strategy.
As we find our groove in the resource constrained era we are in currently as opposed to the everything strategy of ZIRP (zero interest rates), by definition we need to make more harder choices, and strategy is how we know what those choices are, and when and how to make them.
 This is the first rule of strategy: strategy is contextual. A crucial insight, because often when leaders fail, it’s because they tried to apply a strategy that worked in one context, to a different one, without considering the difference.
This is true when you change companies, and I think the reason why there is such a high failure rate for executive hires*. Ones I’ve watched fail came in with a playbook, usually including the org chart they wanted, and expended all the goodwill and capital in pursuit of that goal, whilst achieving very little.
It’s also the case that when the market changes, our strategy must change. One of the core features of ZIRP-era engineering leadership was hiring for the sake of it, and number of people as a proxy for many things it maybe (probably) shouldn’t have been. One of the biggest shifts has been the layoffs and the mantra of “doing more with less”. Regardless of personal feelings on this topic and what is actually realistic, it is apparent that hard choices and discipline are a key feature of the post-ZIRP era.
We could talk about these strategies – product, technical, team, you, like some balanced stool. But realistically, I think it’s more like the image above. The product strategy is a storm (especially pre-product market fit). The technical strategy is a half built shelter (you’ll get to it properly once you have product market fit). The team strategy is an umbrella (the most flexible and controllable). And the you as a human strategy is nowhere to be found.
 This is the second rule of strategy: timeframe varies with the level of uncertainty you’re navigating.
The idea of a proximate objective is the next logical step in pursuit of your overall strategy, if you achieve it, you confirm your course. If you fail, you learn and reconsider your options.
We often talk about strategy like it’s defining the end state, setting and describing the destination. But strategy is about defining the incremental steps – the proximate objectives – that can take us towards that end state. Strategy is understanding where we are at – context – and the path from there to where we need to go**. Any strategic “plan”, is best executed as a set of proximate objectives.
This mistake of how strategy is talked about is why it can be so hard for some people to be seen as strategic. When we think strategy is depicting the end state, and undervalue the proximate objective definitions and execution that it takes to get there, the person who talks more about the end state can be seen as more strategic than the person who actually reaches it.
We need four things for strategy:
- Time – energy – to think deeply about it
- Context to situate it
- Direction to identify proximate objectives
- Expertise to chart the path All of these need to come together to create and deliver an effective strategy. It’s a balance between all of them, leaning into different ones at different times.
To illustrate, why each of these are important, I think it’s helpful to consider the extremes of each.
When someone is all time, we call them a political operator. This is the person who manages up to get credit, but the people underneath them ask what it is that they do.
When someone is all context, we say they can’t see the forest for the trees. They miss the big picture fixating on the details.
When someone is all proximate objectives, we call them a thought leader and it’s not a compliment. Execution is an exercise left to the reader.
When someone is all expertise, they present solutions in search of problems. They don’t seem to understand impact.
Devaluing these things gives us a reason not to do them. So many engineers will tell you they hate politics, and yes, there is definitely toxic workplace politics. But there’s a baseline where politics is getting things done. It’s convincing people that the idea is good, and that it can be executed. My favourite explanation of this is Nik Means talking about Eiffel’s tower.
Context is important. Yes, you’re delivering something bigger, but the details need to add up. You can’t gloss over all of them, you need to learn how to distinguish which are important and which are not.
Proximate objectives chart your path. They explain the steps you expect to take between where you are and where you plan to be. Explaining them helps bring people along with you.
Expertise is ultimately how you deliver things, you need to understand how to deliver and how to validate. Execution is when the strategy becomes real.
Strategy is hard, and being seen as strategic – especially for under-indexed people – can be even harder. We need all of these four things to develop our strategy and move things forward. And we need to be recognized as doing all of them in order to be seen as strategic.
Coming back to our problems of strategy – the product, technical, team, and you.
Product strategy drives your proximate objectives. Whilst product strategy may seem like the job of product management – and to a certain extent it is, but hopefully your product team does not operate in a vacuum. Engineering needs to provide input, but engineering also needs to understand the product strategy, because everything else needs to fit in with it.
*Your team exists for a purpose, and the clearest part of that purpose is delivery of the product strategy.*You need direction and alignment to identify proximate objectives. Direction – where the product strategy is going, alignment on what is most important, and what will be delivered when.
Technical strategy evolves the context. Your technical strategy is often about surfacing the underlying work that allows you to deliver on the business need. It has to be well justified, because ideally it’s pro-active rather than reactive – i.e. you implement it before the emergency rather than during it.
Any technical strategy needs to start with what problem is being solved. A problem is not the absence of a technology – unless, I understand, that technology is AI – but rather the problems that technology would solve. So “we don’t have containers” is not a problem. Number of incidents or environment inconsistencies is. Good technical strategy changes the context over time – making more possible – like building roads on the territory you’ve chartered.
Your team strategy must be grounded in execution. The product and technical strategy define the organizational need. Your team strategy is about how your team is going to meet that organizational need, within the constraints of the business.
Post-ZIRP, this has been a big challenge. Doing more with less means having fewer people, less flexibility, less margin of error. You need to figure out how you retain key people when money is tighter and promotions are harder to come by. But amidst all of these challenges, you have to execute. If in a ZIRP era, you could build the team then deliver, now you must deliver as you build the team.
The you as a person strategy requires that you carve out time to be strategic. In this market, many of us are doing-doing-doing to prove that we’re worth keeping around, but at some point, your job is no longer what is being done this week, and more about what is possible next quarter (and the quarters after that). It’s never been easier to be DDOS’d by the job and think that means we’re doing a good one, but you could be missing key things if you’re too focused on the day to day, or week to week and not enough on the month to month.
To wrap up, strategy is about more than just a vision; it’s about navigating the path to get there. We need to balance time, context, direction, and expertise to ensure we’re not only seen as strategic but are genuinely creating a strategic path forward for the teams we’re responsible for – and our own evolving needs to competently lead them.
* I can’t find a great source here, although the search results suggest it’s commonly accepted #. # possibly, which links out to a site requiring login.
** I love Tanya Reilly’s description of the map in The Staff Engineer’s Path.
Image credit: Joe Groove