This sounds obvious until you realize most companies are doing some version of the second mistake every day. They’re trying to fly a 737 with tricycle controls.

There’s a name for why this fails. It’s been around since 1956, it’s foundational to how complex systems behave, and most leaders have never heard of it. Or if they have, they’ve filed it under “interesting theory” rather than “thing that explains why my last reorg didn’t work.”

The law is simple, the implications are not, and the implications are exactly what every product leader running a real company now needs to think about.

The Law

In 1956, a British psychiatrist and cybernetician named W. Ross Ashby published An Introduction to Cybernetics. Buried in it is what later became known as the Law of Requisite Variety, sometimes called the First Law of Cybernetics. The core idea is that every system has a property called variety, which is just the number of distinguishable states it can occupy. A light switch has a variety of two: on and off. A modern smart home with dimmers, schedules, scenes, voice control, and presence detection has variety in the millions.

Ashby’s law, in its plainest form, says this: for a system to remain stable in the face of disturbances, the controller must possess at least as much variety as the environment it’s trying to regulate. The slogan version, popularized later by management cybernetician Stafford Beer, is that only variety can absorb variety.

Translate that to business language. If your environment can throw a thousand kinds of problems at you, and your organization has thirty kinds of responses, you will lose. Not maybe. Eventually. The math is the math.

The contrarian implication, which Ashby himself flagged, is that complex situations do not call for centralized power. They call for distributed capability. In Ashby’s own words, the law disposes of the myth that extraordinarily complex situations demand the concentration of extraordinary powers in a central entity. The myth of the all-seeing CEO who can personally manage complexity through sheer force of intellect is, by Ashby’s framing, just that. A myth.

Why This Matters Right Now

Take a hard look at the environment a modern product leader is operating in. AI capabilities shifting on a quarterly basis. Customer expectations rebuilt by every new consumer app they touch. Regulatory regimes multiplying, from the EU AI Act to the patchwork of state privacy laws. Talent markets fluctuating with macro conditions and remote work norms. Competitors emerging from adjacent industries you weren’t watching.

That is a high-variety environment by any reasonable definition. The instinct in most companies, when confronted with that kind of turbulence, is to add more control. More approval layers. More dashboards. Tighter roadmap governance. A new VP of Strategy. A central PMO with a quarterly review process and a thirty-tab spreadsheet.

Ashby would tell you this is exactly backwards. Adding centralized control reduces internal variety while the environment is gaining it. The gap widens, not closes. You feel more in control because you can see more reports, but the system is actually less able to respond to the world it lives in.

This connects to a law I’ve written about before: Conway’s Law, which says that organizations design systems that mirror their communication structures. If your org has low variety, your product will have low variety. You cannot out-feature a competitor whose structure lets them understand problems your structure can’t even see. The shape of your team is the shape of your software, and the shape of your software is the shape of the customer experience.

So what does it look like when a leader actually takes this seriously? When they don’t just acknowledge that the environment is complex, but redesign the company so it can match that complexity?

There’s one example that stands out. It’s not a Silicon Valley story.

The Hammer in Qingdao

In the autumn of 1984, a young manager named Zhang Ruimin was sent to take over a near-bankrupt refrigerator factory in Qingdao, China. The factory was producing garbage. Worker morale was nonexistent. The company had defaulted on debts. Most managers in his position would have started with a strategy retreat.

Zhang started with a sledgehammer. He gathered the workers, lined up seventy-six defective refrigerators on the factory floor, and had them destroyed. “We can destroy the defective products ourselves,” he reportedly said, “or the market will destroy us.”

That moment is the founding myth of what became Haier, today one of the largest appliance manufacturers in the world. But the hammer is not actually the interesting part of the story. Plenty of leaders have done dramatic things to signal a culture change. The interesting part is what Zhang did decades later, when Haier was already winning.

By the early 2010s, Haier was a global juggernaut. It had grown into appliances, electronics, and international markets, and would later acquire GE Appliances in 2016. But Zhang was watching the environment shift faster than his company could respond. Mobile internet. E-commerce. The Internet of Things. Customers expected personalization that traditional manufacturing couldn’t provide. He saw, correctly, that a 1980s organizational design, even a successful one, could not handle a 2010s environment. The variety of the world was outpacing the variety of the firm.

So he did something almost no public company CEO has ever done.

He eliminated middle management. Not trimmed it. Eliminated it. According to a 2021 McKinsey Quarterly interview with Zhang himself, Haier removed an intermediate layer of more than 12,000 employees. The HR department went from 860 people to 11, replaced by a shared services platform.

In place of that hierarchy, Haier reorganized into roughly 4,000 self-managing microenterprises, each typically about ten people, each with its own profit-and-loss responsibility, each connected directly to user value. The model is called Rendanheyi, which roughly translates to the integration of employee value and user value. Microenterprises form themselves voluntarily around opportunities. They live or die based on whether they can create value for actual customers. If they can’t attract sufficient capital and revenue, they get dissolved, the way a startup runs out of runway.

If you read this through Ashby’s lens, what Zhang did is unmistakable. He didn’t add controls. He multiplied the variety of the system. Four thousand small teams can sense and respond to four thousand different signals from the market simultaneously. A central HQ with twelve thousand middle managers can sense, optimistically, a few dozen. The Haier of 2010 had the wrong shape for the world it was operating in. The Haier of 2020 had a shape that mirrored the variety of the market itself.

The numbers tell the story. Revenue from Haier Smart Home, the company’s listed home-appliance business, grew more than 18 percent annually from 2015 onward, topping 209 billion renminbi, roughly 32 billion US dollars, in 2020. According to the London Business School case on Haier’s transformation, growth accelerated rather than slowing as the company decentralized. When COVID hit, the GE Appliances unit Haier had acquired and converted to the microenterprise model posted double-digit revenue and profit growth, while most of its US peers contracted.

Zhang himself says other companies struggle to copy this. Adopting the model, in his words, requires giving up powers that most leaders simply will not give up: decision-making, hiring and firing, and setting compensation, all delegated entirely to the microenterprises themselves. One CEO he spoke with asked how he could possibly control his employees without those three powers. Zhang’s answer was that giving up that control is the model. Most leaders hear that and quietly close the case study.

Most of Us Don’t Need a Hammer

You don’t have to dynamite your org chart to apply Ashby’s Law. The point of the Haier story is not the specific structure. It’s the underlying question, which any leader can ask honestly without firing 12,000 people: does my organization’s internal variety match the variety of the environment it operates in?

If the answer is no, you have two options. You can attenuate the environment, meaning narrow your scope, focus on fewer customer segments, simplify the SKU set, or limit the markets you serve. Or you can amplify your variety, meaning decentralize decisions, add sensing channels, shorten feedback loops, and increase the diversity of perspectives in your decision rooms.

Both are legitimate. Pretending you don’t have to choose is what leads to the failures.

In practical terms, for product leaders, this means a few things. Push decisions down to the level closest to the relevant signal. If a PM has to escalate two layers to ship a copy change, the signal is decaying before it can be acted on. Hire for difference, not just credentials, because variety in people produces variety in responses. Run multiple smaller bets instead of one big one, because each bet is a different state your company can occupy. Instrument what your users actually do, not what your dashboards say they should be doing. Latency in feedback loops is variety lost.

And design your org to mirror the variety of customer problems you’re trying to solve, not the variety of internal political constituencies you’re trying to keep happy.

The Reckoning

Don’t ask whether your organization is complicated enough. That’s the wrong question. Complicated isn’t the goal. Variety is.

The right question is this. When your environment throws a problem you didn’t anticipate, who in your organization is positioned to recognize it and respond before it becomes a crisis? If the honest answer is the executive team in the next quarterly review, you have an Ashby problem. The signal is going to be a quarter old by the time anyone with authority sees it, and another quarter old by the time anyone responds.

Sit with that this week. Not as a thought experiment, as an audit. Pick three things that have surprised you in the last quarter. Customer behavior, a competitor move, a regulatory shift, a hiring miss, anything that you didn’t see coming. Now trace, honestly, who in your organization saw each one first. How long it took for that signal to reach a decision-maker. And how much of the original information survived the trip.

That gap, between what your environment is generating and what your organization can actually absorb, is the gap Ashby was talking about. It’s also the gap your competitors are living in, hoping you don’t close.

The hammer is optional. The reckoning is not.

Subscribe now

Share

We tend to tell this story as a triumph of technology. A man, a woodblock, the dawn of print. What gets lost in that framing is the actual motivation.

Wang Jie was not an innovator looking for scale. He was a Buddhist practitioner consumed by a very specific fear: that sacred teachings, passed hand to hand through manual copying, would drift, corrupt, and eventually disappear. Every time a monk copied a sutra by hand, small errors crept in. Passages shifted. Characters were misread, misremembered, misrendered. Across enough copies and enough time, the original meaning would be gone, replaced by a thousand confident variations of it.

The colophon at the end of the scroll tells you everything. It reads, in translation: “Reverently made for universal free distribution by Wang Jie on behalf of his two parents.” This was not a commercial venture. It was not ambition. It was an act of preservation driven by the fear that without a better system, the thing he cared about would not survive at scale.

Woodblock printing was not primarily faster than copying by hand. It was fundamentally different in kind. It did not reduce variation. It eliminated it. Every copy produced from the same block was identical. The message could not drift. The teachings could not corrupt. The fear of entropy had produced the world’s first printed book.

Wang Jie did not invent printing to scale knowledge. He did it to protect it from entropy.

That distinction matters more than it might seem. And it matters a great deal right now, in 2026, as companies everywhere race to adopt artificial intelligence.

The Manuscript Era of AI

Walk into most organizations experimenting with AI today and you will find something that looks, structurally, a lot like a ninth-century scriptorium.

The marketing team is using one set of tools with prompts they have built themselves. The product team is using a different model with different instructions and different guardrails. Customer support has deployed a chatbot that nobody in engineering has audited. Finance is running summarization workflows that legal has never seen. And someone in operations built a workflow six months ago that nobody else knows exists, producing outputs that vary meaningfully every time the underlying model gets updated.

Each team is working hard. Each team believes it is doing the right thing. The problem is not effort or intent. The problem is what happens when you add them all together.

This is the hand-copying phase of AI. And it carries the same risks Wang Jie was trying to solve.

The 2024 McKinsey State of AI survey found that 63 percent of companies using generative AI have no governance structures in place for managing the associated risks. Deloitte’s 2026 State of AI in the Enterprise report found that worker access to AI rose 50 percent in a single year, while only one in five companies has a mature governance model for autonomous AI agents. BCG research found that 74 percent of companies struggle to achieve value from AI at scale.

The gap between adoption and infrastructure is exactly what you would expect to see in the early days of any transformative technology. It is not a sign of failure. It is a phase.

But phases end. And the risks that accumulate during this one are not trivial.

Consider what happens when a company’s AI-generated customer communications are produced by four different teams using four different models with four different prompt conventions and no shared quality standard. The customer does not experience four teams. They experience one brand. And that brand is now producing outputs that no single human reviewed, designed, or can fully explain.

Or consider prompt drift: the phenomenon where the same task, run through the same model, produces meaningfully different outputs as the model is updated, the prompt is casually modified, or the context shifts. In a siloed environment, nobody is watching for this. Nobody owns it. By the time it surfaces, it has already shaped customer decisions, internal reports, or product behavior in ways that are difficult to trace.

This is not a technology problem. It is a systems problem. And it will not solve itself.

Right now, most companies are not scaling AI. They are copying sutras by hand.

The Printing Press Transition

The web offers a useful parallel. When the internet first emerged in the early 1990s, web development was a genuinely creative free-for-all. Every developer wrote their own HTML. Browsers interpreted that HTML in their own idiosyncratic ways. Netscape and Internet Explorer competed not by adhering to standards but by inventing new features faster than the other, leaving developers to write entirely different code for each browser just to make a single page render consistently.

It produced extraordinary innovation. It also produced what historians of the web call “tag soup”: bloated, inconsistent, browser-specific code that was expensive to maintain and impossible to scale. The more ambitious a site became, the more the inconsistency compounded.

The Web Standards Project, launched in 1998, was not an attempt to slow innovation down. It was an attempt to preserve what was working across the chaos of what wasn’t. HTML 4.0 and CSS gave developers a shared language. When browsers finally converged on those standards in the early 2000s, web development did not become less creative. It became far more scalable. The constraint turned out to be the foundation.

This is the pattern. Exploration precedes standardization. Standardization enables scale. The critical variable is timing.

Standardize too early and you kill the learning. The value of the manuscript phase is real. Teams experimenting independently discover what actually works. You cannot skip that stage. You need local learning before global standards, because the right standards emerge from practice, not from anticipation.

Standardize too late and the chaos calcifies. Inconsistency becomes debt. Every workaround, every team-specific convention, every undocumented prompt library becomes a thing someone has to unwind before you can build a coherent system on top of it. Like technical debt, this kind of AI debt compounds with time and scale.

The question is not whether to standardize. It is when, and what.

What Leaders Should Actually Do

The takeaways here are not about tools. They are about what Wang Jie actually did: he identified what was worth preserving, built the infrastructure to preserve it, and made the right approach the only approach. That sequence matters.

Let teams explore, for now. You are almost certainly still in the manuscript phase and that is not a problem. You need the variation. Teams experimenting independently are generating the evidence base you will need to make good decisions about what to standardize. The goal right now is not to stop the copying. It is to watch what the best copies have in common.

Watch for signal, not noise. Most of what teams are experimenting with will not survive contact with reality. A small number of prompts, workflows, and use cases will consistently produce results that are reliable, repeatable, and valuable. Those are the woodblocks. Pay attention to what works across contexts, not just what works in the team that built it.

Standardize patterns, not tools. The trap is to conflate standardization with vendor lock-in. You do not need everyone using the same model. You need everyone working from shared conventions about how AI outputs are reviewed, how prompts are versioned, how sensitive data is handled, and what constitutes an acceptable output in a customer-facing context. The printing press standardized the process, not the content.

Build printing presses, not rulebooks. Policies without infrastructure are just friction. If you want teams to follow shared practices, the shared practices need to be easier than the workarounds. An internal prompt library that teams actually use beats a governance document that nobody reads. An approved model stack with sensible defaults beats a policy prohibiting unapproved tools. Make the right way the easy way.

Time the shift deliberately. This is the hardest part. There is no universal answer to when your organization moves from exploration to institutionalization. But there are signals. If you are seeing customer-facing inconsistencies driven by AI outputs, that is a signal. If teams are reinventing the same workflows independently and producing different results, that is a signal. If a model update breaks something important and nobody knew it was coming, that is a signal. These are not technology problems. They are manuscript-era problems. They tell you the transition is overdue.

From Preservation to Scale

The Diamond Sutra did not survive twelve centuries because people cared deeply about it. Plenty of things people cared deeply about were lost. It survived because Wang Jie built a system that ensured copies would remain faithful to the original, regardless of who made them or when.

That is what AI transformation actually requires. Not discovery of what is possible, which is genuinely exciting and genuinely important, but a deliberate decision about what is worth preserving once you have discovered it. What works. What is reliable. What, when scaled, produces the outcome you actually wanted rather than a confident variation of it.

The organizations that will lead in AI are not the ones with the most experiments running right now. They are the ones that know when to stop copying by hand.

Every company experimenting with AI is writing its own sutras. The question is: when do you stop copying them by hand, and start printing them?

The transition will not be comfortable. Standardization never is. But the alternative, allowing the manuscript era to calcify into the default way of working, is how you end up with a scriptorium when your competitors have a press.

Subscribe now

Share

Stephen King is famously disciplined about it, producing thousands of words with near-mechanical consistency. Haruki Murakami approaches writing like endurance training, pairing it with long runs and rigid routines. John Grisham built his early career by waking up before work each morning to write in small, steady increments. And Daniel Pink has argued that our lives are ultimately shaped by what we do consistently, not occasionally.

It’s hard to argue with any of this. The logic is clean, the evidence overwhelming. Practice compounds. Repetition builds skill. Consistency removes the friction of starting. If you want to get good at something, you should do it regularly.

I don’t follow that advice.

I don’t write every day. I don’t keep a fixed schedule. I don’t sit down and force output when I don’t feel ready. And yet, over time, I’ve managed to write quite a bit. Just not in a way that resembles the standard playbook.

The difference isn’t that I reject discipline. It’s that I apply it somewhere else.

The Model Most of Us Are Taught

The “write every day” model works because it reduces uncertainty. You don’t wait for inspiration; you create conditions where inspiration is less necessary. Writing becomes a habit rather than an event. Over time, the mechanics fade into the background, and you develop fluency.

This pattern shows up far beyond writing. In engineering, we rely on continuous integration and deployment for similar reasons. Small, frequent changes reduce risk and increase reliability. In testing, iteration improves quality. The system gets better because it runs constantly, not because each individual run is perfect.

This approach optimizes for throughput. It’s designed to produce output consistently, and in many domains, that’s exactly what you want. If you’re learning a new skill or trying to build momentum, repetition is the fastest path forward.

But not all work is constrained by throughput. Some work benefits less from frequency and more from depth.

What I Actually Do

Instead of writing every day, I keep a running list of ideas.

Some are well-formed, but most aren’t. They’re fragments, an observation from a meeting, a question that doesn’t quite have an answer, a pattern I think I’m seeing but can’t yet articulate. Often it’s just a title with no content behind it, something that feels interesting without being clear why.

I don’t immediately act on these ideas. I capture them and move on.

Over time, I revisit the list. Not on a strict cadence, but periodically, usually when something else I’m working on reminds me of it. What I’ve found is that most ideas don’t hold up. They felt compelling in the moment, but when revisited, they don’t have enough substance to justify writing about. They fade quietly, replaced by new ones.

But a few behave differently.

They come back. They connect to other things I’m seeing or reading. They evolve slightly each time I think about them. Instead of losing energy, they gain it. They become harder to ignore.

Eventually, one of them reaches a point where it’s no longer optional. I’m not deciding to write it; I’m reacting to it. The structure is already there, the argument mostly formed. The act of writing is less about creating something new and more about capturing something that’s already been developing.

When that happens, the writing flows in a way that feels very different from forced output. It’s not effortless, but it’s directed. The hard thinking has already been done.

The Psychology Behind It

There’s a concept in psychology called the Zeigarnik effect, which suggests that people remember unfinished tasks better than completed ones. Open loops linger in our minds. They create a subtle tension that doesn’t fully resolve until the task is complete.

Most of us experience this as a distraction. An incomplete task keeps pulling at our attention when we’d rather focus on something else.

I’ve come to see it differently.

Each idea I capture is an open loop. By not immediately closing it, I’m effectively handing it off to my subconscious. It continues to process in the background, connecting the idea to new inputs, refining it, or discarding it altogether.

Over time, this creates a natural filtering mechanism. Weak ideas lose their tension and disappear. Strong ideas accumulate it. They persist, not because I’m forcing them to, but because they continue to feel unresolved.

Eventually, the tension becomes high enough that writing is the only way to release it.

In that sense, I’m not practicing writing every day. I’m practicing leaving things unfinished long enough for the right ones to become inevitable.

Two Different Ways to Create

The more I’ve thought about this, the more it seems like there are two distinct models of creative work, and we tend to talk about only one of them.

The first is the discipline loop. You take in inputs, produce outputs, and repeat the process on a regular cadence. This model builds skill through repetition and reduces dependence on mood or inspiration. It’s reliable, scalable, and broadly applicable.

The second is what I think of as the tension loop. You capture inputs, allow them to incubate, and let unresolved ideas build pressure over time. Output happens when that pressure crosses a threshold. This model is less predictable, but it tends to produce work that is more distilled, more connected, and often more original.

One model builds fluency. The other builds perspective. Both are useful. The mistake is assuming they are interchangeable.

Where This Shows Up in Product and Engineering

This distinction isn’t just about writing. It shows up in how we build products and lead teams, often in ways that aren’t immediately obvious.

In product development, we tend to default to the discipline loop. We maintain backlogs, prioritize work, and move items through the system as efficiently as possible. Progress is measured by throughput, how quickly we can turn ideas into shipped features.

There’s value in this. Without it, nothing gets built.

But it can also lead to a subtle failure mode. We treat all ideas as if they deserve immediate execution. The backlog becomes a queue rather than a filter, and we lose the ability to distinguish between ideas that are merely interesting and those that are actually important.

Time, in this context, is an underutilized tool.

Ideas that persist over time, that continue to surface in different forms across customer feedback, internal discussions, and market signals, are often the ones worth paying attention to. They behave the same way strong writing ideas do. They don’t fade; they accumulate tension.

When we rush to execute everything, we remove that filtering mechanism.

The Risk of Moving Too Quickly

One of the more common patterns I’ve seen in product teams is premature convergence. A problem is identified, and the team quickly aligns on a solution. From there, the machinery kicks in, design, build, ship, measure, iterate.

On the surface, this looks like progress. And sometimes it is.

But often, it’s a sign that we didn’t spend enough time understanding the problem in the first place. We closed the loop too early. The solution may be coherent, even well-executed, but it’s anchored to an incomplete understanding of the underlying issue.

This is where second-order effects start to appear. Features interact with user behavior in ways we didn’t anticipate. Metrics improve in the short term but drift away from the broader mission. What looked like a clean solution turns into a more complex problem over time.

As I’ve written before, every product release is effectively an experiment in human behavior. The quality of that experiment depends on the quality of the thinking that precedes it. And good thinking often requires resisting the urge to act too quickly.

Slack and the Space to Think

In engineering, we’ve learned that running systems at full capacity all the time creates fragility. Without slack, small issues compound into larger ones. Bugs accumulate, technical debt grows, and eventually the system slows down more than it speeds up.

The same principle applies to thinking.

If every moment is allocated to execution, there’s no space for ideas to develop beyond their initial form. Everything is acted on in its earliest, least refined state. The result is a steady stream of output, but not necessarily better output.

Slack, in this context, isn’t wasted time. It’s where refinement happens. It’s where weak ideas are discarded and strong ones are strengthened. When we eliminate slack, we don’t just move faster. We reduce the depth of our thinking.

Leadership and the Discipline of Waiting

This is where the distinction becomes most relevant for leadership.

Leaders are often evaluated on decisiveness. The ability to make quick, confident decisions is seen as a strength. And in many situations, it is. But there’s another, less visible skill that matters just as much: the ability to hold ambiguity without rushing to resolve it.

Leaving loops open is uncomfortable. Teams want direction, stakeholders want clarity, and there’s constant pressure to move forward. The temptation is to close the loop as quickly as possible, to replace uncertainty with action.

But not all problems benefit from immediate resolution.

Some require time to fully understand. They need to be reframed, tested against new information, and viewed from multiple perspectives. They need to accumulate context.

This isn’t indecision. It’s a different kind of discipline, the discipline to wait until the problem is clear enough that the solution, when it comes, is actually the right one.

Balancing the Two

None of this is an argument against consistency or practice. Those things are essential, especially when you’re building foundational skills or trying to create momentum.

But they’re not universally optimal.

The most effective creators, and the most effective leaders, seem to operate in both modes. They maintain systems for capturing ideas and engaging regularly with their work, but they don’t force output for the sake of output. They allow certain ideas to sit, to evolve, and to compete for attention over time.

They recognize that some value comes from doing more, and some comes from waiting longer.

Closing the Right Loops

Consistency is easy to measure. You can count the days you wrote, the number of commits, the features shipped. It’s visible, which makes it appealing.

What’s harder to see is the thinking that didn’t happen, the ideas that were never fully developed, the problems that were solved too quickly, the consequences that were never considered.

Some of the most important work happens in that invisible space, where nothing appears to be happening but everything is quietly evolving.

In writing, that’s incubation. In product, it’s judgment. In leadership, it’s restraint.

The goal isn’t to close loops faster.

It’s to understand which ones are worth leaving open long enough to matter.

Subscribe now

Share

Nobody moves. Nobody argues. Nobody offers to fix it. Because a number, sitting alone on a screen, does not tell you what to do next. It does not tell you what failed or how it failed. It does not tell you whether to panic or to pivot. A number is just a number, and this one is not a story yet. It is a fact looking for meaning.

In The Measurement Trap, I argued that an overreliance on metrics can lead organizations to chase the wrong things entirely, optimizing for the measurable at the expense of the meaningful. Nike chased digital conversion rates and lost its brand. Engineers chased KLOC and produced bloated code. Drucker and Deming both warned, in their different ways, that what gets measured gets managed, even when managing it harms the organization. That article was about the trap.

This one is about the escape.

The answer is not to throw away the metrics. It is to do something harder: learn to read them like a novelist instead of an accountant. Because the retention curve that just turned south is not just a number. It is the opening line of a story that someone in your organization needs to tell.

Numbers Do Not Move People. Narratives Do.

The reason dashboards so often fail to inspire action has nothing to do with the quality of the data. It has to do with how the human brain processes information.

In his research at Claremont Graduate University, neuroeconomist Paul Zak discovered that character-driven narratives trigger the release of oxytocin, the neurochemical associated with trust, empathy, and cooperation. Data does not do that. A slide showing a 12-point retention drop does not cause oxytocin release. A story about the customers behind that drop, what they were hoping for, why they left, what we could have done differently, does. Zak found that the amount of oxytocin released during a narrative predicted how willing people were to act, including donating money to strangers. The brain is wired to respond to stories in ways it simply does not respond to data.

The cognitive psychologist Jerome Bruner spent his career describing why this is the case. In his 1986 book Actual Minds, Possible Worlds, Bruner argued that humans operate in two fundamentally different cognitive modes. The first is the paradigmatic, or logico-scientific, mode: the world of argument, evidence, proof, and data. The second is the narrative mode: the world of intention, consequence, character, and meaning. These two modes are not competing, Bruner insisted, they are complementary. But they are irreducible to one another. You cannot replace one with the other. A well-formed argument and a good story are, as he put it, “different natural kinds.”

Most leadership dashboards are built entirely for the paradigmatic mode. They are designed to be logically impeccable. And they fail, repeatedly, to move anyone, because the people in the room are also operating in narrative mode, waiting for a story that never comes.

This is not a soft insight about human feelings. It is a structural observation about how meaning gets made. Metrics describe outcomes. Stories explain what outcomes mean and what they demand of us. The gap between those two things is where most leadership communication falls apart.

Learning to Read the Curve

So what does it actually look like to treat a metric as a story waiting to be told?

Take that retention curve that we started this article with. On the surface it is a straightforward graph: on one axis, time; on the other, the percentage of users or customers who have remained active. It slopes downward, always. The question is not whether it slopes, but where and how fast.

Here is the thing most leaders miss. The shape of that curve is not a performance report. It is a relationship arc. It describes a sequence of decisions, experiences, and emotions that real people moved through before they disappeared. Where users leave on that curve tells you the chapter of the story where your product or service lost them.

A steep drop in week one is an onboarding story. Something about the first experience failed to deliver on the promise of acquisition. The customer showed up, looked around, and left before the furniture arrived. A slow fade between months three and six is a value delivery story. The product worked well enough to stay, but not well enough to become indispensable. A sharp cliff at month twelve is almost always a renewal story, which is really a relationship story: at the moment of reckoning, the customer decided the relationship was not worth continuing.

Each of those shapes has a different hero, a different villain, and a different chapter where the story can be changed. Treating the curve as raw performance data collapses all of that nuance into a single direction: down. Treating it as narrative opens it up.

Donald Miller’s StoryBrand framework offers a useful scaffolding here. Every good story has a hero who wants something, a villain creating friction, a guide who helps, and a plan that leads to resolution. The same logic applies to a retention curve. The hero is the customer. The villain is the moment of friction or disappointment. Your product or team is supposed to be the guide. When the curve drops, it means the guide failed. The interesting leadership question is not “why did the metric go down?” It is “where in the story did we stop showing up for the hero?”

This reframe is not semantic. It changes what questions get asked in the room, who feels responsible, and what kind of response seems warranted. Data ask “what happened?” Stories ask “what does it mean, and what do we do next?”

The Difference Between a Report and a Reckoning

Most leaders present data. The best leaders use data to create a reckoning.

A report is “here is what happened.” A reckoning is “here is what this means, and here is what it demands of us.” The reckoning is where data becomes leadership. It is also, not coincidentally, where most presentations stop short.

The consequences of that gap can be severe. In his book Visual Explanations, the data visualization scholar Edward Tufte analyzed the night before the Challenger disaster. The engineers at Morton Thiokol had the data. They knew O-ring performance degraded at low temperatures. They had prior launch records. What they lacked was the ability to translate that data into a story compelling enough to stop a launch. Their slides arranged the information by launch date, not by temperature, burying the very pattern that mattered. The data pointed clearly at catastrophe. The presentation did not. Seven lives and a shuttle were lost, in part, because the story went untold.

When Steve Jobs returned to Apple in 1997, he did not open the all-hands meeting with a spreadsheet. He told a story about what Apple stood for. Every data point he subsequently shared, revenue figures, product cuts, market position, landed inside that narrative frame. The numbers did not carry the meaning. The story carried the meaning, and the numbers served as evidence.

The difference between Jobs and the Challenger engineers is not intelligence or access to information. It is whether the data was placed inside a story that gave it consequence.

Brene Brown’s research on vulnerability and trust adds a critical warning here. Leaders who tell only positive data stories, the carefully curated metrics that always trend up, eventually lose credibility with their teams. People know when they are being managed rather than leveled with. The retention curve that goes down is actually a more powerful narrative tool than the one that goes up, because it creates urgency, names an enemy, and invites the team into the fight. Honest reckoning builds more trust than optimistic reporting.

How to Actually Do It: The Story Frame

Here is a practical structure that you can use, which I call the Story Frame. It is not a presentation template. It is a thinking discipline. Three sentences, in sequence, before any metric gets shown to a team.

• The Before - The first sentence is The Before: what did we believe was true? What were we hoping for? This sentence establishes the expectation that the data will confirm or contradict. It introduces stakes. Without it, a metric has no reference point, it is just a number floating in space.

• The Reveal - The second sentence is The Reveal: what does the data actually show? This is where the metric lives, not at the top of the conversation, but here, after context has been established. The number now means something because the audience knows what it is measuring against.

• The So What - The third sentence is The So What: what does this mean for how we act, what we value, or who we want to be as a team? This is the reckoning. This is the sentence most leaders skip, either because they do not know the answer yet or because they are hoping someone else will provide it.

The Story Frame is a structure with roots in Terry Borton’s classic reflection model, but with one deliberate shift: The Before forces the leader to name the expectation, not just describe the event.

Here is what the Story Frame looks like applied to the opening scenario. The Before: “We believed our onboarding experience was strong. New users were reaching the activation milestone at rates consistent with industry benchmarks, and the product team had recently invested in a redesigned first-run flow.” The Reveal: “The retention curve shows 40% of users are gone by day seven. We are losing people before they have had a chance to see what we built.” The So What: “This is not a data problem. It is a story problem. We are telling new users the wrong story in their first week, and we need to find out what story they actually need to hear.”

Notice what happens when you run a metric through the Story Frame. It stops being a verdict and starts being an invitation. The team is not sitting in judgment of a number. They are being called into a narrative that needs a next chapter.

Most teams jump straight to The Reveal. They skip The Before entirely and treat The So What as someone else’s job. That is why so many business reviews end with slides that everyone has seen, heads that nod politely, and no meaningful change in what anyone does afterward.

The Leader as Narrator

The ability to translate metrics into meaning is not a data skill. It is a leadership skill. And like most leadership skills, it is unevenly distributed and consistently underpracticed.

This matters because the person who controls the narrative of a metric controls the team’s response to it. When a retention drop is framed as a technical failure, engineers feel responsible. When it is framed as a product-market fit question, the whole organization leans in. When it is framed as a customer relationship problem, customer success, marketing, and product all find themselves in the same story. The frame does not change the data. It changes who sees themselves as part of the answer.

The risk of getting this wrong runs in two directions. Leaders who tell only heroic data stories, cherry-picking metrics, setting up narratives where the team always wins, eventually find that their teams stop trusting the story. And leaders who turn every metric into a crisis burn out their organizations. The best narrators know how to hold tension and hope simultaneously: here is where we fell short, here is what it reveals, here is why we are the right team to fix it.

That is a harder thing to do in a room than pointing at a chart. It requires the leader to have done the thinking before they walk in, to have moved through the Story Frame themselves, to arrive not just with data but with perspective.

The metric is not the problem. The silence after the number is the problem. That silence is where leadership either shows up or it does not.

The Challenge

Before your next team review, pick one metric, just one, that you would normally present without comment.

Write three sentences. One for The Before: what did we believe? One for The Reveal: what does the data show? One for The So What: what does this demand of us?

Do not skip the third sentence. The third sentence is the job.

Then notice what happens in the room.

If you found this useful, you might also want to readThe Measurement Trap, which looks at why over-reliance on metrics causes organizations to lose sight of what actually matters. This piece is the practical companion to that one.

Subscribe now

Share

Then they heard it.

Out of the darkness came a howling that stopped both men cold. Not a single animal, but a chorus, rising and overlapping from directly ahead. Grant later wrote in his Personal Memoirs that to his ear it appeared there must have been enough of them to devour their party, horses and all, at a single meal. Benjamin leaned over and asked the question that was already forming in both their minds: “Grant, how many wolves do you think there are in that pack?”

Grant, not wanting to seem rattled, deliberately undersold his estimate. “Oh, about twenty,” he replied, very indifferently.

Benjamin smiled and rode on. A minute later they were close enough to see.

There were just two of them. Two wolves, seated on their haunches with their mouths pressed together, making all the noise that had seemed to announce an entire pack. Grant wrote the moral plainly: “There are always more of them before they are counted.”

He was talking about politicians. But he could just as easily have been talking about the last two years of enterprise software headlines.

This Is Not the First Time Someone Has Declared the End

Before we count the wolves in front of us today, it is worth noting how many times similar howling has echoed through business history, and how many times the obituaries were written prematurely.

In 1890, there were over 10,000 companies in the United States building horse-drawn carriages. By the late 1920s, only about 90 remained. The automobile had arrived, and for most of those 10,000 businesses, the story ended badly. But not for all of them. Some carriage makers did what their industry said was impossible: they pivoted, survived, and in one case, built the largest car company in the world.

William Durant was already wealthy and bored by the time the automobile appeared. He and his partner Josiah Dort had built the Durant-Dort Carriage Company into the largest vehicle manufacturer in the United States, with $2 million in annual sales at the turn of the century. Durant had pioneered vertical integration and multi-brand strategy in the carriage business, and he had turned carriages into aspirational products. He was, in the words of those who knew him, a master promoter and super salesman.

When the automobile arrived, Durant hated them. He thought they were noisy, smelly, and dangerous. According to General Motors’ own historical account, he initially refused to let his daughter ride in one. That position lasted until he actually got behind the wheel of one and recognized the exact same thing he had recognized years earlier in a horse cart at a county fair: an opportunity.

In 1904, Durant was asked to take over the struggling Buick Motor Company. He brought his carriage-era assets with him: the distribution network, the manufacturing relationships, the salesmanship, the instinct for branding across different price points. Within four years, Buick was the best-selling automobile in America, outselling Ford and Cadillac combined. In 1908, Durant used that momentum to incorporate General Motors, consolidating over a dozen car and parts companies into a single holding company. General Motors is still, more than a century later, one of the largest US car manufacturers by volume.

Durant did not just survive a revolution. He led the next one, because he understood that the skills, the systems, and the instincts he had built in the carriage era transferred directly into the new one. He did not abandon what he knew. He drove it straight into a different future.

Now move forward sixty years. In the early 1950s, television arrived in American living rooms and immediately began cannibalizing radio. By 1955, the traditional radio networks were reporting increasing financial losses. Their biggest stars, their most popular programs, their national advertisers: all migrated to the new medium. A 1949 Gallup poll found that nearly half of people who had seen television believed radio was finished. The consensus, inside and outside the industry, was that radio was done.

Radio is still here.

What happened was not that radio ignored television. It adapted by doing something only radio could do: it became portable, immediate, and local. The invention of the transistor radio made the medium mobile. Top 40 formats built around recorded music gave stations a reason to exist that television could not easily replicate. Talk radio and drive-time programming found audiences that wanted audio in their cars and at work, not a screen. By the 1990s, radio advertising revenue had more than doubled in a decade, reaching more than $17 billion annually by 2000. The medium that was supposed to die at the hands of television found a version of itself that television could not touch.

Two different industries, two different eras, same lesson: the threat was real, the transformation was genuine, and most of the survivors did not survive by doing the same thing. They survived by understanding which of their capabilities transferred and which ones did not.

The Bear Case Deserves an Honest Hearing

It is worth being clear about something before we go further: the threat to SaaS is real. Anyone who tells you otherwise is selling comfort, not analysis.

Since early 2026, ETFs tracking public software companies have fallen sharply, erasing gains accumulated since the launch of ChatGPT. Salesforce, Adobe, Intuit, ServiceNow, and others that had compounded investors’ capital for a decade are down significantly in a matter of weeks. The term “SaaSpocalypse” has entered the vocabulary and is, genuinely, not a fringe position.

The structural argument is straightforward. For two decades, the SaaS business model rested on a simple premise: take tasks that humans did manually, automate them into software, and charge per user seat. That model produced extraordinary margins and predictable recurring revenue. AI now threatens both sides of the equation. If AI agents can handle the tasks the software was automating, the case for a dedicated subscription weakens. If building custom software is becoming cheap enough to do in-house, the case for buying someone else’s weakens further.

Marc Benioff, the founder and CEO of Salesforce, stated publicly that his company would not be hiring software engineers in 2025 because AI could handle so much of the work. This is the CEO of one of the world’s largest SaaS companies saying, out loud, that the core input cost of software is collapsing. That is not nothing.

Andreessen Horowitz has been even more direct. Their analysis argues that “software is eating labor,” meaning AI is no longer just automating workflows but replacing the humans those workflows supported. The old playbook of per-seat SaaS pricing, they argue, is being replaced by outcome-based pricing, and incumbents who cannot make that transition without destroying their own economics are in genuine trouble.

So yes. The howling is real. The question is how many wolves there actually are.

Count the Wolves

When Grant and Benjamin rode toward the sound rather than away from it, they were doing something most people in moments of fear do not do: they went to count. Let’s do the same.

The first thing to count is the actual exposure. Not all SaaS is equally at risk, and the market is treating the category as if it were a single undifferentiated mass. It is not. a16z partner Alex Rampell has made this point clearly: the companies most vulnerable are those whose core value is automating tasks that AI can now handle directly, with no proprietary data advantage and no deep workflow entanglement. Those companies face genuine compression. But companies like Workday, ServiceNow, and Veeva sit on years of proprietary, structured, domain-specific data and are embedded into business processes at a level where replacement costs are measured in years of organizational disruption, not months of license fees.

The second thing to count is switching cost, which the market consistently undervalues. Ripping out an ERP system is not a technology project. It is a change management project, a compliance project, a training project, and an integration project all happening simultaneously. Companies that live inside regulated industries, whether healthcare, financial services, or construction, are not going to replace their systems of record with AI agents built on a weekend. The compliance moat is structural, and it does not shrink just because the underlying models get better.

The third thing to count is what actually happened to the incumbents in the previous transition. When cloud computing arrived, the consensus was that on-premise software vendors like Oracle, SAP, and IBM would be wiped out. They were not. They adapted slowly, awkwardly, and with considerable pain, but they retained their enterprise customer bases precisely because those customers were not going to abandon a decade of customization and integration just because a newer delivery model existed. The pattern has every reason to repeat.

The fourth thing to count is where AI is actually winning today versus where the fear assumes it will win. The categories experiencing real disruption right now are, as a16z notes, point solutions with no data moat, no network effects, and per-seat pricing for tasks that are genuinely automatable. Standalone scheduling tools, basic customer service bots, single-use analytics dashboards. These are real casualties. They are not the same as the death of enterprise software.

In the words of Sequoia’s analysis of the current moment, both the software and services profit pools are under attack, and the opportunity is enormous. But the same analysis points out that the greatest value in the AI era will likely be created at the application layer, by companies that own proprietary data, solve complex real-world problems, and build the kind of deep workflow integration that does not disintegrate when a better foundation model ships.

What Changes, and What That Means for You

Here is the part worth considering carefully: the carriage makers who died were not the ones who took the automobile threat seriously. They were the ones who confused “we are not dead yet” with “we do not need to change.”

Radio did not survive by ignoring television. It survived by honestly assessing what it could do that television could not, and then doing more of that. Portability. Locality. Intimacy. The medium found the version of itself that the threat could not touch, and it built there.

Durant did not survive by defending carriages. He survived by asking a different question: which of the capabilities I have built transfer into the new era? His answer turned out to be almost everything that mattered: distribution, brand strategy, multi-product architecture, salesmanship, vertical integration. The vessel changed. The skills did not.

The question for every SaaS leader right now is not “will AI disrupt my category?” It will. The question is which parts of what you have built are genuinely defensible, and which parts were just the easiest path to growth in an era when the cost of intelligence was high enough that automation itself was the moat.

Two questions are worth asking honestly, not in a board presentation but in a room with your product and engineering leads:

1. If a well-funded team used the best available AI tools for six months, could they build a functionally equivalent product? If the honest answer is yes, that is a problem that needs to be named and addressed, not managed around. If the honest answer is no, the next question is what specifically makes that true, because that is what needs to be protected and extended.

2. What data does your product generate or hold that has no substitute? This is the question Durant answered without knowing he was answering it. His distribution network, his multi-brand customer relationships, his manufacturing knowledge: none of those lived in the carriages. They lived in the organization. They transferred.

Ride Toward the Sound

Grant and Benjamin did not turn back when they heard the howling. They did not hold an emergency meeting about wolf strategy. They rode toward the noise, got close enough to count, saw two animals instead of twenty, and understood the situation for what it was rather than what it sounded like.

The SaaS apocalypse is not a fiction. The threat is real and some companies will not survive it, specifically the ones that are counting on the same business model they had in 2019 to protect them through 2030. But the pack is smaller than the howling suggests, and the companies that will come out of this transition are not the ones that ignored it or the ones that panicked into incoherence.

They will be the ones that rode towards the sound, counted the actual wolves, and built from what they found.

Subscribe now

Share

Researchers who study this phenomenon don’t just chalk it up to adjustment difficulty or the proverbial “reintegration challenge.” They’ve found something far more clinically significant. Veterans who struggle most after service are not only those with high combat exposure. Social connectedness also appears to play a powerful protective role. Studies have found that leaving military service, like leaving any tightly bonded community, requires establishing a new community and a new sense of connectedness to it, and that social connectedness serves as one of the most powerful protective factors against the development of PTSD symptoms. In a study of 722 veterans, the more connected a veteran felt, the less likely they were to develop the disorder, even controlling for combat exposure.

The flip side is even more striking. Research published in Developmental Psychology found that PTSD can destabilize a person’s identity, disrupting the sense of temporal integration and leading to a loss of self that further degrades quality of life and impairs social and professional relationships. It’s not just that you feel bad. It’s that you stop knowing who you are.

I know that sounds extreme for a newsletter about leadership and organizational culture. But bear with me. Because what the veteran story illustrates in high relief is something that plays out at lower voltage in workplaces everywhere, every single day: when people don’t feel like they belong, they don’t just disengage. They start to lose themselves. And that has consequences that no performance management system was designed to catch.

The Science of Needing to Belong

In 1995, two psychologists named Roy Baumeister and Mark Leary published what would become one of the most cited papers in social psychology. Their argument was deceptively simple: belonging isn’t a nice-to-have. It is a basic, powerful, and universal human motivation, as fundamental as the need for food, shelter, and safety.

They weren’t making a philosophical claim. They reviewed decades of research across psychology, sociology, anthropology, and evolutionary biology, and what they found was that people form social attachments readily under almost any conditions, and resist losing them with a ferocity that tells you something important about the underlying drive. Lack of belonging is linked to a wide range of ill effects on health, adjustment, and well-being, with measurable effects on both emotional patterns and cognitive processes.

Consider an experiment that has been rattling around in addiction research since the late 1970s. Canadian psychologist Bruce Alexander noticed something odd about the standard lab studies on drug addiction: they were all conducted on rats kept alone in small, bare cages. When those isolated rats were given a choice between plain water and morphine-laced water, they chose the morphine, repeatedly and compulsively, until many of them died. The accepted conclusion was that the drugs themselves were irresistibly addictive. Alexander wasn’t so sure. He built what he called Rat Park, a large, enriched enclosure filled with tunnels, climbing platforms, running wheels, and plenty of other rats to socialize and mate with. He then offered the same choice: plain water or morphine water. The Rat Park rats largely ignored the drugs. In some conditions, the isolated rats consumed nearly twenty times more morphine than their socially housed counterparts. Alexander’s broader point was not that drugs do not matter, but that environment and isolation can powerfully shape addictive behavior. The research has its critics and some replication challenges, but its central insight has proven durable, that isolation doesn’t just make us lonely. It makes us reach for something to fill the void.

Maslow, of course, put belonging right in the middle of his famous hierarchy, above food and safety, but below esteem and self-actualization. Baumeister later suggested it might matter even more than having an intimate relationship. When someone feels like they are genuinely part of something, everything else downstream gets better: their mood, their performance, their willingness to take risks, their investment in outcomes. Strip that away, and the whole structure starts to wobble.

The question, then, is what happens when we take this wiring and drop people into the modern workplace.

What the Numbers Actually Say

Let’s be honest about the data, because it’s one of those situations where the numbers are so stark that you wonder why they aren’t tattooed on the foreheads of every people manager in America.

According to research from BetterUp, 40 percent of people say they feel isolated at work. Forty percent. That’s not a fringe condition, that’s nearly half the workforce showing up every day to a place where they don’t feel like they’re truly part of something.

The consequences are not subtle. High belonging is linked to a 56% increase in job performance, a 50% drop in turnover risk, and a 75% reduction in sick days. For a 10,000-person company, BetterUp estimates this translates to more than $52 million in annual savings. That’s not an HR metric. That’s a P&L item.

Here is the one that stops me cold, though. A survey of higher education IT and technology professionals found that 90% of respondents who reported a strong sense of belonging also reported job satisfaction, compared to just 8% of those without it. Ninety percent versus eight percent. I want you to sit with that gap for a moment. There is almost no other single variable in organizational behavior that produces a spread that wide.

And, according to Qualtrics, employees who score highest on belonging have a 34% higher intent to stay than those who score low, which matters enormously when you consider that the average employer spends around $4,000 and 42 days filling a single open role. The cost of not belonging isn’t just human. It’s financial.

Belonging and Identity: The Deeper Tie

Let’s go back to the veteran and the athlete for a moment, because I think that example teaches us something that sanitized corporate language tends to obscure.

When a service member or team member puts on the uniform for the first time, something happens that isn’t just about the clothes. They inherit a language, a hierarchy, a set of values, a shared understanding of hardship and sacrifice that creates an almost immediate sense of we. Social identity theory tells us that belonging to valued social groups provides social connectedness, and that this shared sense of identity is crucial in conceptualizing the self, with profound implications for overall wellbeing.

When you stop belonging to something, you stop knowing who you are. Your self-concept requires external confirmation. It needs a mirror, and the mirror is your community.

This is not limited to veterans or athletes. The same pattern shows up in corporate restructurings, in acquisitions where cultures collide, in remote-work transitions that stripped people of their daily social scaffolding. The specifics differ. The neuroscience doesn’t. A person who is told, explicitly or implicitly, that they don’t quite fit will eventually internalize that message.

The Manager as Belonging Architect

If there is one variable that research consistently identifies as the strongest lever for belonging at work, it is the immediate manager. Not the CEO’s vision statement. Not the culture deck. Not the all-hands keynote. The manager.

The data on managers is unambiguous: employees who trust their managers, believe that their managers care about them as individuals, and feel that their perspectives are heard experience a high sense of belonging. The inverse is equally true. A manager who is distracted, transactional, or indifferent, even a competent one, systematically depletes belonging in every interaction.

Think about what this means in practice. Every one-on-one meeting is either a deposit or a withdrawal. Every performance review either affirms that someone matters or reduces them to a set of metrics. Every team dynamic shaped or ignored by a manager sends a signal about who belongs and who is merely tolerated.

What does good look like? It starts with the simplest thing in the world, which is treating people like people. Recognizing the individual, not just the output. Being curious about what someone is working through, not just what they’re working on. Creating space for honest contribution rather than performative agreement. None of this requires a budget. Most of it requires attention, which, in the current environment of fractured focus and Slack-saturated calendars, has become the true scarce resource.

Belonging is also, critically, fluid. It isn’t established once at onboarding and then banked. A culture built over three years of intentional leadership can evaporate in two months under a manager who stops listening. New leaders, restructurings, team changes, all of these reset the belonging calculus, and someone needs to be paying attention when they do.

The Remote Work Wrinkle

The pandemic forced a stress test on organizational belonging at a scale no researcher could have designed. Tens of millions of people were suddenly working in physical isolation, and the question everyone was asking was: can you belong somewhere you can’t physically be?

The short answer, thankfully, is yes, but it doesn’t happen by default. Studies found that belonging can still exist for fully remote employees to the same extent it exists for in-person employees, and that regular virtual meetings and social events meaningfully contribute to that sense of connection. The more important finding is this: organizational culture and climate are likely more important than physical workspace when it comes to whether employees feel they belong.

Remote work doesn’t kill belonging. Indifferent leadership does. The office never created belonging on its own, it just made it easier to do the things that create belonging: casual conversations, shared meals, visible recognition, the spontaneous moments of human contact that accumulate into trust. If you move to remote or hybrid and don’t deliberately recreate those conditions, you haven’t gained flexibility. You’ve just moved the loneliness into people’s homes.

The Question Every Leader Should Be Asking

The veterans and former athletes who navigate the transition successfully aren’t necessarily the ones with the most skills or the most medals. They’re the ones who find a new tribe, a team, a company, a community, that gives them a sense of shared identity and mutual investment. What saves them is not a program. It’s belonging.

The parallel to the civilian workplace should be impossible to miss.

Every leader ought to be asking themselves, honestly, a handful of questions. Do the people who work for you know, in their bones, that they matter to you as human beings and not just as headcount? Is the culture you’re creating one where contribution is invited or merely tolerated? And when someone new arrives, is there a deliberate effort to bring them into the tribe, or are they just left to figure out the unwritten rules on their own?

These are not soft questions. The research suggests they are among the highest-leverage questions a leader can ask, more predictive of performance, retention, and team health than almost anything else you might optimize for.

The best organizations don’t just give you a paycheck. They give you a shared language, a sense of purpose, a reason to show up that transcends the specific task in front of you. That is not a recruitment tagline. That is, increasingly, a documented competitive advantage, and it is built, or destroyed, one interaction at a time.

The most dangerous person on your team isn’t the loudest critic or the lowest performer. It’s the one who has quietly decided they don’t belong here, started to believe it, and hasn’t left yet.

Subscribe now

Share

Content note: This article discusses deaths on Mount Everest, including descriptions of bodies that remain on the mountain. While these stories serve as metaphors for business leadership lessons, readers sensitive to discussions of death and human remains may wish to proceed with awareness.

At 27,900 feet on Mount Everest’s Northeast Ridge, there’s a small limestone cave that every climber ascending from the north side must pass. Inside, curled in a fetal position, lies a body wearing bright green Koflach mountaineering boots. For nearly two decades, thousands of climbers trudged past this spot, using it as a navigational landmark. Some paused to catch their breath. Others took photos. Most simply noted the location and kept moving toward the summit.

The body is widely believed to be Tsewang Paljor, a 28-year-old Indian climber from the Indo-Tibetan Border Police. On May 10, 1996, Paljor and his teammates were caught in a blizzard just short of the summit. His team radioed that they had reached the top, but they never made it back down. Paljor sought shelter in this alcove, where exposure and oxygen deprivation claimed his life. His green boots, remarkably preserved in the thin, cold air, became his defining feature, and his legacy. The true identity of the climber has never been officially confirmed, which in its own way deepens the lesson.

Green Boots became more than just a body on Everest. He became a cautionary tale. A warning. A permanent reminder that ambition without judgment can leave you frozen in place, serving as someone else’s lesson about what not to do.

In business, we have our own Green Boots. Companies and leaders whose failures are so visible, so instructive, that they become case studies in MBA programs and cautionary tales in boardrooms. WeWork. Theranos. FTX. These aren’t just failures, they’re landmarks. Permanent markers of hubris, poor judgment, and the catastrophic consequences of ignoring warning signs.

The question every leader must ask isn’t whether you’ll face adversity or make mistakes. You will. The question is whether your failures will become footnotes in your learning journey, or whether they’ll become permanent warnings to others about what happens when ambition eclipses wisdom.

When Ambition Becomes Warning

Not every failure becomes a cautionary tale. Most mistakes are private, corrected quietly, learned from internally. But some failures are so spectacular, so visible, that they transcend the individual or organization and become permanent teaching tools for others.

What transforms a failure into a cautionary tale? Three elements converge.

Visibility. The failure happens in full public view, impossible to ignore or sweep away. Green Boots lies directly on the climbing route. WeWork’s implosion played out in business headlines globally. Theranos’ fraud trial captivated the nation. These failures couldn’t be hidden.

Preventability. In hindsight, the warning signs were visible to others. Multiple people raised concerns. The conditions demanded retreat. But the leaders pressed forward anyway, driven by summit fever, overconfidence, or willful blindness.

Permanence. The failure becomes a teaching tool, cited repeatedly to justify caution. “Remember what happened to…” becomes the opening line of every objection to bold action.

WeWork: Growth Without Economics

At its peak in 2019, WeWork was valued at $47 billion, fueled by Adam Neumann’s vision of redefining not just office space but human consciousness itself. The company burned $2 billion annually with no clear path to profitability. Neumann treated WeWork as his personal treasury, buying buildings and leasing them back to the company at a premium, trademarking “We” and charging millions for its use, taking out interest-free loans, and flying on private jets while the company hemorrhaged cash.

The business model was fundamentally flawed. WeWork was a landlord with long-term lease obligations and short-term tenant commitments, dressed up as a tech company to justify tech valuations. When the IPO prospectus revealed the financial reality, the valuation collapsed by 80% in weeks. Neumann was ousted. Thousands lost their jobs.

The lesson: Growth without governance is a house of cards. Unit economics matter. No amount of charisma or vision can substitute for a viable business model. WeWork is now taught in business schools as a cautionary tale about conflating hypergiant funding with sustainable growth.

Theranos: Fake It Till You Make It in Healthcare

Elizabeth Holmes promised to revolutionize blood testing with technology that could run over 240 tests from a single drop of blood. At its zenith, Theranos was valued at $9 billion. Holmes graced magazine covers, was compared to Steve Jobs, and assembled a prestigious board including Henry Kissinger and James Mattis.

There was just one problem: the technology didn’t work. The machines couldn’t perform the tests as advertised. Most blood samples were tested on traditional equipment purchased from Siemens. Results were often inaccurate, potentially endangering patients. When Wall Street Journal reporter John Carreyrou began investigating, he uncovered a culture of fear where whistleblowers were threatened with lawsuits and employees were fired for raising concerns. This eventually led to his book Bad Blood: Secrets and Lies in a Silicon Valley Startup.

Holmes multiplied the voting rights of her shares to give herself 99% of total voting control, making it functionally impossible for the board to intervene even after some members learned of the deception. She leveraged the “fake it till you make it” mantra of Silicon Valley, but applied it to medical devices with life-or-death implications.

In 2022, Holmes was convicted of criminal fraud and conspiracy to commit fraud. She received an 11-year prison sentence. Theranos dissolved, leaving investors with total losses and patients with potentially harmful medical advice based on faulty test results.

The lesson: Charisma cannot substitute for substance. Governance structures that concentrate power prevent accountability. In industries where safety matters, healthcare, financial services, infrastructure, cutting corners isn’t just unethical, it can become criminal. The “move fast and break things” ethos has limits.

FTX: The House Built on Vapor

In November 2022, cryptocurrency exchange FTX collapsed practically overnight, wiping out $8 billion in customer funds. Founder Sam Bankman-Fried had built FTX into the second-largest crypto exchange in the world, with a valuation of $32 billion. He cultivated an image as the responsible adult in the wild west of crypto, living modestly and pledging to give away his fortune.

Behind the facade lay catastrophic governance failures. FTX had no board of directors for the first three years of its existence. Critical business decisions were documented via Slack, Signal, and Telegram, ephemeral messaging systems that leave no audit trail. Customer funds were commingled with Alameda Research, Bankman-Fried’s trading firm, and used for high-risk trades without customers’ knowledge or consent.

When customers rushed to withdraw their funds, FTX couldn’t meet the demand. The house of cards collapsed. Bankruptcy proceedings revealed what the court-appointed CEO called “a complete failure of any internal controls or governance whatsoever.”

Bankman-Fried was convicted on seven counts of fraud and conspiracy and sentenced to 25 years in prison. Customers lost billions. Employees lost their jobs. The crypto industry’s reputation sustained yet another devastating blow.

The lesson: Regulatory gaps don’t excuse fundamental fiduciary duties. Even fast-moving, innovative companies require basic governance structures. Trust without verification is negligence. The absence of adult supervision invites disaster.

The Warning Signs Before You Become the Warning

These three companies didn’t fail suddenly. The warning signs were visible for years. People inside and outside the organizations raised concerns. But the leaders pressed forward, driven by summit fever, convinced of their own exceptionalism, or actively suppressing dissent.

How do you recognize when you’re on the path to becoming a cautionary tale? Here are the warning signs, framed through lessons from Everest and business disasters.

Summit Fever: Prioritizing the Goal Over the Conditions

On Everest, summit fever is the phenomenon where climbers prioritize reaching the top over their safety. They ignore the 2 PM turnaround rule, a guideline that says no matter how close you are to the summit, if you haven’t reached it by 2 PM, you must turn back to ensure enough daylight for descent.

Tsewang Paljor and his teammates pushed past safe turnaround times. They may have reached the summit, their final radio transmission claimed success, but they paid with their lives on the descent. The achievement didn’t matter because they didn’t survive to tell the story.

In business, summit fever shows up as pulling forward future revenue to hit quarterly targets, shipping products you know aren’t ready because you’ve promised investors a specific timeline, pushing teams past sustainable limits because you’ve publicly committed to deadlines, and focusing on vanity metrics that look good but don’t reflect underlying health.

Ask yourself: “Am I doing this because it’s the right thing for the long-term health of the organization, or because I’ve publicly committed to it and can’t back down?” If the honest answer is the latter, you’re experiencing summit fever. This is when leaders must have the courage to disappoint in the short term to preserve viability in the long term.

Oxygen Deprivation: Making Decisions Without Clear Thinking

Above 26,000 feet, Everest’s “death zone”, the human body literally begins to die. There isn’t enough oxygen to sustain normal brain function. Judgment deteriorates. Decision-making becomes impaired. Climbers make choices they would never make at sea level.

The business equivalent is operating in continuous crisis mode, making major strategic decisions while exhausted, stressed, or under extreme pressure without time for reflection or consultation. The warning signs: chronic emergency mode with no reprieve, significant strategic choices made at 2 AM or after marathon meetings, no time to consult trusted advisors, dismissing experienced team members as “not understanding the vision,” and the loss of perspective that comes when everything feels existential.

Build “base camps” into your operating rhythm, forcing functions for reflection and recalibration. Monthly strategy reviews. Quarterly board discussions focused on long-term health. Annual retreats with a single agenda item: are we still doing the right things?

As retired General Stanley McChrystal describes in his book Risk, we can’t always control the threats we face, but we can control our vulnerabilities. His formula is a useful lens: Risk = Threat × Vulnerability

The threat may be constant, but reducing your vulnerability through clear thinking and disciplined governance meaningfully reduces your overall exposure. Don’t make life-or-death decisions for your company when you’re in the death zone.

Solo Climbing: Ignoring Your Team and Silencing Dissent

One of the most haunting aspects of Green Boots’ story is what happened in 2006. British climber David Sharp stopped to rest in the same cave where Green Boots lay. Sharp was climbing solo, with minimal supplemental oxygen. He never stood up again.

More than 40 climbers passed David Sharp as he sat dying. Some thought he was already dead. Others were too exhausted to help. A few tried to rouse him but couldn’t. Sharp died where Paljor had died, in the same cave, while dozens of people literally stepped past him on their way to the summit.

The mountaineering community erupted in recrimination. The debates continue. But the broader lesson is this: when you’re isolated, when you’ve separated from your team, no one can help you even if they want to.

In business, solo climbing looks like this. Theranos’ board was filled with impressive names, Kissinger, Mattis, Schultz, but none had relevant expertise in blood testing or medical devices, and Holmes’ 99% voting control ensured they couldn’t replace her. The board was prestigious but powerless. At Theranos, would-be whistleblowers were threatened with lawsuits; employees who raised concerns were fired and marginalized. WeWork’s governance baked in conflict of interest from the start.

When the Wall Street Journal began investigating Theranos, the response was litigation threats, not transparency. When WeWork’s IPO prospectus revealed concerning financials, Neumann initially dismissed the concerns rather than addressing them.

David Sharp died alone while more than 40 people walked past. In business, when you’ve isolated yourself from genuine feedback, silenced dissent, and surrounded yourself with people afraid to tell you the truth, no one can help you when things go wrong.

When Leaders Turned Back Successfully

Turning back doesn’t mean failure. Sometimes it means wisdom.

Microsoft under Satya Nadella killed Windows Phone despite massive sunk investment, years and billions trying to make mobile work. Nadella admitted the strategy had failed, cut losses, and redirected resources to cloud computing and AI. Microsoft’s market cap has since grown by over $2 trillion. He didn’t become a cautionary tale because he acknowledged reality and changed course before external forces compelled him to.

The difference between wisdom and becoming a cautionary tale often comes down to a single question: Can you admit when you’re wrong before the mountain makes the decision for you?

From healthcare’s Morbidity and Mortality conferences to aviation’s accident investigation boards, high-reliability organizations have formalized systems for learning from failure. The same discipline is available to any leadership team willing to build it in.

Blameless postmortems focus reviews on what happened and how to prevent recurrence, not on who to blame. Every major failure gets a written document shared widely. Make your mistakes institutional knowledge, not individual shame.

Pre-mortems and red teaming surface risks before failures occur. Practice thinking about how things could go wrong while there’s still time to change course.

Celebrating intelligent failures attempts at innovative solutions that didn’t work out but resulted from good judgment and reasonable risk, not from recklessness or ignoring warning signs, signals to your organization that learning matters more than appearing infallible.

Final Thought

Here’s the haunting reality: Tsewang Paljor may have reached the summit of Everest. His team radioed that they had made it to the top. By the narrow definition of success, standing on the highest point on Earth, Paljor achieved his goal. But it didn’t matter.

The achievement meant nothing because he didn’t survive the descent. His name isn’t celebrated as a successful summiter. It’s memorialized as “Green Boots”, a cautionary tale about pushing too far. And because his identity was never officially confirmed, even his name is uncertain. He exists only as a warning.

The mountain is littered with the bodies of people who didn’t turn back. Who pushed just a little farther. Who believed they were different, special, exempt from the rules that applied to everyone else.

Unless someone’s life is literally on the line, there is never a need to be reckless with a team, a company, or a career. Be ambitious, but not reckless. Set the bar high, but build the systems to reach it safely. Know when conditions demand you turn back, even when the summit is visible.

The summit will always be there. Your team, your company, your legacy, those may not be.

Don’t become someone else’s lesson. Build something that teaches different lessons entirely: about sustainable growth, about learning from mistakes, about the courage to change course, about leadership that prioritizes long-term viability over short-term glory.

The bodies on Everest remind us that reaching the top doesn’t matter if you don’t accomplish it the right way and make it back down.

Subscribe now

Share

As the plane descended, the pilots transitioned from an instrument-guided approach to a visual one. Below them, runway lights appeared in the darkness. The alignment looked right. The approach felt right. The confidence was complete.

The wheels touched down.

Only after heavy braking did the problem reveal itself. The runway was far shorter than expected. The plane slowed with little margin to spare. The aircraft came to a stop just before the end of the pavement.

The pilots hadn’t landed at Branson Airport at all. They had landed at a nearby, much smaller airport, M. Graham Clark Downtown Airport, by mistake.

What makes this story unsettling isn’t that something exotic or chaotic happened. There was no equipment failure. No bad weather. No rogue behavior. No dramatic lapse in training. These were competent professionals operating in a routine environment.

The error occurred at the exact moment when everything felt most certain.

Certainty Is Not the Same as Correctness

It’s tempting to summarize this story as “mistakes happen.” Aviation accidents are often reduced to a list of contributing factors: lighting conditions, airport proximity, human error. But that framing misses the deeper lesson.

This wasn’t a one-off mistake. It was a repeatable failure mode. Unchecked certainty under time compression.

The Southwest crew had procedures available to cross-check their visual identification against their navigation displays. The correct airport was depicted on their cockpit screens the entire time. The NTSB found that once the crew visually acquired what they thought was the runway, they stopped referencing those displays. This is the uncomfortable truth about procedural safeguards: they only work if people keep using them under pressure. Which is why the design question isn’t just “do we have a checklist?” It’s “what makes the checklist unskippable at the exact moment skipping feels justified?”

Once the pilots visually acquired a plausible runway, their brains did what human brains are very good at doing: they stopped looking for disconfirming evidence. The visual matched the expectation. The expectation reinforced the visual. Confidence closed the loop.

This is expectation bias and confirmation bias working together. Once you think you know what you’re seeing, you selectively notice evidence that supports that belief and ignore what contradicts it. The problem is not that this bias exists. The problem is that it feels like clarity.

Aviation learned this lesson the hard way, decades ago. That’s why modern cockpits are filled with checklists, callouts, cross-checks, and redundancy. Pilots are trained not to trust a single sense, a single system, or a single moment of confidence, especially during high-speed, high-consequence phases of flight.

Now contrast that with leadership.

Strategy, product decisions, and organizational bets are almost always made with imperfect information. The data is partial. The signals are noisy. The environment is changing faster than our models. And yet, we routinely make decisions that carry enormous downstream consequences based on what “looks right” in the moment.

Experience doesn’t protect us from this. In many cases, it makes it worse. The more experienced you are, the more coherent your mental models become. The more patterns you’ve seen, the easier it is to snap new situations into familiar shapes. Confidence becomes efficient. It also becomes dangerous.

The pilots who landed on the wrong runway weren’t inexperienced, they were experienced enough to stop checking.

The real risk in leadership isn’t being wrong, it’s becoming confident too early.

The Product Leader’s “Visual Approach”

In aviation, a visual approach means transitioning from instrument-based navigation to visually identifying the runway. It’s not inherently unsafe, but it requires additional verification precisely because visual cues can be misleading.

Product organizations make this transition all the time, often without noticing.

A product “visual approach” happens when teams move from instrumented verification, data, experiments, structured learning, into narrative-driven reasoning. The dashboards fade into the background. The anecdotes get louder. The decision begins to feel obvious.

You’ve seen this pattern, even if you haven’t named it. A team says, “Users love it,” based on a handful of enthusiastic conversations, while adoption data is thin or ambiguous. A roadmap item gains momentum because a competitor shipped something similar, not because the underlying problem has been validated. A strategy hardens because a senior leader endorsed it early, and now revisiting it feels like dissent rather than diligence.

Sometimes it shows up in ambiguous markets. Two customer segments look similar at first glance. Early traction exists in both. The signals overlap. Instead of slowing down to differentiate, the team commits to one path and retrofits the story to justify it.

In each case, the move away from verification feels reasonable. It feels efficient. It feels like progress. And that’s the trap.

Many product failures don’t come from bad ideas. They come from stopping verification too soon. The moment a narrative becomes internally consistent is often the moment teams stop asking, “What would prove this wrong?”

Why Red-Teaming Disappears When You Need It Most

At this point, someone usually says, “That’s why we encourage healthy debate,” or “That’s why we hire smart people who challenge assumptions.” That sounds good but it rarely works.

Red-teaming, actively testing assumptions and searching for disconfirming evidence, cannot be a personality trait. If it depends on someone being brave, contrarian, or stubborn enough to speak up, it will vanish under pressure.

When timelines compress, when stakes rise, when launch dates approach, organizations don’t become more reflective. They become more decisive. Consensus hardens. Momentum takes over. The social cost of slowing things down increases.

If skepticism is optional, it will be skipped. This is why red-teaming has to be procedural, not a cultural aspiration. It has to be something the system does, not something individuals occasionally attempt.

Properly designed, it’s a service to the decision. It exists to protect teams from the very human tendency to confuse confidence with correctness.

Aviation doesn’t ask pilots to “be more skeptical.” It gives them checklists. Product organizations should take the hint.

The Southwest crew in Branson had every procedural tool they needed. Their navigation displays showed the correct airport. Their standard operating procedures called for verifying visual identification against those displays. What the NTSB found is that once the pilots visually acquired a plausible runway, they stopped consulting the instruments entirely. The checklist existed. The cross-check existed. Under the quiet pressure of a routine approach, both were abandoned.

This is what makes procedural design hard. It is not enough to have the procedure. The procedure has to survive the exact conditions that make people want to skip it.

The Forced Cross-Check Toolkit

The goal of red-teaming is not to slow decisions down indiscriminately. It’s to introduce just enough friction to prevent irreversible errors. What follows are practical mechanisms that create disconfirming evidence on purpose.

Not all of these need to be used all the time. Think of them as tools, not doctrine.

1. The Disconfirming Evidence Check (DEC)

Before committing to a major decision, ask a simple question:

What would have to be true for this to be wrong?

Then assign someone, not the primary advocate, to actively look for that evidence. This is not a rhetorical exercise. The owner’s job is not to agree. It’s to try to falsify the assumption. If they can’t, confidence increases legitimately. If they can, you’ve learned something before it’s expensive. Most teams only collect supporting evidence. DEC forces symmetry.

2. The Two-Runway Test

When two options look similar early, two markets, two architectures, two positioning strategies, require a one-page answer to this question:

How will we know which runway we’re actually on?

That page should include: distinct signals that differentiate the options, how long it should take for those signals to emerge, and a clear decision rule for what happens next. Without this, teams tend to rationalize whatever outcome occurs as “what we expected.”

3. The Time-Boxed Pre-Mortem

Run a pre-mortem, but keep it short. Set a timer for 15–20 minutes and ask:

It’s six months from now and this failed. Why?

Capture the top three reasons. Then convert each into a concrete test or mitigation. If you can’t mitigate a risk, at least acknowledge it explicitly. Pre-mortems work because they temporarily suspend optimism and social pressure. The time box prevents them from becoming unstructured sprawl.

4. Kill Criteria Up Front

Most teams define success criteria. Very few define stopping criteria. Before committing, explicitly state:

• What evidence would cause us to stop?

• What signals would tell us this is not working?

• Who has the authority to call it?

Without kill criteria, projects tend to continue by inertia. Stopping feels like failure rather than discipline.

5. Independent Verification

Separate the advocate from the validator for the most critical assumption. The person who wants something to be true should not be the same person validating whether it is true. This separation doesn’t require a new org structure. It requires role clarity. Aviation learned long ago that self-verification is fragile under pressure.

6. The Assumption Ledger

Maintain a lightweight ledger tracking each assumption, its confidence level, evidence type (data, anecdote, experiment), and next validation date.

This sounds bureaucratic until you try it. The act of writing assumptions down exposes how many are based on belief rather than evidence. It also prevents outdated assumptions from quietly hardening into “facts.”

7. The Slow-Down-at-the-Brink Rule

This is counterintuitive but critical. The closer you are to launch, irreversible commitment, or public positioning, the more explicit your verification should become, not less. This is exactly the moment when teams are most tempted to say, “We’re too far along to question this.” It’s also the moment when mistakes become hardest to unwind. Final approach is when checklists matter most.

Doing This Without Killing Velocity

The immediate objection to all of this is speed. Yes, these practices introduce friction. That’s the point. The question is not whether to have friction, but where to put it. Not every decision deserves heavy red-teaming. Proportionality matters. Reserve the strongest checks for bets that are high-downside, high-ambiguity, and hard to reverse.

For everything else, templates and short rituals beat open-ended debate. A 10-minute DEC is often more effective than an hour-long meeting. A one-page Two-Runway Test beats a dozen slides of narrative justification.

The deeper challenge is cultural. Red-teaming must be framed as service, not defiance. The goal is not to challenge authority, but to strengthen decisions. When leaders model this, by inviting disconfirming evidence and rewarding clarity over agreement, it becomes safe to slow down at the right moments.

Speed doesn’t come from skipping checks. It comes from skipping surprises.

Landing on the Right Runway

The unsettling thing about the Southwest incident is how normal it felt right up until the end. The pilots didn’t feel reckless. They felt confident. That’s what makes it such a powerful metaphor for leadership. The moment something “looks right” is often the moment verification matters most.

Confidence should not trigger commitment. It should trigger constraints.

Red-teaming isn’t about being negative or pessimistic. It’s about acknowledging that humans are very good at convincing themselves they’re right, especially when they’re under pressure and moving fast.

The best leaders don’t rely on smart people to notice mistakes in time. They build systems that assume confidence will arrive before correctness, and they design for that reality.

So here’s the real question:

Where are you most certain right now?And what, exactly, is proving you right, or wrong?

Because landing safely isn’t about believing you’re on the right runway. It’s about checking.

Subscribe now

Share

At the same time, two bicycle mechanics from Dayton, Ohio, the Wright brothers, were running a very different kind of operation. They had no government sponsorship, no institutional prestige, and no expectation that flight was even commercially viable. What they did have was an obsession with outcomes. They weren’t asking, “Can we build a flying machine?” They were asking, “Can we control one?” Every glide, every crash, every failed experiment existed to answer that single question.

Langley’s Aerodrome was launched twice in 1903. Both times it flew briefly and then collapsed into the Potomac River. The public failures ended the program. The outputs were impressive; the outcomes were nonexistent. Nine days later, at Kitty Hawk, the Wright brothers flew successfully. More importantly, they had solved the underlying problem of controlled flight. They didn’t just produce an artifact. They produced understanding.

This distinction, outputs versus outcomes, is where most modern product organizations quietly lose their way.

In technology, we like to believe we are disciplined. We track spend. We forecast ROI. We demand business cases. We talk about accountability. All of that feels responsible, even virtuous. But when those tools are applied too early, to the wrong questions, they don’t create discipline. They create distortion.

Modern product development, such as done with the product operating model, draws a clean line. Outputs vs. outcome. Outputs are what teams produce, such as features. Outcomes are the measurable improvements in customer behavior or experience.

Experiments exist to answer the question: will this solve the customer’s problem?

Financials exist to answer a different question: will the business make money if we do this?

Both questions matter. They just don’t matter at the same time.

One of the most common failure modes I see is treating financial validation as a prerequisite for learning. Teams are asked to justify investment before they’ve had a chance to discover whether the problem is real, whether the solution is viable, or whether the customer even cares. The result is predictable. Experiments get shaped to fit spreadsheets instead of customer reality. Risk is hidden behind false precision. And bold ideas quietly die, not because they’re bad, but because they can’t survive premature accounting.

This isn’t an argument for ignoring costs or abandoning rigor. It’s an argument for sequencing. Financial discipline applied at the wrong moment doesn’t reduce risk; it increases it. It gives leadership the comforting illusion of control while starving teams of the freedom required to learn.

Experiments are not free, but they are not investments either.

That framing is subtle but critical. Investments assume known returns. Experiments exist precisely because returns are unknown. When we demand ROI from discovery work, we are asking teams to pretend certainty exists where it does not. The spreadsheet gets filled in, the narrative gets polished, and everyone involved understands, quietly, that the numbers are fiction.

Good product teams track experiments obsessively, but not for the dollars. They track the learning. They track how quickly assumptions are invalidated. They track whether customer behavior changes, whether friction is reduced, whether the experience actually improves in ways users can articulate and feel. These are outcome signals. They tell you whether you are moving closer to solving a real problem.

Financials, by contrast, are lagging indicators. They tell you what happened after adoption, after scale, after repeat behavior. They are essential for operating a business, but terrible for discovering what that business should become. When financials are allowed to dominate discovery, teams learn the wrong lesson: that safety lies in optimization rather than exploration.

This is how organizations slowly drift into a state of permanent short-termism. Roadmaps fill with “sure things.” Incremental improvements crowd out meaningful bets. Teams get very good at shipping outputs and very bad at producing outcomes that matter. From the outside, everything looks healthy. Inside, innovation quietly atrophies.

Return on investment is particularly dangerous because it feels objective. Numbers look clean. Models look rigorous. But ROI calculations embed assumptions about demand, behavior, and value that are rarely examined. They assume linearity in systems that are anything but. They assume customers behave rationally, consistently, and predictably. Anyone who has spent time actually watching users knows how fragile those assumptions are.

ROI Is a Terrible Product Manager

When ROI becomes the primary lens, it starts acting like a product manager. And it is a terrible one. It favors features over systems, local optimization over global coherence, and short-term wins over long-term leverage. It cannot see second-order effects. It cannot account for trust, habit formation, or emotional resonance. Yet we routinely allow it to veto ideas whose value can’t be neatly expressed in a cell.

Over time, this shapes culture. Teams stop asking what could be possible and start asking what can be defended. Strategy becomes backlog grooming. Discovery becomes theater. The organization confuses activity with progress and output with impact. And because the numbers look good, until they don’t, the warning signs are easy to ignore.

Steve Jobs told his CFO, Joe Graziano, as reported in the book Supporting Steve Jobs by Joe Mandato, “If we make great products, the profits will come.” This quote is easily misunderstood. It is not a rejection of financial reality. It’s a statement about order of operations. Jobs was not anti-business or anti-profit. He was anti-”premature certainty”. Apple cared deeply about money, but it understood that profits are harvested, not engineered directly. They are the byproduct of solving problems so well that customers reward you for it.

Great products create optionality. They open doors you didn’t know existed. Financials tell you how well you’re walking through doors you’ve already chosen. Confusing those roles leads to organizations that are very efficient at extracting value from yesterday’s ideas and very poor at inventing tomorrow’s.

The practical question, then, is not whether to track financials, but when to let them lead. Early in a product’s life, financials should function as guardrails, not goals. They exist to prevent recklessness, not to dictate direction. As confidence grows, as outcomes become repeatable, as customer value becomes clear, financial considerations naturally earn a larger voice. Eventually, optimization is not just appropriate, it’s necessary. The mistake is skipping straight to the end of that journey.

Leadership plays an outsized role here. Protecting outcome-driven discovery from output-driven accounting is not a process problem; it’s a leadership responsibility and a culture. It requires resisting the comfort of false precision and being willing to say, “We don’t know yet, and that’s okay, as long as we’re learning.” It requires trusting teams to pursue truth over theatrics, even when the answers are uncomfortable.

Conclusion

Langley failed not because he lacked intelligence, resources, or ambition. He failed because his system rewarded visible progress over meaningful understanding. The Wright brothers succeeded because they were allowed, and willing, to be wrong repeatedly, cheaply, and intelligently. They optimized for outcomes long before anyone could model the economics of aviation.

Modern product teams face the same choice. You can optimize for outputs, generate impressive artifacts, and produce spreadsheets that inspire confidence. Or you can optimize for outcomes, accept ambiguity, and do the slower, harder work of learning what actually matters to customers.

The future tends to belong to the latter. Not because they ignore financial reality, but because they understand that great businesses are discovered before they are optimized.

Subscribe now

Share

Around 2:15 p.m. on a hot August afternoon, the grid was already failing, but the people responsible for saving it had no idea their alarms had gone dark.

What Happened

On August 14, 2003, a high-voltage transmission line in northern Ohio sagged into overgrown trees and tripped offline. By itself, this was a routine fault, the kind that happens regularly on large power grids and is normally contained without customers ever noticing. But inside FirstEnergy’s control room, something far more dangerous was unfolding.

A software problem in FirstEnergy’s Energy Management System caused the alarm function to stop updating. Operators did not receive audible or visual alerts as additional lines overloaded and tripped. Worse, the system provided no clear indication that the alarm processor itself had failed. From the operators’ perspective, things looked quiet, deceptively quiet.

As additional transmission lines went out of service, power flows rerouted automatically onto remaining lines. Those lines overheated, sagged further into trees, and tripped in turn. Protective relays did exactly what they were designed to do: remove stressed equipment to prevent physical damage. But each correct local action pushed the broader system closer to collapse.

For over an hour, the grid drifted into an increasingly unstable state while the humans responsible for intervening lacked accurate, real-time situational awareness. By the time the failure cascaded beyond Ohio, it was too late to contain. Power outages rippled across the interconnected system, ultimately cutting electricity to roughly 55 million people across the U.S. Northeast and parts of Canada.

Post-incident investigations emphasized a sobering truth: the initiating events were not exotic. There was no cyberattack, no unprecedented weather, no single dramatic failure. The catastrophe emerged from a chain of ordinary weaknesses, inadequate vegetation management, insufficient real-time visibility, and organizations that had never fully reckoned with what “loss of alarms” actually meant.

The U.S.–Canada Power System Outage Task Force’s final report documents this sequence in detail, including the failure of the alarm processor and the resulting loss of operator awareness.

The Alarm Failure No One Was Watching For

It is tempting to describe the 2003 blackout as a physical infrastructure problem. Trees did contact power lines. Transmission corridors were inadequately maintained. But those conditions existed long before August 14. What made that day different was that the grid’s nervous system went numb.

FirstEnergy’s Energy Management System relied on a software component responsible for detecting abnormal conditions and notifying operators through alarms. That component failed silently. Operators were not alerted when it stopped working, nor were they trained to recognize the subtle signs that their alarm system was no longer trustworthy.

Scientific American’s account of the blackout describes how the alarm system failed on that first line trip, and how over the following hour and a half, operators tried to understand what was happening as three more lines sagged into trees and switched off one by one. The system did not announce its own collapse. It degraded quietly, each failure invisible to the people responsible for stopping it. Quiet failures are the most dangerous kind.

Why This Was Not a Knowledge Problem

One of the most important conclusions of the task force was that this was not a failure of competence. Grid operators knew how to run a power system. Engineers understood load flows and contingencies. The rules for preventing cascading failures were well documented.

What failed was the assumption that the instrumentation, the alarms, displays, and indicators, would always be there to tell operators when they were in trouble. The system was designed to handle equipment failures. It was not designed to handle awareness failures.

When alarms stopped updating, there was no explicit “this system is lying to you” signal. No prominent health indicator. No practiced drill for “our alarms are dead.” The absence of alarms was interpreted as the absence of problems, exactly the wrong inference.

Wikipedia’s overview of the event highlights this point succinctly, noting that the alarm processor failure went unnoticed for over an hour while conditions deteriorated. This distinction matters deeply, because it reframes the incident from “operators missed something” to “the system failed to degrade safely.”

Red-Teaming the Wrong Thing

Organizations are generally comfortable red-teaming their plans. They stress-test strategies, forecast demand, model failure scenarios, and ask what happens if a particular component breaks. What they do far less often is red-team the instrumentation they rely on to know whether those plans are working.

The 2003 blackout is red-teaming in the most literal sense. The grid did not fail because no one knew how to operate it. It failed because the operators’ information system failed, and no one had rehearsed that possibility. This is a lesson that translates cleanly to product management and leadership.

Dashboards, alerts, KPIs, uptime monitors, customer feedback loops, these are the alarm systems of modern organizations. Leaders make decisions based on the assumption that when something is wrong, they will know. Product teams assume that regressions will surface through metrics. Executives assume that if a chart is green, things are fine. But what if the chart is wrong?

What if the alerting pipeline is broken, the data is stale, the metrics are lagging, or the signal is drowned in noise? Do teams notice quickly? Or do they, like the grid operators in 2003, interpret silence as safety?

The Northeast blackout demonstrates that losing observability is not just another failure mode. It is a meta-failure, one that disables your ability to respond to every other failure.

When Metrics Become the Alarm System

In modern product organizations, dashboards are the control room. We rely on metrics to tell us whether users are happy, whether systems are healthy, whether teams are performing, and whether strategy is working. Conversion rates, latency percentiles, churn, engagement, NPS, velocity, uptime, these numbers become proxies for reality. When they move, we react. When they’re flat, we assume stability. This is where the 2003 blackout becomes uncomfortably familiar.

The grid operators that afternoon were not ignoring data. They were looking at it constantly. The problem was that their alarm system, the very mechanism designed to surface danger, had failed silently. The absence of alerts was interpreted as the absence of problems. Silence became reassurance. Product teams fall into the same trap.

If dashboards aren’t flashing red, leaders assume things are under control. If metrics are green, they infer health. But metrics are not reality, they are an instrumentation layer, and like any instrumentation, they can be incomplete, misleading, delayed, or broken. This is where the old management adage begins to crack.

The phrase “If you can't measure it, you can't manage it” is often attributed to Peter Drucker, but according to the Drucker Institute, he never said it. It is also frequently misattributed to W. Edwards Deming, though Deming actually wrote the opposite: “It is wrong to suppose that if you can't measure it, you can't manage it, a costly myth.” The truncated version, stripped of its context, inverts Deming's actual point entirely.

Another quote often misattributed to Drucker is “What gets measured gets managed.” Drucker never said it either. The idea actually originates with V.F. Ridgway's 1956 paper Dysfunctional Consequences of Performance Measurements, in which Ridgway warned against the indiscriminate use of quantitative measures. Journalist Simon Caulkin later captured the spirit of Ridgway's argument in a phrase that has stuck: “What gets measured gets managed, even when it's pointless to measure and manage it, and even if it harms the purpose of the organization to do so.” In other words, measurement is powerful, and dangerous.

When product leaders equate what they can see with all that matters, blind spots become inevitable. Teams optimize for metrics that are visible while quietly accumulating risk in areas that are harder to quantify: team burnout, customer frustration that hasn’t yet surfaced as churn, growing operational fragility, cultural erosion, or decision latency caused by process overhead.

Just as critically, teams rarely ask a harder question: How would we know if our metrics stopped telling the truth?

Blind Spots, Silent Failures, and the Illusion of Control

The most sobering lesson from the Northeast blackout is not that alarms failed, it’s that no one was prepared for what that meant. The grid was designed to handle line failures. It was not designed to handle awareness failures. There was no practiced response for “our view of the system is wrong.” By the time operators realized they were blind, the cascade was already irreversible. In product organizations, blind spots emerge in similar ways.

Instrumentation often reflects what is easy to measure rather than what is important. Teams measure feature usage but not user confusion. They track velocity but not rework. They monitor uptime but not the operational load on engineers maintaining it. They survey engagement annually and call it culture. These gaps don’t announce themselves. They compound quietly.

Even more dangerous is when teams don’t notice that their instrumentation has degraded. Metrics become stale. Alerts are tuned out due to noise. Dashboards remain green because thresholds were never updated as the system evolved. Leaders believe they are informed, when in reality they are flying on partial instruments. This is the modern equivalent of the silent alarm.

Product leadership, like grid operation, is not just about making good decisions. It is about knowing when your ability to make good decisions has been compromised. That requires explicitly red-teaming not just your strategy, but your sensing mechanisms.

If user behavior changes in ways you’re not measuring, would you know?

If team morale deteriorates gradually, where would that show up?

If productivity looks stable but innovation slows, which metric would catch it?

If your dashboards went dark tomorrow, or worse, confidently wrong, how long would it take you to notice?

These questions are uncomfortable, which is precisely why they matter.

The blackout did not happen because people were careless. It happened because the system created a false sense of control. Modern product organizations face the same risk when metrics become substitutes for judgment rather than inputs to it.

The lesson is not to abandon measurement. It is to treat measurement as a fallible system, one that needs redundancy, skepticism, and regular challenge. Metrics should provoke questions, not end them. Silence should raise suspicion, not confidence.

Because when the alarm goes silent, the failure is already underway, and the longer you trust what you can see, the harder it becomes to recover from what you can’t.

Subscribe now

Share

The cause was not an engine malfunction or a structural flaw. It was software, specifically, software reused from the Ariane 4 rocket without sufficiently re-examining the assumptions embedded within it. A piece of alignment code, useful before liftoff on Ariane 4 but unnecessary after launch on Ariane 5, continued running during ascent. Ariane 5’s much higher horizontal velocity pushed a value beyond the range of a 16-bit signed integer, triggering an overflow and an unhandled exception.

Both redundant inertial reference units shut down almost simultaneously. The onboard flight computer then received a diagnostic bit pattern, misinterpreted it as valid guidance data, and commanded extreme steering corrections. Within seconds, the rocket was unrecoverable.

The postmortem reads less like a math error and more like an organizational failure: unchallenged assumptions, incomplete safeguards, and a system where a “safe” failure mode became catastrophically unsafe.

The Launch That Never Made It

At 12:34 UTC on June 4, 1996, Ariane 5 Flight 501 rose from its launch pad with enormous expectations riding on it. Ariane 5 was Europe’s next-generation heavy-lift launcher, designed to carry larger payloads and enable more ambitious missions than its predecessor. The Cluster satellites onboard represented years of scientific planning and international collaboration.

For the first half minute, everything looked normal. Telemetry streams showed nominal values. Then, without warning, the rocket began to pitch violently. Data diverged sharply from expectations. Within moments, aerodynamic forces exceeded design limits, structural failure began, and the automatic flight termination system detonated the vehicle to protect people on the ground.

From the outside, it looked like a classic rocket explosion. From the inside, the system was behaving exactly as designed.

A detailed overview of the failure sequence is available in the Wikipedia summary of Ariane 5 Flight 501, which draws from the official inquiry report and flight data.

What Actually Failed

The failure originated in the inertial reference system, or IRS, the subsystem responsible for determining the rocket’s position, velocity, and orientation. Ariane 5 carried two identical IRS units for redundancy, both running the same software.

That software had been inherited almost wholesale from Ariane 4.

On the surface, this seemed sensible. Ariane 4 had an excellent flight record. Its inertial system software had been proven across dozens of successful launches. Reuse promised reliability, reduced cost, and faster development. What it also carried forward, quietly and invisibly, were assumptions about the world in which that software would run.

Ariane 5 was not Ariane 4. Its trajectory was steeper. Its horizontal acceleration early in flight was significantly higher. Those differences mattered in ways no one fully revisited.

One portion of the inherited code was responsible for sensor alignment. On Ariane 4, this alignment routine continued running briefly after liftoff and provided useful calibration data. On Ariane 5, the routine served no operational purpose after launch. But it was left enabled anyway, largely because it had never caused problems before.

That alignment routine calculated a value related to horizontal velocity bias. In Ariane 4 flights, this value always remained within a narrow, safe range. In Ariane 5’s more aggressive ascent, it did not.

The software attempted to convert this value from a 64-bit floating-point number into a 16-bit signed integer. When the value exceeded the integer’s maximum representable range, the conversion overflowed. Unlike several other conversions in the same system, this one was not protected by exception handling. Engineers had reasoned that protection was unnecessary because the value could never get that large.

That reasoning was correct, until it wasn’t.

When the overflow occurred, the IRS shut itself down, exactly as designed. The backup IRS, running the same code and experiencing the same conditions, failed almost immediately afterward. The flight computer suddenly found itself without valid inertial data.

Instead of recognizing the failure and rejecting the data stream, the flight computer interpreted a diagnostic bit pattern as real attitude information. Acting on that false input, it commanded extreme nozzle deflections. The rocket responded faithfully, violently, and fatally.

The Organizational Lesson: When Reuse Becomes a One-Way Door

It is tempting to describe Ariane 5 Flight 501 as a software bug. That framing misses the deeper lesson.

The true failure was not technical competence but decision framing.

Reusing Ariane 4 software was treated as a low-risk, reversible choice. If something went wrong, engineers assumed it could be fixed later. That mindset makes sense in most software environments. It makes sense in simulations. It even makes sense in many production systems.

But a rocket launch is not a two-way door.

Once the vehicle leaves the pad, the first execution of the software is the final execution. There is no rollback, no patch, no hotfix window. Every assumption baked into the system becomes irrevocable reality.

This is where the story becomes uncomfortably familiar to modern organizations.

When teams inherit systems, roadmaps, architectures, or partially completed projects from others, they often inherit assumptions along with them. Those assumptions are rarely written down. They are encoded in design decisions, default thresholds, “temporary” shortcuts, and unchallenged constraints.

Product managers who step into a project mid-stream are especially vulnerable to this trap. The pressure is to deliver, not to rewind. It feels inefficient, or even disrespectful, to question decisions that have already been made. “This shipped before” becomes shorthand for “this is safe.”

Ariane 5 shows how dangerous that reasoning can be.

The Ariane 4 engineers were not careless. Their assumptions were reasonable in their original context. What failed was the absence of a deliberate pause to ask whether those assumptions still held when the environment changed.

Validating Assumptions in Inherited Systems

One of the most striking details in the Ariane 5 failure is that some numeric conversions were protected against overflow while others were not. This wasn’t random. Protection was added only where engineers believed values might plausibly exceed bounds.

That belief was rooted entirely in historical behavior.

This pattern appears constantly in organizations. Some risks are carefully mitigated because they have been seen before. Others are waved away because “that’s never happened.” The difference between the two is rarely analytical rigor. It is institutional memory.

For teams that take over projects mid-flight, this creates a subtle but critical responsibility. Their job is not merely to execute the existing plan, but to revalidate the assumptions embedded within it. That includes assumptions about scale, performance envelopes, user behavior, operational environments, and failure modes.

Revalidation is not an indictment of the prior team. It is an acknowledgment that context changes faster than systems do.

The Ariane 5 software behaved exactly as designed. The failure occurred at the boundary between systems, where a diagnostic became input, where a safe shutdown became an unsafe signal. These boundary conditions are precisely where inherited assumptions do the most damage.

The Spaceflight Now reconstruction of the failure, based on ESA materials, highlights how rapidly this boundary failure unfolded.

In product and platform teams, similar boundary failures occur when monitoring data drives automated actions, when fallback states become primary states under load, or when error handling paths are rarely exercised until they suddenly dominate system behavior.

Successor teams who do not revisit these edges are often blindsided, not because they made poor decisions, but because they trusted inherited ones too deeply.

Why This Story Still Matters

Ariane 5 Flight 501 destroyed hundreds of millions of dollars in hardware and delayed an important scientific mission by years. But its enduring legacy is educational.

It reminds us that reuse is not free. It carries history with it. Assumptions that were once invisible become liabilities when context shifts. The more “proven” something feels, the less likely it is to be questioned, and the more dangerous it becomes when the world changes underneath it.

Whether you are launching a rocket, shipping a platform rewrite, or taking ownership of a project you didn’t start, the lesson is the same:

You don’t just test what’s new.

You interrogate what you inherited.

Subscribe now

Share

Blumberg asked whether these twitches, a special form of self-generated movement, could help robots learn their own mechanics before being asked to do anything meaningful. The question itself was more interesting than the answer, because it challenged the assumption that learning follows performance. Instead, it suggested that learning might need to precede it.

What struck me wasn’t the neuroscience or the robotics. It was how familiar the problem felt in a business context. Most organizations do the exact opposite of what those sleeping rats are doing. We ask them to sprint before they know where their joints are.

We reorganize, launch, migrate, scale, and commit, then act surprised when things break in ways no one anticipated. We demand certainty up front and learning afterward, as if understanding were something that naturally emerges once enough pressure is applied. Blumberg’s rats suggest a different order of operations, one that feels almost subversive in a corporate setting: learn first, perform later.

What Twitching Really Is

The word “twitching” sounds accidental, even sloppy, but in Blumberg’s work it is neither. Twitching has a few defining characteristics that matter far more than the movement itself. It is low-stakes, frequent, self-initiated, and deeply information-rich in ways that intentional performance rarely is.

A twitch does not try to achieve an outcome. It exists to generate feedback about the system itself. Performance-driven movement optimizes for results, while learning-driven movement optimizes for understanding, and those two goals often pull in opposite directions.

Most businesses are deeply uncomfortable with activity that is not obviously productive. We prefer plans, milestones, roadmaps, and metrics that point in a straight line toward a declared goal. Twitching doesn’t look like progress in that sense. It looks like motion without ambition, which is precisely why it works.

In organizational terms, twitching is not chaos or lack of discipline. It is disciplined, bounded exploration designed to teach the system about itself before the system is put under load. It is motion with intent, even if that intent is learning rather than winning.

Learning Faster Than Your Competitors

Every company talks about learning, but far fewer design for it in any serious way. Learning is often treated as a byproduct of execution rather than a first-class objective. In practice, many organizations learn only after commitment has already been made.

They learn after the launch, after the reorg, after the acquisition, or after the migration. Learning becomes a postmortem activity, something conducted when the cost of being wrong is already locked in and the options for correction are limited. At that point, insight is expensive and humility is painful.

That approach is equivalent to discovering how your knees work halfway through a marathon. You may learn something important, but the timing guarantees unnecessary damage. Twitching flips this sequence by allowing organizations to observe consequences before committing fully.

Instead of betting everything at once, teams run small pilots, create parallel paths, and test assumptions in constrained environments. They let parts of the organization probe ideas without the burden of success attached. What emerges is not just data, but understanding.

The competitive advantage here is not speed alone. It is learning velocity, the rate at which an organization updates its mental model of reality. Twitching increases that rate without increasing existential risk, which is a rare and valuable combination.

Product Development: Twitch Before You Ship

Nowhere is this pattern clearer than in product development. Strong product teams rarely start with scale, even when they talk as if they do. What they actually start with is signal, because signal tells them where reality diverges from expectation.

They want to know where users stumble, where workflows bend, and where incentives quietly distort behavior. Twitching shows up here as prototypes, feature flags, fake doors, concierge MVPs, and intentionally manual processes that feel almost regressive on the surface.

What these approaches have in common is not thrift or speed. They are expressions of humility. They assume the team’s understanding is incomplete and that the product is not a solution yet, but a question posed to the world.

Each small release becomes a twitch, an opportunity to feel resistance and discover constraints before those constraints are locked into architecture. Teams that skip this phase often mistake momentum for progress. The dashboard looks great right up until reality asserts itself, at which point the system is too heavy to change gracefully.

Twitching keeps products light long enough to learn what they actually are.

Organizational Design: Feeling the Body of the Company

Reorganizations fail for the same reason big launches fail: leaders assume they understand the system they are changing. They draw boxes, redefine roles, and announce clarity, expecting behavior to follow structure. What they discover instead is that communication paths, informal power, and trust networks ignore org charts entirely.

The company moves, but not in the way anyone expected. Decisions slow down, accountability blurs, and the intended benefits of the change never quite materialize. At that point, leaders often double down, mistaking resistance for stubbornness rather than information.

Organizational twitching offers a different approach. Instead of wholesale change, it relies on temporary structures, trial operating models, time-boxed experiments, and limited-scope governance shifts. These moves are not meant to last; they are meant to teach.

When leaders allow the organization to twitch, they gain insight into where friction actually lives, where authority truly sits, and which assumptions about behavior collapse under real conditions. The organization reveals its body map, and leaders make better decisions because of it.

Strategy as Safe Motion, Not Declarations

Strategy is where twitching feels most counterintuitive. We tend to think of strategy as a declaration, a bet that signals confidence to the market and alignment internally. In many organizations, ambiguity is treated as weakness and exploration as indecision.

Confidence without understanding, however, is bravado rather than leadership. Strategic twitching treats strategy as a hypothesis instead of a proclamation. It allows exploration at the edges without forcing premature coherence across the entire organization.

This approach encourages small parallel bets rather than singular, monolithic ones. It creates space for internal contradiction long enough for signal to emerge, even if that signal challenges the original narrative. Many successful pivots did not begin as bold moves; they began as side projects, internal tools, or experiments no one was quite sure about.

The leaders who recognized their value were not necessarily more visionary than their peers. They were simply better listeners, paying attention to the twitches instead of dismissing them as noise.

Leadership and the Discipline of Not Knowing

At its core, twitching is a leadership posture. It requires admitting uncertainty and resisting the urge to appear decisive before the system has taught you what decisiveness should look like. It favors questions over pronouncements and probes over mandates.

This stance is uncomfortable, especially for senior leaders conditioned to equate authority with answers. Yet the paradox is that leaders who allow twitching often earn more trust, not less. They signal respect for complexity and confidence in learning, which tends to resonate more deeply than forced certainty.

They also avoid the trap of overcorrection. When organizations do not twitch, they swing. Big decisions are followed by big reversals, and learning happens in painful spikes rather than steady accumulation. Twitching smooths that curve and makes adaptation less traumatic.

The Lesson Sleeping Rats Are Teaching Us

Blumberg’s sleeping rats are not trying to optimize anything. They are not chasing outcomes or maximizing efficiency. They are doing something far more foundational by learning who they are and how they work.

The best organizations behave the same way. They move before they commit, test before they scale, and listen before they declare. They treat motion as a source of knowledge, not just progress, and they build systems that can absorb what they learn.

The alternative is familiar and costly. Big launches lead to big reorganizations, which lead to big regrets. We mistake certainty for competence and decisiveness for wisdom, only to discover that complex systems do not respond to confidence. They respond to curiosity.

Twitching is not inefficiency or hesitation. It is foresight. It is how smart systems avoid catastrophic learning later by investing in gentle learning early. As you look at your next roadmap, reorg, or strategic bet, it is worth asking what small, safe movement could teach you who you really are before you ask the system to perform.

That question does not slow progress. It changes its direction in ways that matter.

Subscribe now

Share

I wrote previously about the shape of leadership, drawing inspiration from birds in flight. What struck me was not that there is a single “right” formation, but that different birds organize themselves differently depending on conditions. Geese fly in tight V-formations to conserve energy over long distances, rotating the lead position as individuals tire. Starlings, by contrast, form murmurations, fluid, shifting clouds that respond instantly to predators and wind, prioritizing adaptability over efficiency. In both cases, there is no permanent leader pulling the group forward. Leadership emerges, recedes, and reshapes itself based on context. That piece resonated with many of you because it reframed leadership not as a role or a hierarchy, but as a living system tuned to its environment.

This essay builds on that same idea, but shifts the lens slightly. It’s about decision-making under uncertainty, and specifically the tension every product leader feels between exploiting what already works and exploring what might work next.

If that tension feels familiar, it should. It shows up every time you look at a roadmap and ask whether to double down on incremental improvements or carve out space for something riskier. It shows up when you decide how many teams should focus on reliability and optimization versus discovery and experimentation. And it shows up when success itself becomes the thing that makes future success harder.

Nature has not only struggled with this problem. In many cases, it has a solution.

Consider the honey bee.

A hive survives by finding food efficiently, but the world it lives in is not static. Flowers bloom and die. Fields dry up. New opportunities appear without warning. If bees only exploited the best-known food source, they would thrive briefly and then starve. If they only explored endlessly, they would waste energy and accomplish nothing. Their survival depends on doing both, at the same time.

Bees solve this with one of the most elegant communication systems in nature: the waggle dance. When a forager finds a promising food source, it returns to the hive and performs a dance that encodes both direction and distance. The intensity of the dance reflects the quality of the find. Other bees watch and decide whether to follow.

What’s easy to miss is what doesn’t stop happening. Even when a rich source is discovered and heavily exploited, some bees keep exploring. No announcement is made that exploration is “done.” No quarterly planning meeting reallocates 100% of capacity to the current best option. The hive maintains a persistent minority of scouts, continuously sampling the unknown.

This is not inefficiency. It is insurance.

For product leaders, this maps uncomfortably well to the way teams behave under pressure. When metrics are strong and customers are happy, exploration often feels like a luxury. When things are going poorly, it feels irresponsible. In both cases, the instinct is to exploit harder, to optimize the known, to squeeze more value out of the current system. Bees would recognize this instinct immediately. They would also recognize the danger.

The hive does not survive by being right once. It survives by continuing to learn.

If bees give us the intuition, mathematics gives us the language.

The multi-armed bandit problem is a classic formulation in decision theory. Imagine a row of slot machines, each with an unknown payout rate. You can pull any arm you like, but every pull costs you something. Pulling an arm gives you information, but also commits you to the outcome. Over time, you want to maximize total reward.

The dilemma is you cannot know which arm is best without pulling them, but every pull of a bad arm feels like waste. Pull the same arm repeatedly and you exploit what you know. Try new arms and you explore what you don’t. Too much exploitation too early locks you into a suboptimal choice. Too much exploration too late leaves value on the table.

What makes this problem powerful for product leaders is that it captures something uncomfortable: learning is expensive by definition. The cost is not just time or money, but opportunity. Every team assigned to explore is a team not working on something proven. Every sprint spent exploring is a sprint not spent optimizing.

Yet the math is unforgiving. Strategies that minimize short-term regret perform worse over time. The optimal approach deliberately accepts local inefficiency in service of global performance. In other words, exploration feels wrong precisely when it is most necessary.

This is where many product organizations quietly fail. They understand the theory. They nod at the metaphors. But their structures, incentives, and team designs push relentlessly toward exploitation. Roadmaps fill with features that improve known metrics. Teams are rewarded for predictability and punished for variance. Experiments are tolerated as long as they are small, fast, and disposable.

The result is what I’ve written about before in the context of short-term versus long-term bets. The portfolio drifts. Not because anyone decided to abandon the future, but because the system made that outcome inevitable.

Team topology plays a significant role in this drift.

How you organize teams largely determines whether exploration can exist. A single team asked to both exploit and explore will almost always choose exploitation, especially under delivery pressure. The urgent crowds out the important. Bugs, escalations, and roadmap commitments have a way of consuming any slack that was theoretically reserved for exploration.

On the other extreme, carving out a separate “innovation” team can create the illusion of exploration without its substance. These teams often lack ownership of outcomes, access to real customers, or a path for their work to influence the core product. They explore in isolation, generating ideas that struggle to find a home.

The most effective organizations I’ve seen treat exploration and exploitation as different modes with different needs, but not different levels of importance. Teams oriented toward exploitation are designed for stability, throughput, and reliability. Their success comes from deep context, tight feedback loops, and continuous improvement. Teams oriented toward exploration are designed for learning speed. Their success comes from exposure to uncertainty, permission to be wrong, and time to run multiple pulls of the lever.

Crucially, there is an intentional path between the two. Exploratory work that shows promise does not remain experimental forever. Like a strong waggle dance, it attracts more attention. Resources follow signals, not hope. Over time, bets graduate from explore to exploit, from fragile to durable.

This transition is where leadership matters most. Without active stewardship, exploration becomes theater and exploitation becomes stagnation. The portfolio needs constant rebalancing, not because leaders lack conviction, but because the environment keeps changing.

One of the most subtle failure modes occurs when organizations believe they are exploring, but are really just re-labeling exploitation. Incremental improvements masquerade as innovation. Small optimizations are sold as big bets. The language of exploration is adopted without its risk. This is comforting, but it is not adaptive.

Real exploration produces discomfort. The metrics are noisy. The outcomes are uncertain. The timelines are unclear. These are not bugs in the process; they are signals that learning is happening.

Nature understands this. Bees do not demand certainty from scouts before listening. They amplify based on evidence. They accept that some foragers will return empty-handed. The cost of those failures is built into the system.

Product organizations that last do the same.

They do not ask every team to be everything at once. They design for different kinds of work, and they protect each mode from being overwhelmed by the other. They acknowledge that exploitation pays the bills, but exploration pays the future.

Perhaps the most important shift is psychological. Leaders must stop treating exploration as a phase that ends. There is no point at which the environment becomes stable enough to stop learning. Markets move. Technologies evolve. Customer expectations shift. The moment you believe you have arrived is usually the moment decline begins.

This is why the exploit versus explore tension never resolves. It is not a problem to be solved, but a dynamic to be managed. Like leadership in a flock, or foraging in a hive, it requires constant adjustment rather than a fixed answer.

If there is a single takeaway I hope you sit with, it is this: your roadmap is not a plan, it is a portfolio. And portfolios require diversification, patience, and a tolerance for uncertainty.

Bees don’t optimize themselves into extinction. Wise gamblers don’t expect every lever to pay out. And resilient product organizations don’t confuse short-term efficiency with long-term survival.

The question is not whether you should exploit or explore. The question is whether your system allows you to do both, honestly, continuously, and without apology.

Subscribe now

Share

The document was later titled Meditation on the Divine Will. His secretary, John Hay, said it was “not written to be seen of men,” but rather an attempt by Lincoln to wrestle privately with responsibility, doubt, and forces far beyond his control. Hay described it as Lincoln admitting us “into the most secret recesses of his soul.” What Lincoln wrote is striking, not for its certainty, but for its humility.

He acknowledges that both sides of the war claim moral righteousness. He admits that one, or both, could be wrong. He even entertains the possibility that the purpose of the war itself may be different from what any human leader intends. This is not the writing of a man convinced he has everything figured out. It’s the writing of someone painfully aware of the limits of his own understanding. This is not how we usually picture great leadership.

We tend to imagine leaders as confident, decisive, and unwavering. We rarely imagine them alone, questioning their assumptions, doubting their interpretations, or wrestling with the possibility that their best efforts might still fall short of some larger purpose. Yet Lincoln did exactly that, and he did it deliberately. This is where imposter syndrome quietly enters the leadership conversation.

Many leaders interpret self-doubt as evidence they’re failing. They assume that if they were truly good at this job, they wouldn’t feel so uncertain, so conflicted, or so aware of their blind spots. But Lincoln’s example suggests something different: deep introspection is not a leadership flaw, it’s a leadership discipline.

Lincoln didn’t let doubt paralyze him. He didn’t outsource his thinking to slogans or certainty theater. Instead, he created space to reflect before acting. He processed uncertainty privately so he could lead decisively in public. His self-questioning didn’t weaken his leadership; it tempered it. There’s a practical lesson here for modern leaders.

If you feel like you don’t have all the answers, that doesn’t mean you’re a bad leader. It may mean you’re confronting real complexity instead of oversimplifying it. If you feel the weight of responsibility deeply, that’s not imposter syndrome to be eliminated, it’s a signal to build better reflection and feedback loops around yourself.

Lincoln didn’t ask, “Am I confident enough?”
He asked, “Am I being honest with myself?”

That’s a far more useful leadership question. Good leaders don’t silence doubt; they manage it. They don’t confuse certainty with competence. And they don’t mistake introspection for weakness. They use it to sharpen judgment, expand empathy, and avoid the far more dangerous trap of believing they are unquestionably right.

In that sense, feeling unsure may not be a sign that you’re failing as a leader. It may be a sign that you’re taking the role seriously enough to do the hardest work first, the work inside your own head.

That kind of introspection raises a harder question for the rest of us:
How do you actually know if you’re a good leader?

For most of the year, leadership evaluation is something we do to other people. We rate performance. We fill out scorecards. We calibrate. And then, almost as an afterthought, we move on.

This time of year, annual review season, creates a strange asymmetry. Leaders spend weeks assessing others while rarely applying the same rigor to themselves. Yet leadership is one of the few roles where your effectiveness is almost entirely experienced indirectly, through other people.

Which makes self-evaluation both essential and deeply uncomfortable.

Leadership Is Measured From Multiple Angles

One of the biggest mistakes leaders make when evaluating themselves is relying on a single perspective. Leadership doesn’t have a single audience, and it doesn’t have a single scorecard.

There are at least three distinct ways you are being measured, whether you acknowledge them or not.

First, there’s how your boss experiences you. This is managing up. Do you create clarity or noise? Do you surface problems early or hide them until they explode? Are you a source of leverage or a source of surprise?

Second, there’s how your peers experience you. This is managing sideways. Are you someone others trust in moments of ambiguity? Do you collaborate when it’s inconvenient? Do people feel relief or friction when they see your name on a meeting invite?

Third, and most importantly, there’s how your team experiences you. This is managing down. Do people feel safe telling you the truth? Do they understand what “good” looks like? Do they leave interactions with you clearer and more confident, or more confused and guarded?

None of these perspectives alone tells the full story. But together, they form a far more accurate picture of your leadership than your own internal narrative ever will.

Leadership Is About People, Not Perfection

This is where many leaders get stuck. Leadership is a people system, and people are not clean, predictable, or consistent. You can do ten things right and be remembered for the one moment you handled poorly. You can have good intentions and still cause harm. You can grow and still carry old perceptions longer than feels fair. Perfection is not the bar. It never was.

Good leadership isn’t about eliminating flaws. It’s about recognizing them early, taking responsibility for them, and working on them deliberately. The leaders who do the most damage are rarely the ones with shortcomings. They’re the ones who refuse to acknowledge them.

Lincoln didn’t pretend to have certainty he didn’t possess. He confronted his limitations directly. That’s not weakness. That’s maturity.

Practical Advice: How to Evaluate Yourself Honestly

If leadership is experienced from multiple angles and shaped by imperfect humans, then self-evaluation requires more than introspection alone. Do a 360 review, even if no one requires it.

Ask for feedback from your manager, your peers, and your team. Not as a formality, but as a genuine inquiry. Look for patterns, not individual comments. One piece of feedback might be noise. Five similar observations are a signal. And when the feedback comes, there are only two possibilities. Either the feedback is correct, or it isn’t.

If it’s correct, the path is straightforward, if not easy. You acknowledge it. You make a plan. You work on it. You don’t explain it away or soften it with context that arrives too late to matter.

If you don’t think the feedback is correct, the responsibility still doesn’t disappear. Because now you own the perception. Perceptions don’t come from nowhere. Something you did, or failed to do, created it. Arguing about intent doesn’t change impact. Once a perception exists, leadership requires you to address it, not debate it.

This is one of the hardest truths of leadership: once feedback is given, ownership transfers to you.

The Real Test of Leadership

Being a good leader isn’t about being universally liked. It isn’t about having unshakable confidence or perfectly polished answers. And it certainly isn’t about never feeling doubt.

The real test of leadership is whether you are willing to look at yourself with the same honesty you expect from others.

Annual review season shouldn’t just be about scoring people. It should be a reminder to pause, reflect, and ask uncomfortable questions about how you show up in the lives and work of others.

Lincoln’s private meditation wasn’t written to inspire anyone. It was written to steady himself. And yet, it reveals something timeless about leadership: the strongest leaders are not the ones most convinced of their own righteousness, but the ones most committed to self-examination. If you’re wondering whether you’re a good leader, that question alone doesn’t disqualify you. What matters is what you do next.

Subscribe now

Share

In his early essay The Coolhunt, Gladwell describes the people whose job wasn’t to create culture but to notice it first. These were the coolhunters, observers embedded in subcultures, clubs, sidewalks, and scenes, whose value came from pattern recognition rather than originality. They didn’t invent trends. They detected them, named them, and helped them travel.

What made the essay compelling wasn’t fashion. It was the underlying mechanism. Culture didn’t move randomly. It moved because certain people had unusually good judgment about what would spread, what would stick, and what would fade. They were early curators of taste, long before the word “curation” became common outside of the arts.

Fast forward a few decades, and that role hasn’t disappeared. It has exploded.

Today we see the same function playing out at internet scale through what we might call cultural curators. These are the accounts, playlists, channels, and feeds that don’t primarily create new material, but instead select and frame what already exists. Some of the most influential entertainment accounts online are famous not for originality, but for selection. FuckJerry, for example, built a massive audience largely by choosing which jokes, images, and moments deserved attention at a given time.

It’s easy to dismiss this kind of work as derivative. But doing so misses the structural role it plays. Cultural curators don’t add value by making more content. They add value by reducing uncertainty. In a sea of options, they answer a simple but critical question: what should I pay attention to right now?

Abundance Is the Problem, Not the Solution

The need for cultural curators exists because we now produce information at a rate that overwhelms human cognition. Every minute, hundreds of hours of video are uploaded, millions of messages are sent, and more data is created than any individual, or organization, can reasonably process. On a daily basis, we generate data in quantities so large they’ve become abstract.

We tend to respond to this abundance by celebrating it. More voices. More content. More access. And those are real gains. But abundance without structure doesn’t lead to understanding. It leads to noise.

Raw information does not scale on its own. Meaning does not automatically emerge from volume. Without some form of filtering, prioritization, and framing, people don’t become better informed, they become exhausted.

Curation is the mechanism that makes abundance usable.

This is often where the conversation turns to algorithms. Recommendation engines, feeds, rankings, dashboards. These tools are powerful, and they do real work. But they optimize for what is measurable, not what is meaningful. They surface what has performed well before, not necessarily what matters now or what will matter next.

Cultural curators fill that gap. They apply context. They make judgment calls. They take reputational risk. They decide what not to pass along. In doing so, they restore a sense of coherence to an otherwise overwhelming system.

YouTube and the Myth of Pure Creation

One of the clearest historical examples of this dynamic comes from the early days of YouTube.

We often tell YouTube’s origin story as if it were simply about cheap video hosting and user-generated content. But that framing overlooks a critical ingredient. In YouTube: Online Video and Participatory Culture, Jean Burgess and Joshua Green argue that YouTube was not built by uploaders alone. It was co-created by a mix of corporate users, professionals, everyday amateurs, organizations, and, most importantly, the audiences who engaged around that content.

Those audiences didn’t just watch. They commented, responded, embedded, shared, grouped, and remixed. They curated.

Early YouTube worked not because most videos were good, they weren’t, but because humans constantly filtered the chaos. Before algorithms became sophisticated, people decided what traveled and what disappeared. They turned a raw archive of uploads into something that felt like a living culture.

YouTube scaled not by eliminating curators, but by amplifying them.

From Cultural Curators to Concept Curators

Once you see this pattern in entertainment and media, it becomes impossible to unsee it elsewhere.

The same structural role exists in business, but it goes by different names. Analysts, investors, operators, writers, and strategists often do their most valuable work not by generating ideas, but by selecting and synthesizing them. They notice patterns across markets, connect dots between disciplines, and surface concepts that help others think more clearly.

These are not cultural curators. They are what I call concept curators.

Concept curators operate in environments where the constraint is not information, but interpretation. Businesses are flooded with dashboards, metrics, reports, trends, think pieces, and opinions. The problem is rarely a lack of data. It’s deciding which signals matter and which can be ignored.

When someone adds your blog to a curated reading list, they’re not just sharing content. They’re transferring trust. They’re saying, “When I’m overwhelmed, this source helps me make sense of things.” That’s a fundamentally different value proposition than reach or frequency. It’s quieter, slower, and far more durable.

Concept curators don’t aim to be exhaustive. They aim to be useful. Their power comes from restraint and judgment, not volume.

Algorithms, Judgment, and Leadership

Like cultural curators, concept curators are often undervalued because their work is second-order. There’s no obvious artifact. The output is clarity, not content. The impact shows up as fewer bad decisions, better conversations, and faster alignment.

Every organization curates, whether intentionally or accidentally. Every dashboard, roadmap, and metric selection is an act of prioritization. When leaders pretend they’re neutral, incentives and algorithms fill the gap. And those systems will always optimize for what’s easiest to measure, not what’s healthiest to sustain.

This is why curation is ultimately a leadership responsibility. Deciding what deserves attention is inseparable from deciding what matters.

Interestingly, the rise of AI-generated content only increases the importance of concept curators. When content becomes cheap and abundant, quality becomes harder to assess and context becomes more valuable. People don’t want more information. They want help deciding what to ignore.

Curators as Infrastructure

If there’s a single idea worth holding onto, it’s this: modern systems don’t collapse from a lack of content. They collapse from a lack of curation.

From Gladwell’s coolhunters to YouTube’s early participatory culture to today’s business thinkers and writers, the same pattern repeats. Whenever volume overwhelms cognition, curators emerge to restore signal. Sometimes they’re formal. Often they’re informal. But they’re always doing the same essential work, turning abundance into meaning.

Curation isn’t about controlling attention. It’s about respecting it.

And in a world where attention is the real constraint, cultural curators and concept curators may be doing the most important work of all.

Subscribe now

Share

Read the full article: Perfectly Designed for These Results: If you don’t like the outcome, redesign the system

Most leaders carry that idea with a shrug: “I’m just doing my job.”

Yet everything they say, everything they choose to pay attention to, and even every calendar invitation they send echoes through their organization, often in ways they never intended.

A few years back, a Stanford professor’s research on how bosses unintentionally waste their employees’ time brought this into stark relief. Leaders didn’t set out to make people’s work harder or less productive. But small missteps, offhand comments, or ambiguous signals wound up reshaping where people invested their energy, often at great cost.

This phenomenon has a name in organizational psychology: executive amplification, the outsized effect a leader’s communication and behavior can have on the entire organization.

Understanding it isn’t just a matter of politeness. It’s a matter of organizational performance, employee engagement, and strategic execution.

In this article I want to explore:

• Why leaders’ words matter so much

• How that amplifies behavior across teams

• What research says about these effects

• How leaders can use this insight intentionally and responsibly

• The blue-muffin problem: offhand remarks with real consequences

In one of the examples highlighted by Robert Sutton and Huggy Rao’s work on organizational friction, a CEO casually mentioned at a breakfast meeting that there were “no blueberry muffins.” The remark was meant as small talk, not an instruction.

But his team interpreted it as a preference, turned it into a directive, and soon his calendar was surrounded by meetings stocked with blueberry muffins because executives believed it was expected. Only years later did the leader discover how much effort and logistics had gone into fulfilling that incidental comment.

In the 2025 film Jay Kelly, there’s a scene that captures executive amplification perfectly: George Clooney’s character asks why cheesecake appears everywhere he goes. At meetings, at dinners, in hotel suites, it is always there, presented proudly and without question. We learn that this was put in his contract after a quip by him about cheesecake, despite him not really liking cheesecake. The scene works because it mirrors real organizational behavior: when someone carries authority, their words stop being observations and start becoming signals, and those signals travel farther, harder, and more literally than the speaker ever intended.

These vignettes are shorthand for what I mean by executive amplification: a single leader’s comment reverberates far beyond its original intent.

It’s not unusual, and it’s not trivial.

When an executive mentions something, even in passing, others often treat it as an instruction. They bend behavior around that signal. They reallocate priorities. They interpret tone, emphasis, and nonverbal cues as direction.

And when leaders don’t realize how much weight their words carry, they inadvertently introduce friction into workflows, distract teams with unplanned work, or create new “priority signals” that don’t align with strategy.

This is not just an HR gripe. It’s productivity, motivation, and alignment at scale.

Executive communication changes perceptions and behavior

Why does this happen? Part of the answer lies in a classic psychological phenomenon known as the Pygmalion effect.

The Pygmalion effect describes how expectations, especially from authority figures, become self-fulfilling prophecies. Leaders’ expectations shape how individuals see their roles and what they feel obliged or empowered to do. In workplace research, this translates into how leaders’ voice expectations influence employees’ role perception and actual behavior.

Research published in the Journal of Management & Organization found that leaders’ normative expectations shape employee performance through a process that goes deeper than simple compliance. Across two quantitative studies, leaders who clearly communicated high expectations influenced not just what employees did, but how employees came to define their own roles — ultimately internalizing those expectations as part of their professional identity.

This isn’t merely about setting goals. It’s about how employees come to see themselves. The research found that the most powerful mechanism wasn’t employees following a directive or even admiring a leader as a role model — it was that the leader’s expectations became woven into the employee’s sense of who they are at work and what “good work” looks like for them.

That’s a profound level of influence. It means leaders don’t just direct activity, they shape identity within the organization.

Leaders are role models, especially when calendars are public

Another dimension of executive amplification shows up not in words, but in actions.

Leaders frequently must keep their calendars private, not because of ego, but out of necessity. When leaders have open calendars, people watch who they meet with, when they’re available, and what they prioritize. People infer meaning from those patterns: who matters, what issues are worth attention, and whose problems will get solved.

This aligns with broader findings in leadership research on implicit leadership theories, which explain that followers develop cognitive expectations about leaders and then interpret leaders’ behavior through those mental models.

Put simply:

When a leader meets with someone, others see that as a signal.

When a leader declines meetings, others see that as a signal.

Even when neither decision was meant to send one.

These observed behaviors turn into organizational meaning. A private calendar isn’t just about privacy; it’s about controlling the signal bandwidth leaders unintentionally broadcast.

Leaders inadvertently waste employees’ time, and energy

Returning to the Stanford research: what Sutton and Rao call organizational friction isn’t primarily a product of bad intentions. It’s a product of unmanaged amplification.

Some examples highlighted include:

• Leaders launching new initiatives without thinking through the operational consequences, employees drop everything to comply, even if the initiative isn’t aligned with core priorities.

• Ambiguous comments that teams interpret as directives, leading to redundant work or refocusing efforts to satisfy perceived expectations.

The result? Teams spend less time on high-value work and more time on work they think the boss wants. This is expensive in both time and morale.

This also mirrors broader data about workplace time waste. The more meetings people attend, especially meetings driven by ambiguous leadership signals or unclear agendas, the less time they have for deep, meaningful work.

The unintended consequences of being a leader

Leaders often assume their statements are small, just a comment in a meeting, a casual aside, an observation meant as background. But in many organizations, leaders’ behavior functions as a binding signal for others. Teams calibrate to what leaders emphasize, repeat, or react to publicly.

This dynamic is reinforced by research on tone at the top, a concept from organizational ethics and governance. In accounting and corporate governance literature, it’s widely acknowledged that the ethical climate of an organization is determined by the attitudes and behaviors of senior leaders, especially in ambiguous contexts where employees look to leaders for cues about acceptable behavior.

Even though the term originated in accounting, the principle holds in broader leadership contexts: leaders set expectations through their behavior, much more so than through written directives or formal policies.

So what should leaders do?

If you accept that leadership communication and actions have outsized influence, then the question becomes not whether leaders should be careful, but how they should be intentional.

Here are practical steps based on research and best practice:

1. Signal with purpose - Know that every public statement, in a company meeting, even in side conversations, becomes a signal. Leaders should clarify intent and check for shared understanding.

2. Model priority through action - Make calendars intentional. Protecting time for strategic work speaks louder than announcing focus on it. When leaders’ schedules reflect priorities, employees follow. When calendars are chaotic or public, teams infer everything from them.

3. Encourage voice with clarity - Research shows that leaders who communicate clear expectations can encourage employees to speak up and engage proactively, especially when they feel psychologically safe doing so.

4. Be aware of amplification - Leaders should assume anything they say will be amplified, sometimes unpredictably. It’s better to preface statements with context and be explicit about intent than to leave interpretation to inference.

Closing thought

Leadership isn’t just about authority. It’s about interpretive power, what you say, how you act, and what others hear when you do those things.

Leaders don’t get to opt out of being signals. Whether they intend to or not, everything leaders do becomes data to the organization.

Words become work.

Actions become norms.

Signals become strategy.

Executive amplification isn’t a metaphor. It’s a real force in organizational life, one every leader needs to understand and respect.

Because the world listens harder than most leaders realize.

Subscribe now

Share

Before that chapter of my life, I had spent years in the military. Leadership and management was unavoidable there. You didn’t opt into it; it was assigned. You learned quickly that decisions had consequences, that clarity mattered, and that people looked to you whether you felt ready or not. When I left the military and entered the tech world, I mostly treated that experience as something I had done, not something I was. It was background. A prior life.

Then one day, my manager’s manager said something that, at the time, didn’t feel particularly profound.

She said, almost casually:

“You have so much management experience from the military. You should go into engineering management.”

That was it. No grand speech. No formal mentorship session. No multi-year development plan. Just a sentence.

I didn’t walk out of that conversation thinking my life had changed. But it had. That comment altered how I saw myself, and once that shift happened, the rest followed with surprising inevitability. I moved out of individual contributor engineering and into engineering management. That led to broader leadership roles. Those roles eventually led to multiple CTO positions. And later, to being a CEO.

Not because I had planned any of that in advance.

But because someone else helped me recognize a version of myself I hadn’t fully acknowledged.

The power of a reframe

I’ve written before about how change, whether personal or organizational, requires an external force to overcome inertia. People don’t change simply because change is rational. They change when something disrupts their existing narrative.

That’s what this moment was for me.

Until then, my internal story was simple: I am a software engineer who happens to have led people before. Her sentence reframed that into something else entirely: I am a leader whose leadership and management experience is relevant here, now.

That difference may sound subtle, but it isn’t. Careers rarely pivot on skills alone. They pivot on identity. On what we believe is “for people like me.”

What made this moment powerful wasn’t encouragement in the abstract. She didn’t say, “You’d be good at management someday,” or “You should think about leadership.” Those are low-commitment statements. Easy to ignore. Easy to file away under “maybe later.”

Instead, she connected two dots that I had kept separate and presented the connection as obvious. Natural. Already true.

That’s a pattern I’ve seen repeatedly since then, both as a leader and as someone who has benefited from leaders. The highest-impact mentorship moments aren’t about advice. They’re about recognition. About someone else articulating a coherent story of your potential before you can fully tell it yourself.

What great mentors actually do

We often talk about mentorship as a relationship measured in time: monthly meetings, long conversations, ongoing guidance. And those can be valuable. But in my experience, the most consequential mentorship moments are often brief.

They tend to share three characteristics.

First, great mentors surface undervalued assets.

We are notoriously bad at assessing our own strengths. We normalize what comes easily. We discount experience that doesn’t neatly map to our current role. My military leadership experience felt distant from software engineering because no one had explicitly told me it counted. She did.

Second, they offer a new identity, not just advice.

Advice suggests possibility. Identity suggests inevitability. “You could try this” is very different from “this fits who you already are.” One invites exploration; the other invites commitment.

Third, they grant permission.

Career inertia is powerful. Even when something feels right, we often wait for external validation before acting. When that validation comes from someone credible, the psychological barrier drops dramatically.

This is why mentorship is often less about teaching and more about naming. Naming patterns. Naming potential. Naming futures.

The compounding effect of being seen

That one sentence didn’t magically unlock a career. What it did was shift my trajectory by a few degrees. But trajectories compound.

Engineering management forced me to develop entirely new muscles. I had to learn how to communicate context instead of instructions. How to hire people better than me (that was easy). How to build systems that scaled beyond individual heroics. How to sit in ambiguity and still make decisions. How to be accountable not just for output, but for outcomes.

Each of those skills made the next role possible. And the next. And the one after that.

From the outside, this progression can look deliberate and linear. From the inside, it often feels like a series of doors that only became visible after someone pointed them out.

This pattern isn’t unique. It shows up repeatedly in the stories of people whose careers changed because a single leader saw something first.

Henry Ford and Thomas Edison: permission to persist

Before Henry Ford became synonymous with mass production and the automobile, he was a young engineer with a stubborn idea and an uncertain future. In 1896, while working as chief engineer at the Edison Illuminating Company in Detroit, Ford had just completed his first vehicle, a crude, gasoline-powered contraption called the Quadricycle. He believed in the concept, but he had no capital, no track record, and no way of knowing whether the world would ever want what he was building.

What changed wasn’t Ford’s technical ability. It was validation from someone whose judgment mattered.

At a company convention in New York that year, Ford found himself seated near Thomas Edison and described his gasoline-powered engine. Edison, already one of the most celebrated inventors in the world, listened carefully, then banged his fist on the table and said, “Young man, that’s the thing; you have it. Keep at it.” Ford later said that Edison’s encouragement was worth worlds to him.

That moment didn’t prevent the failures that followed. Ford’s first business venture, the Detroit Automobile Company, collapsed within eighteen months. He burned through investors’ patience. By the standards of his time, he looked unreliable. But Edison’s early conviction gave Ford something to return to when things went wrong. It reframed persistence as legitimate rather than delusional.

Their connection eventually deepened into a lifelong friendship, one rooted in mutual respect and, later, material support. Edison continued to encourage Ford’s work even as his own focus remained on electricity. Ford, once successful, repaid that early belief many times over, funding Edison’s research and standing by him through setbacks of his own.

This is an important distinction. Great leaders don’t remove difficulty. They remove illegitimacy. They tell you that the struggle you’re in is a reasonable price for the future you’re aiming at.

Oprah Winfrey and Maya Angelou: identity before platform

Oprah Winfrey’s career is often framed as a story of talent meeting opportunity. That’s true, but incomplete. Early in her rise, Oprah was successful but still constrained by expectations about what she should be: a talk show host, a media personality, a performer.

Maya Angelou offered her something different.

Angelou didn’t just mentor Oprah on craft or career moves. She consistently reinforced a deeper idea: that Oprah’s voice carried responsibility. That her role wasn’t merely to entertain, but to shape how people understood themselves and the world.

That reframing mattered. It helped Oprah transition from hosting a show to building a platform. From reacting to cultural moments to curating them. From being a media figure to being an institution.

Angelou’s mentorship was not about tactics. It was about identity. About helping Oprah claim an internal authority that external success alone doesn’t automatically provide.

Bill Gates and Warren Buffett: changing the game you’re playing

When Bill Gates met Warren Buffett, Gates was already wildly successful. Microsoft dominated its market. Wealth was no longer the constraint. But Buffett influenced Gates in a different way.

Buffett modeled long-term thinking with almost unsettling consistency. He emphasized focus, simplicity, and leverage, not in the technical sense, but in terms of impact. He demonstrated that the game wasn’t about winning faster, but about choosing the right game in the first place.

That influence showed up years later in Gates’s transition toward philanthropy. The Gates Foundation didn’t emerge from a sudden change of heart. It emerged from a gradual reframing of what success meant once financial constraints were removed.

Again, the pattern holds. Mentorship at the highest levels isn’t about skills transfer. It’s about redefining the objective function.

Socrates and Plato: seeing a successor before one exists

One of the earliest and most enduring mentorship relationships in history is between Socrates and Plato. Socrates famously wrote nothing. His influence exists almost entirely through his students, especially Plato.

What’s striking about this relationship is that Socrates didn’t treat Plato as a disciple in waiting. He treated him as a thinker. As someone capable of extending and transforming ideas rather than merely preserving them.

Plato, in turn, went on to found the Academy and shape Western philosophy for centuries. That outcome wasn’t accidental. It was the result of being taken seriously early. Of being treated as more than a student.

Great mentors often behave as if the future is already present. They interact with people based on what they could become, not just what they currently are.

Why this matters more than we admit

There is research that supports this intuition. A majority of senior executives report having had influential mentors. High-quality relationships with leaders correlate with higher performance and engagement. The Pygmalion effect shows that expectations themselves can shape outcomes.

But beyond the data, there’s a simpler truth: most people are walking around with partially formed narratives about themselves. Those narratives are fragile. They can be expanded or constrained by a single credible voice.

This is especially true during career transitions, when identity is most malleable.

A challenge for leaders

If you’re a leader, you are almost certainly sitting on moments like this.

You see patterns in people they can’t yet articulate. You recognize strengths they’ve discounted. You can imagine futures they haven’t allowed themselves to consider.

Saying nothing is not neutral. It preserves inertia.

Leadership isn’t just about setting direction for teams. It’s about helping individuals overcome the quiet friction that keeps them where they are.

Sometimes that requires programs and planning.

Sometimes it requires nothing more than a sentence, said at the right moment, by the right person.

And a note for everyone else

If you’re earlier in your career, pay attention to moments when someone credible reflects something back to you that feels slightly uncomfortable. Not because it’s wrong, but because it doesn’t fit your current self-image.

Those moments are easy to dismiss. They’re also often the ones that matter most.

Careers don’t always change because of careful planning. Sometimes they change because someone noticed something, and said it out loud.

That sentence, spoken years ago, is still echoing in my life. And I’m grateful she said it.

Subscribe now

Share

When results are good, we credit the system. When results are bad, we default to stories about individuals. Someone did not care. Someone was not capable. Those explanations feel clean, but they are usually wrong, and over time they quietly shape systems that punish learning and reward self-protection.

A better starting point is to assume competence and positive intent. Not to lower standards, but to change the question. Instead of asking why someone failed, ask what made success difficult here. That shift moves energy from blame to diagnosis and creates space for people to do their best work.

Most people who are struggling already know it. What they lack is clarity or a safe way to ask for help. Trust matters because control scales linearly while trust scales exponentially. Leaders who look for constraints instead of villains improve performance at scale.

The stories you tell about people become the systems you build. And the assumptions you make today become the organization you lead tomorrow.

Read the full article People Frameworks.