“You need to be more strategic”
A primer on strategy for software engineers
Being told you need to be more strategic is common feedback for senior engineers looking to move to the next level.
This can be tough feedback to hear.
Does it mean you’re not making good decisions? Not having enough impact? Relying too much on others? And what even is strategy? People rarely define it in a crisp and actionable way, instead offering hand-wavy explanations about needing to have more impact or expand your scope.
In this post I want to offer a concrete definition of strategy, and then provide a few models which you can use to start thinking more strategically.
So what is strategy?
Strategy isn’t long term planning. It’s not a detailed roadmap. It’s not even just making big, important decisions. Strategy can be thought of as the framework that guides decision making; strategy is an articulation of both a path forward and explicit trade-offs — what you’ll do and what you won’t do — that align your actions with your core objectives.
Strategy can be thought of as the framework that guides decision making.
Let’s look at a couple of analogies to try and illustrate this.
Imagine you’re driving from San Francisco to Seattle, and you want to get there in under 12 hours. That’s your goal. For those unfamiliar with the West Coast geography, 12 hours is a theoretically doable timeframe but the variance can be high. It’s possible to lose 2 hours if you pass Portland at the wrong time, and there are several other traffic bottlenecks.
A possible strategy to achieve this somewhat optimistic goal would be to use multiple drivers to enable continuous driving while optimizing around traffic patterns rather than absolute distance or speed.
The strategy isn’t “take I-5” or “drive fast”, it’s a higher-level approach that introduces new possibilities (can drive straight through), adds constraints (need to coordinate schedules), and impacts other decisions that might be made (no need for a sleeping stop). It’s a set of fundamental approaches which generate a cascade of tactical decisions — when to swap drivers, timing of departures to avoid city traffic, length of rest periods, etc.
A good strategy helps shape our decisions. It isn’t just a plan, it’s a framework that opens some doors and closes others.
Let’s look at one more example, this time from software engineering.
Imagine you need to improve the reliability of a complex system that’s having frequent production issues. Your goal is to catch bugs before they hit production.
One possible strategy would be to slow down releases and introduce a comprehensive manual QA step. But a more common strategy would be to focus on adding end-to-end automated tests of critical user flows.
The strategy isn’t just “add more tests”, it tells us what type of tests we want to add and how we’re going to prioritize adding them.
These two examples should show how a good strategy reduces the decision aperture. It isn’t a roadmap, it’s a framework that helps prioritize what to work on and how to do it.
Frameworks for Strategic Thinking
Anyone who knows me, knows I love models and frameworks. And I find strategy particularly fun. These are three frameworks that touch on different aspects of strategy and can help get you unstuck.
Rumelt’s Kernel of Strategy
Reading Good Strategy, Bad Strategy by Richard Rumelt is a bit like starting to see through the Emperor’s New Clothes. I know multiple people who’ve read this book then sat through presentations by high level VPs with their head on their desk.
The book has a bunch of insights on what makes a good strategy and how to spot bad strategy, but the most valuable takeaway is Rumelt’s Kernel of Strategy.
The Kernel has three parts: diagnosis, guiding policy, and coherent actions.
The first part is a diagnosis of the biggest obstacle that you need to overcome in order to reach your goal. It’s not a list of problems, but an expression of the key challenges that makes everything else harder. Using the testing analogy above, the diagnosis might be “Our test coverage looks good on paper, but our tests don’t match how customers actually use the system.”
The second part is the guiding policy, this is the general approach you’ll take to address the challenge. This should help you decide what to do and what not to do. In our testing example, the guiding policy might be “focus on testing end-to-end customer workflows rather than individual components.”
The final part are the steps you’ll take that align with the guiding policy. They need to work together, that’s why they’re “coherent”. Putting it all together for the testing example it looks like this:
- Goal:
Catch bugs before they hit production - Diagnosis:
Our test coverage looks good on paper, but our tests don’t match how customers actually use the system - Guiding Policy:
Focus on testing end-to-end customer workflows rather than individual components - Coherent Actions:
Build an end-to-end test suite for critical user journeys
Add production monitoring for these journeys
Change incident review process to focus on user impact
This is just a quick look of Rumelt’s framework. If you want to learn more, without reading the whole book, Jeff Zych has some good notes.
Playing to Win
The second framework I like is from another book called Playing to Win. It’s based on the authors’ experiences at Proctor & Gamble, so is more oriented towards business and product strategy, but it can still be very useful for engineers.
The framework asks you to answer five questions:
- What’s your winning aspiration? (What does success look like?)
- Where will you play? (What problems spaces will we focus on?)
- How will you win? (What’s our unique approach?)
- What capabilities do you need?
- What management systems are required?
Using the testing example again, this might unpack like so:
- Winning Aspiration:
Be perceived as the most reliable service in our space - Where to Play:
Focus on interactive user flows even over offline processing systems - How to Win:
Catch issues through automated testing of real user workflows - Capabilities Needed:
End-to-end testing framework
Automated test infrastructure
Production monitoring for user visible errors
Ability to replicate real user behavior in test environments - Management Systems:
Automated pre- and post-commit checks
Regular reliability reviews
Incident analysis focused on user impact
Test coverage reporting for critical paths
This framework forces you to make trade-offs. When you choose to win through automated testing of user workflows, you’re choosing not to win through extensive manual QA or unit testing.
This framework is also particularly useful for eng leaders because it can be used to connect technical decisions to business strategy. When your company has defined its winning aspiration and where it will play, you can work backwards to determine what technical capabilities and management systems you’ll need to support that strategy. It helps bridge the gap between top-line business objectives and the day-to-day engineering work.
Three Horizons
Sometimes it can be really hard to reconcile what you need to do right now with longer term plans. Why are we working to keep the lights on, when this metaphorical building will be demoed in a years time?
McKinsey’s Three Horizons model is very simple and breaks down the strategic outlook into different timeframes.
Horizon 1 is about optimizing the systems and processes you have today. This is typically 0-2 years out, but in startups things move faster and the horizons can be compressed.
The 2nd horizon is about emerging opportunities, typically 2-5 years out, but again often much sooner in startup-land. This work is adjacent to existing systems, but represents new capabilities or major expansions of existing services. While these things are further out, you often need to start laying the groundwork today, factoring future needs into architectural decisions or product design.
Horizon 3 is about creating entirely new capabilities. These will be big bets that look fundamentally different from where the product or architecture is today. At first there may be little clarity about horizon 3, so the key is identifying what foundational work would be needed regardless of where H3 ends off landing.
Imagine you’re dealing with a legacy monolithic service, this is how you might break down the work into horizons:
- H1: Stabilize the existing system. Clean up the worst of the technical debt while adding monitoring and improving test coverage.
- H2: Service separation. Identify service boundaries and start building internal APIs between components. Create basic deployment infrastructure to support microservices.
- H3: Fully distributed architecture. Complete transition to microservices architecture. Implement event-driven patterns. Enable auto-scaling and self-healing. Support multiple regions.
Note how the work on H1 enables H2’s service separation. Each horizon needs to deliver immediate value while laying the foundations for the subsequent horizon.
In practice, you may also be working on all three horizons simultaneously, just with different expected payback periods. In a startup, H1 projects might be addressing customer needs next week, while H2 projects are working towards something 6 months out, and H3 projects are speculative and may not deliver meaningful value until much later. The challenge is finding the right balance, enough H1 to keep things running smoothly while still investing in H2 and H3.
I hope you find that these frameworks give you more clarity about what people mean when they tell you to “be more strategic”.
They’re often asking you to create structures and systems for how decisions get made, rather than just making decisions. Frameworks like Rumelt’s Kernel, Playing to Win, and Three Horizons can help break down complex problems into actionable steps. They guide you to diagnose issues, define a winning approach, and balance immediate fixes with future opportunities.
But remember, bad strategy is bad strategy, no matter how well executed.
And good strategy still needs good tactics and strong execution.
