Strategy is a luxury funded by tactics

Here's something most engineering playbooks leave out. If you're building a startup's product, you're tied to that startup's fortunes. If it doesn't find customers, or runs out of road, the work stops. You're not a detached contractor working through a spec. You're on the same rollercoaster.

That changes what "the right thing to build" means.

What matters this week

Sometimes the most valuable thing an engineer can do this week isn't the next feature on the roadmap. It might be:

• the one integration a pilot customer needs before they'll sign
• the answers to a prospect's security questionnaire, and the fixes it turns up
• a change of direction halfway through the week, because the founder just had a conversation that changes everything about who the first customer is

None of these is glamorous, and none of them shows up in a technical roadmap. Engineers often find that uncomfortable. We want to build the thing we planned, properly, and a mid-week change of course feels like chaos.

But the roadmap only matters if the company is still here to follow it. You have to survive long enough to carry out your strategy, and survival is tactical. Strategy is a luxury funded by tactics.

Seeing the whole business

The engineers a startup needs understand the whole business, not just the code. They know who the first customers are, what's blocking a sale, where the money comes from and what the founder is worried about this week. That's what lets them make good calls about what to build, in what order, and to what standard.

We use a mental model we call focus and blur. Picture the startup as a photograph. Some parts are in sharp focus: the core thing a customer will pay for. We build those properly, with real architecture and real tests. Everything else is deliberately blurred: deferred, bought off the shelf or kept as simple as possible until it matters.

When the business context shifts, the focus shifts with it. So:

• Say what's changed. Write it in the log channel: what moved up, what moved down, and why. Nobody has to guess.
• Name the trade-off. "We can get the pilot integration done this week, but it means the reporting work slips." The founder decides with the facts in front of them.
• Keep the standard. A change of priority is never a licence to cut corners. Whatever ships still goes through the same tests and review.
• Go back. Once the urgent thing is done, return to the plan, updated for what you've learned.

Why founders need engineers who get this

A founder under pressure from customers, runway and their own ambition doesn't need engineers who refuse to look beyond the roadmap. They also don't need engineers who build whatever's asked, with no sense of which bits matter. They need people who understand the business well enough to know the difference, and who'll say so.

That's the real job of a startup's first engineers. It's not just writing good code. It's knowing which work matters, this week, for this company to still exist next quarter.

We've ridden this rollercoaster with a lot of founders. The ones who make it aren't the ones with the most perfect roadmap. They're the ones whose whole team understood what the business needed, and built it.