Strategy vs Plan: Which Comes First, and Why a Plan Alone Isn't a Strategy

Strategy comes first. A plan is a sequence of actions, and without a diagnosis of the problem you are sequencing work towards a goal nobody has justified. A plan can be immaculate, fully resourced and on schedule, and still be the wrong plan. The diagnosis is the part teams skip.

This is written for tech leads and engineering managers who keep being handed a roadmap and asked to call it a strategy. It covers the order the two things go in, why a plan on its own is not a strategy, what a strategy with no plan degrades into, and the cases where you genuinely only need the plan.

What comes first, strategy or plan?

Strategy comes first, because the plan is downstream of a choice that the strategy makes. Richard Rumelt, in Good Strategy Bad Strategy, describes a strategy kernel with three parts: a diagnosis of what is actually going on, a guiding policy for dealing with it, and a set of coherent actions that follow. The plan is the third part. Written without the first two, it is a schedule.

Take a real one. “Migrate to microservices by Q3” is a plan. It has a target, a date and an implied set of tickets. It contains no diagnosis at all, so nobody can tell whether it is the right work. The missing half sounds like this: deploys are coupled, two teams cannot ship independently, and the queue in front of every release is what is costing us. Now the plan is arguable. Someone can reasonably say that a deployment pipeline change would fix the coupling faster than a service split, and that argument is the useful one. Without the diagnosis there is nothing to argue with, only a date to slip.

	Strategy	Plan
Question it answers	What is our real problem, and what are we choosing not to fix?	What are we doing, in what order, by when?
Shape	A page of argument	A sequence of work with owners
How it fails	It is wrong about the problem	It is late, or it does not deliver what was scheduled
What invalidates it	New evidence about the problem	Changed capacity, dependencies or scope
Who should challenge it	Anyone who can see the system	The people doing the work

The order matters more than the artefacts. Plenty of good teams hold the strategy in three sentences and never write it in a document. What they do not do is start sequencing before they can say what the sequence is for.

Why is a plan not a strategy?

A plan is not a strategy because it contains no choice. It says what you will do, not why that beats the alternative you rejected, and a strategy that rejects nothing is not making a decision. Rumelt’s sharpest point is that most bad strategy is goals dressed up as strategy: a statement of where you want to end up, presented as though it explained how to get there.

Three things get called strategy on engineering teams and none of them are:

• A roadmap is not a strategy. It is a strategy with the argument deleted. Quarterly columns of features tell you the sequence and hide the reasoning, which is why roadmap reviews turn into negotiations about dates rather than about problems. A roadmap is still worth having, and there is real craft in setting its detail, timeframes and dates, but it is an output.
• An OKR set is not a strategy. Objectives and key results measure whether you got somewhere. They do not say why that place is worth reaching or what you are giving up to reach it. Reduce p99 latency to 200ms is a fine key result and a terrible strategy, because it is silent on whether latency is the thing hurting you.
• A goal with a date is not a strategy. “Zero P1 incidents by December” describes an outcome you would obviously prefer. Every team would prefer it. The strategy is the unpopular part: which class of incident you will invest in eliminating, and which you will accept and page someone for.

The test is subtraction. Remove the numbers and dates from the document and see what is left. If what remains is a list of things you would like to be true, you were holding a plan. If what remains is a claim about your situation that a competent colleague could dispute, you were holding a strategy. The same distinction runs through testing, where a test strategy and a test plan are separate documents with different owners and different lifespans.

What is a strategy without a plan?

A strategy without a plan is an opinion. It is the more comfortable failure, because nobody gets blamed for it and the document usually reads well. Six months later the diagnosis is still accurate and nothing about the system has changed.

The pattern is familiar. A staff engineer writes a clear-eyed piece about why the deploy pipeline is the constraint. Everyone who reads it agrees. It gets linked in Slack a few times. No work is scheduled against it, no owner is named, no first change lands, and the next planning cycle allocates capacity to feature work as usual. The strategy was correct and had no consequences.

Coherent action is the part that makes a strategy real, and coherence is stricter than it sounds. It means the actions reinforce each other and that you can point at each one and say which part of the diagnosis it addresses. If half the roadmap has no line back to the diagnosis, either the diagnosis is incomplete or that work is there for other reasons. Both are worth knowing before the quarter starts.

When a plan on its own is enough

Often, and pretending otherwise is how strategy becomes ceremony. If the diagnosis is already agreed and uncontroversial, you do not need to restate it as a strategy layer. You need a plan and someone to run it.

Work that just needs a plan:

• The Node runtime reaches end of life in four months and you have to be off it
• A vendor deprecates an API with a published shutdown date
• Remediation items from an incident, where the postmortem already established the cause
• Routine dependency and certificate work with a known cadence

What these share is an external constraint doing the diagnostic work for you. The problem statement is not in dispute, the option space is small, and the interesting questions are all about sequencing, risk and cutover. Adding a strategy document to that is theatre, and experienced engineers read it as theatre.

The honest signal is disagreement. If you can state the problem in one sentence and nobody in the room argues, go and plan. If two senior people describe the problem differently, stop planning, because you are about to schedule work that only one of them believes in.

How to pressure-test a plan before you schedule it

Run this before capacity gets allocated, not at the review afterwards. It takes about twenty minutes and it is mostly writing things down that people assume are shared.

1. State the diagnosis in one sentence. No goals, no solution, just what is going wrong and why. If it takes a paragraph, you have more than one problem and should say which you are attacking first.
2. Name what you are not doing. A strategy with no sacrifice is a wish list. Write the two or three credible options you are turning down, so that when someone proposes one in month three there is a record of it having been considered.
3. Say what would have to be true. Every plan rests on assumptions about traffic, team size, vendor behaviour or the shape of the existing code. List them. These are the things that will actually break the plan.
4. Check each work item against the diagnosis. Take the top ten tickets and mark which part of the problem each one addresses. The unmarked ones are not necessarily wrong, but you should be able to say why they are in this quarter.
5. Decide what would make you stop. A signal and a review date. Plans that cannot be abandoned are not plans, they are commitments with Gantt charts attached.

The output of that conversation needs somewhere to live where the team can argue with it later. An architecture decision record is the usual home on engineering teams, and writing an ADR your team actually reads back is a specific skill; at company level the equivalent is a strategy memo with a real statement at its core. Teams that would rather not book another meeting for it sometimes use Projan, which asks the clarifying questions in Slack, keeps the rejected options recorded next to the chosen one, and exports the agreed work to Jira or Linear. What matters is that the diagnosis is written where the people who will be held to the plan can see it and push back.

Frequently asked questions

Who owns engineering strategy on a team without a CTO? Usually the most senior engineer with enough context to see across teams, working with whoever controls headcount. Ownership means writing the diagnosis down and defending it, not deciding alone. If nobody holds the pen, the strategy defaults to whatever the loudest roadmap item implies, which is how teams end up committed to work nobody chose.

What is the difference between a strategy and a tactic? A strategy is the choice about which problem to attack and what to give up. A tactic is one move that serves that choice. Extracting billing from the monolith is a tactic. Deciding that deployment coupling matters more than latency this year is the strategy underneath it. Tactics are cheap to change and strategies are not.

How often should an engineering strategy be rewritten? Rewrite it when the diagnosis stops being true, not on a calendar. A strategy built around scaling limits becomes obsolete the moment traffic flattens, however recently you wrote it. Quarterly reviews are useful for checking whether the diagnosis still holds, but a strategy that changes every quarter was probably a set of goals in the first place.

Is a technical strategy the same as a product strategy? No, though they should agree. A product strategy chooses which users and problems the company serves. A technical strategy chooses what the system must be good at to make that possible, and what it is allowed to be bad at. When they disagree, engineering usually ends up optimising for something the product no longer needs.

Strategy first, then the plan, and the join between them is a diagnosis somebody wrote down and other people were allowed to attack. Most engineering plans that go wrong were never wrong about the work, only about the problem. Ask what you are choosing not to fix, and if the answer is nothing, you have a schedule.