I’ve always seen strategic decision-making as consisting of a large element of guesswork. It’s educated guesswork, but it’s very much taking a punt on what we want to achieve based on our assessments of how certain situations will evolve and where we want to be positioned at the end of that. And we can never know in advance how things will really evolve.
On the other hand, once a strategic direction has been set we need to make day-to-day tactical decisions based largely on evidence. We need to listen to our users or customers, and react to what they are telling us. Combining that evidence-based approach with a historic decision about predicting the future may seem tricky, particularly when we start seeing evidence that suggests things aren’t entirely as we predicted. How can we combine these approaches effectively?
This week I came across a good example of a successful approach to this. You can see it in the Windows Weekly podcast of 19 April 2017 at the 1 hour mark, in which the presenters interview Rich Turner. Rich is the Senior Programme Manager at Microsoft for Bash on Windows and Windows Console—projects which allow GNU/Linux tools to run directly on Windows. The whole interview is fascinating if you like that sort of thing (and I do), but here I want to highlight how the team combines a strategy with hard evidence.
The strategy is about keeping software developers on Windows (or bringing them to it) by enabling their GNU/Linux development tools to run directly on the Windows 10 operating system. It’s an audacious proposition, and they are achieving this by implementing a vast number of Linux system calls in the Windows kernel. For the purposes of this conversation, though, the technicalities are less relevant than the rough numbers:
- the more developers there are on Windows the more successful they have been; and
- they make this happen by implementing more system calls more completely.
(Regular readers will recognise that these descriptions tie in with my constant desire to measure your goals.)
The strategic decision is that Microsoft will be better off with more developers sticking to, or coming to, Windows. The team’s day-to-day success and progress is measured by completeness of system calls.
In order to prioritise their work, Rich’s team collects data about which system calls users are making and which are failing the most. Fixing or implementing the failures is what they put at the top of their to-do list.
But just going by that list of most-failed calls would not deliver the strategic aim. They also have to consider which of those calls are for development tools. The team is small, and so they really have to focus their efforts. As an example of this, Rich said that lots of people have asked for graphical tools such as Firefox to be enabled. But he said this is not a priority for them because core development tools are all based on the command line (text only). So implementing graphical system calls is not something they will spend time on in the foreseeable future. On the other hand they have just implemented calls to access serial ports and therefore (say) allow someone to programme an Arduino board.
Overall, then, their approach is to separate user needs (have frictionless development tools) from user wants (e.g. graphical tools), and they have used the evidence which informs their understanding of the user needs while generally filtering out evidence that provides interesting but non-strategic guidance.
They are not allowing users’ wishes to derail the strategic objective. But their approach does allow the strategic objective to be delivered by means of hard evidence.