In the early days of writing my book, when I was listening to people tell me what they thought strategy was, I often heard people break it down using this analogy:
Strategy: Take the hill. Tactics: Skinny guys behind trees, fat guys behind rocks.
It’s not a great use of time to debate exactly what is a strategy and what is not, butÂ what makes more sense to me is something more like this:
Goal: Take the hill. Strategy: Skinny guys behind trees, fat guys behind rocks. Tactic: Find the nearest rock/tree that will help me get closer to the hill.
Some people seem to think that strategy needs to be a comprehensive statement of what you’re doing and how. I think it’s better to have a number of smaller strategic approaches that can be joined together – a modular approach to strategy.
If you’re waging a war, playing a football game or trying to do whatever it is your organisation does, the kind of strategy you don’t want is a ‘play by play’, an inflexible, linear strategy that requires the entire world to stay exactly as it is (or exactly as you plan it to be) in order for your strategy to succeed.
Most of us now operate in environments that are crazily complex and uncertain, subject to unpredictable change. Competitors do surprisingly good things, financial sectors have unpredicted crises, a whole new programming language is required (or deprecated) by an company that is critical to accessing your end users, a butterfly flaps its wings….
The kind of strategies you need are ones that the troops can apply even when they get separated from their commander and each other. That allows them to know what they should be doing without relying on being told. It allows them to reliably predict what all the other brave soldiers would do in any given situation. This allows the company to behave in a reasonably unified way.
Having a collection of easily remembered, easily applied strategies work best. Strategies that everyone in the organisation can apply. Strategies that are complementary and integrated. Strategies expressed with carefully chosen words.
Someone commented in on a previous post saying that although GDS says ‘the strategy is delivery’ this is not a strategy because it doesn’t say what is being delivered. This is true in as much as ‘the strategy is delivery’ is not the only strategy in play, but I’d argue that it is still very much a strategy and is used in a strategic way.
Modular strategy works something like this.
Combine ‘start with user needs‘ with ‘making digital services so good that people prefer to use them’, ‘the strategy is delivery‘ and ‘show the thing‘ (four strategies that are widely in use at GDS). This tells the team an awful lot about what they should be focussing on and how they should be working.
You can apply this at a project level – what should we be working on and prioritising as a team right now? Answer: quickly making a thing (probably a prototype to being with) that addresses the things that are most important to the end users (or finding out what that is if you don’t know), making it as easy for people to understand and use as possible, getting stuff live, iterating based on research, analytics and feedback.
Apply this at an individual level and you also get a lot of guidance. As a user researcher, for example, we are constantly focussed on understanding our users and their needs, and working with the team to iterate design improvements and test new features. We take a delivery focussed approach – optimising for providing actionable insights for our team over taking the most robust research method.
When you’re doing something for the first time, when you’re choosing between different approaches, deciding what to do and how to do it, when there is no one around to tell you what you should be doing – you can go a long way to doing the best thing by applying these strategies.
Have a clear goal – know which hill your organisation wants to take, but then have a whole load of strategies that can be combined to help project teams and individuals be empowered to make decisions that are aligned and will all work together to help achieve the goal.
This is the fifth post in a series of rambles around the topic of strategy in the general vicinity of user experience which I’m posting as a kind of obituary to the book I almost finished writing then realised was pretty much completely wrong. This is some of the stuff I probably should have written instead. You can see the first post here, the second one here, the third one here, and the fourth one here.