“Defense network computers. New... powerful... hooked into everything, trusted to run it all. They say it got smart, a new order of intelligence. Then it saw all people as a threat, not just the ones on the other side. Decided our fate in a microsecond: extermination.”
Kyle Reese, The Terminator
One of the common criticisms of executive teams that fail to achieve good outcomes is that they failed to see a problem that later crippled their organisation. Built into this criticism is an implicit assumption that executives can both see everything to which their organisation is exposed and can understand that data point in the context of every other one.
Hindsight is a fine thing. Executive teams are not like Skynet’s CPU. They are collections of human beings and subject to human failings. It is, however, somewhat useful to imagine the executive team as a processor, sitting at the centre of an information system. This information system is built to an information architecture, which governs how data is ingested, how it flows and is processed into instructions for the organisation to follow. Understanding the blocks of this information architecture and improving their performance gives the executives in the ‘central processing unit’ the best possible chance of making more good decisions than bad. At the most basic level I like to draw the information architecture like this:
As with any computer, the executive team functions to a programme. In a public company, programmes are typically set by the board as a set of parameters (revenue, cash, market share, acceptable markets within which to operate). All organisations have such a programme, although the fidelity and honesty with which it is supplied to executives inevitably varies.
The programme provides one set of ‘weights’ that are applied to data within the executive team and its supporting infrastructure. There are other weights too, of course, such as personal heuristics and the arbitrary rules that are imposed by governing bodies or the organisation’s historical experiences. The sum of these weights are what tilts a group to focus on one issue over another and ultimately to favour one potential solution over others. In the ideal world every decision-maker would have the same set of programme-related weights but they don’t and we therefore have to design an information architecture that can deal with such imperfection of intent.
In any case, the executive team’s programme should enable them to sketch a picture of the sort of strategy that they intend to pursue. They start from a model of reality that takes internal and external signals and forms them into a picture of the world the organisation inhabits today. A good reality model encompasses facets of the market outside as well as the effectiveness of the capabilities it has to change that market. Signals flowing into the organisation may contradict or confirm aspects of that reality model, some of which need to be acted on to further the programme. The degree to which those changes are perceived at all or are perceived to be important depends on weights and biases.
The perfect leadership team in the perfect organisation would be able to rapidly and decisively prioritise potential issues and opportunities for resolution. Information selection is always imperfect to some degree, which is inevitable and fine, provided that the information architecture as a whole is able to cycle reasonably fast. If decisions take a long time then poor information selection is a real problem because the cost of going back and starting again is time consuming and difficult to accept. The sunk cost fallacy acts against change most obviously in this kind of business.
Potential solutions to the problems caused by new information are prototyped within the team or on its behalf. In the latter case, often deemed necessary because of constraints on the executive calendar, subordinates or external agencies may be employed to develop potential solutions, assess the viability of potential solutions and even to recommend a particular path forwards. Outsourcing decisions is somewhat dangerous as concepts developed on behalf of decision-makers are rarely as well understood or as well loved as something developed by the decision-makers themselves.
An action is selected from the prototypes in a decision-making stage or process and then communicated to the organisation in a set of instructions. A high degree of accuracy and precision is required in this communication, offering up a further reason why decision prototyping needs to be done by executive managers rather than by subordinates.
Although simplified, seeing executive decisions in this manner is helpful because, similarly to the taxonomy of executive roles, it enables us to have rich conversations about how to optimise performance. Stating ‘we’re great at decision-making’ misses the opportunity to understand what types of decision an organisation is good at and why that is so.
By way of example, I’ve been working with a client recently that is superb at dealing with immediate crises and medium-term resource allocation. The reason for this, it turns out, is that they are really good at using internal performance data and pre-set ‘decision prototypes’ to rapidly arrive at and communicate sound conclusions. Their issue is with imaginative challenges. In some ways they’ve over-optimised for particular decision types, so that they are comparatively poor at taking in longer-cycle trend signals and creating new decision prototypes. Finally, they struggle to communicate how to do something different because they are used to very discrete targets, rather than relatively directional ones.
So now we can see where we can work with the business and the executive team to identify particular decision-making scenarios and then apply different methods to solve them. Next time I’m going to take a deeper dive into what goes wrong across the information architecture, based on case studies of famous business failures.
If you can’t wait that long, then I’ll direct you to The Point Of Maximum Uncertainty, available now :).
Comments
Post a Comment