Antifragile or Reactive?

  • April 11, 2013
  • Scott

Keith Swenson is probably the foremost proponent of ACM.  He has a new series of blog posts and talks that touch on Nicholas Taleb’s book “Antifragile,” a new wrinkle on his theme of knowledge work and ACM.  His presentation at bpmNEXT leaned on this concept as well. He gave a series of excellent examples and analogies from nature and commerce to support the concept of a system that gets more robust when it is stressed, rather than more fragile.  Not just reacting to external stress, but actually becoming less fragile.  Forests are more robust if forest fires are allowed to burn, rather than intervening to stamp them out (the fires clearing the underbrush for example).

Sandy has a good writeup of the talk.  In particular, the demo, in which he showed a research prototype of how one would:

[…] create a case, referred to as a project, that is completely empty. The case owner can add documents, including sending an email to external participants with a URL for uploading documents without having an explicit login, and write notes. A project can be used as a template, and its characteristics merged into an existing project. Goals (tasks) can be created and assigned, and turned into subprojects for more complex activities. Other users may have the project in their watch list, and have goals assigned to them. In order to link projects together, a project can generate a streaming link that is linked into another project; the projects can then be set up to synchronize goals and documents between the linked projects. The system is intended for non-technical knowledge workers to create cases on the fly; there is no “design time” environment or more technical requirements.

So far so good. But I was waiting for the punch line- the part where ACM (or the prototype) actually achieves or demonstrates its anti-fragile characteristics.  Creating a case on the fly, in reaction to external stress.

To review:

  • Fragile: small perturbations tend to magnify and destabilize the system.  Picture a coin balanced on its edge. The slightest touch is likely to knock it over – or the slightest breath of wind.
  • Robust: small, medium, possibly even large perturbations fail to destabilize the system.  Picture how hard it is to tip over a coin laying on its face.  However, an extreme force – say, a tornado – could overcome this robust nature.
  • Anti-fragile: in its normal state, robust but not remarkably so.  However, with greater stress the system becomes more stable, rather than more fragile.  Apparently a pyramid/cone of the right dimensions and angle has this property with respect to wind forces knocking it over.  The higher the wind force, the greater force holding that shape to the ground, rather than lifting it up or pushing it around.

The examples and analogies are compelling narrative and motivation to the topic, and Keith is a great speaker. But I was looking for the closing argument to show me that the system wasn’t just responding to stimulus, that it was getting more robust as a result of having previously responded to stimulus.

So I asked the question after his talk – but the answer didn’t address how the system had become more robust in the process (e.g. anti-fragile).  I was convinced that given an external request or stress, a user could put a case together to respond to it. But I wasn’t convinced that a second stress or external request would be handled better than the first.  Or that the 10,000th request would be handled better than the 2nd.

(As an example, in our mobile presentation we showed an app that lets the user define pre-requisites, tasks, documents, etc.  We didn’t present this in an ACM context, but all the capabilities are there.  But I wouldn’t describe it as anti-fragile.  You could describe it as robust or not-fragile, but not “anti-fragile”.)

Anti-fragile remains an excellent goal for organizations to strive for.  But I don’t think we have the silver bullet yet.  Being anti-fragile as an organization means repeatedly taking a look at how you run your business operations and looking for ways to improve.  That might mean changes to standard process, it might mean rolling out new software, it might mean new training or skills are required.  It might also mean empowering users to react to unexpected situations by providing better tooling.  But it is an organizational imperative to be anti-fragile, rather than an IT system imperative. The software won’t do it for you (yet!)…


Related Posts
  • July 18, 2018
  • Ariana

We're pleased to announce all of the sponsors for Driven 2018. Automation Anywhere Camunda Bizagi ...

  • July 16, 2018
  • Ariana

Driven 2018 is coming up quick and we wanted to share some of our most anticipated sessions with you. You can ...

  • July 15, 2018
  • Scott

From nearly the first year I began writing this blog on behalf of BP3, pundits and commentators have predicted...

  • KDS


    Thanks as always for the writeup about my talk. Sorry to disappoint about the “punchline” at the end to demonstrate antifragility. Antifragility doesn’t work that way. I demonstrated antifragility, but you didn’t see it.

    Also sorry I didn’t answer your question optimally. I was a bit thrown off balance because I would have thought it was clear, and I was not quite sure how to answer, so I stumbled a bit. Several audience members actually gave me better answers to your question after the talk … but too late. The question was reasonable, but just sort of threw me off balance. Let me try to answer here.

    Generally (and I am cautious about generalizing, but please bear with me) when you and I disagree, it is because you are expecting me to talk about systems that automate work. I have repeatedly said that I am designing systems that “facilitate” work by humans. That is a different thing. I am not trying to automate work, I am trying to make system that allow people to work more effectively. Your expectation for a big bang at the end appears to be some demonstration that the system changed. It did change, you saw me change it, but you didn’t didn’t recognize the forest because the tress were in the way. Adaptability is not something that happens outside of what people do, it is exactly WHAT people do, and everything I did was adapting the system.

    I never said that the IT system would learn autonomously. I very clearly state at the beginning that this is an exploration of systems that support a learning organization. I am not talking about “learning IT systems”. A learning organization is about people learning, and the IT system is to support these people learning. As people learn, they extend the IT system as well, and they use the IT system to teach others. This is what I demonstrated.

    The videos are now available, so you and your readers can go back and take a look:

    As you watch, pay attention to a couple of things.

    1) I say that the main character, Alex, has never worked on townhouses before, but he knows someone who has. He does a search and FINDS another case that was for a townhouse. He copies those tasks into his own case folder. This helps him learn how to handle townhouses.

    2) I also mention (later) that none of the lists of tasks were designed by a programmer. These tasks were put in simply by another escrow agent created for the townhouse case.

    3) But then notice, playing the role of Alex, I rearrange the tasks, and reassign them. This is the “adapting” part. it does not require any special punchline.

    4) A real escrow would take weeks, and not just 10 minutes, and we might assume that over those weeks Alex would figure out that new tasks are required. I gave an example of one, and I show how Alex would create a new task to “Inspecting the Trees”. This is adapting the process. This is learning how to handle this kind of townhouse.

    5) What should have been clear, and might not have been from the quick demo, is that the case folder that Alex left behind can be the template for another case. That was the point of starting with Alex searching for and finding the other townhouse case.

    Go watch the video and see if this makes sense.

    Each escrow agent can put their own extensions in, as they find the need for them. If suddenly there was a federal law requiring dog DNA tests around the property, they would add that. That case might becomes the template for the next case. The collection of different varieties grows with each case, and the people in the organization can learn from each other through the system.

    Fragility would be if the workers were PREVENTED from adding the task to “Inspect the Trees”. That is the source of fragility. Antifagility however is the ability to add the task, not by a programmer, but you see me do it in the video, in real time. No punchline is needed — that is antifragility in action.

    A solid cone does not demonstrate anti-fragile qualities. That would be stability. To be antifragile, you have to RESPOND to the stress with a change. Organizations do this all the time, and my talk was about a system that helps an organization do this. You saw how Alex added a task for “Inspect the Trees”. This is a response to the stress. And it is also “learning” since others can see this step, and can use the result of this case in another case.

    I am sorry if this seems anticlimactic. A forest is antifragile, but it does so without any big punchline. It is a slow and gradual response to many different stresses, and that is exactly how a learning organization works: lots of small changes to stresses, each one making a very small improvement.

    I always appreciate these questions, and I hope that my answer makes things a little bit more clear.

    • Keith –

      “Antifragility doesn’t work that way. I demonstrated antifragility, but you didn’t see it.”

      The problem must be me, right? 🙂 First, blame the listener.

      So, you’ve clarified now that you don’t consider antifragile to be a case where outside stress makes the system stronger (the cone I mentioned). That’s fine, I’ll accept your clarification.

      However, let’s move away from analogy (forests and cones). To be anti-fragile, you posit that the system has to react. But you have also stated that *reacting* to change was necessary but not sufficient to be antifragile, that the act of reacting had to make the system stronger.

      I asked the question because the whole premise of your talk was that anti-fragile was not just “not fragile” and not just “reactive in one instance” but learning over time to be stronger over time. You set up the goal post, I tried to give you a softball question to put the ball through and state the obvious. I guess it wasn’t that softball after all.

      If it was obvious that the case folder was a template, then say that. And that that satisfies your requirements for antifragility. Fantastic.

      In fact, you could have just said that in the comment here. And then we could have talked about what happens when there are thousands of variants that individuals have created, and I need to pick one – how do I know which one to pick? We could have had some interesting follow-up discussions 🙂

      • KDS

        “So, you’ve clarified now that you don’t consider antifragile to be a
        case where outside stress makes the system stronger (the cone I
        mentioned). That’s fine, I’ll accept your clarification”

        You believe that my comment “A solid cone does not demonstrate anti-fragile qualities” has been construed as a “clarification” of the definition of antifragility?

        Can you explain how this logic works?

        • So by clarification – I’m acknowledging that your note clarified –
          for me – that you intend that the system has to actually change as well as get stronger. That’s my mistake, not a criticism of your previous explanation or the idea of anti-fragility.
          (not just get stronger, but change explicitly). I should have left out the word “now” as well, as it has the wrong connotation.

          Parenthetically, if you understand the properties of a solid cone under high winds, of the proper angle, it is both stable under no outside stimulus, and MORE stable under high winds (increased stimulus). Its pretty interesting for monitoring high winds in, say, a tornado. The cone actually sticks to the ground more than it normally would, under 400mph winds.

          • KDS

            The point of antifragile is that it “gains” from being stressed. The cone is stable under high winds, but when the wind stops, the cone has not “gained” anything. A balloon pushes back when you push on it, but this is not antifragility. When you stop pushing, and the balloon goes back to the original shape, it has not “gained” anything. The cone, the balloon, are examples of stability. The cone is stable particularly because the wind causes a downward force that holds it in place. I realize that under faster wind, there is a stronger force, but to “gain” something it needs to be increased when returning to the original situation. When carrying a weight up the stairs it gets additional potential energy, but when you bring it back to the original position, it has not truly gained anything.

            What you saw in my demo, was a customer that needed new activity that had never been done before. Alex created a new goal for that, and the record of that goal remained in the system. At the end of the demo, the system had “gained” the definition of a new goal, and that new goal could we reused by others. I know this is not incredibly profound, but that is the behavior of a learning organization that Cognoscenti supports.

            Another name for this is “innovation”. Any organization that innovates is demonstrating anti-fragile behavior because they are putting into place practices that did not exist before. A stable organization might be a hospital that can take care of accident victims efficiently and effectively, but an innovative hospital has the ability to put NEW practices into place.

            The cone example is really nothing like “innovation” if you see what I mean.

          • BTW, analogies are tricky 🙂

            e.g. the cone. It “gains” from the windforce. Its attachment to the ground is just gravitational force until a high wind shows up, and then it has a stronger attachment. When the external (wind) force dissipates, so does that benefit. You yourself mentioned in your talk that anti-fragile systems not exposed to external stress tend to degrade somewhat. That they need external stimulus 🙂

            We used the forest fire analogy w.r.t. forests. But forests also adapt (anti-fragile?) to prevailing winds on the coast of California. If those winds were to change direction however, you’d find a lot of trees falling over. Systems adapt to the forces and stresses put on them – but that shaping, if permanent, can sometimes render systems more vulnerable to a different, or unanticipated stress.

            Moreover, I wouldn’t call a forest “innovative” though you could make that argument, it isn’t the common term. I think innovation is a bit orthogonal to the notion of anti-fragile. Innovation implies intent, organizational imperative, and design. Anti-fragile by your definition doesn’t imply intent. And an innovative organization may not survive when those innovations aren’t well-received by the market… which could mean that the innovative organization is still fragile… In other words, there are lots of different kinds of innovation, and the fragile access only addresses a subset. And vice versa.

          • KDS

            Scott, with all due respect, you are just not getting the concept of “antifragile”. Yes the wind is a stress on the cone. Yes, it is cool that the wind on certain shaped cones actually pressed down more to keep them even more secure. But when the wind stops, the cone is exactly as it was before. The concept of “gain” is about a lasting change in response to the stress.

            But note that not just ANY change. Fragile systems break when subjected to stress. So it is not just that they change, but antifragile systems get “better” in response to the stress.

            You exercise a muscle, and the muscle grows to become better at doing the work. (It may also be sore for a while — lots of things are happening, but the antifragile response is the one that makes the muscle better at doing the work.) If you practice piano, you get better at playing the piano. If you ask an organization to do a fire drill, it gets better at getting away from burning buildings.

            The cone simply does not do this. When you subject it to wind, it may experience greater force with the greater wind, but the cone does not get “better” at creating this force. It is a pure stimulus/effect. The cone does not “grow” in any way.

            Stopping the wind is not the same thing as the degradation of muscles from stopping exercise. In response to exercise, muscles physically change. Laying in a hospital bed for 6 weeks causes a physical change to the muscles as well.

            I am not talking about simple change in response to a stimulus. Press on a balloon and it deforms. It also pushes back. (It also gets a little bit warmer.) Press harder, and it presses harder back. Gently stop pressing, and the balloon returns to the original shape. There are all sorts of effect and response that are NOT antifragile behaviors.

            If the sun shines on a rock, the rock gets warmer. This is not the kind of “gain” that we mean by antifragile. Shade the rock and it gets cooler. Like the cone and the balloon, the rock is NOT exhibiting antifragile behavior.

            Are you really having a hard time grasping this?

          • Keith, with all due respect, you should understand your own ideas and analogies better if you’re going to make every argument with an analogy – and then argue other analogies instead of just going back to the one concrete example in cognoscenti. In the case of a muscle, if you stop exercising, it reverts back to how it was before you started exercising (and thanks to age, it regresses even further). At least in the case of a cone, the vacuum under the cone actually creates a tighter seal even after the windforce abates 😉

            As I said before, you should have just used your case example and explained that the requirement to be antifragile instead of just reacting, is that the new goal/task/whatever can be stored as a template. That’s fine, I accept that explanation. Instead I get a diatribe. Take a deep breath.

            Now. having explained what constitutes anti-fragile in your mind – I’ll be honest, I’m not that impressed. Once you get past the analogies and just talk software, its such a minor change to software systems to support that definition of anti-fragile. So I’m not sure why we’re arguing about silly analogies. Case. Template. Re-use of said template. Got it. Seems really obvious and non-interesting and covered by various existing software packages.

            I realize we’re like oil and water on these things but I try to keep from the personal attacks on someone else’s ability to understand. That doesn’t seem to be your modus operandi however, which is pretty disappointing.

          • KDS

            It seems as though you are still arguing that a cone is antifragile, just as the muscle is.

            You do agree, I hope, that after exercise a muscle physically changes. At the same time, you can blow wind on the cone, and cone itself undergoes no physical change at all.

            You seem to be equating the stopping of blowing the wind, to the stopping of exercise. But I hope you see that there is a big difference. Actually, muscles don’t actually grow when you exercise, but they grow later in response. Every day, you exercise and you stop exercising, but the muscles keep growing. It is true if you stop for a long period of time (weeks or months) then indeed they will atrophy. The cone never actually grows no matter how long the wind blows, and can’t be described as atrophying when the wind has stopped for a long time. Unless I missed it, I haven’t seen a confirmation that you agree muscles are antifragile, while cones are not..

            If you think I am confused about these concepts then I am quite happy to listen to input.

            I am happy you have made me appreciate that some of these concepts are not as obvious as I thought. I would like to know if any of this is making the concept of antifragile clearer….

          • incidentally, it doesn’t matter whether i think cones/muscles are antifragile or not (i would agree that based on your definition, muscles are, cones are not) – my point is that it takes a reasonably fine-grained argument to “prove” something with analogies. and none of those analogies say anything about software.

            whereas, by contrast, the software argument is clean – you defined what you consider anti-fragile. I’m fine with that definition. The concept of anti-fragile itself was clear before you ever wrote about it 🙂 the only thing i was trying to figure out is, how are you interpreting it to apply to software. I think you misunderstood that to mean I don’t understand antifragile, when i’m really just seeking to understand your take on it.

            I think you summed it up as – an end user being able to define a new template (or goal) and re-use it later. Good enough.

          • KDS

            Yes, I think you have it there.

            But the way, earlier you made an excellent point about the forests: “forests also adapt to prevailing winds on the coast of California. If those winds were to change direction however, you’d find a lot of trees falling over.”

            I like how this illustrates that adaptiveness is not a shield that prevents all kinds of failure. As Taleb points out “Nature loves small errors.” If the winds were to suddenly and profoundly change, many (but not all) trees would be blown over. New trees would grow, and some of those would be blown over. Eventually, however, you would have a complete forest able to take the new wind direction. The adaptiveness comes from the continual experimentation with tree location and situation — not from any kind of central control. In this way, one actually can say that the forest is truly “innovative” in its limited way without any “intent”.

            You made another good point when you said “And an innovative organization may not survive when those innovations aren’t well-received by the market.” In order insure success, the innovations need to be NUMEROUS and SMALL, which is why an adaptive system focuses on allowing individuals to experiment. With many small innovations, some of them will fail, but the failure will be small, and the organization will learn from them.

            What I like is that you point out that an organization can be fragile when individual are not allowed to experiment, and they must follow strictly the designated best practice. When this is the situation, a centrally controlled innovation causes very few, but very large failures. Companies are doomed by CEO’s making disastrous decisions far more often than by poor decisions by individual salesmen. Once again, the point of an adaptive system is not to prevent all errors, but ironically to allow errors at a small level that the organization can learn from. Fragility comes from trying to eliminate the small variations.

  • Pingback: BPMNext Notes | Collaborative Planning & Social Business()