There’s a difference between mirrors and mirroring. Over the years I’ve come to see that difference, and I wanted to share how my thinking has shifted.

Earlier in my career, I was smitten by the idea that if teams could “just” visualize how they work, embrace transparency, etc., then almost any team could improve. This is similar to the “if we could just talk it out” belief, or the “if we could just hear each other out” (or consider other perspectives, etc. etc.) belief. I still carry some of this with me to this day despite numerous run-ins with “reality” and, as some people are keen to point out, “the real world.”

I’ve yet to observe evidence of a single “real world,” or that things are destined to be the way “real world” folks make them out to be (all the time, at least), but I have come to see the idea of mirrors differently as my career has progressed.

• Mirrors are not neutral

• Organizational truth can be weaponized

• We prefer flattering mirrors

• The person holding the mirror has an agenda too

• Seeing something clearly doesn’t mean you can act on it

• Every mirror has a frame, and the frame is a choice

• “Radical honesty” is its own kind of performance

• Solo mirrors and collective mirrors work differently

• Truth in organizations is negotiated

What people want isn’t the mirror — it’s to be mirrored

People don’t want the “truth” reflected back in some abstract way. They want their experience to be recognized. They want their perspective to matter. Shifting my thinking from mirrors to mirroring has been a big mental leap. It is the shift from showing people the truth to helping people feel seen. And in the current landscape, feeling “seen” might actually look like the reverse of transparency. It is someone feeling like their perspective is understood, but is not being held against them.

The trouble with mirrors is that they don’t show “reality”; they show a reality, from a position, through a frame. And even when people see something clearly, that does not mean they are ready, safe, aligned, or empowered to change it.

I was thinking about this while I was looking in the mirror this morning. The morning of my birthday. And I thought to myself, “You know, that gray hair isn’t exactly the thing I wanted to see this morning.” But hey, it is a mirror, right? I *should* want to see things. Not really. I should want to see that messy closet so that I can “get real” with the mess. But I don’t open it. We do many things to avoid seeing things as they are, or at least how we might perceive them in that particular moment.

We do this all the time in our personal lives, so it should come as no surprise that we might not want to see a company org chart as it “is,” with the vestiges of strategies past littering the reporting structures, team structures, and collaboration patterns. It might be far more comforting to see the bright, shiny, and new team names, even if they obscure the situation on the ground.

If a team tries to explain “how it is” a couple times, and no one really pays attention (or punishes them for that), they would prefer to keep things under wraps. And for all the talk about “clear-eyed” strategies, it isn’t exactly inspiring to walk into a meeting and find out that the chances of the company succeeding are basically a coin flip, that there are a dozen competitors who customers could wake up in the morning and sign a deal with, or that there’s not anything terribly differentiated about what you do. That’s uncomfortable. There was a lot to be said from a raw, unabashed capitalistic standpoint that the company would do just fine in pure extractive mode. It was actually better for everyone involved to add some frosting and sparkle to the mirror, at least until the job market improved.

All this is to say that while the concept of shining a mirror on operations sounds good in theory, it misses a couple key points:

• There is no single mirror, or at least people will perceive what they see differently. There are many mirrors.

• Looking at mirrors requires high levels of psychological safety AND shared goals. You can have an incredibly “safe” environment where people just don’t see the shared incentive to stare down the big elephants in the room.

• Companies are more like the funny room with all the contorted mirrors. We like to shift our bodies around slightly and look VERY BIG, and then sometimes VERY SMALL. Sometimes we like to see 1,000 fractal images of ourselves, and sometimes we want to stare into the abyss.

What people really want is for their view of things not to be discounted and invalidated. They want their truth understood and their perspective heard. They want some sense of control. They want to be heard and understood. They want someone they trust to “mirror” them and connect.

The solo mirror works because it’s a one-party system. You, your body, the coach, the scale. There’s a single locus of control and a single viewer. Truth is uncomfortable but “simple.” You can look or not look, but the thing you’re looking at isn’t looking back at you with its own agenda. Or if it is, you’re negotiating with your many “faces” and sides, which is basically the underpinning of Internal Family Systems therapy — but that is a story for another day.

Organizations are multi-party. There is no mirror — there are dozens of people holding up fragments, each angled slightly differently, each reflecting something real but partial, and each with something at stake in what gets seen. That’s not a pathology. That’s just what it means to be a collective. The “truth” isn’t being hidden or distorted; it’s being negotiated, constantly, because it has to be. There’s no view from nowhere (see Thomas Nagel’s *The View from Nowhere*, where he explores the tension between the objective standpoint we aspire to and the subjective standpoint we’re stuck with).

Maybe we’re doing what collectives do: negotiating what to foreground, what to background, what to act on, and what to leave alone (based on power, incentive, timing, capacity, and a hundred other things that have nothing to do with courage or cowardice).

I often find myself coming back to Venkatesh Rao’s Gervais Principle and how it tackles this. In his framing, the people who want to hold up mirrors to the organization are the Clueless, the middle layer that genuinely believes the organization is what it says it is. The Sociopaths at the top already know what’s behind the mirror; they built it. And the Losers at the bottom stopped looking a long time ago.

The belief in “organizational truth” tends to come from a very specific position in the hierarchy: consultants, coaches, agile practitioners, team leads. People close enough to the mess to see it, who care enough to want to name it, but who don’t have the power or the cynicism to just play the game.

The belief in mirrors is itself positional. It’s not universal wisdom. It’s the worldview of a particular organizational stratum. The people at the top don’t need the mirror; they’re arranging the lighting. The people at the bottom have already internalized that looking doesn’t change anything. It’s the middle that builds its identity around “if we could just see clearly...”

Some of the loudest voices for “transparency” or “radical” honesty, or trying to do away with politics, are actually about power. They get to decide what counts as honest, what counts as political, and who is being “difficult” for not going along with their version of clarity.

And some of the biggest advocates for “crucial conversations” are either people who have never had to suffer the direct consequences for speaking up, or people who’ve already won enough that candor is cheap for them.

I realize all of this sounds negative. Why am I saying it? I’m saying it to underscore that you have to be careful about what you ask for. Before you hold up a mirror, or ask someone else to look into one, it’s worth questioning whether the “truth” will be met with stewardship. Will what gets surfaced be held with care, or will it just be out there, exposed, with no one accountable for what happens next?

So where does that leave me? Something more aligned with Peter Block.

In *Community: The Structure of Belonging*, he writes: “Individual transformation is not the point; weaving and strengthening the fabric of community is a collective effort and starts from a shift in our mindset about our connectedness.” His question isn’t “what does the data say?” It’s “how are we going to be when we gather together?”

Mirroring is engaging in some version of reality (or realities) together. Exploring it, mapping it, not because the map is inherently right, but because we’re exploring together, and both people feel heard and part of it.

The map matters less than the fact that we drew it side by side.

So you want your team to figure out how to use AI for the benefit of your company? Then stop stripping them of the agency to do it.

AI is posing all of us hard questions about agency, worth, and identity. But the far bigger problem is how we’re talking about it, mandating it, and wielding it.

You see leaders blabbering on about everything they're doing to drive adoption, while trampling the most basic elements of human nature: agency, trust, and dignity. Many leadership teams are engaging in what amounts to collective gaslighting of their teams. They treat resistance to AI as a personal failing, a lack of curiosity, motivation, or willingness to adapt, rather than a rational response to a changing environment.

They frame adoption as an education problem, a motivation problem, a mindset problem, or a matter of individual “agency.” They spend very little time considering how the environment can be either an affordance to high agency, or a limiter. But as Bandura put it, “Personal agency operates within a broad network of sociostructural influences.” People are both producers and products of their environment.

The individual’s relationship with AI is a long-term, multi-career, deeply personal thing. You’ll have many jobs across many companies. Learning how AI fits into your craft, on your terms, is genuinely important. But that’s not what leaders are talking about. They’re talking about adoption for the company. On the company’s timeline. For the company’s metrics. The language sounds like “this is for your growth,” but the structure (and any halfway sensible reading between the lines) says “this is for our Q3 goals.” They’re co-opting a personal journey for organizational benefit and calling it empowerment.

No one is asking the harder question: what have our companies done to erode so much trust and loyalty that people are naturally going to question these mandates? Years of layoffs, reorgs, broken promises, and treating people as interchangeable, and now you’re surprised they don’t take “this will be great for you” at face value?

Agency is not only individual.

Agency exists in an environment. Yet almost everything about how we talk about AI adoption treats it as a personal trait you either have or you don’t.

Paraphrasing a friend’s recent rant over coffee:

I'm not anti-AI. I'm anti how my company is talking about it. I'm anti being treated like an ‘agent’ who needs to adopt something for someone else's benefit. I use AI every day. I'm genuinely curious about it. But when my manager tells me I need to 'show more AI initiative,' I don't feel inspired. I feel managed. I have twenty years of experience solving hard problems, and now the measure of my worth is whether I'm prompting enough? Give me a real problem, give me space to figure out whether AI helps solve it, and get out of my way. That's all I'm asking.

When you strip people of the ability to question, to learn at their own pace, to experiment with tools on their own terms, you strip them of agency. You’re not asking them to adopt a tool. You’re asking them to stop thinking. Healthy skepticism and empiricism is a core tenet of agency. Curiosity and the ability to act on that curiosity is a bedrock of agency. When companies gaslight healthy skepticism, they remove people’s agency.

You shouldn’t steal agency from the people asking the right questions. The distinction between tools that help and tools that hurt is critical, and the people trying to make that distinction are doing the most important work right now.

• Ursula Franklin warned that prescriptive technologies “eliminate the occasions for decision-making and judgment” and produce “a culture of conformity and compliance.” That’s what mandates do. They turn an exploratory tool into a compliance exercise.

• Ivan Illich drew the line between convivial tools, which give people “the greatest opportunity to enrich the environment with the fruits of their vision,” and manipulative tools, which “allow their designers to determine the meaning and expectations of others.”

AI can be either. The way most companies are deploying it, it’s the latter.

And when you remove people’s agency in the face of a technology that already raises hard questions about human agency, about what we’re for, what our work means, what only we can do, what else would you expect? Of course people push back. Of course they disengage. You’ve taken the one thing they needed most.

The "bar raiser" idea is deeply encoded in tech lore: find the best, study what makes them different, use them to raise the standard for everyone else. Even the best versions of this, like Atlassian's evolution from vanity adoption metrics to per-function superuser analysis, still frame the problem as "find the right individuals" while ignoring the environment that makes their behavior possible and measuring capability-building rather than actual return. Grow capacity faster than the judgment about where to aim it, and you just get a more capable org producing more output of unproven value.

The productivity narrative keeps inflating.

First, you had to hire 10x people. Then AI was going to make everyone 10x. Now we have CEOs claiming they’re 100x more effective. I recently asked one of these CEOs, who runs a collaboration tool, whether there was 100x more demand for their product. Crickets. The math only works if you don’t ask where the value goes.

When a company says “everyone is going to use AI,” what message does that send to the people who work there? Why should they tinker on your shareholders’ behalf? What assurance are you giving that today’s ingenuity and experimentation will actually benefit people, both individually and collectively? How do your breathless rallying cries convey anything other than “produce more, faster, with fewer of you”?

Self-Determination Theory (Deci & Ryan) tells us that people need three things to be genuinely motivated: autonomy, competence, and relatedness. Look at what we’re doing to all three.

• Autonomy. “Everyone will use AI.” Mandates replace choice. You’ve removed the very thing that makes adoption feel like agency instead of compliance.

• Competence. AI devalues hard-won skills while demanding new ones on someone else’s timeline. Skills like judgment, facilitation, synthesis, and craft are glossed over because they’re harder to see in an AI workflow. The message: what you were good at matters less now, and you’d better catch up fast.

• Relatedness. The individual “superpower” narrative rewards going solo. When one person can bypass the team, collaboration isn’t enhanced. It’s sidelined. People lose their connection to the group’s purpose.

The companies demanding AI adoption are systematically destroying the conditions that would make genuine adoption possible. Then they label the predictable result a mindset problem.

This is the exact moment that calls for collective continuous improvement. Learning together, experimenting safely, sharing what works, iterating on how the team operates. Instead, we’re navigating highly pathological environments, where trust is low, mandates are high, and the people best positioned to figure this out together have been stripped of the agency to do so.

So ask yourself:'

• Am I creating an environment where people can develop agency with AI, or am I mandating compliance and calling it adoption?

• When someone on my team pushes back on AI, do I treat that as a signal to listen to or a problem to fix?

• Can I articulate who specifically benefits from our AI push, and over what time horizon, and have I said that out loud to the people I’m asking to change?

Book a short research session

I have been thinking a lot about self-care, especially for people who find themselves pulled into helping people and making things better. The desire to help can be a gift. It can make you notice pain other people have normalized. It can help you imagine futures that are more coherent, humane, and effective. It can give you the energy to push against inertia. And it can give you the patience to nurture something that others might give up on too quickly.

But it can also become a source of pain and overwhelm.

You can see something that others do not see yet. You can imagine a better future that is not yet accessible. You can spend enormous amounts of energy pushing against a system that may not be ready, willing, or able to shift.

So part of the work is not just learning how to catalyze change. It is learning how to relate to your own impulse to help: what activates/triggers it, how it shapes your judgment, how much (and what type of) energy it demands, and how it might trigger a response in others.

Especially now, in the current environment, it is critical to meter your efforts. There is a never-ending parade of stimuli: things to learn, teams under strain, leaders under pressure, abuses of power, shifting priorities, fear, ambiguity, layoffs, and people trying to make sense of what comes next.

You have to pace yourself, and understand why you do what you do.

The Four Impulses

When you care about helping, different situations can activate different impulses.

You may be pulled toward advocating for a method, relieving pain in the system, serving a mission, or helping people build agency. These are not fixed personality types. They can overlap, combine, and shift depending on the situation.

Each impulse has a gift. But taken too far, each one can become a trap. And because each impulse carries an implied claim about what should happen (and what is broken), it is also liable to trigger certain people around you. In other words, each impulse can be kryptonite for someone.

Way-Driven

“This group would be better off if they could learn, adopt, or inhabit this way of working.”

The way-driven impulse is activated by belief in a particular method, model, practice, philosophy, or way of working. There is a sense of, “I have seen what this can do, and this group would benefit from it.”

This impulse is not necessarily dogmatic. It often comes from care. The desire to help meets passion for the approach, and that creates a powerful drive. But when this impulse is leading, the group’s pain tends to be interpreted through the lens of the way.

Trap: The method becomes more important than the people it is meant to help.

Kryptonite: People who are allergic to orthodoxy, frameworks, jargon, or being “converted.” They may experience this impulse as rigid, acting superior, or naïve, even when the method has real value.

Tension-Absorbing

“This does not have to be this way. There must be a more coherent, humane, effective future this group can reach.”

The tension-absorbing impulse is activated by pain in the system: tension, incoherence, waste, ambiguity, misalignment, unfairness, or avoidable suffering.

When this impulse is leading, something in the body reacts to the gap between what is happening and what seems possible. There is a pull to resolve the tension, defend people, protect the group, or make the situation more coherent. The helper instinct gets triggered.

Trap: Felt urgency becomes a substitute for the group’s readiness, consent, or agency.

Kryptonite: People who dislike emotional pressure, moral intensity, or being implicitly cast as part of the harm. They may experience this impulse as too sensitive, dramatic, over-involved, or destabilizing.

Mission-Driven

“This problem matters too much for the current system to keep failing at it.”

The mission-driven impulse is activated by a cause, outcome, or problem that feels too important to keep failing at.

When this impulse is leading, tactics become secondary. Methods, coalitions, arguments, compromises, and operating models are judged by whether they move the mission forward. The motivating force is not the elegance of the method or the felt pain in the room, but the importance of the outcome.

Trap: The importance of the mission becomes permission to override people.

Kryptonite: People who place high value on relationships, local knowledge, fairness, or careful process. They may experience this impulse as pushing too hard, moving too fast, or treating people and context as secondary to achieving the goal.

Agency-Building

“People need the power, relationships, confidence, and leadership to act for themselves.”

The agency-building impulse is activated by blocked capacity. The concern is not only whether the group reaches a better future, but whether people build the power, relationships, confidence, and leadership to shape that future for themselves.

When this impulse is in the driver’s seat, the work is less about personally resolving the tension, installing a method, or advancing the mission through one’s own effort. The focus is helping the group develop a shared language, organize around common interests, build relationships, practice leadership, name power dynamics, and increase its ability to act.

Trap: Respect for self-determination becomes an excuse to withhold needed structure, expertise, or protection.

Kryptonite: People who want clarity, decisiveness, expertise, or relief from ambiguity. They may experience this impulse as indirect, slow, overly facilitative, or unwilling to lead.

Personal Identity

These impulses can also attach to your personal and professional identity.

• You may take pride in understanding a particular method, practice, or way of working. You may have spent years developing that craft. So when someone dismisses the method, it may not feel like they are only rejecting an idea. It may feel like they are dismissing something you have worked hard to become good at.

• You may identify with your ability to sense incoherence, pain, or tension in a system. That can be a real strength. But if people do not see what you see, or seem unwilling to respond to it, it can feel lonely, invalidating, or maddening.

• You may tie part of your self-worth, safety, or sense of purpose to the mission. If the mission stalls, gets diluted, or is treated as optional, it may not feel like a normal strategic disagreement. It may feel like something important about you, your values, or your reason for being there is being threatened.

• Or you may see your strength in your ability to step back, foster agency, and help the group act for itself. If others demand quick answers, decisive direction, or heroic leadership, you may feel misunderstood or pulled away from what you believe real help requires.

Identity can give these impulses depth, commitment, patience, and craft. But it also raises the stakes.

When an impulse becomes part of your identity, resistance to the impulse can feel like resistance to you. A critique of the method can feel like a critique of your expertise. A lack of urgency can feel like a rejection of your values. A leader’s dismissal of tension can feel like a dismissal of your perception. A demand for more direction can feel like a rejection of your belief in agency.

That is when it becomes harder to stay curious.

Power

These impulses, and the identities they become connected to, are channeled through your relationship with power: both the power around you, and your own.

The first layer is your relationship to people with power.

A person with power may be able to bless the change, block it, ignore it, hijack it, protect it, or distort it. They may be the person you need to influence. They may be the source of the problem. They may be a genuine advocate who still struggles to help. They may say they support the work, but hesitate when it requires real political capital.

When one of your change impulses meets someone else’s power, it can trigger strong feelings. You may feel anger when power is used carelessly. You may feel helpless when people with authority will not act. You may feel fear when the source of power is also the source of threat. You may feel urgency when people are being harmed and the people who could help remain quiet.

These experiences can also stir some of your deepest feelings, sometimes reaching back to childhood experiences with authority, safety, fairness, or belonging. That can make these moments extremely hard to navigate, and the intensity of your reaction may reflect more than the present situation alone.

You might ask yourself:

• Who am I expecting to use power here, and what am I expecting them to do?

• Am I reacting to what this person is doing now, or to what they represent to me?

• Am I waiting for permission, protection, or courage from someone who may not provide it?

• What feeling is most active in me right now: anger, fear, disappointment, helplessness, urgency, or something else?

The second layer is your relationship to your own power.

You may have more influence than you realize: credibility, expertise, relationships, access, judgment, language, or the ability to make something visible. You may also have formal authority: a role, title, budget, team, decision right, or the ability to approve, deny, prioritize, protect, delay, or expose.

That can bring up its own set of feelings, energy, and tension. You may underuse your power because you do not want to be coercive, political, self-important, or unfair. You may overuse it because the pain feels intolerable, the mission feels urgent, or the better future feels obvious. You may hide your power behind “just helping.” You may deny your power because admitting it would mean admitting responsibility.

This can cut deeper than people expect and bring up strong emotions. It is deeply personal. Your relationship to your own power may touch old experiences of responsibility, exclusion, shame, fear, guilt, pride, or helplessness.

You might ask yourself:

• What power do I actually have here, formal or informal?

• Am I underusing it, overusing it, or pretending I do not have it?

• Am I hiding influence behind the language of helping?

• What responsibility comes with my place in the system?

• What would using my power carefully look like here?

One important note: there is a whole other angle here around who is expected to help.

The burden of noticing, translating, smoothing tension, naming harm, educating others, or holding the group together is not evenly distributed. There is a large body of work around emotional labor, cultural taxation, identity taxation, office housework, and emotional tax that points to a similar pattern: the work of making a system more humane often falls disproportionately on people who are already carrying more of the cost.

In many organizations, people from underrepresented groups are typed as helpers and asked, implicitly or explicitly, to do extra emotional, cultural, and political labor. They may be expected to make pain legible, soften the message, protect others from discomfort, represent a group, educate colleagues, or help the system improve while also absorbing the effects of the current system.

That deserves more attention than I can give it here. But I wanted to call it out.

Power and Impulse Combined

Combined, these impulses and power dynamics can create a familiar spiral.

(If you aren’t in the mood for a story, just skim this section.)

Imagine a situation where someone senses real tension and incoherence in a group. Their tension-absorbing impulse is active. They see people struggling, and they feel pulled to name the pain, reduce it, or protect people from it.

A leader responds with something like, “Well, why didn’t the managers deal with that?”

That may be a reasonable question. But for someone whose tension-absorbing impulse is active, the temperature rises quickly. It can feel like the person with more power is avoiding the pain that power helped create, or at least has some responsibility to address.

From there, the situation can escalate.

The person trying to help may assume that the people closest to the problem are not really in a position to name it publicly. That may be true. They may have said things privately that they do not feel safe saying in the room. They may have real reasons to be cautious. But the helper may also misjudge it. They may underestimate the group’s agency, overestimate the danger, or start shouldering something the group has not asked them to shoulder.

Then, because they want to make progress, they reach for a practice as a next step: a better meeting, a clearer operating rhythm, a retrospective, a decision log, a working agreement, a way to surface tensions more safely. That may come from care and experience. But it can also trigger someone else’s kryptonite.

For the leader, the tension-absorbing impulse may already feel like emotional pressure, moral intensity, or an implicit accusation: “You should have noticed this,” or “You are partly responsible for this pain.” Then the way-driven impulse shows up too, because the proposed next step is a practice. Now it can sound like, “And here is the process you should have been using all along.”

To the leader, it may feel like the helper believes a practice can solve a power problem. It may sound naïve, procedural, or overly earnest. They may hear, “If we just ran the right ritual, the tension would go away,” even if that is not what was meant.

And if the leader has power, their skepticism may hit the helper harder. It may not feel like ordinary disagreement. It may feel like being dismissed by someone who has the power to dictate reality. If the leader says, “I don’t think that’s the issue,” or “This feels like process for process’s sake,” the helper may feel reduced to the “process person,” even if they are trying to point at something deeper.

Now the situation is charged on multiple levels.

The helper’s tension-absorbing impulse may be kryptonite for someone who dislikes emotional pressure or being implicated in harm. Their way-driven next step may be kryptonite for someone who is allergic to frameworks, rituals, or being “converted.” The leader’s power may be kryptonite for someone sensitive to being dismissed by people with authority.

The helper may be reacting to what feels like power deflecting responsibility. The leader may be reacting to what feels like someone reducing a messy leadership situation to a framework choice. The helper may be assuming the group cannot safely say publicly what they have said privately. The leader may be assuming the proposal reflects naivety about how change really happens.

And on and on it goes…

A Few Observations

The obvious one: this takes an incredible amount of energy and patience. Not just the work of changing the system, but the work of noticing what is getting activated in you, what is getting activated in others, how your identity is getting pulled in, and how power is shaping the interaction.

As your energy gets depleted, you are more likely to get pulled in. And once you are pulled in, you are more likely to escalate the situation. You may push harder, read resistance less generously, over-identify with the pain, reach too quickly for a practice, turn disappointment into anger, or begin to threaten—subtly or directly. And when escalation turns into threat, you often diminish your odds of creating the change you were hoping for.

Understanding your relationship to power is critical. That includes your response to other people’s power and your relationship to your own. Both can get very personal, very quickly. Power can touch old experiences of authority, fairness, safety, belonging, responsibility, shame, helplessness, or being dismissed.

Understanding your relationship to identity matters too. The impulse may be connected to something you take pride in: your craft, your values, your ability to sense tension, your commitment to a mission, or your belief in helping people build agency. When that identity gets touched, resistance can feel less like disagreement and more like a rejection of something important about you.

Each impulse to change carries its own trap, and each can trigger people around you in different ways. The way-driven impulse can sound like conversion. The tension-absorbing impulse can sound like accusation. The mission-driven impulse can sound like pressure. The agency-building impulse can sound like ambiguity or abdication.

The point is not to stop caring. The point is to notice what caring is doing to you, how it is landing with others, and whether you still have the energy and perspective to help.

This is where Edgar Schein’s work on helping is useful. Schein captured the paradox well: “All too often, to our bewilderment, our sincere offers of help are resented, resisted, or refused—and we often react the same way when people try to help us.”

From the inside, the impulse to help may feel generous, careful, and well-intended. But from the outside, it may land as pressure, judgment, superiority, rescue, or control. The other person may feel exposed, corrected, diminished, or put “one down,” even if that was not the intent.

This is why helping requires more than care. It requires attention to the relationship your help is creating. Are you increasing the other person’s capacity and agency, or are you making yourself the one who sees, knows, carries, or fixes? Are you helping in a way that the other person can actually receive, or are you adding another layer of pressure to an already charged situation?

For someone pulled into making things better, Schein’s warning is a useful check: sincerity is not enough.

Coming Back to Self-Care

This is why self-care matters.

Not self-care as a vague reminder to take breaks, but self-care as the discipline of staying in the right relationship with your own desire to help.

If you are someone who notices pain, imagines better futures, and feels pulled to intervene, you need ways to conserve your energy and keep your perspective. Otherwise, the very thing that makes you useful can start to work against you. You may become emotionally overinvested, assume action is needed before conditions are right, or push harder than others are ready for. Over time, this can lead to frustration, poor judgment, or burnout.

Self-care, in this context, is not checking out. It is learning to stay useful without becoming consumed.

It means asking: What impulse am I responding to? How do I personally identify with that impulse? What part of me needs this to be seen, valued, or vindicated? What power dynamic am I reacting to? Am I helping in a way that others can receive?

The goal is not to care less.

The goal is to care with enough clarity, pacing, and humility that your help remains helpful.

A quick ask: I’m doing positioning research for the product I manage, and I have a goal of running 50 short sessions over the next couple weeks. It’s 30 minutes. I’ll share a short presentation/demo, then spend the rest of the time on feedback and questions. I’d really appreciate the help, especially if you work in product operations, program management, or working on an “AI operating model” transformation. Any help is appreciated!

Book a short research session

This post is about the people who built the fiefdoms now looking to AI to save them from the fiefdoms, and why that will only work if we are honest about what those fiefdoms were built to avoid in the first place.

Unfiltered Saturday morning coffee writing engaged.

The people who built the fiefdoms are now complaining about the fiefdoms That is the part I can’t stop thinking about.

Some of the same people who benefited from riding the ZIRP wave to safer places of leadership are now waxing, not very poetically, about flattening orgs, 10x engineers, getting into the details, reducing bureaucracy, and getting closer to the work. The people who helped build the system are now turning around and saying the system is out of control.

And to be fair, the system is (and was) out of control.

But it did not come out of nowhere. The GM fiefdom model was built on assumptions that, at the time, probably felt reasonable. The first assumption was that autonomy creates speed. If you give a leader a clear area, a team, a budget, and a mandate, they can move faster than if every decision needs to be negotiated across the whole company. The second assumption was that business accountability creates focus. If a leader owns the outcome, and not just the work, they will make better tradeoffs. They will act more like a general manager than a functional lead.

The geometric problem

The third assumption was that as an organization gets larger, you need people “at the head” of these things. You need leaders who can absorb complexity, make calls, and keep the system from collapsing under the weight of everyone needing to talk to everyone else. It was a geometric problem. And on some level, I think there was an intuitive appreciation for Dunbar’s number. People knew there were limits to how many people could collaborate closely, how much context people could hold, and how much coordination a group could tolerate before everything slowed down.

So the answer became: create smaller worlds, give each world a leader, give each leader accountability, and let them run their business. That is the GM mindset. And in the ZIRP era, you saw a lot of it. You saw business-minded product leaders grow by adding more and more “products.” You saw more layers, more sub-orgs, more areas, more heads of things. You saw “product” become a container for almost any sufficiently large bundle of work, even when the thing being called a product was not really a product in any meaningful end-to-end sense.

The pain was always there

Anyone working in those environments felt the problem viscerally.

Dependencies compounded. The end-to-end experience became harder to reason about. Things that were supposedly separate turned out to be deeply connected. One team’s work created a blast radius for another team. The customer did not experience the org chart as cleanly as the org chart experienced itself.

People would say, “We need to focus on the end-to-end experience.” Other people would say, “That’s too hard.” And in a way, they were right. It was too hard, given the structure. It was too hard because senior leadership was unwilling to prioritize across fiefdoms. It was too hard because the leaders inside those fiefdoms had self-interest. It was too hard because the system had created local accountability without enough shared responsibility for the whole.

So the company kept barreling forward in ways that continued to perpetuate the problem. The coordination burden moved downward. The people closest to the work were left to discover the dependencies, negotiate the exceptions, route around the politics, and absorb the ambiguity. After a while, once they realized no one was going to resolve the underlying structure, they resigned themselves to functioning the best they could.

Now enter AI

Suddenly, AI appears to offer a way out. What if we did not need all of those fiefdoms? What if smaller teams could get more done? What if AI could act as the coordinator, the aligner, the context-transferer? What if more people could “work together” without actually needing to work together in the old way?

There is something real there. AI can reduce information friction. It can summarize. It can retrieve context. It can help people see patterns. It can surface dependencies earlier. It can make smaller teams more capable. It can lower the cost of keeping context moving across a flatter organization.

But context transfer is not the same thing as shared understanding. AI does not clarify who decides. AI does not neutralize incentive misalignment. AI does not resolve contested ownership. AI does not create the slack needed to coordinate well. AI does not magically fix the political economy that made the fiefdoms feel untenable while allowing them to persist anyway.

The real opportunity

The opportunity is not “AI lets us pretend we do not need to choose.” The opportunity is that maybe, finally, we make the hard organizational choices that should have been made anyway: clearer end-to-end ownership, decision rights that match responsibility, senior leaders willing to prioritize tradeoffs, and smaller teams with enough autonomy to move without recreating the old mess.

In that world, AI is genuinely useful. It becomes a cheap context layer. It helps teams see dependencies. It helps leaders spot conflicts earlier. It helps the front lines avoid carrying the full coordination tax alone. But that only works if the organization has done the real work. AI can amplify a coherent operating model. It cannot substitute for one.

The new coordination theater

What gets in the way of that opportunity?

AI can create a new kind of coordination theater: the appearance of working together without the friction of actually deciding together. This is why I care more about meetings and collaboration now than I ever have before.

People with a bias toward working alone suddenly have a whole new quiver of tactics to avoid working with other people. They set up agents. They send copious documentation. Their agents talk to your agents. They shut down conversations with hastily pulled-together, but very persuasive, deflectors. I am not saying this is intentional or malicious. But if you are tuned in a certain direction, AI can accentuate that tuning.

If someone was already allergic to “groupthink,” and they now exist in a world where agents do their bidding, then the future is now. Meanwhile, people who see value in collaboration are overloaded trying to handle the overflow of decision-making, noise, and responses to all of these async tactics. They are desperate to be thoughtful while dealing with a deluge of theoretically replaceable moments.

The old problem in a new shape

There is potential for way more WIP, and people only have marginal control over it, though they imagine their agent-form does. It sits in their mind, eating away at focus. So yes, AI can help us move beyond the fiefdom model, but it can also recreate the same problem in a new shape. The old coordination burden was pushed to the front lines by org design. The new coordination burden may be pushed to the front lines by async abundance.

Good collaboration can save millions of dollars of wasted effort. It can be one of the highest-leverage things you do. But AI will not automatically make us better collaborators. It will not automatically make us flatter, clearer, or more coherent. Like a lot of things, AI can supercharge existing habits. It can supercharge avoidance. It can supercharge fiefdom-preservation with better prose. It can supercharge solo-optimized work at scale. Or it can supercharge adaptation to the new reality, but only if we are honest about what the problem was in the first place.

Hint: It’s not some magic skill.

This post is for anyone who has tried to answer “What is a team?” and been caught between three things: confusion at why such a simple question was so hard, a gut feeling that if people could just describe reality honestly things would get so much better, and the deflating experience of watching that honesty get met with resistance.

Why is it so easy to describe how an organization actually works, and so hard to say it out loud?

Chris Argyris called these “undiscussables”: things everyone in the room can see, but that are tacitly off-limits to name. Not because the description requires special expertise, but because the act of describing threatens existing narratives, incentives, and power structures. The skill barrier is low. The potential political costs are high.

This post is about one of the most common undiscussables in product and technology organizations: the gap between how teams are described and how they actually work.

In workshops, provided we’ve built enough psychological safety, I’ve never had trouble unpacking the various “frames” of organizational design.

• The product-centric view: capabilities, features, value propositions, business outcomes.

• The design view: end-to-end experiences, customer journeys, touchpoints, information architecture, service blueprints that map the full service delivery chain including what happens behind the curtain.

• The technology view: architecture, interfaces, code ownership, the services that actually run in production. The platform view: deeper in the stack, a couple hops away from the customer, something that can absolutely be treated as a product but is an order of magnitude more complex to organize around.

• And then there’s the collaboration view: who is actually talking to whom, which Slack channels carry the real decisions, which meetings actually unblock work, which cross-team relationships hold things together that the org chart says should be separate. This one rarely shows up on any diagram, but it’s often the most accurate picture of how work gets done.

It was never rocket science.

These frames are in the room. People can describe them. People know them. The question is what to do next. How to take that reality and deal with it. Or not.

The Tension Between Frames

Even in organizations that have ostensibly adopted cross-functional teams, product management, design, and technology hold different views of team structure, purpose, and ownership.

Product divides the world into capabilities, “products,” feature areas, whatever framing the strategy demands. Design sees customer segments, end-to-end journeys, and touchpoints that often span multiple product areas. Technology has varying degrees of real-world alignment to either mental model. Not because they don’t want to be aligned with value. They do. But they’ve got systems and architecture to contend with, and the legacy of decisions made over years.

It is easy to McKinsey on in and say “these are your real products.” But McKinsey wasn’t there during the time the company was running a well-oiled feature factory and building a massive amount of organizational and technical debt in the process.

A mapping needs to take place. And teams fall across a spectrum: from high coherence, where the product view and the tech org naturally align, to deep misalignment, where the technology organization reflects architecture, and technical domain ownership that bears little resemblance to how product or design thinks about the world.

The cracks start to show first with UX and product.

Designers get assigned to multiple teams, or to a single “product” that multiple engineering teams serve. A designer might see the customer journey as one continuous experience while product has carved it into three capability areas and engineering has split it across five services. PMs compete with each other over a shared “resource” (a team). One PM needs the coordination of a dozen teams to deliver on what they see as a single capability. Elsewhere, four PMs are fighting over the efforts of one team because it owns a service at the intersection of multiple product areas. This is common.

This is often heavily dependent on architecture.

You can’t just flip a switch and magically rearchitect everything, or staff up, or will your way to perfect coherence. As Will Larson puts it: “The fact that something stops working at significantly increased scale is a sign that it was designed appropriately to the previous constraints rather than being over-designed.” The architecture was built for a different reality. The reverse Conway maneuver, intentionally restructuring teams to match the architecture you want, is compelling in theory. But the existing architecture constrains how quickly you can actually pull it off. And most aspirational models underestimate this.

And all of this assumes the org has a strategy that’s stable enough for the definitions, capabilities, personas, levers, jobs, to actually hold. The product taxonomy itself might still be in flux.

The Pendulum

I see a pendulum swing here.

First, a swing into “what are the actual products?” The org goes deep in that direction: naming capabilities, drawing taxonomies, mapping customer journeys, defining experiences. But that only gives you part of the view.

Then a swing into “but how are our teams actually structured?” Which tilts you to the technology reality: the actual org chart, the actual services, the actual on-call rotations, the actual code ownership. Design, meanwhile, is trying to hold the customer experience together across both frames, seeing the seams that neither product’s taxonomy nor tech’s org chart acknowledges.

The problem is that it’s very hard to have both going at once. You’re either looking at the product map or the team map, and the two rarely overlap cleanly. This is the crux.

It is actually relatively easy to name product areas and capabilities from a more academic angle. It is much harder to actually align architecture, incentives, funding, and team structure around those things.

There’s a history here worth remembering. In the mid to late 2010s, it became wildly popular to call everything “a product.” Every team was a product. Every service was a product. Every internal tool was a product. But that left companies with a vast complex of product-in-name-only. These weren’t products. They were teams relabeled to fit a narrative.

Now the pendulum has swung the other way. Companies are looking to “simplify,” so they claim to have very few products, or very few “journeys” or “experiences.” And that actually goes in the other direction: it obscures the collaboration reality for the purpose of simplicity. When you say you have three products and the truth is that each of those “products” requires the coordination of fifteen teams across four architectural layers, you haven’t simplified anything. You’ve just made it harder to talk about what’s actually happening.

If there’s an enterprise architecture trap, where capability maps get built in a vacuum and end up as a “museum of boxes” that nobody uses, there is also a market-tecture or product framework trap.

It picks one convenient model, like experiences, journeys, or jobs, squints, and imagines this to be true because somehow the categories are mutually exclusive and collectively exhaustive. They rarely are.

Design can fall into its own version of this: the service blueprint or journey map that elegantly describes the customer experience as a continuous flow, when in reality that flow is stitched together by six teams who don’t share a PM, a codebase, or a planning cadence. The domain-driven design community understands this: bounded context boundaries should match team boundaries, but those boundaries are discovered, not invented, and they rarely match existing org charts. Service boundaries, as one consulting group puts it, are “organizational confessions.” They reveal power structures and historical accidents more than intentional design.

And the domains themselves aren’t static. Strategic shifts are normal. What looks like a clean boundary today may fragment tomorrow. DDD can slip into replicating the semantics of a domain at a point in time while ignoring that a lot of the understanding is emergent, that we don’t know yet.

There’s another layer that often gets lost: organizational history.

Every team carries the sediments of decisions from past re-orgs, past strategies, past leaders. There’s knowing what they are now, but also understanding the evolution that got them here, which may have been lost to the sands of time. A team that looks puzzlingly structured today may make perfect sense when you learn it was the remnant of a 2019 platform bet that was half-funded and never fully unwound. But that context is rarely written down, and the people who carried it have often moved on.

Triad Fractals

The idea of “fractal” triads, product, design, and engineering mirrored at every level of the org, is very compelling. And it exists in many cases. But the incentive structures for those groups can be very different, even when the intent is aligned.

I’ve written about this before. Cross-functional teams are a mirror of the managers they report into. If the product director, design director, and engineering manager don’t know, trust, and actively collaborate with each other, the front-line team will struggle no matter how well-structured it is on paper. As David Dame observed: “The C-suite is cross-functional with complete oversight. The team is cross-functional with limited sight outside the teams. The middle management continues to be functional.”

The self-similarity breaks at the manager level. And it breaks because the incentives are not self-similar. Product, tech, and design managers face structurally different pressures: headcount costs, reliability accountability, matrixed assignments, career ladder ownership. The fractal looks clean on paper but fractures at the management layer.

There’s something else here that doesn’t get talked about enough. Engineering culture matters in many companies, more than org designers tend to acknowledge. Engineering managers actually manage people. They build team culture. They own long-term systems and the relationships around them. They run on-call rotations. They hire, mentor, and create career paths. These are the people building and shipping.

I’ve seen models that try to pull engineers into an overall “product is everyone” tent, only to discover that PMs are largely solo operators. Product orgs don’t do team culture nearly as well as they would like to believe. You can’t dissolve engineering’s team-building function into a product-centric model and expect the same cohesion to emerge. Engineering culture is a load-bearing wall, and ripping it out to satisfy an org chart aesthetic has real consequences. Larson is emphatic on this point: “Sustained productivity comes from high-performing teams, and disassembling a high-performing team leads to a significant loss of productivity, even if the members are fully retained.”

I’ve observed CTOs create complete parallel goal systems under the premise of the “technology strategy,” their managers running a separate set of OKRs alongside the team’s shared goals. Everyone reports into two goal hierarchies simultaneously. And I think this ultimately happened because the CTO was under pressure around reliability, performance, and technical debt, pressures that the product-centric model doesn’t absorb or even acknowledge.

Why It Stays This Way

Most systems in companies flatten this reality. You end up with a flattened version of what exists, a single org chart, a single taxonomy, a single set of team names, when the truth is that some product-team pairings have high coherence and others require elaborate mappings just to make sense of the world. There is resistance to calling out that complexity, because it strikes at incentives, org structure, hints of re-orgs, maybe even layoffs.

Herbert Simon defined design as “devising courses of action aimed at changing existing situations into preferred ones.” The gap between present and preferred is literally design’s subject matter. But design theory also warns that the “preferred future” org chart carries embedded assumptions about power, investment, and complexity that typically go unexamined. Whose future gets designed? Whose reality gets erased? Those questions are usually left implicit.

Tech actually carries the headcount costs. Product can name things whatever they want, capabilities, products, areas, but the salaries sit in the engineering budget. Product management is a small, lightweight function. Maybe 1 PM per 8-12 engineers. They can propose structures with relatively low personal risk. If the taxonomy doesn’t work, they rename it. The cost of being wrong is low for them.

Consider how this asymmetry plays out in practice. A single PM might be responsible for a “product area” that requires coordinated work from a dozen engineering teams. That PM draws a box on a slide and calls it their product. But each of those engineering teams has a manager, a budget, a hiring plan, an on-call rotation, and a set of systems they’re accountable for. When the mapping is bad, teams split across domains, specialists stranded, on-call rotations fragmented, tech leaders absorb the operational pain. Which then leads to attrition, burnout, reliability incidents, slowed delivery.

Meanwhile, in another part of the org, four PMs are fighting over the efforts of one team. That team owns a critical shared service. Each PM has their own roadmap, their own priorities, their own stakeholders. The team can’t satisfy any of them fully, and every sprint planning is a negotiation about whose work comes first. Product gets to describe the world; tech has to live in it.

Design sits in the worst position: a small team, usually matrixed or shared, with no budget authority and no structural home. They’re asked to be “part of the team” but spread across multiple product surfaces. They’re thinking in journeys, touchpoints, and service blueprints, seeing the customer experience as a continuous whole that spans all these arbitrary product boundaries. They can often see where the seams are, but have no organizational power to push back.

So you get a pattern. Product defines the narrative with relatively low cost if they’re wrong. Tech resists or quietly maintains a shadow structure because the cost of change is high. Design absorbs the incoherence because they have no structural power to fix it.

The engineering manager incentives reinforce this. Headcount scales with influence and promotion eligibility. Managers who own a technology area can recruit specialists and offer clear career ladders. They’re accountable for uptime and incidents regardless of the org model. Honestly describing misalignment can trigger a re-org where the reality-teller loses their role. And product strategy shifts quarterly while architecture pays off over years, so eng leaders rationally resist being reorganized around something that might change again in six months.

These are structural incentives, not character flaws, and treating them otherwise misses the point.

Pragmatic Change Aversion

What a lot of frameworks miss is that this is a highly politically charged situation. I experienced this in my past when I would do Kanban-related work. The act of dumping reality onto a board was theoretically easy. It was MUCH harder when that reality bumped up against the narrative tension that exists in most orgs.

And this manifests in ways that can’t be pinned immediately as “change aversion.” You have a manager whose team has been perpetually underfunded, who has been advocating for a platform approach for years, suddenly told that “you are a platform,” when realistically they are very early in that journey. And leaders have all these economies-of-scale assumptions around that, which the manager knows are very far off. Or you have the leader who is perpetually tired of explaining all the dependencies for their group, and knows they have worn that argument thin, basically pushing back on yet again showing those dependencies. Or the director who knows leadership’s penchant for glossing over the real-world complexity of things, and “knows how things go.”

This isn’t bad-faith politics. It’s earned skepticism from people who have context. The underfunded manager, the dependency-weary leader, the director who’s seen glossy narratives collapse: they’re reacting rationally to past experience. Calling it “politics” flattens legitimate, informed pushback into something dismissable. The political charge comes from the fact that surfacing reality threatens existing narratives, not because people are acting in bad faith.

Nils Brunsson’s “organized hypocrisy” theory offers a useful lens here. Organizations may actually need a gap between what they say and what they do. It lets them satisfy contradictory demands from different stakeholders simultaneously. The aspirational model keeps executives, boards, and customers happy. The real model lets practitioners get work done. The delta can be functional, a North Star you’re genuinely moving toward. But it becomes dysfunctional when it’s permanent theater that no one believes or acts on. The key question is whether leadership treats the gap as something to incrementally close, or as a convenient fiction to avoid hard decisions.

So What?

Organizations need a legible, aspirational model of how things should work. They also need an honest account of how things actually work. Most orgs struggle to hold both at once.

Closing the gap requires honest assessment, resource reallocation, structural change, and patience, all of which threaten the people and incentives currently in place. The tension is self-reinforcing.

Describing reality is not a hard skill. It’s not an expert activity. You can start with templates, spectrums, plain-language dimensions: relationship to technology, relationship to customers, how work arrives, how performance is assessed, what mandate the team actually has. Place your team along each spectrum. No certification required.

The hard part isn’t filling in the template. It’s the willingness to be honest about where you actually land. The skill barrier is low. The courage and trust barrier is high.

The question isn’t whether you can see the two (or more) org charts. You already can. The question is whether your organization can hold both views at once, and do something with the gap.

A note for change agents: don’t internalize this tension. It may just be the way it is. The organized hypocrisy may feel unbearable, the gap between the slide deck and the Slack channel may wear you down, and the impulse is to take it personally or burn out trying to close it yourself. But the incoherence isn’t yours to fix alone, and it may not be fixable in the way you imagine. What you can do is surf it. Find the pockets where the two org charts happen to overlap, where a team has enough coherence to move, where a leader is honest enough to work with reality instead of against it. The tension is where the opportunity lives. Not because the tension is good, but because it’s where the system is most ready to shift, if someone is paying attention.

Questions

1. If someone outside your company asked “how are your teams organized?”, could you give one answer that product, design, and engineering would all agree with?

2. What would happen if you put the real map of how work flows across teams on a wall in a room full of your leaders?

3. Which teams in your org are carrying the weight of multiple team types at once, and does anyone acknowledge that?

4. Where is the biggest gap between what your teams are called and what they actually do?

5. Are there things about how your teams work that everyone knows but no one will say in a planning meeting?

6. When was the last time a reorganization actually changed how work got done, versus just changing who reported to whom?

7. If you removed all the team names and org chart labels, could you still describe who depends on whom to ship something?

8. Are you trying to describe your teams as they are, or as you wish they were, and do you know which one you’re doing?

Side note, I have a live talk up on YouTube that I’m proud of called Single Player to Multiplayer: AI, Context, and Collaboration if watching/listening is more your thing.

Like a lot of leaders and practitioners I talk to, I’m trying to wrap my head around what I see happening in companies right now. The fatigue is real, the pressure is coming from many directions, and it’s impacting people in often very different ways.

I hosted a small TBM meetup in SF recently, and it felt so refreshing to be chatting in person, without the weight of optics, hype, dancing to company norms, and the usual performative composure. One thing that stood out was the mix of optimism and genuine excitement, with an appreciation for things being “not ok” (especially if you’re really paying attention).

I keep coming back to whether existing principles still hold And if so, why they feel so hard to apply right now.

1. Why do some leaders seem so out of touch with the vibe at the moment? Or is it that they are very “in touch,” and what we’re seeing is a defense mechanism, or even an act of territorial aggression?

2. AI should mean more flow and less cognitive load. So why does everything feel heavier?

3. Why is middle management and glue people getting such a bad rap currently? Why are leaders claiming they are so in the dark about what is happening? Why are the normal instincts breaking down? Why are we repudiating the “normal” playbook?

Why, to quote the title of a recent post, are we Seeing Everything, Understanding Nothing?

It has driven me to some “back to basics” thinking. One model I’ve been playing with lately is the triad of Exception, Presence, and Delegation. The ideas aren’t new, but it has sparked some good conversations and thoughts.t

This post:

• The three motions and how they interact

• Mintzberg’s configurations

• Using examples to explore Scaffolding vs. Load-Bearing (Mulally, Chesky, and Huang

• Back to those questions

Three Motions

Consider three fundamental motions in management/leadership:

Exception-based

You set up systems to flag when something deviates from what’s expected, and only then do you intervene. Done well, these systems are also how you learn (individually and collectively). As Cedric Chin has written, approaches like Amazon’s WBR build a shared causal model of the business into people’s heads over time, and help them explore and refine that model. The exception system is the learning mechanism. (See: statistical process control (SPC), XMR charts, Amazon’s Weekly Business Review (WBR), RAG dashboards, management by exception (MBE).)

Presence-based

You “go see” (genchi genbutsu) for yourself. You stay close to the work to build firsthand understanding and develop the intuition that no report or dashboard can give you. Presence is also how expert intuition gets transferred. Design critiques, Pixar’s Braintrust, side-by-side pairing, apprenticeship. You can’t write down tacit knowledge. It transfers when people work together on real problems. (See: Gemba walks, management by walking around (MBWA), founder mode (the positive interpretation, not the pathological one), player/coach, skip-level meetings, ride-alongs.)

Delegation-based

You push authority to the people closest to the work. You align on outcomes, then trust them to figure out the how. Or as David Marquet put it after transforming a struggling nuclear submarine: “push authority to information, as opposed to information to authority.” (See: management by objectives (MBO), commander’s intent, Theory Y, subsidiarity, servant leadership, self-organizing teams, mission command.)

These labels are imperfect. “Delegation” hints at prescriptive orders, but it also includes bottom-up self-organization and peer-to-peer alignment. “Exception” hints at mechanistic control, but exceptions can be emergent and intuitive, not just dashboards with thresholds. And “presence” doesn’t necessarily mean in-person. It means synchronous, engaged, intentional attention to the details. The boundaries blur. But the labels are useful enough to work with.

The Virtuous (Or Wicked) Loop

When the three work together, they create a virtuous loop. When they don’t, you see a lot of familiar org-stress anti-patterns.

Exceptions

Exception-based approaches, when they work well, free up time and attention for presence and delegation. Focus goes where it is needed most, and over time, and ideally with coworkers, you build an intuition for what drives (or causes drag) for the business.

Without presence and delegation, the exec says:

We have great data. The dashboards are all there. People just need to use them.

The team says:

We have dashboards for everything, but no one knows what any of it means. When leadership actually looks at them, it triggers a completely random fire drill. No one can connect it to what is actually happening in the technical and product details. Everyone scrambles, but no one has the authority to actually fix anything without three levels of approval.

Trap: Confusing legibility with understanding. The data looks clean from the top, so you forget no one closer to the work helped make sense of it.

Presence

Presence builds the intuition to recognize exceptions and put them in context. Presence also builds credibility (when wielded with humility), along with the relationships, alliances, and shared understanding that make delegation actually work. You can convey guidance, calibrate judgment, and build trust in ways that docs and dashboards can’t. It also builds trust that leaders will act responsibly and skillfully when escalations happen.

Without exceptions and delegation, the exec says:

I need to be in the details. That’s how I add value.

The team says:

Nothing moves unless our VP is in the room. She’s in every meeting, and she’s exhausted, and so are we. We’ve stopped even bothering to think about it ourselves, because our thinking will go to waste.

Trap: Mistaking your own involvement for value creation. The team’s learned helplessness feels like proof they need you.

Delegation

Delegation creates local knowledge (and local presence) that improves exception systems. The people doing the work know which signals matter. You’re not using Nth-time removed RAG charts wrapped in wishful thinking and optics. Presence scales that up, down, and across the org. And delegation, done well (with coaching, back-briefing, and presence), scales everyone’s intuition. It brings other people’s judgment and presence up so the whole system doesn’t depend on one person’s attention.

Without exceptions and presence, the exec says:

We’ve empowered our teams. They have full ownership.

The team says:

They told us to own it, but no one told us what good looks like, and we have no guardrails to tell us if things are working. No one is close enough to the work to give us real feedback, or really understand the challenge. When we try to escalate, by the time it reaches leadership it has been watered down. Not worth it. So every team is doing something different and hoping for the best.

Trap: Treating autonomy as something you announce rather than something you build and nurture. Empowerment without shared context.

Mintzberg’s Configurations

Mintzberg mapped organizational configurations decades ago, and each one basically overweights one of these motions:

• Entrepreneurial (Simple Structure): The founder coordinates through direct supervision. All presence. Exceptions and delegation live in one person’s head. Fast and coherent, but the founder becomes the bottleneck.

• Machine Bureaucracy: Standardized work processes. Heavy exception-based. Delegation is highly transactional, leaving the front line with prescriptive and narrow mandates. Think assembly lines, compliance-driven industries. Works in stable environments. Breaks in dynamic ones.

• Professional Bureaucracy: Standardized skills. Heavy delegation. Trained professionals own the work. Hospitals, law firms, universities. Presence is peer-based. Exceptions are professional judgment.

• Divisionalized Form: Standardized outputs. Exception-based at the corporate level (performance metrics). Delegation to division heads. Presence is the quarterly review.

• Adhocracy: Mutual adjustment. Closest to the virtuous loop. Small teams, constant recalibration, distributed authority. But fragile and exhausting. Great for innovation, hard to sustain.

• Missionary: Standardized norms. Delegation via culture and shared beliefs. Netflix’s “context not control” fits here. Powerful when the culture holds. Brittle when it cracks.

Each configuration flexes in a certain way.

As Mintzberg put it: “Most organizations experience all five of these pulls; however, to the extent that conditions favor one over the others, the organization is drawn to structure itself as one of the configurations.” The shape depends on the context. Organizations use what they need to use, and the mix shifts over time.

Scaffolding vs. Load-Bearing

How does this all play out in companies, and with leaders?

Scaffolding

Some leaders embody all three.

I stumbled on a random YouTube interview with Alan Mulally recently, and the interplay was obvious.

• He had 37 years of engineering credibility at Boeing (lead engineer on the 777). That presence meant people took him seriously when he walked in the room at Ford. (This was before Boeing’s well-documented safety crises, which many attribute to drifting away from exactly this kind of culture.)

• He introduced a weekly Business Plan Review — green, yellow, red. But the exception system only worked because he was present every week and made it safe to show red. Without that, it was just another watermelon chart.

• His “Working Together” philosophy pushed decision-making out to the team. But delegation only worked because everyone was looking at the same signals, in the same room, every week.

Each leg made the other two possible, and his presence was scaffolding.

The goal was to build systems and culture that could hold without him in the room. A caveat: it’s easy to build heroic narratives around turnarounds. Phil Rosenzweig’s The Halo Effect warns that we routinely attribute success to leadership qualities after the fact, working backwards from the outcome. Ford’s stock dropped 40% under Mulally’s own chosen successor. The systems didn’t hold the way the story suggests. Still, the interplay between the three motions is instructive, even if the retrospective narrative is cleaner than the reality.

Founder Mode

Now compare that to the “founder mode” movement. In 2024, Brian Chesky’s approach at Airbnb became a rallying cry for hands-on leadership. The backstory matters.

From 2015 to 2019, Airbnb was in full ZIRP-era expansion mode. Experiences, Plus, Luxe, Trips, transportation, a magazine, restaurant reservations through Resy, a massive push into China. New divisions for every new opportunity. Chesky followed the conventional playbook: hire good people, empower them, get out of the way. “I did all these things everyone told you to do,” he said later, “and the results were devastating.” Fiefdoms formed. Costs rose. Employees worked 80 hours and got 20 hours of productive work. Meetings about meetings about meetings.

From my vantage point, however, the drift wasn’t a failure of delegation.

It was delegation without exceptions or presence. No shared signals. No Schelling points for autonomous groups to coordinate around. Alex Komoroske’s coordination headwind framework explains this well: as organizations scale, coordination costs grow with the square of the number of people involved.

His Schelling point model goes further: when you increase the number of equivalent-looking options (more products, more growth vectors, more parallel bets), coordination actually gets worse, not better. Even with communication, people split across the options. Without a clear shared focal point, the organization fragments. That’s exactly what ZIRP-funded sprawl did. It created a dozen plausible priorities with no shared signal to coordinate around. The slime mold with too many directions and no gradient to follow.

When COVID hit and wiped out 80% of Airbnb’s revenue, the initial response was standard crisis management: hiring freeze, marketing cuts, exec salary cuts. Then in May 2020, Chesky laid off 1,900 people (25% of the company) and killed entire divisions: Studios, transportation, Luxe, Plus. That was triage. The organizational redesign came next, over 2020 and 2021. He eliminated the divisional structure, moved to a functional org, and started personally reviewing everything before it shipped. “Everyone’s gonna work on everything together,” he said. “There are no longer swim lanes. There’s one roadmap.” The instinct was right. Go high-presence in a crisis. That’s exactly what Mulally did at Ford.

The Difference

The difference is what happened next.

Mulally used his presence to build shared exception systems (the BPR) and restore delegation (”Working Together”). His presence was in service of the other two motions. Chesky used his presence to replace them. He became the coordination layer, the exception detector, the quality bar, the context holder. As of mid-2025, he was still saying “I’m still in founder mode. Like, hire, fire, promote, and manage.”

More recently, Airbnb has started evolving toward what they call “structured autonomy,” with AI-augmented squads and 40% fewer managers. Whether that’s rebuilding the other two legs or just replacing the middle layer with AI is an open question. It’s also worth noting that behind every celebrated founder-mode CEO, there are usually people doing the actual thoughtful and disciplined org design work: building the systems, operationalizing the vision, sometimes working around the founder to make things function.

The founder gets the narrative. The other two motions still have to happen. Someone is doing them.

Founders do have something real and hard to replicate. Vision, earned legitimacy, pattern recognition, taste. Mintzberg’s Entrepreneurial configuration validates this. Direct supervision from the apex/core of the org is a legitimate coordination mechanism with genuine strengths. But Mintzberg also identifies the ceiling. As the organization grows, the structure has to evolve toward externalized coordination. Standardized systems. Distributed authority. Founder mode ideology says: don’t evolve.

A friend at a large US bank, the kind of place where “conservative” and “risk-averse” are core identity, told me this language has seeped into their leadership conversations. “Founder mode,” “be in the details,” “cut the middle layer.” It’s mainstream now. But as Venkatesh Rao noted in his analysis of Komoroske’s work, “leaders diving in to help out” is one of the predictable pathological responses to coordination headwind. Not a solution. It is a symptom dressed up as a leadership philosophy.

The self-reinforcing loop tightens and spirals.

The founder stays involved because the context lives in their head. The team never develops that context because the founder is always there. The founder concludes they must remain involved. Whether this works long-term at Airbnb is an open question. But the pattern is clear: the medicine became the diet.

Then there’s Jensen Huang. He also has 55 to 60 direct reports and a famously flat structure. On the surface it looks like Chesky’s playbook. But Huang doesn’t review everything. He doesn’t do 1:1s. Instead he built systems: weekly “top 5” emails from rank-and-file employees, all strategic information shared company-wide, group problem-solving sessions he calls “extreme co-design.” The flat structure isn’t Huang being the coordination layer. It’s removing layers so information flows faster. And Nvidia’s near-death in the 1990s (one month from running out of cash) became a cultural norm that drives urgency without depending on his presence in every room.

Back to Those Questions

At the start I asked three questions. The triad doesn’t answer them definitively, but it does reframe them in ways I find useful. And AI, which promised to supercharge all three motions, is making each of these dynamics worse.

Why do some leaders seem so out of touch?

Because they’re reading the exception signals (the dashboards, the rollups, the AI-generated summaries) and concluding they understand what’s happening. Without presence, they don’t feel what the numbers can’t show: the fatigue, the learned helplessness, the withdrawal of discretionary effort. The employee engagement surveys tell a story, but when you try to get the straight story…crickets.

Exception systems also depend on a stable baseline, and right now the baseline itself is shifting. New tools, new roles, new competitive dynamics. In VUCA conditions, the exception system doesn’t just miss things. It actively misleads, because the signals look familiar even when the underlying reality has changed.

And some leaders aren’t out of touch at all. They see it clearly and have decided the moment calls for consolidation, pulling authority back to the center, tightening control, using the AI transition as cover for a structural power grab. That’s not cluelessness. It’s presence-without-delegation: “I’m close enough to see it, and what I see tells me I should hold on tighter.” The defense mechanism and the territorial aggression are both real. They’re just different failure modes of the same broken loop.

Why does everything feel heavier, not lighter?

More signals, more inputs, more context flowing to people who are already overwhelmed. AI tools amplify existing overload patterns rather than enabling deeper effectiveness. And AI tries to replace presence with context transmission, but context isn’t something you transmit. It’s something teams create through interaction.

The cognitive load isn’t coming from the work itself. It’s coming from the gap between how much is now visible and how little infrastructure exists to actually process it. Meanwhile, delegation doesn’t move without trust, and trust is in short supply. The “supply lines” of information that delegation depends on are stretched thin and pulled in competing directions: AI-generated summaries flowing up, top-down mandates flowing down, reorgs reshuffling who knows what.

When people don’t trust the information they’re working from, and don’t trust that their judgment will be backed, they stop exercising authority even when they technically have it. And most people don’t yet know how to use AI for multiplayer mode. The default is solo prompting, solo generation, solo review. AI doesn’t create bad habits, it turbocharges the ones people already have. If your team’s pattern was already “work alone, sync in meetings,” AI just makes you a faster, more isolated version of that.

Why are glue people and middle management getting such a bad rap?

Because they’re invisible to the exception leg and delegation problems are easy to scapegoat. Their value doesn’t show up in dashboards or deliverables. It shows up in the quality of decisions made three levels away, in the trust that lets a team escalate early instead of late, in the context that turns a mandate into something people can actually execute.

AI can reproduce the artifacts glue people produce, but it cannot reproduce the connective tissue: the judgment, the legitimacy-building, the social bridging. Remove them, and you get the thing leaders keep complaining about: “I don’t know what’s happening, no one is escalating, everyone is working in silos.” The question is whether we’re genuinely rethinking how authority and judgment flow, or just automating old models faster. We’ve just removed the people who made it work, and now we’re blaming the playbook.

This is true even in organizations that were functioning well before. An org that was hyper-adapted to one configuration (a Professional Bureaucracy that ran beautifully on delegation, a Machine Bureaucracy with finely tuned exception systems) may find that the current moment demands a fundamentally different mix, and the muscles for those other motions have atrophied. The adaptation that made them strong is now the rigidity that makes them fragile. It’s not that the playbook was wrong. It’s that the environment shifted, and the organization’s repertoire didn’t shift with it.

The interplay (exception informing presence, presence enabling delegation, delegation improving the signals) is what makes organizations actually function.

Same principles.

Different context.

Almost ten years ago, Arlo Belshee used a line that stuck with me: “Org design is basically about solving the puzzle of what must be consistent, and what you’re willing to lose to keep it consistent.”

I've written about consistency, and minimally viable consistency, before (Part 1, Part 2). In this post I want to explore what I've been calling sharp consistency, flexible consistency, and legible variety. You work with all three in your quest to find minimally viable consistency.

Understanding this is also a big unlock for where and how AI can be valuable for teams. As with most things, the devil is in the details. AI might make things genuinely more locally rich without sacrificing alignment, or just flatten everything.

A quick review of the core idea before I go somewhere new.

Why consistency?

Consistency in an organization reduces coordination costs, enables work and context to flow across boundaries without a translation tax, makes the system legible above the team level, supports faster feedback loops through apples-to-apples signals, and lowers cognitive load for anyone who moves between contexts.

It also acts as a scaffold for learning. When people are new to a role, team, or practice, shared structure gives them something to follow until they build their own intuition. It helps people get up to speed faster and creates a common language for coaching.

But consistency isn’t free. In fact, sometimes it costs a great deal.

Why minimally viable consistency?

Consistency has diminishing returns and escalating costs.

Each additional constraint adds governance burden and reduces local fit. Over-consistency kills responsiveness and creativity because teams can’t adapt to their domain without fighting the system. It generates performative compliance where people fill in the fields but the data means nothing.

You’re always looking for the most upside with the least downside. If you can achieve the same consistent behavior and outcomes with fewer negative side effects, that’s what you’re shooting for.

The calculus here depends on context. A large enterprise with regulatory requirements, complex dependencies, and hundreds of teams coordinating across boundaries will genuinely need more consistency than a scaleup with fewer dependencies and more autonomous teams. Neither is wrong. They produce very different answers to the question of how much consistency is enough.

MVC asks: what is the least consistency we need to get the benefits above, without paying the costs of over-standardization? Getting this right is equal parts skill, science, and art.

Three approaches

Not all consistency works the same way or asks the same thing of people. When you decide what to make consistent, you’re actually choosing between three different strategies:

Sharp consistency

A small number of things that are opinionated and uniform. It can be a hard rule, but “sharp” also means spiky, provocative, designed to get people thinking. The opinionatedness is part of the point. It creates a strong frame that shapes behavior through the clarity of the stance, not just through enforcement. Use when the value is in the sameness itself, and when the opinion embedded in the constraint really matter. Example: every team has named goals and input metrics, surfaced weekly in the same format. The opinion here is that teams should be accountable to outcomes they can influence, and that this should be visible.

Flexible consistency

Things that are consistent because they share an intent, but bend to local meaning. Use when the value is in the shared purpose, not the shared form. Example: every team has a “work unit” object that must be less than a quarter in duration, but can represent anything (a feature, an experiment, a spike) and links to whatever context the team needs.

Legible variety

A consistent way of describing inconsistency. Things that are intentionally different across teams, but the differences are named, visible, and navigable. You might challenge why this is a form of consistency at all, but the consistency is in the effort to name the variety. You are consistently explicit about what’s different and why. Use when the work is structurally different across groups and people need to orient quickly without requiring sameness. Example: the org has five team types (platform, product, enablement, growth, ops), each with a different cadence and reporting shape, all documented so anyone can look at a team and know what to expect.

A basic portfolio

Here’s what it might look like when you mix all three deliberately:

• Sharp: Every team has named goals and input metrics, surfaced in the same format quarterly. A common way to see priorities, outcomes, dependencies, and progress across the org. Non-negotiable.

• Flexible: Every team practices discovery, but we define the thinking that goes into it, not the exact artifacts, depth, or sequence. Teams apply better product judgment in their own way.

• Legible variety: Our platform teams, product teams, and ops teams have fundamentally different initiative shapes (a six-month cross-team migration, a two-week experiment, a continuous optimization effort). We name those shapes explicitly so everyone knows what they’re looking at.

Other frames

Here are a few other ways to look at the same three ideas:

As agreeing on what words mean:

1. We agree on what they mean, and we are going to all enact a very narrow definition. (Sharp.)

2. We agree on what they mean in principle, and we’ll adapt accordingly. (Flexible.)

3. We agree we disagree on what they mean, but it is important to know how we disagree, and why it matters. (Legible variety.)

As a computer science analogy:

• Sharp consistency is a strict schema (everything must match exactly, and the strictness is opinionated enough to trigger thought about what you’re putting in).

• Flexible consistency is an interface or protocol (you define the contract but not the implementation).

• Legible variety is a tagged union (you enumerate the valid variants, each with its own shape, but the system knows all possible shapes and can route accordingly).

Each of these has risks.

Sharp consistency can stop matching reality but stay enforced anyway, so people route around it. Flexible consistency can be interpreted so differently that the shared part disappears entirely. Legible variety can accumulate too many types until the map becomes as complex as the territory.

The AI opportunity

Which brings me to AI and the jobs it can do well (and not as well).

Job 1: AI as translator between inconsistent contexts.

This lets you keep things inconsistent without jumping to consistency just for legibility’s sake.

AI is effective at translating between schemas. One group works in bets and experiments, enterprise wants initiatives under a strategic pillar with coarse-grained capacity. AI can serve as the translator, like the person who previously had the mind-numbing job of copy-recontextualize-pass-along. Teams retain local variety, AI handles the translation to the enterprise view.

The risk: AI translation replaces the sensemaking that happens when people communicate directly. The messy “wait, what do you actually mean?” conversations are where alignment actually forms. If AI-generated summaries enable management from on high and reduce those conversations, you get legibility without understanding. (Related: Messy Docs As Helpful Pattern.)

Job 2: AI as enabler of multiple concurrent frames.

This lets you stop forcing everyone into one “official” model and support multiple valid views of the same work simultaneously.

Companies naturally gravitate toward “one model to rule them all” because simply having one way is hard enough. They don’t embrace concurrent operating models or support multiple valid frames because the cognitive and coordination overhead of maintaining them is too high.

AI can break that down. The same underlying work can be viewed through different lenses depending on who’s asking. Finance sees budget allocation and cost centers. PMs see bets and learning goals. Engineering sees technical scope and dependencies. Leadership sees strategic pillars and progress. None of these is “the real one” that everything else translates from. They’re all valid frames, maintained simultaneously, without humans having to manually keep them in sync.

Again, the risk: humans keeping things in sync is how people actually learn, build shared understanding, and develop intuition about the system. If AI removes that friction entirely, you also remove the cognitive work that builds organizational sense-making. The translation was never just a tax. It was also a learning mechanism. (Related: Institutionalized Overload (Now With AI).)

Job 4: AI as a consistent coach for learning.

This lets you provide consistent guidance while people are building new muscles, adapted to their context.

When teams are learning new practices, they need consistent advice that still bends to their situation. AI can provide that: consistent guidance on what good discovery looks like, consistent nudges toward writing assumptions down before starting, consistent reminders to connect work to outcomes. But adapted to what this team is actually doing, right now. In the hands of more skilled coaches who configure and guide it, AI becomes a way to scale the scaffold without requiring that coach to be in every room.

The risk: coaching without relationship becomes compliance prompting. If the AI coach doesn’t have context on the team’s situation, history, and constraints, its nudges become generic best-practice nagging that people learn to dismiss. And if it replaces the human coach rather than extending them, you lose the judgment, trust, and adaptation that makes coaching actually work.

Questions to consider

• Where in your org are you forcing sharp consistency that should actually be flexible? Where is something “flexible” that has eroded and become meaningless?

• What are you calling consistent that is actually just a shared label with no shared meaning underneath?

• Where do you have variety that no one has bothered to name or document? Is it causing confusion, or is it fine?

• If you removed a consistency requirement tomorrow, what’s the worst thing that would actually happen? Who would notice?

• Are you asking for consistent behaviors when all you really need is a consistent interface?

• Where are people spending time translating between local reality and global formats? Is that translation building understanding, or is it just overhead?

• What consistency exists today only as a scaffold for learning? Has the learning already happened? Can you release it?

• If AI could handle the translation for you, would you actually trust the output? What’s missing for that trust to exist?

• Where are you stuck in “one model to rule them all” not because it’s right, but because maintaining multiple frames felt too expensive?

I’ll be hosting a small TBM pop-up meetup next week in San Francisco (financial district) on Wednesday, May 6th. Let me know if you’re interested. I might be able to find a sponsor. The theme: multi-player mode AI.

SF TBM POPUP

The AI Playbook

Everyone wants tactical advice on “how to AI.” But I keep arriving at the same conclusion.

We already know a lot, but struggle to explain it in the new context.

We don’t know a lot, but aren’t willing to sit with that uncertainty.

And the biggest threat is identity threat.

Most of the “tactical advice” I see either reinforces things we’ve known are broken for decades, or reinvents what we’ve known works under a new name. Very little of it is genuinely inspired or thoughtful. But the “nothing has changed” argument is also a safety blanket.

Consider things we already knew worked/didn’t work:

1. Writing strategy as a single-player activity and then flattening it into a four-pillar slide with no guiding principles, no decision heuristics, and nothing experienced people could latch into was always a bad idea. Before AI, after AI, doesn’t matter. If your strategy doesn’t help people make decisions, it’s not a strategy.

2. PRDs as a static document were always a bad idea. Before AI, at best, a static PRD was a one-time snapshot of thinking. It had some value as a forcing function to think things through, but decayed immediately. Teams confused the document with the understanding.

3. Pre-mortems were a thing way before AI. “Imagine this failed. Why?” Good teams always found ways to stress-test their thinking before committing. Now AI can be another adversary at the table, poking holes right alongside humans. Not replacing the conversation, but making it sharper.

4. Prototyping was/is a thing, way before AI. The instinct to make something tangible and react to it is old. Designers have always gone to great lengths to prototype. They’d use paper mockups, clickable wireframes, and throwaway code. Seeing and responding beats speculating in a doc.

(See below where I acknowledge that context is a big factor when it comes to good and bad.)

Bad and Good

Which leave us with two buckets:

1. AI makes bad ideas worse. AI just lets you generate these faster and with more false polish. Same bad idea, same trap, higher velocity. And the leadership pressure to check the AI boxes right now is intense — which only accelerates the rush to automate broken things.

2. Good ideas before AI can be supercharged with AI: Living documents, living context, prototyping as shared understanding, continuous co-design, outcome-centricity, “think big, work small,” making your meetings worthwhile, supporting real periods of divergence and convergence. These were always the right instinct.

Here’s a real example.

I recently looked at a team’s “AI transformation plan.” This team was already deep in broken patterns: time allocation as a proxy for capacity, story points as a broken measure of progress, gates everywhere in their SDLC, team members siloed by function despite being nominally on the same team, ship and forget, massive batches. Their AI plan? A “Governance Agent” to enforce the gates. A “prototyping step” bolted into the existing stage-gate process. AI-generated PRDs. Every broken mental model, now with AI. Not a single thing in the plan questioned the underlying model. It was the checkbox problem in its purest form.

Was this fear, a genuine lack of imagination, a smart response to constraints (see below), or something else? I don’t know. But AI was certainly going to make a struggling thing worse (except for some promotions).

Compare that to a team I’ve been working with through Dotwork.

They used AI to automate the repetitive stuff that was creating friction: status updates, keeping shared context current, summarizing decisions so people didn’t have to re-explain things in every meeting. They used it to prep for interactions, not replace them. Better 1:1s. More focused design reviews. Less “can you catch me up?” and more “here’s where I think we should push.” They weren’t adding AI to their process. They were using AI to have better conversations and spend more time on the hard, creative, judgment-heavy work.

The Unimagined. The Meta-Skill

Actually, it is four buckets. Let’s add:

3. There’s the stuff we haven’t imagined yet. Beyond fixing old bad ideas and supercharging old good ideas, there may be entirely new workflows, practices, and ways of working that don’t map to anything we did before. Things that only make sense when AI is in the loop. Some practices that were genuinely “good” were only good because of a limitation (cost, speed, tooling, access).
   
   This is also a huge emotional journey. When a practice you mastered needs to be retired, it’s not just a workflow change. It’s a huge and unsettling professional identity hit. People built careers and reputations around these things. Letting go is real.

4. And a meta-skill: Yes, bad vs. good is an oversimplification. Practices—good, bad, necessary—were always contextual. Something generally “bad” (like a static PRD) might have been the best option available given the constraints (team size, tooling, org culture, regulatory environment). Understanding why something worked or didn’t in a specific context is a skill unto itself. Understanding the influence of context on practices has always been a superskill.

And it’s even more important now. When everything is shifting—tools, constraints, what’s possible—the people who can read context, sense what actually matters, and adapt accordingly will thrive. That’s not a new skill. It’s the skill that always separated great practitioners from people following playbooks. The difference is that the pace of change now punishes rigidity faster and rewards adaptability sooner.

I have a background in music, and I watched this exact thing play out with DAWs. Same four buckets. Bad producers made worse music faster. More polished, more lifeless. Good producers found new creative territory they couldn’t have reached before. Whole genres appeared that only make sense because of DAWs. And the people who really understood why certain techniques worked? They adapted. They thrived. But I also watched talented people go through real identity crises. Some came through it. Some didn’t.

So four buckets: bad ideas AI makes worse, good ideas AI can supercharge, genuinely new things we haven’t imagined yet, and the meta-skill of reading context that ties it all together.

The Crunch

The irony is that the kind of thinking you actually need right now, systems thinking, the ability to shift between elevations, the ability to challenge your own assumptions, metacognition (of yourself, of others, of computational systems), is exactly what’s being discounted the most in the current environment. Everyone wants the tactical “how do I prompt better” and nobody is investing in the deeper cognitive work that determines whether you’re even solving the right problem.

And there’s a trio of identity pressures making this worse, especially for leaders.

1. One: projecting a new identity as “AI-forward” or “AI-native” because the moment demands it.

2. Two: not actually being able to handle the personal identity shift underneath.

3. Three: applying the same outdated models while wearing the new label. So you get people performing transformation while resisting it internally and executing it with the old playbook. All three happening at once in the same person.

The Three Traps

I see three traps (I used a COM-B behavioral diagnostic skill I built for AI to generate the assessments below, which is itself a good example of encoding domain knowledge into a reusable tool):

Amplify Bad

First, completely ignoring what good looked like and just amplifying whatever outdated practices you had. It’s like you lay out how you work and just add a checkbox: “now use AI.” 80% of the time I check out someone’s “I built my chief of staff” or “second brain,” I see broken mental models now running on AI. Faster bad is still bad.

(COM-B: The motivation here is real but shallow. It’s pressure and FOMO, not genuine understanding. The deeper problem is capability: their mental model of “how work should be done” is already wrong, and they don’t know it’s wrong. The brokenness of existing practices has been normalized for so long it’s invisible. Easy AI tooling just amplifies all of this.)

Identity Threat

Second, for experienced practitioners, believing so strongly in your ability to detect timeless principles that you sit back and wait for the dust to settle. The trap is that confidence in your own judgment becomes the reason you don’t become an active part of shaping the reinvention. We need you more than ever.

(COM-B: They have the capability. The opportunity is there. But motivation is blocked by identity. “This isn’t who I am” or “I’m above this.” When it feels hard, they read that as confirmation it’s not for them, rather than a sign it matters. Overconfidence in their own judgment hides blind spots. And the emotional cost of admitting “I need to relearn” is high when your whole career says you’re the expert.)

Avoiding It

Third, not doing the work to understand what AI actually does and how it works. Without that, you can’t apply it to good ideas, you can’t recognize when a good idea was really just a constraint, and you definitely can’t explore what’s genuinely new.

(COM-B: Capability is the bottleneck. They don’t have a working mental model of what AI actually does, and there’s no obvious on-ramp to start building one. The learning feels expensive relative to an uncertain payoff, so it keeps getting deferred. But without this foundation, all the motivation and opportunity in the world can’t help. You can’t apply what you can’t comprehend.)

Paradox: The more certain someone sounds right now, the more likely they’re pinning everything on existing mental models. That can be good when the models are sound. It can be dangerous when the models are the problem.

The Journey

The journey, if you’re honest with yourself, sounds something like this:

1. “Something is happening here. I’m not sure what to make of it yet.”

2. “Okay, I think I see how this fits. Let me apply what I know works.”

3. “A lot of what we were doing was never actually good. We just normalized it.”

4. “Some of what I was doing wasn’t actually good either.”

5. “Some of what was genuinely good only worked because of a constraint that’s gone now.”

6. “If the things I built my career on don’t apply the same way... who am I in this?”

7. “I don’t know what this looks like yet. I need to be in it to find out.”

8. “The skill isn’t having the answer. It’s staying in motion while everything shifts.”

Conclusion

So where does this leave us?

• Some things were always broken. AI makes them worse faster.

• Some things were always good instincts. AI can supercharge them.

• Some things only make sense now that the old constraints are gone, and we haven’t even begun to discover most of them.

• And the meta-skill that holds it all together, reading context, challenging your assumptions, knowing when to apply what, has never mattered more.

The identity pressures are real.

And nobody has the playbook yet, no matter how confidently they’re selling one. The way through isn’t to cling to who you were or to perform who you think you’re supposed to become. It’s to stay in the work, let your identity shift with what you’re learning, and be open to the possibility that the most important practices haven’t been invented yet.

Five questions worth sitting with:

1. What practice on your team exists only because of a constraint that no longer applies? What would you do instead if you started fresh?

2. When you look at your “AI strategy,” how much of it is automating the existing model vs. questioning it?

3. What part of your professional identity are you protecting that might be keeping you on the sidelines of the reinvention?

4. If middle management skepticism is rational, what does that tell you about how the transformation is being led?

5. What would it look like to invest in systems thinking, metacognition, and contextual judgment as seriously as you’re investing in AI tooling?

You ask a hard question in a meeting and someone hears negativity. You name a risk and you’re a pessimist. You push on a plan because you think the team can handle it, and people wonder why you’re not on board.

Or maybe you’re on the other side. You’re trying to keep the team moving. You’re holding the group together through uncertainty. And then someone starts poking holes, surfacing risks, pulling the conversation into the weeds. You think: we were aligned. Why are you making this harder?

Both of these people think they’re being optimistic. Both of them are probably right. And both of them are probably fooling themselves about something.

I’ve been thinking about this for a while. Not just because it happens to me, but because I’ve watched it play out everywhere. I’ve written before about how experienced people who ask lots of questions get silenced, and how that silence compounds over time. But I’ve also watched the questioners use their questions as weapons, and I think we need to talk about that too.

Someone on LinkedIn put one side of it perfectly: “I’ve probably been called negative my whole career, mostly by people less invested in the outcome than I was. I don’t bother listing obstacles to a future I don’t believe in. That part is my optimism.” (Sean Coon) I get that. But it’s not the whole story. Because sometimes “you’re being negative” is a self-sealing argument where defending yourself proves the accusation.

And sometimes it’s accurate. The hard part is telling the difference.

Two kinds of optimism

There are two kinds of optimism that get confused all the time.

• The first is outcome optimism. “We’ll get there.” It protects morale. It keeps people moving. It holds the group together when things are uncertain. It’s valuable.

• The second is capability optimism. “We can figure this out.” It shows up as pressure-testing, naming risks, going deep on what could go wrong. Not because you doubt the team, but because you trust the team enough to handle the truth.

Both are real optimism, but they protect different things. Outcome optimism protects momentum. Capability optimism protects the quality of the plan. Teams need both.

I’ve explored a version of this as the “just” and “but” polarity. “Just do it” people favor action and simplification. “But what about...” people favor questioning and context. Neither is wrong. But when one dominates, the other gets pathologized.

There’s research on this I find useful. Psychologist Julie Norem studied people she calls “defensive pessimists.” These are people who mentally rehearse what could go wrong before a high-stakes situation. Not because they’re anxious wrecks, but because that’s how they perform best. When you force them to “stay positive,” they actually do worse.

And the reverse is true too. People who naturally stay upbeat perform worse when you make them dwell on risks. Both work. The problem starts when one group insists the other is doing it wrong.

But most workplaces only reward the first kind. The second kind, the probing, the questioning, the sitting in discomfort, gets read as doubt. As negativity. As not being a team player. Someone else nailed it: “Constructive optimism often gets read as negativity because it names the work honestly. ‘I think we can ship this, and here’s what has to be true’ gets heard as hesitancy.” (Eric Culus)

The system punishes it too

It’s not just interpersonal.

Organizations structurally punish the second kind of optimism. Saying “we can be better” implies something isn’t good already. That’s threatening. Pointing out improvements gets treated as a threat to whoever built the current thing.

Certain roles get cast as the negative ones by default. One finance leader told me he learned early to financially prove why a stakeholder’s idea is good, even when he immediately spotted issues, just to avoid being cast as the pessimist. A data leader said the same: “We’re another team that tends to get branded as naysayers.” Eventually, people just stop saying anything. Not because they don’t see the problems. Because the cost of naming them is too high.

And then there’s gender. The same words, the same tone, the same level of directness, and it lands completely differently depending on who says it. One commenter cut straight to it: “It’s called being a woman. We are always negative apparently even when we are optimistic.” And it doesn’t land the same for everyone.

The angry optimist

Someone told me that it’s the optimists who are angry all the time, because they can imagine how things could be. I think that’s right. The frustration isn’t about tone. It’s about the gap between what’s possible and what’s happening.

And if you’re someone who naturally holds multiple perspectives at once, that gap is exhausting. You’re carrying the weight of complexity while everyone around you wants a simpler story.

And this cuts both ways. Each side has a process allergy to the other. The capability optimist introduces uncertainty, sits in discomfort, probes assumptions. To the outcome optimist, that registers as “something is wrong.” The outcome optimist smooths things over, offers quick reassurance, radiates let’s-move-on energy. To the capability optimist, that registers as avoidance. Each side’s process is the other side’s allergen.

I’ve seen this play out as the “you’re making this too complicated” problem. One person’s exploration is another person’s analysis paralysis. And because these are felt reactions, not just intellectual disagreements, they’re hard to override with logic alone. You can’t just explain your way out of it.

Climbing mode and base-camp mode

The best teams I’ve seen don’t resolve this tension. They sequence it.

Think about elite performance environments. Competitive sailing, special forces, surgical teams. These groups are brutally candid when the situation calls for it. They challenge each other, poke holes, refuse to smooth things over. And then they shift gears. They commit. They stabilize. They execute.

Linda Hill spent a decade studying leaders of innovation at places like Pixar and Google. She put it simply: “Innovation rarely happens unless you have both diversity and conflict.” Not brainstorming where everyone suspends judgment. Actual heated, constructive arguments. She called it creative abrasion. The teams that felt comfortable but never fought stayed good, never great. The discomfort was the point.

The key is that everyone knows which mode they’re in. In base camp, you debate. You pressure-test the route, argue about the weather, challenge assumptions. That’s where the hard questions belong. On the climb, you execute. You commit and move.

The friction in most workplaces isn’t that people disagree about which mode is better. It’s that they’re in different modes at the same time without realizing it. One person is in base-camp mode, stress-testing and probing. Another is in climbing mode, committed and pushing forward. And they’re both confused about why the other person isn’t being helpful. I’ve called this the drivers vs. fixers problem.

When one mindset dominates, it creates self-reinforcing loops of exclusion. The drivers think the fixers are slowing things down. The fixers think the drivers are ignoring reality. Both are partly right. The move isn’t to pick one. It’s to be explicit: “Let’s spend 15 minutes in base-camp mode, then climb.” Create the container, then both modes make sense.

“I’m just asking questions…”

Everything I’ve said so far is true. Critical thinking is essential. Questioning the plan is how you strengthen it. Naming risks is competence, not negativity. But critical thinkers have a responsibility too. And a lot of them — a lot of us — don’t live up to it.

Asking hard questions is essential. It’s also a great place to hide. You can use critique to avoid committing. You can use questions to protect yourself from being wrong. You can perform skepticism instead of practicing it. Poking holes in other people’s plans while never putting your own on the table.

We all know the Question Person. They’re not honestly being critical. They are just being a jerk under the cover of rigor. They raise concerns without intent to act on them. They destabilize commitment mid-action. They project doubt without offering an alternative. That’s not capability optimism.

And optimists can fool themselves the same way. They think they’re “just asking questions” when really they’re only optimistic for their version of the future. Their questioning isn’t honest inquiry. It’s advocacy dressed up as curiosity.

I’ve written about how in-group loyalty pairs with out-group scapegoating. Critical thinking can become a tribal identity. “We’re the rigorous ones, they’re the naive ones.” At that point, it’s not inquiry anymore. It’s just another form of politics.

Decades of research on what’s called “constructive controversy” backs this up. Structured disagreement, where people present opposing views, sit in the discomfort, and actively search for better answers, produces better decisions and stronger relationships. But only under cooperative conditions. When disagreement happens in a low-trust or competitive frame, it turns destructive fast.

The difference between productive conflict and toxic conflict isn’t the conflict itself. It’s whether the people involved are actually on the same side. The climbing metaphor works here too. On the mountain, negativity isn’t seeing problems. It’s breaking the link between the problem and a constructive response. “This is going to go badly” without “here’s what we do about it” is not competence. That’s just amplifying fear.

Earned confidence

So here’s where I land.

The feel-good optimist can skip the work of actually testing their beliefs. They claim the outcome without doing the work that justifies it. That feels hollow to anyone paying attention.

The critical thinker can disguise fear, self-interest, or plain old stubbornness as rigor. They get to feel smart and careful while actually just avoiding risk.

Both need to ask themselves: am I doing this because it serves the team, or because it serves me? Before you react to being dismissed, before you escalate, ask yourself what you actually want. Validation? A specific change? To be right? The answer matters. The strongest version is something like: we believe we can handle reality, so let’s actually look at it. And then once we’ve looked, let’s commit and move. It requires honesty from everyone in the room. Especially the person asking the hard questions.

TBM posts linked in this piece

• Those Pesky Question-Askers

• The Self-Sealing Argument Trap

• Just and But

• “We Kind of Suck at That Right Now”

• Why Aren’t They Saying Anything?

• Why Reflexive Thinkers Need to Take More Breaks

• “You’re Making This Too Complicated”

• Drivers vs. Fixers

• Hot Takes and Parochial Altruism

• In That Space Is Our Power

1. Hope, Context, and Control

2. Seeing Everything, Understanding Nothing (The Context Trap)

3. Institutionalized Overload (Now With AI)

4. Legibility and Legitimacy

5. Before You Fire All Your Glue People Because of AI

6. Simple-player to Mutliplayer: Context Through Collaboration

At the day job, I’m deep in the question of how AI can help teams do more effective work, hence all the thinking below. It has highs and lows these days, with enough inspiring stories to keep me curious and hopeful.

If you and your team ever want to chat about this, reach out.

If you are using AI to reinforce broken mental models of how great software products get built, write the same old PRDs that wither on first contact with reality, generate box-checking business cases designed to shut out critique, decompose work into tidy cascades nobody believes in, and rinse all the value out of your customer feedback, you will supercharge whatever was already broken at your company with a deluge of polished markdown.

More artifacts, same blind spots.

But if you’re using AI in ways that are congruent with the true, collaborative nature of product development, that respect how context emerges and gets shaped, that speed up learning and synthesis, and that result in higher leverage conversations with teammates, you’re on the right track.

Co-design, co-prompting, evolving context(s), and shared understanding that compounds = right track.

Two Multiplayer Examples

Two personal examples of things working from the last 24hrs:

Lane Coherence

My coworker and I use Dotwork to pressure test the guiding principles for our stable workstreams, checking where our confidence has shifted and whether upcoming work is still in the right sequence. We take that readout as input into our next review session, where we reshape the principles to reflect what we currently believe is true. It doesn’t replace conversations. It makes them higher leverage. We use AI as an imperfect, eager-to-please genie (thank you Kent Beck) to help us do better work. We use Dotwork to keep our mental model as up to date as possible.

Co-Prompting

In the midst of writing this post, I took a break to grapple with a thorny date problem (the best!). Let’s go! First, my coworker explained that he had been adding some markdown files as context pointers in our codebase, and was excited for me to test them out using this as a use-case. I popped open our codebase in Cursor, and copied in a JSON file I had put together as part of a prototype (my initial effort to wrap my head around the problem). Then we “pair prompted,” him with his technical eye, and me with my customer eye, to figure out what we supported. Meanwhile he was taking notes on where there were gaps in his context pointers, and where we were burning tokens.

In twenty minutes, I learned a ton about our platform, he learned about an area of functionality he hadn’t checked out in a while, and we generated a couple options to discuss later with other team members. A couple minutes later, another coworker pinged me, and I was able to talk intelligently about how our system is architected while weaving in the customer’s overall need.

These are two examples of things working. Like any team at the moment, we have our fair share of misses. But we’re learning.

4Es

Both are great examples of multiplayer. There’s a lens from cognitive science, the 4Es (embodied, embedded, enacted, extended), that captures why these sessions worked:

• Embedded: our thinking was shaped by what we were sitting inside of. Dotwork’s lane principles and confidence levels, the codebase, the context pointers, the customer JSON. That surrounding context shaped what we even thought to question.

• Enacted: we didn’t read an output and nod. We reshaped guiding principles, poked at prompts, redirected in real time. Understanding came through doing, not consuming.

• Extended: neither of us could have held all of this in our heads alone. AI, the markdown files, the context pointers. They carried knowledge we could think with, not just refer to.

• Embodied: the back-and-forth mattered. My coworker’s technical eye caught things I’d miss; my customer eye caught things he’d miss. The pacing, the “wait, go back” moments, the way we traded the steering wheel. Not incidental to the outcome. It was the outcome.

In both examples, multiple people are bringing different perspectives, different knowledge, and different needs to the same session. Nobody is prompting in isolation and shipping the output. AI isn’t the collaborator (although I use AI that way too, when it makes sense, and when I would annoy the crap out of a coworker). It’s the surface the collaborators work on together. And the output isn’t a deliverable; it’s shared understanding that each person carries into their next conversation, decision, or piece of work.

Now flip it. What happens when someone works alone with AI, curating their own context, prompting in isolation? The 4Es reveal what’s lost:

• Embedded: you’re embedded in your own curated context. The environment you reason within is shaped entirely by what you chose to include. You can’t question what you didn’t think to put there.

• Enacted: the loop is prompt, read, revise, prompt again. AI goes where you steer it. No one redirects you. No “wait, go back” from a different vantage point.

• Extended: AI extends your cognition, powerfully. But it holds what you gave it, not what three people with different expertise would have given it. Deep but narrow.

• Embodied: there’s no other body in the room. No one frowning at something that feels off. AI can simulate multiple perspectives if you ask, but that’s directing a puppet show, not a collision of genuinely different stakes.

Single-player AI, through this lens, is accelerated isolation that feels like collaboration. It’s using AI as a cartographer for places you haven’t visited. The map looks authoritative, the terrain is detailed, the legend is clean. But nobody walked the ground, and they certainly didn’t walk it with other people who see different things, trip over different rocks, and ask different questions about the landscape.

Stigmergy

Multiplayer doesn’t have to be synchronous. Look at the pair-prompting example again, but focus on what happened before the session.

My coworker had been adding context pointers to the codebase on his own, days before we sat down together. When I opened the codebase, his thinking was already there, shaping what I saw and what I thought to ask. During the session, he was noting gaps to update for the next person. I brought in a customer JSON file that now lives in the repo for whoever comes next. A couple minutes later, I was on a call with another coworker, and the understanding from our session was already flowing into a different conversation.

There’s a name for this kind of coordination: stigmergy. Ants leave pheromone trails that shape what the next ant does. Termites build by responding to what other termites have already placed. Wikipedia works this way: each edit reshapes the environment the next editor encounters. No central plan, just traces that accumulate. The 4Es still hold, just across time. The environment my coworker shaped (embedded) was the environment I reasoned within, even though he wasn’t there when I opened it. Engaging with his traces was active, not passive (enacted). The markdown files carried his knowledge beyond the moment he wrote them (extended). And when we did sit down together, our different eyes made the traces richer than either of us would have alone (embodied).

Single-player AI is stigmergy for an audience of one. Your traces only loop back to you. Nobody else’s surprise you, and yours don’t compound for anyone else.

Campfires and Quests

But humans aren’t ants. We have more to convene about than which path to take.

We need more than trails. We need campfires and quests. The trails are the traces we leave for each other: context pointers, shared docs, evolving principles. The quests are the purposeful work we do between campfires: sometimes solo, but often together. Pair prompting a thorny problem. A designer and developer researching a constraint side by side. Two people with different expertise walking the same territory and seeing different things.

And the campfire is where we bring it all back together: the pair-prompting session, the live reshaping of what we believe, the collision of different eyes on the same problem. We need all three, because we also need to map the territory together, not just report back from solo expeditions.

Trails without campfires are a wiki nobody reads. Quests without campfires are solo adventures that never connect. Campfires without trails or quests are Groundhog Day: great conversation, nothing learned since last time, start from zero again.

The question isn’t “are you leaving traces?” or “are you having conversations?” It’s: are your traces feeding your conversations, and are your conversations updating your traces? AI can power both halves of that loop. But only if there are other people in it.

I made this diagram about eight years ago, documenting what designer/developer collaboration actually looked like on a team with real trust. No AI involved.

Joint prep, then a kickoff. Co-design together, then go off and research individually. Come back for a pairing test. Split up for deeper work. Reconvene. Iterate. Release. The rhythm is the point: go apart, come together, go apart, come together. Trails and campfires, long before I had those words.

Now weave AI into every phase of this.

1. The individual prep is sharper because AI helps you synthesize what you know before you walk into the room.

2. The co-design session is higher leverage because everyone arrives with context that’s already externalized, not trapped in someone’s head.

3. The “go off and do deeper work” phase leaves richer traces because AI helps you document what you’re learning as you learn it.

4. The pairing tests surface more because AI can hold the full history of what’s been tried and what’s changed.

5. The iteration cycles tighten because the context graph updates in real time, not whenever someone remembers to update the wiki.

I know there are people in 2026 who look at this diagram and say “AI makes all of this mess redundant. Why do you need the kickoff, the pairing, the back-and-forth? Just prompt it.” I’d say the opposite. Used responsibly, AI doesn’t make this redundant. It makes it accessible to teams that could never pull it off before, and even better for teams that already could.

AI doesn’t replace any phase. It makes the trails richer between campfires, and the campfires more productive because of the trails.

1. Hope, Context, and Control

2. Seeing Everything, Understanding Nothing (The Context Trap)

3. Institutionalized Overload (Now With AI)

4. Legibility and Legitimacy

5. Before You Fire All Your Glue People Because of AI

6. Simple-player to Mutliplayer: Context Through Collaboration

At the day job, I’m deep in the question of how AI can help teams do more effective work, hence all the thinking below. It has highs and lows these days, with enough inspiring stories to keep me curious and hopeful. If you and your team ever want to chat about this, reach out.

The hardest part of figuring out how to use AI at work is that our heuristics are right often enough to feel reliable, and wrong often enough to cause real damage.

We develop mental models for where AI fits. Those models work in some contexts. Then we carry them into contexts where they don’t work, and because the logic sounds the same, we don’t notice the difference until it’s too late.

1. People lose their jobs based on these calls.

2. Teams lose capabilities they didn’t know they depended on.

3. Organizations hollow out functions that took years to build, and discover the consequences months later when the problems are structural and the people who could have helped are gone.

The goal of this post is to help you make better calls about where to focus with AI. Where should you lean into the heuristic? Where should you be skeptical of it? What should you look for before committing?

And I want to make a passionate plea: before your organization goes off and fires all of its “glue people” on the assumption that AI can pick up what they were doing, please stop and think about what those people were actually doing. I have watched companies make this move. The ones who got it wrong didn’t realize it for months, and by then the damage was structural. You owe it to yourself, your teams, and the people who held your organization together to understand what you’re really replacing before you replace it.

The Basic Thesis

There are things we all know we should be doing at work but aren’t. AI can help with many of them. Follow that instinct.

But some of that work was only happening because specific people made it happen, and what those people were doing was far more than it looked like from the outside. The risk right now is that we replace the people, keep the visible artifacts, and lose everything underneath that made those artifacts matter.

This post is about how to tell the difference.

The “Should Do” List

In our work we are surrounded by things we know would help us take our work, and our company’s work, up a couple notches. But things get in the way.

We know we should cross-reference risks in our docs. We know we should keep a well-curated research library with insights linked to decisions. We know we should write good launch notes for our customers. The list goes on. .

And just like in our personal lives, all the stuff we know we should do tends to land in the “aspirational, but the real world got in the way” category.

In some orgs, those things happen sometimes:

Some people bend the curve because they are hired to do that thing, or because they really, really cared about it (and are good at it).

Before AI there were people who curated amazing personal knowledge management systems in Obsidian. They took atomic notes. They Got Things Done (GTD). But this was a rare breed. It was people who really cared about those things, who were particularly dialed in to doing that work.

Every company has those people who valiantly went above and beyond even when it wasn’t their job description: updating docs, closing the loop on outcomes, sending the thank-you note to the customer, dotting their i’s, spending that extra time on great facilitation.

And then there were the superstars, often in short supply, who did things as part of their job description that literally no one else would do because it was “not in their job description.” I know program managers who were magicians at aligning multiple teams towards an outcome without cramping everyone’s style. The product managers loved them because they were doing all the dirty work that didn’t fit in the time anyone else had, in ways that didn’t map to how anyone else identified with doing a good job.

In both the case of the informal advocates and the formally appointed role-holders, companies often have a love/hate relationship with the idea that there are people who “glue” everything together. As of late, glue people are getting laid off in many companies because they are the visible externalization of dependencies. Some people imagine AI can simply replace the activities that the informal unicorns and formally appointed connectors were doing.

Which brings us to the topic at hand.

The Heuristic

I’ve been saying recently that people are overthinking how to use AI. I say, very simply, that they should use AI to do the things they know they should do and aren’t doing. Don’t overcomplicate it.

Start with simple examples.

We know we should tailor release notes for different customer segments. That takes time. We don’t have time. So most companies don’t do it. Can AI do this well? Yes. OK. Do it.

Another one: we know we should write better updates and capture more context on our initiatives instead of letting stuff simmer in different systems, only to be forgotten and never updated. Can AI make this a more organic activity? Can it remind us to do it, nudge us, make it easier to spot things that are out of date, recontextualize it for different audiences? Yes. OK. Do it.

These seem relatively straightforward because our mental model is: we know we should do it, we know things get in the way, therefore we believe that using AI to assist us would be beneficial. And in a lot of cases that instinct is right.

Where It Gets Interesting

But let’s see how these behaviors chain together.

I have worked with companies that DID value those things, and assembled enough informal advocates and formally appointed job-doers to make them happen. They embedded the underlying behaviors and norms. They saw the benefit, so they kept on it. Without the magical elixir of AI.

And realistically, sometimes it “worked” and sometimes it didn’t. The constraint shifted. “I’m a leader, I don’t have enough time to read this.” “Nothing we are shipping that we are writing the release notes about is all that smart. Why did we prioritize it?” “Even with all of this data and information, it turns out no one is actually using it.”

When Your Instincts Are Right

The heuristic works when the actual barrier to the behavior is friction and cost. Specifically:

When the behavior is already understood and practiced, but painfully.

The activity is mandatory or deeply valued. People do it. But the environment fights them. It takes too long, the tooling is clunky, the workflow has too many steps. The person doing it is essentially absorbing infrastructure cost with their own labor. AI legitimately reduces that cost. Tailoring release notes for customer segments, keeping project status documents current, cross-referencing risk logs. When the only thing standing between “we should” and “we do” is the hours it takes, AI is a direct solution.

When the behavior is valued and agreed-upon, but consistently displaced by competing priorities.

Everyone agrees this matters. It keeps getting bumped. The work isn’t hard or mysterious. It’s just never the most urgent thing. Here AI works because it lowers the effort cost enough that the behavior survives contact with a busy week. It doesn’t need to become anyone’s top priority if it only takes a fraction of the time it used to.

In both of these cases, the instinct is correct: the gap between “should” and “do” really is about cost and time, and AI genuinely closes that gap.

When Your Instincts Break Down

The heuristic breaks when the actual barrier to the behavior isn’t friction and cost, and you don’t realize it.

• When the behavior exists only in pockets, carried by specific people.

• When the behavior is “agreed and valued” but the system doesn’t actually reward it.

• When the behavior was aspirational and nobody actually knows what “good” looks like.

• When systemic forces were actively preventing the behavior.

When the behavior exists only in pockets, carried by specific people.

It looks like the gap is effort: “If only we had more time, everyone would do what Sarah does.” But the reason Sarah does it and others don’t isn’t usually time. Sarah reads the room. She knows when to surface information and when to hold it back. She has the trust and relationships that make her updates credible. She understands the political landscape well enough to frame things in ways that land. She builds shared understanding across teams that don’t speak the same language. She has judgment about what matters that comes from years of pattern recognition.

When you “use AI to do what Sarah did,” you replicate the visible artifact (the update, the summary, the aligned roadmap) while losing the judgment, social navigation, and legitimacy work that made the artifact useful. AI produces the document. Nobody acts on it. Not because the document is bad, but because Sarah wasn’t just writing documents.

When the behavior is “agreed and valued” but the system doesn’t actually reward it.

Everyone says cross-referencing risks matters. But the incentive structure rewards shipping features. The performance review doesn’t mention documentation quality. The people who did maintain risk logs were either intrinsically motivated (and eventually burned out) or occupied a formal role that justified the time (and is now being cut). AI makes it cheaper to produce the risk log, but the risk log enters the same system that never rewarded maintaining it. The constraint wasn’t production cost. It was that the organization doesn’t actually value the output enough to consume it. Making it free to produce doesn’t change that.

When the behavior was aspirational and nobody actually knows what “good” looks like.

“We should be more data-driven.” “We should have a learning culture.” “We should close the loop on outcomes.” These are identity-level desires, how we want to see ourselves, without agreed-upon practice, defined skill, or clear specification of what it means to do it well.

AI can produce something that looks like the aspiration: a metrics dashboard, a retrospective summary, an outcomes report. But without shared understanding of what good looks like, without the capability to interpret and act on the output, and without organizational agreement on what counts, you get artifacts that perform the aspiration without delivering the outcome. Worse: the presence of the artifact can create false confidence that the gap has been addressed.

When systemic forces were actively preventing the behavior.

Sometimes the reason people aren’t doing what they “should” do is that the organization, through its power dynamics, political structures, or implicit rules, makes it unsafe or unrewarding to do so. The person who raised concerns in the risk log got punished for slowing things down. The team that invested in documentation was told they weren’t shipping fast enough. In these cases, AI doesn’t remove the barrier. It may actually increase the exposure: now there’s a visible AI-generated artifact pointing at problems the organization has been structurally avoiding.

The Constraint Shift

The deepest version of the break is this: even when AI successfully produces the artifact, the constraint shifts rather than dissolves. Companies that did invest in the “should do” behaviors, with real people, real effort, real norms, discovered this repeatedly:

• “We have beautiful release notes. But nothing we’re shipping is worth writing release notes about.”

• “We have the data. But leadership doesn’t have time to engage with it.”

• “We aligned the teams. But the prioritization didn’t support what we aligned on.”

• “We captured the context. But nobody’s workflow includes consuming it.”

AI makes the first link in the chain nearly free. But the chain has many links, and the downstream links have their own barriers. Barriers that have nothing to do with production cost. They involve capability (can people interpret this?), motivation (do they care enough to act on it?), social dynamics (is it safe and rewarded to act on it?), and system design (does the workflow even include a moment where someone would encounter this?).

The heuristic “do what you should do” ignores all of this (in many situations). It addresses the production side and is silent about the consumption and action side.

Applying Lenses Around Capability, Opportunity, and Motivation

Where we apply COM-B.

Everything above can be sharpened by asking three questions about any behavior you’re considering handing to AI. Is it a capability problem? Is it an opportunity problem? Or is it a motivation problem? The heuristic assumes the answer is almost always opportunity (not enough time, too much friction). When it’s wrong, AI solves the wrong problem.

Capability

Do people know what this behavior actually involves?

For well-practiced behaviors, everyone has a shared understanding of what the output should be. AI can hit that target because the target is defined. But for behaviors that exist in pockets are purely aspirational, there is no shared specification. Different people mean different things by “close the loop on outcomes.” AI will produce something, but without a shared definition of what counts, nobody will trust it.

People also consistently mistake the visible output of a behavior for the behavior itself.

When Sarah sends a well-timed update that keeps three teams aligned, the visible part is the update. The actual behavior is reading the situation, judging what matters to whom, framing it so it lands, choosing the right moment, knowing who needs a private heads-up first. The thinner the organization’s mental model of what a behavior involves, the more likely they are to believe AI can replace it.

And there’s a subtler trap: can people even evaluate whether AI’s output is good?

For well-understood behaviors, yes. You know what a good release note looks like. But for complex, judgment-heavy behaviors, the people evaluating the AI’s output are often the same people who don’t fully understand what the behavior involves. The organization lacks the capability to do the behavior, asks AI to do it, and also lacks the capability to tell whether AI did it well. The gap doesn’t close. It becomes invisible.

Opportunity

Is the environment set up for this behavior to succeed?

Physical opportunity is the heuristic’s home turf. Time scarcity, workflow friction, clunky tooling. When these are the dominant barriers, AI is a direct fit. Take the win.

But the system also needs to consume what AI produces. Even pre-AI, companies that invested in these behaviors found the constraint shifted to feedback loops and visibility. The artifact existed, but nobody’s workflow included a moment to encounter it. AI makes production nearly free. If the workflow doesn’t include consumption, you’ve accelerated the first step of a broken pipeline.

Social opportunity is where the deepest breaks live. Many “should do” behaviors don’t have clear ownership. They lived in gaps between job descriptions. AI can produce the output, but production without ownership means nobody is accountable for whether it gets used. Organizations also frequently endorse behaviors rhetorically that they punish operationally. “We value documentation” but we promote people who ship fast. Making the endorsed behavior cheaper doesn’t change that calculus.

And some behaviors aren’t happening because the organization makes them risky. Surfacing problems, flagging misalignment, questioning priorities. The person who did this before had enough social capital and trust to do it safely. An AI-generated artifact has none of those buffers. A risk report from Sarah, who has ten years of trust with the VP, lands differently than the same report from an AI tool. The information is the same. The social permission is completely different.

Motivation

Why were people doing this in the first place?

The heuristic targets effort cost. But motivation also includes: Do people believe this will produce a good outcome? Do they see it as part of their identity? Is there a competing habit that crowds it out? Each of these can be the binding constraint, and AI-as-effort-reducer doesn’t touch any of them.

Some behaviors were carried by people who identified with doing them. When AI takes over the output, the organization loses the motivational engine that made the behavior happen with care and judgment. And in organizations where “should do” behaviors have been repeatedly championed and then abandoned, people develop a rational skepticism. They’ve learned that the organization doesn’t follow through. Cheaper production won’t convince them. Demonstrating that the systemic conditions have changed might.

How the picture shifts

The critical insight across all three lenses: as you move from well-practiced-but-painful behaviors toward aspirational-or-contested ones, the dominant barrier shifts from physical opportunity to a combination of capability, social opportunity, and motivation. The heuristic “use AI to do what you should” only addresses the physical opportunity layer. It is silent about the rest.

For behaviors where the capability exists, the social environment supports it, and the motivation is present except for effort cost, AI is a near-perfect intervention. For behaviors where the capability is thin, the social environment is ambivalent or hostile, and the motivation was carried by specific individuals rather than organizational systems, AI produces artifacts that enter a system unprepared to use them. The artifacts look like progress. The underlying conditions haven’t changed.

The Glue-Person Risk

This brings us to the most consequential version of the problem. The people who carried these behaviors, the informal advocates, the formally appointed connectors, the “glue,” were rarely doing what it looked like they were doing.

From the outside, it looked like they were writing updates, maintaining docs, sending summaries, and running alignment meetings. Activities. Tasks. Things that AI can plausibly do.

From the inside, they were:

• Reading weak signals about when an intervention would land and when it would be resisted. Timing and context that requires years of accumulated pattern recognition.

• Navigating legitimacy. Knowing whose endorsement was needed to make an artifact credible, when to surface something publicly versus privately, how to frame a message so it wasn’t threatening.

• Building shared language across roles and teams that organize reality differently. Translating between engineering’s mental model and sales’s mental model and leadership’s mental model.

• Running informal feedback loops. Noticing when something was drifting off course, deciding whether it was worth intervening, calibrating the right amount of correction.

• Absorbing role ambiguity. Stepping into gaps between job descriptions that nobody had formalized, taking ownership where ownership was unclear.

• Making the invisible visible. Surfacing friction, cost, and coordination failures that the organization had normalized and stopped noticing.

When organizations say “AI can do what the glue people did,” they are looking at the output layer and missing everything underneath. The risk isn’t just that the AI-produced artifacts will be lower quality. It’s that removing the people and assuming AI covers it eliminates the judgment, social infrastructure, and adaptive capacity that made those artifacts matter, while creating the appearance that everything is still being handled.

The cruelest version of this: the glue person’s work was often invisible because they were good at it. Things ran smoothly. Information flowed. Teams stayed aligned. Nobody noticed the work because the work’s purpose was to prevent problems from becoming visible. Remove the person, replace the visible artifacts with AI, and for a while nothing seems different. The problems surface months later, disconnected from the cause, and nobody connects the breakdown to the removal of the person whose job was to prevent exactly that kind of breakdown.

So What Do You Do?

The heuristic is still good. Use AI to do the things you know you should do. Start there. But hold two things alongside it:

Diagnose before you automate.

Ask: why isn’t this happening? If the answer is genuinely “it takes too long and we don’t have time,” go. That’s the sweet spot. If the answer involves “nobody’s really sure what good looks like,” or “the org doesn’t actually reward this,” or “it works when Sarah does it but not when anyone else tries,” the barrier isn’t cost, and AI-as-effort-reducer won’t solve it. You need to understand the actual gap before you can know whether AI addresses it.

Respect the iceberg.

When someone was carrying a behavior successfully, formally or informally, assume you’re seeing 20% of what they were doing. The artifacts were the visible output. The judgment, relationships, timing, framing, and political navigation were the invisible 80% that made the output useful. Before you replace the person with AI-generated artifacts, understand what the other 80% was and what happens to the system when it disappears.

Watch for constraint shifts.

When AI makes something easy to produce, ask: what was the next bottleneck, even before AI? If companies that were already doing this work still hit limits (and they did), then making the first step free doesn’t clear the path. It just moves you faster to the next wall. Know what that wall is before you celebrate solving the first problem.

The advice is sound. The instinct is often right. But “do what you should do” is only as good as your understanding of why you weren’t doing it in the first place.

Every company eventually asks the question: “What are we getting from our engineering investment?” And it almost always goes sideways. There’s finger-pointing. There’s fear. There’s weird math that nobody believes.

People retreat to flow metrics because the real question is terrifying. Or they fixate on near-term revenue contributions and vanity metrics. They reach for benchmarks like “revenue per engineer” without any sense of whether the business models being compared are even remotely similar. They latch onto growth rates and efficiency ratios that obscure the real issue (and are almost certainly lagging). They track time allocation with exact precision on the cost side while hand-waving wildly around the return side. Teams throw up their hands and settle on terrible proxies, or avoid the question entirely.

The hardest thing to accept is that the rigor is in the care and stewardship, not in the calculation. Yes, there’s math (sometimes) and stats (sometimes). Yes, there’s probably some modeling. And a whole lot of qualitative data. But when you actually care about the thing, you answer the question from a very different perspective.

Understanding the return on your product and engineering investments isn’t a calculation you perform. It’s a set of behaviors you practice, continuously, over time, that happen to involve some measurement. It shapes where you allocate resources, which teams you invest in and nurture, how you support the people doing the work, what you build, and when to change approaches. Get it wrong and you over-hire into dysfunction, under-invest in the things that compound, and lose the teams worth keeping. Get it really wrong and you lose years.

Here’s the problem: by the time most teams finally ask the hard questions, they’re standing in the aftermath of years of not asking. And they’re expecting an easy answer. Understanding engineering ROI is a habit you had to have been building all along. You can’t reverse-engineer it. If you’re struggling to answer the question right now, you’re almost certainly asking too late.

You Can’t Cold-Start This

Say you wake up one morning with 2,000 engineers at your company, and you try to cold-start answering the question: “So what are all these engineers worth? How do they contribute to revenue?”

You've never discussed outcomes. Never tracked leading indicators. Celebrated velocity and throughput as if shipping faster were the same as shipping the right thing. Obsessed over time allocation and cost tracking while hand-waving the value side. Used "revenue per engineer" benchmarks ripped from companies with completely different business models. Celebrated “cooked” business cases. Spreadsheet theatrics. Hired your way around problems instead of solving them. Played dumb games with finance around projects completed and near-term revenue contributions.

And now you want to cold-start the question of what all of these engineers are "worth"?

An engineering leader I know had a couple great lines

1. Money is generally the easiest part of the equation when it comes to building software. It’s very hard to turn $$$ into valuable software and adding people rarely “fixes” a team, and can make things worse by obscuring the actual issue

2. Any investment requires confidence in the leadership to be a good steward of capital

3. Asking for more people for an initiative implies everything else on your roadmap is more important and that you can’t find other efficiency gains to get the initiative done with the existing team.

The real issue they point out is increasing the size of the team without fully exploring all potential paths to achieving the mission with the existing team. The same goes with the product: achieving the same effect with less code, less complexity.

Very few companies address “what is the ROI of our team” from a position of diligence, curiosity, and being proactive. They face the question after hiring their way around problems, a weird strategy, a toxic leader, a self-inflicted revenue pinch. And then they’re left with a team that’s too big, navigating an inefficient system.

By the time the finger-pointing starts, you rarely get any admission of responsibility.

There’s an idea in economics called the Lucas Critique: when you change the regime, all the historical relationships you estimated under the old regime break down.

Given that the structure of an econometric model consists of optimal decision rules of economic agents, and that optimal decision rules vary systematically with changes in the structure of series relevant to the decision maker, it follows that any change in policy will systematically alter the structure of econometric models.

You built an entire organization around one set of rules (feature factory, hiring around problems, story points as currency). Now you want to flip to a new regime of fiscal stewardship. But all the relationships, incentives, and data you accumulated were products of the old regime. They don’t carry over.

An executive once asked me, “Why can’t we be like Amazon?” I responded: you can, if you rewind 20+ years, make operational efficiency a core trait, and keep growing consistently by re-investing profits. You haven’t proven that. If your business is literally built on a lack of operational effectiveness and unsustainable growth, you can’t decide one day to talk that language. If you’ve run a feature factory forever without trying to build proof around the causal chain, you’re in no position to say “measuring ROI is hard.”

An aside on private equity. Leaders who've been through a PE acquisition often report something surprising: a moment of clarity. For the first time, someone made the model explicit. Here's how much cash the business generates. Here's what we're spending. Here's what we're cutting. Here's the EBITDA target, and here's exactly how every dollar of investment is expected to contribute to it. Reduce costs, optimize margins, eliminate anything that doesn't directly serve the number. It's blunt. It's focused almost entirely on extraction. And many leaders don't agree with it, or think it sells the company's potential short. But they'll also admit: at least someone finally had a clear model. At least the math was honest, even if it was reductive. That should give you pause. If it takes a PE firm showing up with a spreadsheet and a 100-day plan for your organization to experience that kind of clarity, something was deeply broken long before they arrived.

Why It’s Hard (And Why That’s the Point)

Part of the reason companies delay this work is that it’s genuinely difficult. Most product work is several causal hops away from dollars and cents. You can progressively increase your confidence in the causal chain, but you can never fully eliminate uncertainty. Near-term, tangible outcomes always have a gravitational advantage over things with multiple hops to value.

And people get trapped in a false binary: either you have something overly precise, or nothing at all. A bad proxy (story points as investment theory) is worse than no proxy at all, because it gives you false confidence in a wrong answer. But a good-enough proxy, one that is directionally correct and honestly held, is genuinely valuable. The goal isn’t perfect measurement. It’s continuously increasing confidence in the core underlying hypotheses.

The difficulty isn’t an excuse. It’s the reason you need to build the habit early. If you wait until the question is urgent, you have no foundation to stand on.

What the Habit Actually Looks Like

This is Bayesian updating applied to product. Start with a prior. Collect signals. Update your confidence. You never arrive at certainty; you narrow uncertainty over time. The “precision or nothing” trap is a frequentist fallacy: demanding a p-value when what you need is a posterior that’s directionally useful. The teams that get this right treat every quarter as another round of evidence, not an excuse to wait for conclusive proof.

The narrative underpinning a team’s “ROI,” measured over time, is as much about conviction and signals (”we seem to be doing a lot with a little”) as anything scientific. Almost by definition, because of the lag in outcomes. Teams that dominate through usability, or speed, or operational excellence rarely did precise math about that differentiation beforehand. They had conviction, which started to show signals of working. Stubbornness, skill, culture, positive reinforcement.

What I am trying to get at is that the question of “what is the ROI of engineering” or “what do we get from our money” is a set of behaviors, continuously applied. It is a culture of stewardship and thriftiness.

It's a habit of a team constantly asking itself about the leverage of its work. Not "what can we do" but "what should we be doing?" Is this the highest-leverage use of our time? Could we achieve the same outcome with less complexity? Without hiring? Are we solving the right problem, or just the one that landed in our lap? Teams that ask these questions every day, every week, every quarter, compound that discipline over years. They stay lean. They stay functional. When they do add capacity, it's onto a functional setting. Very different from how most companies treat this.

Stick with that attitude quarter after quarter, year after year, and you get great things. You know you’re lean. You know most of your teams are functional, so you’re adding teams onto a functional setting. Very different from how most companies treat this.

The heuristic of “be incredibly stingy about hiring, but very watchful and supportive of your team” has a lot of merit. It’s a forcing function for exploring all paths before throwing bodies at the problem. And remember: “revenue per engineer” is more a statement on the overall business model than on engineering efficiency. It’s about the whole system.

And the teams that garden their codebase, investing some portion of their normal time and focus? They supercharge the flywheel. In two years, when their peers might be sitting around struggling to ship anything, this team is still cooking, having fended off the normal entropy.

The Job

There is no formula. There is no framework you can buy. There is no dashboard that will tell you what your engineers are “worth.” There are only behaviors, sustained over time, that earn you the right to claim your investments mattered.

Stewardship. Thriftiness. Conviction held loosely enough to update but firmly enough to act on. Honest conversations with finance that respect the lifecycle and the cost of information. The willingness to narrow uncertainty a little bit, every quarter, rather than demanding certainty or giving up.

That’s the job. It always has been.

The good news: there's no better time than the present to start. You can begin today.

1. Identify leading indicators. What early signals would tell you whether your investments are working before the lagging financial results show up?

2. Build a model for how the business works. Not a perfect model. A useful one. How do the levers product can move (reasonably) actually contribute to revenue, retention, and cost structure?

3. Start regularly assessing those leading indicators. Every quarter, revisit your priors. Update your confidence. Treat it as a practice, not an audit.

4. Apply real discipline around hiring. Before adding headcount, ask: have we exhausted all ideas on how to fix existing issues to make this possible with who we have? Apply discipline around team formation and funding. If you don’t have this, start! It isn’t about teams proving why they should exist—it is about at least having a reasonable hypothesis and some evidence (or a plan to get some evidence).

5. Have honest conversations with finance. Not the dumb game of time allocation, projects completed, and made-up business cases. Or oversimplified lifecycle models. Establish a reasonable model together that accepts the lag of outcomes in product, that accepts a portfolio of bets that are different shapes, and that accepts teams are operating in different modes that need specific funding models.

Related Posts

Orgs spend a lot of time talking about dependencies, intake, predictability, “discovery,” capacity, and so on. But far less time talking about the harder questions around the demand mix teams are dealing with, and how they are actively involved in shaping that demand.

What I want to do in this post is cover some of the basics of demand mix, context, and how those two things actually determine how teams operate and what “good” looks like. Then, after walking through those principles, I’ll share some thoughts on how AI is starting to change the picture.

The key point is that without a discussion of demand mix and the activities involved with shaping and filtering demand—getting into the real specifics—it is very hard to have a real discussion about how you operate.

The Demand Funnel (A Helpful Simplification)

A dominant mental model of product development looks like this:

There is effectively a “funnel” that all sorts of stuff gets dumped into, filtered, assessed, and eventually that work produces change, which then feeds back into the funnel.

Both (1) the makeup of what is in the funnel and (2) how it is filtered, shaped, and influenced can vary dramatically across teams and companies.

At one end, you have support teams waking up each day to a fresh batch of inputs. The team is almost stateless, aside from the decisions that shaped what landed in their queue.

At the other end, you have product teams that largely source their own inputs through customer interaction, guided by high-level company goals, constrained by decisions made years ago about their mandate, and shaped by incentives tied to relatively stable metrics.

And then there is everything in between.

So you have:

1. The mix of stuff in the funnel. Where it came from, who is involved, and what “it” is, for example support tickets, internal requests, production fires, or strategic goals. The composition of the funnel matters, and the variations are massive, even within a single organization.

2. How that flow is shaped. How the team, and others, actively shape what moves through. One team might be prototyping, testing with customers, and constantly shaping or discarding ideas. Another might have almost no involvement until a late-stage feasibility check. And again, everything in between (even inside a single org).

Mix and Approach

Mix and approach are obviously related. You have to adapt your approach based on the mix (or try to change the mix).

For example, when a team is fed by a high volume of interrupts coming from across the organization, it tends to rely on structured intake, prioritization forums, economic trade-offs, and planning cadences to manage the chaos.

In contrast, when a team sources most of its own demand through discovery and strategy, the approach shifts toward shaping the funnel upstream through continuous learning, selective intake, and ongoing refinement.

In both cases, the practices can be sound, but they are responding to very different input conditions, and those conditions ultimately shape how the team operates.

No Team Is An Island

Of course, no team exists completely on an island.

In the leftmost example you might see teams tightly coupled through shared interrupts, constant cross-team dependencies, and work being reshaped as it flows between groups.

In the rightmost example you are more likely to see teams loosely coupled around shared priorities, where strategic alignment happens upstream and each team shapes and executes against its own coherent stream of work.

On the left, you’re lucky to get teams focused and coordinated, let alone figuring out if what you are doing is actually working. On the right, teams are able to stay aligned around clear priorities, operate with focus, and continuously learn from what they’re doing, making it much easier to see what is actually working and adjust accordingly.

Demand and Prioritization

Building on my piece on the four prioritization jobs, the mix of demand and the activities used to shape that demand will have a huge impact on how people prioritize and why they prioritize. Those four jobs, efficiency, leverage and effectiveness, alignment and autonomy, and support and commitment, show up very differently depending on what is feeding the funnel.

For example, in a high-interrupt environment like Org A, prioritization discussions are often dominated by efficiency and support. Teams are trying to reduce noise, survive the volume, and negotiate commitments they may not even be resourced to handle.

In contrast, in Org B, where demand is largely self-shaped, prioritization leans much more heavily into leverage and alignment. The conversation shifts toward which bets matter most, how they connect to strategy, and how teams can make confident local decisions without constant escalation.

Demand and Mandate Levels

This is also where my idea of mandate levels becomes very concrete.

In the diagram, all of these levels are active at once, from “build exactly this” at the top to generating long-term business outcomes at the bottom, with different parts of the organization operating at different altitudes and connected to one another.

What is a bit counterintuitive is how each side feels. The left side can appear deceptively simple. Work shows up pre-shaped, teams are given things to build, and the flow looks straightforward on the surface. The right side, in contrast, can feel messier. There are experiments, drivers, inputs, feedback loops, and more visible iteration across levels.

But underneath that perception, the shape of demand and the activities used to shape it are very different.

On the left, the apparent simplicity is driven by pushing complexity “downstream” and outward, into fragmented inputs, hidden dependencies, and pre-shaped work that obscures outcomes.

On the right, the messiness comes from engaging with that complexity directly, linking levels together, and actively shaping demand through discovery, experimentation, and alignment. So while one looks clean and the other looks busy, they are responding to fundamentally different mixes of demand, and that difference determines how teams can operate across the mandate levels.

Controlled Intake vs. Distributed Chaos

(Note, we’re shifting org examples here.)

Why is any of this important? When we talk about “discovery,” capacity, “shaping,” throughput, etc., it is critical to understand the context.

I know a highly effective product owner (their org is very much a Scrum shop). He runs what he calls an “efficient feature factory.” “I wish it was different, but that is what we do here.”

What does that mean?

1. The team does very extensive requirements discovery based on all the requests coming in

2. They put back-pressure on requests, deliver often, are “predictable,” and can generally forecast, within a confidence range, when things will be finished

3. They went from being perpetually overwhelmed, with everyone saying the team was untrustworthy, to having all of their internal stakeholders “love” the team

4. He figured out how to get stakeholders in a room periodically and essentially run a rigorous auction on their “capacity”

“Look, at least compared to my last job, this produces reasonably usable software. We ship often, we limit our WIP, we understand requirements, and people aren’t bad-mouthing the team.”

Now contrast this with a PM from a theoretically “empowered product company” whose leaders frequently show up on popular product podcasts:

Honestly, it is a shit show. Empowered here means we are basically empowered to negotiate with dozens of teams across massively competing priorities, everyone with their own agenda. No one wants to face how hard it is to get things done, and none of the VPs want to let their precious budget go to any other group.

We have teams flying high because they are doing something AI-related, and they go around the company basically commanding other people to help them. Meanwhile, the teams working on the actual guts and infrastructure of the org, the stuff that everyone relies on, are having to beg, beg for headcount.

Everyone is terrified about layoffs, but what we really need to do is start doing more top-down prioritization and make hard decisions. Maybe we need to re-org, but probably right now we need to be doing like 50% less, as unpalatable as that sounds. When anyone says that, the answer is, ‘but you’re empowered!’

Putting these examples together, the mix of demand and the way it is shaped fundamentally determine how teams operate, what practices make sense, and even what “good” looks like in a given context.

For the feature factory, “good” means control, predictability, and earning trust by reliably handling a high volume of incoming work. For the more “empowered” but fragmented environment, “good” is supposed to mean choosing the right bets and owning outcomes, but often devolves into fragmentation, negotiation, and heroics when the mix and shaping activities aren’t aligned.

Who is actually empowered?

Who gets rewarded in both environments?

The Story of Everyday Actions

Whether you are talking about “dual-track Agile,” “continuous discovery,” “requirements gathering,” straight-up research, or anything in between, it is a pretty useless discussion unless you understand the context: the demand mix, the mandate levels, the nature of the work, the risks involved, and how all of that actually shows up day to day.

The real story of demand is not explained by a theoretical SDLC. It is the story of everyday work. Everyday activities. Everyday tickets, docs, goals, and requests.

• Where did this come from?

• What shaped it before it got here?

• What did you actually do with it?

• How did you get from that goal or priority to this thing right here?

• How much of your roadmap do you actually control?

• How much is handed to you?

• How are you self-sourcing opportunities?

There is never an excuse for too much WIP or overloading a team. Sometimes that is self-inflicted, but often it is a mix of self-inflicted and organizationally inflicted. In theory, you can say no. In practice, when work is coming at you from all sides, that is often not a real option.

If a week before quarterly planning the wind suddenly shifts and there is a new hot priority, and your team of five is already tackling 15 things, you are likely going to add item number 16, and bump it up, unless you have built a significant amount of influence in the organization.,

The important point is that even very strong teams, with a clear understanding of their demand mix and taking contextually appropriate actions to manage it, can get pushed over the edge when the organization drifts into chaos and there are no enabling constraints. Meanwhile, with the right support, a “normal” team can operate sustainably.

Critically, how you tame WIP, how you approach discovery, and how you manage demand is, I repeat, contextual. There are no one-size-fits-all approaches.

Some AI Thoughts

Are you shipping faster than you learn, or learning faster than you ship? I think a lot of companies believe they were learning faster than they could ship, and now see AI as an insta-fix.

The Ingrained Mental Model

There is a deeply ingrained mental model in product development that looks something like this: ideas flow through a funnel, get refined, and eventually land with a scarce engineering team that turns them into reality. That team is treated as the bottleneck, the point of constraint, the place where all upstream effort is justified. The entire system organizes itself around feeding that constraint as efficiently and predictably as possible.

It is a version of our funnel.

Once you believe that, a whole set of behaviors follows. Upstream work becomes about shaping and de-risking ideas before they ever reach engineering. Requirements get over-specified. Decisions get made early. Stakeholders negotiate intensely to secure their place in line. Work is packaged, defended, and handed off. The goal becomes to “get it right” before it hits the team, because the cost of being wrong is assumed to be too high once it does.

This is where many of the familiar pathologies emerge. Premature convergence replaces learning. Performative certainty replaces curiosity. Large batches of pre-shaped work move through the system, giving the illusion of progress while obscuring whether any of it will actually work. Much of the effort shifts away from understanding customers and toward managing internal dynamics, competing priorities, and access to scarce capacity.

In that world, the funnel is not really about producing meaningful change for customers. It is about allocating a constrained resource. The system’s output is not learning but decisions that have already been made, often far removed from real feedback. Engineering becomes the receiver of these decisions, rather than an active participant in shaping what should exist in the first place.

An Alternate Mental Model

There is a different way to think about the funnel.

Instead of ending at a team, it ends at meaningful change for customers. The purpose of everything upstream is not to perfectly specify work, but to learn what is worth doing. Work is shaped continuously, not front-loaded. Decisions remain flexible longer. Teams are not just executing against a queue; they are actively participating in discovery, shaping, and iteration.

In this alternative model, the constraint shifts. It is no longer engineering capacity in isolation. It is the system’s ability to learn, to focus, and to make coherent decisions across competing inputs. The funnel becomes less about filtering work down to a team and more about shaping and refining ideas as they move toward real-world impact.

Now Supercharged With AI

This is where AI enters the picture, and it is easy to misread what it changes. If you are operating in the first model, where engineering is treated as the bottleneck, AI looks like a breakthrough. If we can generate code faster, prototype faster, and ship faster, then surely the constraint has been lifted.

If you keep the same mental model, AI will not clean anything up. It will accelerate the dynamics you already have. More ideas will be generated. More work will be shaped upstream. More artifacts will be produced. More things will enter the funnel. The negotiation does not go away. The theatrics do not go away. The overload does not go away. It all speeds up.

The vibe-coded prototypes, vibe-written PRDs, and faster requirements do not solve the problem. They just replace the old rituals of documentation and premature convergence with new, higher-velocity versions of the same thing.

On the other hand, if you shift the model, AI becomes something very different. It becomes a tool for accelerating learning rather than feeding a bottleneck. It helps teams explore more options, test ideas faster, and surface connections that would otherwise be too costly to process. It reduces the cognitive burden of making sense of complex systems, allowing teams to focus on what actually matters.

The key point is that AI does not fix the funnel. It reveals and amplifies whatever version of the funnel you are already operating. If your system is oriented around managing scarcity and negotiating access to engineering, AI will make that system more intense. If your system is oriented toward learning and shaping demand toward meaningful outcomes, AI will make it more effective.

So the real question is not what AI enables in isolation. It is the version of the funnel you are running.

Questions

• What is the funnel in your organization actually for? When you step back, what is it really optimizing for, and how intentionally has that been designed?

• How would you describe the shape of demand your teams are dealing with today? Where does it come from, how does it take form, and how much agency do your teams have in shaping it?

• When you observe how work moves through your system, what feels like learning, and what feels like negotiation or performance? How easy is it to tell the difference?

• Where in your organization are decisions being made too early, and what would it look like to hold those decisions open longer?

• If your teams suddenly had the ability to generate and explore far more ideas, what would actually change? What would improve, and what might quietly get worse?

• What do you believe is truly scarce in your system today? Is it engineering capacity, or something less visible like focus, clarity, or the ability to make coherent decisions?

• As AI becomes more embedded in your workflows, what existing behaviors or patterns might it reinforce? Which ones would you want it to challenge instead?

• If you imagine your organization a year from now, with AI fully in play, what would need to be different about how demand is shaped, filtered, and acted on for that future to feel meaningfully better?

Here’s a fun little image from a team doing a bucketing exercise for their funnel/demand:

I guess I’m putting together an AI series of sorts. This is #4.

1. Hope, Context, and Control

2. Seeing Everything, Understanding Nothing (The Context Trap)

3. Institutionalized Overload (Now With AI)

4. Legibility and Legitimacy « THIS POST

5. Before You Fire All Your Glue People Because of AI

6. Simple-player to Mutliplayer: Context Through Collaboration

At the day job, I’m deep in the question of how AI can help teams do more effective work, hence all the thinking below. It has highs and lows these days, with enough inspiring stories to keep me curious and hopeful. If you and your team ever want to chat about this, reach out.

There is a big difference between legibility and legitimacy.

The terms sound related, and they do share a lineage, but they diverge in meaning. Legibility derives from legere, meaning “to read” or “to gather,” referring to what can be seen, interpreted, and made understandable. Legitimacy, by contrast, derives from lex (legis), meaning “law,” and refers to what is considered lawful, justified, and worthy of acceptance.

Legibility is not neutral, despite the surface-level appeal of transparency or simplicity.

As James C. Scott argues, legibility and power are intertwined. Making systems legible requires selective filtering and simplification—boiling people, activities, and relationships down into forms that can be acted upon. In that sense, legibility enables control.

Legitimacy, by contrast, determines whether that control is accepted as justified.

When someone steeped in technology starts talking about “world models,” treats middle management as an information-processing appendage, and advocates for organizational flattening while remaining largely silent on questions of power and control, it is worth paying attention. Especially worrisome is the familiar pattern: appeals to decentralization and freedom while simultaneously ceding significant control to technology and those who control it. That’s when you really need to pay attention.

And when people take the bait, hook, line, and sinker, and accept it all as new or innovative—seeing it not just as progress, but as a form of personal freedom—that’s when you really, really, really need to pay attention. Because the rhetorical trick is working.

And it shows up clearly in Jack Dorsey’s recent post Hierarchy vs. Intelligence. The post argues:

• Organizational hierarchy is a byproduct of information transmission problems

• AI enables greater legibility

• It assumes legitimacy

• It avoids discussing who holds power once the system is (more) legible

At a high level, Dorsey’s thesis is that organizational hierarchy exists primarily to route information, and that AI can now perform that function more effectively. If a system can maintain a real-time “world model” of the company and coordinate work directly, then many layers of management become unnecessary, and decisions can move to the edge.

In the context of legibility and legitimacy, my take is that the post:

• repackages control as freedom

• relies on legibility

• skips legitimacy

Dorsey rehashes a familiar set of ideas:

• the company as an intelligence system

• persistent frustrations with layers and information distortion

• aspirations to flatten organizations and push decisions to the edge

• the dream of running the company as a system

None of that is new. See: learning organizations, cybernetics, systems thinking, platform thinking, and industrial and managerial traditions. What’s new isn’t the concept, but the claim of feasibility: that AI can finally operationalize it.

Maybe AI can help make a dent—but by how much, and toward what end? Human flourishing? Or humans as edge “meat” operators in a system designed for ultimate legibility and control? For a discussion on the actual feasibility of a company “world model,” see here.

The underlying philosophy matters. The article references Haier, but treats it as just another structural attempt at coordination that fell short because it lacked the technology. But Haier isn’t just a structure. It’s grounded in a clear philosophy about human value and autonomy. You can agree with it or not, but it defines what “better” means and for whom:

• Better = more autonomy at the edge

• Better = closer to the customer

• Better = humans as accountable units of value creation

Dorsey’s post, by contrast, implies “better” in terms of:

• faster decisions

• clearer visibility

• tighter coordination

• less distortion through layers

But those aren’t philosophies. They’re optimizations in service of something. They describe how a system might perform, not what it is ultimately for or who it is serving.

Haier defines what counts as value. Dorsey defines how efficiently value flows.

The promise of AI-driven “intelligence systems” reframes increased legibility as empowerment, while shifting control to those who own the model and sidestepping the question of whether that control is legitimate.

In the classic Silicon Valley ethos, technological progress is often treated as self-legitimizing.The playbook: keep quiet on values, or allude to vague calls for “freedom” and “progress.”

Will we play along?

This is really about whether we choose to accept AI-powered legibility in the control of organizations as legitimate, or whether we ask harder questions.

One of the defining traits of AI is that it becomes a catalyst for whatever people already believe. If you believe in “re-wilding,” you can imagine how AI will help. If you care about efficiency, autonomy, or decentralization, AI promises a step change. Which is why this is as much about questioning the why as it is about any specific proposal. Not just what becomes possible. But what we choose to accept, and for what purpose.

One thing I’ve noticed (and experienced firsthand) is that when change agents advocate for a better way of working, there’s a moment that feels extremely unfair. The burden of proof is all on you. You’re tiptoeing through nonviolent communication, channeling your utmost curiosity, trying to connect, trying to not rock the boat, and still somehow ending up in the position of having to prove that what you’re seeing and feeling is even real. Suddenly, you’re on the witness stand.

It’s a deep human need to feel understood, to be listened to, to not be immediately dismissed. That’s part of why this lands so hard. You wish someone would just say, “Tell me more.” But that rarely happens. Or when it does, there are a lot of strings attached, or the curiosity is short-lived.

The response?

• “That doesn’t happen in the real world.”

• “I don’t think A-players need that.”

• “That’s too [insert process-focused, utopian, buttoned-up, unreasonable].”

• “Great. Now explain how we can actually do that… here.”

• “You need to be more [insert open-minded, go with the flow, pick your battles, etc.].”

And what those responses often convey, directly or indirectly, is that your perspective, your hopes, your ideas are invalid. You’re putting in all of this work. At least on some level, you believe you are being open-minded and accepting of different views. And the message often lands as a mild inconvenience. A hassle. Harshing the vibe.

Yet, there are ways to reframe this and not let these moments drain your energy, your spirit, and your passion.

First, some perspective. Ask yourself: were you curious the last time someone challenged one of your deeply held beliefs? It’s tough for anyone to have their identity challenged. That’s not unique to the person you’re talking to. It’s human. It’s also easy to forget what that feels like and imagine yourself somehow above the normal response, even among people who think of themselves as open-minded. We all imagine we’ll be more open-minded and curious when challenged than we actually turn out to be, even on the best of days.

Second, realize that your need to be heard and acknowledged is also a core part of your identity, just as someone else’s need for the status quo to remain intact is tied to theirs. You are both operating from a point of vulnerability and both defending your professional identity. It is very easy in these situations to start ascribing agendas and motives that are wildly blown out of proportion.

Third, put these situations in context compared to the relationships you have with your longtime friends, your family, and siblings. Most people we interact with at work are acquaintances and “situational friends” at best. While it is inspiring to be validated by these “situational friends,” and people you may have come to respect professionally, they are a very far cry from the relationships you have that transcend that particular company.

It is easy to equate the two: the boss or manager as the older sibling who may have dismissed you, or to compare them to the loving parent who met you where you are, but that is a huge stretch. Ask yourself how many people really stay in touch from your work life. Also (and I think this is thankfully very rare), realize that there are unscrupulous people out there who will manipulate this deep need for validation for their own motives. Don’t fall for it.

Fourth, you have to ask yourself the extremely hard question: “What do I want?” What change are you seeking, and if you were to step back, is there really a chance in hell that logic, comparisons, hearing what works elsewhere, etc., will make a difference? Imagine you ran a psy ops team, and your goal was to manipulate people to change their behavior. Would you really suggest the “hey, I think we might want to try” approach? Or would you start showing, not telling, and generally manufacture conditions where everyone somehow woke up thinking X was a good idea, and their idea?

When you ask yourself that question, sometimes the answer is, in fact: “I want to feel validated, to be listened to, for my perspective to be taken seriously,” which is an important thing to know, especially in the context of the workplace, where it is rare for conditions to truly support that (as much as we might wish otherwise).

When we deeply acknowledge our needs, our pains, and our feelings, while also using the evidence in front of us to understand whether those needs are actually being met, something shifts. Yes, it is painful. But you aren’t controlled by that pain. It goes from all-consuming, to something that no longer dictates your next move.

Because we all know what happens next, when that hurt turns into an escalation.

“Between stimulus and response there is a space. In that space is our power…” — Viktor Frankl

I guess I’m putting together an AI series of sorts. This is #3.

1. Hope, Context, and Control

2. Seeing Everything, Understanding Nothing (The Context Trap)

3. Institutionalized Overload (Now With AI) « THIS POST

4. Legibility and Legitimacy

5. Before You Fire All Your Glue People Because of AI

6. Simple-player to Mutliplayer: Context Through Collaboration

At the day job, I’m deep in the question of how AI can help teams do more effective work, hence all the thinking below. It has highs and lows these days, with enough inspiring stories to keep me curious and hopeful. If you and your team ever want to chat about this, reach out.

We’ve gotten so acclimated to organizational overload, endless work in progress, and constant unplanned demands that it has become the norm. It is clearly too much for any person, but people adapt. Their defense mechanisms kick in, and over time that overloaded state just becomes what work feels like.

When I look at how people are using AI, I see the same pattern. People are not really questioning whether this massive amount of cognitive overload is healthy or even appropriate for achieving their goals. They are using the tools to navigate and sustain the overload that already exists. Success becomes processing ever more context, juggling ever more balls, and riding the dopamine hits of perceived navigation and progress. Like Syndrome from The Incredibles, the power feels real while you’re holding it, but it’s built on something external and fragile, and it quietly pulls you deeper into needing it.

New technology rarely breaks the paradigm on its own. It tends to reinforce whatever system it enters, even while claiming to disrupt it. As Tressie McMillan Cottom has argued in different ways, systems that promise to fix what is broken often end up reproducing the same underlying dynamics. You can see this playing out now. Leaders talk about “AI-ing all the things,” but stop short of anything that would actually change how power and decisions flow in the organization. The targets are familiar. A few jabs at middle management. Some efficiency gains. But the core structures remain intact.

Over time, people start to ground their professional identity in this. Being good at your job becomes being good at handling noise, juggling competing inputs, and staying afloat in the chaos. That becomes the work. And the “hit”.

At some point, people go further and begin to argue that this constant “soup” of inputs, interruptions, and competing demands is actually necessary. That it fuels innovation. That it keeps people sharp. That without it, progress would slow. What starts as adaptation turns into justification. The very conditions that make thoughtful work harder get reframed as the reason good work happens at all.

Herbert Simon captured the core constraint: “a wealth of information creates a poverty of attention.” What follows, as Chris Argyris observed, is that people and organizations develop “defensive routines” that protect the status quo rather than question it. And in Byung-Chul Han’s framing, this dynamic becomes internalized, where “the achievement subject exploits itself until it burns out.”

Taken together, the pattern is consistent:
1. overload is not just experienced…
2. it is normalized, defended, and ultimately…
3. sustained by the very people caught inside it.

One of the strange outcomes is that when you operate with calm, determined efficiency and real focus, it can feel uncomfortable. It feels like something should be happening. It feels like something is missing. Overload becomes so normalized and even celebrated that suggesting we do less, or process less, starts to sound almost heretical.

In Han’s framing, the mechanism is that external pressure becomes internalized. People begin to define competence as the ability to handle more, respond faster, and process more context. Feedback loops reward this behavior, and over time it becomes part of identity. Tools like AI then amplify the system by making it easier to cope with overload, which raises expectations further. The result is that people don’t just experience overload, they actively sustain it, and stepping out of it starts to feel uncomfortable or even wrong.

What I am observing is that instead of looking at new technology as a catalyst for being more effective at a deeper level, we assume things are (and will remain) the way they are. Then we use technology to help us cope with a reality that we have largely created. We’ve always done this. We adapt to overload, normalize it, and build systems that sustain it. What’s new is that AI gives us a tool that can amplify the pattern while making it feel like we’re finally taming it.

Work expands to fill the available space, and now context does too. Information, inputs, signals, all of it will grow to fill whatever you allow. In this maximalist phase of AI hype, resisting that expansion is part of the work.

In my day-to-day work (at Dotwork), I hear about all the real-world exceptions, “things that work,” “things that never work” (but we keep trying), and everything in between. I’m a big fan of saying, “Can you show me?” on discovery calls. A slide, agenda, doc, dashboard, screen, etc., combined with the person talking about the “thing”, is worth a million abstract summaries.

I love seeing real examples of how people work every day, especially when they differ from the “official” process.

One interesting pattern I’ve noticed among many (not all) high-performing teams is that they use freeform documents with frequent “migration.” We’re talking very manual:

• Ad hoc, random, disconnected status “pills,” flags, and tags everywhere

• Links to everything and anything, and those links go everywhere (Miro, dashboards, Jira tickets, other docs, call recordings, etc.). The pool of artifacts is ever-expanding

• Complete disregard for theoretical hierarchies. For example, “initiative” is a completely nebulous and shape-shifting idea. Exceptions everywhere. “Oh, that’s just a thing.” “Oh yeah, that really falls into two categories.” “Oh, that’s sort of morphing into this other thing, but for now we’ll…”

• Strikethroughs, comments, and information repeated over and over. Comments. Lots of comments

• Checklists everywhere. No big push to make everything an official “ticket”, but links to things when it makes sense. Yes, tickets exist, but so do a lot of in-line todos.

• Manually copied quantitative data, or links to dashboards or notebooks. Screenshots are OK too.

What is so interesting is how common the practice is. It’s definitely a pattern, though the tools (GDocs, Slack, Confluence, etc.) all vary. The consistent theme is copy-paste migration and reflection as a habit—snapshotting reality, copying it forward, talking about it, and then rinse and repeat. But what is actually going on?

Whenever I see a strong pattern, my brain starts churning.

The fact that a lot of the Claude workflows people are experimenting with sort of mimic this format is especially interesting. I wonder how AI will shift/supercharge this habit?

My mental model for the practice looks like this:

Sure, the work is messy.

First off, the messiness is no surprise. That’s product work.

Whenever companies imagine a “simple” rollup of product work, they are either lying to themselves or very smart about choosing a small number of things to roll up. Or—and this is perhaps most damaging—they are forcing teams to ignore the true essence of the work.

Imagine a manager who immediately shut down this kind of emergent sense-making and forced a team to constrain themselves to tickets for everything. “Everything must be a ticket, OK?”

Well, your most talented/experienced product developers would work around you (a pain, alas). Your least experienced product developers would nod their heads and imagine that you can fit product work exclusively into tickets. That would be a shame, especially if they don’t spend 1:1 time with more experienced people who teach them how things really work.

So in that sense, the pattern is a no-brainer. Form follows function.

Does it scale? Yes and no. Yes, because you can have a whole company doing things at different resolutions, in different pockets, etc. No, because you can’t magically make it “simple”.

(Related post on the “simplicity fetish”…

Getting Things Out Of Your Head

Another piece of this pattern is the power of externalizing working memory.

Product work quickly overwhelms what any individual, or even a small group, can comfortably hold in their heads. There are too many signals: partial insights from customer calls, shifting hypotheses, dependencies with other teams, half-formed ideas about solutions, metrics that may or may not matter, and the ever-present “wait, didn’t we talk about this already?” moments.

So teams that build the habit of maintaining these messy docs push that cognitive load out of their heads and into the environment. That’s what all those messy artifacts are doing. None of this is meant to be a perfectly structured system of record. It’s more like a shared scratchpad for the team’s brain.

Repetition reinforces shared understanding. These teams are getting things out of their heads, and the process of putting them back IN their heads is helpful.

Frequent Integration and Fewer Elephants

Related to the survivorship bias point below, strong teams also seem to have a knack for not letting too many elephants sit in the room for very long. Most of us have seen the opposite play out.

You join a team. Someone proposes a perfectly reasonable working rhythm. Maybe it is a weekly reflection doc, a shared running list, or a lightweight status ritual. Everyone tries it for a couple of weeks. And then the slow decay begins.

1. The artifacts degrade.

2. More and more information moves into 1:1 conversations.

3. Someone starts saying, “Well…we can’t really write that down, can we?”

Three weeks later, the once-helpful document is now a relic. If it is still technically being updated, it is usually a well-meaning project manager dutifully going through the motions. The real status lives somewhere else. The RAG chart becomes a watermelon chart. The “official” update becomes the optics update.

Practices like the messy reflection documents described earlier do not work because they are declared in a meeting. They work when teams close the loop often enough that the habit forms. Sometimes that means a not-so-subtle nudge from a leader to stay on it. Sometimes it is the team’s own desire to keep the loop closed. But more than anything, it requires repetition.

You have to run the cycle enough times that it becomes natural. In other words, the practice cannot just exist as a document. It has to live inside a ritual.

(Related post on frequent integration…

Survivorship Bias

Which brings us to survivorship bias.

Maybe the pattern isn’t that these messy, evolving documents create high-performing teams. It might be that the teams capable of performing well are also the teams capable of sitting with something like this long enough for it to become a habit.

This kind of reflection practice requires patience. It requires people who are willing to pause, copy things forward, revisit assumptions, and talk through what the work actually looks like right now. In many environments, that loop gets shut down quickly. Things move too fast, the pressure for clean artifacts takes over, or the team simply never sticks with the practice long enough for it to become natural.

So it’s possible that what we’re seeing isn’t the cause of strong teams, but a side effect of teams that have created the conditions to sustain that habit.

The Legibility Question

All of this raises a natural question. If the nature of product work is this kind of messy, emergent activity on the front lines, how are leaders/managers in an organization supposed to understand what is actually going on? Leaders still need some degree of legibility. People need to know how work is progressing, where risks are emerging, and where teams are investing their focus. So the moment you acknowledge that real product work looks like the messy sense-making described above, you immediately run into a tension.

1. Teams need space for local emergence.

2. Organizations need some way to see and understand what is happening.

That tension raises a deeper question: how should organizations handle this gap between messy reality and organizational legibility?

(Related post on context, legibility, and control…

Three Possible Views

The Trade-Off View

One interpretation is that this is simply a permanent trade-off. Organizations constantly juggle two competing forces: 1) enabling effective work on the front lines, and 2) maintaining enough visibility to coordinate and manage the broader system. There is no clean solution. You are always searching for a moving sweet spot. The work becomes one of continuous adjustment rather than resolution.

Many organizations implicitly accept this framing.

The Fractal Emergence View

Another interpretation is to lean fully into the messy emergence. If teams operate through evolving lists, messy documents, and shared reflection, then perhaps the right move is to replicate that pattern at multiple levels of the organization.

1. A team has its messy working document.

2. A group of managers has a messy working document.

3. A leadership group has its own evolving artifact.

In this view, the pattern becomes fractal. Each layer of the organization mirrors the sense-making behavior happening below it. Legibility emerges through repeated reflection at multiple levels.

The Intentional Interface View

The approach I find most compelling is slightly different. If we treat this as a product problem, the goal is not to eliminate the messy emergence. That is the nature of the work, and it is the nature of the work at multiple levels (see fractal emergence above).

Instead, the goal becomes designing intentional interfaces between that messy reality (or realities) and the broader organization.

1. What is the smallest number of shared routines?

2. What are the minimal objects that allow teams to communicate clearly with others?

3. What shared language helps translate the frontline work without crushing it?

If a team is working effectively in this emergent way, the real question becomes: What simple mechanisms help others understand what they are doing without forcing them to stop doing it that way? That is where thoughtful design matters most.

(Two related posts:

• TBM 375: Minimally Viable Consistency

• TBM 409: Minimally Viable Consistency (Part 2)

Reflection Questions

1. Where do you see this pattern already happening in your environment? Think about the real working artifacts people use day to day. Are there messy docs, running notes, Slack threads, or dashboards that act as the team’s shared scratchpad?

2. What purpose do those artifacts serve that more formal systems do not? What kinds of thinking, sense-making, or coordination happen there that would be difficult to capture in tickets, status reports, or structured tools?

3. Why might this messy approach work for experienced teams? What habits, trust, or shared understanding allow people to navigate ambiguity without everything needing a rigid structure?

4. What pressures in your organization push people toward “cleaner” artifacts? Compliance, reporting, leadership expectations, or tooling constraints can all shape how work gets documented.

5. Where does the tension between messy reality and organizational legibility show up most strongly? When leaders ask for visibility, what information is hardest for teams to translate?

6. If you think about the “intentional interface” idea, what might that look like in your context? What small set of shared objects, routines, or language could help others understand the work without forcing teams to abandon how they actually operate?

We’ve got to make the app easier to use!

If you’ve been doing product for a while, you probably cringed. It’s not specific. It has no diagnostic value whatsoever. It could apply to almost any product in the world. There’s no hint at what outcomes or impacts might be possible as a result of making the app easier to use.

Another quote:

Users take too long to create an initiative.

Better? Not really. Is speed actually the goal? If you make initiative creation shorter, what might you have to sacrifice? OK, you have creation time, but you also have data breadth and depth. Is creation time the problem, or does the user just enter initiatives to check a box and gain nothing from the task? What if entering an initiative thoughtfully was worth the effort?

Users take too long to create an initiative because they’re unsure what information is required, much of the information isn’t readily available, and there’s confusion about what an initiative should represent.

Ah, that gives me some clues, provided there’s evidence to back that up. We have more diagnostic depth in the statement. Someone has done some research! But there’s a gap: I still don’t know why this matters, how much it matters, or what fixing this makes possible.

Someone adds:

This delays planning discussions and forces leaders to spend time clarifying basic context.

Now we’re getting somewhere. But I’m still curious about the human side of this. How do people feel about the process? Do they see it as valuable work, or as bureaucratic overhead? Do they approach initiative creation thoughtfully, or do they rush through it just to get it done? Why are they rushing?

Is this a moment where teams feel like they’re clarifying strategy and alignment? Or is it a moment where they feel like they’re filling out a form to satisfy a system? Who runs the system? What agency does the person feel in this environment?

When creating an initiative is fast and low-friction, teams capture ideas earlier and with richer context. In many tools, information only appears once something becomes official. But if people capture ideas while they’re still forming, the system accumulates valuable context that improves planning and prioritization discussions. As more of these rituals rely on that shared context, the product becomes embedded in how the organization coordinates work, and much harder to replace.

Notice here how we’re now dealing with many layered hypotheses and statements. Someone could have come up with this on a lark, or someone could have put a lot of heart and soul into increasing confidence around every assumption and link. Note how “big” some of the conclusions are. In theory that’s the flywheel, but so much has to come together to make that real, and it could take years for that loop to materialize.

Notice how your logical brain perks up. You start tracking the chain: friction, idea capture, context, rituals, embedment, switching costs. You begin asking whether each step really leads to the next. Does lower friction really lead to earlier capture? Does earlier capture really improve planning? Do those rituals really start to depend on the system?

But then your brain snaps back to the present moment.

What is actually happening today? What are people really doing when they create initiatives? What conversations are happening around those rituals right now? What evidence do we have that any of this chain is even starting to form? The big causal framing was great, but not enough.

So someone steps in and says:

Initiative creation is too heavy because the form asks for too many fields.

That feels good for a moment. Clear root cause. Clear solution. Remove some fields, streamline the form, and initiative creation becomes faster. And then all that good, persuasive narrative materializes, and everyone gets a promotion.

(For a discussion of “root cause”, see…

Your brain relaxes. The ambiguity disappears. The problem feels tractable.

But then the gears start turning again.

Which fields? Why were those fields added in the first place? Were they arbitrary, or did they emerge from real planning conversations that needed more context?

Who relies on that information later? Does removing those fields make planning easier, or does it simply shift the burden downstream?

And if initiative creation becomes lighter, what actually changes? Do teams capture ideas earlier? Do planning discussions improve? Or do we simply end up with more initiatives that lack the context needed to make good decisions?

For a few seconds, the root cause felt obvious. Then it didn’t.

The Point

Here’s the point of this post. There is no perfect articulation of a problem. You’re always swimming between having to answer a whole bunch of questions:

Exploratory
What questions should we even be asking about initiative creation, and what are we really talking about?

Definitional
What exactly do we mean by an “initiative,” and how is it defined in this system?

Contextual
What is the surrounding environment in which initiatives are created?

Descriptive
What is actually happening today when someone tries to create an initiative?

Explanatory
Why does initiative creation feel heavy for some users?

Strategic
Why does this matter, and what would improving initiative creation make possible?

Generative
What alternatives or better futures for initiative creation might exist?

Evaluative
Is initiative creation actually working well today, and how can we tell?

(These question types are from…

You’re constantly moving up and down layers of the stack.

Sometimes you start with the customer’s words. Sometimes you zoom out to see how other actors experience the issue. Sometimes you dig into incentives, habits, or power dynamics. Sometimes you jump forward and ask whether your product can meaningfully influence the situation at all.

(A discussion of problem layers…

The trick is to dance between layers.

A statement that feels solid at one layer can fall apart at another. A root cause at the behavioral layer might not hold up when you look at the surrounding ecosystem. A strategic opportunity might collapse when you ask what you can realistically influence today.

And then your audience and their experience level come into play. Even if you’ve thought carefully about the problem across these layers, you still have to communicate it to other people. And the level you choose often depends on the experience, interests, and responsibilities of the person you’re talking to.

• Some people want a very concrete instruction: Build exactly this.

• Others want to understand the behavior: Build something that does this.

• Others care about the task the user is trying to complete.

• Others want to talk about the broader customer problem.

• Others are focused on metrics and business outcomes.

• And still others are thinking in terms of long-term strategic impact.

(These mandate levels are from…

All of those frames are legitimate. In fact, effort is happening at all of these levels simultaneously inside most organizations. The trick is recognizing which level someone is operating at, and knowing when you need to move the conversation up or down the stack.

This is part of why Richard Rumelt emphasizes how difficult it is to arrive at a real diagnosis.

In Good Strategy/Bad Strategy, he argues that good strategy begins with a clear diagnosis of the situation (he calls it the “crux”). But when you start looking closely at the layers and dimensions we’ve just explored, you begin to see why that’s so hard.

Different actors see different problems. The time horizon shifts. The level of abstraction changes. Some statements are about behavior. Others are about outcomes. Some are about tasks. Others are about systems.

Somewhere in that space lies the mysterious and elusive crux.

I remember an incredible moment when someone dropped a concise insight on a group of leaders.

Look, if we don’t beat our competitors in a new market and gain a sufficient lead, then we’ll be forever fighting an uphill battle because of high switching costs. So the contract value doesn’t matter. We’ll have plenty of time to sell them new products if we land them as a customer. We need to make it easy to get started and to adopt our core offering to create a beachhead.

People shifted nervously in their seats. There was a cool simplicity to the statement. The team had been debating the mix of new products ad nauseam, and this reframing shifted the whole conversation. Bingo! AND STILL, the immediate next discussion was about the problems beneath the problem.

Or another moment in a workshop mixing front-line ICs and the CEO of a big bank in South America. People were debating and debating, and a junior UX researcher calmly shared an insight about the different banking habits of the bankers in the country they wanted to expand into. These weren’t the same bankers they had success with in their home country.

A collective “aha!” And then the same… one point of shared understanding unlocked the next cycle of divergence and convergence.

You’ll often hear the advice that product leaders should define the problem teams should solve.

There’s truth in that. Teams do need clarity about what they are trying to address.

But I’d reframe it slightly. The work of product leadership isn’t simply defining the problem and handing it to the team. It’s creating the conditions where people can engage with the situation from multiple elevations and perspectives.

• Sometimes you’re looking at the customer’s stated problem.

• Sometimes you’re examining the surrounding ecosystem.

• Sometimes you’re digging into incentives and behavioral dynamics.

• Sometimes you’re asking what your product can realistically influence today.

• Sometimes you’re zooming out to long-term business outcomes.

Each view reveals something different.

Over time, the goal is to expand the web of shared understanding so that people across the organization can move fluidly between these perspectives, test explanations, challenge assumptions, and converge on the few things that actually matter.

Defining “the problem” isn’t a single moment. It is a space to navigate together.

I’m looking for about 20 minutes of discovery, and I’d be happy to spend the other 25 minutes chatting about anything to return the favor. My goal is 30 calls over the next couple of weeks. Not sales oriented in any way. Though I’d be happy to show you what I’m working on.

Grab some time here!

I’ve been thinking more and more about the challenge of defining “minimally viable consistency“ across a company’s operating system. From that post:

The general idea, in the context of how I’m using this, is that when you’re designing your company’s operating system, you should strive to have the fewest number of consistent concepts, terms, and phrases possible that still allow you to operate the way you need to.

In workshops, and in customer conversations, the idea has legs. It sparks great discussions about common interfaces, cognitive load, and the benefits of local variation. But it can be devilishly hard to get right.

Model Market Fit

You often can’t plan what things will take hold in a company. Perfect plans, glossaries, and frameworks fall apart, and then suddenly the idea you least expected to take hold at a global level catapults to the front. I think of this as Model Market Fit (MMF).

For example, I have a friend who has been gung-ho on the North Star Framework for years and couldn’t get it to stick. Meanwhile, their design leader peer was heavily involved in journey mapping. For some reason, journey maps took hold in the company. You couldn’t make them (journey maps) go away as a “consistent” idea, even if you wanted to. Everyone was talking about journeys.

I kept telling him, “Look, turn that driver tree on its side and lay it alongside the journey map, and you’re done. Stop being dogmatic!” He didn’t listen. And that played out predictably. (X, if you’re reading this, I told you so 🙂).

But this pattern holds in countless conversations. Ideas spread across companies in unexpected ways. Ask someone about the founding story behind key rituals or ideas in your company, and you’ll often be surprised to learn about what “won”.

Shifts in Strategy and Structure

I think one of the hardest situations is when strategy shifts, but the structure in your company hasn’t yet caught up. The strategy is changing. The structure hasn’t caught up, or you’re experiencing a temporary hit-and-shift. These are the moments when people become desperate for consistency, because they suddenly need to work across boundaries.

Working across boundaries benefits from consistency. Before, when things were less coupled, teams could get away with aligning on a couple of key things. Now there’s more demand.

I don’t have the answers here, except to say that it is largely cultural.

For example, do you start codifying a “dependency object” more consistently in your tool of choice? Do you start holding meetings around those dependencies? Or does that actually encourage the very thing you’re trying to stop? Are you willing to keep things ambiguous for a bit?

Many dependency management practices encourage premature convergence on solutions, over-reliance on estimates and guesses, and generally prevent leaders from resolving their priority differences. At the same time, treating dependencies consistently can be very helpful for overloaded, centralized teams. It can also become a weapon for over-eager teams that have the favor of leadership and want to command everyone’s time.

This is where things get tricky. You have to step back and think about the behavior you actually want.

In many cases, dependencies aren’t the real problem. Prioritization at a more global level is the problem. So you could decide on a graceful prioritization heuristic at the leadership level that doesn’t create too many negative downstream effects and resolves many of the dependency deadlocks.

But that is hard, so people don’t do it. And then suddenly, you are debating the common definition of a dependency.

Action Item: Be especially careful during a big strategic shift. You may introduce some “temporary consistency” to stabilize the situation, but don’t get too used to the new reality.

The Myth of the Standard Framework

One trap is assuming that because a framework is well known, teams are actually doing the same thing. Take OKRs. They feel extremely standardized. Everyone knows the terms. The books exist. The templates exist. The slide decks look similar. It creates the impression that companies are running the same operating model.

In reality, the implementations vary wildly.

Some organizations treat OKRs as a strict hierarchy. Others connect them loosely through shared metrics. Some anchor everything on quarterly objectives. Others build driver trees underneath. In some places, OKRs are deeply tied to financial planning. In others they function more like directional bets.

In Dotwork, we’ve started cataloging the different patterns we see in customer environments. The diagrams above are all “OKRs,” but the structures are fundamentally different.

The other trap is assuming that this variation is a bad thing. And maybe this is the beauty of the “consistency” of OKRs. The language is consistent enough that people can recognize it, but flexible enough that teams can bend it to their context.

Or maybe that’s the problem. You have to be the judge in your company.

Avoid The Pyramid

The further away ideas get from teams, the more ambiguous they seem to become. “Pillars,” “Vision,” “The CTO 5,” “Strategic Opportunities.” This makes perfect sense because these objects tend to do a lot of work. There is an optics component. There is a basic grouping element (”There’s so much going on, I need these in buckets”). You’ve got Slideware. You’ve got overlaps with the org chart (”portfolio”), which start eating into the actual meaning of a portfolio.

The unfortunate reality is that these are often the things people point to as the “consistent” ideas in their company, yet they are far from actionable. They are roll-up mechanisms.

All of which is to say there are better places to spend your time: on key, consistent fractal rituals, on your approach to framing bets, on new language around the unique, quirky habits you have as a company, on consistent kickoff formats, or a special document you use.

For example, a consistent culture around a certain quirky-named one-pager format will go a very long way. A “pillar” on the Parthenon slide will not.

Viability

The obvious problem is “viable for whom?” The CTO who believes everyone should work in two-week sprints so that they can generate a certain report likely believes that getting everyone working in two-week sprints is both viable and valuable. They probably don’t see a downside.

They may even see a looming existential threat that no one else sees (like someone with even more sway who believes they need a report). I’ve met leaders in this situation who know the downside, but rationalize that the people who really care will work around the rules anyway, and that the benefits of outward legibility and consistency outweigh the downside and the mild inconvenience of going through the motions of running sprints.

And I have to admit, sometimes I don’t fault their logic. They have a point.

The people gluing an organization together see the cracks formed by poor interfaces (they literally absorb the friction and cognitive load). Still, the people on the other ends of those interfaces might feel very differently. Finance needs to fit things in certain buckets. That’s how financial reporting works, and unless you figure out how to play that game in a more product-like way, you’ll have to play along with their “viable” game.

Building shared understanding around viability is hard.

Permanent Scaffold

The next challenge is to strategically use consistency as a scaffold when people are less experienced. It is a teaching aid. Before they go off freestyling, it can be helpful to have somewhere consistent to start. But then that gets old. Slowly, the guardrails come off, and you start to expect people to forge their own path.

The trouble is that companies are littered with these scaffolds. They represent the baggage of long-lost change and upskilling efforts, and as long as they are just a mild inconvenience, no one minds checking the boxes. But they can drag an organization down.

For example, say a team is learning new product discovery skills. It might be important to put a label on that, and maybe even tool-ify it. But as those product discovery skills become ingrained, you no longer need the formalization. Lo and behold, years later, there is still a checkbox in some system for “discovery complete”.

All to say that tread lightly when the goal is up-leveling and/or norming. Write down an expiration date, or at least a date to reassess the constraint.

Some Questions:

If this wasn’t consistent, what is the worst thing that could happen?

What actual risk are you trying to reduce? Confusion, coordination failures, reporting gaps, regulatory risk, something else? Be specific. If the worst outcome is mild inconvenience or cosmetic inconsistency, the consistency requirement may be overkill.

Does this idea make people’s lives easier or harder?

If it makes things harder, is the hardship justified by a real long-term benefit? Would customers actually pay for the outcome this consistency produces? Or is it primarily benefiting one group (leadership, reporting, governance) at the expense of everyone else doing the work?

Is the idea graceful? Does the idea bend well to local variability?

Is it strategically simplifying the situation? Or oversimplifying? Like any model, it will be wrong, but is it still useful? Does it clarify the system and help people reason about their work, or does it add more conceptual clutter?

Can teams adapt it where local conditions genuinely differ? Some variability is beneficial. If the idea breaks the moment a team operates differently, the consistency may be too rigid.

Are there cheaper ways to achieve the consistency you want?

If the goal is consistent behavior around something, could you nudge people in that direction without a heavy rule? Examples include examples, defaults, templates, visibility, or shared artifacts instead of mandates.

Does this consistency have an expiration date?

Is this a scaffold for learning, onboarding, or stabilizing something new? If so, when should it be revisited or removed?

What would it take to remove this later?

Once consistency mechanisms get embedded, they rarely disappear. If you needed to retire this rule or structure in two years, would it be easy or painful?

A back to basics post…

Yet, not so basic…

When you ship something, you’re not delivering an outcome. You’re delivering the potential of an outcome and starting a chain of effects that unfold over weeks, months, and years. You’re committing the organization to a new state that may or may not produce the results you want.

Each step in the chain is a hypothesis about what will happen next, supported by underlying assumptions. Over time we strengthen or weaken our confidence in these relationships, and areas of high uncertainty often signal both opportunity and the need for a leap of faith.

Work rarely affects just one thing. It usually sets off multiple chains at once, influencing different users, metrics, and systems in different ways. Some chains produce visible short-term results, while others only emerge months or years later.

Not all impact paths look the same. One effort may drive immediate sales outcomes, another deeper adoption and retention.

Begin with actionable inputs, specify the immediate effects you expect to see, and then connect those effects to longer-term outcomes.

Strategy is about choosing focal points in the system—where to act and what to move—rather than deciding in advance exactly how to act.

Research and insights help you choose what to try, where to focus, how change is expected to propagate, and how to learn from the results.

Teams often anchor on a stable set of inputs they can reliably influence. The roadmap is a collection of researched options they may choose to pursue, each paired with a causal hypothesis about what effects it should produce.

You are not limited to lagging outcomes. Goals can target the actions you take, the signals you expect to see soon, or the results that arrive later.

Rinse and repeat.