The hidden cost of crowdsourcing leadership.
I’ve heard some version of “don’t just bring me problems, bring me solutions” for most of my career. I’ve probably said it myself.
It is generally good advice. Nobody wants to work with someone whose only contribution is identifying everything that’s wrong and then tossing it over the wall. If I’m bringing a problem to somebody, I should have thought about it first. I should understand the options, have a recommendation, and be able to explain the tradeoffs.
There is another phrase I’ve heard almost as often, usually in organizations trying to empower people and move decisions closer to the work: “You guys figure it out.”
I like that one too. The people closest to a problem frequently know more about it than somebody several layers removed from the actual work. I’ve always preferred leaders who provide some boundaries, trust capable people, and give them room to operate.
Lately, though, I’ve been thinking about where those two perfectly reasonable ideas can go sideways.
There is a version of “you guys figure it out” where responsibility for figuring everything out moves down through an organization while the authority to actually settle disagreements stays exactly where it was. People are empowered to develop a solution, but not necessarily empowered to decide between competing solutions. They can build an operating model, but can’t compel anyone else to follow it. They can establish a priority, but another group can establish a different priority. They can negotiate and build consensus, but when consensus isn’t possible everyone eventually retreats into their respective management chains looking for an answer.
At some point that stops looking like empowerment and starts looking suspiciously like crowdsourcing management.
The organization underneath the org chart
Every company has an organization chart. Every company also has another organization hiding underneath it.
The first has boxes, reporting lines, and titles. The second is made up of who actually knows how something works, who can convince whom, which meeting really matters, who needs to be included before a decision is considered “real,” and which person everybody calls when something falls between the cracks.
Large matrixed organizations seem particularly good at producing this second organization.
There are formal managers and executives with hierarchical authority, but there are also program owners, initiative leads, councils, strategic teams, workstream leads, task forces, and various other people who have been asked to make something happen across organizational boundaries. Those people may have responsibility. They may even be held accountable for an outcome. What they don’t necessarily have is authority over the people required to produce it.
The gap gets filled with consensus.
We meet, socialize, circulate drafts, pre-align before the alignment meeting, and incorporate feedback. If that doesn’t work, people go back through their individual management chains. Different pieces of the question eventually reach different pieces of leadership, answers trickle back down, and everybody reconvenes to find out whether we’re finally aligned.
Sometimes that’s healthy collaboration. Sometimes it is twenty smart people spending three weeks negotiating something that one appropriately placed person could have decided in twenty minutes.
Nobody puts those three weeks on the dashboard.
The hidden tax, and the good kind of friction
Meetings are the obvious cost of this kind of operating model, which is probably why everyone complains about meetings. I think the much bigger cost is everything surrounding them.
There is the time spent building consensus, explaining the same issue separately to several leadership chains, maintaining status artifacts, reconciling priorities, and translating information between groups. There is the work required to make the actual work visible to the systems designed to track the work. Then there is the mental overhead of remembering how all of these things fit together.
Robert Sutton and Huggy Rao have spent years studying this broader idea of organizational friction. One of their more interesting ideas in The Friction Project is that leaders should think of themselves as trustees of other people’s time. Their argument isn’t that all friction is bad. Some friction is useful, even necessary. Rao compares it to cholesterol: there is good friction and bad friction. Good friction slows us down when slowing down helps us think, challenge an assumption, hear dissent, or avoid an impulsive decision. Bad friction overwhelms, exhausts, and confuses people.
That distinction matters because I am certainly not advocating for a frictionless organization. I don’t even think I’d want to work in one. Disagreement can be healthy. Having somebody challenge the popular answer can be healthy. Requiring another set of eyes before doing something risky can be healthy. Some decisions should be difficult to make.
The real question isn’t whether an organization has friction. It is whether we’ve put the friction in useful places.
Making an irreversible customer-impacting decision? A little friction might be good. Challenging a strategy everyone has blindly accepted? Good friction. Getting several perspectives before making a major investment? Probably good friction.
Figuring out which of three supposedly top-priority projects is actually the top priority because nobody with the authority to choose will choose? Not so much.
Every dependency has a carrying cost. Every ambiguous boundary creates transactions. Every unresolved priority requires somebody to reconcile it. Eventually an organization can consume an astonishing amount of its own capacity coordinating itself.
The goal isn’t zero friction. It is removing the friction that prevents people from doing valuable work while deliberately preserving the friction that helps them do valuable work well.
Bring me solutions
This brings me back to that advice I started with.
“Don’t bring problems, bring solutions.” Sure. I still believe it.
If I understand a problem, I should have thought about possible solutions. Ideally I should be able to explain what I recommend, why I recommend it, and what the tradeoffs are.
But I think we’ve occasionally turned a useful coaching principle into an excuse for leaders not to lead.
There are problems I can solve. There are problems where I can develop a recommendation. Then there are problems where the problem itself is that several reasonable people, teams, or priorities are in conflict and nobody at our level has the authority to settle it.
I can bring a recommendation in that situation. What I can’t always bring is a decision.
Sometimes an organization actually needs a leader to listen to two reasonable arguments, understand enough of the messy details to appreciate the tradeoffs, make a difficult call, and put enough organizational weight behind that call that everybody can move forward.
There is a reason “disagree and commit” requires both parts. People can disagree laterally all day long. The commitment part becomes considerably harder when nobody knows who had the authority to end the disagreement.
Leaders don’t need everything written in crayon
None of this means every difficult question should immediately be thrown upward. Leaders don’t need everything written out in crayon for them.
There is real skill in distilling complexity. Good operators should know their material well enough to separate important details from noise, explain tradeoffs clearly, and respect the time of people who have broader spans of responsibility. I want my leaders to be successful, and part of my job is helping them understand what they need to understand without dragging them through every detail I’ve encountered along the way.
But helping leaders understand complexity isn’t the same thing as hiding complexity from leadership.
Sometimes the weeds matter. Sometimes understanding why six groups can’t agree requires understanding how those groups actually work. Sometimes an apparent personality conflict is really a systems problem. Sometimes a seemingly trivial disagreement exposes an unresolved question about strategy, ownership, capacity, or incentives. Sometimes there isn’t a magical win-win hiding behind one more alignment meeting.
Someone has to make a decision.
When leaders consistently stay above those conflicts, the complexity doesn’t disappear. It gets absorbed lower in the organization. Managers absorb it. Individual contributors absorb it. Program owners absorb it. Teams absorb it. People spend hours negotiating boundaries and trying to infer priorities. When they can’t resolve something, everybody retreats up their own reporting chain, receives slightly different guidance, and comes back together to start again.
The leadership conflict still exists. We’ve just distributed the cost of it across twenty people’s calendars.
Over time that creates something worse than toil. It creates built-in organizational tension. People who should be working together start looking like obstacles to one another because the system hasn’t clearly established whose priority wins, who owns a decision, or where a disagreement is supposed to end.
I don’t think the sole purpose of everyone below leadership is to make leadership’s job simple. We should make information understandable, bring recommendations, solve the things we’re empowered and equipped to solve, and avoid escalating decisions simply because they’re uncomfortable. But customers are complicated. Technology is complicated. People are complicated. Strategy involves tradeoffs. Organizations contain competing incentives and finite resources.
Leadership is supposed to encounter some of that complexity.
The green-box economy
Then we get to measurement.
I love measurement. I love systems. Give me a dashboard and a spreadsheet and I can happily disappear down a rabbit hole for an unreasonable amount of time.
The problem comes when the representation of the work starts becoming more important than the work.
If leadership is sufficiently removed from the actual machinery, it naturally relies on abstractions. A complicated customer situation gets summarized into a few bullets. Those bullets become a metric. The metric lands on a dashboard. Eventually a complicated mixture of customer experience, technical work, risk, toil, and human judgment has been reduced to a little green square.
That is wonderfully efficient until everyone discovers the square wasn’t doing a particularly good job of describing reality.
W. Edwards Deming was warning organizations about versions of this problem decades before anyone could build a digital dashboard. His 14 Points included breaking down barriers between departments, eliminating numerical quotas and numerical goals for management, and substituting leadership. The point wasn’t that numbers are bad. Deming’s entire body of work would make that interpretation rather silly. The numbers have to be understood as products of a system.
Goodhart’s Law takes us down a closely related rabbit hole. The popular version is usually given as, “When a measure becomes a target, it ceases to be a good measure.” There is even a fun bit of nerd trivia hiding here: that memorable wording isn’t Charles Goodhart’s original formulation, but a later generalization by anthropologist Marilyn Strathern.
Regardless, the phenomenon is instantly recognizable. If organizational success becomes legible through completed work items, deadlines, status colors, compliance percentages, or whatever happens to be visible this quarter, people rationally optimize for those things.
Create the work item. Update the status. Hit the milestone. Make the square green. Get the cookie.
There don’t have to be bad actors involved. People are responding intelligently to the incentive system around them. The problem is that someone thinking about long-term dependencies, customer outcomes, systemic risk, or whether the process itself makes any sense can start looking less productive than someone who has become exceptionally good at turning squares green.
Organizational duct tape
This line of thinking inevitably sent me back down the David Graeber Bullshit Jobs rabbit hole.
Graeber’s larger thesis is deliberately provocative, and I’m not prepared to declare half of corporate America pointless. But some of his categories are painfully useful. He describes “duct-tapers,” whose jobs exist because something in the organization is broken and hasn’t been permanently fixed, along with “box-tickers,” whose work provides evidence that something has been done.
That made me wonder how much highly skilled labor inside modern organizations functions as organizational duct tape.
These are frequently some of the most valuable people in a company. They connect teams that don’t naturally connect. They translate between groups. They remember decisions nobody documented. They reconcile incompatible processes, manually stitch together information, chase dependencies, and prevent things from falling apart.
I’ve played this role plenty of times myself.
The paradox is that their work is valuable precisely because the system keeps producing the problem. There is a career trap buried in there too. If you are competent, have institutional memory, and naturally see connections between things, filling every available gap can feel a lot like ownership. Eventually you can become human middleware.
The organization depends on you without necessarily becoming better because of you. Worse, every time a capable person quietly absorbs organizational ambiguity, the organization receives one less signal that the ambiguity exists.
When weird becomes normal
Diane Vaughan’s research into the Challenger disaster provides a much more serious historical example, and the comparison deserves some care because seven people lost their lives.
Vaughan spent years studying the organizational circumstances surrounding the 1986 Challenger launch. What she found was more interesting than a simple story about bad managers knowingly ignoring obvious danger. She described a process she called the normalization of deviance, where anomalies and deviations could gradually become interpreted as normal through repeated experience, organizational culture, and established ways of making sense of risk.
The important lesson for ordinary organizations isn’t that a messy operating model is equivalent to a spacecraft disaster. Obviously it isn’t. The interesting connection is how easily human systems can normalize friction.
A manual reconciliation is needed once, so somebody creates one. It happens again, so it becomes weekly. A meeting is required to resolve an unclear boundary, so the meeting becomes recurring. Someone builds a spreadsheet to bridge two systems, and three years later a business process depends on that spreadsheet.
Eventually nobody remembers the original problem. The workaround is simply how the work works.
Strategy from below is still a good thing
There is an obvious danger in this argument. Taken too far, it starts sounding like executives should decide everything. Please don’t.
Henry Mintzberg and James Waters wrote about deliberate and emergent strategy back in 1985. They described the two as ends of a continuum, with real strategies taking different forms between them. Strategy doesn’t descend perfectly formed from a conference room. It emerges from customers, experimentation, technical realities, failures, frontline experience, and people throughout the organization noticing things leadership can’t possibly see.
The people closest to customers and systems should have enormous influence over strategy. But there is a difference between strategy emerging from the organization and leadership outsourcing responsibility for strategic choices to the organization.
Eventually two good ideas will compete for the same people, money, or time. Someone has to decide.
Please, God, not another transformation
My natural instinct when I encounter an operating-model problem is to design an operating model. That may be how we got into some of this trouble in the first place.
So I don’t think the answer is another transformation, a clever new taxonomy, or a 47-slide deck explaining the governance framework. Most organizations could probably make meaningful progress by answering a handful of boring questions consistently.
Who recommends? Who decides? Who needs to contribute? Who executes? What happens when two priorities require the same capacity? Where does an unresolved dependency go?
There should also be an actual priority stack somewhere. Individual teams can have their own backlogs and plans, but when several groups need the same people, systems, or customers, someone has to be willing to say that A outranks B. Without that mechanism, prioritization eventually becomes a mixture of persistence, escalation, personality, and proximity to leadership.
Dependencies deserve similar treatment. They aren’t footnotes attached to projects. They consume real time and capacity.
Finally, status and governance aren’t the same thing. A meeting where everybody reports whether something is red, yellow, or green might be useful reporting. A meeting where someone says, “We can realistically do one of these three things. Here are the consequences. Which one wins?” requires governance.
That second meeting may be uncomfortable. That’s kind of the point.
The part leaders can’t delegate
Executives shouldn’t operate every piece of the machinery. They shouldn’t be making decisions that capable people closer to the work can make better and faster. But they do need enough contact with the machinery to understand what they are governing.
The further leadership gets from actual delivery, the more the organization has to compress reality for them. Details become summaries, summaries become metrics, and metrics become colors. Some compression is necessary at scale, but every compression algorithm loses information.
There has to be a way for leaders to occasionally encounter the uncompressed version: a customer conversation, an incident review, a frontline delivery discussion, or a room full of people explaining why something that looked trivial on a dashboard consumed sixty hours of coordination.
That isn’t micromanagement. It is telemetry.
Sometimes leadership means diving into the details, aligning people who haven’t been able to align themselves, making the difficult decision, and putting enough organizational weight behind it that the decision sticks.
If every difficult problem arrives at the top perfectly packaged, universally aligned, and accompanied by a solution requiring nothing more than an executive thumbs-up, I’m not convinced we’ve created exceptional leadership. We may have simply moved most of the leadership work somewhere else.
Perhaps the simplest test of an operating model is whether capable people can answer a few questions without convening a committee: What are we trying to accomplish? What matters most right now? What am I empowered to decide? Who decides the things I can’t? What happens when reasonable people disagree?
Smart, motivated people are remarkably good at compensating when those answers aren’t clear. I’m just increasingly unconvinced that we should mistake their ability to compensate for evidence that the system works.
Rabbit Hole
Robert Sutton and Huggy Rao, The Friction Project. This may be the closest companion to the whole idea. Their distinction between good and bad friction is particularly useful because the goal shouldn’t be a frictionless organization. Rao’s May 2026 Stanford interview is a good short entry point: Fixing Bad Friction, Finding Good Friction. For the deeper dive, see The Friction Project.
W. Edwards Deming, 14 Points for Management. Deming was writing about systems, numerical management, departmental barriers, and leadership decades before our current collection of digital management tools existed. The Deming Institute: 14 Points for Management.
Goodhart’s Law and Marilyn Strathern. If you’ve ever wondered why the metric everybody cared about eventually became strangely disconnected from the thing it was originally supposed to measure, this is your rabbit hole. The familiar wording is Strathern’s generalization of Goodhart’s observation. A useful academic overview.
Henry Mintzberg and James Waters, “Of Strategies, Deliberate and Emergent.” Published in 1985 and still a useful counterweight to the idea that strategy should simply flow downward. Read the paper via DOI.
Matthew Skelton and Manuel Pais, Team Topologies. Their thinking about cognitive load, team boundaries, and explicit interaction modes is useful far outside software architecture. Team Topologies: Key Concepts.
Diane Vaughan, The Challenger Launch Decision. This is the serious rabbit hole. Vaughan’s work challenged the simpler story that Challenger resulted from a few obviously reckless individuals and instead examined how organizational culture and decision-making gradually normalized risk. Columbia Magazine: Challenger and the normalization of deviance.
David Graeber, Bullshit Jobs. Read it as a provocative argument rather than a management framework. The “duct-taper” and “box-ticker” categories alone are worth the trip.
Positive Friction, literally. The management rabbit hole eventually collided with the musical one. Donna the Buffalo released Positive Friction in 2000, including the title track. It has essentially nothing to do with organizational design, which naturally means it belongs here.
Donna the Buffalo: Positive Friction on YouTube
Once you start noticing organizational friction, good luck not seeing it everywhere.
