Faster, Better, Stronger is not a Strategy

Leading an area of engineering often means that every now and then you need to define an engineering strategy. This work can be especially prominent for platform engineering teams where much of the work is important yet not urgent.

One type of strategy you can often see presented for platform teams is what I call faster, better, stronger – aka we want to support more users, handle more traffic, improve reliability, reduce costs, and here's how we're going to do it. There's nothing wrong with any of these goals, but most of the time there wouldn't be anything strategic about them either.

In this article, I'll explain why, and share my mental model of what a good platform strategy looks like.

What is a strategy?

First, let's establish what a strategy actually is. The classic book on the topic is Good Strategy/Bad Strategy by Richard Rumelt. The book describes three main components of a good strategy:

• Diagnosis – understanding the challenge and identifying the critical aspects of the current situation.
• Guiding policy – a high-level approach to overcoming the challenge.
• Coherent actions – a set of coordinated actions that implement the guiding policy.

The key point of a strategy is that it's a response to a challenge the business is or will be facing – it's a solution to a particular problem, and not a description of how the current system can be improved.

When defining a platform strategy specifically, I find it useful to think of it in terms of making a bet. Based on observations about the present, you make a bet on what the future will look like – an insight, and choose how to position your platform to benefit from it.

What does the insight come from?

So, you need an insight. You need to stop, look around, and understand the current state of the world to try to figure out where things are going. There is a particular challenge that presents itself for platform teams – as they don't build the product itself, but rather support the product teams, their strategy will often require a level of indirection.

One has to understand the direction of the business, then also understand what the product teams will be building in a year or two, how their requirements will change, and what limitations of today's platform will prevent them from doing so.

Large changes to a platform can take time, in large companies sometimes years. By the time product teams start asking for a new capability, it might already be too late to build it. It's useful to ask product teams what they think they'll want to build in the future. But the question must be presented carefully as most product teams would be much more inclined to tell you about the problems they're facing today, especially when asked on the spot.

And this is what I meant when I mentioned a bet above – based on all the information you've collected, you'll need to predict which challenges will matter most in the future, with no guarantee that you'll turn out to be right.

Making a bet

Now that you've got an insight, the next step is to figure out what the most beneficial position for your platform will be if your bet turns out to be correct.

And here's another trap that I've seen in strategies in the past – describing a perfect future, a perfect platform that you'd like to build. While it's a useful exercise, actually reaching that perfect state will likely be prohibitively expensive. After all, every engineering organisation has more work than it can reasonably complete.

Instead, a strategy is about prioritisation, it's about making a choice – what to work on, and what work to give up. If you believe that a particular capability will become critical in the future, you will need to prioritise building it over other improvements. Moreover, based on what you think the future will be, some improvements might simply be wasted effort despite some engineers, including yourself, wanting to work on them.

Tying it all together

Going back to the book definition of strategy, the insight into what the product teams will need in the future becomes the diagnosis, and the choice of capabilities to prioritise becomes the guiding policy. Based on them, you can prioritise the engineering investments as a set of coherent actions.

Altogether, this becomes a strategy that allows you to make decisions about what to work on, and even more importantly, what not to work on.

Of course, making the platform better, faster, and stronger is still important. And sometimes these improvements might be exactly what your strategy needs to call out. Yet, the difference is that now it's based on the specifics of the challenge the business is facing.

Ultimately, if your strategy doesn't help you choose between two perfectly reasonable engineering investments, then what is its purpose?