Strategy: From Boardroom to Command Line

"Oxygen is good" doesn't help your engineers

I've been thinking about strategy lately, particularly about the gap between high-level company strategy and what engineers actually need to make decisions. It's a thornier problem than it first appears.

What Is Strategy, Really?

At its core, strategy is three things:

• Your vision of where you want to be

• The specific goals that support that vision

• How you're actually going to achieve those goals

Sounds straightforward enough, but if your strategy doesn't help people make decisions and say "no", it's not really a strategy at all. It's just a list of nice things.

It’s All Good Stuff

There's an old Dilbert cartoon that parodies executive strategy with three bullets: "Oxygen is good. Competition is bad. I like Jello." While that's clearly a parody, I've seen plenty of real strategies that when you stop and think aren't much more useful.

Take these real world common examples:

• "Engineers are empowered to make their own decisions"

• "We share tooling to increase efficiency"

Sure, both of these sound good. But what happens when they conflict? What if an engineer decides (empowered!) that the shared tools don't work for their team and they want to create their own? A good strategy needs to provide or enable guidance for these conflicts.

Just Say No

I learned this lesson the hard way at a previous company. Our strategy looked great on paper - laying out all the exciting directions that we were going to grow in. What it didn't have was any guidance on what we weren't doing or when we should stop doing something. As a result, we spread the engineering organisation progressively thinner because we were really good at starting new projects, and really bad at shutting them down - consuming resources ongoing that could have been better used elsewhere. We never quite killed them off because our strategy didn't give us a framework for making those tough decisions.

Beyond the Taglines

The other trap I've seen companies fall into is getting hung up on the perfect wording of strategy statements, that don’t have enough to unpack them for day-to-day use. I've sat through endless meetings where people wordsmith vision statements to death, while engineers are still wondering whether they should be spending time on automation tools or cranking out features.

The taglines are great to rally around, but the strategy isn't the carefully crafted taglines - it's what those taglines mean for people on the ground. Engineering leaders and managers need to translate high-level strategy into concrete guidance about things like:

• Time allocation between creating tools and building features

• Whether to focus on quick demos or solid regression frameworks

• How to balance supportability vs usability vs enhanceability, and which stakeholders matter most

• Which languages or technology stacks to invest in

• When to align tools across teams vs when to experiment

Making Strategy Work

So how do we fix this? A few key principles I've found that help:

1. Multiple Versions for Multiple Audiences Your strategy needs to be expressed differently for different groups. Executives need the high-level view tied to business outcomes. Engineers need concrete guidance about technical decisions. Both versions should align, but they need different language and detail.

2. Clear Decision Frameworks When principles conflict (and they will), your strategy should provide guidance on how to resolve those conflicts. Maybe "engineer empowerment" trumps "shared tooling" except for core infrastructure. Maybe it's the other way around. The point is, make it clear.

3. What You Won't Do Be explicit about what you're not doing. If you're choosing simplicity over flexibility, say so. If you're prioritizing rapid iteration over perfect stability, make that clear. These trade-offs are where the real strategic decisions happen. “Everything is important” is no help to anyone.

4. Regular Reality Checks Feedback loops are good! Regularly ask engineers about recent technical decisions they've made. Can they explain how those decisions aligned with strategy? If not, either your strategy isn't clear enough, or it isn't being communicated effectively.

The Bottom Line

Strategy isn't just for the boardroom - it needs to work all the way down to the command line. If your engineers can't use it to make decisions about whether to build or buy, which technical debt to tackle first, or what architecture to choose, then it's not really a strategy. It's just a collection of nice-sounding words.

Take the time to translate your strategy into terms that matter for each group in your organization. Your engineers will thank you for it - and your strategy will actually have a chance of working.