Eight to Late

Sensemaking and Analytics for Organizations

Towards an antifragile IT strategy

with 4 comments

Introduction

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.

Decentralisation

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.

Agility

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:

  1. 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.
  2. 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.
  3. 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.

Diversification

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:

  1. 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.
  2. 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.
  3. 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!
  4. Set up small, low-cost skunkworks projects to explore technologies and ideas that have the potential to provide your business an edge.
  5. 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.

Summing up

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.

Written by K

June 3, 2014 at 8:59 pm

4 Responses

Subscribe to comments with RSS.

  1. […] Kailash Awati extracts some thoughts on antifragility from Nassim Taleb’s recent book, and applies them to IT strategy. […]

    Like

  2. […] to benefit from uncertainty rather than just being resilient to it. After I read the book I wrote a post on what an antifragile IT strategy might look like…and in an uncanny resonance with what you just said, I made the claim that trust would be the […]

    Like

  3. […] a post inspired by the book, I outlined the elements of an antifragile IT strategy.  One of the key points of such a strategy is the assumption that, despite our best laid plans, it […]

    Like

  4. You might be interested in a book by Henry N. Pollack, Uncertain Science, Uncertain World. It would help organizations who want to strategize about the future to learn some of its characteristics.

    More research does not mean less uncertainty. A little dose of future reality can be worth much more than a large dose of research. All research is on this side of the timeline, trying to predict things on the other. The future is not just a continuation of the past. Knowing more about the past does not guarantee the accuracy of predictions.

    Research hardly ever finds a silver bullet or the one right answer. The future is unlike the past in many ways. It is unlikely that research will find all of its assumptions satisfied in some future scenario and its analysis precisely correct. The odds of a single or simple solution resolving a complex problem are low. The odds of research finding it are also low.

    Some issues cannot wait for clarification. They may have long developmental time scales. Natural processes take many years to change. Glaciers move at a well, glacial, pace. Even after changes have occurred, it may be a long time before they are detected. Issues may also have uncertain tipping points, i.e. irrevocable changes that precipitate future outcomes, events or conditions. Waiting to detect reaching a tipping point eliminates the possibility of solution. Action must be taken before the situation it totally clear.

    Causes and consequences of problems are non-linear. Like the beat of a butterfly’s wings that may affect the weather, small causes can be amplified into large effects. Chaos reigns in the domain of complexity and uncertainty. Scenarios close together in one domain may resolve into situations very far apart over time.

    Such a strategy would recognize that the benefit/cost ratio of remediation is greatest when a problem is first recognized. The best time to put out a fire is when it has just started and is small. There is less damage and you need much less water. Waiting allows problems to grow and their eventual remediation costs to increase. The amount of resources needed for remediation will normally be less at the beginning.

    Uncertainty will never be eliminated. Until the future arrives, it remains uncertain. If a solution needs precise alignment to be effective it is unlikely to attain perfect aim. Research to reduce uncertainty will have diminishing returns. Analysis and research will consume resources and time that could be put to better use.

    Surprises are the rule, not the exception. This is another way of saying the future is not just a continuation of the past. It is a bad idea to craft solutions with this as an assumption. Predictions don’t usually work past discontinuities. Strategies should be designed to survive and overcome surprises.

    Uncertainty must not lead to analysis paralysis. Rounds of study and refinement of research are common responses to uncertainty. Paralysis can be avoided by acting on the future instead of studying it. In the real world time lost in paralysis it time that could have been better spent.

    ‘Optimal’ strategies may not be optimal. These are based on assumptions of the past and cannot be guaranteed with any certainty. Optimality is a property of the past that may not survive into the future.

    This would lead naturally to a strategy that would reduce uncertainty through action, not research. A little taste of the future is worth more than most research. Don’t waste a lot of resources on it. The future is only a moment away. Play with it, act on it.

    Take incremental steps. Despite the non-linearity of the consequences, it is best to try things out in the small before making large changes or investments. Don’t jump into the future with both feet. Stick a toe in, first. Experiment. Learn something. Make adjustments.

    Explore a wide range of future scenarios. You will always be uncertain of the true nature of your reality. The way to come close is explore a variety of potential futures and define scenarios around them. One or more may prove to be accurate. Or, maybe a few will bracket the true situation by being close and surrounding it. This is more likely with a larger number that covers a large area of possibilities.

    Seek robust strategies that do well across many scenarios. Given the uncertainty of knowing the true scenario, it is not wise to invest in just one. Strategies that may be successful in more than one scenario require amplify their value in the overall scheme of things and increase the likelihood of problem resolution. Strategies that operate in various scenarios may cover the undiscovered ones in between, or beyond.

    Monitor the future as it unfolds. It will do so quite differently than you expect. Surprises need to be detected so that non-operative scenarios and strategies can be abandoned, existing ones refined, and new ones formulated. Sensitive tipping points require monitoring to prevent large negative non-linear effects.

    Make mid-course corrections, as needed. Plans found to be in the wrong direction need to be adjusted. Abandoned strategies need to have their resources reclaimed and reinvested elsewhere. New scenarios are needed to answer the incremental taste of the future. New strategies and new directions need to be established. The target may be moving.

    I see that you are going in the right direction with your advice.

    Rick

    Like

    Rick Bollinger

    November 17, 2014 at 9:37 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: