The end of role clarity

The idea of role clarity has come up in about 80% of the conversations I've had with teams and leaders. (By the way, all of the questions here follow Betteridge's Law of Headlines: if there's a question, the answer is no.)

• It comes up when there are disputes about propriety of a given action. Should so-and-so have done what they did?
• When there are questions about whether individuals can do their best work. Does so-and-so have a good idea of what's expected of them?
• When there are worries about people's ability to grow. Do managers know what it takes to become a leader?
• When execs wonder if they're hiring right. Are we confident this JD is what we actually need?

Role clarity, or the lack of it, gets blamed in every case.

The classic organizational psychology research (Robert Kahn and colleagues in 1964, John Rizzo and colleagues in 1970) treats role ambiguity as almost uniformly destructive: it lowers satisfaction; it reduces motivation; it drives emotional exhaustion. A Rutgers meta-analysis confirmed a moderate negative relationship between role ambiguity and job performance. This is the received wisdom, and I think it's increasingly wrong.

Eleven years ago I wrote about my dim view of this idea, and I truly believe knowledge workers can now leave it behind, break Jevons' Paradox, and kill Baumol's Cost Disease in the process.

Huh?

William Stanley Jevons observed in 1865 that Watt's more efficient steam engine actually massively increased coal consumption, because efficiency made coal viable in far more applications. This happened in knowledge work too, where collaborative tools that were supposed to simplify communication multiplied channels instead. Every time we make administration easier, we produce more administration: more meta-work about work.

Economist William Baumol noticed in the 1960s that some sectors just can't get more productive: a string quartet still needs four people and forty minutes to play Beethoven. Costs in those sectors rise anyway, because they have to compete for labor with sectors that are getting more productive. Management has been a Baumol sector, and that sucks for everyone involved, including (Bane voice) you, the people.

So why can we leave role clarity behind?

TL;DR: AI lets us do a lot more with a lot less → every team can be smaller → smaller teams want and need less role clarity.

I'm not going to try to convince you whether the AI part of this argument is real. I know it is because I've seen it. If you're not yet there, fine! You can still believe that teams can and should be smaller.

I spoke recently with Michelle Peng at Charter about Hidden Patterns, and among many good questions, she asked: "What do you think companies will look like, how will they be organized, if they apply all of the ideas in the book?"

My expectation is that organizations will both be smaller and feel smaller, feel more local, even while achieving the same or better outcomes. They'll be made of networks of teams. Yes, those teams will in many cases be part of a bigger thing, but I think that'll feel more abstract and federated, and the thing you'll care about is the small(er) team around you.

Smaller teams need and want less clarity. There's more overlap between roles, more closeness with teammates, more exploration of what you can do, what they can do, and genuine optimism about what might be possible tomorrow. Obsessing over where I stop and where you pick up freezes what's possible.

Role clarity is a symptom of relational poverty

Richard Hackman's research found the optimal team size is roughly 4.6 members, because coordination costs grow exponentially with team size, and as a result he never allowed teams larger than six in his Harvard classes. Jennifer Mueller found that in larger teams, individuals perceive less available support, or "relational loss." Fewer people means more of each other.

Consider CLOUs, or Colleague Letters of Understanding, used at Morning Star, the world's largest tomato processor, since the 1990s. Each employee writes a Personal Commercial Mission and specifies 20-30 distinct roles with deliverables, levels of authority, and performance metrics, all negotiated peer-to-peer, creating extreme, bottom-up role clarity. The most generous version of the idea you could design. Morning Star is highly profitable, and yet roughly 50% of senior hires leave within two years because they can't adapt to the system. Paul Green Jr., co-founder of the Self-Management Institute at Morning Star, attributed the washout not to incompetence but to inability to adapt to self-management. The people who most embody the instinct toward role clarity, those who have spent careers defining their remit and operating within it, are exactly the ones who fail.

So even the best possible version of role clarity, one that is negotiated not imposed, transparent not hidden...still breaks experienced people. The problem is role clarity itself. It's a bureaucratization of what should be a living relationship.

If you do knowledge work, stop wanting role clarity. Instead, do what IDEO founder David Kelley recommends: "see what you can get away with." Kelley's philosophy is that the primary obstacle to creative work is fear of failure and of judgment. Your job description is the floor, and you define the ceiling. Push past your formal mandate to find the real limits, rather than pre-constraining yourself. This only works when there's trust, and trust is easier in small teams.

The counterargument from the research is worth taking seriously: autonomy within a clear mission is productive; ambiguity about what the mission is tends to be destructive, or "be loose on how, and tight on what." A 2022 study in Frontiers in Psychology tried to show that role ambiguity promotes creative problem-solving, but the positive pathway wasn't empirically supported. Only the negative path held up: ambiguity → rumination → stress → reduced creativity. I think they were measuring the wrong thing. They were looking at individual role ambiguity inside organizations that otherwise demanded clarity. Imagine being the one person without a job description at Deloitte. Of course that's stressful. What I'm more curious about is what happens when the whole team agrees to operate with less definition.

If role clarity is out, then team clarity is in. The distinction matters: role clarity asks "What am I supposed to do?" while purpose clarity asks "What are we trying to accomplish?" Role clarity only becomes meaningful inside a container of collective purpose. Without understanding the actual work first, job descriptions are abstract exercises. Google's Project Aristotle found that "structure and clarity" was one of five factors for team effectiveness, but their definition blended individual expectations with collective purpose. The research suggests these are hierarchical: mission clarity is the container; individual role clarity is a downstream detail that small teams can often leave implicit.

Bbbut without role clarity we can't have psychological safety! Let's look at what Amy Edmondson says in Teaming. A team is a stable object, a fixed group with defined roles; Teaming is a verb, the activity of coordinating across shifting boundaries. Her argument is that in fast-moving knowledge work, you can't rely on stable teams with clear roles; you need people who are skilled at teaming across those boundaries. Teaming is what you do when role clarity runs out, and in her view it's the more important capability. She defines psychological safety not as comfort but as "permission for candor": speaking up across boundaries of status and expertise without fear of penalty. That's the condition I want to design for. Some of that candor, if not most of it, is going to come from people willing to go beyond what was already made clear.

Where am I wrong? Where is role clarity essential, actually? Safety-critical environments: you want the surgeon and the anesthetist to have very clear roles, and the same thing applies to captain and first officer. Regulated industries or functions (legal, compliance, finance) often need auditability, and auditability requires named accountabilities. In large-scale manufacturing or logistics, where hundreds of people must coordinate tightly, formal role definition reduces catastrophic error. My thesis is strongest in knowledge work, creative work, product development; the strategic side of any of those regulated industries. The irony is that these are exactly the contexts where leaders most loudly demand role clarity. They want certainty in a domain that doesn't offer it. (Or they're looking for someone to declare them a leader and someone else a follower, and that's not how that works.)

The organizations that perform well under conditions of speed and ambiguity are the ones with more developed relational capacity. For Edmondson, this is psychological safety. For Mueller, it's relational support. For Morning Star, it's encoded in a letter of understanding. All three are pointing at the same thing: shared context and trust let people act without checking their job description first. Why not just make trust easier by shrinking teams and making more of them.

So what gets harder?

More small teams. More humanity within them. More joy from having better relationships with colleagues. More of the outcomes we want. More output! But it has to go somewhere.

Further to that, it's a lot of more, and the received wisdom on strategy is that it's fundamentally about less, about saying no. Michael Porter's canonical 1996 argument: "The essence of strategy is choosing what not to do." Steve Jobs, returning to a nearly bankrupt Apple in 1997 with 40+ products, cut the line to 4. "Focus means saying no to the hundred other good ideas." If you believe that structure is downstream of strategy, then capabilities and teams optimized for one strategic position are inherently suboptimal for another. As an example: Continental Lite tried to be both full-service and low-cost; they lost hundreds of millions and fired the CEO.

I'll grant that this is absolutely true when building things is expensive, when it was hard to turn the machine on. When it took months and a full team to ship a feature, you had to choose carefully. Prioritization was a scarce-resource allocation problem, and all the OKRs, roadmaps, sprint planning sessions, and quarterly reviews were coordination mechanisms that protected that scarcity, and compression algorithms for communications overhead. Fred Brooks showed that communication channels grow as n(n-1)/2: five people have ten channels, fifty people have 1,225. (Also a small-team stan, Fred would tell you that adding more software engineers to an already late project will only make it later).

When building gets cheap

A friend who leads engineering at a midsize tech firm texted me recently:

I think 3-4 months from now we will have a serious problem where we've run out of roadmap. We'll be shipping things faster than sales, marketing, customer success, and operations can keep up. We don't have to spend months doing annual planning of what we'll build vs. what we won't. We just build it all.

Okay so...the people who build things are telling you the building stopped being the problem. This is a head of engineering telling you that we will run out of “shovel ready“ work to do. CircleCI's 2026 State of Software Delivery report found that daily workflow runs increased 59% year-over-year, driven by AI code generation. Feature branch activity increased 15% while main branch throughput – code actually reaching production – declined 7%. Teams are generating more code than ever and shipping less of it. Review, validation, integration, and recovery are now the scarce thing.

Absorption failure

Sometimes this really, really does not work. Samsung rushed the Galaxy Note 7 to beat the iPhone 7 to market. When the battery spec changed mid-development, the QA team wasn't informed; their tests were based on the original design. Everybody knows this story by now, courtesy two global recalls, and phones banned from every airline on earth. The $5.3 billion in losses can be chalked up to absorption failure. They could build it; the organization couldn't safely release it.

"Yes, but if you ship a new feature without appropriately onboarding legal, you'll risk a lawsuit. Without onboarding CS, you'll have a quality escape."

So the constraint moved downstream, to the folks maintaining the (typically, but not always) non-software systems in the business. And I don't think the answer here is "don't build that," but instead something like "don't ship it yet."

Wesley Cohen and Daniel Levinthal's 1990 paper on absorptive capacity showed that the ability to exploit new knowledge is a function of prior related knowledge. You can only absorb what you're already partly prepared to absorb. Organizations that haven't built integration, onboarding, legal-review, and change-management muscle arrive at the doubling without the capacity to absorb it. Shaker Zahra and Gerard George's 2002 update splits this into potential capacity (recognizing and acquiring knowledge) and realized capacity (transforming and exploiting it). Our potential capacity has gone way, way up, and not just in technology teams. The question is whether the we have the realized capacity to use what's being shipped.

There's a darker concept in the original Cohen and Levinthal paper called "lockout": if you fail to invest in absorptive capacity during a fast-moving period, you may never catch up, because you won't even recognize the signals that you're falling behind. You can't see what you're missing. The evidence of competitive disadvantage stops reaching you because you no longer have the prior knowledge to recognize it as a signal.

The way I see it, prioritization alignment is evolving into two disciplines, with both pieces being harder than what they replaced.

The first question: are we doing the right things? When you can build everything, "everything" could include a lot of garbage. The scarcity of engineering capacity used to be a natural filter. Without it, you need real judgment about what matters: a single person with genuine taste, or formalized direction-setting, or structured environmental scanning. (And for the stuff that won't actually cause a legal/quality/safety disaster, maybe just stop worrying and let speed be your new moat.)

The second question: can the organization absorb what we're shipping? Even if you're doing the right things, doing them faster than legal, CS, ops, and marketing can keep up is its own failure mode. This is the "say not yet" discipline. the thing is working, it's ready, and you have to not ship it.

The old prioritization question was "what should we build?" and scarcity answered it for you. The new questions are "what actually matters?" and "can we hold it together long enough to ship it well?" Nobody has a framework for those yet. Cool; frameworks are exactly how we got into this mess.

So where do the old ways still have value? When you genuinely can't do two things at once. Even if building two things is cheap, sometimes the market will only let you be one thing. Porter was right about Continental Lite, and he's still right about companies trying to serve contradictory positions simultaneously. For early-stage companies where every person IS the absorptive capacity, saying no to ideas is still the discipline. The 'say not yet' frame assumes you have capacity downstream of the builders. A lot of companies don't, and for them, the old prioritization is still the whole game.

Strategy is saying no not yet

Wrapping up!

1. On role clarity: Shared context and trust that let people act without checking their job descriptions. Make that easier by encouraging smaller, stronger teams.
2. On prioritization: The solution to absolute abundance is organizational capacity: the systems that allow all teams to absorb what other teams can produce.

You'll probably be thinking, as I am, that both of these are leadership problems. It's hard for teams to get small all on their own. It's normally impossible for them to decide on their own what they should be doing. You will probably also note that most leadership teams are not ready for either of these. They're still trying to solve role clarity where it's not needed or wanted, with tools that actually prevent the real problem – relational poverty – from getting solved. Meanwhile teams are quickly accomplishing astonishing things, outpacing the absorptive capacity of the org.

If you take one thing from this: stop asking, "who does what?" and start asking, "can we service what we're building?" The answer is probably no. It'd be wrong to slow down; the right reaction here is to build capacity.

Aaaaand that's the work.