My thoughts about strategy are influenced by Mintzberg, who sees strategy formulation as an emergent process of trial and error that takes place during implementation. A company may start with a broad-brush deliberate strategy, but this strategy often overlooks some significant issues and risks.
These weaknesses need to be addressed as part of the execution of the strategy. Thus a more complete and correct strategy emerges out of the execution process.
Senior management sometimes take a long time to recognize and acknowledge the fact that the defacto (emergent) strategy is now better than the original (deliberate) strategy. And in some companies the original strategy is so bad, and the senior management so pig-headed, that there is little chance of a more sensible strategy emerging.
In order to see strategy and execution as co-evolving, we need to link both strategy and execution to outcomes. If the outcomes turn out unsatisfactory, it is surely a subjective judgement whether this is blamed on weak strategy or weak execution. And if the overall outcomes turn out to be satisfactory then we may suppose that any weakness in strategy was compensated by excellent execution, and any weakness in execution was compensated by brilliant strategy.
This of course depends on our notion of excellence. Some people might think that perfect execution means doing exactly what it says in the strategy, no more or less. Alternatively, we might define excellence in terms of achieving the best possible outcomes, thus excellent execution may need to depart from the official strategy if that's what it takes.
Which brings me to Nassim Nicholas Taleb's notion of antifragility. If fragility means that something is harmed when bad things happen, antifragility means that something becomes better or stronger when bad things happen.
So let me try to apply this notion to the current discussion. A fragile strategy is one that would fail if there are any deviations in execution. A robust strategy is one that would be unaffected by the quality of the execution. And an antifragile strategy is one that would grow better with deviations in execution.
Partly based on my contributions to a Linked-In discussion I wonder what the EA team is doing? (One person has deleted his contributions, so the discussion as a whole no longer makes much sense.) See also Fragile Strategy or Fragile Execution? via Storify.
Carole Cadwalladr, Nassim Taleb: my rules for life (The Observer, 24 Nov 2012)
John Crace, Antifragile by Nassim Nicholas Taleb – digested read (The Guardian, 2 Dec 2012)
David Runciman, Antifragile: How to Live in a World We Don't Understand by Nassim Nicholas Taleb – review (The Guardian, 21 Nov 2012)
I would call the strategy robust and qualify it as fault tolerant, eventually.
ReplyDeleteHow one implements that is a different matter. The subsequent roadmap can have branches for various future potential events.
Taleb's notion of antifragility is more than robustness or fault-tolerance.
ReplyDeleteA cake recipe is fragile if the slightest error by the cook, or the slightest unevenness in the oven, produces an inedible cake. A cake recipe is robust if it produces a decent cake regardless of the skill of the cook or the quality of the oven. And a cake recipe is antifragile if it produces a boring cake when followed exactly but produces a fantastic cake when the cook throws in whatever random ingredients happen to be in the store cupboard.
In your examples
ReplyDeleteA recipe is robust if whatever one throws into the recipe makes it no worse.
A recipe is antifragile if whatever one throws into the recipe makes it better.
In other terms, that may mean that the antifragile recipe was not good enough in the first place, or at least not finished. Or it is some kind of template recipe that awaits change.
But perhaps we read too much into it. Academics have to write books.
Following up on my tweet reply ('sandwich, pasta, rice are #antifragile dishes because they "gain from disorder": designed for mixing in to create new dishes'), I agree with your above description of the three types of cake (fragile, robust, and antifragile).
ReplyDeleteHowever, my cryptic point (due to the 140 character limit of a tweet) was that while a cake might be antifragile in THEORY, in PRACTICE cakes do NOT respond well when "the cook throws in whatever random ingredients happen to be in the store cupboard." (In fact, that's why the role of pastry chef is usually a separate role from the traditional (savory?) chef. :)
I therefore highlighted pasta, rice, and sandwhich "dishes" as REALISTIC examples of antifragile dishes. These "starches" (as they used to be called) are specifically intended to be used with "whatever random ingredients happen to be in the store cupboard." Perhaps the paradigm example is the Dagwood sandwhich!
I first thought of this class of food as "antifragile" (even though I didn't use that term) back when I first tried to explain the concept of a spanning layer (aka hourglass, bowtie) architecture to my wife. She asked me for a non-technical example (since the examples of the Internet and inter-modal shipping didn't do much for her).
So after thinking for a while, I said "Noodles!" Noodles are the narrow waist of the hourglass. You can make noodles from a small variety of ingredients--wheat, rice, spinach, squid ink, etc.--(the bottom of the hourglass) and they can be used to make a huge variety of dishes (the top of the hourglass). I then thought of similar "spanning layer" types of dishes (rice dishes, sandwiches, stews, pizza, etc.).
So it's my belief that spanning layer architectures are the most anti-fragile architectures because they are most likely to gain from "whatever random ingredients" you add to them. (Note I am NOT saying they always gain, just that they are the architectures most likely to gain.)
But note that John Doyle, who studies such spanning-layer architectures as well (though he usually calls them bowtie architectures), has pointed out in a number of papers that such architectures manifest "highly-optimized tolerance" (HOT), an inescapable (IMO) form of fragility. See for example, http://www.pnas.org/content/102/50/17912.full
The only way to deal with such HOT fragility (not overcome it though) is to create a panarchy: a resilient (or as NNT puts it "antifragile") network of HOTs (or as Buzz Holling refers to them, "adaptive cycles"). Panarchy is the basis on my work on Panarchitecture. See for example, http://bit.ly/PhYpO5
Why do I always have problems leaving comments on Richard's blog? :)
ReplyDelete"Unknown" (at least the unknown that left the comment about spanning layers) is me, Nick Gall. Why does it think I'm "unknown" when I verified my identity with my Google account?
Hello Richard,
ReplyDeleteI would suggest, as I did in Twitter, that antifragility is not a property of a set of instructions. It is a property of the person following the instructions.
In your cooking example, a cake recipe is a set of instructions. It is neither fragile nor antifragile. A talented pastry chef may improve the recipe by adding and subtracting ingredients. A household cook (like me) would probably just produce a mess. Assuming that the two of us started with the exact same recipe, would you call it fragile if one person changed it for the better and the other did not?
I believe that systems are fragile or antifragile. Our original discussion was about company strategy and the execution of that strategy. You specifically mentioned that strategy evolves and that it is quite likely that the resulting strategy is more robust and produces better outcomes than the original strategy.
In making that statement, you acknowledge that there are, in fact, two strategies. (at least). There is the starting strategy S.1 and the resulting strategy S.n. The strategy may have gone through zero to N modifications during execution.
If execution can make a strategy work, then we could say that success is a function of execution of strategy, or:
Success = Execution(S.1)
However, as you've noted, this is largely untrue. Execution changes strategy. The real formula would be:
S.b+1 = Execution(S.b)
Success = Execution(S.n) (where n>b)
Effectively, we refine the strategy until it becomes successful, and there we stop.
In that model, fragility is NEVER an attribute of the strategy itself, but of the Execution() function that is able to produce a new version of the strategy as it goes.
Note that every company will use a different "execution()" function. Some functions are NOT able to produce a better version of the strategy during execution. Other functions are.
In this thinking, it is the execution() function itself that has the attribute of fragility and/or anti-fragility, not the strategy.
The strategy is a cake recipe. The execution function is the chef.
--- Nick Malik
Nick,
ReplyDelete"Antifragility is not a property of a set of instructions. It is a property of the person following the instructions."
I couldn't disagree more. Antifragility is a property of the RELATIONSHIPS among people.
We all know that people are only only partially reliable. They get sick, they die, and even when they're performing at 100%, they are prone to myriad cognitive biases and competing, even conflicting priorities. The only way to create a robust system, much less an antifragile one, from such semi-reliable participants is to design a set of relationships among them that addresses their shortcomings: Checks and balances, editors and reviewers, substitutes, and alternatives, etc. These are just some of the relationships (roles) required to build systems that are more reliable than their weakest parts. This is as old as the concept of "a government of laws and not of men."
I don't know what one calls such relationship design: governance, architecture, strategy, etc. I just know that the structure of a system is as important to its antifragility as the antifragility of its components.
-- Nick Gall
It looks like NN Taleb is using the food analogy as well:
ReplyDelete"We take hummus, add an ingredient, say a spice, taste to see if there is an improvement from the complex interaction, and retain if we like the addition or discard the rest. Critically we have the option, not the obligation to keep the result, which allows us to retain the upper bound and be unaffected by adverse outcomes."
"UNDERSTANDING IS A POOR SUBSTITUTE FOR CONVEXITY (ANTIFRAGILITY)" (posted today 12/12/12)
http://bit.ly/Rpp3f0
Hi Nick,
ReplyDeleteThank you for responding. I think we may be agreeing more than we are disagreeing.
I stated that anti-fragility is not a property of a set of instructions but rather the person following the instructions.
You stated that anti-fragility is a property of the relationships among people.
Perhaps you read my statement too literally. My comment about "the person" refers to my metaphor of a chef. In a real organization, there are many people involved in executing a strategy and, I agree, that anti-fragility is embedded in the systems and relationships that bring them together. But in making that statement, I percieve that you've ended up agreeing with me that anti-fragility is NOT in the strategy itself.
The relationships between people are part of the "execution() function" not part of the strategy. The same relationships will be used, and reused, on multiple strategies. They are therefore, necessarily, NOT part of the strategy.
Another person with "Unknown" posted an exerpt from N.N. Taleb referring to a food analogy. Perhaps that was you as well.
Go through that excerpt and count the number of times that he used the words [we] and [us] (both implicitly or explicitly)
To make the implicit explicit, we'd rewrite his sentence as:
"We take hummus, [we] add an ingredient, say a spice, [we] taste to see if there is an improvement from the complex interaction, and [we] retain if we like the addition or discard the rest. Critically we have the option, not the obligation to keep the result, which allows us to retain the upper bound and be unaffected by adverse outcomes."
I count seven uses of [we] and [us]. So, what's more important in that sentence? The recipe, that is the starting place, or the person ([we] or [us]) that executes it?
What is anti-fragile, the hummus recipe or the capability of the chef to experiment successfully with it?
Would ANY chef be able to change the recipe successfully? If not, then the chef MATTERS. As you pointed out, the relationships between the people executing the strategy are IMPORTANT.
My point, that you appear to agree with, is that the relationships are NOT part of the strategy, but are, in fact, part of the system that executes it. Antifragility is therefore an attribute of that system, and not the original strategy.
Respectfully
--- Nick Malik
Nick, Thanks for your engaging response.
ReplyDelete(FYI, So far, I am ALL the "Unknowns" in this thread. I don't know why Richard's crappy commenting system ID's me as Unknown, since I authenticated myself using my Google Account. Whatever. :)
The point all my posts in this thread is that the antifragility inheres more in the recipe than the chef, or alternatively, more in the design than the execution. See my extended discussion of spanning layer dishes like rice dishes, sandwiches, pasta dishes.
A wide range of competent chefs can make myriad variations on the basic recipe of spaghetti and tomato sauce because those ingredients and the recipe for combing them tolerate a wide range of variation. The pasta can be a bit too overcooked or a bit too al dente. The tomato sauce can range from a bit watery to a bit too thick. I can throw in ground beef, cheese, beans, etc. And I'll still end up with a decent pasta dish.
That has MUCH more to do with the ingredients and the recipe than the chef.
Now I don't call a recipe a strategy or vice versa. I call it, in my previous posts, an architecture or a design. But as I also said previously, "I don't know what one calls such relationship design: governance, architecture, strategy, etc."
Let's turn it around. One of the most fragile recipes known to humankind is the souffle. The fragility is in the combination of the ingredients (aka relationships aka design). Even the most resilient, antifragile chef has a hard time making a souffle turn out. And forget about being able to throw in random additional ingredients, no matter how wonderful the chef. So the chef (or execution more generally) CAN'T be the source of the (anti)fragility.
I think the property of antifragility comes more from the DESIGN of a system than the EXECUTION of a system. Given an antifragile DESIGN, a system can tolerate a wide range of variation in EXECUTION, and not only survive, but thrive on the variation.
So when you say 'The relationships between people are part of the "execution() function"', I'm pretty sure I disagree (and the only reason I'm not sure is that I'm not completely sure what you mean by "execution()function." The relationships between people are part of the design of the system. See for example the work on relational coordination: http://rcrc.brandeis.edu/ .
-- Nick Gall
My dear Nick (Gall)
ReplyDeleteI'm very sorry you have experienced such difficulty leaving comments on my blogs. As far as I know, I haven't done anything to cause this; and even though I am a Blogger user, I probably have less influence on Google than you do. (Especially after all the critical things I've said about Google over the years.)
One possible reason why your comments show up as "Unknown" is because that is the name on your Blogger Profile. Have you tried changing this name?
Nick Malik says that "antifragility is not a property of a set of instructions. It is a property of the person following the instructions." He goes on to insist that fragility and antifragility only make sense as attributes of systems.
ReplyDeleteBut the set of instructions is just as much a system as the person following the instructions. Fragility or antifragility has to do with the relationship between the system of interest and any other systems in its environment. I think this is what Nick Gall is saying as well.
The cake-making system is composed of many subsystems: the set of instructions, the ingredient supply chain, the person following the instructions, the kitchen and equipment (food-mixer, oven). Each of these subsystems can be more or less fragile in relation to variations (errors, mutations) in the other subsystems. So we can have fragility of the recipe relative to the cook, and we can also have fragility of the cook relative to the recipe. We can also have fragility of the cake-making system as a whole.
As Nick Gall points out, a recipe is not a strategy, so the cake-making example is only a very approximate analogy for the strategy process in an enterprise. But I believe Nick Gall agrees with me in seeing recipes and designs and strategies as having something in common, and the notion of fragility/antifragility applying to all of them.
Thanks Richard for the tip about editing my Blogger profile. I never even knew I HAD a blogger profile!
ReplyDeleteWhat's so frustrating is that I specifically chose to use my GOOGLE account for identity. Blogger's identity choices said NOTHING about a BLOGGER identity. Now I'm saddled with YAI (Yet Another Identity). Sigh. Well I suppose it's worth it so I can comment on your excellent posts.
I updated my information in my Blogger profile, so let's see if this works.
BTW, Have you ever considered switching to disqus.com or a similar commenting service? I really like disqus (easy identity, threaded discussions, ie reply to a specific comment, likes, etc.).
PS I hate the captcha as well. I have more trouble getting it right than any other captcha I've used. I'm on my 3rd try now. Arrrrrggghhhh!
Richard,
ReplyDeleteI agree wholeheartedly with your description: "I believe Nick Gall agrees with me in seeing recipes and designs and strategies as having something in common, and the notion of fragility/antifragility applying to all of them."
I do want to comment on your mention of subsystems though: "The cake-making system is composed of many _subsystems_... Each of these _subsystems can be more or less fragile_ in relation to variations (errors, mutations) in the other subsystems."
True enough, but incomplete. What makes a system resilient (and IMO antifragile) MORE than its subsystems, are the SUPERSYSTEMS on which the system in question is dependent. This relationship between a system and its supersystems and its impact on resilience is one of the key insights of Buzz Holling's Panarchy work. Of particular importance is the concept of "remembrance." When a system is disrupted, much of it's ability to reorganize and renew is dependent on the supersystems that support it providing needed resources for said reorganization and renewal. Holling calls the provision of such resources from supersystem to subsystem "remembrance." (The linked articles below contain nice visualizations of the remembrance relationship.)
What NN Taleb seems to be missing in his antifragility model is the vital role that supersystems play in the antifragility of a given system. (I say seems because I've only read his articles on antifragile, not yet the book.)
His favorite example, buying options as an investment system, is a perfect example. His option-based investment system is only antifragile because it is dependent on a market supersystem that provides the appropriate payoffs (remembrance). And the market itself is only antifragile to the extent it relies on the supersystem of government to provide resources in the face of disruption. I haven't seen Taleb address this full panarchy structure in his work.
For more on Panarchy, see
Short version: http://bit.ly/gRDdNN
Long version: http://bit.ly/PhYpO5