Published · 12 min read
Strategy is a word that's often used but rarely understood. Ask ten people what it means, and you'll get ten different answers. I often see people confuse it with a vision statement, a quarterly roadmap, or just a long wish list. None of those are strategies. I’ve seen what happens without clarity. Lots of motion, No momentum. Motivation only takes you so far. Discipline carries you forward. That, to me, is part of the difference between vision and strategy. You have to do the ugly work sometimes because it’s part of the deal. Otherwise, you end up with a lot of code written, a lot of meetings held, but very little that actually moves the company or group forward.
I like to think of strategy as choosing what really matters when you can’t do it all. In engineering, the hardest part isn’t generating ideas. There are so many things that you can solve. Strategy gives you that boundary so that you can say no to most of the good ideas. A good strategy is a filter: it shows your team where to lean in, where to hold back, and where to ignore the noise entirely.
When you have that strategy, the planning is where you make it real. This is the unglamorous work: breaking big bets into projects, sizing them, weighing risks and opportunities, and keeping everyone aligned as reality shifts. But that’s what management is sometimes. When you do this well, planning gives a team the confidence that their effort adds up to something bigger. If you do the planning poorly, it becomes a spreadsheet of false promises that never makes it to production.
Project planning
I don’t see software engineering as any different from any other field when it comes to strategy. The same rules apply. That’s why I often come back to Richard Rumelt’s Good Strategy/Bad Strategy. He makes the point clearly: good strategy identifies a real challenge and then lays out a focused way to tackle it. Bad strategy hides behind big words. A grand vision and vague nonsense that sounds inspiring but doesn’t tell anyone what to do next.
Rumelt argues that a leader’s first job is to face the hard truths: diagnose the biggest obstacles and build a coherent plan to overcome them. Strategy isn’t about ambition or nice-sounding vision statements. It’s about choices. It’s about deciding what you won’t do, as much as what you will. And those trade-offs are never easy.
At the core of Rumelt’s thinking, kernels of good strategy are three parts: a diagnosis of the core problem, a guiding policy for how you’ll address it, and a set of coherent actions that actually put it into motion. How does that translate to an engineering strategy? Here’s an example.
In a large organization with multiple brands, users move between apps and websites all the time, but each platform treats them like a stranger. There’s no shared view, no consistent way to personalize, no way to see the full journey. Here’s the diagnosis: a fragmented identity landscape, where users cannot be reliably identified across systems.
Guiding Policy: fix identity first. Build one model that works everywhere, instead of letting each brand solve it on their own.
That’s how I define a good strategy: name the real problem, pick a direction, back it up with actions that fit together. The trade-off is simple. You hold off on new initiatives until the foundation is in place. Identity comes first and then collecting relevant data. Once that’s solved, everything else has a chance to work.
A bad strategy in the same situation sounds impressive at first. We’ll become more data-driven across all brands. Each team should build its own analytics pipeline, and we’ll layer some dashboards and machine learning on top.
On paper, that looks ambitious. In practice, it ignores the real blocker. Without a shared identity, none of those systems connect. You get five versions of the same user, duplicated data everywhere, and dashboards that don’t line up. Teams burn time maintaining their own tracking instead of solving the core issue.
A strategy on its own doesn’t deliver anything. You need to turn it into work people can execute. That’s where planning comes in. Planning is the bridge between the big choices and the day-to-day. Without it, even the best strategy stalls. The way I approach planning comes down to three policies:
Vague goals don’t count. “Improve performance” is meaningless. Every initiative must define a measurable outcome with a timeline. Example: Cut API latency by 50% in six months so partners don’t churn. I don’t staff an initiative unless the outcome is written down and testable.
This is where strategy gets real. Trade-offs come with how you staff people and what you hold them accountable to. With 20 engineers, you can’t let everyone chase ten different priorities. You draw hard lines and commit. Let’s do it for the identity example. We can three focused teams:
That’s the shape. Each team has a measurable outcome that ladders back to the strategy: reliable identity, clean data, stable platform. If the strategy shifts, we replan. Until then, this is the map. Clear scopes, hard KPIs, full accountability.
Requests never stop. You get feature requests from sales, shiny tech pitches, hiring asks. Without guardrails, every one of them can technically start a fight. How do you stop that? My rule is simple: we only accept work that ties to our top three priorities, improves reliability, or compounds long-term advantage. Everything else waits.
Planning starts with intent. The why and what. Gradually, you need work towards the how: the projects, timelines, and resources that make it real. You can’t predict everything perfectly. Nonetheless, you should come up with sequencing the work so the team knows where to spend energy first, and leaving room to adapt as things change.
Take the identity example. The diagnosis is clear, but you can’t fix everything in one go. Strategic planning forces you to stage the work, grow resources step by step, and deliver value in sequence.
Each phase builds on the last. Outcomes are measurable, teams are deliberately shaped, and decisions follow clear rules. That’s how strategy turns into execution.
Planning sets the roadmap: the sequence of work, the teams that own it, and the outcomes we’re driving toward. Project selection and sizing make that roadmap executable.
Planning gives you the phases, but execution depends on picking and sizing the right projects inside each phase. You'll always have more projects than engineers, which is why stack-ranking them is crucial. The way I rank them is simple:
This is where stack-ranking matters. During a rebuild, some teams may want to plug into the new identity service with their own schemas so they can spin up executive dashboards quickly. On the surface, it sounds like progress. Simply faster visibility, quicker wins. But without standardized validation, the data would be fragmented and unreliable. The dashboards would tell a story, just not the right one.
So, we need to hold the line. The first projects need to be the foundations: shared schema, validation, monitoring. Only after those are solid, we can open the service to wider consumers. Dashboards would land later, but when they would, the numbers can be trusted.
Disruptions always come: a critical outage, a leadership pivot, a flashy feature request. The policy I use:
This keeps the team from thrashing while still reacting when it truly matters.
Sizing and estimates are always the best effort. You’ll never get it perfect, but you need a consistent bar:
Some projects will overrun. That’s fine if you’ve broken them down small enough. Your slip is measured in weeks, not years. So, you are fine there.
Example:
Phase 1: Identity Service could stack like this:
If a disruption arrives (say, a security gap), it may jump above #3. If a flashy feature request comes in, you hold the line. It sits below #7 unless it ties directly to strategy. Nevertheless, you need to acknowledge the reality. There are times where you’ve to let one/two slip because of an exec asks.
Every project is a bet. The mistake I’ve seen is treating every bet the same. In practice, you need a way to weigh risk against opportunity.
Risks are the things that can sink you: outages, data loss, compliance failures. Opportunities are the bets that can compound: new revenue streams, adoption enablers, long-term leverage.
The policy I use:
This stops you from wasting months on work that looks exciting but doesn’t matter when stacked against core risks and opportunities.
Even the best strategy fails without solid execution. You need to know whether projects are actually delivering. The way I handle it:
Execution is the management. It’s where trust is built. When teams deliver what they said they would, leaders start listening.
I’ve seen strategies fail when they stay in leadership’s head. Big initiatives need sponsorship, buy-in from adjacent teams, and a clear escalation path. Without that, everyone defaults to their own priorities.
My rules:
Alignment isn’t more meetings. It’s removing guesswork on why the work matters.
Strategy only works if it flows all the way down into execution. You start by finding the areas that align with the company’s direction. Then you break them into projects, size them, and stack-rank them based on risk, opportunity, and effort. Not every project makes the cut. And that’s the point.
From there, you track. Software isn’t a bridge you can see rising every day, so you create increments, checkpoints, and metrics to keep progress visible. Some projects will slip, some will underdeliver. That’s normal. The way through is transparency. You need to trim scope when needed, adjust when reality shifts, and keep stakeholders close through communication channels.
In the end, it’s not about producing the perfect plan. It’s about clarity. People should know why their work matters, how it ties into the bigger picture, and where to look when priorities clash. Strategy sets the direction, planning makes it concrete, project selection and sizing keep it deliverable, and alignment ensures nobody is in doubt.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。