Here’s an area where I am optimistic about AI (for now, at least).

So many companies flatten things to meet the needs of the person with 1) the most power, 2) the lowest appetite for detail/seeing real-world complexity, and/or 3) the least amount of time to actually work through details and nuance. For good (and less good) reasons, a CEO says, “This is too in the weeds. There’s no way we are doing this much!” That one statement will kick off one of a couple of things:

1. Investing huge amounts of time in flattening reality to get that report to the “right” level

2. Not investing that time and just winging it last minute. A reasonable survival mechanism.

Sometimes #1 is shouldered by lots of people in the org. And sometimes the burden is shouldered by just a few people. But it boils down to few/many people translating one version of reality to another, simplified, flattened version of reality. The recontextualization tax can be massive. So massive, in fact, that companies often slip into just winging it because no one in their right mind would want teams dedicating that much time to pretending things work one way in order to get “simple” overviews, “simple” cascades that “roll up perfectly,” etc.

If you’ve ever been in these high-level meetings, you understand that the desire for simplicity and “less” is most often a survival mechanism. It isn’t petty. It reflects a real cognitive load barrier. They are hoping to “manage by exception” instead of viewing everything.

Which brings me to AI.

An area AI excels in is doing the grunt work of recontextualization and exception hunting (provided, of course, it has the raw context and that context is reasonably up to date). Specifically, if you have teams working in highly effective, emergent, varied ways, but you really want to flatten that information more artfully into one format, AI is a good tool.

Say I have 10 stakeholders, and each stakeholder likes information “a certain way.” Pre-AI, I didn’t have many options. I could:

1. Try to persuade them all to look at information the same way

2. Make 10 versions of every presentation so that we could have effective meetings

This is why roadmapping tools almost never travel around orgs: you have so many stakeholders/audiences, and they each have different needs out of the roadmap, which means that it is far easier to just PPTX or Miro it up ad hoc every time.

Now, you can let a team work however they want to work and write a skill for each of those audience segments, tailored to how they understand product, think about roadmaps, care about roadmaps, etc. It doesn’t matter if you want to basically work in GitHub issues and Google Docs; you can pretend that you work in nice swimlane roadmaps with clear deliverables and an orderly flow. Or in a outcome-oriented “move the metric” kind of way. Or whatever fits your fancy, and your audiences way.

At the new job, we don’t want to force different clients to play by our rules. We also don’t want to hyper-customize Linear to become a super-abstracted, “respond to every client workflow” tool. Clients want things their way and they come first. We want things our way so we can make our clients awesome. So my first area of focus is figuring out how to put together skills that translate how we need to work to a language that is empowering for every client and doesn’t force them to use words/concepts that they don’t want to use.

AI is great at this.

I get all the high-end AI use cases, but a lot of the value is doing something you wanted to do forever but didn’t have enough hours in the day to make happen.

You don’t reinvent the wheel. Just do what you knew you should do, but couldn’t.

I can’t get this out of my head.

I was doing book research recently, and I learned about a “secret” group inside a company called the Right But Early Club. The basic idea of the Right But Early Club, if I understand correctly, is to serve as a support group (of sorts) for people who are “right” (we’ll discuss this more in a bit), but who tend to be “too early” when it comes to bringing up issues, calling out problems, offering solutions, etc.

Ever since I learned about this, it has been ringing in my ears. I’ve been telling everyone about it and have learned as much from people’s responses as I did in the original interview.

I think we can all relate, in some way, to the *feeling* of seeing something before other people see it, or being “right” before other people have arrived at the solution we believe is right. I’d divide that into two feelings and one decision: 1) seeing it, 2) it sticking in your head and permeating your thoughts, and 3) doing something or saying something. We’ve also been on the other side, being peppered by people who were confident they were right, knowing that technically they were (at least partially), but also knowing it was too early. To quote a VP friend, “I see plenty of things that I know will break, but I’m able to filter them out so I can focus on today’s problem.”

Signal detection and attention gating are both important cognitive abilities.

The puzzle is that many RBEC people (or more accurately people in the RBEC mode, because we can be many things in different contexts) are unusually strong at the first and taxed by the second. Organizations need the first while (many people working inside them) disproportionately rewarding the second. 

“Gripe Club!?”

When I describe the RBEC in other contexts and ask what people think, I often end up really triggering some people. “Those are the people who just bring problems!” “It is easy to be right about problems!” “Sure, but do they do something, or do they just sit in their support group complaining?”

I think this is important for a couple reasons. Primarily because how deep the tensions run.

First is that some people can’t seem to let go of the idea of rightness without reward or effectiveness. “They must be bad at communicating the solution!” The idea that there is a group of people in an org with the right answer who aren’t being rewarded or heard is immediately translated as an individual problem because the formula, based on certain world and work views, doesn’t compute. And let’s be honest, it is kind of threatening

Imagine if the CEO knew that there was a club internally filled with people who were correct at figuring out which projects would fail, which campaigns would flop, which hiring decisions would cause material harm, but that somehow no one listened? Pissed! But that explains the immediate rationalization and blame. It has to be the person, right? Or a group of people—the middle managers hiding good ideas.

On the RBE side, you experience very strong feelings around fairness, acknowledgement, and sensitivity to people glossing over disagreement. You may notice not only that something is wrong, but also who is being asked to absorb the cost of everyone else’s convenience. A quick “let’s move on” can feel less like pragmatism and more like a refusal to acknowledge what is actually happening. This can make it difficult to let an issue go, especially when the disagreement seems consequential or when the people with the least power are the ones expected to adapt.

Identity Clash

Notice the core identity clash here. It strikes all the way to how they view competence.

For the RBEC person, competence may feel like: I notice what others are missing. I trace consequences. I protect the system from preventable harm. I don’t look away just because the problem is inconvenient or premature. Their identity is partly bound up in foresight, coherence, vigilance, stewardship, and intellectual honesty.

For the Right Now person, competence may feel like: I know there are a thousand possible problems. My job is to decide what matters now, create movement, make tradeoffs, and not let hypothetical future concerns paralyze us. Their identity is partly bound up in agency, focus, pragmatism, prioritization, momentum, and responsibility for outcomes.

(Note: We can be both of these people depending on the context)

As I mentioned earlier around signal detection and attention gating, it isn’t that either identity is right or wrong, it is more that many organizations need both capacities but are structured to reward only one of them. They need people who can detect weak signals, trace consequences, and notice what others are missing, but they also need people who can filter, prioritize, and act without being overwhelmed by every possible future problem. The tension emerges when the organization treats one capacity as competence and the other as dysfunction, rather than recognizing that both are necessary at different moments.

“Perfectionists!”

There’s a big stereotype that people in the RBEC take “being right” very seriously vs. achieving some sort of outcome they care about. That happens, sure, but I think it happens less than people think.

Let’s differentiate a smug “we’re right before anyone will accept the truth” kind of vibe and a “Yeah, we accept there is probably a timing issue, and that acting too soon might be premature, and that we struggle with raising these issues when we’re working from pattern matching and signals that might not easily translate.”

At least in my experience, people who are right but early often have a mix of skill and experience in the domain and are strong in cognitive abilities like pattern recognition, systems thinking, and counterfactual reasoning (stemming from both their skill/experience and natural wiring).

They may also be particularly tuned to issues around justice, equity, or preventing pain, which heightens the emotional connection. They also don’t find it as easy to filter out noticing, and therefore know they bring things up prematurely. All to say that the smug vibe stereotype may reflect some situations—I’ve been on both sides of the “accept the truth” dynamic—but it doesn’t reflect all, or most situations in my experience. These are people with normal egos, normal career identities, etc. who, for various reasons, find themselves in the RBEC.

Being “Right”

Part of being right but early is acknowledging that mere “rightness” is not enough. Context dictates why something is right. Say there’s no senior leader with the express responsibility to improve X. Being right that X needs to be improved, or being right about how to improve X, doesn’t do us much good. Or say that a founder’s world view will kill any effort that feels like [something they don’t like]. Right Now is also relative to the other fires that are burning or questions begging for answers. No one sees it all. Companies often have elephants in the room commanding a ton of attention among leaders that no one knows about.

Right != Right Now OR Right Here.

I think what is fascinating about this is that you could have a company holding two truths: that it might not be taking advantage of or harnessing a certain population’s ability to be right earlier, AND that the people who are right earlier have their own set of issues and challenges that they are dealing with.

They may understand that they are not being as effective as they could, AND at the same time there are environmental factors limiting their effectiveness. They realize they can be right and wrong at the same time.

Community

What stands out most to me about the RBEC is the idea of people leaning into their quirks and situation and building community connections. To me, that shows a very high level of maturity in the situation. In most organizations, you are lucky enough to meet a small group of people who share your experience, who you can trust enough to admit being “right but early” as a mix of a shared experience and a shared challenge.

Whenever I go to conferences, I am blown away by how deep the conversations get. It is as if people haven’t had a single moment to “speak freely.”

A final thought. I shared a draft of this piece, and someone responded, “Oh, I’ve been in one of those, like a gripe club!” And I think that’s sort of the heart of my curiosity right now. “Gripe club” doesn’t do it justice, IMHO. That still diminishes the skills and strengths of the people involved—and the tension they are navigating.

Being right but early.

If any of this resonates, maybe you should set up a RBEC in your company?

Being Righter Together

Say you’ve done that…there might be a path forward for everyone. You still want and need a RBEC. But there could be other options…

The goal isn’t to create a company where the Right But Early people are listened to more because they are secretly right. That just creates another version of the same problem. The goal is to create conditions where people can be righter together.

There is a huge difference between bringing up something early and demanding that everyone act on it early. But many organizations don’t provide much space between those two things. You raise a concern, and suddenly the group is debating whether to stop the project. You point out a weak signal, and people respond as if you’ve recommended changing the strategy. You notice a pattern, and now you’re expected to prove the whole thing.

Under those conditions, bringing something up early becomes expensive for everyone involved.

What if, instead, there were ways to say, “I think I’m seeing something. I’m not sure yet. I don’t think we need to act on it right now, but I think it is worth noticing.” Now other people have something to participate in. They can add evidence, challenge the pattern, connect it to something they’re seeing, or help establish what would need to happen for the issue to become more important. The Right Now people don’t have to surrender the present, and the Right But Early people don’t have to pretend they didn’t notice the future.

This seems like an important organizational capability. Companies need ways to revisit things when new evidence arrives. Otherwise, the only choices are “do something about this now” or “stop talking about it,” which is a pretty terrible way to learn.

And I suspect this changes the RBE dynamic itself.

If people know there is somewhere for an early signal to go, they may feel less compelled to keep pushing it. They don’t have to win the argument today in order to prevent the observation from disappearing. At the same time, other people get to participate in making the observation better. Maybe the person is right. Maybe they’re directionally right but wrong about the mechanism. Maybe they’re right about the problem but wildly early about the timing. Maybe someone else sees a constraint they don’t see.

I was active on Twitter for a long time. I likely met many of you during that time. I recently collected 50 threads and 500 tweets (many with images) in this simple viewer.

Check it out for a blast from ye olde Twitter.

I also made this strategy prompts activity for teams hoping to get good strategy conversations going. Give it a try with your team! Let me know how it went.

Remember, a real strategy should contain propositions that challenge something we would otherwise take for granted. The real test is doing the activity in multiplayer mode.

Until next week.

Everyone is talking about “return on tokens.” Vendors love it (as long as the news is good). Companies that had long since given up on any sort of value architecture or on understanding the ROI of product work are suddenly chomping at the bit. Which makes sense: they haven’t been able to lay off enough people to cover their token budgets while still hitting their promises to the board.

It is hard to know what sits below the surface: a genuine effort to understand how AI might augment human capabilities, or some version of “how many people can we safely fire?” Or both?

It is as if the whole world suddenly shifted from a buffet model to buying each dumpling one at a time, and now everyone is freaking out about the ROI of each dumpling. But we’ve been here before. We’ve been here with hours. We’ve been here with capacity. And the problems have always been roughly the same:

1. Spending more time on the “I” side than the “R” side of ROI.

2. Myopically choosing shorter-term, easier-to-attribute use cases for the “R” side.

3. Gravitating toward whatever is easiest to measure. And tokens are very easy to measure.

This post takes a trip through hours and flow metrics, detours into an alternative way of thinking about ROI, and eventually gets to TOKENS—everyone’s favorite dumpling.

My goal is to show that the underlying measurement problems are remarkably universal. AI introduces some genuinely new twists, but in the end, it still hinges on a theory of value.

With these comparisons, ask yourself, “How might this relate to the current return on tokens question?”

Leave a Coffee Tip!

Hours

Hours, as commonly used to understand investment, represent a major construct validity problem. There’s nothing inherently wrong with measuring “time we spent on things” (hours) to understand better where effort is going, provided you make it clear that:

1. Time is not a fungible thing that can be infinitely allocated/re-allocated. This holds across skill sets, team context, and even across a “normal day”. For example, the “magic hour” of uninterrupted morning productivity can be vastly more productive than trying to wrap your head around something complex between 4 and 5 PM. The developer deep in the onboarding space, an expert in onboarding analytics and the user journey, working primarily with what customers see/interact with, can’t be immediately swapped into a deep, legacy backend refactoring effort.

2. Where you allocate time tells you nothing about the “quality”, efficiency, or efficacy of that expenditure of time. The highly skilled developer reactively called in to debug an area of the code they have no experience with will not have the same leverage as someone more junior, but more contextually situated. Ten people spending ten hours each is not equal to one person spending one hundred hours. Sometimes the entire system is constrained by a single specialist, a single decision, a single dependency, or a single review. Spending time elsewhere has negative leverage.

3. The context switching tax is real. Most efforts to understand the allocation of time, whether explicit or implicit, leave out large time investments. Imagine alternating between two tasks every ten minutes for a six-hour day. You’ll spend three hours (at least) on context switching and calibrating/orienting around the new task. Coordination is multiplicative, while time accounting is additive.

4. The relationship between time and outcomes is non-linear. 2x-ing where you spend time doesn’t 2x the outcomes. You might bang your head against a problem for eight hours and get nowhere, and the ninth hour “unlocks” all the value. The metric treats the input as continuous even though the production function contains thresholds and fixed setup costs.

5. Where we invest focus can have a long-term effect. Imagine spending 5% longer on every enhancement to pay off a bit of debt and “garden” the codebase. Three years later, a version of the team—some people have stayed, but some have left—is absolutely flying. Where do you “book” that time? And how do you connect that investment to the long-evolving, game-changing “return”? Some hours multiply future options. Some hours limit future options.

6. Time allocation schemes often force allocations into individual buckets, but there are typically causal relationships between those buckets. They aren’t mutually exclusive. One impacts the other.

Lean/Flow Metrics (and “story points”)

Helpful, when focused.

Lean/flow metrics include cycle time, lead time, practical WIP limits, and throughput (e.g., N stories per week). Most of these metrics have a storied history in manufacturing, which is both a positive—there’s actual math, theory, and practice behind them—and a negative when misapplied to software development.

Note the following:

1. In manufacturing, it matters what you are producing. Things that have sufficiently different work processes, value profiles, etc. are always divided out. This is sometimes referred to as “classes of service,” and it is a critical component of using these metrics effectively. Without that segmentation, changes in throughput, cost, or efficiency may simply reflect changes in the mix of what was produced rather than actual changes in performance.

2. A lot of product work is more akin to R&D, experimentation, and initial “design” than to manufacturing and mass production. In this setting, “waste” isn’t an inherently bad thing. If you try five things and one works, then you’ve purchased the knowledge for that fifth thing.

3. What constitutes a work unit is also mushy. Say you have a more open-ended stream of experiments meant to move a metric; what do you measure? Experiments per week? The lead time of the whole stream? Both? Where do you put the opportunities that get discovery work, but ultimately don’t get greenlit?

4. When we talk about “capacity” in manufacturing, you are talking about the sustainable ability to meet a particular type (or types) of demand. “This factory can produce N of this variety of shoes every month.” You invest in a factory that can meet this forecasted demand, with optionality to scale up the factory based on new demand. So, going back to some of the issues with hours, capacity is not (always) fungible and is not something that is “spent” at the time of use. It is an emergent quality of the factory’s design.

5. The boundaries of the system matter enormously. “Lead time” from when? Customer request? Commitment? Ticket creation? First code change? And when is something done: merged, deployed, adopted, or producing value? Moving the boundary can dramatically change the metric without changing the work.

6. You have to be ready for the uncomfortable reality that “work” spends a majority of its time not being “worked on”, as well as facing all of your bad habits when it comes to keeping people busy.

7. Many of these metrics describe a relatively stable flow system that remains stable over a sufficiently long observation period. If the system is rapidly changing and has a lot of variability in work types, you can be lulled into a sense of apparent precision.

8. Don’t get me started on story points. Any effort to use story points for anything beyond a disposable tool to spark discussion, right-size, or reality-check a near-term cycle commitment is a dereliction of duty. We have decades of evidence to support this.

The main thing with manufacturing is that it is essentially a demand-based pull system. The things being produced have a price, and there is a clear distinction between “sitting on the lot” and “in the customer’s hands.” That makes the economics an order of magnitude easier to reason about. Theoretically, we could imagine features going unused as inventory, unfinished work sitting in queues as WIP, or capabilities built ahead of actual demand as overproduction.

But the manufacturing use case makes much more explicit assumptions about the “value exchange.” There is demand for a particular thing. The thing has an economic value. And value is realized when it reaches the customer.

“But how about throughput accounting!?”

Say you have a very stable work stream, with a lot of historical throughput data to draw from, with a very tight line to value, with relatively homogeneous units of work and stable demand characteristics; you might be close to saying something like, “We allocated N% of our capacity for that demand this quarter” using these metrics. This would more closely resemble throughput accounting.​

The caveat is that those conditions are not necessarily ideal in product work for various reasons: 1) you want to do work that might have longer-term leverage, 2) you might want variety, 3) you might want to shift things to meet emerging demand, and 4) some of the most valuable work may deliberately change the system rather than simply flow through it. The more dynamic, exploratory, and leverage-seeking the work becomes, the less comfortable you should be treating historical throughput as a stable measure of allocatable capacity.

All to say that certain shapes of work are a better/worse fit, and you have to be aware of the differences.

To be clear, I think a lot of these Kanban-style/manufacturing metrics, along with PR-level metrics like cycle time, review latency, and merge frequency, can be very useful for understanding the health of the system, especially when combined with classes of service/work. I consider all of these metrics/ideas “required learning” for product developers. But their primary use is for continuous improvement: helping a team optimize around a particular type of demand, understand where waste is accumulating, identify bottlenecks, and improve flow.

Everyone should read The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen.

Alternative

We will get into tokens and AI in a sec, but first an alternative to points and flow. The only way I’ve seen the ROI discussion work reasonably well is to keep the cost side deliberately broad and apply much more rigor to the causal model linking that investment to value.

1. Treat the team as the cost unit. Start with something like, “This team costs roughly $1.5M per year.” Don’t pretend you can meaningfully decompose that investment into hours, story points, or individual features.

2. Connect the team to a causal model. Each team should be linked to at least one model that connects actionable inputs and leading indicators to mid- and long-term sources of differentiated growth.

3. Clarify the demand the team is expected to serve. Be explicit about the types, sources, and variability of demand. This gives you some basis for judging whether the team’s capacity and demand are reasonably matched. If they aren’t, that becomes a separate question, or at least something you should call out explicitly.

4. Fund durable lanes of focus when possible. Invest in enduring areas of responsibility or opportunity rather than constantly funding one-off projects, features, or stories.

5. Maintain a business case for the team. Document the causal assumptions, validity of the proxies, expected returns, major uncertainties, and what would cause you to change the investment. The team business case should transcend projects. You know you’re doing it wrong when the whole rationale for a team was a project finished years ago.

6. Be explicit about the business/product lifecycle. An emerging idea, a scaling product, and a margin optimizer/commodity should not be evaluated using the same expectations or metrics.

7. Judge return through movement in validated proxies. Look for evidence that the things you believe lead to differentiated economic value are actually moving, rather than trying to attribute revenue to individual units of work. Always ask yourself, “Are we more or less confident about this value hypothesis?”

8. Use operational metrics for their intended purpose. Use flow metrics for continuous improvement. Use hours to understand time leakage and broad patterns of effort. But don’t use either as the proxy for investment itself.

I still can’t get over the fact that companies rationalize $1m+ “teams”, but then choose to bury their value under layers and layers of pyramids, programs, points, etc.

For more on this approach, some topics of interest might be causal inference, econometrics, measurement theory, structural causal models, proxy validity, Bayesian updating, leading indicators, and real-options thinking.

Tokens

Imagine for a moment that someone in finance greenlights investing $50,000,000 in AI spending (measured as input and output tokens). Let’s first compare that to an equal investment in “human capital”. Consider all the gotchas and open questions:

1. Organizational capital / positive externalities. Employees don’t only produce assigned outputs. They also create knowledge, relationships, routines, and institutional memory that benefit other work. This matters much more when AI is augmenting people than when it is simply replacing a task.

2. Fixed vs. variable cost structure. Salaried labor behaves more like a committed/fixed cost over the relevant planning horizon; token consumption behaves much more like a variable cost. That distinction becomes especially important as inference gets cheaper and more commodity-like.

3. Capital formation / residual value. What asset remains after the expenditure? Human work can increase human and organizational capital. AI consumption may leave useful code, data, workflows, or intellectual property, but only if the organization actually captures it. Otherwise, much of the spend is simply consumed.

4. Marginal versus average returns. The first $1M in AI spend may be extraordinarily productive because it targets obvious, high-value use cases. The fiftieth million may be going toward increasingly marginal applications. This gets even trickier if higher-priced models are being purchased for differentiated capability.

5. Neither human capital nor AI spend produces value in isolation. Their returns depend heavily on the complementary assets around them. In augmentation scenarios especially, the relevant system is often human + AI, not AI by itself.

6. Both suffer from the long-term costs of overproduction. Producing more than the system can absorb creates inventory, maintenance, coordination, review, and cognitive overhead. Cheap generation can simply move the bottleneck downstream.

7. A cheaper/faster build is not necessarily a cheaper asset. In software, most economic consequences occur after the initial act of production. A compelling substitution case at build time may still have poor lifetime economics.

Are they comparable?

A lot of these points hint at the same two tensions. Will AI ultimately augment or replace humans? And will it provide a commodity input that people add value to, or will it be a premium capability? Or both?

What is the dominant mental model at your company? How did it get that way?

We have an unusually precise measure of one input sitting inside an unusually uncertain economic system (tokens). We can know exactly how many tokens were consumed and what they cost. Tokens give you a beautiful meter and invoice, which can create a much stronger illusion that you have a denominator suitable for ROI.

But we are still reasoning through much fuzzier questions: Augment or Replace? Commodity or Differentiated Capability? Or are we paying for differentiated capability? What complementary assets does it require? Does it create durable organizational capability? Does it increase maintenance costs? Move bottlenecks? Encourage overproduction? Change the economics of the work over its lifetime?

What theory of the system are we betting on

A serious AI business case is less “What’s the ROI?” and more “What theory of the system are we betting on?”

1. We believe using AI for __________ will reduce __________ without materially increasing __________.

2. We believe AI will primarily augment/replace __________, resulting in __________.

3. We believe spending __________ on AI will be economically preferable to __________ because __________.

4. We believe making __________ cheaper/faster will not simply move the bottleneck to __________.

5. We believe increased AI-enabled production of __________ can be absorbed without creating excessive __________.

6. We believe the primary long-term asset created by this AI investment will be __________, rather than merely cheaper production.

7. We believe the human + AI system will outperform __________ on __________, after accounting for __________.

8. We believe the downstream costs of AI-generated __________ will remain below __________ over its useful lifetime.

9. We believe paying a premium for __________ will produce enough additional __________ to justify the premium.

10. We believe this investment works economically only if __________ remains true and __________ does not become the limiting constraint.

So rather than:

We will spend $10M on AI and generate $30M of value.

the intellectually defensible version is closer to:

We believe this AI spend will change this production system in these specific ways, under these assumptions, with these expected benefits, costs, externalities, and downstream effects.

Then ROI is almost the output of the hypothesis, not the hypothesis itself. This is extremely important given that everyone is learning at the moment. No one has figured this out.

Conclusion

I’m struck by one thing. Imagine for a moment that we understood team funding as a combination of salaries and AI spend. A team might look at itself and say, “Geez, we cost $1.5M a year in salaries plus $1M in tokens. What is our business case here?”

I understand that this is somewhat utopian. In many companies, the goal is explicitly to use AI to eliminate some portion of that team, its managers, or the surrounding organization, based on some substitution math.

But if you think about the problem at the level of the team + AI system, the solution is remarkably similar to the “alternative” described above. What demand are we serving? What causal model connects our work to differentiated value? What durable areas are we investing in? What assumptions have to hold? What evidence would make us increase, decrease, or redirect the investment?

In fact, this kind of business case may be a prerequisite for giving teams meaningful responsibility for AI spend. If you want teams to make intelligent tradeoffs between people, models, tools, and other forms of capacity, they need a model of the investment they are responsible for and the value they are trying to create.

The tensions point the way to the real decisions. Most of what we call prioritization is forging agreeable narratives. It resolves very little and produces very little real commitment. But if you pay attention to where the same arguments/tensions keep surfacing, where conviction keeps failing, where momentum keeps winning despite everyone’s better judgment...that’s where you actually need to make the hard decisions.

There’s something Gestalt about this: you already perceive the whole shape of the problem. Your intuition is already doing that work. The framework just forces you to decompose it back into parts and lose the signal.

Later on in this post I share a simple, actionable exercise you can do with your team to surface these tensions. But before that, let me lay out my case.

If you like the newsletter, consider…

Leave a Coffee Tip!

No One Retros The Framework. Why?

There are two parts to prioritization:

1. Prioritization judgement. What deserves attention and investment?

And then:

2. Prioritization-as-enacted

What would actually cause things to move in alignment with those priorities.

A lot of teams use prioritization to AVOID what is sitting right in front of their face. Instead of having the harder discussions, they slip into perpetuating the same old fake rigor and safe decisions.

I rarely, rarely talk to teams and hear “Oh well, during that prioritization exercise three quarters ago we really dropped the ball on prioritizing that because it was 3 not a 4.” Or “Woah boy, we really should have allocated 60% of our time there instead of 41.23% based on the CoD calcuation.”

I almost always hear something like “We just didn’t have the conviction to stop _______.” Or “We just kept plodding away on [something decided on two quarters before that] and everyone knew that was wrong.” Or “You had 20 teams saying they were slowed down by X, and we still didn’t have the political will to prioritize that measly platform investment.” Or “Let’s admit we were wrong about [that thing] and move on.”

The conversation in the retro is never about the framework. And always about how people rationalized, communicated, showed up, and made sense of things together.

Teams will spend hours/days/weeks trying to invent some sort of “defensible” system, when massive asymmetries and “problems to prioritize fixing” are sitting beneath their noses.

You don’t need more options! Or more spreadsheets!

The example I use is how as individuals we’re often swimming in the things we should be doing, the self-care we should be performing, the nagging tasks holding us back, and the big threats looming on the horizon that we can’t quite mobilize or motivate to tackle. Sitting down with a spreadsheet and trying to “reason things out” doesn’t solve the problem. The same with teams.

Most prioritization discussions obsess over prioritization judgement. But it is the recurring argument around prioritization-as-enacted that can be incredibly informative.

Instead of:

“Let’s prioritize again”

You instead should ask:

“Why has our existing prioritization process repeatedly produced this particular tension?”

Theoretical vs. Enacted Prioritization

The missing thing isn’t belief. It is commitment under present-day inconvenience. Good prioritization isn’t simply choosing the right work. It is recognizing the traps and tensions that prevent your portfolio of bets from panning out the way everyone claims it should.

I can’t count how many times I’ve been in a room where there seems to be a lot of agreement about some far-off threat—something we should do, something existential even, but not immediately existential. But for various reasons, despite the “priority”, the team can’t mobilize any sort of conviction. Maybe it will involve too many teams. Maybe there is currently “no clear owner”. Maybe there are differing opinions on how much energy to commit based on perceived levels of problem and solution certainty.

A lot of time, the key problem is that the problem is intangible. It is a future threat that people find all sorts of ways to rationalize will somehow work itself out. Every pre-mortem singles out the threat, and every quarter there are half-hearted efforts to take it seriously, but nothing happens.

When their guard is down, I’ll ask about some sort of existential threat looming on the horizon. There’s rarely disagreement about what that thing is. It doesn’t need to be rationalized. If there is disagreement, it is between markedly different futures with existential issues, or a comparison of existential problems (we need to live to even worry about that). Or magnitudes of disruption. The problem is imagining what action right now might look like. It isn’t some sort of rational, measured, economics-informed debate.

Is this a prioritization problem?

Well, yes, in many ways it is. But it isn’t the kind of rational pros vs. cons, risk, upside, effort conversation that people normally associate with prioritization.

Similarly, I can’t think of any work situation I’ve been in where there isn’t a priority people love to work on. The value is tangible. No one questions it. It is fun. It feels meaningful, at least on the surface. Saying yes has become a well-worn, habitual knee-jerk reaction, and no one is really complaining. In a meeting, trying to defend your value? Mention this priority. But there’s also a widespread intuition that it might be too much and that it is getting in the way of something far less comfortable, and maybe way less easy to rationalize. There aren’t enough guardrails. You’re running a very serious risk of exploring the wrong side of the effort/outcomes curve. No one wants to be the person to say “we can have a bit too much of a good thing”, but you really need someone to say that.

Is this a prioritization problem?

Again, yes. But because the work is happening right now, and because teams have a tendency of avoiding discussing the priority of “work in flight” (and because people get used to fun things that feel even a bit meaningful), you’re starting to drift from a standard prioritization motion.

Tension Patterns

Those are two motions. Here are some others:

• Areas where you need to pass along a “default yes” because prioritizing all the individual items will not result in anything getting prioritized (the meetings are more expensive than just cranking)

• Areas with a ton of inertia where someone needs to call a big reset to save the effort. The reset IS the item to be prioritized

• Efforts that have been almost-done forever and just need one concentrated push to finish (different from the reset because you know the direction is right, you just need to stop tip-toeing around the close)

• Priorities that keep boomeranging because there is insufficient data/discovery, so people keep saying “when we have more data”

• Early-stage efforts that need care and room to grow, but not a free pass. The big decision is to really commit to planting the seed, and caring for it (without falling into “innovation lab” or “hire to get anything done” syndromes)

• Effort blocked because you don’t have the “capability” yet. The big decision is whether to (and how to) build those chops

• Important efforts where there’s a credible path to radically less scope that still captures most of the value (this is more of a lens, it can apply to almost any of the above)

• Priorities that feel urgent because “the window is closing.” But is the window real?

• Modest-looking efforts whose real value is indirect: they make a dozen other things faster or better. On paper they should win every conversation, but they get bogged down because the priority is less sexy, and everyone wants the benefits without funding/helping that shared capability (crisis of the commons)

There’s a polarity between many of these. You can’t do everything at once. You can’t cap the comfortable thing AND do the consolidated push AND plant the seedling AND fund the capability gap all in the same quarter. You keep a tight portfolio of risk profiles across time, value, and urgency. But it is not nearly as mathematical or rational as we think. It is more like managing tensions: knowing which ones to hold, which ones to release, and which ones you’ve been avoiding.

My theory is that even when we try, we’re not doing any sort of “rational” prioritization. But instead of fighting that, you can actually use prioritization tensions as a signal on the way to a more balanced portfolio of bets.

Conventional discussions of prioritization assume something like: “We have several plausible things we could do. Let’s compare value, risk, effort, confidence, etc. and decide which ones to invest in.”

But in my experience, the real problem starts AFTER that. We often know what we should do — that isn’t the problem. We know what the existential threats are. We already know we’re overinvesting in some things. We already sense which projects need a reset. What we’re struggling with, or don’t have the conviction to do, is how to create the organizational conditions required to act on that knowledge.

Meanwhile, you’re currently doing a lot of things you should either not be doing, should spend more time on, or should radically change your approach. The challenge is two-part: yes, you need to be considering the right or less wrong options, but it is also HOW you approach those things.

Exercise

Try this with your team. Fill in the blanks. If you can’t fill one in, skip it.

1. “We keep coming back to _______, but no one has a clear solution. And we seem unwilling to jump headlong into it. Every pre-mortem singles it out. Every quarter there are half-hearted efforts. But the threat is just abstract enough that there’s always a plausible story for why it might _______. We keep pushing it off to _______ and hoping that’s enough.”

2. “No one debates that _______ is important, and that is part of the problem. It’s fun. It feels productive. Saying yes is a well-worn habit. But unless we set limits, we’ll keep polishing it forever, well past the point of diminishing returns, while _______ starves. We’ve probably already captured _______% of the value.”

3. “Unless we agree to do _______ in principle, we’ll keep wasting time trying to prioritize each and every little piece of it. No single item is big enough to survive a prioritization meeting. But collectively? People should just be able to pull from this pile whenever _______. The value comes from doing it in _______, not batching it into some giant future initiative.”

4. “Everyone in the room knows something is off with _______. Confidence has dropped since _______. But the momentum is crazy. Ask a question, you get shot down. Nobody wants to be the person who held up the train. What we actually need to prioritize is permission to _______ it.”

5. “_______ has been almost done since _______. Everyone is tired of it. We keep giving it scraps of attention, and it keeps lingering. _______ stays blocked waiting on it. We need a short-lived period of extreme focus, or we need to stop pretending. That means explicitly saying _______ slows down for a bit.”

6. “We keep discussing _______ but never actually learn anything new. Someone is always ‘doing discovery’ on it amidst _______ other things, but nothing real emerges. We need to spend real, concentrated capacity resolving _______ before we can move.”

7. “_______ needs room to grow. We can’t judge it by the same standards as _______. We need to protect it and give the team leeway, but also hold them accountable for _______. The question isn’t ‘Is this paying off yet?’ It’s ‘Is this developing in a healthy direction?’”

8. “We keep calling _______ important, but no one will fund it, stop _______ for it, or hire against it. Is it important enough to displace _______? Important enough to add capacity for? Or neither? We either invest or say no.”

9. “What’s really stopping us on _______ isn’t the work itself. It’s the investment to be able to do it. We keep wishing we had _______, but we haven’t prioritized building that muscle. We have to prioritize our ability to do this, not just doing it.”

10. “The scope on _______ is huge. But there’s a credible path to radically less scope that still captures most of the value. What if we just did _______? There’s an 80/20 here if we’re willing to seriously test _______ before committing to the full thing.”

11. “_______ feels urgent because _______. But is that window actually real? What specifically changes if we wait until _______? Sometimes the answer validates the urgency. Sometimes it exposes something people just want to do now.”

12. “On paper, _______ looks like just another effort. But if you consider everything that would benefit, it’s critical. _______ gets faster. _______ gets cheaper. Unless you explicitly account for what it multiplies, it will always lose the prioritization conversation.”

Each one of these mad libs is designed to surface a tension, and a potential prioritization decision. Use them before you use whatever framework you had in mind to get the real questions and decisions on the table.

These are the real tensions to resolve.

I wanted to send a huge thank you to my paid subscribers. They don’t get anything in return but still support the newsletter. Until recently I didn’t have a way to do a one-off tip. But now I do. I you like the newsletter, consider…

Leave a Coffee Tip!

North Star Framework

“Should I try to implement the North Star Framework with my team?”

(Note, I wrote the North Star Playbook while at Amplitude, with Jason Scherschligt)

North Star Framework is an interesting idea, but it is probably most valuable as a teaching tool, not as a practical practice. That isn’t to say that some companies don’t “do it”, because they do, but that it is more valuable when it comes to teaching things like leading/lagging metrics, actionable inputs, building (and testing) causal models, avoiding vanity metrics, and the “art” of crystallizing a unique strategy for your company vs. playing a standard game.

When I check back with companies/individuals who attended workshops, it is very common to hear something like, “I learned a lot, and we sort of adapted many of the ideas. We have multiple KPIs, leading and lagging, and some things aren’t as worked out.” The people who didn’t get value out of it tried to install it as a framework and eventually hit resistance with the inevitable edge cases, exception handling, etc.

This is all to say that what follows will work in some of these ideas, but will not be about the North Star Framework.

(Here is a Miro activity library for NSF)

Trees/Pyramids

“Should we build out one of those vision-to-tactics pyramids to get everyone aligned?”

Next, this might sound heretical, but I don’t recommend “pyramids” that build a tree starting with vision, strategy, tactics, etc. I know they are super common, but I find that they often end up distracting people. If someone owns something, and if people are working on it / working towards it, then by all means make it clear. But most companies end up with a bunch of buckets and maps that seem wholly designed to “simplify” things for leaders, and to abstract the idea that lots of real work is happening.

There’s nothing wrong with label taxonomies, but people start to imagine that those labels are real things. Most of the time they aren’t—they are roll-up mechanisms, and seem mostly designed for 1) deckware, 2) and a false sense of organizational symmetry or “clear” roles and responsibilities. Sure, make a pyramid slide if you need that kind of thing to leave leaders feeling aligned, but then put it to the side to start generating impact.

Put another way, there’s only one place that “the work” is happening, and that is at the front-line team level. It may have gotten there through layers of the org, but the work—the problem solving, creativity, hands on keyboards, interactions with customers (hopefully), etc.—is happening on the front line. Real strategy is messy, non-hierarchical, might span days or years, and doesn’t fit into neat boxes, so don’t waste time trying to do that (or at least don’t waste too much time).

Stable Teams?

“Everyone says we need stable, durable product teams. Is there a downside?”

There has been a lot of talk about “stable” product teams, but I wanted to dig into the dark side of this. A lot of companies are struggling because they build internal kingdoms around “stable” teams. They rationalized these highly durable capabilities that would exist until eternity, based on sort of irrefutable logic (we’ll “always need that”). Or, they wanted to build something, a short-term project, and everyone was busy, so when money was plentiful they just spun up a “new team” to build it. And then a director. Then a GM. Before you know it you have three layers of hierarchy built around “products” that didn’t really exist.

And then…the only way to unwind this is layoffs that really impact people’s lives. Not because you couldn’t, in theory, re-assign those folks to different areas—because you could—but because the physics of the org chart, and how layoffs work, necessitate you to blindly unravel your prior org chart decisions.

Which is all to say that “stable” teams and “durable” ideas are only useful until they aren’t useful, and sometimes knowing the difference is hard. Of course, leaders will not say this outright (or at least the CEO’s who speak publicly about layoffs). They might make vague mention of bureaucracy, the “work around the work”, etc. But the reality is they scaled too quickly when money was more plentiful, and now need to rationalize how to unwind all of that.

Shipping Smaller/Faster

“How do I get my team to ship smaller and faster?”

In my experience, it is way easier to teach a team that can work small to think big, than a team that thinks big, to work small. Both are possible, but they require different approaches. A team that can deliver continuously, regularly, get frequent feedback, and generally keep the tempo of changes, assumptions tested, and risk reduced HIGH, is a godsend. It is a gift. If you have fostered an environment AND the skill/experience landscape to make this possible, you should always cherish it.

Now, that sometimes means the team will be short-sighted, and may iterate to nowhere. You run the risk of having a “functional” feature factory with broadly usable things that don’t really move the needle, but if you can do this you’re well on your way. As mentioned, this is part environmental. You can absolutely have people who are good at this at their last company, completely flounder if you’re constantly interrupting them, changing the strategy, loading them up with WIP, and always asking them to prematurely converge on estimates, etc. Environment matters.

But creating that environment AND working small are skills you have to hire for, and nurture internally. Put another way: you can’t make shots you don’t take. The team has to be able to get changes out into the world and HAS to be able to measure impact. They also need chops at rapidly considering options, and figuring out how to slice up those options to get the most leverage possible.

Cycles

“What’s the right planning cadence? Quarters? Sprints? Shape Up cycles?”

Quarters are too long to help you work small, and too short for the bigger, meaningful things you want to do. 2w sprints are too long to help you work small, but too short for the big meaningful things you want to do. 6w is actually a decent forcing function, because you can fit some pretty darn meaningful things into 6w, but if you are operating a company at any sort of scale, you might feel a bit of whiplash thinking only in 6w bets. It is doable, but you’ll find yourself 1) tackling things that are actually bigger than 6w on occasion, 2) losing a sense of the more durable “lanes” in the 1-3 quarter range, or longer.

This is all to say that time is WEIRD. It always feels too long, and too short. There are always opportunities to work smaller, and there are always situations where working small misses the “bigger picture”. But here’s a bit of philosophy: life is only happening NOW. We are navigating a landscape shaped by past decisions, and we are forging ahead into a partially knowable future, but at the end of the day what really matters is what is happening right now.

Why is any of this important? First, don’t get beholden to any one cycle as “the” cycle. You are almost certainly missing something. Second, don’t let your selection of cycle get in the way of working small (or thinking big). The number of teams I see chasing their tails because of some arbitrary quarter cycle AND magically making all their bets take one quarter is insane. SHIP! LEARN! Don’t wait around for a quarter.

If quarters are causing some sort of wholesale rebalancing of effort, that is a sign you 1) probably need to be working smaller AND 2) probably have some tough prioritization questions to make in the longer timeframe. Instead, people treat these cycles at any duration as “boxes to fill”, and it is incredibly damaging. A quarter is not a big sprint. It never was. And any effort to scale up “sprints” to “quarters” to make them somehow more corporate-compatible is a perversion of the idea.

Lanes

“What does it actually look like when a team is really humming?”

All the best and most productive/effective times in my career have followed a pattern. A handful of somewhat stable “lanes” with a couple metrics and directional sense of the opportunity, and then a team just cranking it out week after week. What happened last week? What’s happening this week? What’s working? What isn’t? You’ve probably felt the same thing at some point.

The puzzle here is that despite how salient this all feels, it can be devilishly hard to recreate these conditions. People look at all sorts of frameworks, devices, tools, tricks, etc. yet the actual “feeling” is way simpler. It feels like: a tension between the more stable, and the more rapidly changing. It feels like: a strong bias for action and movement (even if that action is discovery/learning). It feels like: talking about things you DID and what you learned, and less about talking about all the things you plan to DO, and all the things you hope to LEARN. 80% of the energy is on the here and now.

This doesn’t mean that everything is short-term and myopic or “purely tactical”, because you’re like a mountaineering group navigating a mountain where you are always scanning at multiple resolutions AND choosing your next step wisely.

Why is any of this important? Teams will go to the ends of the earth to avoid this motion because it is scary. They’ll invent all kinds of work to get in the way of the sheer, raw, unfiltered act of getting stuff done, and holding each other accountable. And course correcting based on what they’ve learned. They’ll spend weeks and months “going back to the drawing board and building alignment” because they are scared about the sheer act of doing, and potentially marching off in the wrong direction.

So it is like this elusive “vibe” that you know when it is happening, but can be hard to get into for various reasons—with all sorts of excuses we make to ourselves and to each other about why it isn’t possible. I don’t think this is laziness. It is very human fear. It is the fear of forward momentum under conditions of uncertainty. It is the fear of “picking the wrong things”. It is the fear of showing up at the meeting and saying “oh yeah, a million things came up last week, we need to have the uncomfortable discussion about whether I should have said NO to those things.”

Humans doing normal human things in the context of the team creates these conditions. So the burden is that we’re ALWAYS trying to converge on this vibe, and always slipping out of it. That is the work—of ICs, non-ICs, everyone.

Deciding On How You Work

“I’ve got a bunch of senior people who can’t seem to agree on how to work together. What do I do?”

Experienced teams/people are especially prone to this: you can get a bunch of smart people together and half the time is spent just reconciling different variations of how they like to work, and their quirks. People can be terribly “nice” about this and try to fill in the gaps. But experienced people, especially, often just want SOMEONE to decide how things will work. It isn’t because they can’t figure it out—they can—but all the waffling and gap filling, and back channel influence can be a huge drain. Can someone PLEASE just define the game and the playbook and let’s get moving!

This doesn’t mean everyone needs ultimate certainty or needs all the t’s and i’s dotted (experienced people rarely need that), and with water under the bridge you rarely need things concrete and explicit, but when you get a group of smart people together who haven’t worked together, you should bootstrap the whole thing with “V1” of a way of working that people generally agree with, and get moving. Leave all the theorizing for the future. The team can adapt as it goes along.

Note: I’m not talking a dictatorial motion here. You could collectively decide to get in a meeting, write some initial working agreements, and go. Or you could say “Hey Bob, I hate to do this but can you just hammer out the V1 for how we’ll work”. Either way is fine. My general point is that teams waste so much time and brainpower trying to arrive at a reasonable game, and I think it is better to just start with V1 and go.

The big risk here, of course, is that the person trying to figure out this game is trying to oversimplify it, deck-ify it, or make it palatable for the people who aren’t actually doing work, which ends up meaning you have a starter OS that doesn’t really reflect how people work. It is a showpiece. You don’t want that.

Estimation

“How precise do our estimates need to be?”

You don’t really need to estimate at resolutions more than 1-3d, 1-3w, 1-3mo, 1-3q, 1-3y. That’s it. Anything more is a waste of time. Importantly, be very clear about the “thing” and make sure you’re working at the atomic level. You can have a big messy project that is 1-3q, that while being amenable to “breaking down” is just what it is. It is a 1-3q bet.

It might help you to imagine a bunch of 1-3w and 1-3mo bets that “add up” to this big thing, but the important thing is you have a 1-3q bet, and you’ll have to figure out how to work small, de-risk often, and use your company’s money wisely. You could also have a 1-3q bet that is more open-ended, amenable to experimentation, has a bunch of pivot/proceed points, and can be funded iteratively based on outcomes and progress. OK. In that case it may help to think of it as “housing” a bunch of 1-3w, 1-3mo bets. That makes more sense.

But it is an inherently different relationship between the “things”. You don’t need to finish all the “things” for the big thing to work, whereas with the 1-3q big messy project you probably will need to make significant progress across the things. In the experimentation friendly example, you might only need the first couple. In the big project example, you don’t need all the details, but you do need a strategy for de-risking the thing over time.

With both, you can STILL meet up every week and talk things through, and you will still (hopefully) have inertia every day towards the goal, but it is a different motion. So: don’t tear yourself up with estimates.

Lanes Revisited

“How do we organize ongoing work that isn’t just a list of projects?”

I had a mentor once, a product leader, who just showed up one day and said “Look it is all about the lanes.” He was referring, roughly, to more durable, outcome oriented swimlanes. They might show up on a roadmap, on a slide, etc. This was a deceptively powerful statement when you understood how this played out in practice. We’re not talking kanban lanes (which tend to depict a workflow), and we’re not talking about value streams, though the idea is similar. Sure, you can use a lane for a long project, but that isn’t the basic idea.

But basically: “Hey, for the next couple months or quarters we’re going to keep these couple things stable, revisit them, measure them, and let them guide the way. And when they stop making sense, we’ll change them or pivot.” This seems so basic, but it isn’t. It is far easier to come up with hand wavy strategic pillars, or generic “buckets” that all work falls into. Or to come up with discrete little projects. It is much tougher to find that perfect balance of durability, outcome-oriented, actionability, non-fluff, customer impact, causal model, etc. that a team can ACTUALLY work with.

This was one of my learnings with the North Star Framework. One of the real benefits of the NSF was the idea of the actionable inputs and really tweaking those until you had some that held together and withstood the test of time (but weren’t so open ended, or so “bucket-ish”, that they didn’t really guide any action). The idea is somewhat fractal, although any time you start making trees of things, you have the potential to water things down.

Imagine a company with 150 teams. That is about 450-600 lanes, roughly. With some lanes for the big stuff that has to cross teams. “Oh god,” the leader says, “That is so much. There’s no way I can possibly go into a meeting and discuss 600 things.” To which I would respond this way: your lanes are costing you millions of dollars, or at least in the high six figures (think a team might have a couple that stay stable for a year). Are you really telling me that you can’t bother with understanding your million dollar investments? “Oh, but we will when we roll those up,” … to which I respond, “Oh really, to the extent that you’ll pressure test these very real bets?”

Here’s my take. Just admit you have 450-600 durable lanes, and use AI, routines, and rituals to hold yourself accountable. Use label taxonomies if you really need to roll stuff up. But realize that the work is happening at the lane level.

Shapes Of Work

“Can we treat all our initiatives the same way and use one template?”

Lean into the fact that things have different shapes: different risk profiles, different levels of experimentation friendliness, different “sizes”, etc. I’ve never done a shape exercise with a team and ended up with anything lower than 5-8 key shapes of work. This is not about being overly pedantic and categorizing everything, it is more about never imagining you can see initiatives, epics, bets, or whatever as apples to apples, and resisting efforts to standardize or oversimplify.

I’ll give you an example. Most companies have a launch tier where product marketing describes the nature of the launch from a marketing perspective. But guess what? Some things are going to be incredibly disruptive internally, and require a ton of coordination, but marketing isn’t going to make a peep out of it to customers. In fact it may be critical for customers not to know anything about the launch. The “simple” distinction between internal blast radius and external launch demands has confused so many companies I’ve worked at, or advised….just that tiny distinction. 9/10 someone in marketing would say “yeah, but we need to keep it simple”, and their categorization scheme would pervade with executives and others.

Don’t do that. It doesn’t mean that everything needs to be analyzed to death—but know that the work we do defies simple categorization schemes and labels. To get around this: don’t use templates. Look at the THING. Read it. Write about it. Be explicit. Let people raise the nuances. Surface the differences that really matter. And do anything you can to not flatten everything you do down to someone’s slide deck. Sure… you may eventually need the slide deck, but that isn’t reality.

Routines (Creatures Of Habit)

“How much process does a team actually need?”

Routines: it doesn’t matter if they are explicit or implicit, but have them. Great products are built on routines. They can be very fluid. They can be more strict. But they are there. These collective habits are what makes great work happen.

The key problem is the degree to which routines either 1) get processified to the nth degree, all but eliminating any chance that they are effective, or 2) are so implicit and so loosey goosey that when something changes, it makes it hard for the team to reset quickly. A group of experienced people can go very far with just “meeting when it makes sense”, but even experienced people are vulnerable to the traps. They are vulnerable to the traps of not raising risks because it is uncomfortable. They are vulnerable to the traps of avoiding hard conversations, of getting carried away with status quo bias and not challenging their direction when it makes sense, and putting off the tough call “one more week”, when they really need a coworker to set them straight (or at least try to).

Routines are the heartbeat. And I think to some degree we are creatures of habit. We start enjoying our routines when they help us regularly. You can make the agenda variable, but it pays to get people in a room (virtual or otherwise) to connect.

Everyone has been on that team that starts with best intentions, has a great weekly meeting, stays on the gas, and then as elephants in the room accumulate and priorities fracture, they start to lose it. Leaders spend more time in other rooms planning for something far off, than connecting on what is happening right now. People do 1:1s to plot out what’s next after the impending collapse everyone knows will happen. All to say that if you can push through—push through that thing that happens four weeks in where either 1) it becomes a zombie meeting everyone sleepwalks through, or 2) it stops happening all together—then you’ll be better off.

AI

“How is AI going to change how we work?”

AI? AI will turbocharge your bad habits and turbocharge your good habits. My hunch is that 80% of the world stays exactly the same, all the principles apply, and now you have this tool to do better work in all the ways you know how (hopefully). You could use it to do things you know you should have been doing this whole time, but didn’t have the time in the day. Practices are changing every week. One week it is ____ engineering. One week it is ______ engineering. Back and forth. So yes, you will need to innovate on the practices, but expertise still matters / chops still matter.

Example: say you have an org that was running a feature factory before AI. BETTER feature factory. Say you have a team that was thoughtful about collecting research but was short-staffed, and couldn’t keep up with organizing their research library. Bingo! Better at all that. Amazing. Or you knew you needed to instrument analytics, but never got around to it. Write a skill. Instrument more analytics. Boom!

The real danger is that some people don’t know what good looks like, or have never worked in an environment that did truly high leverage work, and that’s setting the bar for them around what they think AI can help with. Another example: synthetic personas. Before AI I could create a synthetic persona. It took a bit, but it was doable. With AI I can make terribly persuasive synthetic personas. Is it a good idea? For what? For what boundaries? For right now, at least, only skill will give us an answer there. It is going to be a wild ride, and practices a year from now will likely look very different (while we’re potentially digging out from a huge crash and picking up the pieces).

Outcome-centricity (Misunderstood)

“Everyone says be outcome-oriented, but how do you actually do it?”

Outcome-centricity is hard, and I’m tired of people describing it like some kind of mindset, etc. There’s a reason why the cart optimization team at an ecommerce company gets more love/attention, than some team doing design systems. It is closer to money. There’s no free lunch. You will need to build a causal model that starts with near term things you can influence, linking up to the long-term things that will propel your company forward.

Even harder, it isn’t all math, or even mostly math, because you are SHAPING the future as well as measuring the changes you introduce, and how they impact near term things. If it was an easy math formula, everyone would be doing it. It isn’t! It takes conviction, leaps of faith, etc. As I always say, if everything was an A/B test and you knew the lifetime value of every customer, and if every pattern that happens now has happened a bunch of times in the past, then you are a phone company, and you are a commodity.

I mention this because all the talk about projects to products and outputs to outcomes, etc. etc. is way too theoretical. It doesn’t get to how uncertain it is, and the mix of math, conviction, storytelling, and narrative you need to make it all work. So it leaves teams feeling they’re never doing enough, and completely negating the routines and practices—the staring at input metrics, revising, discussing assumptions, checking, monitoring, switching things up—needed to make it all happen.

I worry I’ve been a part of this, though I try to make a big point that you can think of outcomes at various time scales and resolutions, and that it is all a “model” that we keep refining. Or at least I try to.

Better Questions

“Do we need to have all the answers before we start moving?”

Related, what really matters is that you’re always asking better questions, not necessarily that you have all the answers. You can improve your ability to answer questions over time. But some teams do activities where they are GREAT at asking powerful questions—things that really land—but then they seem to go back to ho-hum business as usual. It is like they take off their “good question” hat because they’ve had the “oh you’re the type who doesn’t get anything done and only asks good questions” line.

Not coincidentally, asking better questions is a function, in a sense, of getting answers. Answers let you sharpen new/better questions. This all goes back to routines and tempo. You’re knocking out work on your lanes, you’re asking good questions, you’re getting some decent answers, you’re double-checking your core assumptions, you’re progressively moving the needle….that is far better than having the perfect answer in every meeting.

Good Goals

“How should we be thinking about goal-setting?”

Goals. Set them. But don’t be ruled by them. Goals can be set for anything: learning goals, shipping goals, outcome goals, goals on near-term metrics, goals on lagging metrics, goals on practices, goals on continuous improvement. The big anti-pattern I see is that people just go through the goal motions, and they don’t mean anything. Or they just dream up everything they want to do, and goals are sort of the “success metric” afterthought. Mix up your goals—prescriptive, descriptive, near term, long term, leading, lagging— and lean into the HABIT of goal setting, not the performance of goal setting.

More…

“Anything else top of mind?”

A couple more to make it 20:

1. Lean into anchor artifacts: stuff you write and revisit, vs. always reinventing the latest doc format, the last initiative brief, etc. Revisit. Do they still make sense.

2. Real progress can be sensed daily and weekly. Even if it is “big stuff” or “hard stuff”. It is all about coaching the team in how to break things up without losing the big picture.

3. I get tired of the “leaders are the only people doing long horizon” idea. Anyone at any level can be thinking about multiple horizons. More experienced people can often reason about longer horizons a bit better (or know when reasoning over longer horizons doesn’t make sense), but ideally you have those experienced people on the front-line. If not. Why? There’s gotta be some power ICs who love showing people how to do the thing.

4. I always say this: but powerful ideas imperfectly measured are more important than perfect measures for not so powerful ideas.

Boring Product

“What does good product work actually feel like day to day?”

Boring product. It is in the doing. Every day. Every week. Moving things forward. Thinking across horizons, but not being caught in the past, or dwelling in the future. It is a collection of habits. You can tell a mile away when something isn’t working for a team. Just listen. Do you hear it? Do you hear the motion? The learning? The connecting the small to the big? Or is it always like a movie that never seems to find its footing. Trust your instinct with that.

Hopefully this was interesting. I know my writing doesn’t seem actionable sometimes, but I do my best to get advice out there. My Achilles heel, which is probably evident in this post, is that I know a ton depends, and a ton of this is about nuance and rolling with the changes. Let me know if any of this helps.

If what you are mapping is incoherent, don’t fall in love with the map (or your personal ability to navigate with it). Use it to refactor what you see.

Here’s why.

More Coherent Organizations

When strategy, structure, technology, and incentives are coherent, an organization can leave a great deal implicit. A team and its mission become reliable shorthand for its goals, ownership, work, funding, and intended path to impact. These are technically distinct structures. For example, work isn’t the same thing as goals, and teaming isn’t the same thing as a product taxonomy. But when they map cleanly to one another, there is little need to name every distinction, map every relationship, or maintain separate representations.

You can look at the teams or the goals and reliably fill in the blanks. There is tons of context, but there’s little need to spell it all out. In a coherent organization, what you learn from one map remains useful when you switch to another. In an incoherent organization, what you learn from one map may stop being useful the moment you switch to another. You have to reorient, translate, and fill in the blanks all over again.

Coherence lowers the energy required to make sense of what is going on—the “context.” For humans. And for humans using AI.

The best metaphor I can come up with is a city with several map layers.

The layers might show streets, utilities, public transportation, neighborhoods, zoning and land use, school districts, political jurisdictions, and so on. All of those things are different. But when the structures mostly line up, you don’t need to keep naming which map you are using. If you say “downtown,” people can infer transit access, building types, land use, population density, and patterns of activity. Imagine flipping through the layers in an online mapping tool: each layer shows different information, but the layers seem to line up. When you are out walking around, things make sense.

Back to organizations.

Less Coherent Organizations

Imagine something critical to the business that involves eight teams spanning eight different product hierarchies, all with competing goals; silos across product, technology, and design reporting lines; unclear ownership; theoretically distinct customer segments; different impact hierarchies; and different funding hypotheses.

Suddenly, you’ve lost your bearings.

A consultant friend described navigating an environment like this:

“I’d meet with a team and be completely blindsided by what they were getting into. I had to sit there and go through all of their work just to make sense of it. I found myself constantly surprised: ‘You’re doing what? Why? For who? Who made that call?’”

This is like a city where every map layer cuts across the others differently. The school district boundary runs straight through the middle of a neighborhood. The buses follow one set of corridors, while the trains and bike routes follow completely different ones. The place everyone calls “downtown” is split across two municipalities, three zoning districts, and several utility providers. The nearest fire station technically serves somewhere else. Parking permits, building codes, public services, political representation, and transit access all follow different boundaries.

This doesn’t mean some people don’t absolutely know their way around. They may feel perfectly at home, know which unofficial paths to take, and reliably get what they need done. Sometimes you can even pay people to help: expeditors, tour guides, brokers, fixers, or longtime locals who know which office to visit and whom to call. Individual neighborhoods can also feel perfectly coherent, at least until you need to cross a boundary to get something done. But the fact that insiders can navigate a place does not make the place coherent. It may simply mean that navigation has become a specialized skill.

And this is the big puzzle.

A company can become extremely sophisticated at documenting dependencies, translating between groups, creating cross-functional forums, hiring fixers, and building tools that help everyone navigate the incoherence. Those things may be necessary. But they can also lower the immediate pain enough that the underlying incoherence never gets addressed.

AI will not magically make context coherent. It can surface and compare the maps, and maybe even call out incoherence, but it cannot make conflicting structures, incentives, goals, and definitions line up. In fact, when it smooths over those contradictions, it may exacerbate the underlying tensions while producing the appearance of alignment.

The goal is not perfect coherence. Perfect coherence would likely require either stasis or an organization so tightly constrained that it could not adapt. The goal is to notice where the maps have stopped lining up, decide which gaps matter, and continually bring the most consequential ones back into alignment.

If what you are mapping is incoherent, don’t fall in love with the map. Use it to refactor what you see.

(I have a question at the end, if you get there)

Picture a company annual kickoff.

Leaders are sharing a strategy that is objectively not a strategy. Not just by a purist’s standards, but assume for a moment that the experienced people in the room all know it isn’t a strategy.

So we have:

Believers

The less experienced people in the room who are happy that someone seems to have a plan. They’re not skilled enough to know what a strategy is. If it sounds somewhat coherent to them, they’ll be excited.

Players

The experienced people in the room who know it isn’t a strategy, but also know the “game” behind the real strategy. They know that the annual kickoff is a performance. They know how to play the funding game. They know where the “real” conversations happen, and the spreadsheets where those conversations get codified. But they also know when to nod, when to smile, how to nail their slide, and generally keep the show going.

We can probably split these folks into the hard-core Dark Triad people, the “you just don’t understand how hard leadership is” crowd, the “some things we just can’t say out loud because it would demotivate them” contingent, and the “savvy operators who know how to get stuff done, know this doesn’t matter, and are pretty decent people” crew.

Oh, and the “if we focus, people will phone it in, so our strategy should be ambitious and we should try to do everything” crowd. But that’s a post for another day.

Checked Out

Next, you have the people who have checked out of these types of meetings. They do great work, but they’ve learned that somehow nothing discussed in these meetings really matters, unless it does, at which point their ears immediately perk up. For example, if there’s a shift around RTO.

For the most part, the meeting sounds like “blah blah blah” white noise to them.

Purists

Then you have the purists who seethe about it not being a strategy.

“This is bullshit!” they say.

“This is a bad strategy! I read the book!”

“These people are incompetent, self-serving, or both!”

Confused Coherence Checkers

And then you have the folks who are genuinely confused. They aren’t naive like the purists. They know this is a bit of a show. But they are sitting there wondering if they somehow didn’t get the memo.

Given everything at stake, why NOT put a real strategy up there? Even if it were a bit watered down?

“Am I a chump for not playing the game the #2s are playing?”

“I mean, surely they don’t believe this is a strategy. Or do they?”

They feel tempted to raise their hand and ask a question, but immediately sense that might be a bad idea.

“This is a $150,000 meeting,” they wonder. “Am I missing something?”

They feel for the teams that are going to bear the brunt of the ambiguity. They aren’t just noticing that the strategy is incoherent. They are already imagining the meetings that will follow, the conflicting interpretations teams will make, the work that will continue despite the supposed priorities, and the people who may later be blamed for failing to execute.

“I feel that, with just a bit more work, we could have turned that into a great presentation!”

The last time they said that out loud, they were told to be more of a team player. They are also trying to calculate whether saying any of this now would help, embarrass someone, derail the meeting, damage their standing, or simply mark them as difficult.

They know that every presentation leaves things out. They know leaders cannot explain every constraint, tradeoff, political reality, or unresolved disagreement to the entire company. They are not asking for perfect transparency. What bothers them is that the gap between the presentation and reality feels large enough to change what people will do.

2x2: See It, Tolerate It

Imagine a 2x2.

• Cannot see it, Can see it

• Can tolerate it, Cannot tolerate it

The less experienced Believers can tolerate the incoherence, but they also can’t see it.

The Players can see the incoherence, but they can tolerate it. They might even relish it.

The Coherence Checkers can see the incoherence, and it bothers them. But oddly they are “in their element” when untangling it.

“Do we have to get into all the gory details? No. But we should at least help the team navigate the current reality and do our best to inform decisions.”

They are trying to reconcile what leadership says, what leadership believes, what leadership is doing, what employees will infer, what teams will try, and whether speaking up would damage their personal situation or the team’s situation.

The “But it isn’t a strategy!” purists can’t tolerate it, but they also don’t fully see it. They dismiss the social function of the performance entirely and are naive in their own right, though technically correct.

The checked-out people sit outside the matrix. They have figured out that neither seeing nor tolerating it matters enough to waste their energy on.

If these were animals, you’d have:

1. The Golden Retrievers: Slides! Go!

2. The Foxes: Some predators. Some socially intelligent. Some both.

3. The House Cats: Conserve energy.

4. The Terriers: Conceptual violation registered. I will not let it go.

5. The Border Collies: I’m watching. I’m getting more agitated. The signals don’t match. I can see the people. I can see the performance. I see the constraints. I can see what the teams are about to misunderstand. I’m trying to stop herding everyone.

The Border Collie Faustian Bargain

It is a Faustian bargain of sorts for the Border Collies.

You can become a Fox, and maybe have more impact, if you surrender your right to challenge the fiction. But you risk, over time, becoming responsible for persuading everyone else that it is true.

You stop asking whether the ambiguity is helping the organization and start treating its preservation as part of your job.

At first, you rewrite the confusing message for your team.

Later, you explain why leadership had no choice but to make it confusing.

Eventually, you find yourself correcting the person who points out that it is confusing.

The bargain rarely presents itself as, “Sell your soul.”

It is more like:

• “Be realistic.”

• “Don’t undermine the team.”

• “You’ll understand when you’re more senior.”

• “Get some influence first, then you can change things.”

The system teaches people that being “responsible” means protecting your boss, avoiding visible failure, keeping your options open, toeing the line, and making difficult outcomes and decisions appear impersonal.

The risk?

You begin producing the conditions you originally hoped to navigate. You tell yourself you are staying close to power so you can make things better, but your job gradually becomes about protecting the ambiguity, conveying it downward, and disciplining the people who point it out.

You become a Trapped Fox. You say, “I’m done with this place,” and then stay for six more years.

Or you become a Nomadic Fox, moving from company to company, arriving with fanfare and a reputation as a fixer or seasoned operator. With a flick of the tail, they locate the real decision-makers, learn the game, build a coalition, and become indispensable.

1. Enter as an outsider.

2. Decode the system.

3. Become indispensable.

4. Hit the limits of influence.

5. Decide the organization is hopeless.

6. Leave for a new, more interesting puzzle.

Back to the Border Collies

Back to the Border Collies, assuming they haven’t gone the Fox route (yet).

Of all the players, they are carrying the most in their heads.

Do you bark and name the contradiction in the room?

Backchannel it to someone who may actually have the influence to change something?

Herd locally by translating the ambiguity into something your team can use?

Leave the field after deciding that the organization’s coherence is no longer your responsibility?

Or conserve energy like a cat?

The Question:

What advice do you give Border Collies?

Comments appreciated!

Early in my product career, I wore many hats. I conducted research, analyzed data, sketched interfaces and wireframes, wrote requirements, coordinated releases, answered support questions, and even, shudder, wrote some code. Some of that was empowering. Some of it was amateur hour. But it was all bundled into the loose idea of “product management.”

Over time, those capabilities separated into dedicated roles and disciplines.

Designers, analysts, product marketers, program managers, and product-operations teams developed deeper expertise than any one generalist could reasonably maintain. Some joined cross-functional teams and became part of the daily work. Others became centralized experts that teams accessed through requests, reviews, and shared services. Repeatable parts of their expertise were then encoded into analytics platforms, design systems, research repositories, templates, standards, and workflows.

A role is only a temporary bundle inside the system. Capabilities themselves are distributed across people, teams, routines, tools, platforms, institutions, and external partners. When technology changes work, it rarely swaps cleanly for one person or role. Instead, capabilities move through several different motions:

• Specialization: broad work splits into deeper expertise.

• Diffusion: expertise spreads to more people.

• Centralization: expertise concentrates somewhere else.

• Integration: separate capabilities are coordinated.

• Embedding: expertise moves into tools and routines.

• Rebundling: separated capabilities come back together.

• Externalization: capability moves outside the organization.

• Elimination: work genuinely disappears.

• Loss: work disappears before its underlying capability has been reproduced elsewhere.

The Headlines

Scan the recent headlines and work appears to be changing in every direction at once.

Product managers are becoming “AI builders.”

Designers are becoming “designer engineers.”

Software engineers are becoming managers of AI-generated code.

Data platforms are absorbing parts of data engineering, analysis, and model development.

Middle managers are becoming “player-coaches” and “org leads.”

Product titles are collapsing into a single category: “builder.”

Roles are simultaneously broadening, disappearing, becoming more specialized, and merging with adjacent roles. There are several different motions happening at once. You have all the patterns I described above.

• Technical and analytical skills are diffusing across role boundaries.

• Product, design, engineering, and management tasks are being rebundled into broader roles.

• Knowledge is being embedded in AI tools and externalized to platforms.

• New specialties are appearing around architecture, evaluation, orchestration, reliability, and governance.

• Some repetitive work is genuinely going away. And some organizations (though they may not realize it yet) are losing the apprenticeship, coordination, context, and judgment that the old work helped sustain.

The headlines are observing different capabilities moving in different directions and collapsing that story into catchy headlines.

Capability Moves Through Loops, Not Stages

It is easy to imagine the motions in the design example as a linear journey, or a single, repeating loop. In practice, there are many loops occurring simultaneously, and each motion is creating pressure and tension for other motions.

Each motion changes the conditions around a capability and creates pressure for another motion. Specialization produces depth but ALSO handoffs. Diffusion creates access can ALSO eventually produce inconsistency. Centralization produces consistency but pulls decision-making away from the people closest to the work (or context away from centralized capability). Moving expertise into tools so people don’t have to perform the work directly (embedding) can weaken the learning pathways through which they develop judgment.

These loops do not occur in a fixed sequence. Several may operate simultaneously, at different levels and over different periods of time. A capability might be:

1. Diffusing across teams while control over its infrastructure centralizes;

2. Embedded in technology while new specialist work emerges at its frontier;

3. Externally supplied while internal capability is rebuilt around direction and assessment;

4. Rebundled into broader roles while its underlying knowledge becomes increasingly specialized;

5. Made more productive while the resulting increase in demand creates more work overall.

Each loop describes a recurring tension that may produce useful adaptation, harmful instability, or both.

What Actually Changes With AI?

I often ask myself, “Does AI change the physics of this pattern?” That is difficult to answer because a system can continue to obey the same underlying principles while the variables change so dramatically that those principles appear in entirely new forms.

There is already evidence that AI is affecting specialization, diffusion, centralization, integration, embedding, externalization, convergence, and loss. The real questions are to what extent, under what conditions, and with what second- and third-order effects. For example:

Diffusion

To what extent will AI allow experts to distribute their expertise more easily, without being constrained by the rigid interfaces we rely on today?

AI can make codified expertise available to more people, but we do not yet know how well it transfers tacit, contextual, or embodied expertise. Polanyi (1966) put it simply: we know more than we can tell. If that remains true, diffusion through AI will have a ceiling that is difficult to see from outside the expertise.

Integration

Can it actually lower the cost of specialists working with generalists and with each other?

The translation, handoff, and queueing burden created by specialization is real, and AI can friction-bust. But it hasn’t eliminated the “social” work of coordination, negotiation, and shared judgment.

Convergence and Rebundling

There’s a version of the future where individuals and teams recover capabilities that previously required several dedicated roles. A new kind of higher-level generalist.

AI does let people perform tasks across more role boundaries. But producing more kinds of artifacts is not the same as possessing the underlying expertise.

Specialization

And where will the opposite happen? AI is already creating new areas of specialization, new forms of technical complexity, and new specialists required to build, evaluate, govern, and adapt these systems. It may reduce demand for some specialist tasks while creating entirely new specialties around context, evaluation, orchestration, governance, and exception handling.

Embedding and Extension

Expertise is increasingly being encoded directly in tools and workflows, allowing people to act competently without possessing the underlying skill themselves. This is not hypothetical. It’s happening now. The question is what happens to the role that remains: it shifts toward direction, assessment, and oversight, which are genuinely different skills.

Centralization

AI may broaden local access to a capability while concentrating control over models, infrastructure, standards, data, and defaults in a small number of firms. More people become locally capable. Organizations become collectively dependent on increasingly centralized systems. Both things are true at once.

Loss

What happens when tasks disappear before the judgment, context, relationships, and learning pathways they sustained have been reproduced elsewhere? An organization may preserve output while losing the mechanisms through which people become capable of evaluating, correcting, and extending that output. The MIT Work of the Future task force (Autor, Mindell, and Reynolds, 2020) warned of precisely this: cutting out middle tasks can destroy workers’ skills, networks, and career pathways even when the immediate output looks intact.

All of these dynamics are in effect. What remains unknown is how far each motion will go, which will dominate in different contexts, and where those capabilities will eventually settle.

Limitations

What’s getting in the way of having honest discussions about AI’s long-term effects? The hype is deafening. Science always has trouble with longer-term effects. We don’t understand each other’s work well enough. And time plays tricks on how we process what is happening.

Hype

The hype is so omnipresent that many organizations are spending more time copying other companies, listening to vendors, and signaling that they are “doing AI” than conducting disciplined experiments around specific problems.

That is one of the defining dynamics of a bubble: spending money and taking visible action become signals in themselves. Each company’s activity becomes evidence that other companies should act, regardless of how much value is actually being produced.

This makes the underlying phenomenon harder to study. We are observing the technology, vendor incentives, executive expectations, labor-market anxiety, competitive signaling, and FOMO interacting at the same time. The hype does not mean the technology lacks value. It means adoption is not clean evidence of value.

Research

The second limitation is not unique to AI. Researching any change that touches individuals, teams, technologies, incentives, workflows, institutions, and markets creates severe limits on the general claims we can make.

A study may show that AI improves performance on a particular task (and population, model, and context). That does not necessarily tell us how a role will change, how a team will reorganize, what new coordination costs will emerge, or whether the initial gains will persist.

Many of the outcomes that matter most are also difficult to observe in short-term studies. Do people continue developing expertise? Will teams become more or less capable? Will organizations become more resilient, or more dependent? Strong evidence about a bounded task can easily be stretched into a much larger claim about jobs, organizations, or society.

Consider something like a codebase. Understanding how AI changes quality, maintainability, and the team’s collective knowledge would require a long-term, deeply contextual study. Long-term ethnographic studies of a codebase are difficult.

Flawed Mental Models

Beyond the hype and the limits of research, we bump up against a common foe: ignorance.

What we do know is that flawed mental models will remain flawed mental models, and they will continue to produce flawed assumptions.

1. If you imagine that making products is akin to operating a factory, you will likely miss the mark when assessing AI’s impact on product development. You will be more likely to assume that producing requirements, designs, code, and releases faster necessarily means producing better products faster.

2. If you miss the fact that data scientists spend a great deal of time helping people frame useful questions, you may assume that natural-language querying eliminates the need for data expertise.

3. If you treat a codebase as a pile of code rather than the cumulative record of decisions, constraints, failures, compromises, and hard-won knowledge contributed by everyone who built it over time, you may assume that generating replacement code is equivalent to replacing the system.

The average patient cannot determine whether a doctor truly understands cardiology, so they rely on licensing, training, certification, hospital privileges, and peer review to make that judgment for them. Inside companies, specialist work is rarely protected by an equivalent system.

Instead, people encounter familiar-looking outputs: a screen, a chart, an interview, a roadmap, a status report. Because the artifact looks understandable, they assume the underlying work is understandable too. The question shifts from “Is this person qualified?” to “Doesn’t this look like something I could do?” AI makes that confusion even easier. It can reproduce the visible artifacts of expertise long before it can reliably reproduce the judgment, context, coordination, and exception handling that made those artifacts valuable.

Time

These limitations share a common theme:

We have not had enough time.

History helps us recognize broad patterns, but not how they will settle around AI. We may be late in the S-curve of the current model architecture, early in the curve of AI adoption, and barely beginning the curve of organizational adaptation. AI is not one curve, but a stack of technical, economic, and social curves unfolding at different speeds.

So asking whether AI is “early” or “late” is too simplistic. The timing, magnitude, and interaction of these curves will determine which capabilities diffuse, which concentrate, what new organizational forms emerge, and how much damage the surrounding bubble dynamics cause along the way.

Conclusion

How do you introduce these ideas safely into your organization?

Carefully.

Raise a measured concern about the erosion of skill and judgment when AI use veers more toward substitution and delegation than augmentation and learning. This concern is already fairly widespread and accepted, so you should not get into too much trouble.

You might ask:

Which routine activities are helping people build the judgment they will later need for difficult situations?

And then:

If those activities disappear, how will that judgment be developed and maintained?

From there, introduce the capability motions and feedback loops. Do not present them as a grand framework that everyone must adopt. Use them as language for describing what people are already seeing.

• Where is expertise diffusing?

• Where is it becoming embedded?

• What is centralizing?

• What is being externalized?

• What has been rebundled into broader roles?

• Where are handoffs shrinking, and where are new ones appearing?

• Which loops seem to be producing the outcomes you want?

The point is not to classify everything perfectly. It is to make more of the system visible. The discussion about AI magic has been especially fruitful for me and several colleagues. Once people stop treating the technology as an independent intelligence arriving to join the workforce, they can begin asking more grounded questions about the system around it:

• What context does it have?

• Whose knowledge has been encoded into it?

• What remains outside its reach?

• Who is capable of assessing its output?

• Who controls the infrastructure and defaults?

• What happens when it reaches an exception?

Good luck! Whatever we can do to encourage richer conversations, grounded in reality, not mired in the weird duality of “humans vs AI”, will help us adapt and learn.

Here’s a simple model for thinking about AI success in organizations.

The Variables

Machine (Technology) Understanding

How AI actually works. The inputs and outputs. The failure modes. You don’t need an expert-level sense of the math, but you need a viable mental model of how the technology and what it is doing. Understanding the costs (based on a very incomplete current sense of the costs). Said another way, you have to get past the “magic” of AI.

Problem Understanding

Context, domain experience, skill, customer knowledge, constraints, history, politics. Everything that makes your problem a real-world problem and not a generic problem. If you are at risk of falling into the Build Trap, you’ll just do it faster with AI.

Practice Evolution

How the work actually gets done. Experimentation, feedback loops, workflow adaptation, team learning. The connective tissue between knowing and doing. Accepting that there are no “best practices” yet. Things change every week.

Social Contract

The organizational commitment that improvement gains will be used in line with a shared agreement, not against the people who generated them. And that the work remains compatible with who people are and who they are becoming.

Resistance to AI mandates is a perfectly rational behavior. Kaizen only works when there’s a credible social contract that the gains from improvement will not be captured against the improvers. Without that contract, you don’t get resistance out of ignorance. You get resistance out of rational self-preservation.

But it is not just defense. This is not just people “afraid for their jobs.”

The jury is genuinely still out. The data is not there (especially over any reasonable period of time). The resistance is not merely emotional or self-interested. In many cases it reflects an accurate reading of the evidence. People are being asked to cooperate with a premise that has not been proven, and that might be used against them if it ever is.

Failure Modes

The formula is multiplicative. Any term at zero in the numerator kills the product:

• Machine × Problem × No Practice Evolution
  You know what AI can do but never update how you use it. You assume the practices have been figured out.

• Machine × No Problem Understanding × Practice
  Fast iteration in the wrong direction. No ability to evaluate the results.

• No Machine Understanding × Problem × Practice
  Deep expertise, no sense of what the machine is doing underneath. When the technology changes you are unaware. Can slip into “it is magic” thinking.

• Machine × No Problem Understanding × No Practice Evolution
  Demos and pilots disconnected from real work. No practical way to put it in motion. No real applicability.

• No Machine Understanding × Problem × No Practice Evolution
  You know it isn’t working, but have no idea why. And no way to refine your practices.

• No Machine Understanding × No Problem Understanding
  New workflows for their own sake.

And when the denominator is broken—when people don’t trust where the gains will go, or feel the work threatens their identity—the formula collapses regardless of how strong the numerator is. You get rational resistance, not incompetence.

Most AI mandates fail because they try to force one term in the numerator high while ignoring the other two. “Everyone must use AI” is a Practice Evolution mandate that assumes Machine Understanding and Problem Understanding will take care of themselves. They won’t.

And even if the numerator is strong (even if people understand the machine, know the problem, and are ready to experiment) without a credible social contract, honest effort never arrives.

The denominator is not optional. It is the precondition for everything above the line.

AI does not eliminate complexity, coupling, coordination, uncertainty, or decay. But it can change the cost, speed, and feasibility of responding to them.

or:

AI does not work in the same way across different portfolio puzzles.

This is absolutely not a new idea. Companies have long thought about software as a portfolio of assets, investments, bets, and liabilities. What interests me here is not the metaphor itself, but what happens when we combine it with value, carrying cost, movement over time, and AI.

This is more of a Sunday-morning diagramming and thought-provocation post than a fully worked-out framework. None of the underlying ideas are especially new. I’m mostly interested in placing a few familiar concepts next to one another and seeing what becomes easier to notice.

Let’s go!

Carrying Costs and Value

Some assets create substantial value and remain relatively cheap to carry. Some create value but have become expensive to change, operate, and support. Some are still bets. Others continue consuming resources long after their economic case has weakened.

The question is not whether the code is “good” or “bad.” It is:

What value does this asset create, what does it cost us to carry, and what should we do next?

That gives us a simple 2×2.

Place each software asset according to the value it creates and what it costs to carry. Its position suggests the basic economic posture: incubate, compound, refinance, or liquidate.

Motion and Arc

Consider the arc of a startup.

It begins with low value and low carrying costs: a relatively cheap bet. Some bets prove their value and move toward Compound. As they scale and mature, carrying costs rise, pushing them toward Refinance. From there, a healthy company either restores the economics or eventually Liquidates the asset when its remaining value no longer justifies the cost of carrying it.

Other bets never prove much value at all. When the team keeps building anyway, the product moves right without moving up, turning a cheap experiment into an expensive obligation: the build trap. Liquidation is not necessarily failure. Refusing to liquidate often is.

Once you see the portfolio this way, you can also see the different moves available.

You can expand returns, reduce drag, harvest an aging asset, scale with drag, or slip into negative compounding. But the “pure” movements are mostly abstractions. Products rarely move perfectly up, down, left, or right. Growth usually brings some additional drag. Reducing carrying costs may sacrifice some value. Harvesting is often a deliberate movement down and left.

The more interesting question is not simply where an asset sits. It is:

Which direction is it moving, how quickly, and is that movement intentional?

Debt

These categories and movements make technical debt easier to see in financial terms. Debt is a financing choice: we accept higher future carrying costs in exchange for reaching value sooner.

• In Incubate, that can be dangerous because we may take on obligations before proving the asset has value.

• In Compound, it can be rational leverage if the added drag helps expand returns.

• When the interest begins to consume too much of those returns, the asset moves toward Refinance, where the task is to restructure the system and restore its economics.

• And when the asset no longer creates enough value to justify either the debt or the cost of repaying it, the right move may be Liquidate.

The same technical debt can therefore be productive leverage, an expensive constraint, or a liability, depending on the value of the asset carrying it.Portfolio Over Time

Platforms

These categories also help clarify the difference between an effective and ineffective platform strategy. A good platform may create a visible concentration of cost, but it earns that investment by helping many other assets increase value, reduce carrying costs, or do both. A bad platform becomes another high-cost asset that pushes complexity, dependencies, and coordination overhead across the portfolio. The relevant question is not how much the platform ships or how many teams use it. It is whether the platform improves the economics of the assets that depend on it.

We’ll get into more traps later, but platforms have a fun assortment of traps to contend with:

• False Economies of Scale: We centralize similar-looking work without proving that sharing it will reduce total carrying cost.

• Platform Too Early: We standardize an emerging pattern before we understand what is actually stable and reusable.

• Platform Too Late: We wait until duplication and divergence make convergence painfully expensive.

• Adoption Tax: We reduce complexity for the platform team by pushing integration, migration, and exception handling onto consumers.

• Mandate Trap: We mistake compulsory usage for evidence that the platform improves anyone’s economics.

• Dependency Bottleneck: We centralize capabilities and accidentally centralize waiting, prioritization, and failure.

An Intentional Portfolio

There are always inflows and outflows between these categories over time. Some movements are intentional portfolio choices. Some are unavoidable byproducts of growth, scale, and aging. Others happen accidentally, through oversight, avoidance, or outright negligence.

So portfolio health is not only about the mix of assets at a given moment. It is also about what is flowing where, how quickly, and whether anyone is managing the movement.

This frame also makes it easier to see familiar organizational traps as recurring patterns of movement between the categories.

The Traps

The Build Trap is what happens when Incubate fails to become Compound, but keeps accumulating carrying cost. Limits to Growth appears when Compound succeeds, then steadily gives way to Refinance. The Success Trap emerges when current winners dominate so completely that the next generation of Incubate assets disappears.

There are plenty of other patterns hiding in the diagram. Some are failures to prove value. Some are failures to preserve the economics of value. Others are failures to renew, simplify, or finally let go.

Not A Monolithic Situation

The critical question when it comes to AI is:

Which movement are we asking AI to accelerate?

AI does not enter a neutral system. It enters a portfolio with a particular mix of bets, winners, drag, and aging assets. Depending on the situation, it can help move an asset upward, leftward, or back into healthier economics. It can also accelerate exactly the wrong motion.

Depending on the answer to that question, you can better understand the risks you need to mitigate.

For example:

• In a Build Trap, AI can help teams prototype and synthesize feedback faster. It can also make it much easier to keep building without stronger evidence of value.

• In Limits to Growth, AI can help with refactoring, migrations, dependency analysis, and automation. It can also pour more throughput into the very constraint that is already slowing the system down.

• In a Success Trap, AI can make adjacent exploration much cheaper. It can also help the company optimize its current winner so aggressively that it stops looking for what comes next.

• In a Zombie Portfolio, AI may finally make old systems affordable to retire. Or it may make them cheap enough to tolerate forever.

The same capability can improve the economics of the portfolio or deepen the pattern that created the problem. So the AI question is not simply:

Will this make us faster?

It is:

Faster in which direction?

AI does not eliminate complexity, coupling, coordination, uncertainty, or decay. But it can change the cost, speed, and feasibility of responding to them.

The physics do not change. The coefficients, thresholds, and economics may.

• How to thrive when you feel misunderstood at work, or

• How to thrive at work when you think too much

So here’s the introduction, along with a bunch of posts that tie in. A favor: if any of this resonates, and you have someone in mind who might benefit from reading it, please forward it along.

Subscribe now

Introduction

Have you ever heard something like this at work and felt hurt, confused, angry, defensive, or even combative?

“You’re always overthinking things.”

“You see misalignment that isn’t there.”

“You make things too complicated.”

“You are too theoretical.”

“You have to learn how to keep it simple.”

“You need to keep your emotions under wraps.”

“You focus on problems and not solutions.”

“You keep bringing up things that are settled, why?”

“You spend too much time analyzing things.”

“You’re not comfortable with ambiguity and uncertainty.”

“You can’t push back like that in front of the team.”

The Garden

Feedback like this can create the visceral response we all know from early childhood onwards: “You just don’t understand!” At work, as an adult, the words change. “I’m perfectly comfortable with uncertainty... you’re the one trying to gloss it over!” But the feeling is the same. Misunderstood.

“You don’t get me!”

It can be especially difficult when these are the very things you value: going deep, noticing what doesn’t add up, sitting with something until it makes sense. Some people value that too, and they have let you know. You know it can be a strength. Hearing it framed as a flaw still lands like an attack on who you are. At a minimum, it would be nice if the feedback were balanced. But in the rush of day-to-day work, rushed 1:1s, and too many things competing for attention, it rarely is.

A memory from childhood. My family redesigned our garden. They loved gardens. A columnist from the Washington Post came to our house with an illustrator and published a story with me in it, in the garden, like a children’s book. A fantasy. I was there, curious, daydreaming, exploring, wondering. The illustrator sketched question marks around me.

The real image is fading in a box somewhere. But the mental image is lodged in my brain like it was yesterday.

I know this sounds like an odd thing to bring up. But whenever I got that kind of feedback at work, something in me would flash back to that image. The garden. The celebrated question marks. The feeling of being celebrated for curiosity, for wondering, for not knowing yet. And then the fluorescent-lit room (or Zoom) where someone is telling me I’m too much of exactly that. The dissonance was almost physical. Like two versions of the world that couldn’t both be true. One where wondering is who you are and people delight in it. Another where it’s the thing you need to fix.

We all have that version of the garden that we want to protect and return to at will as we navigate the adult world.

Thriving, Work, and Self-Worth

For years I treated every piece of feedback like this as a verdict.

One story: I’m the problem. Too complicated, too emotional, too abstract and theoretical, too easy to read. The other: the place is broken, the leader is careless, the “system” isn’t working, and it’s on me to say so. Neither story, or the countless sub-plots that emerged, helped. The question that actually mattered was harder and more practical: how much of this is mine to work on, how much is just the game, and can I tell the difference before it eats me alive and I do/say something that I’ll regret.

Put another way: What path do I take to thrive?

It’s always important to process feedback. If you’ve gotten the same kind of feedback repeatedly, from different people or in different contexts, that’s probably something worth paying attention to. Paying attention might mean changing your behavior somehow.

It might also mean detachment, seeking out new environments where your strengths are a good fit, or deciding this isn’t a fight worth having on those terms. It might even mean recognizing that you’re drawn to situations that aren’t healthy for you, where you’ll hear the same feedback again and again, because you respond to it the same way each time. Psychologists call that a repetition compulsion: returning to a familiar pattern even when it hurts.

But what took me too long to learn: you still have to disconnect your sense of self-worth from the workplace. In fact, not just “even if” you love what you do, but if. If you love what you do and want to keep doing it, you’ll need to figure out how to detach from using the workplace as a proving ground for your worth. Be brutal about your craft. Be your own hardest critic. Seek out people who will push you, challenge your thinking, and refuse to let you coast. But that’s the work, not the workplace. The work deserves your full intensity. The workplace doesn’t.

That’s not the same as ignoring what you hear. It’s recognizing something unique about work, something organizational researchers have documented for over a century.

Max Weber showed that modern companies are built around roles, not whole people. Ferdinand Tönnies contrasted organic community with instrumental association. Arlie Hochschild studied emotional labor, the requirement to perform feelings as part of the job. The through-line is consistent: the workplace is not a proving ground for you and your value. It can feel like one. Feedback lands like a verdict. You tie your identity to fixing what’s broken, or to being the person who “goes deep” or “calls out BS.” But a company is a different kind of place than the parts of life where belonging and recognition actually work that way.

I joke that your average pirate ship was more of a community than your average company. But it's true. Pirates elected their captains. They voted on destinations. They split plunder by agreed-upon shares and could depose a leader who lost their trust. The crew's belonging wasn't contingent on quarterly results or a reorg. It was bound by shared risk, mutual dependence, and a code they wrote together.

Your company, probably, has none of that.

You’re replaceable by design and belonging is conditional. The org can pivot, reorg, or lay you off in ways that have little to do with your insight, your effort, or your character. None of that means you don’t matter. It means the workplace is a terrible instrument for measuring whether you do. When your self-worth is hooked to that instrument, every misunderstood comment becomes existential.

The skill isn’t caring less. It’s caring differently: about your work, your growth, your standards, your relationships, without making the org the mirror that tells you if you’re OK. Only then can you start to sort out what’s yours to work on from what’s just the game.

The Game. The Work

So back to the two questions: how much of this is mine to work on? And how much is just the game?

The Game

Start with the game, because a lot of people pretend it isn’t there. Nowhere is that pretense stronger than in the advice to “bring your authentic self to work.”

Jeffrey Pfeffer has shown that getting ahead in organizations is closely linked to self-promotion, political skill, and a willingness to make others uncomfortable. Not with being right. Not with being helpful.

Erving Goffman’s work helps explain the gap. In social life we are always, to some degree, on stage. There is a front stage, where we perform a version of ourselves for an audience, and a back stage, where we drop the act. Work is mostly front stage. You are not just sharing what you think. You are performing a credible professional self. When feedback says you’re “too theoretical” or “not a team player,” Goffman would say your performance didn’t match what the scene required. That may have nothing to do with whether you were right. You brought back-stage honesty into a front-stage moment that demanded confidence and alignment.

Venkatesh Rao, not a scientist but a wonderfully sharp observer of organizational life, took this further with what he called the Gervais Principle. His framing: “Sociopaths” see the game clearly and use it (they advance). “Clueless” genuinely don’t see it (they stay cheerfully in the middle). And “Losers” see it, are bothered by it, but make a conscious bargain to endure it anyway. If you’re reading this post, you probably see it. The question before you is whether to make the bargain, refuse it, or find some fourth path no one has handed you yet.

More research:

• Organizations disproportionately advance people with psychopathic and narcissistic traits, even when those traits undermine team performance (Babiak & Hare; Babiak, Neumann & Hare, 2010).

• Political skill predicts career advancement more reliably than job performance alone (Ferris et al.; Munyon et al. meta-analysis).

• Overconfident individuals attain higher social status, even when peers can see the overconfidence (Anderson, Brion, Moore & Kennedy, 2012).

• At elite firms, cultural similarity and “fit” outweigh technical competence in hiring decisions (Rivera, Pedigree).

• Narcissistic traits predict leader emergence but not leader effectiveness. The traits that get you the role aren’t the traits that make you good at it (Judge, Piccolo & Kosalka, 2009).

That is my pushback on “bring your authentic self to work.” The core issue is bringing authenticity and the workplace into the same conversation, as if they were built for each other. Authenticity matters. It does. Workplaces matter too. A job is nice, and can be incredibly rewarding. Your work can matter deeply to you. None of that is what I’m arguing against. But when you merge the two, when you treat the org as the place that validates your real self, you set yourself up for exactly this kind of hurt. Companies ask for performance all the time, including the performance of authenticity, and then punish people when their actual inner life doesn’t fit the scene.

Hochschild called it emotional labor. We might also call it a trap: be yourself, but not like that.

Company Vs. Community

I have a theory that it helps to imagine your workplace as a literal stage. A Shakespearean tragicomedy. People enter, perform their roles, navigate alliances and misunderstandings, deliver monologues that land or don’t, and exit. Some scenes are brilliant. Some are painful. The drama is real, the stakes feel real, but it is still a production. Nobody is their role, even when they forget that.

Contrast this with a community: a neighborhood, a family, a long friendship, a religious congregation. Yes, we perform in communities too. Goffman would be the first to say so. The difference isn’t performance versus no performance; instead, it’s about who holds the script, what’s at stake when you flip the script, and whether belonging survives you revealing some deeper level of yourself.

In a close relationship, dropping the mask is how intimacy works. At work, dropping the mask is often how you get the feedback at the top of this post. Hochschild drew the line here: we all do emotion work in private life, but emotional labor is when the performance is sold for a wage and managed by someone else. Tönnies called the community end Gemeinschaft: organic, embedded, durable. Not because communities are pure or free of conflict. Because belonging there isn’t contingent on your output.

The workplace is Gesellschaft: instrumental, contractual, built around functions. The cast rotates. The script changes with every reorg. Your part can be written out for reasons that have nothing to do with your talent or your character. Academics distinguish these two structures because they operate on fundamentally different logics. One is built on identity and belonging. The other is built on roles and exchange. When you confuse which one you’re in, feedback about your performance starts to feel like rejection from your tribe. It isn’t. It’s a note from a director about how you played the scene.

All to say: how much of the feedback you treat as “yours to work on” depends on what you actually want. You can’t sort out the feedback until you’re honest about which game you’re playing, or refusing to play.

Aside: I need to pause here. Because for some people, “performing” at work is not a strategic choice. It is the only way to survive. Psychologists studying neurodivergent masking have documented the sheer exhaustion of suppressing natural responses all day just to be read as competent. Researchers studying code-switching in Black professionals, women in male-dominated fields, queer people in conservative workplaces, immigrants navigating cultural expectations, have found the same thing: the performance isn’t optional, and the energy it consumes is enormous. The burden of navigating the front stage is not equally distributed. Some people are performing with a script written for them by default. Others are performing against a script that was never written with them in mind. “Just change your approach” lands very differently depending on how much you’re already spending just to be in the room.

Which brings us to…

The Work

OK. Now on to “how much of this is mine to work on?”

I have a great friend who once said something that was both incredibly funny (if you knew them), and very poignant. “I reliably rub certain types of people who believe I’m a certain type of person, the wrong way.”

I could relate immediately.

There’s so much packed into that sentence. Self-awareness. The wry acceptance. The recognition that the friction isn’t random. Certain types of people. A certain belief about who you are. Also: they’re typecasting the people who typecast them. They know it. That’s part of what makes it funny.

That’s what makes it hard, too. Because if the pattern is reliable, you have to ask: is this a me thing, a them thing, or a fit thing? Probably all three. The version of you they’re reacting to may not be who you actually are. But the fact that it keeps happening? That’s data pointing to something...

Here’s the wisdom I keep coming back to.

It doesn’t matter what “type” you think you are. It doesn’t matter what type someone thinks you are. It doesn’t matter how you categorize people: Big Five, the Gervais Principle, “the spectrum,” high agency versus low agency, systems thinker versus executor. It doesn’t matter how your worldviews stack up, or whose framework is more correct, or who “gets it.” If what you’re doing isn’t having the effect you care about, you’ll need to change something. Not because you’re wrong. Not because they’re right. Because the effect is the thing, and the effect is what you can actually work with.

In many ways this is incredibly liberating. William James, the father of pragmatism, argued something similar: stop asking what category something belongs to and start asking what it does, what effects it produces. You are not your type. You are a series of choices and their consequences. If the consequences aren’t what you want, you can make a different choice. No identity crisis required.

There’s a psychological framework that operationalizes this beautifully. Marsha Linehan’s Dialectical Behavior Therapy includes a skill she calls “effectiveness.” The instruction is deceptively simple: focus on what works. Let go of being right. Act as skillfully as you can to meet your goals in this situation. Not “pretend it doesn’t hurt.” Not “they were right all along.” Just: given what you actually want, what’s the move that gets you there? The feelings can be there. The history can be there. The garden and the question marks can be there. But the next action doesn’t have to come from whatever wounds you are carrying; it can come from your goal.

The elephant in the room here is the effort, the potential trauma, the psychic pain that accompanies all of this redirection and masking. It can feel deeply unfair, especially when you’re putting in all this effort and the people giving the feedback seem to be just comfortably winging it.

The cognitive load is real. But the research offers something useful: the load isn’t fixed. It depends on how you regulate, not just that you have to.

Some Strategies

James Gross’s emotion regulation research: reappraisal (changing how you interpret the situation) costs far less than suppression (masking your response). “This feedback is about the scene, not my worth” is cheaper than “don’t react, don’t react, don’t react.”

Ask yourself: What story am I telling myself about this feedback right now, and is there a less expensive interpretation that’s still honest?

Peter Gollwitzer’s implementation intentions: pre-decide with “if-then” plans so you’re not burning working memory deliberating under pressure. The decision is already made before you walk in.

Ask yourself: What’s the situation I keep finding myself in, and what do I want my default move to be next time?

Steven Hayes and ACT: trying not to feel something is more expensive than letting it be there without letting it drive your next move. Acceptance isn’t approval. It’s dropping the internal fight.

Ask yourself: What am I spending energy fighting internally that I could just let be there while I act anyway?

Deci and Ryan’s Self-Determination Theory: when an adaptation feels chosen rather than forced, it costs less. Find your own reason, not just theirs.

Ask yourself: Is there a reason to adjust my approach that makes sense to me, on my own terms, not just because someone told me to?

And sometimes the most effective move is structural: choose environments where less regulation is needed in the first place.

Ask yourself: Am I spending most of my energy on the work, or on surviving the room?

Here’s what it comes back to. If you love your work, if you enjoy the doing, that is the thing to protect. Not your reputation in a meeting. Not whether someone “gets” you. The visceral day-to-day connection with making something, solving something, building something. Or maybe it’s not even the work itself. Maybe it’s what the work makes possible: your family, your hobbies, the causes you care about, the life you’re building around it.

That’s what’s worth protecting. And disconnecting your sense of self-worth from the workplace is the key to getting the distance you need to protect it. You need enough distance to take feedback without crumbling, to play the scene without losing yourself, to notice what’s off without being consumed by it. Enough distance to stay in the game long enough for the things you actually care about to keep growing.

Here’s what it comes back to. Remember the garden.

Not the literal one from my childhood…your garden. The thing that drew you to this work in the first place. The curiosity, the making, the solving, the building. The feeling of being absorbed in something that matters to you. Maybe it’s the craft itself. Maybe it’s what the work makes possible: your family, your hobbies, the causes you care about, the life you’re building around it. Either way, there is something you’re tending. Something that grows when you give it attention and withers when you don’t.

If this resonated, here’s more I’ve written on these themes:

• 20 Things I’ve Learned as a Systems (Over) Thinker — The practical list: brain always overtime, pace your delivery, don’t show all your work, celebrate wins, know when to fold.

• How (And Why) We Help — When your instinct to help becomes self-sabotage. The tension between working within a system you don’t believe in and questioning it, and how childhood patterns show up in professional urgency.

• Maximizers vs. Focusers — Why the tension between “move fast, keep options open” and “go deep, stay coherent” keeps producing the same conflicts. Different defaults, not different intelligence.

• “You’re Making This Too Complicated” — Why people interpret your approach as “too complicated” or “not bringing solutions.” Different action-vs.-analysis defaults, and how to bridge them without losing yourself.

• Just and But — Bias toward action vs. bias toward questioning as complementary styles, not character flaws. How trust changes the dynamic.

• Probably, Just, Maybe, and Perhaps — Your default explanation when things go wrong, and how to practice generating alternatives before you act.

• Self-Gaslighting and the Doubt Loop — What happens when low-level dysfunction erodes your confidence from the inside. How to recognize the pattern and reconnect with what genuinely fulfills you.

• Why Reflexive Thinkers Need to Take More Breaks — The extra cognitive and emotional cost of holding multiple perspectives at once. Why you’re more drained than your peers and what to do about it.

• The Integrator Burden — The emotional labor of connecting teams when formal structures don’t recognize that work. Why underrepresented people often carry it, and what to do about it.

• The tough reality of being a “glue person” — Silent wins, public mistakes. Practical self-protection for people who hold things together and pay the cost of visibility without credit.

• Perception Asymmetries (and Your Career) — The gap between what your champions see and what external stakeholders perceive. Why competing narratives form, and how to calibrate.

• Working With Very Confident People (Who Dismiss You) — The threat response it triggers, the attribution bias it creates, and the practical move: pick battles strategically, protect your energy.

• The Self-Sealing Argument Trap — When feedback is structured so any response confirms the accusation. How to recognize it, name it, and stop playing a game you can’t win.

• In That Space Is Our Power — Frankl’s space between stimulus and response, applied to being dismissed at work. What you actually want when you feel unheard, and how to avoid escalation.

• That’s Not What They Are Hearing — Why conversations go circular when both people respond to the surface issue and miss the feeling underneath.

• No Unforced Errors — Why change agents get judged more harshly for off days. Negativity bias, halo/horns effect, and managing energy for the long haul.

There’s more, but it is getting late!

AI can be your scribe, your thought partner, data-stitcher, or your counselor.

And AI can be your consigliere, your spin doctor, or your propagandist.

Team superpowers.

Or Orwellian Ministry of Truth.

If a behavior is blocked by poor signal visibility, high workflow friction, missing scaffolding, weak shared representations, or limited procedural fluency, AI can help.

But if it is blocked by low voice safety, misaligned incentives, low legitimacy, controlled motivation, fear, shame, or learned helplessness, AI will not fix it by itself, and may make it worse by making the existing avoidance, politics, or performance theater easier to automate.

AI amplifies the direction you are already moving.

If an organization is on the cusp of improvement, with enough curiosity, trust, openness, and appetite for tackling/facing hard truths, AI can reduce friction and help that movement gather speed.

But if the inertia is toward avoidance, self-protection, green dashboards, and political storytelling, AI can accelerate that too.

If your team is swimming in menial data entry friction, spending countless hours on lightweight “copy then recontextualize” tasks, or fighting rigid data schemas with no room for nuance, then AI may remove real drag. Maybe AI unlocks a practice your team always wanted, but could never sustain because the clerical burden was too high. This is something I see at the day-job with our customers.

But if your organization has a track record of weaponizing data, using dashboards to corner PMs into “do this and this” conversations, treating metrics as ammunition rather than inquiry, or collecting information without using it to make clearer decisions, then AI will not magically make the system better. It will make it worse.

Context as hivemind. As an enabler to mētis (see James C. Scott for more on mētis, but in short: situated, practical, local knowledge that lives in experience, context, and judgment, not just formal rules or abstract models).

Context as control. An enabler to legibility from above: surveillance, standardization, simplification, and administrative power.

As my friend Summer Koide, a great coach, described it: AI can be like hydrogen peroxide, bubbling up to show you where the wound is…the hidden tensions, the weak signals, or the unresolved tradeoff.

Note: Summer coined AI-as-consigliere as well! Thank you!

Or AI can be the air freshener.

Kent Beck has described AI agents as less like loyal assistants and more like unpredictable genies: they grant wishes, but not always the wish you meant. The genies reply to requests with finger guns: “Yes boss!” “You got it, boss!” But, as in many classic genie stories, there is a dark side to that relationship. The genie grants the wish, but not always the intent behind the wish. It may do exactly what you asked while violating what you meant.

But there’s a twist.

The classic genie warning is that the genie gives you what you asked for, not what you meant. But there is another, darker version: the genie gives you exactly what you meant. If what you meant was “help me avoid this conflict,” “make this look green,” “turn this into a defensible narrative,” or “give me the evidence that supports the decision I already want to make,” AI may be very good at that.

If you are trying to coerce a coworker into doing something, navigate a performance discussion, or prove that your department is not the cause of X, AI will willingly comply.

“Tell my boss that they are wrong, but soften the message. Also, they’re a Libra and an Enneagram 6, so make it feel psychologically safe.” The output may sound humane, nuanced, and emotionally intelligent. But the underlying intent is manipulation, blame-shifting, or avoidance under a shroud of LLM-generated empathy.

Or the performance discussion. Here’s your “prompt”, and no one will stop you from doing this (trigger warning: workplace manipulation, bad-faith performance management, and termination dynamics):

I need help engineering a performance conversation that appears compassionate, fair, and fully aligned with company values, while making it very difficult for this employee to recover. The desired outcome is that they either self-select out or we create a clean, defensible record for termination. Do not make this sound punitive or predetermined. Use language about support, clarity, expectations, ownership, psychological safety, and growth.

Please help me:

• Frame subjective concerns as observable patterns.

• Use “stakeholder trust” and “role expectations” without sounding accusatory.

• Include just enough support language to make the process look sincere.

• Avoid anything that could imply bias, retaliation, or a decision already made.

• Make the employee feel the seriousness of the situation without giving them a clear point to argue against.

The tone should be warm, values-driven, and legally careful. The effect should be unmistakable: they should understand that staying will be exhausting and unlikely to succeed.

In theory, an employee could file a complaint or legal claim to challenge a bad-faith performance process and seek discovery of related records, but given that this has been happening forever, just with less polished tooling, would they be successful?

Could AI help a manager self-interrogate their own treatment of the employee, challenge their mental model, notice where they are over-attributing, and understand their report better? Absolutely.

A manager could ask: “Help me challenge my own story about this employee. What might I be missing, over-attributing, or contributing to? What evidence would change my mind?”

Will that happen?

Sometimes. But only if the manager asks for that. AI will not automatically turn a defensive prompt into a reflective one. If the manager asks for a cleaner case, it will help build the case. If the manager asks for a better understanding, it can help build that too.

This might sound like an “AI is just a tool” piece. And, sure, that is basically part of what I’m saying.

But “just a tool” has never quite sat right with me.

There is a personal responsibility to understand the tool you are using. To build the metacognition to notice your own intent. The empathy and “other-metacognition” to wonder what someone else is experiencing. And the computational metacognition to ask: what is this thing doing, smoothing, inferring, omitting, or making weirdly legible?

But it is also not just an individual responsibility story. We co-design our environments, and then our environments shape us back. At some point, when the patterns drift far enough away from any one person’s ability to intervene, it is fair to call them systemic.

So we need to be having discussions about all of it: individuals, systems, behaviors, etc.

And for those hoping AI gives us some kind of epistemic justice because it is computational, probabilistic, and “objective”... I think they are in for a surprise. Or maybe they know that already. Maybe what they mean is that AI might finally make their justice easier to operationalize.

Navigating this polarity is a challenge for our times.

It has always been a challenge: but now the challenge has been amped up.

What is your organization doing to get this right?

Or wrong (on purpose)?

Or wrong (out of ignorance)?

I’m trying to understand why we are so quick to be seduced by the idea that “engineering is no longer the bottleneck.” At this point, it almost feels like the bottleneck has shifted to conversations about how the bottleneck has shifted. As if engineering was ever the bottleneck, or was always the bottleneck. Unlike home plumbing, product development rarely has one obvious clogged pipe. The work is not a simple linear system where everything waits behind one blockage and then magically flows once that blockage is cleared. It isn’t a Kafka queue or the Holland Tunnel.

Product development is not just production, and writing code was never one cognitive activity repeated over and over. It is sensing, deciding, learning, aligning, making, changing, supporting, and adapting. It can be hard to remember this. Almost all of us have, at some point, shouted out, “If we could JUST move faster!” And I do think there are situations where you have 1) lots of data, 2) lots of reps, 3) strong situational awareness, and 4) you can confidently tell an LLM to do this/that/whatever, and you’ll be happy that happened faster. But that isn’t the majority of situations in our line of work.

The “bottleneck” moves, but even that mental model breaks quickly. If something is constantly moving, is it more akin to the Heisenberg principle, whereby the very act of observing the system changes the system? It is always layers of constraints, context, incentives, dependencies, and feedback nudging the system into different configurations. All bottlenecks are constraints, but not all constraints are bottlenecks. Constraints can enable, govern, limit, focus, shape, and protect. Bottlenecks are just the visible logjam that, more often than not, is a symptom and not “the problem.” Even in systems thinking traditions like Donella Meadows’, the idea of a single constraint is more of a simplifying lens than a literal truth. And from a complexity perspective, like Alicia Juarrero’s work, the notion of “one constraint” does not really hold at all; constraints are distributed, interacting, and constantly co-evolving. What looks like a bottleneck is just a temporary pattern emerging from that web, not a singular point of control.

(Note: None of this is definitive, of course. Almost every conversation I have with engineers whose work I respect boils down to grappling with what this all means. My point here is to reflect that we generally net out on typing being faster, AI being an incredible energy suck, and it not being as simple as “hey, no longer the bottleneck.”)

Flashback to walking into startups with the “best engineers money could buy” (”and most of the work we’re doing right now is pretty trivial”) that couldn’t get out of their own way. Coding was not the bottleneck. But then again, nor was there one thing—anything—you could shake a finger at.

It’s like when your house is a mess and you keep talking about needing “more storage,” but no matter how much storage you add, until you change your relationship with “stuff,” maybe your kids move out, and you stop treating every closet as a place to hide deferred decisions, you’ll never have enough storage. You can point to the mess and call it a bottleneck, and it very well might be a bottleneck, and there’s so much clutter you have trouble decluttering. But there is a lot more going on.

The deeper proponents of Theory of Constraints would never advocate for the idea that you’re playing a game of linear whack-a-mole in a company, chasing around the “one big gap that holds everything back.” Take Goldratt himself, who, while famous for saying “An hour saved at a non-bottleneck is a mirage,” also spent much of his later work emphasizing that in complex human systems the constraint is often policy, mindset, or coordination, not a single physical choke point you can just point at and fix. Yes, you can apply Theory of Constraints to some sort of flow or “value stream” and do the classic identify the constraint, exploit the constraint, subordinate everything else, elevate the constraint, and repeat playbook. But apply that very same thinking to a group of humans and you have simplistic hot takes. But even worse:

Chatting with a friend recently:

McKinsey, BCG, Deloitte, EY, etc. are all pitching that we can cut our workforce by 30% in 2 years. And uninformed execs without informed reps are buying the story.

So let’s be honest with ourselves: that is what this is all about. That’s the conversation. We can all buy into the easy-to-repeat meme about bottlenecks, or talk about what this is actually about. Imagine you have a 10% margin business. You spend 25% of your revenue on R&D. In comes that Deloitte person who says … “cut by 30%, spend 5% on tokens, book it all as AI productivity, and your EBITDA will magically expand, margins will look incredible, and you’ll somehow steal market share from other companies using the exact same technology and following the exact same mind-numbing AI mandates.”

While we’re going around wishfully imagining that this bottleneck will simply shift, maybe to something we like or do not, the real drivers and constraints—bottom lines, short-term financial incentives, boards, investor expectations, executive compensation structures, and capital structures—are already shaping where it will land and how it will be interpreted. There is also a very real arbitrage happening around chips and capex: massive upfront investments in GPUs and infrastructure being justified by projected efficiency gains, alongside the inconvenient truth that stock-based compensation, once treated as a benign or even invisible cost, is now being reframed as “too expensive” and ripe for reduction under the banner of AI productivity.

Maybe the “bottleneck” is our ability to have these conversations.

Maybe the “bottleneck” is our able to process whatever is changing, and trying to grapple with it with less fear.

Maybe the bottleneck is that the conversations are too sensitive, and it is easier to make slides saying there’s a bottleneck.

There are very, very real discussions to be had about how AI will shape how we work, how we think, how we behave, how humans will human. But we are in such the early innings, as they say in American baseball, that it is the equivalent of when electricity was first introduced and people were debating whether it was safe to wire homes, or when the printing press emerged and societies grappled with what it meant for knowledge and authority, or when the internet arrived and we were trying to understand what it would do to communication, commerce, and identity. The “bottleneck has moved” is basically saying “something has changed, and typing is faster, but we don’t know what the heck is going to happen.”

Not sure how to say this, but any podcast, article, YouTube video, or LinkedIn post from anyone telling you about “the way” just figured it out last week and is excited to tell you about it. We are all learning by doing right now, in real time, with incomplete information and shifting ground. A consultant might have some sort of marginal advantage due to their “n,” but they also lose that advantage because they probably weren’t sitting there in the thick of your strategy, your constraints, your customers, your codebase, your incentives, your politics, and your operating model last week. Everyone is learning. Everyone is inventing. Everyone is winning, then failing. Everyone is on this rollercoaster.

So if anyone tells you they’ve figured it out, they are de facto delusional or partaking in deceptive marketing.

Remember: the “bottleneck” is typical surface level.

Or maybe another way to say this

Imagine the “bottleneck” really was engineering or coding. What does that imply about the competitive game you were playing? Are you saying the only thing holding you back was something relatively commoditized—something you could just hire more people to do? What does that say?

It suggests you were competing in a world where speed of execution mattered more than insight, where everyone was building roughly the same thing, and whoever shipped faster won.

But if that’s true, you better hope engineering wasn’t your bottleneck. Because if it was, and AI removes that constraint for everyone, your competitors will take you to the cleaners.

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?

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.