Moving Past “I Don’t Know”

In 2015 I attended the Mile High Agile conference in Denver where Mike Cohn delivered the morning keynote address: “Let Go of Knowing: How Holding onto Views May Be Holding You Back.” As you might expect from a seasoned professional, it was an excellent presentation and very well received. A collection of 250+ scrum masters, product owners, and agile coaches is no stranger to mistakes, failures, and terrifying moments of doubt.

As valuable as the ideas in Cohn’s presentation are, I want to take them further. Not further into the value of keeping our sense of sureness somewhat relaxed, rather onto some thoughts about what’s next. After we’ve reached a place of acknowledging we don’t know something and are less sure then we were just a moment before, where do we go from there? It’s an important question, because if you don’t have an answer, you’re open to trouble.

The “I Don’t Know” Vacuum

Humans are wired to find meaning in almost every pattern they experience. The cognitive vacuum created by doubt and uncertainty is so strong it will cause seemingly rational people to grasp at the most untenable of straws. It’s a difficult path, but developing the skill for being comfortable with moments of doubt and uncertainty can lead to new insights and deeper understanding if we give our brains a little time to search and explore. Hanging out in a space of doubt and uncertainty may be fine for a little while, but it isn’t a wise place to build a home.

After acknowledging we don’t know something or that we’ve  been wrong in our thinking, it’s important to make sure the question “What’s next?” doesn’t go begging. I’d wager we’ve all had the dubious pleasure of discovering what we don’t know in full view of others and in those situations the answer to this question becomes critical. It may not need an immediate answer, but it does need an answer. If you don’t work to fill the vacuum left by “I don’t know” or “I was wrong,” someone else surely will and it may not move the conversation in the direction you intended.

The phenomenon works like this. Bob, a capable scrum master, ends up in a situation that reveals a lack of experience or understanding with the scrum framework and doesn’t know what to do. Alice, maybe immediately or maybe later, moves into the ambiguity, assumes control, and tells the team what should be done. If Alice is wise in the ways of agile, this could end well. If command-and-control is her modus operandi in the defence of silos and waterfall, it probably won’t.

So how can an agile practitioner prepare themselves to respond effectively in situations of doubt and uncertainty? Here are a few things that have worked for me.

Feynman-ize the Conversation

In his book “Surely You’re Joking , Mr. Feynman!,” Nobel physicist Richard Feynman tells a story from his early career where several building engineers started reviewing blueprints with him, thinking he knew how to read them. He didn’t. Having been surprised by being placed in a position of assumed expertise, Feynman improvised by pointing at a mysterious but ubiquitous symbol on the blueprint and asking, “What if that sticks?” The engineers studied the blueprint in light of Feynman’s question and realized the plans had a critical flaw in a system of safety valves.

That’s how to Feynman-ize a conversation. Start asking questions about things you don’t understand in a manner that challenges those around you to seek the answer you need. In essence, it expands the sphere of doubt and uncertainty to include others in the situation. This tactic is particularly effective in situations where corporate politics are strong. Bringing the whole team into the uncertainty space helps neutralize unhelpful behaviors and increase the probability the best answer for the moment will be found. It is no longer just you who doesn’t know. It’s us that that don’t know. That’s a bigger vacuum in search of an answer. In short order, it’s likely one will be pulled in.

The Solution Menu

Thinking of the agile practitioners in my professional circle, they are all adept at generating possibilities and searching their experience reservoir for answers based on similar circumstances. When the creative juices or flow of answers from the past are somewhat parched by the current challenge, it is natural to project the appearance of not knowing. Unless you’ve drawn a complete blank, you can still use the less-than-ideal options that came to mind.

“I can think of several possible solutions,” you might say. “But I’m not yet sure how they can be adapted to this challenge.” Then offer your short list of items for consideration. One of those menu choices might be the spark that inspires a team members to think of a better idea. Someone else may find an innovative combination of menu choices that gets to the heart of the issue. I’ve even had someone mishear one of my menu choices such that what they thought they heard turned out to be the more viable solution. This is just another way to leverage the power of everyone’s innate drive for finding meaning.

Design an Experiment

If there is a glove that fits the “I don’t know” hand, it’s experimentation. I suppose you could work to stretch the guessing glove over “I don’t know.” But if your team is aware that you don’t know something, it’s worse if they know you’re pretending that you do. Challenges and problems are the situation’s way of asking you questions. If the answers aren’t apparent, form a solution hypothesis, set up a simple test, and evaluate the results. And as the shampoo bottle says: lather, rinse, repeat until the problem is washed away. It’s another way to expand the sphere of uncertainty to include the whole team and increase the creative power brought to bear on the problem. If your shampoo bottle is this agile, I’ve every confidence you can be, too.

Now I’m curious. What has helped you move past “I don’t know?”


Image by Gerd Altmann from Pixabay

Deliberate Practice and Coding

Deliberate practice applied to coding offers some unique opportunities. Unlike other skills, like learning to play the cello (to pick one that I have some experience with), you can go very far without a personal mentor. The feedback from the computer is about as objective as it gets. It will let you know exactly how good your code is.

This also helps remove the emotional component – positive and negative – that can sometimes impede progress with an in-person mentor. This doesn’t remove all emotion, however. Just about everyone who’s worked in a professional coding shop has witnessed the rare occurrence of a coder cursing at or even physically attacking their computer because their code isn’t working as expected. Those are surreal moments when an avalanche of cognitive biases and unconscious behavior become visible to all but the coder. That’s a topic for for a different post. Suffice it to say, learning how to control your emotions, channel frustration, and ignite curiosity is part of what distinguishes good coders from great coders.

Which gets met to finding quality feedback. While I’ve made a good living writing mountains of proprietary code for various business and corporations, I earned my coding chops by working on or authoring open source projects. This was the best source I found for getting feedback on my code. It also taught me another important lesson: Do not attach your identity to the code you write. Like any noob, I had a lot of pride in my early code that was pretty much untested outside my little work environment. In the open source world, the feedback was often swift and harsh. Or, at least is was when my identity was attached to it. Learning to separate work product from identity revealed just how much emotional spin I was putting on what was in hindsight reasonable feedback. I have concerns that the current climate in the coding world is opting for soft feedback and good feelings over legitimate and reasonable feedback. This, too, is for another post.

It’s worth giving some thought about the the pros and cons of working with an actual person for mentorship. Along with good instruction, a single mentor will pass along their own limitations and biases. Not necessarily a bad thing, just something to be aware of. So multiple mentors are better than just one, which starts to move down the path of actively participating in open source projects. By “actively” I mean not just contributing code, but studying the code (and it’s history) of existing successful projects. There are usually many ways to solve a problem with software. Work to understand why one approach is better than another. Insights like this are best gained, in my experience, by studying good code.

Somewhat related, if you are working from a book or a training program, actually type in the examples – character by character. Don’t cheat yourself by copy-pasting code examples. This is the muscle memory component to coding that you will find when learning other more physical skills (like playing the cello.) If you really want to experience the gnarly edge, ditch the IDE and code with at text editor. I still do all my coding in vim and this keyboard.

Another approach to deliberate practice is the idea of coding “katas.” This never clicked with me. I attribute this to having studied martial arts for 25 years, most of that time at the black belt level. Mapping the human psycho/physical world and the purpose of katas in the dojo to the machine world is too much of a mis-match. Much is lost in the translation, in my experience. The katas in the dojo, regardless the art form, translated easily to other styles and practices. The coding “katas” are more tightly coupled to the coding language in which they are written. In my view, it’s yet another example of swiping a cool sounding word and concept and force-fitting it to another domain. A software version of cargo cults – expecting form to create function. “Black belt” or “Ninja” coder are other force-fits. Yet again, something for another post.

But those are my limitations. Your experience will no doubt be different. As learning exercises and proficiency tracks, many of the coding “katas” look to be very good.

(For related thoughts on how building your own tools can deepen your understanding of a skill, see “Tools for Practice.” The examples in the article combine software development and cello practice.)


Image by Robert Pastryk from Pixabay

Expert 2.0

A common characteristic among exceptionally creative and innovative people is that they read outside their central field of expertise. Many of the solutions they find have their origins in the answers other people have found to problems in unrelated fields. Breakthrough ideas can happen when you adopt practices that are common in other fields. This is a foundational heuristic to open software development. Raymond (1999) observes:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this “Linus’s Law.” (P. 41)

So named for Linus Torvalds, best known as the founder of the Linux operating system. In the case of the Linux operating system, no one developer can can have absolute expert knowledge of every line of code and how it interacts (or not) with every other line of code. But collectively a large pool of contributing developers can have absolute expert knowledge of the system. The odds are good that one of these contributors has the expertise to identify an issue in cases where all the other contributors may not understand that particular part of the system well enough to recognize it as the source of the agony.

This idea easily scales to include knowledge domains beyond software development. That is, solutions being found by people working outside the problem space or by people working within the problem space in possession of expertise and interests outside the problem space.

Imagine, around 1440, a gentleman from Verona named Luigi D’vino who makes fine wines for a living. And imagine a gentleman from Munich named Hans Münze who punches out coins for a living. Then imagine a guy who is familiar with the agricultural screw presses used by winemakers, has experience with blacksmithing, and knowledge of coin related metallurgy. Imagine this third gentleman figures out a way to combine these elements to invent “movable type.” This last guy actually existed in the form of Johannes Gutenberg.


Assuming D’vino and Münze were each experts in their problem space, they very likely found incremental innovations to their respective crafts. But Guttenberg’s interests ranged farther and as a consequence was able to envision an innovation that was truly revolutionary.

But if you, specifically, wish to make these types of connections and innovations, there has to be a there there for the “magic” to happen. Quality “thinking outside the box” doesn’t happen without a lot of prior preparation. You will need to know something about what’s outside the box. And note, there aren’t any limitations on what this “what” may be. The only requirement is that it has to be outside the current problem space. Even so, any such knowledge doesn’t guarantee that it will be useful. It only enhances the possibility for innovative thinking.

There is more that can be done to tune and develop innovative thinking skills. What Bock suggests touches on several fundamental principles to transfer of learning, the “magic” of innovative thinking, as defined by Haskell (2001, pp. 45-46).

  • Learners need to acquire a large primary knowledge base or high level of expertise in the area that transfer is required.
  • Some level of knowledge base in subjects outside the primary area is necessary for significant transfer.
  • An understanding of the history of the transfer area(s) is vital.

To summarize, in your field of interest you must be an expert of both technique and history (lest your “innovation” turn out to be just another re-invented wheel), and you must have a sufficiently deep knowledge base in the associated area of interested from which elements will be derived that contribute to the innovation.


Haskell, R. E. (2001). Transfer of learning: Cognition, instruction, and reasoning. San Diego, CA: Academic Press.

Raymond, E. S. (1999) The cathedral and the bazaar: Musings on Linux and open source by an accidental revolutionary. Sebastopol, CA: O’Reilly & Associates, Inc.


Image by István Kis from Pixabay

The Path to Mastery: Begin with the Fundamentals

Somewhere along the path of studying Aikido for 25  years I found a useful perspective on the art that applies to a lot of skills in life.  Aikido is easy to understand. It’s a way of living that leaves behind it a trail of techniques. What’s hard is overcoming the unending stream of little frustrations and often self-imposed limitations. What’s hard is learning how to make getting up part of falling down. What’s hard is healing after getting hurt. What’s hard is learning the importance of recognizing when a white belt is more of a master than you are. In short, what’s hard is mastering the art.

The same can be said about practicing Agile. Agile is easy to understand. It is four fundamental values and twelve principles. The rest is just a trail of techniques and supporting tools – rapid application development, XP, scrum, Kanban, Lean, SAFe, TDD, BDD, stories, sprints, stand-ups – all just variations from a very simple foundation and adapted to meet the prevailing circumstances. Learning how to apply the best technique for a given situation is learned by walking the path toward mastery – working through the endless stream of frustrations and limitations, learning how to make failing part of succeeding, recognizing when you’re not the smartest person in the room, and learning how to heal after getting hurt.

If an Aikidoka is attempting to apply a particular technique to an opponent  and it isn’t working, their choices are to change how they’re performing the technique, change the technique, or invent a new technique based on the fundamentals. Expecting the world to adapt to how you think it should go is a fool’s path. Opponents in life – whether real people, ideas, or situations – are notoriously uncompromising in this regard.  The laws of physics, as they say, don’t much care about what’s going on inside your skull. They stubbornly refuse to accommodate your beliefs about how things “should” go.

The same applies to Agile practices. If something doesn’t seem to be working, it’s time to step in front of the Agile mirror and ask yourself a few questions. What is it about the fundamentals you’re not paying attention to? Which of the values are out of balance? What technique is being misapplied? What different technique will better serve? If your team or organization needs to practice Lean ScrumXPban SAFe-ly than do that. Be bold in your quest to find what works best for your team. The hue and cry you hear won’t be from the gods, only those who think they are – mere mortals more intent on ossifying Agile as policy, preserving their status, or preventing the perceived corruption of their legacy.

But I’m getting ahead of things. Before you can competently discern which practices a situation needs and how to best structure them you must know the fundamentals.

There are no shortcuts.

In this series of posts I hope to open a dialog about mastering Agile practices. We’ll begin by studying several maps that have been created over time that describe the path toward mastery, discuss the benefits and shortcomings of each of these maps, and explore the reasons why many people have a difficult time following these maps. From there we’ll move into the fundamentals of Agile practices and see how a solid understanding of these fundamentals can be used to respond to a wide variety of situations and contexts. Along the way we’ll discover how to develop an Agile mindset.

Photo by simon sun on Unsplash

Building Mastery One Day At A Time

Old joke: A young couple visiting New York City for the first time has lost their way. They spot a street musician, just the person to help them get reoriented. “Excuse us, but can you tell us how to get to Carnegie Hall?” The musician stopped playing and thought for a moment before replying: “Practice.”

The prevailing wisdom is that it takes 10,000 hours of practice to achieve the level of mastery in any particular field of endeavor. Turns out, this is true for fields with well-defined measures for excellence like chess and music. In each of these areas, the rules are relatively simple, but mastering them isn’t easy. It’s pretty easy to tell when someone is playing an instrument out of tune or off-beat. And yet, a pawn shop guitar in the hands of Joe Satriani or Liona Boyd will likely result in that instrument expressing a voice no one knew it had. As for chess masters, they’re the ones who win against all challengers regardless the time or place of the match.

For areas of human endeavor where the edges are less well defined, like business or coaching, there may be no marker for how much practice it takes to reach a stable mastery. Having successfully started and built one business does not guarantee the next venture will be equally successful. A coach with a winning system for one team may end up at the bottom of the ranks when the same system is used with a different team.

Developing expertise with scrum is a blend of both of these. The rules are simple, but they are not easy to master. At the same time the territory isn’t well defined and frequently changes. A new client, a new team, or a new project and the edges for what is possible change. Misunderstanding this has been at the root of much of the frustration I’ve observed among people new to agile. They come from a world with well-defined edges – traditional project management practices filled with Gantt charts, milestones, functional specifications, use cases, deployment requirements, and a plethora of other artifacts that “must” be in place before work can begin. As many unknowns as possible must be made known, risks pounded down to trivial annoyances, and all traces of ambiguity squeezed out of the project plan. Learning how to let go of deeply rooted practices like this is no small thing. We like the comfort of well-defined rules. And when there’s work to be done with scarce resources to make it happen, we reach for the rules most familiar to us.

So how can we update the tried-and-true, super comfy confines of past practices and rule sets?

Practice, of the deliberate variety. As Emperor Hadrian might have put it, “Brick by brick, my fellow citizens, brick by brick.”

Research following on the “10,000 hours of practice” generalization has shown that it isn’t just that someone has completed 10,000 hours of practice. The critical factor was how they practiced. Was each hour spent completing the same motions and behaviors from the previous hour or were they spent building on successive experiences, seeking greater challenges, and developing a deeper understanding of their craft? Following the latter path leads to the incremental improvements required to build mastery. And once obtained, the same attitude toward practice helps sustain a level of mastery. There will always be something more to learn, a fresh perspective to experience, or a more satisfying way to experience success.

There is a great deal of neuroscience at the foundation of practice and few would dispute the value of learning how to learn. And yet as our experience grows and we master a particular field, it’s deceptively easy to fall into a complacency of thought whereby we convince ourselves there isn’t anything else to learn. That is until some seismic paradigm shift makes it clear the rules have changed and we’d let our mastery go stale. The consequences of this are captured by Greene (2012) in his book, Mastery:

“We prefer to live with familiar ideas and habits of thinking, but we pay a steep price for this: our minds go dead from the lack of challenge and novelty; we reach a limit in our field and lose control over our fate because we become replaceable.” (pg. 176)

If this happens, learning how to learn may not be enough. Learning how to unlearn may be equally valuable for regaining mastery.

In classic hacker culture, you aren’t a hacker until other recognized hackers call you a hacker. It’s a title to be earned, not claimed. The unfortunate title of “scrum master” aside, it is useful to take this credentialing tradition to heart with scrum as well. Consider yourself an apprentice scrum practitioner until other recognized scrum masters recognize your mastery. Holding such a frame keeps us humble, curious, and open to constant and never ending improvement.

I’ve been practicing, leading, or coaching scrum in one capacity or another for over 10 years and based on my billable hours over the past several years, I’m quite confident I’ve passed the 10,000 hour mark for practicing scrum. Even so, I’m not a master scrum master…yet. The reason is simple and is expressed by the great cellist Pablo Casals’ response to filmmaker Robert Snyder’s query as to why Casals continues to practice five hours a day at 80 years of age, “Because I think I am making progress.” I keep building upon my practice because each day I discover new ways to enhance team performance and improve my skills. Perhaps more telling, any time I think I’ve heard every excuse for not following the scrum framework, someone on one of my teams surprises me.

If you’re interested in staying on the path toward scrum mastery, you need to get out of the books and into the world. There are a variety of ready opportunities to mark and gauge your progress.

  • Frequently review the framework for scrum and compare what’s there with your current projects. If there are mismatches, find out why. Is there really a good reason for straying from the framework? If so, open a dialog about these differences during your retrospectives.
  • If possible, ask your fellow agile practitioners when they are holding their next review, backlog refinement, or sprint planning session and get yourself invited as an observer.
  • There are probably a number of excellent agile related meet-ups in your area. Speaking from personal experience, these are incredibly valuable communities of support and new ideas.

Image by sarfarazis from Pixabay


Greene, R. (2012). Mastery. New York, NY: Viking Penguin

The Value of “Good Enough…for Now”

Any company interested in being successful, whether offering a product or service, promises quality to its customers. Those that don’t deliver, die away. Those that do, survive. Those that deliver quality consistently, thrive. Seems like easy math. But then, 1 + 1 = 2 seems like easy math until you struggle through the 350+ pages Whitehead and Russell1 spent on setting up the proof for this very equation. Add the subjective filters for evaluating “quality” and one is left with a measure that can be a challenge to define in any practical way.

Math aside, when it comes to quality, everyone “knows it when they see it,” usually in counterpoint to a decidedly non-quality experience with a product or service. The nature of quality is indeed chameleonic – durability, materials, style, engineering, timeliness, customer service, utility, aesthetics – the list of measures is nearly endless. Reading customer reviews can reveal a surprising array of criteria used to evaluate the quality for a single product.

The view from within the company, however, is even less clear. Businesses often believe they know quality when they see it. Yet that belief is often predicate on how the organization defines quality, not how their customers define quality. It is a definition that is frequently biased in ways that accentuate what the organization values, not necessarily what the customer values.

Organization leaders may define quality too high, such that their product or service can’t be priced competitively or delivered to the market in a timely manner. If the high quality niche is there, the business might succeed. If not, the business loses out to lower priced competitors that deliver products sooner and satisfy the customer’s criteria for quality (see Figure 1).

Figure 1. Quality Mismatch I
Figure 1. Quality Mismatch I

Certainly, there is a case that can be made for providing the highest quality possible and developing the business around that niche. For startups and new product development, this may not be be best place to start.

On the other end of the spectrum, businesses that fall short of customer expectations for quality suffer incremental, or in some cases catastrophic, reputation erosion. Repairing or rebuilding a reputation for quality in a competitive market is difficult, maybe even impossible (see Figure 2).

Figure 2. Quality Mismatch II
Figure 2. Quality Mismatch II

The process for defining quality on the company side of the equation, while difficult, is more or less deliberate. Not so on the customer side. Customers often don’t know what they mean by “quality” until they have an experience that fails to meet their unstated, or even unknown, expectations. Quality savvy companies, therefore, invest in understanding what their customers mean by “quality” and plan accordingly. Less guess work, more effort toward actual understanding.

Furthermore, looking to what the competition is doing may not be the best strategy. They may be guessing as well. It may very well be that the successful quality strategy isn’t down the path of adding more bells and whistles that market research and focus groups suggest customers want. Rather, it may be that improvements in existing features and services are more desirable.

Focus on being clear about whether or not potential customers value the offered solution and how they define value. When following an Agile approach to product development, leveraging minimum viable product definitions can help bring clarity to the effort. With customer-centric benchmarks for quality in hand, companies are better served by first defining quality in terms of “good enough” in the eyes of their customers and then setting the internal goal a little higher. This will maximize internal resources (usually time and money) and deliver a product or service that satisfies the customer’s idea of “quality.”

Case in point: Several months back, I was assembling several bar clamps and needed a set of cutting tools used to put the thread on the end of metal pipes – a somewhat exotic tool for a woodworker’s shop. Shopping around, I could easily drop $300 for a five star “professional” set or $35 for a set that was rated to be somewhat mediocre. I’ve gone high end on many of the tools in my shop, but in this case the $35 set was the best solution for my needs. Most of the negative reviews revolved around issues with durability after repeated use. My need was extremely limited and the “valuable and good enough” threshold was crossed at $35. The tool set performed perfectly and more than paid for itself when compared with the alternatives, whether that be a more expensive tool or my time to find a local shop to thread the pipes for me. This would not have been the case for a pipefitter or someone working in a machine shop.

By understanding where the “good enough and valuable” line is, project and organization leaders are in a better position to evaluate the benefits of incremental improvements to core products and services that don’t break the bank or burn out the people tasked with delivering the goods. Of course, determining what is “good enough” depends on the end goal. Sending a rover to Mars, “good enough” had better be as near to perfection as possible. Threading a dozen pipes for bar clamps used in a wood shop can be completed quite successful with low quality tools that are “good enough” to get the job done.


I’ve been giving some more thought to the idea of “good enough” as one of the criteria for defining minimum viable/valuable products. What’s different is that I’ve started to use the phrase “good enough for now.” Reason being, the phrase “good enough” seems to imply an end state. “Good enough” is an outcome. If it is early in a project, people generally have a problem with that. They have some version of an end state that is a significant mismatch with the “good enough” product today. The idea of settling for “good enough” at this point makes it difficult for them to know when to stop work on an interim phase and collect feedback.

“Good enough for now” implies there is more work to be done and the product isn’t in some sort of finished state that they’ll have to settle for. “Good enough for now” is a transitory state in the process. I’m finding that I can more easily gain agreement that a story is finished and get people to move forward to the next “good enough for now” by including the time qualifier.


1Volume 1 of Principia Mathematica by Alfred North Whitehead and Bertrand Russell (Cambridge University Press, page 379). The proof was actually not completed until Volume 2. (This article cross-posted at LinkedIn.)

Concave, Convex, and Nonlinear Fragility

Nassim Nicholas Taleb’s book, “Antifragile,” is a wealth of information. I’ve returned to it often since first reading it several years ago. My latest revisit has been to better understand his ideas about representing the nonlinear and asymmetric aspects of fragile/antifragile in terms of “concave” and “convex.” My first read of this left me a bit confused, but I got the gist of it and moved on. Taleb is a very smart guy so I need to understand this.

The first thing I needed to sort out on this revisit was Taleb’s use of language. The fragile/antifragile comparison is variously described in his book as:

  • Concave/Convex
  • Slumped solicitor/Humped solicitor
  • Curves inward/Curves outward
  • Frown/Smile
  • Negative convexity effects/Positive convexity effects
  • Pain more than gain/Gain more than pain
  • Doesn’t “like” volatility (presumable)/”Likes” volatility

Tracking his descriptions is made a little more challenging by reversals in reference when writing of both together (concave and convex then convex and concave) and mis-matches between the text and illustrations. For example:

Nonlinearity comes in two kinds: concave (curves inward), as in the case of the king and the stone, or its opposite, convex (curves outward). And of course, mixed, with concave and convex sections. (note the order: concave / convex) Figures 10 and 11 show the following simplifications of nonlinearity: the convex and the concave resemble a smile and a frown, respectively. (note the order: convex / concave)

Figure 10 shows:

So, “convex, curves outward” is illustrated as an upward curve and “concave, curves inward” is illustrated as a downward curve. Outward is upward and inward is downward. It reads like a yoga pose instruction or a play-by-play call for a game of a Twister.

After this presentation, Taleb simplifies the ideas:

I use the term “convexity effect” for both, in order to simplify the vocabulary, saying “positive convexity effects” and “negative convexity effects.”

This was helpful. The big gain is when Taleb gets to the math and graphs what he’s talking about. Maybe the presentation to this point is helpful to non-math thinkers, but for me it was more obfuscating than illuminating. My adaptation of the graphs presented by Taleb:

With this picture, it’s easier for me to understand the non-linear relationship between a variable’s volatility and fragility vs antifragility. The rest of the chapter is easier to understand with this picture of the relationships in mind.