The new cloud service had shipped two weeks earlier and immediately broken in public. Walt Mossberg, the Wall Street Journal columnist whose blessing Apple had relied on for a decade, had written a brutal review. Subscribers couldn’t sync. Email vanished. Press coverage was scathing. Jobs assembled the entire MobileMe team in the auditorium and opened with a question.

“Can anyone tell me what MobileMe is supposed to do?”

Someone gave him a clean answer.

“So why the f--- doesn’t it do that?”

He spent the next thirty minutes telling the team they had tarnished Apple’s reputation. He told them they should hate each other for letting each other down. He told them Walt Mossberg, their friend, was no longer writing good things about them. Then he named a new executive on the spot and disbanded most of the original team. The account comes from Adam Lashinsky’s Inside Apple feature in Fortune, published three years later.

Nobody walked out of that room. No member of Apple’s board called an emergency session. No human resources investigation followed. The CEO of one of the most valuable public companies in the world had just stood in front of dozens of his employees and told them to hate each other, and the organizational response was to ship a better product. Three years later, when Jobs died, he was one of the most admired chief executive in the world.

The interesting question is not whether Steve Jobs was a difficult boss. He was, and the evidence had been public for a very long time. The New York Times described him as “widely hated at Apple” in October 1987. The interesting question is why none of it ever stopped him.

The answer is that we don’t punish behavior. We punish behavior in context. And the context that matters most is whether the numbers are good.

A Framework Hiding in Plain Sight

Most leadership writing treats bad behavior as a fixed quantity. The leader is either abusive or not, either over the line or not, and the only real question is how long it takes the organization to notice. The trouble with this framing is that it doesn’t match what actually happens inside organizations, where the same behavior gets celebrated, tolerated, ignored, and finally prosecuted in rapid succession, often without the behavior itself changing at all.

In 2016, a research team led by Robert J. Bies at Georgetown’s McDonough School of Business published a chapter that tried to explain why. Working with Thomas M. Tripp of Washington State and Debra L. Shapiro of Maryland, Bies argued that whether subordinates and outside observers perceive a leader’s harsh behavior as abuse or as motivation depends on a small set of contextual factors that have very little to do with the behavior itself. Their summary, published in Psychology Today, is unusually direct: “Whether one is viewed as an abusive leader or a master motivator is in the eye of the beholder.”

Three filters do most of the work.

The first is whether the leader develops people into top performers. When the team wins, the yelling reads as standard setting. When the team loses, the same yelling reads as bullying. The second is whether subordinates trust the leader’s motives. Trust acts as a translator that turns hostile remarks into “she wants me to be better.” Without trust, the same remarks become “she is trying to break me.” The third is the explanation the leader offers for the behavior. A sincere account of why the standards are high buys an enormous amount of grace. A dismissive “that’s just who I am” buys none of it.

The implication is the part most readers miss. The behavior may not have to change very much for the verdict to change. Context often does much of the work. And the most volatile element in that context is whether the leader is still winning.

This is not an argument for tolerance. It is a description of the machine. When results are extraordinary, harsh behavior gets reclassified as excellence. When results turn, the same behavior gets reclassified as misconduct. The leader didn’t shift. The frame did.

Three cases show the machine in motion.

Linda Wachner, 1986 to 2001

Linda Wachner won control of Warnaco in a hostile leveraged buyout in 1986 and took the company public again five years later. Over the next fifteen years she built it from a sleepy $600 million bra manufacturer into a $2.5 billion apparel conglomerate. By the late 1990s, she held licenses for Calvin Klein, Speedo, Chaps by Ralph Lauren, and Fruit of the Loom. She was one of only a handful of women to head a Fortune 500 industrial company. By the late 1990s her personal stake in the business was worth around $200 million.

She also ran her organization with a public brutality that was reported openly, repeatedly, and without apparent consequence while the company was succeeding.

In October 1993, Fortune magazine published a cover story titled “America’s Toughest Bosses”. Wachner was one of seven leaders profiled, alongside Steve Jobs, Harvey and Bob Weinstein, T.J. Rodgers of Cypress Semiconductor, and Herbert Haft of Dart Group. The piece quoted her telling a newly arrived executive, “You’d better start firing people so they’ll understand you’re serious.” It noted she had once kept another executive waiting three days before dismissing him after a two-minute meeting. Reached for comment by the Associated Press, her explanation was that “that was in a turnaround situation.”

None of this was secret. Fortune put it in print. The board knew. Shareholders knew. Calvin Klein, who would later sue her, knew. And for the better part of fifteen years, nobody did anything, because while Wachner was doing what Fortune had called her out for doing, the share price was climbing toward forty-four dollars, more than four times the post-split IPO price. She had a severance agreement that would pay her $43 million if she were ever fired. The board was not going to fire her. Why would they? She was making them rich.

Then in 2000, Warnaco lost $338 million that year. The stock fell eighty-seven percent, eventually trading at thirty-nine cents a share. Calvin Klein, who had not previously felt the need to comment on Wachner’s management style during the years his licenses were profitable, suddenly described her in a federal lawsuit as “a cancer on the value and integrity of” the Calvin Klein brand. The Securities and Exchange Commission opened an investigation into a $145 million inventory misstatement; documents released years later showed PricewaterhouseCoopers consultants had alerted Wachner and her CFO to the problem in the spring of 1998, nearly three years before it became public. Warnaco filed for bankruptcy in June 2001. The $43 million parachute was voided by the filing. On November 16, 2001, the board fired her, with the directors deciding not to pay severance.

The Wachner of 2001 was the Wachner of 1993. The management style had not softened, and the inventory problem had not been new; the Fortune profile had run five years before PwC first flagged the inventory discrepancy and eleven years before the SEC formally documented it. What changed was the cover the numbers were providing. The moment the numbers turned, every anecdote that had once been chalked up to a “tough boss” became evidence in a fiduciary case. Same behavior. Different verdict.

Bobby Knight, 1971 to 2000

Wachner showed how quickly the verdict can flip when the numbers turn in a single bad year. Bobby Knight shows the slower version: how institutions absorb behavior, decade after decade, until they cannot remember what their original standards were. Knight coached the Indiana Hoosiers for twenty-nine years. He won three NCAA championships, an Olympic gold medal in 1984, and 662 games at Indiana alone. He was, by any reasonable measure, one of the most successful college basketball coaches who ever lived.

He was also, across those same twenty-nine years, repeatedly violent.

In 1975, he grabbed sophomore guard Jim Wisman by the jersey and jerked him into his seat during a game. On February 23, 1985, during a home game against Purdue, he picked up a red plastic chair from the Indiana bench and threw it across the floor as a Purdue player prepared to shoot a technical free throw. In March 1994, he head-butted a freshman named Sherron Wilkerson after pulling him from a game. In 1997, during a closed practice, he put his hands around the throat of a player named Neil Reed.

The notable feature of each of these incidents is not the incident itself. It is what the institution did about it. The chair-throwing in 1985 produced a one-game suspension from the Big Ten and two years of probation. Knight made it into a recurring comedy bit on David Letterman. The head-butt in 1994 was explained away by Indiana’s sports information director as an accident. The choking incident in 1997 was not acted on at all by Indiana.

This is where Diane Vaughan’s work becomes useful. In The Challenger Launch Decision, published by the University of Chicago Press in 1996, Vaughan analyzed how NASA, an organization with no shortage of intelligence, expertise, or safety procedures, came to launch a shuttle that was likely to fail. Her conclusion, what she called the normalization of deviance, was that institutions don’t tolerate single transgressions. They tolerate accumulating ones. Each time a deviation from the standard happens and produces no catastrophic consequence, the deviation gets quietly absorbed into the new standard. By the time something irreversible happens, the organization has been operating outside its original safety parameters for years and calling it normal.

That is exactly what happened at Indiana. By 1997, the institution that would have fired any other coach for choking a player in practice did not act, because Indiana had already been absorbing Knight’s behavior for twenty-six years. The chair, the head-butt, the grabbed jerseys, all of these had already been absorbed into how Coach Knight runs the program. The choking incident in 1997 had effectively ceased being treated as a transgression. By 1997, it was the standard.

What finally moved Indiana was not the behavior. It was the visibility. In March 2000, CNN/Sports Illustrated aired the practice video. Three months later, Indiana president Myles Brand imposed a “zero tolerance” policy. In September 2000, Knight grabbed the arm of a freshman who had said, “Hey, Knight, what’s up?” and Brand fired him.

By that point, Indiana had not been to a Final Four since 1992 and had not won a championship since 1987. The team was no longer a national title contender. Bies’s analysis names this directly: Knight was, in his words, “eventually fired for reasons that pointed to the abusiveness of his leadership style at a time when his team no longer had a winning record.” The behavior had not escalated. The cover had collapsed.

Steve Jobs, 1976 to 2011

Return briefly to the MobileMe room, because the point is not to relitigate Jobs. The point is that he proves the model at the highest possible altitude.

The 1987 Times description of Jobs as “widely hated at Apple” was published before the Macintosh team had even finished metabolizing his first ouster. The MobileMe meeting in 2008 was twenty-one years later. In between, Jobs returned to Apple in 1997, launched the iMac, the iPod, the iPhone, and the iPad, and added roughly $400 billion in market capitalization. Walter Isaacson’s biography catalogs more or less the same behavioral patterns in 1983 and in 2010. The patterns did not soften with age.

What changed, instead, was that by the time of the MobileMe meeting, no internal critic existed who could survive a confrontation with both the CEO and the share price. Bies’s three filters were all maximally pinned in Jobs’s favor. The products were defining a generation. Trust was reinforced every quarter. And Jobs’s standard explanation, that the company existed to make great products, was the most defensible motive any leader has ever been able to claim.

This is what the Bies framework predicts in the limit case. When results are extraordinary, harsh behavior does not get downgraded into motivation. It gets upgraded into legend. The MobileMe team did not leave that auditorium feeling abused. By every account that survives, they left it more committed to fixing the product. That is not a happy ending. That is the system working exactly as Bies and Vaughan described it.

The Uncomfortable Mirror

Most readers of this piece will not be running organizations with Steve Jobs in them. They will be running organizations with a much more ordinary version of the same problem.

The high-performing engineer whose 1:1s leave people in tears, but whose technical judgment is irreplaceable. The salesperson who hits 140 percent of quota every quarter and openly disrespects the legal team. The executive whose strategy is brilliant and whose treatment of direct reports is corrosive. In every case, the same machine is running. Each instance of bad behavior produces no real consequence because the results of the behavior are good. Each non-consequence teaches the organization that the standard has moved. By year three, the behavior is no longer a transgression. It is a feature.

The harder, more honest question is the one Bies’s framework forces on every leader who is paying attention. What would the verdict on this person’s behavior be if their results dropped twenty percent next quarter? Not because their results are likely to drop. They probably aren’t. But because the gap between how you are judging the behavior today and how you would judge it tomorrow is the exact measure of how much coverage their performance is currently providing.

That gap is your normalization of deviance. It is also the headline you have not written yet.

What to Do About It

This week, write down the name of one person in your organization whose behavior you would act on tomorrow if their numbers dropped twenty percent. Do not soften the exercise by adding the people whose behavior is bad and whose numbers are bad. Those are easy. Write down the name of the person whose behavior you are currently filing under “high standards” or “passion” or “she gets results.”

Then ask yourself the harder question. Are you waiting for the behavior to escalate, or are you waiting for the results to fade? Because if it is the second one, your organization is not making a judgment about character. It is making a bet about performance. And if the performance ever turns, the same behavior you are tolerating today will become the headline you are explaining tomorrow.

The verdict is not on the leader.

The verdict is on you.

Subscribe now

Share

I write because it helps provide me with clarity of thought. Each post forced me to take a half-formed idea or something nagging at me and work it into something coherent. Some posts landed, some didn’t. But all of them taught me something.

This post marks the 200th article. To help celebrate that, here are the 50 articles that resonated most with folks. The ones readers shared, debated, and came back to. I’ve organized them into seven themes that, taken together, represent the map I carry as a leader and operator.

I hope they’re useful to you.

In this post

1. 🦅 Leadership & Vision

2. 🏛️ Culture

3. 🤝 Managing People

4. 🎯 Product & Strategy

5. 🤖 AI & Technology

6. 🌱 Personal & Professional Growth

7. 🔄 Change & Adaptation

🦅 Leadership & Vision

#1 The Shape of Leadership - Leadership Lessons from Birds That Know When to Lead and When to Adapt

Great leaders know when to take charge and when to follow. Drawing on the breathtaking collective behavior of murmurations, this post reimagines what modern adaptive leadership looks like.

#2 Leadership Principles - Part 1 - Self-Awareness, Technical Mastery, and Team Welfare

The foundation of great engineering leadership rests on three pillars: self-awareness, technical mastery, and genuine care for your team. This post unpacks each one with practical examples drawn from real organizations.

#3 Visionary Leaders and Product Success - A Closer Look

A clear product vision doesn’t just inspire the team, it fundamentally shapes what gets built and how. This post examines the patterns connecting strong product leaders to winning outcomes.

#4 No More Mr. Nice Guy - Why caring means making the hard decisions

Real care isn’t about avoiding hard conversations, it means making difficult decisions in service of your people and your mission. The most caring thing a leader can do is be honest, even when it’s uncomfortable.

#5 Speed Is Never Just Speed - What rugby can teach us about leadership

There’s a lot more going on underneath the surface when we talk about moving fast. Drawing on rugby’s concept of decision-making under pressure, this post explores what velocity actually means in leadership.

#6 The Impact of One Great Leader - How a sentence changed my career

A single sentence from a mentor changed the way I approached my entire career. This post explores the outsized, often invisible impact that one exceptional leader can have on the people around them.

#7 Leading Through Ambiguity - Create Alignment, Not Illusion

Creating alignment when the path isn’t clear is one of the hardest jobs in leadership. This post lays out a framework for making decisions and maintaining team confidence even when the answers aren’t obvious.

#8 Executive Amplification - Why what leaders say matters more than they think

A CEO once mentioned offhand that there were “no blueberry muffins,” and his team spent years stocking them at every meeting. This post explores executive amplification, the outsized effect a leader’s words, behaviors, and even calendar choices have on the organization, and what leaders should do once they realize how loudly they’re being heard.

🏛️ Culture

#9 Culture - Which is the best?

Not all cultures are the same. Some organizational models are dramatically more effective than others. This post compares different cultural archetypes and helps leaders identify which one their organization has, and whether it’s the one they want.

#10 Culture Debt - The Invisible Interest of Speed

Just like technical debt, cultural shortcuts accumulate and eventually demand repayment. This post introduces the concept of culture debt, the hidden cost of deprioritizing culture in favor of speed.

#11 How Culture Scales (or Doesn’t) - The Uneven Path of Growth

Culture that works beautifully at 20 people can break completely at 200. This post traces the uneven path of cultural evolution as organizations grow and what leaders can do to stay ahead of it.

#12 Teamwork - Working together makes all the difference

The best products and outcomes almost never come from individuals alone. This post makes the case for investing in team dynamics, and explores what working well together actually requires in practice.

#13 Cultivating a Culture of Excellence - Goals, Metrics, Experimentation, and more

Excellence at scale doesn’t happen by accident - it requires goals, metrics, experimentation, and constant reinforcement. This post lays out a practical approach to building and maintaining a culture that expects and rewards great work.

#14 Conflict - Sometimes it is useful

Contrary to what most managers believe, conflict isn’t something to eliminate, it’s something to use well. This post explores how productive tension and well-managed disagreement are hallmarks of strong, healthy teams.

#15 The Brilliant Jerk vs. Team Performance - Why The Team Always Wins

A single high-output but destructive team member can undermine the performance of an entire group. The research is clear, protecting team dynamics is worth more than any individual contribution.

🤝 Managing People

#16 Management - The most noble of professions

Management is not a consolation prize for people who can’t code, it’s the most leveraged profession in any organization. This post makes a passionate case for why management is noble, underappreciated, and deeply meaningful work.

#17 People Frameworks - How Leaders Should Think About People

How you think about people problems determines how well you solve them. This post introduces frameworks that help leaders organize their thinking about team dynamics, performance, and growth.

#18 Thayer Method - How to run large meetings

Large meetings are notoriously hard to run well, but they don’t have to be. This post introduces the Thayer Method, a simple structure that brings clarity and momentum to even the most complex group discussions.

#19 Are 1:1s Worth The Time? - An exploration of the pros and cons of 1:1 meetings

The humble one-on-one is both the most powerful and most misused tool in a manager’s toolkit. This post honestly examines the tradeoffs and offers a clear framework for deciding how to make 1:1s genuinely useful.

#20 Hands Off - How to know how close to manage

Knowing when to step back is one of the most underrated management skills. This post helps leaders calibrate the right level of involvement for each team and situation, not too close, not too distant.

#21 How To Start a New Role - Listen and learn before taking action

The first 90 days in a new leadership role can define your long-term success or undermine it. This post argues for listening and learning before taking action, and explains why patience at the start pays dividends later.

#22 How Do You Know If You're a Good Leader? - The hardest performance review is your own

In September 1862, Abraham Lincoln privately wrote a meditation that admitted he might be wrong about the war he was leading. This post uses that moment as a starting point for an honest framework on self-evaluation, arguing that the leaders most committed to self-examination, not the ones most convinced of their own righteousness, are the ones worth following.

#23 Hiring Great People - Look for curiosity

The single trait that most predicts future success is something most hiring processes don’t screen for. This post makes the case that curiosity, not pedigree or technical skill, is the quality worth hiring for above all else.

🎯 Product & Strategy

#24 People > Principles > Process > Product - The order in which you should prioritize

The order in which you prioritize things determines everything about how your organization operates. This post argues for a clear hierarchy and explains why getting the foundation right unlocks everything above it.

#25 The Measurement Trap - The Hidden Costs of Over Reliance on Metrics

Metrics are meant to help us but sometimes they start to hurt us. This post explores the hidden costs of over-reliance on measurement and how organizations fall into optimizing for the wrong things.

#26 Build the Right Thing - And the money will follow

The Wright brothers obsessed over outcomes while Samuel Langley optimized for outputs, and only one of them learned to fly. This post draws on the early history of aviation to make the case that financial validation applied too early to product work doesn’t reduce risk, it manufactures the illusion of control while quietly killing the ideas worth pursuing.

#27 Frameworks - Handrails for thinking

Mental models and frameworks are handrails for thinking, they help you navigate complex problems faster and more consistently. This post explores what makes a good framework and how to apply them without falling into rigid, formulaic thinking.

#28 Solve Customer Problems - Start with the job to be done

The best products start not with technology but with a deep understanding of what job the customer is trying to get done. Applying jobs-to-be-done thinking changes everything about how you build.

#29 Run Your Own Race - Focus more on what customers need and less on competition

Obsessing over competitors is a trap that distracts teams from what actually creates value, deep attention to customer needs. This post makes the case for building with your customer in mind, not your competition in your rearview mirror.

#30 Aim Small, Miss Small - Attention to details

Precision and attention to detail at the micro level produces dramatically better outcomes at the macro level. A culture of high standards in small things compounds into extraordinary results over time.

#31 Exploit vs Explore - What bees and casinos can teach us about product leadership

A hive that only exploits known food sources will starve, and one that only explores will burn out. This post draws on the waggle dance, multi-armed bandits, and resilient product organizations to argue that your roadmap isn’t a plan, it’s a portfolio, and the question isn’t whether to exploit or explore but whether your system allows you to do both honestly.

🤖 AI & Technology

#32 More Efficiency, More Demand - The future of software engineers and data scientists is bright

Jevons’ Paradox tells us that as AI makes software engineers more productive, demand for their work actually increases. This post makes the case that AI is creating more opportunity for engineers and data scientists, not less.

#33 The Importance of Engineering Managers - What happened when a company set out to disprove the importance of managers

When Google famously tried to prove managers didn’t matter, they discovered the opposite. This post examines the unique and irreplaceable role engineering managers play in building high-performing technical teams.

#34 Architects & Tech Leads - What do they do and how do they work together?

Technical architects and tech leads are often confused, yet they serve distinct and essential functions. This post clarifies both roles and explains how to set each up for success in your organization.

#35 Everything New Has Bugs - Increasing velocity and quality

Moving fast and maintaining quality aren’t actually opposites, if you engineer for both from the start. This post offers a framework for increasing development velocity without accumulating the quality debt that slows you down later.

#36 The AI Trap - The Cycle of Shiny New Technologies

Every generation has its shiny new technology that promises to change everything and AI is no different. This post traces the familiar cycle of hype, disappointment, and eventual integration, and offers a more grounded way to think about AI adoption.

#37 Twitching Before You Sprint - What sleeping rats, robots, and great companies have in common

Sleeping rats twitch, not randomly, but to help their brains learn how their bodies work before they ever have to use them. This post extends that finding into product and organizational design, making the case that the best companies move before they commit, test before they scale, and treat low-stakes motion as a serious form of learning rather than wasted effort.

#38 Engineering Maturity Model - Layering

Great engineering organizations don’t happen overnight, they grow in deliberate layers. This post introduces a maturity model for building engineering capability over time, from foundational practices to advanced organizational design.

🌱 Personal & Professional Growth

#39 Time Management - 10 Ways to Take Ownership of Your Time

Most time management advice focuses on efficiency, this post focuses on ownership. It lays out ten concrete ways to stop letting your calendar happen to you and start making intentional choices about where your time goes.

#40 Writing - Why leaders should take the time to write

Writing is one of the highest-leverage habits a leader can build. Leaders who write regularly think more clearly, communicate more effectively, and develop stronger ideas.

#41 The Success Trap - How winning can shrink your options

Success can narrow your options as easily as it expands them, if you’re not careful. This post explores how winning in the short term can box you in, and how to avoid the trap of optimizing for today at the expense of tomorrow.

#42 Short-term vs Long-term - How to balance investments

One of the most recurring tensions in any organization is balancing near-term results with long-term investments. This post offers a practical framework for thinking through when to optimize for now and when to build for later.

#43 Listen or Speak - What should leaders do more of?

Most leaders default to speaking when listening would serve them far better. The best leaders are ruthlessly selective about when they use their voice and generous with their attention.

#44 Challenge Network - The Competitive Advantage of Being Challenged

Having people around you who challenge your thinking isn’t comfortable but it’s a serious competitive advantage. This post introduces the concept of a challenge network and explains why being genuinely challenged makes you dramatically more effective.

#45 The Repetition Advantage - Why Product Mastery Is Built on Systems, Not Sparks of Genius

Mastery in product work comes not from flashes of genius but from systematic repetition and deliberate practice. This post draws on athletic training research to show why product mastery is built on systems, not inspiration.

🔄 Change & Adaptation

#46 When Change Outruns Us - Why growth depends on absorption and recovery

Organizations and people can only absorb so much change at once. Sustainable growth depends on the often-overlooked capacity to recover and integrate new ways of working before the next wave hits.

#47 Perfectly Designed for These Results - If you don’t like the outcome, redesign the system

If you don’t like what your system is producing, the answer isn’t to push harder, it’s to redesign the system. This post applies systems thinking to organizational challenges and shows why changing inputs rarely works without changing the underlying design.

#48 Unintended Consequences - The perils of poorly designed metrics and incentives

Poorly designed metrics and incentives reliably produce outcomes nobody wanted. This post catalogs the most common patterns of metric misalignment and offers practical guidance for designing incentives that actually drive the behavior you want.

#49 Collective Fallacy - How it can stifle innovation

When groups make decisions together, the results can be worse than what any individual would have chosen alone. This post explores the mechanisms behind collective fallacies and how leaders can structure decision-making to avoid them.

#50 Change Is Hard - Frameworks can help

Every organization knows change is necessary, and almost every organization finds it harder than expected. This post introduces frameworks that actually help teams navigate change, rather than simply accepting that it will be difficult.

Thanks for reading.

Subscribe now

Share

They were inventing it, and they were inventing it on Schwinn’s own product. The vintage frames they prized were the same balloon-tire bikes Frank Schwinn had pioneered in the 1930s. According to the Marin Museum of Bicycling, the fat tire that Frank had introduced in 1933 had “the same wheel diameter, cross-sectional diameter and carcass construction as the tires used by the Marin County pioneers in the 1970’s.” Schwinn had, decades earlier, built the literal raw material for the mountain bike revolution. They were watching their own DNA get reassembled into the future of the industry.

The leadership in Chicago was not unaware. The phenomenon was visible enough to make national television. And the company’s response, captured in interviews with Judith Crown, co-author of the definitive history of Schwinn’s collapse, was withering. Frank V. Schwinn, then heading the company, “wasn’t interested in change” and “turned up his nose at others using Schwinn frames to make mountain bikes.” Crown’s verdict on the executive team was blunt: “the older executives just pooh-poohed it.” Schwinn’s own marketing department, per the company’s history, “initially discounted the growing popularity of the mountain bike, concluding that it would become a short-lived fad.” The reasoning behind the dismissal, captured in Crown and Coleman’s No Hands: The Rise and Fall of the Schwinn Bicycle Company, is almost charmingly insular. Company executives “had trouble imagining that any adult would spend money on what they thought of as a toy.”

That sentence is worth thinking about for a moment, because it tells you everything you need to know about how a hundred-year-old American institution went bankrupt. The mountain bike was not a fad. It became, and remains, the dominant category in the global bicycle industry. Companies like Specialized, Fisher MountainBikes, and Trek were soon selling hundreds of thousands of mountain bikes at competitive prices to eager customers, setting sales records in a market niche that quickly grew to enormous proportions. Schwinn, meanwhile, kept building the bikes it had always built, in the factory it had always built them in, for the customers it imagined still existed. Sales dropped by half during the second half of the 1980s. Schwinn eventually entered the mountain bike market, but by then companies like Specialized and Trek had seized much of the momentum. The company filed for bankruptcy in 1992.

There are a lot of business school postmortems on Schwinn, and most of them blame manufacturing complacency or globalization or some flavor of management incompetence. All of those are true. But the more interesting question, and the one that matters for anyone in a leadership seat today, is why Schwinn’s leaders made the calls they made. The answer is right there in the Crown and Coleman account, in language that is impossible to misread. “No one but a Schwinn would ever run Schwinn, and few not named Schwinn ever came close to real power in the company.” Daughters were excluded from the business by tradition. Outside investors were repeatedly turned away. When the bankers eventually came to the table in the early 1990s, the family declined private capital again, on principle, because outside money meant outside voices, and outside voices were not how Schwinn made decisions.

Schwinn’s leaders did not fail because they were stupid. They failed because every person they consulted had reached the same conclusion they had, by the same path, from the same vantage point. Their advisory network was a closed loop. The people in the room agreed that adults would not buy mountain bikes because everyone in the room was the kind of person who would not have bought a mountain bike. The data they trusted was the data their inner circle generated. The judgment they sought was the judgment their inner circle returned. By the time the world disagreed with them loudly enough to break through, the world was buying its bikes from Specialized.

This is not a story about a bicycle company. This is a story about what happens to leaders, in any industry, who let the network around them collapse into a single tight cluster of agreement.

The Two Networks Every Leader Has

Every leader operates inside two networks at the same time. The first one is obvious. It is the network of direct reports, peers on the leadership team, the board, the vendors who present quarterly, the consultants on retainer. It shows up on org charts and calendars and Slack channels. It is the network you manage, and most leaders pour something close to all of their relational energy into it. That is reasonable. It is the network that pays the mortgage.

The second network is invisible. It is the lattice of former colleagues, peer group members, friends from a previous role who are now at a competitor, the person you sat next to at a conference three years ago and exchanged thoughtful messages with twice since, the neighbor who happens to be a CFO at a company that does something adjacent to what you do. You do not manage this network. You either feed it or you starve it. Most leaders, without quite meaning to, starve it. It withers quietly, and they do not notice until they need it and discover it is no longer there.

The temptation, especially when work gets busy, is to treat the first network as sufficient. The people in the first network are smart, capable, well-informed, and immediately available. They show up to your one-on-ones. They prepare materials for your offsites. When you ask them what they think, they tell you. The whole apparatus of your professional life is designed to make them feel like the natural and complete answer to the question of who you should consult.

They are not. The first network is necessary. It is also, on its own, dangerous. To understand why, you have to understand what kind of information actually flows through tight social structures versus loose ones. And for that, you have to go back to a paper a sociologist wrote in 1973.

Why Strong Ties Tell You What You Already Know

In 1973, Mark Granovetter published The Strength of Weak Ties in the American Journal of Sociology. Most people who have heard of the paper remember it as being about job-hunting, which was Granovetter’s empirical hook. He found, in a survey of professionals who had recently changed jobs, that their new positions had come overwhelmingly from acquaintances rather than close friends. That finding has been replicated many times since. A 2022 study of 20 million LinkedIn users covered by MIT Sloan’s Ideas Made to Matter confirmed it at internet scale. Weak ties move careers.

But the deeper claim in Granovetter’s paper, the one that matters more for the question of how leaders make decisions, is about information itself. Strong ties cluster. The people closest to you, your immediate team, your closest peers, your inner circle, tend to know roughly the same things you know, because they are embedded in the same network you are. They read the same publications, attend the same conferences, talk to the same vendors, gossip about the same competitors. Their information set overlaps almost perfectly with yours.

Weak ties span what Granovetter called structural holes. They bridge between clusters. The acquaintance who works at a company in a different industry, the former colleague who left to start something on the West Coast, the person you met at a peer group dinner three years ago and have stayed loosely in touch with, all of them sit in different neighborhoods of the network than you do. They have access to information your strong ties literally cannot have, because your strong ties are standing where you are standing. As Granovetter put it, no strong tie is a bridge. The most novel, decision-altering information almost always arrives through somebody you do not know that well.

Now go back to Schwinn for a moment. Schwinn’s leaders had every strong tie a person could want. Brothers, cousins, lifelong colleagues, distributors who had worked with the family for decades. What they did not have, structurally, was a single weak tie inside the room when the mountain bike conversation happened. There was no person in that meeting who had spent a weekend on Mount Tamalpais. There was no acquaintance from a different industry who could have said, the way the data eventually said it, that what looked like a fad to a man in a suit in Chicago looked like a movement to a generation of riders in California. The bridge was missing. The information could not cross.

This is the same dynamic that shows up in every echo chamber post-mortem ever written, from the Bay of Pigs to the 2008 financial crisis. The Harvard Business Review summarized it bluntly a few years ago: the higher leaders go, the more likely they are to find themselves surrounded by people who think like them and agree with them. Affinity bias does some of the work. Hiring patterns do more. The simple gravitational pull of a calendar full of internal meetings does the rest. Without deliberate intervention, the network around a senior leader will collapse, by default, into the most informationally redundant possible shape.

This Pattern Scales From People to Whole Economies

If you want to see what closed networks and open networks look like at the scale of an entire industry, the cleanest natural experiment ever recorded is documented in AnnaLee Saxenian’s 1994 book Regional Advantage. Saxenian set out to explain a puzzle that had been quietly tormenting economists for a decade. In the early 1970s, two American regions were producing the world’s most advanced electronics: Silicon Valley in Northern California and the Route 128 corridor outside Boston. Both had elite universities. Both had defense department contracts. Both had brilliant engineers and venture capital and ambitious founders. And then, over the course of about fifteen years, one region pulled away and one region stagnated.

The conventional explanations, weather, taxes, culture, did not hold up under scrutiny. What Saxenian found, after years of fieldwork, was that the difference was structural. Boston’s Route 128 firms were vertically integrated, secretive, and proprietary. Engineers stayed at one company for decades. Information was an asset to be hoarded. The companies were strong, but the region was a collection of isolated fortresses.

Silicon Valley was the opposite. As Saxenian documented, the region was “distinguished by unusually high levels of job-hopping. During the 1970s, average annual employee turnover exceeded 35 percent in local electronics firms and was as high as 59 percent in small firms.” That sounds like chaos, and from any individual company’s perspective it was. But at the regional level it was something else entirely. Engineers carried what they learned across firm boundaries. Suppliers worked with multiple competitors. People socialized across companies. The network was porous, and the porousness meant that knowledge accumulated faster in the region as a whole than it did in any single company.

Saxenian’s verdict is that Silicon Valley’s engineers “developed stronger commitments to one another and to the cause of advancing technology than to individual companies or industries.” The region became a learning system. Route 128 remained a collection of learning organizations, which is a categorically different and weaker thing. The region with the more open network compounded. The region with the more closed network did not.

The same logic that explains why one regional economy outpaced another is the logic that explains why one leader’s judgment compounds and another’s stagnates. A leader whose network is closed, only consulting people who work for them, only attending events sponsored by their own vendors, only reading the same five Substacks every week, is operating like a Route 128 firm. The information they receive is high-quality but redundant. They will produce smart-sounding decisions for years, right up until the world changes underneath them and the decisions stop working. A leader whose network is open and well-fed, by contrast, is operating like a Silicon Valley engineer in 1975. They are picking up signal from a dozen different neighborhoods of the network. They will sometimes look less efficient in the short term, because they are spending time on conversations that have no obvious ROI. But they will see things their closed-network peers cannot see.

Peer Groups as Manufactured Serendipity

I have written before about peer groups, and at the time I framed them mostly as a source of advice and emotional support, which they are. But I want to reframe them now, because they are also something more important than that. Peer groups are the deliberate, peacetime engineering of the second network. They are how a working leader manufactures the kind of weak-tie infrastructure that Saxenian’s Silicon Valley engineers got accidentally, by changing jobs every two years.

Most of us cannot, and should not, change jobs every two years to keep our information set fresh. Peer groups are the workaround. The New York CTO Club, Venwise, 7CTOs, the various functional roundtables and birds-of-a-feather gatherings that exist in almost every industry, they all serve the same structural function. They put you in a room, on purpose, with people whose information set does not overlap with yours. You leave the room knowing something you did not know when you walked in, and the something is almost always something you could not have learned by talking to anyone on your own team.

This is the part of peer groups that I undersold the first time I wrote about them. They are not nice. They are not optional. They are the closest thing a leader has to a structural defense against the closed-loop problem. Schwinn did not fail for lack of intelligence. Schwinn failed for lack of bridging ties. A working peer group, treated seriously, is exactly the kind of bridging tie that would have put a Marin County rider in the room before the mountain bike got dismissed.

How to Tell If Your Second Network Is Alive

There is no clean metric for the health of an invisible network, but there are a handful of honest questions that will tell you, fairly quickly, whether yours is functioning or atrophying. Of the last five major decisions you made, how many did you stress-test against someone who does not work at your company? Name three people you would call right now for unvarnished input on a hard call who do not depend on you for their paycheck. When was the last time you heard a useful piece of professional information from someone who has no obvious reason to keep talking to you? If you left your current role tomorrow, how many of the people you talk to every week would still be talking to you in six months?

If those questions are uncomfortable, the second network has gone quiet. The diagnostic is not about volume. A leader with five thousand LinkedIn connections and zero weak ties they actively feed is just as isolated as one with fifty. What matters is whether information is actually crossing bridges into your decision-making, or whether you are running, like Schwinn, on the recycled judgment of a single tight cluster of people who already agree with you.

The Challenge

The team you lead will, most days, tell you that you are right. They will mean it. From where they sit, you usually are. That is the gift of a strong, cohesive inner circle, and it is worth protecting. The research on belonging is unambiguous about how much that closeness matters for performance, retention, and trust. Do not give it up.

But understand what it cannot do for you. A strong-tie network cannot give you the one thing you most need from the people around you, which is information you do not already have. For that, you need the people you do not manage, do not pay, and do not see every day. You need former colleagues you have stayed in touch with on purpose. You need a peer group you actually show up for. You need the acquaintance from the conference whose perspective is different enough from yours to be uncomfortable. You need, in short, the network you cannot see.

This week, before the inbox refills and the calendar reasserts itself, pick three people in your second network and reach out. Do not ask them for anything. Do not pitch them on a job or a meeting or a deal. Just keep the bridge open. Send a note that says you were thinking about something they once said, or ask how a project they mentioned a year ago turned out, or share an article and ask what they made of it. The point is not the message. The point is that bridges decay when they are not walked across, and you do not get to build the bridge on the day you need it.

The biggest risk for most leaders is not bad ideas. It is having built a feedback loop so tight that bad ideas come back validated. That’s when they discover, the way Schwinn discovered, that by the time the world disagrees with them loudly enough to break through, the world has already moved on.

Subscribe now

Share

According to Clarence Jones, the lawyer and confidant who helped draft the original remarks, the most famous passage in twentieth century American oratory was not in the text. Mahalia Jackson, the gospel singer who had performed earlier that day, was sitting on the platform behind King. Somewhere in the middle of the address, she called out to him, loud enough to be heard: “Tell them about the dream, Martin.” Jones recalls watching King set the prepared pages aside. What followed was improvised. The dream of children walking together. The dream of mountains made low and valleys lifted up. The dream that was rooted in the American dream.

The data of injustice was already on the page. The story was not. And it was the story that changed America.

I have been thinking lately about why this is. About why a story, told well, can do work that no amount of evidence will ever do. About why most of what I remember from a career of meetings and decks and offsites is not the bullet points but the moments someone told me a story I had never heard before. A story is not a leadership technique. It is something more fundamental than that. The story itself, I want to argue, is the first principle of all art, of which leadership is one. And once you see it, you cannot unsee how much it explains.

The first principle

Let’s start with the obvious cases. Literature is stories. Novels, short fiction, narrative nonfiction, memoir, biography. Poetry too, even the spare imagist poems and the haiku, which compresses an entire scene into seventeen syllables and asks you to fill in the rest. Drama is stories acted out. Film and television are stories projected. None of this is controversial.

But push outward. A painting is a single frame of a story. Edward Hopper’s diner at midnight is asking you who those four people are, what brought them there, what they will not say to each other. The Mona Lisa is asking what she is thinking, and the fact that we still cannot answer is precisely why she is famous. Rodin’s Thinker is mid-thought, which is to say mid-story. Even photography, the most documentary of forms, is a frozen instant of something that came before and something that will come after.

Music is harder, but I think it works the same way. A song has tension and release, verse and chorus, a build and a payoff. Even instrumental pieces with no lyrics carry an emotional arc, which is what an arc is for. The reason a Coltrane solo or a Beethoven adagio can move us is that it is enacting something, going somewhere, even if where it is going cannot be put into words.

Pottery and ceramics tell the story of a hand shaping a material into something useful, and then the story of the meal that bowl will hold, and then, eventually, the story of being unearthed by an archaeologist who tries to reconstruct the people who used it. Architecture tells you what its makers thought mattered. The cathedral and the strip mall are arguing about different stories, and you can read the argument in the materials and the proportions if you know how to look.

The point is not that art uses stories. The point is that story is what art is.

The operating system

There is a reason for this, and the reason is us. Humans do not actually think in spreadsheets, even when we pretend to. We think in stories. The literary scholar Jonathan Gottschall makes this case in The Storytelling Animal, drawing on cognitive research showing that narrative is not a thing the brain does occasionally. It is closer to the format the brain runs in. We turn weather into stories about luck. We turn coincidences into stories about fate. We turn quarterly numbers into stories about strategy.

Princeton researchers have shown that when one person tells a story and another person listens, the listener’s brain activity begins to synchronize with the storyteller’s. Not just in the language regions, but in regions associated with emotion and prediction. The teller and the listener are not really two people anymore for the duration of the story. They are running the same simulation. I think this is also what happens when you stand in front of a painting that grabs you, or when you finally hear what a song was trying to tell you. The art is not finished in the canvas or the recording. It is finished in you.

Which raises a fair objection. What about the art that seems to refuse this entirely? What about a Rothko canvas of nothing but color fields, or a piece of late Coltrane that abandons melody, or the cold concrete of a Brutalist building? Where is the story there?

I think the honest answer is that the viewer brings one. The art that appears to reject narrative is actually betting on it, betting that you will supply the story it withholds. Stand in front of a Rothko long enough and you will start telling yourself something. The piece is incomplete until you do. Which is, in its own way, an even stronger version of the thesis. Story is so foundational to how we make sense of anything that even art designed to refuse it gets re-storied by the people experiencing it. There is a Hopi proverb worth remembering here: those who tell the stories rule the world. The corollary is that the world is always being told stories, whether or not anyone is consciously telling them.

The leader as curator

Bring this back to leadership, because it is the same observation. Managing and leading are not the same thing. Managing is about tasks, deadlines, dependencies, and the mechanics of getting work done. Leading is about meaning. A junior engineer who frames a thorny project as a chance for the team to finally build something they will be proud of is leading, even without anyone reporting to them. A senior vice president who only talks about deliverables and dates is managing, even with hundreds of people on their org chart. The difference is not seniority. The difference is whether you are giving your team a story to live inside while the work gets done. And meaning travels in stories.

The Mahalia Jackson moment is the proof. King had the data. He had the structure of the march, the coalition, the years of preparation. He had a prepared text that was, on its own merits, a perfectly competent speech. What he did not have, until prompted, was the story. The story is what turned a march into a memory.

The same dynamic shows up everywhere if you look. Apple’s 1984 commercial was not a product specification. It was a two minute David and Goliath myth, with the Macintosh cast as the rebel hammer thrown at a screen full of conformity. The commercial was the story; the product was almost incidental to the launch. Howard Schultz, returning to Starbucks during the 2008 collapse, did not lead with operational fixes, although those came. He led with a story about who Starbucks was and what it had forgotten about itself. Shackleton, before the Endurance ever sailed, was already trafficking in the story of his expedition; whether or not the famous “men wanted for hazardous journey” advertisement was ever actually printed (and the historical evidence suggests it probably was not), the story of the ad has done more leadership work in the century since than most things that were actually said. Even an apocryphal story can rally people, which tells you something about how thin the membrane is between leadership and narrative.

Every leader is a curator of stories whether they realize it or not. The buildings you choose to put your team in. The logos on the laptops. The all hands rituals. The way someone’s departure is talked about, or not talked about. Every one of these is a fragment of a story that your team is reading, even when you are not consciously writing it. The risk is that if leaders do not author the story, someone else will. Usually badly. In the absence of a coherent narrative from the top, every team writes its own, and they do not agree with each other, and the disagreements show up as politics, which is what we usually call story conflict when we are too tired to name it correctly.

A caveat worth keeping

Not every story is worth telling. The history of leadership is also a history of dangerous narratives. Nationalist myths. Demagogue arcs. The manipulative “us against them” that has been used to sell every cruelty humans have ever talked themselves into. Story is a tool. Like all tools, it has no ethics of its own.

So the question is not whether a leader is telling stories. They are, always, including the leaders who insist they are just dealing with the facts. The question is whether the stories are true, whether they are generative, and whether they are worthy of the people being asked to live inside them. Those are different tests, and a story can pass one and fail the others. A leader’s job is to keep checking all three.

Tell them about the dream

Here is what I want you to do this week. Ask yourself what story your team is telling itself about who they are. Not the mission statement on the wall. Not the OKRs in the deck. The actual story your people would tell each other if you were not in the room. The version that gets told over a beer after the offsite, or in the side channel during the boring part of the meeting.

If you do not know the answer, your team is writing one without you, and it may not be the one you would have written. If you do know the answer and you do not like it, you have a chance to change it. Not with another deck. Not with a memo. Not with a values poster in the break room. With a story. The kind that someone could repeat to a new hire on their first day and have it land.

Somewhere on your team there is someone waiting for you to set the prepared text aside and tell them about the dream. The only question that matters is whether you have one to tell.

Subscribe now

Share

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