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. 

Engineering project planningEngineering project planning

Project planning

What’s a Good Strategy

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.

Good Strategy

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.

Coherent Actions:

  • Provide a single source of truth for user IDs that every platform calls.
  • Standardize events around that ID so journeys can be connected.
  • Merge identities when overlaps happen, so duplicates don’t pollute the view.
  • Feed that unified data into personalization, marketing, and reporting so the business can actually use it.

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.

Bad Strategy

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.

Strategic Planning

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:

Clarity on outcomes

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.

Allocation of resources

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:

  • Identity (6 engineers): owns the core identity service.
    • KPI: percentage of requests successfully resolved to a unique ID within 30ms.
  • Data (7 engineers): handles ingestion, validation, and backend processing.
    • KPI: percentage of events captured, validated, and delivered without errors.
  • Platform (7 engineers): ensures infrastructure, reliability, and performance at scale.
    • KPI: uptime of core services and p95 latency across the stack.

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.

Decision principles

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.

Intentional Planning

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.

  • Months 0–6: Core identity service. Build the foundation, set storage and latency targets, keep the API simple. Analytics waits.
  • Months 6–12: Event capture. Standardize schemas, expand with data engineers, make sure the pipes are reliable.
  • Months 12–18: Processing and access. Build pipelines, expose clean data, form a real data engineering team.
  • Months 18–24: Personalization. Spin up a small ML team, deliver first models, expand feature pipelines.
  • Months 24–30: Scale. Focus on global reliability, developer experience, and clear ownership across platform, data, and ML.

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.

Project Selection and Sizing

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.

Project Selection

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:

  1. Unblockers. The work without which nothing else matters (e.g., database + APIs before dashboards).
  2. Risk reducers. Projects that prevent pain later (KPIs, monitoring, validation).
  3. Value drivers. Projects that deliver visible business value (dashboards, pilot integrations).
  4. Nice-to-haves. Everything else.

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.

Dealing with Disruptions

Disruptions always come: a critical outage, a leadership pivot, a flashy feature request. The policy I use:

  • If it threatens reliability or security, it jumps the queue.
  • If it aligns with the top strategic priority, we re-rank and possibly bump it up.
  • If it doesn’t meet either bar, it waits until the next cycle.

This keeps the team from thrashing while still reacting when it truly matters.

Sizing projects

Sizing and estimates are always the best effort. You’ll never get it perfect, but you need a consistent bar:

  • A project should deliver something tangible in 1–2 months.
  • A single team should own it end-to-end. If it needs two teams, it’s too big, split it.
  • Don’t obsess over exact hours. Go just detailed enough to expose hidden dependencies.

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:

  1. Database + schema (unblocker).
  2. Core APIs (unblocker).
  3. Merge logic (risk reducer).
  4. KPIs + monitoring (risk reducer).
  5. Load testing (risk reducer).
  6. Pilot integration with one consumer team (value driver).
  7. Runbooks + docs (value driver).

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. 

Risk and Opportunity Analysis

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:

  • Projects that remove existential risk get priority, even if they’re invisible to the business. Nobody thanks you for avoiding an outage, but everybody remembers when you don’t.
  • Projects that unlock leverage also get priority. A solid identity layer is leverage — once you have it, personalization, cross-selling, and analytics all become easier.
  • Projects that are low risk and low leverage go last.

This stops you from wasting months on work that looks exciting but doesn’t matter when stacked against core risks and opportunities.

Execution and Tracking

Even the best strategy fails without solid execution. You need to know whether projects are actually delivering. The way I handle it:

  • KPIs at the team level. Each team has one or two metrics that prove they’re moving the strategy. Example: % of events captured without error for the Data team, or p95 latency for the Platform team.
  • Checkpoints, not promises. A six-month phase is broken into 1–2 month deliverables. At each checkpoint, we ask: did this project land, and did it deliver the outcome we wrote down?
  • Visualize progress. Dashboards, weekly digests, even a simple “stoplight” view (green, yellow, red). If you can’t see drift, you’ll only find it out when it’s too late.
  • Review and adjust. If projects slip, you re-rank. If priorities shift, you re-plan. Plans always drift. That’s normal. I know plans always drift so I’m prepared for that. I set checkpoints every 2–4 weeks to catch it before it’s too late.

Execution is the management. It’s where trust is built. When teams deliver what they said they would, leaders start listening.

Organizational Alignment

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:

  • Write it down. If it’s not documented, it doesn’t exist.
  • Cascade. Every manager should show how their team’s work ties to strategy.
  • Feedback. Adjacent teams spot friction first. If that input doesn’t flow back, the plan drifts.
  • Stay consistent. Teams only move when the strategy itself changes.

Alignment isn’t more meetings. It’s removing guesswork on why the work matters.

Closings Thoughts

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.