PDF Summary:The Octopus Organization, by Phil Le-Brun and Jana Werner

Machines are rigid, hollow, and dependent on outside direction—and if you’ve worked in a large organization, you’ve probably been a cog in one. Amazon strategists Phil Le-Brun and Jana Werner argue that most companies are still designed this way: built for a world of standardization and control that no longer reflects how work actually gets done. Their alternative is inspired by the octopus—a creature that adapts continuously through distributed intelligence rather than central command. The Octopus Organization identifies the specific habits that keep companies stuck and gives any leader, at any level, a practical place to start changing.

In this guide, we’ll explore Le-Brun and Werner’s insights into what an Octopus Organization is, the structural pillars that support it, and an approach to cultivating one through small experiments, continuous learning, and a new model of leadership. We’ll also draw on military history, behavioral neuroscience, and computer science to deepen your understanding of the authors’ principles.

(continued)...

Ownership

Ownership, the second quality of an Octopus Organization, means having genuine agency over your work—the ability to make real decisions, take initiative, and be accountable for outcomes, not just to execute a predefined task. Le-Brun and Werner argue that this is the natural human state. Children don’t need to be encouraged to explore, take initiative, or claim mastery over their environment. What organizations manage to do, often without realizing it, is train that instinct out of people.

The most fundamental barrier to ownership is the fear that speaking up will cost you something. You can spot this in meetings where people wait to see which way the most senior person is leaning before sharing their own view, raising concerns only afterward in the hallway. Le-Brun and Werner note that this happens even when leaders invite candor, because people’s experience has taught them what typically happens when someone states an uncomfortable truth. Building ownership requires creating conditions where people believe that speaking up won’t put their reputation or job at risk. Leaders do this by admitting what they don’t know, treating mistakes as material for learning, and demonstrating that they want to hear bad news.

Ownership Is a Brain-State Problem

There’s a neurological reason why you can’t just instruct people to take more ownership or assure them that you really want to hear their ideas. Research on motivation identifies autonomy, a sense of genuine agency over your work, as a basic need. Without it, initiative drops, engagement fades, and psychological health suffers. The most common ways workplaces undercut autonomy—such as by evaluating people and enforcing hierarchy—are conditions the brain registers as social threats, which it can’t distinguish from physical danger. Both trigger the same defensive response, which crowds out the sort of thinking that ownership requires.

This means the problem may not primarily be one of attitude or incentives. Instead, the ordinary features of hierarchical work environments—like who speaks first in meetings, who evaluates whom, and whether raising a concern feels safe—keep many people’s brains occupied with managing social risk rather than engaging in the cognitively demanding thinking that taking ownership of your work requires. Therefore, the behaviors Le-Brun and Werner recommend (admitting uncertainty, treating mistakes as learning material, and going first in taking risks) may work not as signals of cultural values, but as cues that a social threat has passed and the brain can dedicate its resources to other cognitive tasks.

A second, more structural barrier is the proliferation of approval processes. In most organizations, blocking a decision carries less personal risk than approving one, which creates an incentive for cautious behavior that slows everything down. Le-Brun and Werner describe an insurance company whose promising new product feature was reviewed by legal, marketing, security, and the CEO before stalling entirely, while a competitor launched first. The fix isn’t to abandon oversight, but to be judicious about whether you need gates (checkpoints where someone can simply say no) or guardrails (boundaries that define what teams are free to do without asking permission).

Perhaps the most important question ownership raises is a simple one: Does anyone actually own this outcome, not as a task or a section of a presentation, but the result itself? Le-Brun and Werner argue that most organizations have plenty of people attending meetings, offering input, and providing partial approvals without designating anyone who is fully, personally accountable for making something happen. They call the people who would fill this role “single-threaded leaders”—individuals with genuine decision-making authority, a clear remit, and a real stake in the result. Creating a culture of ownership in an Octopus Organization means designing roles so that accountability is genuine, not merely declared.

Gates, Guardrails, and the Question of Reversibility

The case against excessive approval processes isn’t a case against oversight, but against oversight that’s disconnected from what it would cost you to be wrong. Jeff Bezos made this point in Amazon’s 2015 shareholder letter in which he noted that as companies grow, they tend to route every decision through their most expensive approval process, even decisions that could easily be reversed if needed. This suggests that a useful diagnostic for how much oversight is needed isn’t how significant a decision feels, but how easily it could be undone. If a decision is reversible, handing people a clear principle (what Le-Brun and Werner call a “guardrail”) and trusting them to apply it is a better choice than putting up a “gate.”

When a decision can’t be reversed, the real question might not be whether you need a gate or a guardrail, but who should own the task. Karl Weick and Kathleen Sutcliffe spent years studying exceptionally high-stakes work environments—nuclear aircraft carriers, air traffic control systems, nuclear power plants—and found that they tend to resist the impulse to push irreversible decisions up the org chart. In routine operations, procedure governs. But when something unexpected happens, authority moves to whoever has the most direct knowledge of what’s occurring, regardless of rank. That isn’t a gate, and it isn’t quite a guardrail: It’s a system to ensure that the most crucial decisions are made where the greatest understanding is.

Curiosity

Curiosity, the third quality of Octopus Organizations, is the drive to ask questions, test assumptions, and update your understanding of what’s true, even when the answers are inconvenient. It’s what allows an organization to keep learning as its environment changes, rather than doubling down on what used to work. Le-Brun and Werner argue that organizations talk about valuing curiosity more often than they reward it. Research cited in the book found that twice as many organizations claim to cultivate a culture of curiosity as actually practice one—the gap between what organizations say and what they incentivize tends to be widest exactly where curiosity matters most.

The clearest example is how organizations handle failure. When failure is treated as something to be hidden or survived rather than examined, teams do exactly what you’d expect—they prop up failing projects, obscure setbacks from leadership, and avoid running experiments that might produce the wrong answer. The result is that organizations accumulate large, expensive failures rather than small, informative ones. Octopus Organizations change this by framing initiatives as experiments where the goal isn’t to succeed on the first try, but to learn something true as quickly and cheaply as possible.

(Shortform note: The shift Le-Brun and Werner describe—from protecting failing projects to learning from them—depends on a design decision that’s easy to overlook: A useful experiment has to be capable of failing. In The Lean Startup, Eric Ries argues that a hypothesis only earns the name if it makes specific, observable predictions— predictions that could turn out to be wrong. An experiment designed to confirm what you already believe isn’t an experiment; it’s confirmation bias with extra steps, and it produces the same large, expensive failures as no experiment at all. Under Ries’s framework, a negative result isn’t failure—it’s data. It tells you something true about your assumptions before you’ve committed further resources.)

Curiosity also demands something counterintuitive—the willingness to tackle the hardest and most uncertain part of a project first. A founder who spends her first year perfecting a product before testing whether anyone will pay for it has done the easier thing before the essential one. She skipped the question she needed to answer first—“Will anyone want this, and at this price?” Le-Brun and Werner describe this as a common failure: Teams gravitate toward tasks they already know how to do, building the impressive and visible parts of a project, while deferring the test that would reveal whether the whole thing is worthwhile. Octopus Organizations counter this by identifying the riskiest assumption in any project and testing it first.

Amazon formalizes this through a practice called “Working Backwards.” Before committing resources to building anything, teams write a mock press release describing the finished product as if it already exists. The exercise forces clarity about who the product is for, what problem it solves, and why a customer would care. This kind of distributed curiosity is also what produces genuine innovation. Many organizations miss the connection, treating innovation as a dedicated function confined to a lab, assigned to particular people, or subject to a formal process. By designating specific people to innovate on behalf of everyone else, they inadvertently communicate that the job of most employees is execution, not exploration.

Why You Need to Ask the Hard Question Before You’re Invested in the Answer

When you work on the comfortable parts of a project first, that creates momentum, and momentum makes the harder questions about your initial assumptions feel more threatening to ask—and more like a verdict on everything you’ve already invested. Both Amazon’s “Working Backwards” practice and Le-Brun and Werner’s advice to challenge the riskiest assumption first are designed to prevent this problem: They force you to tackle what you’re most uncertain about before you have anything to protect.

Teams at NASA have a similar process for embracing uncertainty early in a project. Before engineers begin designing a spacecraft, the people who will operate the mission are asked to write out what a successful mission looks like—not to provide engineering specs, but to give a plain account of what needs to happen from launch through every stage of the mission until it achieves its objective. The idea is that if the engineers can’t yet describe what success looks like from the perspective of the person doing the work, they shouldn’t start building toward it.

Ozan Varol explains in Think Like a Rocket Scientist that NASA applies the same principle once a spacecraft is built, too. Rather than building a spacecraft and hoping it survives conditions in space, engineers put the hardware through those conditions—vacuum, thermal extremes, the violence of launch—before anything leaves the ground. The goal is to find out what breaks while breaking it is still a solvable problem. This is why both practices enable more innovative design: When you know that failure will be caught early and cheaply (rather than causing catastrophe), you can create and test more ambitious ideas.

Le-Brun and Werner argue that innovation labs consistently disappoint because they structurally separate innovation from the everyday customer observations that drive it. Amazon Prime began out of one engineer’s observation about how customers were experiencing shipping, not as a strategic initiative. It emerged because someone close to the work was paying attention and had the space to act on what they noticed. Creating an organization that values curiosity means giving everyone the tools and permission to surface problems, test ideas, and make improvements, because that’s where most of the best ideas actually come from.

(Shortform note: Some experts suggest that innovation labs fail not because separating them from other parts of the business is wrong, but because separation without communication is a dead end. In Loonshots, Safi Bahcall calls this “the PARC trap” after Xerox’s Palo Alto Research Center, which developed innovations that went on to define modern computing—none of which Xerox brought to market. The distance between the lab and the core business wasn’t the problem; it was that there was no feedback loop to connect them. This suggests that a dedicated innovation team can work, but only if it’s actively paired with exchange between the people developing ideas and the people closest to customers.)

How to Start Becoming an Octopus Organization

Having mapped the territory of what blocks clarity, ownership, and curiosity, Le-Brun and Werner turn to the practical question of where to begin. Their answer is designed to avoid the trap that dooms most transformation efforts: applying the same rigid, top-down approach to the problem of being too rigid and top-down. Their method for making change is intended for anyone with influence over how work gets done—not only senior executives, but team leaders, middle managers, and anyone who can surface a problem and propose a small experiment. The scope of the change should match the scope of your influence, and it can grow from there.

How to Start Change When You’re Not in Charge

Le-Brun and Werner make a point of saying the Octopus journey doesn’t belong exclusively to executives—that anyone with influence over how work gets done can start. Two bodies of research offer guidance on what that looks like in practice. In Switch, Chip and Dan Heath suggest identifying what they call “bright spots”: places in your organization where the behavior you want is already happening. The team that runs effective meetings, the manager whose people speak freely—these are experiments that have succeeded, and studying them may be more powerful than proposing something new, because solutions that originate from within tend to be trusted in a way that imported frameworks simply aren’t.

The harder work comes when you’re ready to push a change beyond your immediate team, and here Adam Grant’s Originals adds a note of realism: Making change from a nonexecutive position depends on how much credibility you’ve accumulated. People who push for unconventional ideas before they’ve established a track record are often resented—what Grant calls “idiosyncrasy credits” have to be earned before they can be spent. His advice is to resist the urge to project confidence: Acknowledging uncertainty and naming the potential weaknesses in your proposal can lower people’s defenses and make them more receptive to unconventional ideas.

As we noted earlier, Le-Brun and Werner catalogue 36 specific negative patterns that undercut clarity, ownership, and curiosity. Most organizations will recognize themselves in many of them, but the starting point isn’t to make an exhaustive plan to fix them all. It’s enough to identify one that generates the most recognition or frustration and begin there. Counterintuitively, the goal isn’t to complete a transformation and arrive at a finished Octopus Organization. Even the most adaptive companies have to fight against drifting back toward these traditional patterns as they grow. What changes is an organization’s ability to spot them early and act.

Old Habits Don’t Disappear—They Wait

There’s a reason even the most adaptive organizations have to fight against drift: Old patterns don’t disappear; they just go dormant. In The Power of Habit, Charles Duhigg notes that organizational routines accumulate from individual decisions until they become so embedded that people follow them without knowing why. When deliberate effort relaxes—such as under pressure or busyness—familiar defaults reassert themselves. The force driving this at the individual level is the brain’s instinct to conserve energy: Each person defaults to what they already know how to do, and maintaining new routines demands conscious effort. Attempting too many changes at once tends to fail because the cognitive effort required is too much.

James Clear’s Atomic Habits identifies when reversion is most likely to occur: during the interval between starting new behaviors and before they’ve produced any visible results. Clear calls this the “plateau of latent potential” and describes it as a gap when change looks like it isn’t working but is quietly building toward a breakthrough. It’s this moment when organizations are most likely to declare an experiment unsuccessful and revert. The plateau is predictable. Knowing it’s coming—and that the curve will turn upward—is one of the most practically useful things to understand before you begin.

The authors frame the ongoing work of changing how an organization operates around three principles: Make changes with people rather than imposing them from above; ensure that every change produces real value and learning, not just activity; and do less to achieve more—subtract friction and remove what isn’t working rather than layering new programs on top of old ones. These principles run through each of the specific approaches that follow—shaping how experiments get designed, how successful practices travel through organizations, and what effective leadership looks like in practice.

(Shortform note: What you learn from an experiment depends on how well it was designed. In The Lean Startup, Eric Ries notes that many experiments take measurements that aren’t tied to a specific prediction—they tell you that something moved, but not whether your change caused it. A well-designed experiment, on the other hand, specifies what you’d expect to see if the change works, which is why it’s informative regardless of outcome. This sharpens the case for “do less”: If you change five things and performance improves, you don’t know which change made the difference. The case for designing change with people rather than on them works the same way, because the people closest to a problem can design more informative experiments.)

Start with the Learning Loop

Once you’ve identified a negative pattern that’s pervasive at your organization—one that makes people roll their eyes in meetings, or raises concerns only in the hallway afterward—Le-Brun and Werner recommend a simple approach. Form a hypothesis about what’s causing the problem and what small change might address it. Then run an experiment to try the change in a limited context, over a short period, with a clear sense of what you’re testing. Experiments can take many forms: stopping something that isn’t working, modifying an existing process, or piloting something new entirely. Keep it small enough that failure is survivable and fast enough that learning is timely.

The step most organizations skip is reflecting carefully on the experiment’s results. The most tempting conclusions are also the least useful—“The experiment worked, so let’s roll it out everywhere,” or “The experiment failed, so let’s never try that again.” Both miss something more important: Why did the experiment produce the result it did, and what does that reveal about how the organization actually functions? Le-Brun and Werner describe this deeper reflection as the difference between correcting a symptom and beginning to understand the system.

What the Learning Loop Actually Requires

Both steps in Le-Brun and Werner’s learning loop are harder than they look, and each fails in a predictable way.

The first failure happens when forming the hypothesis. Most organizational hypotheses are too vague to be informative. Just as Reis notes in The Lean Startup, philosopher of science Karl Popper argues that a hypothesis has to be falsifiable—it can be tested and proven wrong—and must be specific enough that a negative result counts as evidence against it. This means designing tests with the goal of disproving your hypothesis, not confirming it. An experiment meets this standard when it specifies exactly what you’d expect to see if the change worked: Only a hypothesis that can be proven wrong will teach you something if it’s proven right.

The second failure happens at the reflection stage. In The Fifth Discipline, Peter Senge calls the assumptions encoded in a hypothesis “mental models”—the closely held beliefs about how things work that shape how we interpret any result we see. Organizations tend to protect these models from examination. When an experiment produces a surprising result, the easier move is to attribute it to external circumstances—the timing was off, the sample was too small—rather than to ask whether the underlying assumption was wrong in the first place. That’s why the reflection step Le-Brun and Werner describe isn’t really analysis: It’s self-examination, which is a harder thing to ask of an organization.

As you design your hypothesis and experiment, it’s also worth thinking about what kind of change you’re trying to make. Drawing on the work of systems thinker Donella Meadows, Le-Brun and Werner identify three levels of intervention. The shallowest are quick adjustments to an existing process, which produce immediate results but don’t alter underlying dynamics. Deeper changes reshape how information flows; they’re harder to implement, but more durable. The most powerful interventions shift shared assumptions: what a team believes about how decisions should be made, or what good leadership actually looks like. These changes are often simple to articulate but take time to become habits, and they tend to be the ones that last.

What Each Level of Change Actually Creates

The three levels of intervention differ in how they affect an organization’s capacity to handle disruption, and in Antifragile, Nassim Nicholas Taleb explains why. He distinguishes between systems that break under stress (fragile), those that survive it (robust), and those that get stronger from it (antifragile). Le-Brun and Werner’s intervention levels correspond to these outcomes. Shallow tweaks optimize an organization for its current conditions, which makes it more fragile: A tightly tuned system lacks the slack to adapt as conditions shift. Deeper changes—ones that shift how feedback moves, how quickly problems surface, and what patterns trigger responses—build robustness, giving the system a wider operating range.

Major shifts in the assumptions built into an organization have the potential to make it genuinely antifragile—the organization doesn’t merely tolerate disruption but learns from it, treating uncertainty as information rather than something to be managed away. Seen this way, the Octopus Organization is structured to get stronger from the same shocks that would break a traditionally managed one. One caveat Taleb notes is that antifragility requires manageable, recoverable doses of stress. An organization asked to absorb too much change too quickly doesn’t become antifragile—it breaks. The prescription to keep experiments small and survivable isn’t just organizational caution; it’s a condition for learning itself.

Spread, Don’t Scale

When an experiment succeeds, the natural impulse is to scale it—to push it across the organization through a top-down mandate. Le-Brun and Werner argue that you should resist this instinct. Scaling strips a solution of its local context, removes ownership from anyone who didn’t participate in developing it, and treats specific insights as universal prescriptions. What works for one team may not translate directly to another, and mandating adoption tends to produce compliance without genuine understanding. The alternative is what the authors call “spreading”—creating conditions for good practices to travel organically, pulled from team to team because they demonstrably solve real problems.

For example, an early Amazon developer, frustrated with a cumbersome image-management system, built a better one on his own initiative. Other teams noticed and adopted it without any mandate, and eventually someone built an international version. Le-Brun and Werner offer this as a model of spreading in action—the idea traveled because it worked, not because someone told people to use it.

Why Good Ideas Don’t Necessarily Spread Themselves

The concept of spreading originates in Aaron Dignan’s Brave New Work, which explains why mandated changes tend to fail. When people adopt a practice because they were told to, they have no stake in whether it actually works. When they adopt it because it solves a real problem, they own it—and that ownership makes change durable. But what does it actually take for a practice to travel organically? Malcolm Gladwell’s The Tipping Point suggests that what matters most is the power of context: whether the environment makes people receptive to change, more so than the quality of the idea or finding the right champion for it.

In Le-Brun and Werner’s Amazon example, all the right contextual conditions happened to be present: The old system’s failure was visible, the new solution was immediately observable in practice, and the culture gave developers permission to use it without waiting on permission or a mandate from above. But in organizations where those conditions are absent—where teams are siloed, problems are invisible to potential adopters, or trying something new requires approval—even a genuinely better practice may not spread on its own. Creating that receptivity to change is itself an active part of the Octopus leader’s work.

Shift How You See Leadership

All of this requires a corresponding shift in how leaders understand their own roles. In the Octopus Organization model, their primary job isn’t to direct the work but to improve the conditions in which others can do their best work—asking more questions than you answer, making it genuinely safe for people to surface problems, and actively removing the friction that slows teams down. Le-Brun and Werner describe this as working on the system rather than in it.

They explain that Reed Hastings illustrated this distinction as CEO of Netflix by eliminating the company’s formal vacation policy. Instead of handling time-off requests one by one, he changed the environment, replacing a bureaucratic process with a single principle—act in Netflix’s best interests. Employees still managed their schedules with their teams in mind, but the whole apparatus of tracking, requesting, and approving leave had been removed. The goal of the Octopus leader, Le-Brun and Werner argue, is ultimately to make the organization function so well that it no longer depends on the kind of direction most leaders were trained to provide.

Why Building an Organization That Doesn’t Need You Is So Hard

The leadership shift Le-Brun and Werner describe—from directing work to improving the conditions for it—requires leaders to pursue a goal most of their career incentives punish: building systems and people that will thrive without their direction. (There’s rarely a career reward for making yourself unnecessary.) In Turn the Ship Around!, L. David Marquet explains that in most organizations, when performance drops after a strong leader departs, the organization concludes the leader was indispensable rather than that they’d failed to build anything lasting. Replacing a policy with a principle—as Hastings did with Netflix’s vacation tracking—is one mechanism for doing this.

But why does a principle outperform a more comprehensive rulebook? In Algorithms to Live By, Brian Christian and Tom Griffiths describe a problem called “overfitting,” when a model is so precisely calibrated to known scenarios that it fails when reality throws something new at it. A rulebook is this kind of model, but a principle works better because it forces people to use their judgment rather than deferring to rules. One caveat, though: As No Rules Rules notes, Hastings abolished Netflix’s vacation policy only after building an unusually high-trust culture, and even then, managers had to coach people on how to use their new freedom. A principle only works when the organization is already capable of using the judgment it demands.