Towards an antifragile IT strategy
In his thought-provoking book on antifragility, Nassim Taleb makes the point that the opposite of fragility is not robustness or resilience, rather it is the ability to thrive on or benefit from uncertainty. There is no word in the English language to describe such behavior, and that is what led him to coin the term antifragile.
Nature is an excellent example of an antifragile system: whenever subjected to a cataclysmic event (like this one that occurred ~66 million years ago), nature manages not only to recover, but does so in novel and arguably better ways. Unlike nature, however, most human-made systems tend to be fragile. An example that Taleb highlights is the global financial system , not just prior to the 2008 financial crisis but even now.
The broader lesson to be learnt from the financial crisis is that it is impossible to predict the future in any detail. Systems should therefore be designed to cope with (if not take advantage of) the irreducible uncertainty associated with this lack of predictability. Human-made systems that overlook this inescapable fact tend to be brittle by design.
The above is true not only of systems, but also of future-directed activities such as strategic planning. Overlooking the role of irreducible uncertainty in planning invariably locks an organization into an inflexible course of action. Unfortunately, this is not always appreciated by those who run organisations. As Taleb puts it:
Corporations are in love with the idea of the strategic plan. They need to pay to figure out where they are going. Yet there is no evidence that strategic planning works —we even seem to have evidence against it. A management scholar, William Starbuck, has published a few papers debunking the effectiveness of planning [see this paper, for example]—it makes the corporation option-blind, as it gets locked into a non-opportunistic course of action.
The trick, as Taleb hints in the above passage (and elaborates on in his book), is to plan in such a way as to take advantage of options that we are unaware of now, but might emerge in the future.
That, of course, is easier said than done.
In this post, I draw on Taleb’s book and my own experiences to discuss how one can formulate an IT strategy that thrives on uncertainty. Although my focus is primarily on IT, the points discussed have a wider applicability to strategic planning in general.
Towards an antifragile IT strategy
Before we get into antifragility, it is useful to take a brief look at how IT strategy is usually formulated.
Although some IT leaders will contest this point, a good majority of organisations tend to view IT as a cost rather than a strategic focus area. As a consequence, the objectives of an IT strategy are generally geared towards cost reduction and increased efficiency. The obvious ways in which to do this are through strict governance, standardization and/or outsourcing. Unfortunately, these actions tend to make organisations less flexible and hence more susceptible to uncertainty…and thus more fragile.
So, the key to an antifragile strategy is flexibility…but what exactly is flexibility?
The best definition of flexibility I have come across is the one proposed by Gregory Bateson who defined it as uncommitted potential for change (see this post for more on Bateson’s definition of flexibility). Only if one is flexible in this sense can one take advantage of unexpected events when they occur. The problem of formulating an antifragile IT (or any other!) strategy thus boils down to finding ways in which one can increase one’s flexibility. With that in mind, here are some suggestions.
This one is going to raise some eyebrows because the general trend in the world of corporate IT is to move in exactly the opposite direction – i.e. towards greater centralisation. The drive to centralisation manifests itself in many different ways: from top-down decision-making to the deployment of standardized processes and pan-organisational “enterprise” applications (single instance ERP systems being an extreme example).
The justification offered by advocates of centralisation is that it increases efficiency and reduces cost by using a one-size-fits-all approach. In reality, however, such an approach almost always has undesirable features. For example:
- It overlooks the unique features of different structural units of the organization (subsidiaries in different countries, for example). Indeed, this is precisely at platform standardization fail – see my post entitled, The ERP paradox for more on this point.
- It increases coupling between different structural units. Since systems and processes have a global reach, an unexpected glitch in any of these will affect all structural units within the organization.
Decentralisation basically amounts to giving structural units the autonomy they need in order to make decisions and choices that affect them. To be sure, this must be balanced with some oversight and direction from a central authority, but the overall aim should be a federal structure rather than a centralized one. A few examples of things that can be controlled centrally include network infrastructure, security…and possibly even things such as preferred vendors, especially from the perspective of getting volume discounts on pricing. There is no black and white here: choices need to be made judiciously and revisited if they don’t work.
I use the term agile here in the sense of adaptability rather than as a reference to the slew of methodologies that go under the banner of Agile. Indeed, agility in the sense I use it here is more about a mindset than a methodology: if you are adapting to a shifting environment by changing your approach and priorities appropriately, then you are being agile in the sense of adaptability.
So, what does agility entail? Here are some things I see as being important:
- Responding to changes within and outside the organization…but only after determining that they need to be responded to. The qualifier is important: one must be able to distinguish between changes that merit a response and those that don’t. Moreover, any change should be instituted in a gradual or incremental fashion so that one can adjust one’s approach and take corrective actions if needed. Agility does not imply rapid, large-scale change.
- Sensing (or even creating!) new opportunities and taking advantage of them. The term intrapreneurial is often used to describe such a mindset. Many IT leaders are aware of the need to do this, but don’t always know how. In my experience, instituting a dedicated innovation group isn’t the best way to go about it. Instead, it may be better to focus on creating an environment in which people feel inspired to try new things. One of the ways to do this is to actively encourage staff to learn by experimenting on company time – say, one Friday afternoon per month – with no expectation of useful outcomes.
- Building flexibility into your external contracts so that you can respond to changes that weren’t foreseen when the contract was drawn up. Essentially this amounts to building a trust-based relationship with your vendors (see the last point in the present post for more on this) and factoring in transaction costs in your outsourcing deals.
An agile mindset is unlikely to thrive in an IT department that is bogged down by overly onerous rules and procedures. To be sure, rules and processes are necessary, but not at the expense of flexibility.
One of the keys to being antifragile in financial investing is to spread one’s investments over a range of different products. In analogy, one of the best ways towards developing an antifragile IT strategy is to diversify elements of your IT environment, especially those things that are likely to be negatively affected by uncertainty.
Here are some examples:
- For coverage in times of trouble, ensure that your team consists of people with overlapping sets of skills. This should be reinforced by periodic cross-training of staff in all key technologies that are used within your organisation.
- Hire people with different thinking styles. Your teams should contain a mix of people with analytic and synthetic approaches to problem solving. Most uncertain situations require both types of approaches.
- Diversify your vendor base. Among other things this means do not…and I repeat, do not…tie yourself to a single vendor by signing a multi-year, multi-million dollar contract!
- Set up small, low-cost skunkworks projects to explore technologies and ideas that have the potential to provide your business an edge.
- Seek to understand diverse viewpoints. Any important decision should be made only after soliciting and understanding viewpoints that are different from yours. Such an understanding will lead to better decisions than those made by relying on gut instinct or advice from a single source.
…and I’m sure there are many other possibilities.
Creating an environment of trust
I kept this for the last because it is possibly the hardest to put into practice. An antifragile IT strategy will only work if there is a mutual trust between all parties involved in a business relationship – be they managers and employees or IT folks and the businesses they serve. Although much has been written and spoken about trust, the fact is that it is conspicuous by its absence in the present day corporate world. Indeed, use of the word in corporate circles tends to evoke cynical reactions from the rank and file; it is seen as platitude rather than a word of significance.
Why is trust important?
Elinor Ostrom’s prize winning work established that trust is one of the core relationships that promote cooperation (see this post for more on this point). In situations of uncertainty, those who work in a high-trust environment would generally be willing to step outside their regular roles and work with others to fix the problem. In contrast those in a low-trust environment are likely to switch off or worse, start apportioning blame. On another note, people are more likely to share their ideas in a high-trust environment rather than in one that is riven by mistrust and unhealthy competition. I’m pretty sure that most readers would have experience of low-trust environments and would know from experience that such work environments are fragile in that they simply fall apart under stress.
It should be noted that that trust is also important in external relationships, such as those with vendors. Although purchasing and legal departments are quick to advise us about the importance of rock-solid contracts, in my experience it is far better to rely on trust. Indeed, it has been suggested that contracts can destroy trust!
Finally, just in case it is not clear: the onus for creating an environment of trust lies with management rather than the rank and file.
I offer the above as some suggestions aimed at making your IT environment less susceptible, even responsive, to unexpected external or internal events. Indeed, I believe that in times of uncertainty, they are likely to work much better than some of the well-worn but discredited command and control approaches that are inexplicably popular.
To sum up: IT strategies are invariably focused on improving efficiency and reducing cost. Typical measures to achieve this tend to reduce flexibility (tighter governance and outsourcing, for example). As a result most IT strategies are unable to deal with, let alone benefit from uncertainty. In this post I have outlined key elements of an antifragile IT strategy that can correct this oversight.
When I reviewed this piece just prior to posting it, I was struck by the fact that the points I have mentioned have more to do with social or ethical matters than technology. This reminded me of Heinz von Foerster’s ethical imperative:
“Act always so as to increase the number of choices.”
And that, quite possibly, is the perfect one-line summary of an antifragile strategy.