Engineering Strategy Is Not a Backlog

Most of us do not write engineering strategy often. It is not part of the daily job, it rarely shows up in a performance review as a deliverable, and almost nobody is taught how to do it. So it stays one of the least understood tasks in an engineering organization.

It is also the single biggest driver of impact. A strategy influences years of work, the careers of the people executing it, and what the organization is capable of building afterwards. Getting it right is the first step in being successful as an engineering organization.

And here is the uncomfortable part: strategy is always impactful. A bad one is not neutral. It is just as influential as a good one, pointed in the wrong direction.

The most common failure I see is simple. Someone writes a list of projects, puts quarters next to them, and calls it a strategy.

That is a backlog.

A strategy is a theory. It is a claim about why the organization is where it is, where it should go instead, and what has to be true for that to happen. Projects and tasks hit walls quickly and need to change. A strategy should not change when it hits a small bump. It is the compass and the guidelines you follow through a series of projects, and it should guide you through challenges you had not thought of yet.

When a project fails, the strategy survives.

#The Ship That Hits the Storm

Imagine a ship sailing across the Atlantic.

The captain has a destination, a compass, navigation principles, and a route planned for the next few days. Then a storm appears.

The original route is no longer viable. Following it blindly would be stupid. So the captain changes course.

But they do not change the destination.

And they do not throw away the compass because the route turned out to be wrong.

The route is execution. The compass and the destination are strategy.

Engineering organizations face this constantly. A project that looked straightforward turns out to be technically infeasible. A dependency changes. A technology does not perform the way the benchmarks promised. A team discovers that its assumptions were wrong.

If the strategy says build project X using technology Y by Q3, then the strategy has already failed the moment the storm appears. The organization is left with two bad options: keep executing a plan everyone knows is wrong, or rewrite the strategy every time reality intervenes. Both destroy trust, and the second one is worse, because a strategy that changes every quarter teaches people not to follow it at all.

#The Layout of a Good Engineering Strategy

Four parts. In this order, because each one depends on the one before it.

#1. Diagnosis

First establish your point of reference. Where are you right now? Why are you there? Why are you not yet where you want to be?

Be honest. This is the foundation, and if you are not honest in the diagnosis, everything built on top of it will not fit your actual situation. Go deep and find the root causes. Do not treat symptoms.

The diagnosis does not have to be comforting. It has to be true.

This is the part most strategies skip, usually because an honest diagnosis is politically expensive. “Our builds are slow” is a symptom. “We have no ownership model, so nobody is accountable for the thing that makes builds slow” is a diagnosis. The first one leads to a tooling project. The second one leads to a strategy.

#2. North Star

In one sentence, what is the end state?

Where is the destination. It should be clear and precise, because this is the sentence that gets repeated in rooms you are not in. You want to make it very hard to misunderstand.

If it takes a paragraph, it is not a north star yet. Keep cutting.

#3. Strategic Bets

These are not projects. They are bets.

A bet reads like a claim: we believe we have to do this because of that, and if we are right, it will help us in this specific way. It names the reasoning, not the implementation. It can be wrong, and you should be able to tell when it is.

That framing matters more than it sounds. A project is something you are committed to finishing. A bet is something you are committed to testing. When a bet turns out to be wrong, you have learned something and the strategy still stands. When a project fails and the project was the strategy, you have nothing left.

Keep the number small. Focus is the scarce resource here, not ideas.

#4. Guiding Principles

Nothing concrete. Rules and policies that equip you to deal with challenges you have not seen yet.

These principles should guide decision making when you are not in the room. Following them should keep the organization on track by default. They need to be clear, precise, and easy to remember, because a principle nobody can recall is a principle nobody applies.

This is the part that makes a strategy generative instead of prescriptive. A good principle answers questions you never anticipated.

#What This Looked Like For Me

I have been on the wrong side of this.

I spent more than a year building toward incremental builds in a large monorepo. I learned the space, built credibility, and became the person driving that direction. Then a couple of months of spikes, prototypes and profiling made the conclusion unavoidable: incremental builds were not going to work for us.

It hit harder than I expected, and it took me a while to understand why. I had tied part of my identity to it, but more importantly I had been treating the route as the destination. The bet was “pre-building libraries will remove the bottleneck.” That bet was wrong, and I had let it stand in for the strategy.

The actual problem had not changed at all. Developer productivity, engineering efficiency, and scaling collaboration across a large organization were still the things worth solving. The destination was intact. The compass still worked. Only the route was gone.

Once I separated the two, the recovery was months of work instead of starting over. I documented what we learned, socialised the alternatives, and rebuilt sponsorship for a different direction toward the same north star.

A failed bet inside a real strategy is information. A failed project that was masquerading as the strategy is a reset.

#Do Not Write Fluff

The last thing worth saying is the easiest to get wrong.

Do not try to sound thoughtful for the sake of sounding thoughtful. Strategy documents attract abstraction, and abstraction feels safe because nothing in it can be proven wrong. Sentences that could describe any organization describe yours by accident.

Be genuine and make it simple to digest. Great execution requires focus, and focus requires that everyone understands the same thing. Every ambiguity in the document becomes a different interpretation in a different team, and you will pay for it in months of work pointed slightly in the wrong direction.

If people cannot repeat your strategy back to you from memory, it is not going to survive contact with a storm.