Strategy isn’t a slide deck. It's a decision filter.
Why Engineering Teams Need Strategy
“Vision without diagnosis is just corporate karaoke.”
Neither Richard Rumelt nor Nassim Taleb, but feels like both could have said it.
Picture this: a two‑hour “strategy” session where the highlight is a 3‑D pie chart wobbling in PowerPoint. The chart promises 62 % “synergy,” 23 % “innovation,” and a mysterious slice labeled “other.” Everyone leaves inspired, yet nobody can name one thing we would stop or start doing on Monday. That’s corporate strategy at its worst: plenty of sparkle, zero incision.
Good strategy is the opposite. It doesn’t sparkle - it slices. One ugly fact, one ruthless rule, a handful of actions that reinforce each other. Engineers (usually people allergic to fluff) need that scalpel more than anyone. Without it we code, deploy, and firefight our way into treadmill miles masked as velocity.
Let’s look at what separates a scalpel from a karaoke mic.
Good Strategy/Bad Strategy
Richard Rumelt trims real strategy down to a three‑piece kernel:
Diagnosis – one brutal sentence explaining why you’re losing.
Guiding Policy – a rule clear enough to kill 90 % of tempting side‑quests.
Coherent Actions – moves that reinforce each other like gears.
That’s it. Miss one ingredient and you’re singing karaoke in a boardroom.
Bad strategy is notoriously easy to spot once you know the tells:
Thesaurus Bingo — fancy words everywhere, focus nowhere.
OKR Soup — more objectives than quarters, none tied to the deficit. A goal is not a strategy
Resource Myth — “Just hire more devs.” Fred Brooks buried that idea in 1975.
A roadmap stuffed with buzzwords feels inspiring; execution feels impossible. Why? Because nothing in it forces trade‑offs. Nothing says no.
The fix is painfully simple: write the ugly fact first.
If outages doubled because six services do one job
If the team can’t get anything done because everything is high priority
If you keep shipping features that don’t get any adoption
Say it. In plain English.
Everything that follows—policy, actions, metrics—must serve that single truth. When the diagnosis is visible, half the initiatives die on arrival, which is exactly what you want.
Clarity is ruthless. By design.
Strategy equals constraint. The tighter the kernel, the sharper the edge. And sharp edges cut scope faster than any motivational poster.
Why Engineering Teams Need Strategy
Code rarely stalls velocity—complexity does. Every new microservice, every home‑rolled tool, every “mandatory” framework adds friction. Without a strategy, teams become tax collectors for their own inventions.
Three concrete reasons engineers need a strategy as much as any C‑suite:
Scope control – A clear guiding policy kills features before code is written, sparing you half‑finished ghosts haunting backlog. Less scope, fewer merge conflicts, cleaner releases. And most importantly- more focus.
Morale alignment – Nothing drags culture faster than spinning wheels. When engineers see how daily tasks connect to a north‑star objective, motivation turns from paycheck compliance to mission energy.
Metric movement – Strategy turns abstract goals into observable deltas: lead‑time drops, defect rate shrinks, infrastructure cost goes down. Without that lens, you ship motion, not mileage.
Complexity compounds like credit‑card interest. Strategy is the only scheduled payment large enough to stop the balance raging out of control.
Where to Aim Strategy First
“Do everything” is not a strategy. It’s a full‑body sunburn. Thin‑spread strategy stalls. Single‑point strategy punches through. Before drafting policies, decide which pain hurts the most and throw the first punch there.
Pick one zone. Ignore the rest for a few weeks. Why? Because strategy is an elimination tournament: each round you cut half the distractions, doubling force on the survivor.
Focus isn’t fashionable - it’s lethal. In war you aim for the bridge, not every soldier. In engineering you aim for the bottleneck, not the whole system.
How to Craft the Strategy
How to craft a strategy? Not with a deck full of buzzwords. Start with the ugliest fact you can find.
Here’s a five‑step playbook you can run in a single afternoon.
Diagnosis (1 sentence)
State the pain in unflinching English.“On‑call pages doubled because six services do one job.”
Guiding Policy (≤ 20 words)
A rule clear enough to kill 90 % of shiny distractions.
“Consolidate to the simplest viable system.”Coherent Actions (~3)
Each action must reinforce the others.
Service audit → reroute key codepaths → migration & consolidation.
If success in one hurts another, scrap it.Metric That Gets Lighter
Everyone must see progress shrink weekly: lead‑time, infra spend, defect count. Numbers tighten discipline when enthusiasm fades.Time‑Box
Long enough for impact, short enough to expose delusion.
Post‑it Test: If your draft won’t fit on a sticky note, it’s too fat. Strategy is the adhesive, not the billboard. Everything else—runbooks, technical specs, hiring plans—flows downstream.
Run the playbook Monday morning; by lunch you’ll know which meetings to cancel, which features to defer, and why the build is still red.
Case Study — Deleting Our Way to Velocity
Context – We have inherited a bloated system, with service sprawl and business logic split into too many small pieces. In the meantime, the purpose of the system shifted completely, so now half of the features are not even used. The architecture never got the memo. Velocity grinds to a halt as the team struggles to find its way through the bloat.
Diagnosis – We’re paying a 100 % complexity tax for 30 % business value.
Guiding Policy – “Consolidate to the simplest viable system.” Not “rewrite everything.” Fold any non‑differentiating service into the core.
Coherent Actions
Service Audit
which servies are used
which parts of these are used
is it actually a distributed monolith?
Strangler Routes – new traffic to core; old service starved to zero, then deleted.
Migration – move the relevant code to a bigger but modularized service. Split into microservices can still be done if needed.
Metric – “System Weight,” - number of services and the size of their codebase. Goal: lighter each week. If weight held steady two weeks, pause feature work.
Results are still to be seen, as the strategy is still being formulated.
My expectation? Deleting code will ship more value than writing it. No hero rewrite, just strategy aimed at the fattest waste.
Conclusion
Strategy is not a luxury for the corner office. It’s the minimum viable guardrail that keeps engineers from drowning in their own enthusiasm. Diagnose brutally, frame one guiding policy, choose three coherent actions, and measure a number that gets lighter.
The rest is execution, made easier because every irrelevant idea already heard “no.”
Ship something so coherent it looks like one person built it—then show the org what leverage really feels like.
Strategy isn’t a deck. It’s the scalpel that cuts scope so your team can breathe. Pick it up.
‘Engineers are allergic to fluff.’ Love that, it is so true.