Locally rational; strategically irrational
Image credit: Peter Hansen via Unsplash
Enterprises frequently find themselves sliding down the slope from strategic rationality to strategic irrationality, while acting in ways which seem locally rational. To put it another way: if everyone’s so busy, how come we’re not going anywhere?
Working for a large enterprise can feel like being on a ship where the boiler is being stoked, the engines are churning, the propeller is turning, the kitchen is turning out meals, the brasswork is being polished, but, when you look out the window, you are still at the dock.
Actually, that might be too optimistic: many enterprises feel like a ship where the coal is being delivered to the kitchen, the stewards are working in the boiler room and the navigator is holding the charts upside down.
And if you work in technology, it often feels like the engines are overdue for a service, steam is escaping from the valves, and the pumps are struggling to keep the water at bay, but despite the constant, frantic activity, basic maintenance does not seem to be anyone’s job.
Large enterprises feel this way because of the long gap between strategic intent and local action. They set goals, driven by their mission, the expectations of their shareholders and investors, the dynamics of their market, or the ambitions of their executives. If those goals are suitably big and bold, they cannot be achieved by a single action: the whole of the enterprise must be mobilised to achieve them, usually over an extended period of time. The strategy is divided into chunks, and those chunks are disseminated across the organisation, into divisions, business units and teams.
This is, in itself, an entirely rational step to take: how else can we get work done which is too big to be executed in one go? However, enterprises often fail to recognise that, in dividing up work and allocating it to teams, they set local conditions of rationality for those teams, and those conditions are unlikely to be identical to those of their strategic goals. For example, if your strategic goal is to transform the digital experience of your customers, and you create a project with a fixed time and budget to achieve that goal, you have made it rational for your project team to optimise for time and budget, whatever the impact on your customers’ digital experience.
And when things go wrong, as they so often do (so often that things going wrong can reasonably be regarded as inevitable), we are often tempted to change the local conditions of rationality once again. If the project goes off the rails, and we respond by increasing reporting frequency, setting up ‘challenge’ sessions, and scrutinising every estimate, then we make it rational to optimise for the satisfaction of management oversight. We make it seem rational to accept future regrets (skimping on testing and security reviews; deferring the support model) for the sake of immediate relief from pressure (reducing the number of red items on the project report; avoiding a change request).
Large enterprises often feel like busy ships which are going nowhere because they create conditions in which it is rational for everyone to optimise with extreme locality (for their boss, for their performance review, for the weekly update, for getting through this meeting without being asked a difficult question), to work hard and do their best in good faith, whether or not they make a difference to strategic goals.
This is not new news, and there are many leadership mechanisms which attempt to overcome this phenomenon. Leaders can publicise and promote the company strategy, and do their best to make everyone feel connected to it (but does the boss that sets your objectives and rates your performance feel just as connected?). They can attempt to construct cascading metrics which ensure that local action is driven by strategic outcomes (but how many of us are adept at designing metrics which drive behaviour and link global strategy to local action?). And they can attempt to create organisational designs in which autonomous teams self-organise and choose actions to achieve strategic goals (but how successful have we been in creating genuine autonomy, and preserving it when things get tough?).
All of these mechanisms and more are worth pursuing: difficulty should not discourage attempts to lead well. But no single mechanism will do the job on its own.
Unsurprisingly, one of my favourite mechanisms, particularly for enterprises whose success is dependent on their digital capability (aka: all enterprises), is to make sure that your technology organisation has plenty of architects. It doesn’t matter whether you call them Enterprise Architects, Technical Architects, Solution Architects or something else, as long as their role is to connect global strategy to local action and as long as they are expert and empowered.
It is often said that one of the key tools of a technology architect is to keep asking why, at least five times, to get to the fundamental truth of problems, needs, circumstances and motivations. I believe that it is important for architects to use the why of persistence as well as the why of curiosity, to be the people who remind us why we set out to do something in the first place, to question whether the action that appears locally rational is also strategically rational. That can be irritating, but, when they are doing their jobs properly, architects are often challenging to work with, and challenging to be.
