What can technologists learn from board games?
Photo Credit: Christopher Paul High via Unsplash
Have you played a board game recently?
If not, you might find that they are very different from the games of Monopoly, Risk and Scrabble that you are familiar with. Many of today’s board games seem bewilderingly complex, packed with counters, cards and other components, described by intimidating rulebooks, and based on unlikely themes: cross-Atlantic trading in the 17th century, subsistence farming in the Middle Ages, and the construction of stained glass windows (these are all real games).
However, like any hobby, I think that they are worth paying attention to (and I have to admit that I have spent plenty of my own time playing these games). It’s a useful rule of thumb that, even if an activity seems uninteresting or difficult to appreciate at first sight, when a lot of people invest a lot of time in it, then it is good to be curious about it. Even if it’s not for you, you will learn something new.
In this case, I think that those of us who work in enterprise technology can learn something from the category known as engine building games. These are games in which there’s not much you can do when you start, but, as the game progresses, you acquire more and more powers and abilities. For example, in the game Agricola, you start as a farmer on the edge of starvation, but over the course of the game you build fields and paddocks, you plant crops and raise animals, and create a system which supports you and a growing family. (If you’re interested in this type of game, then Agricola can be notoriously hard to learn, though: Splendor, a game about jewel trading, is a much easier place to get started - and, unlike some of these games, which can take hours, is quick to play.)
The interesting thing about engine building games is that, if the game is well designed, you continuously have to make trade-offs between immediate rewards and future rewards: between taking prizes now, or building the engine that will enable you to take more prizes later on. Most of the time, deferring reward is the best choice: by the end of the game, the player that has built the best engine will be far ahead of the player who is still scrabbling around with their starting abilities, even if that player had an early lead.
The obvious parallel in enterprise technology is the way we build and run software. A good software team (whether we call it a pod, a product team, a DevOps team or some other name) knows that it is in the engine building game: it is not simply concerned with the next release or the current incident, but is concerned with the practices, capabilities and tools which make the next release better, or resolve the next incident more quickly (or avoid it altogether). Such a team is continuously improving: it knows that it is its own engine.
And yet, despite the demonstrable value of such engine building behaviours, it is still rare to find them in most organisations. Even after many years of disciplines such as product management, Agile, DevOps and, latterly, SRE, all of which are aspects of engine building, much software development work is still run as one-off projects, where the sponsor does the equivalent of taking an immediate prize now, rather than creating the ability to take many more prizes in the future.
As ever, I don’t think that we can blame our non-technologist sponsors for this problem. I think that, amongst the many challenges we have in explaining enterprise technology, explaining the importance of engine building is one of the hardest. Non-technologists have a hard time understanding the complexities of a single project lifecycle: understanding the meta-characteristics of the engine that underpins that lifecycle is even more difficult. Of course, I don’t think this means that we should give up: it is, after all, our duty to explain. There are four ways we can attempt this - although none of them is easy.
First, we can remind our sponsors that, when they invest, they are not simply buying the output of the engine: they are buying the engine too. This is true even if they are serial purchasers of projects from different systems integrators: they are just buying a new engine with every project, and throwing it away without prospect of improvement.
Second, we can, with patience, diligence and time, demonstrate the value of engines which continuously improve themselves. This means that we need to adopt simple metrics which demonstrate continuous improvement, and show why they make a difference to our sponsors: velocity, measured by release frequency, and reliability, measured by incident volume, are my favourites.
Third, we can adopt vocabulary which continuously reminds people that the engine exists. I must admit that I am sometimes guilty of simplified language which does not do this job: I like to talk about platforms (which emphasizes the importance of technology capabilities which can be used widely across an organisation to provide a reliable, scalable, software-defined place to do great software engineering and data science) and products (which emphasizes the importance of multi-disciplinary teams with the skills and autonomy to deliver outcomes which matter), but don’t often talk about engines (which emphasizes the importance of the efficiency, operations and capability of the team, separate from the features of the product). I’ll have to modify my language.
The fourth approach is a highly speculative one. The board games I described at the beginning of this article are fun and simplified simulations of the real world. The best games leave you thinking both about their rules and the situations which they represent. If there is an aspiring game designer out there who could make an engine building game about software development (or has already done so), it might give us a helpful way to engage people. Games have been made about stranger things.
