Distributed Leadership: Definition and Examples

Most conversations about leadership start with a person: their traits, their style, their track record. Distributed leadership starts somewhere else. It starts with the observation that in most organizations that actually function well, leadership was never living in one person to begin with. It moved through the team: the engineer who called the outage before anyone with a title knew, the nurse who flagged the drug interaction, the maintainer who merged the pull request because they understood the codebase better than anyone with authority over it. Distributed leadership is the framework that names what was already happening and asks how to do it on purpose instead of by accident.

What is distributed leadership?

Distributed leadership is the idea that leadership is a property of the system, not a trait of one person. Instead of asking "who is the leader," a distributed lens asks "how does leadership practice get accomplished across this group of people, their tools, and their routines." The unit of analysis shifts from an individual to the interactions between people.

The framing comes out of education research from the early 2000s. James Spillane, working with Richard Halverson and John Diamond at Northwestern, argued that school leadership is "best understood as a distributed practice, stretched over the school's social and situational contexts," where leadership practice takes shape through the interactions of leaders, followers, and aspects of the situation itself (routines, schedules, data systems), not through any one person's actions alone. Around the same time, Peter Gronn described leadership as a form of "concertive action": something that arises when people work in concert on a shared activity, rather than something that resides in a single role. Alma Harris, who studied distributed leadership's link to school improvement, put it plainly: it "equates with shared, collective and extended leadership practice that builds the capacity for change and improvement," and works as "leadership by expertise" rather than leadership by title or tenure.

The idea crossed into business and organizational-behavior research a few years later, largely through Craig Pearce and Jay Conger's edited volume on shared leadership, which examined how teams perform when the leadership function rotates to whoever has the relevant expertise for a given task, instead of defaulting to the person with the manager title. That's a related but distinct idea, and the difference matters enough that it gets its own section below.

Key Facts: Distributed Leadership

• Alma Harris describes distributed leadership as practice built on "high levels of trust, transparency and mutual respect," functioning as "leadership by expertise" rather than leadership by role. Source: Teacher Magazine
• Aviation formalized a version of distributed leadership after a June 1979 NASA workshop, "Resource Management on the Flight Deck," chaired by John Lauber at Ames Research Center. NASA reports that the research behind it "showed that subordinates regularly hesitated to correct their supervisors out of a traditional, but sometimes dangerous, respect for authority," and the resulting crew resource management training made it every crew member's job to "articulate a discrepancy." Source: NASA Spinoff
• The Incident Command System, the standard structure US emergency response uses today, is a product of FIRESCOPE ("FIrefighting RESources of California Organized for Potential Emergencies"), formed by the State of California, Cal OES and local fire departments after the deadly Southern California wildfires of 1970, and later used as the model for the National Incident Management System. Source: California Governor's Office of Emergency Services
• When Python's creator, Guido van Rossum, stepped down as the language's "Benevolent Dictator for Life" in July 2018, the project replaced a single decision-maker with a five-person elected steering council rather than naming a successor. Source: PEP 13, Python Software Foundation
• After Zappos moved to holacracy in 2015, about 18% of the workforce, roughly 260 people, left within a year, a reminder that distributing leadership badly carries a real cost. Source: Fortune

Distributed vs shared vs participative vs delegated vs laissez-faire

This is the section that actually clears up the confusion, because these five terms get used almost interchangeably and they describe genuinely different things.

The line that matters most: participative leadership is a process a leader chooses; distributed leadership is a structural fact about how the organization already works. A participative leader can be the most consultative person in the building and still be the sole point of authority. Distributed leadership describes organizations where that single point of authority doesn't exist, by design or by accumulated practice, and decisions get made at the point of expertise instead of routing to one desk.

The line against delegated leadership is just as sharp, and it's the one people get wrong most often. Delegating a task keeps the manager as the accountable party; they handed out work, not authority, and they can reclaim it whenever they want. Distributing leadership means the authority actually moved. If a team lead can override the decision whenever they feel like it, the org hasn't distributed leadership: it has just distributed labor.

Democratic leadership shares distributed leadership's discomfort with concentrated authority, but it solves it differently: through voting and group consensus on a given decision, rather than through routing different decisions to different points of expertise. And laissez-faire leadership is the one distributed leadership gets confused with most unfairly. Laissez-faire is the absence of leadership activity. Distributed leadership, done well, actually requires more active design work than a single strong manager does, because someone has to build the routines, information flows, and named ownership that make dispersed authority function instead of collapsing into nobody being in charge.

What actually gets distributed

"Distributing leadership" is vague until you name what's actually moving. Five things, specifically:

That last row names the most common failed version of this whole idea: an organization distributes the work (more people get pulled into decisions, more meetings, more input requested) without distributing the authority (who can actually say yes, and who answers when it goes wrong). That combination produces the worst of both worlds: slower decisions and unclear accountability, with none of the speed or ownership benefits a genuinely distributed structure is supposed to deliver. Types of power in leadership is worth reading alongside this table, because distributed leadership only works when expert power and referent power are allowed to outweigh pure positional power in the moment that matters.

Where the model fits and where it doesn't

Where distributed leadership works

Knowledge work where the manager isn't the deepest expert in the room. A platform team's most senior engineer usually knows the failure modes of the system better than their manager does. Distributed leadership routes the technical call to that person, with the manager still owning people decisions, budget, and prioritization.

Cross-functional problems that touch multiple domains at once. A pricing change that involves finance, sales, legal, and product doesn't have a natural single owner. Distributed leadership lets each function's expert lead the piece they actually understand, instead of forcing one person to become a shallow expert in all four.

Incident response. The person closest to a live failure, an outage, a safety event, a clinical emergency, usually needs to act in seconds, not after a call gets escalated up a chain. This is why aviation and emergency response both formalized versions of distributed authority decades ago; the cost of waiting for the "real" decision-maker is measured in lives, not just delay.

Organizations too large or too fast for one decision-maker to be the bottleneck. Once a company crosses a certain headcount or decision volume, a single approver becomes a queue, whether or not they're a good leader. Managing at scale increasingly means designing who can decide what without you, not just working longer hours yourself.

Teams whose expertise genuinely exceeds the manager's. This overlaps with the first point but deserves its own line: distributed leadership isn't really optional once a team's technical or domain knowledge has outpaced the manager's ability to evaluate their work in detail. At that point the manager's real job becomes building the structure that lets expertise lead, not protecting a decision-making role they can no longer fill well.

Where distributed leadership fails

Unclear accountability. If a bad outcome can't be traced to a named decision-maker, the org has diffused responsibility along with authority. That's not a distributed system: it's a system nobody actually runs.

Decisions with no owner. The mirror image of the above. A decision that everyone had input into and nobody was assigned to make just doesn't get made, or gets made by whoever happens to speak last in the meeting.

Crisis conditions that need a single voice. Even the most distributed structures usually collapse to one decision-maker during an acute crisis, on purpose. The Incident Command System is instructive here: it distributes leadership across specialized roles and, in multi-agency events, across a unified command of several agency leads, but it still enforces "unity of command," meaning every person in the structure reports to exactly one supervisor at a time. Distributed does not mean nobody is in charge of anything; it means the org has been deliberate about who is in charge of what.

Low-trust or low-capability teams. Distributing decision rights to people who don't yet have the judgment or the standing to use them well doesn't produce better decisions, it produces inconsistent ones. Distributed leadership assumes a floor of psychological safety and competence that has to be built before authority gets pushed outward, not after.

Leaders using it as cover for absence. This is the least discussed failure mode and possibly the most common one. "We're a flat, distributed team" can be a genuine structural choice, or it can be what a disengaged or toxic leader says instead of doing the harder work of building real decision structure. The tell is simple: in a genuinely distributed org, someone can always answer "who decided this and who owns the outcome." In a leadership vacuum dressed up as distribution, nobody can.

Real examples

Aviation crew resource management. After the 1978 crash of United Airlines Flight 173, where the captain fixated on a landing-gear problem while the crew's fuel warnings went unheeded, the industry built formal training to push authority and voice outward across the whole cockpit and cabin crew, not just the captain's seat. NASA ran a founding workshop in 1980, United Airlines launched the first full program in 1981, and the model spread globally through the 1990s. It's one of the clearest cases of an industry distributing leadership deliberately because the old, single-authority model was getting people killed.

Incident command structures. Emergency response in the US runs on the Incident Command System, born out of the FIRESCOPE program after coordination failures during 1970s California wildfires. It distributes command across specialized sections (operations, planning, logistics, finance) and, for events spanning multiple agencies, across a unified command that shares authority among agency leads who still act as a single decision-making entity. It's a designed system for distributing leadership without losing unity of command.

Open-source project maintainership. When Guido van Rossum stepped down as Python's "Benevolent Dictator for Life" in July 2018, the project didn't crown a successor. It adopted a five-person elected steering council with defined terms and no permanent seats, formalized in PEP 13. Authority that used to sit with one person now sits with a small, rotating group, plus a broader core team that votes on membership. It's a rare case of an organization distributing leadership through a written constitution instead of informal habit.

School leadership teams. This is where the modern academic literature started. Alma Harris's research links schools that spread leadership practice across department heads, lead teachers, and administrators, not just the principal's office, to stronger capacity for sustained improvement. The mechanism isn't mysterious: more people with real authority over their piece of the work means more people building the judgment to improve it.

The honest complication: Zappos and holacracy. Zappos is the example that gets cited constantly and understood the least. In 2013 the company adopted holacracy, a formal system that replaced managers with overlapping, self-organizing "circles." It's frequently held up as either a triumphant proof of concept or a total failure, and neither framing survives contact with what actually happened. In March 2015, Tony Hsieh offered severance to anyone who didn't want to work under the new system; roughly 14% of the 1,500-person workforce took it immediately, and by the following January, 18%, about 260 people, had left in total. That's a real cost, not a footnote. But later research into the rollout also found the company adapted holacracy's rules substantially over time rather than running it as originally announced, gaining faster structural adaptation and clearer accountabilities in some areas while genuinely struggling with complexity overload in others. The honest read isn't "distributed leadership failed at Zappos." It's that a hard, sudden structural change has real transition costs, and the media's binary storyline (revolutionary or failed) was never a good fit for what was actually a messy, partial, ongoing experiment.

How to move toward it without creating a vacuum

Step 1: Name the decision rights explicitly, not just the tasks

Handing someone a task without naming what they can actually decide inside it isn't distribution, it's an assignment with extra confusion attached. Write down, in plain language, what this person or role can approve without checking with you.

Step 2: Distribute information before you distribute the work

People make bad calls with real authority and no context just as often as they make bad calls with good context and no authority. If you want someone to own a decision, make sure they see the data, the history, and the constraints you'd have used to make it yourself.

Step 3: Let expertise outrank title, and say so out loud

If the most junior person in the room understands the failure mode best, that person's read should carry more weight in that specific call. This has to be stated as policy, not assumed, because default org behavior pulls the other way.

Step 4: Keep exactly one named owner per outcome

Distributing input is easy and mostly harmless. Distributing accountability without a named owner is where the model breaks. Every meaningful decision needs one name attached to it, even in the most distributed structure you can build.

Step 5: Build a deliberate way to re-centralize under pressure

Decide in advance what triggers a return to single-point decision-making: a live incident, a legal exposure, a values conflict that can't be resolved at the working level. The Tannenbaum-Schmidt Leadership Continuum is a useful map for this, because it treats the control-versus-delegation choice as something a leader recalibrates by situation, not a single setting they pick once.

Step 6: Watch for the teams borrowing this language for the wrong reason

Self-organizing structures show up honestly in agile leadership, where cross-functional squads are trusted to make delivery calls without escalating every sprint decision upward. They show up dishonestly when "the team decides" is really just nobody deciding. Both use the same words. The difference is whether you can still answer who owns the outcome.

Distributed leadership rewards organizations that are honest about where authority actually sits, and does real damage to the ones that use the language to avoid building any structure at all. Name the decision rights, not just the tasks. Keep one owner per outcome. And when the moment calls for a single voice, know in advance who that voice belongs to.