Reflections from host Sarah Olivieri ... Why Distributed Leadership Fails (And What Actually Makes It Work) Most nonprofit leaders I talk to already know they can't make every decision themselves. They've read the books. They've heard the term "distributed leadership." They've said out loud, in strategy meetings and board retreats, that they want more decisions happening closer to the people doing the work. And then, a year later, they're still the bottleneck. The story I hear is almost always the same. "I told my team they had authority. I told them I trusted them. But nothing changed. Decisions still come to me." What looks like a resistance problem is actually a systems problem. Distributed leadership is being announced instead of built. The word gets used. The system underneath it does not exist. When the system doesn't exist, people keep doing what the old system taught them to do. They ask permission. They wait for the meeting. They send the email up the chain. Not because they don't want authority. Because nothing around them has been redesigned to make holding that authority a real, workable practice. The Difference Between Declaring And Building A pattern I see over and over: a CEO decides the organization is going to be less hierarchical. They restructure the org chart. They rename departments. They talk about it in the all-staff. And then, six months in, nothing has actually shifted. The org chart is new. The meeting agendas are the same, the decision paths are the same, and the CEO is still the person everyone routes to. The chart got redrawn on top of an unchanged system. This is the structural piece that gets missed. An org chart tells you who is in charge of who. It doesn't tell you what actually needs to get done in the organization or who is accountable for making sure it does. And it doesn't touch the two places where the old hierarchy actually lives, which are meetings and decisions. Until those change, you've made a values statement. You haven't built a system. Trade The Org Chart For A Functions Chart The first piece of the redesign is the one leaders skip most often, because it looks like a semantic move and it isn't. Stop leading with an org chart. Build a functions chart. An org chart is about who is in charge of who. It's a picture of hierarchy. And a hierarchical leadership system, by design, consolidates power by concentrating decision-making. Using an org chart is literally a system that moves you in the opposite direction of distributed decision-making. A functions chart, which is the shape of the Leadership Blueprint I've developed with clients, is about what actually needs to get done in the organization and who is accountable for making sure it does. Instead of boxes for roles under other roles, you have named functions, each tied to a specific outcome, each with one person accountable for that outcome getting produced. That single move changes everything downstream. Now people aren't waiting to be told what to do by the person above them. They're accountable for an outcome, and they hold the decisions required to produce it. Distributed leadership stops being an aspiration. It becomes the actual design. One line from my conversation with Jocelyn Wyatt, CEO of Alight, has stayed with me: "I both could hold distributed leadership, but then also had to teach distributed leadership to sort of the next level and the next level and the next level." What I appreciate about this framing is that it explains the mechanism. Once the functions chart is in place and each function has a clearly accountable owner, the work at each layer is to run distributed leadership inside their piece of the chart. That's a system carrying the practice, not a value statement trying to. Rework The Meetings The second piece is meetings. This is the piece I see leaders underestimate the most, and it is where command-and-control reinstalls itself no matter what the org chart says. Meeting agendas are a system. They reinforce whatever model is baked into them. If your leadership team meeting agenda is a series of updates rolling up to you, followed by decisions the group is asking you to make, you are running a command-and-control meeting. It doesn't matter what you call the meeting or what values you name at the top of it. The structure produces the behavior. A meeting designed to reinforce distributed leadership looks different. The agenda is structured around identifying where things are going right and where things are going wrong, and giving each outcome owner the chance to receive support from the rest of the group. Not approval from everyone. Not approval from any one person. Support. The group's job is to be useful to that owner, not to sign off on their work. That one shift, done consistently, changes how the whole organization behaves inside a quarter. People stop bringing their decisions to meetings for permission. They start bringing them for input, and the input goes back with them. Let People Volunteer Into The Outcomes They'll Own The third piece is how outcomes actually get owned, and this is the part most leaders get backwards Distributing decision-making is essentially the same thing as delegating outcomes. The person in a heads role is accountable for an outcome that sits outside their direct control. They can't personally make every donation come in, or every program hit its mark, or every partnership hold. But they own whether it happens. They decide what changes, what scales, what gets paused, what gets killed. The traditional way to fill those roles is assignment. The CEO and one or two senior leaders sit in a closed room and decide who gets promoted, who gets moved, who gets the new accountability. That model has two problems. It's bad for innovation, because people don't do their best thinking when they feel like they need a supervisor's approval for their next move. And it's bad for equity, because every layer of subjective human assessment lets inherited bias operate. The better move is to make the Leadership Blueprint visible to the whole team and let people volunteer into the heads roles they want to grow toward. The map shows every function, every outcome, and who currently owns each one. In front of the team, you ask: Where does the organization need to grow next? Who's ready for a heads role they've never held? Who wants to add a heads accountability on top of what they're already carrying? That's not chaos. It's not a free-for-all. It's a shift in the question. Instead of "what does my manager think of my work this quarter," the question becomes "where does this organization need to grow next, and where do I want to be standing when it does?" When someone volunteers into an outcome, the accountability lands differently. They chose it. They saw the map, understood the gap, and stepped forward. That's a very different starting point than being told what you're now responsible for. Ownership behaves differently when it's chosen than when it's assigned. The closed-door version of advancement produces one thing: the CEO deciding who moves. The open-map version produces three things at once: better innovation, better retention, and a more equitable system. Then Train Inside The System Once the functions chart is visible, the meetings are redesigned around it, and people have volunteered into the outcomes they'll own, training becomes the thing that lets the system actually run. Training is real work. Workshops, small conversations, direct coaching on what it means to invite the person closer to the problem into the decision, how to synthesize what they say, how to bring insight back and let it change the plan. It teaches people how to operate inside the redesigned system. On its own, though, training can't do the whole job. If the meetings, the reporting lines, and the decision rights still send the old signal, the training won't override them. Announcing a principle is a values statement. Building the system that makes it real, and then training people to operate inside it, is the whole job. Only the second one holds. Curiosity Is The Precondition There's one more piece underneath all of this that I want to name, because it's easy to miss. All of the structural work, all the redesign of the functions chart and meetings and decision rights, all the workshops and small practices, sit on top of a mindset. The leader has to be genuinely curious about what the people closer to the problem think. Not curious in a symbolic way. Not curious in a "we ran a listening tour" way. Curious in the sense that you actually don't already have the answer, and you know that the person in front of you has information you don't, and you want it. Jocelyn put it well: "I would probably say curiosity. I think that curiosity is such important sort of trait to hold, particularly as a leader. Like, I think we so often, as we sort of go up a journey in leadership, are told that we're the experts, that we know all the things, and people ask us all the questions, and we have the answers." This makes sense given the setup. When a leader believes they already have the answers, distributed leadership becomes theater. The information from the people closer to the problem never actually changes what happens. When a leader is genuinely curious, the information starts to move things. That's when the system produces something different. Curiosity is what makes the whole system real instead of performative. Without it, the practice collapses back into the CEO deciding everything, just with more meetings. What Changes When You Build It This Way When distributed leadership is actually built into an organization, a few things start to shift. The CEO stops being the bottlen
