Most engineering strategies don’t fail because the team can’t execute them. They fail because the strategy can’t adapt when reality changes.
I’ve written enough engineering strategies to learn that the hard part isn’t creating the plan. It’s creating a plan that is clear enough to guide decisions, focused enough to create trade-offs, and flexible enough to survive the first unexpected event.
The strategies that fail tend to fall into two camps. The first is the vision document: “become the most reliable platform in the industry” - sounds inspiring, doesn’t help anyone decide what to build next. The second is the feature roadmap: “ship login v2 in Q1, migration tool in Q2” - specific, but falls apart the first time something unexpected happens, which is usually day one of Q1.
A good engineering strategy sits between these extremes. One that holds regardless of the planning horizon. I’ve landed on a structure that works after enough failures to know what doesn’t.
The One-Page Strategy
Every quarter, I write a one-page strategy document. Not a deck. Not a Notion page with twelve sections. One page.
If the strategy doesn’t fit on one page, we haven’t done the thinking yet. We’ve done the writing. The one-page constraint forces prioritization: what actually matters this quarter?
The page has four sections:
Context: What changed since last quarter that affects our priorities. New business commitments. Major incidents. Team changes. Market shifts. This section should be 3-5 bullet points, not a history lesson.
Priorities: Exactly three things we will achieve this quarter. Not five. Not ten. Three. If everything is a priority, nothing is. Each priority has a one-sentence description of what success looks like.
Trade-offs: What we will explicitly not do this quarter. This is the most important section. A strategy that doesn’t say no to anything is not a strategy - it’s a wish list. I’ve learned to be specific here: “We will not address the database scaling issue. We will not build the admin dashboard. We will not reduce technical debt in the auth service.” The trade-offs are where the strategy lives.
Risks/Challenges: What could derail us and what we’ll do if it does. Not a comprehensive risk register - just the top three things that could go wrong and the trigger that would cause us to reprioritize.
I’ve found that the one-page constraint does more for strategic clarity than any framework or methodology. When you can’t hide behind length, you have to actually decide.
The Three-Priority Rule
Three priorities per quarter is the right number for an engineering team of 10-50 people. Fewer than three and you’re not ambitious enough. More than three and you’re not focused enough.
But not all priorities are equal. I categorize them into three types:
Type 1: The bet. One priority that moves the business forward. A new capability, a major migration, a platform investment. This is the thing that will matter in six months.
Type 2: The obligation. One priority that keeps the business running. Reliability improvements, compliance work, technical debt reduction in a critical area. This is the thing that will hurt if we ignore it.
Type 3: The experiment. One priority that explores something uncertain. A new technology evaluation, a process change, a team topology experiment. This is the thing we’re not sure about but need to learn.
I’ve learned that most teams overload on Type 1 priorities (all bets, no maintenance) or Type 2 (all maintenance, no forward motion). The three-type framework ensures balance. Every quarter should have one of each.
The Mistake
The most common mistake in quarterly planning is treating the plan as a commitment.
A plan is a hypothesis. You’re guessing what will matter in three months, what dependencies will align, what incidents won’t happen. The probability that your plan survives the first month unchanged is near zero. The question isn’t whether you’ll deviate - it’s whether you have a mechanism for deviating intentionally rather than reactively.
I use a simple mechanism: every month, I revisit the one-page strategy and ask three questions:
- Is this still the right priority?
- Has the context changed enough to warrant a shift?
- Are we making progress or just staying busy?
If the answer to question 2 is yes, I rewrite the strategy. Not incrementally - a fresh one-page document. This isn’t failure. It’s adaptation. The teams that stick to a bad plan out of discipline don’t earn respect. They earn irrelevance.
I’ve had quarters where I rewrote the strategy every month. I’ve had quarters where the original plan held for all three months. Both are fine. The discipline isn’t in following the plan - it’s in having a clear enough strategy to know when it needs to change.
The Communication Strategy
A strategy no one knows about is not a strategy. It’s a private document that the author feels good about.
I’ve learned to communicate the strategy in three channels, in three different formats:
The document: The one-page strategy, shared with the entire engineering org. This is the source of truth. It lives in a shared location that anyone can find.
The presentation: A 15-minute walkthrough at the beginning of the quarter. Not a read-along of the document. A conversation: here’s what we decided, here’s why, here’s what we’re not doing, and here’s where I’m uncertain. The Q&A is more important than the slides.
The reminder: A one-sentence version of each priority that gets repeated in every planning meeting, every standup, and every retro for the quarter. “This quarter, we’re focused on reducing checkout latency, migrating off the legacy payment system, and evaluating our incident response process.” If people can’t repeat the three priorities from memory, we haven’t communicated enough.
The reminder is the most important channel. People forget. Priorities drift. The quarterly goal that felt obvious in January feels distant in March. Repetition isn’t redundancy - it’s reinforcement.
The Review
The end-of-quarter review is where most teams lie to themselves.
They present what they built, celebrate the wins, and quietly skip the parts that didn’t work. The review becomes a performance instead of a learning opportunity.
What works better: Answer three honest questions:
- What did we achieve that we planned to achieve?
- What did we achieve that we didn’t plan to achieve?
- What did we plan to achieve that we didn’t achieve?
Question 2 is the most revealing. It shows where the strategy was wrong and where the team’s intuition was right. If question 2 has more items than question 1, the strategy was too rigid or too disconnected from reality. If question 3 has more items than question 1, the strategy was too ambitious or the execution was flawed - and the review should distinguish between those two causes because they require different fixes.
I’ve started publishing the quarterly review as a public document within the company. Not to embarrass anyone - to normalize the practice of honest assessment. When teams see that admitting what didn’t work is valued more than spinning what did, they stop hiding the truth.
What I’ve Learned
Five things about quarterly strategy that took me too long to understand:
Strategy is about what you won’t do, not what you will. Anyone can make a list of priorities. The courage is in the trade-offs. If your strategy document doesn’t have a “we will not do this” section, it’s not a strategy.
A good strategy survives its first contact with reality. Not by being rigid - by having clear principles that guide decisions when the plan changes. The principles outlast the quarter.
The team should be able to derive the strategy from first principles. If I disappeared, would the team make the same prioritization decisions? If not, the strategy is dependent on me, which means it’s fragile.
Strategy without execution is fantasy. You can’t make good prioritization decisions without knowing what the team actually did. Review what shipped, what slipped, and what it cost. Measure cycle time, deployment frequency, and incident rate. Use what happened to inform the strategy, not anecdotes about how you think things went.
The best strategy is the one the team actually uses. A perfect document that sits in a folder is worse than an imperfect one that guides daily decisions. The measure of a strategy is not its quality on paper. It’s whether people reference it when they’re deciding what to do.
Strategy is not about predicting the future. It’s about making the best decision you can with the information you have, being honest when it needs to change, and building a team that can execute either way.