On gamification

One of the themes that’s come up during our Patreon-funded further development of ‘the bucket-list’ suite of change-guidance tools is that of gamification – using some kind of game to guide the process of sensemaking and decision-making for a given context.

Yes, agreed, it is a good idea – yet only when subject to certain really, really important provisos.

The TL;DR version of those provisos is that for enterprise-architecture and the like, we need to play any game to learn, rather than to ‘win’.

The key to all of this is the crucial contrasts between ‘finite-games‘ versus ‘infinite-games‘, as described in James T. Carse’s classic book Finite and Infinite Games (full-text: PDF):

A finite-game is played to rules. It has a distinct start-event, and a distinct end-event – usually when a specific condition is met, such as the end of a specific period of time. At the end of a game, someone is usually deemed to have ‘won‘, and that others have ‘lost’ – there are ‘winners’ and ‘losers’. That outcome of a finite-game is ‘final’, unchangeable and, in most cases, a true/false distinction without shades of grey. Once a game is over, another game may be started, at the end of which there may be different ‘winners’ and ‘losers’, but this does not change the outcome of any previous game. (The only exception to that is if some player is deemed to have ‘cheated’ or suchlike – in other words, played ‘outside the rules’.)

An infinite-game is played without rules (though it may be played in context of identifiable constraints, some self-chosen, some imposed from ‘beyond’ the game). An infinite-game has no distinct start-event, and no distinct end-event – in effect, it simply ‘is’. Because there is no distinct end-event, there can be no ‘winners’ or ‘losers’. Instead, the aim of the game is to learn – more usually, how to play the game better.

In terms of ‘tame-problem versus wild-problem‘, a finite-game essentially represents a class of tame-problem; an infinite-game represents a class of wild-problem (or ‘wicked-problem’). In development of an enterprise-architecture, we will more commonly face wild-problems rather than already-defined tame-problems.

A finite-game cannot challenge its own rules, because it is inherently dependent on the existence of those rules. (If the rules are changed it is, by definition, no longer the same game.)

A finite-game always exists in context of one or more infinite-games, as a means to define or change the rules of that finite-game.

For example, a tennis-match is a finite-game: it follows distinct rules, with a distinct-event and end-event via which it is possible to determine the ‘winners’ and ‘losers’ of that match. Each player will play to win the respective tennis-match. Yet each tennis-match takes place within the context of the infinite-game of tennis itself – within which the most common aim of the game is to learn, and more specifically to learn to play tennis better. (This may be in context of broader infinite-games, such as ball-games in general, or team-oriented exercise in general.)

To put it somewhat the other way round: within the finite-game of tennis, winning is the aim – not learning. Any learnings that may happen in context of a tennis-match are incidental to the match, and may even be a distraction to the aim of the match. But if the broader infinite-game of tennis is ignored, and the focus held only on the finite-game aim of ‘winning’, there is no longer any context within which to learn. In most real-world contexts, a ‘winner’ who fails to learn is unlikely to remain a ‘winner’ for long…

In designing gamification for enterprise-architecture and the like, we therefore need to be really careful about how we balance the various trade-offs here. Finite-games are great for generating the kind of passions we need to get people engaged in exploration; but the moment the aim shifts too much towards ‘win at all costs’, and too far away from infinite-game aim of learning, the game loses any practical point.

Much as per the Architects’ Mantra, the key here is ‘Just Enough’ – or, in this case, ‘Just Enough Winning’. For games in change-guidance and the like, too much ‘winning’ actually leads to losing, in the broader sense which, for sensemaking, is the one that actually matters…

That’s the criterion that we’re now watching most closely as we develop our own ‘game’-based tools for sensemaking and decision-making in EA and the like.

How do you keep the balance right in your own efforts and experience of gamification in business and elsewhere?

Posted in Business, Complexity / Structure, Enterprise architecture, Knowledge Tagged with: , , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*