We’ve all probably experienced something like this. At a company meeting, a leader makes statements like “We put customers first” and “Our people are our greatest asset.”

Some people in the audience immediately start comparing those statements with the company’s actual incentives, decisions, and everyday behaviors. They’re connecting the dots across different contexts. They notice where things don’t add up and perhaps feel increasingly uncomfortable with the contradictions.

Other people don’t seem particularly bothered. They may hear the same statements and process them within the context of an aspirational mission. Later, when discussing budgets, incentives, or difficult business decisions, they switch to a different frame without necessarily experiencing a contradiction.

Or they may assume that corporate statements like these are inherently aspirational, performative, or political. They may have long ago concluded that what leaders say and what organizations do rarely line up perfectly. Or they may recognize these statements as part of a well-worn organizational game, understanding their social and political function without expecting them to describe reality.

The difference may not be whether people notice the contradictions, but what those contradictions mean to them, how uncomfortable they make them, and whether they feel compelled to do something about them.

There is SO much that can be going on here, including the huge influence of the context and environment we’re in. But I think exploring different childhood experiences can be a useful way to appreciate just how many paths can lead to similar behaviors, and how different the experiences beneath those behaviors might be.

Big caveat. This is only one of many important frames.

Imagine growing up in an environment where what adults said and what they did frequently didn’t add up. A parent insists everything is fine, but their behavior suggests otherwise. Rules change without warning. You’re told you’re overreacting or imagining things when you point out inconsistencies. You learn to be hypervigilant, constantly scanning for signs that something isn’t right, while becoming fiercely protective of your own perceptions, especially when others try to dismiss or invalidate them.

Compare that with growing up in a family or community where fairness and intellectual honesty are deeply valued. Questioning authority and calling out hypocrisy are actively encouraged. These very different childhood experiences could both produce an adult who is highly sensitive to incoherence and feels compelled to call it out.

Or you could have experienced both, perhaps even at the same time. A family that encouraged questioning authority in the wider world but discouraged it at home. A parent who championed fairness but reacted defensively when their own behavior was questioned. We don’t fit into neat categories, and neither do the experiences that shape us.

Now consider a different response to incoherence. A child might grow up in an environment where questioning contradictions only makes things worse. Authority can’t be challenged, and the safest approach is to accept inconsistencies and work around them.

On the other hand, a child could grow up around adults who model pragmatism and diplomacy. They learn to live with competing priorities without needing to resolve every contradiction. Again, very different childhood experiences could produce adults who are relatively comfortable navigating incoherence without feeling compelled to challenge it.

We don’t just develop different relationships with incoherence. We also develop stories about the people who respond to incoherence differently than we do, and sometimes turn them into our antagonists.

Let’s get into the voices in our heads…

People are always trying to deflect responsibility. They overcomplicate everything. They question every decision, pick apart every little detail, and find a hundred reasons why something won’t work. Nothing is ever good enough. They want everything to be perfect before they’ll lift a finger. At some point, you have to stop talking, take ownership, and actually deliver something.

Or…

People in power just want you to shut up and deliver. They don’t want anyone asking the hard questions or pointing out that their grand plans don’t add up. They make promises they know they can’t keep, ignore the people doing the actual work, and then leave everyone else to pick up the pieces. And when things fall apart, somehow it’s never their fault. They don’t care whether anything actually works, as long as they look good, collect their bonuses, and move on to the next big thing.

Who are these “people” we’re talking about? What roles do they play in the stories we tell ourselves about our experiences at work? I think with both of these, we very quickly get to raw feelings of hurt, betrayal, broken trust, and powerlessness. There’s a sense of being dismissed or taken advantage of.

I think the important thing for anyone collaborating in the workplace is recognizing how much can be going on beneath the surface. Coherence checking, apparent compartmentalization, asking lots of questions, or just jumping in and getting things done can all have very different origins. What looks like resistance might be an attempt to protect one’s sense of reality. What looks like impatience might reflect a learned need to maintain momentum. What looks like indifference might be a sophisticated understanding of how organizations work.

We can get into trouble when we assume we know what’s driving someone else’s behavior, especially when we start turning those assumptions into stories about their character, intentions, or competence.

A constraint can be “enabling” and “limiting” at the same time.

For example, I’m working with a home contractor who takes his time. It is frustrating because I really need this job done. But there’s a side benefit. On a couple of occasions, being forced to look at the plans for a bit, consider the cost, and walk impatiently around the house thinking about how we live has inspired objectively better decisions about what we want (and need). The job will get done more slowly, but it will (hopefully) be a better fit. I have a suspicion that the contractor knows this. This is a mind trick they use to improve project outcomes.

One of the challenges in product development right now is that “the bottleneck has moved” is far too simplistic. The limiting constraint may have moved, but now you have ALSO removed an enabling constraint. The bottleneck was both a bottleneck AND an enabling constraint. The thing that was annoying, challenging, glacial, and vibe-crushing was also the thing that forced us to pay attention (even if we hated it).

The “dumb” project ROI pro forma, while putting way too much emphasis on shaky estimates and far too little emphasis on progressive risk reduction, at least forced us to wait a couple of days or weeks for a better alternative to emerge.

The pairing session—while a major drag to do remotely, and now “easily” replaceable by pairing with an LLM—was a critical way to extend the hivemind of the team.

The six rounds of revision of a doc, each person adding their perspective and taking time to get their words right, took a whole afternoon and meant that the team had a couple of days to reflect before pressing send.

So the question isn’t as simple as “less bad stuff, more good stuff.” It is more “the good stuff is actually good, but we’re also skipping a lot of good stuff because woven into a lot of drudgery and friction were a lot of positive things.”

Here’s an example from my day-to-day work. It is great to walk out of a customer call with a transcript and watch, an hour later, as a bunch of things get deployed. That’s magic! No tickets. No mind-numbing “definition of done” conversations. No “demo.” None of that.

But intermingled in all that stuff I’d rather do without was a lot of positive friction.

“Is this worth it?”

“Is that actually what they meant?”

“Is this design workable in the long run?”

“Wait, are you sure you didn’t mean _________?”

“Wait, this isn’t working how I thought it would work.”

All of that friction was an opportunity to make better decisions, even if it felt like it was slowing us down. We have to be very INTENTIONAL about making space for this to happen.

The trouble is that as people turn inwards into their own little AI-assisted universe, their own “team” of agents, and their own workflows, there is even LESS patience. The immediate gratification of pressing a button and seeing code come out the other end is way too strong. It is too easy to work in single-player mode. And multiplayer mode seems archaic in comparison. Almost quaint. A reminder of all that messy friction.

Everyone, including your customers, loves a good game.

Even if you’re not in consulting or don’t offer a service, you might find some of this content interesting. It touches on what happens when you treat your whole company as a product.

Context

I work on a small team (Clonal) nested within a larger consulting firm.

We’re like a mid-market Palantir, without the…um…yeah. Think operational intelligence, digital twins, and combining disparate data sources for tangible (often physical/digital) outcomes. FinOps, field service operations and faster billing, EV charging network uptime, supply chain visibility, predictive maintenance, cold chain integrity, production quality, etc.

We’re affordable (low-to-mid seven figures), which is a steal considering the outcomes we can drive quickly. We nerd out about driving operational outcomes using our “platform” (think toolchest) mixed with a high-touch engagement model. Our goal is to drive tangible outcomes in 3–6 months. The industry term for this is “forward-deployed.”

What I love about the gig is that I’ve always imagined the “company as a product.” The engagement design is as much the product as “the product,” and in this age of AI, companies want the outcome. I wanted to share a post I wrote for my team about game design and consulting. If you’ve ever been interested in forward-deployed product motions and mixing services, platforms, and ways of working, this might be interesting.

If you have problems we could help solve, ping me on LinkedIn.

A Good Game

In consulting, custom development, etc., part of the “product” is the customer experience of the engagement itself. I like to think of designing this experience as a form of cooperative game design. To review, what makes a good game?

1. Clear, attainable goals that players understand

2. Maintain a balance of difficulty, ensuring challenges aren’t overly easy or excessively hard.

3. Timely feedback and rewards boosting player motivation.

4. Engaging gameplay mechanics captivate players and sustain their interest.

5. Signs of small victories or incremental progress can motivate them. This could be through progress bars, intermediate rankings, or minor accomplishments.

6. Meaningful choices that impact the outcome, fostering player agency.

7. Immerse players in a compelling environment or narrative.

8. Calibrate progression and learning curves, promoting mastery over time.

9. Variety in challenges, environments, and mechanics keeps players engaged.

10. Social interactions, such as cooperative or competitive play, enhance the gaming experience.

11. Accessibility in terms of difficulty, controls, and inclusivity broadens the game’s appeal.

12. High replayability ensures the game remains fresh and exciting for repeated plays.

Consulting presents some particularly interesting game-design challenges. You’re not designing for one unified team, but for groups of people with different roles, incentives, and ways of working. Money, expectations, pride, and clashes in professional culture all shape the experience. And create a whole set of fun game design puzzles to solve.

One-Sided Games and Wicked Loops

There are many ways to design the game that suit only one party.

For example, internally we might want a super loose, process-light, flexible, “get answers whenever,” “focus on outcomes,” iterative approach. Part of that is because we think it works. Part of that is because it is more fun and less of a headache. Part of that is because we’re continuously evolving the platform. So the flexibility helps. But there’s a potential problem. This approach may or may not feel right for the customer, even if rationally they’ve bought into the idea.

Turn that example around.

Imagine a client that wants to know exactly when and how everything will be delivered, wants to know exactly the outcomes we’ll generate, and wants an answer any time their manager asks “So where is this thing at?” They are also absolutely sure they know exactly how every interface should look, and want to at least try those things.

Those are perfectly rational needs. Who wouldn’t want those things? But we know that premature convergence and glossing over uncertainty reduce the chance that we’ll produce stellar outcomes. Additionally, that process overhead is also a pain in the ass and can be cognitively draining (for us). If we’re honest with ourselves, the rigor makes us nervous and worried. We translate that into rational, logical, adult arguments about merit, skills, “types” of people, etc.—we rationalize why it feels hard—but the more we rationalize, the more our empathy drifts from real customer-centricity.

Now imagine both parties being snobbish and dragging their feet on their respective approaches under the premise of what’s “right” or “professional.” You can see where that will go very quickly. It triggers all sorts of bad things. Suddenly both sides are persuading themselves that their needs are somehow ordained, and resistance is unreasonable.

In general, it is a lot easier to retain trust and goodwill than to attempt to rebuild it when it goes south. In studies, teams with low trust tend to fall back on conflicts over personality, while teams with high trust find it easier to shift the focus to task conflict. Once a client loses faith in our ability to deliver and be transparent—for whatever reason, even when it is “totally their fault”—that will filter how they perceive everything thereafter. Once we lose faith in our client to provide feedback with good intentions, to understand real-world development constraints, or to stay true to the SOW in principle while remaining flexible on details that might slip, that will filter how we perceive their feedback.

A wicked cycle.

Game Design (Engagement Design)

Imagine two wedding planners. In wedding planning you need to force or catalyze all sorts of hard decisions, in sequence, on a deadline, with a TON at stake.

Wedding planner A brings the couple into the process, but anchors it in clear milestones everyone understands, so participation doesn’t become chaos. They make choices explicit, in terms the couple understands. They know budget decisions can sting, so they help the couple face the tradeoffs with care—showing options, explaining what each choice makes possible, and protecting what matters most. They make progress visible in ways that feel inspiring. They meet the couple at their favorite coffee spot. And before the hundreds of little decisions begin, they help the couple name their North Star: what they want the day to feel like and what matters most. That shared compass makes all those spot decisions easier to settle.

Back at HQ, though, WPA is all about getting shit done, dotting every i, and crossing every t. They just don’t expose that machinery to the couple (client).

Wedding planner B is just as competent, but comes from a different philosophy: expose the planner’s own process to the customer. They share the full project plan up front—numbered milestones, vendor dependencies, deposit schedules, and budget line items—and walk the couple through each step in the order the planner needs to work. Decisions arrive when the process calls for them, framed in the planner’s terms: lead times, cost per head, what other couples typically choose. Budget conversations are factual and direct. Progress is tracked as tasks completed and milestones checked off. Nothing is hidden, and on paper it is efficient and professional. But the couple is essentially looking at the planner’s workflow, not at the day they’re trying to create.

Those are objectively different experiences for the customer. You can imagine all sorts of ways that the relationship with WPB will go south. You can also imagine couples that might prefer WPB. But there is something critical here to understand. Wedding planner B WILL have an easier job in terms of context switching between their external approach and internal approach. They are designing the engagement around how they operate internally!

This example surfaces a couple of key points:

1. In an ideal world, the internal and external are the same thing. That’s everyone’s dream.

2. But it isn’t necessarily best for the client. And it isn’t necessarily the thing most likely to produce the best overall outcomes. You’re forcing your internal approach on the customer.

3. You can “design” the game, and the overall offering, to align these goals in ways that are mutually beneficial.

Both planners are designing the engagement, whether they recognize it or not. Some choices are explicit and intentional; others are implicit, baked into the way the work unfolds. Either way, those choices shape the customer’s experience.

Pivotal Labs did an incredible job here.

They put an offering out in the world that represented what they thought was right for the customer AND what the customer thought was right for the customer—and they were loud and proud about it. Clients weren’t just buying a team of “Pivots” to build software; they were buying an embedded way of working. Pivots paired with the client’s own product, design, and engineering people, shipped the product together, and transferred the practices so the client team could carry on without them. Pivotal called itself a teaching company. Their internal approach was the external game, and the learning was part of the value, not a byproduct of shipping.

Pivotal made its way of working part of the product the client was choosing.

To all my Pivotal friends…you’re a perpetual source of inspiration!

Self-Serving Assumptions

The trap in consulting is assuming that because we believe our way of working is right, the customer will experience it as right for them. But it doesn’t always work that way.

“We Know What’s Best For You”

The first trap is assuming that our preferred way of working is inherently best for the customer. We may favor loose scope, light process, and flexibility because those support the work, suit our team, or reduce overhead. Those may be sound choices. But the customer may experience them as ambiguity, poor visibility, or a lack of control. Calling the approach agile or outcome-focused does not, by itself, make it feel aligned. We may be asking the customer to play our game and describing that as best practice.

“The Customer Is Always Right”

The second trap is treating “the customer is always right” as a mandate to accommodate every request. We may agree to firm dates, precise outcome promises, or specific design directions even when uncertainty, dependencies, or technical realities make them risky. That can preserve goodwill in the moment while hiding tradeoffs, encouraging premature convergence, or weakening the result. We may ask the delivery team to play a game we believe is unwinnable and describe compliance as customer-centered.

Stakeholder reassurance can be a legitimate need in its own right. The problem is disguising it as a requirement for the product outcome, which makes it harder for the team to discuss the actual tradeoff.

“Follow the Money”

The third trap is letting incentives implicitly set the rules of the game, without deeply thinking those incentives through. It shows up in two ways.

The first is not acknowledging incentives at all. Every engagement has them, on both sides. The firm needs margin, utilization, and renewals. The client stakeholder needs to show progress, manage up, and protect their own credibility. But naming them feels awkward or cynical. So everyone talks as if the work were driven purely by the outcome. The incentives don’t go away; they just operate underground.

The second is missing the perverse incentives. A consulting firm may have more incentive to

1. extend the engagement than to make itself unnecessary

2. say yes to scope changes than to push back on what won’t serve the outcome,

3. produce visible activity than progress the client can feel, or

4. protect the renewal than to deliver bad news early.

A client stakeholder may have more incentive to look in control to their boss than to get the best outcome, or to push risk onto the vendor than to share the uncertainty. Because no one is looking for them, these show up as reasonable-sounding decisions.

None of this requires bad actors; it’s just what the structure rewards. Left unexamined, it makes the first two traps stickier: our methods and margins make “we know what’s best” convenient, while billing and renewals make “the customer is always right” pay. We may end up playing the game the contract rewards and describing it as serving the client.

The Work

This is quintessential cooperative game design: the engagement is a game both parties have to play together, and its design shapes whether they can succeed together. The same components that make a good game apply:

• Clear, attainable goals: A shared North Star that captures what the outcome should feel like and what matters most. The hundreds of spot decisions have something to anchor to.

• A winnable level of difficulty: Hard enough to be worth playing, achievable enough that both sides believe they can win. Overpromising certainty makes the game unwinnable, while ambiguity with no visible structure makes it feel impossible to play.

• Meaningful choices: Tradeoffs made explicit, in the client’s terms, so they have real agency instead of rubber-stamping our process.

• Timely feedback and visible progress: Small wins the client can feel, not just milestones checked off.

• A compelling narrative: Progress framed around the outcome they’re trying to create, not the machinery of our workflow.

• Mastery over time: As with Pivotal, learning is part of the design; both sides should get better at playing together.

• Shared goals, different incentives: The client and consultant bring distinct needs, constraints, and incentives, so the rules have to make room for both and be checked for perverse ones.

• Trust as the social layer: Honest conversations and goodwill keep the play cooperative. Once trust breaks, every move gets read as adversarial.

The Score

We’ve probably all heard the stories from space and aerospace: a program defines a set of stable capabilities, and the team “spirals” toward them through experimentation, testing, and iteration. Before Apollo could land on the Moon, Project Gemini had to prove that astronauts could survive two weeks in space, work outside the capsule, and rendezvous and dock with another spacecraft in orbit. Then Apollo built up mission by mission: crewed flight in Earth orbit, a trip around the Moon, a lunar module test, a full dress rehearsal, and finally the landing. SpaceX did something similar with reusable rockets, moving from low-altitude test hops to controlled ocean descents to landing boosters on land and on drone ships.

These are storied efforts. But there is a critical game design component to them. Think about how well these stories “sit.” You can just feel the risk reduction involved. You can just feel these capabilities coming to life. You can just FEEL the outcomes. And they typically involve something super tangible that can be tested and measured. We’re not talking stupid story points here, or random “epics.” We’re talking milestones that mean something, and that give meaning to a lot of work. This is an example of a good game and a good scorekeeping method.

OK. Back to reality. Now imagine a Gantt chart with arbitrary phases that don’t really mean anything. No risk reduction. All show. The “% complete” gives you no sense of progress. In fact, it increases the tension. “Oh, great, we are N% closer to figuring out if this thing will work. Will it?”

Side by side:

But there is a critical angle to this. The space teams SHIPPED (with some obvious setbacks, including the Apollo 1 fire, the near-disaster of Apollo 13, and plenty of SpaceX boosters that exploded before one finally landed). There’s nothing worse than a product team that sells its customer on being outcome-centric and iterative, then takes forever to iterate and fails to measure outcomes (or gives itself gimmes all the time and phones it in). In other words, you need to play your side of the game if you’re asking a customer to step up.

A lot of designing good games is about retaining trust and credibility. A while back, I shared a thread about trust that drew on some definitions from Larry Maccherone. Trust is directly related to credibility, reliability, and empathy, and inversely related to apparent self-interest.

Individuals should:

• Know what they are talking about and be able to admit when they aren’t sure or don’t know.

• Do what they say, and do it quickly. If they can’t do it quickly, they should be able to give a good understanding of when they will be able to start and stop.

• Care about the interests, needs, and desires of other people.

• Minimize their self-interests. It could be that your self-interests overlap with the interests of other people, so emphasize the interests of others. There is a line between interests or desires and needs, so individuals should not risk their long-term health and safety for others (outside of certain counterexamples).

Trust is critical in cooperative games and touches each of our dimensions. Let’s ground these in our prior discussions to consider what teams actively control across the “good game” dimensions.

So it is not just “the score” and agreeing to the “score.” There are also a lot of emotions and intangibles at play that you need to consider.

Recommendations and Principles

1. Don’t inflict ways of working the customer doesn’t want or can’t support. Some ways of working are unwanted outright. Others are aspirational: the client says they want to be iterative, outcome-focused, or “more agile,” but nothing in their environment supports it. Their calendars are full, their governance expects fixed plans, and their bosses still ask for dates. If we design the game around the aspiration, we set them up to fail at it, and we both feel it. Design for the team they are today, with a path toward the team they want to become.

2. If you create a good score, follow through and hold yourselves accountable. A meaningful scorekeeping method cuts both ways. Capability milestones expose our progress just as clearly as the client’s. If we ask for an outcome-centric game, we have to actually iterate quickly, measure honestly, and say so when a milestone slips or a test fails. No gimmes. The fastest way to discredit a good game is to stop playing it the moment it makes us look bad.

3. Be honest with yourselves about incentives, including the perverse ones. Name what the firm needs (margin, utilization, renewals) and what the client stakeholder needs (to show progress, to manage up). Seek to align those incentives with the outcome through pricing, milestones, and how success is defined. But don’t pretend they’re aligned when they aren’t. Saying the quiet part out loud, at least internally, keeps it from quietly steering decisions.

4. Find people whose full-time job is the work. Social reinforcement (pairing, shared rituals, celebrating small wins) is powerful, but hard to sustain when the engagement is one of ten things on the client’s plate. A part-time stakeholder can’t carry their side of a cooperative game. Push for people on both sides who are fully vested in the work together, and treat their availability as a real constraint in the design.

5. Don’t assume expertise the customer doesn’t have. Don’t expect customers to be skilled product developers, or domain experts to be experts in product development, unless they are. It’s tempting to assume they can write good requirements, interpret prototypes, or give feedback the way a product team would, because that makes our job easier. When the assumption is wrong, the game becomes unwinnable for them. Check the assumption, then design the support they need: examples, worked options, structured feedback, or coaching.

6. Over-promise, over-deliver, and think hard about the promise. I don’t mean promise the moon. I mean truly think through your promises to make sure they represent a good game: meaningful, ambitious, and credible. Overdo the thinking on what you’re committing to and why. Hedging for hedging’s sake creates a vague game no one can win or lose, which is its own way of losing trust.

7. Go design the game, and test it with them. Don’t just default to your standard engagement model. Prototype a few versions of the game: a milestone and RAG version, a North Star framework, a graded capability scorecard, whatever fits. Walk the client through them and see which ones they’d actually play, and which ones answer “So where is this thing at?” for their boss. Treat the engagement design like any other product decision.

8. They’re paying us to be the experts, and they’ll often take our word for it. That’s a responsibility, not just a compliment. Clients will often accept our recommended routines and games without pushback, even when they can’t truly deliver on their side. Silence is not alignment. Probe for what they can actually commit to, and adjust before the gap shows up as missed reviews and stalled decisions.

9. Consider what it feels like to work with us. Back to basics. Every cadence, artifact, status update, and meeting is part of the customer experience. Periodically step back and ask how the engagement feels from their side. Avoid dogma: no method is so right that it justifies a bad experience for the people who have to live inside it.

10. Stop the self-owns. Trust is easier to retain than to rebuild. Most trust damage is self-inflicted: missed follow-ups, surprises that could have been flagged earlier, jargon, defensiveness, small promises that slip. Each one is minor, but they compound, and once trust goes south, everything gets filtered through it. Protecting trust is mostly about not giving it away.

“Software factory” is a kind of identity defense (and branding). And there’s a historical precedent here.

I’ve been pondering the almost Dionysian fervor surrounding all these new “factories” people are building. The sheer exhilaration, obsessive energy, and unmistakable pride people seem to take in building systems that build things.

Imagine your whole profession of “building” has shifted. Things that underpinned your identity are no longer considered valuable. Historically, your expertise gave you considerable influence over what could be built, how it would be built, how long it would take, and what trade-offs were necessary. Suddenly, the act of producing software became dramatically cheaper. Your traditional source of scarcity (and therefore power) is threatened.

What do you do?

You move up a level. You become the architect of the software factory. You control the orchestration, infrastructure, standards, quality gates, security, evaluation, and deployment systems. You may no longer have a monopoly on producing software, but you can establish authority over the means of production.

When technology automates work central to your professional identity, one attractive response is to become the person who designs, operates, and governs the automation. That can be productive adaptation, genuine craftsmanship, identity preservation, and a defense of professional authority. All at once.

This is not new. As industrialization transformed traditional crafts, some skilled craftspeople shifted their attention from making things to designing the systems that made things. For example:

• Eli Terry (clockmaker → clockmaking machinery)

• Josiah Wedgwood (potter → factory design and production systems)

• Henry Maudslay (metalworker → precision machine tools)

• Joseph-Marie Jacquard (weaving → programmable looms)

• Frederick Winslow Taylor (machinist → scientific management)

You shift your focus to “building” a factory. It is like CI/CD, infrastructure as code, automated testing, deployment pipelines, and developer platforms. But now for AI agents. You get to preserve the identity of being a builder.

Let’s go back to 2012. What were we debating then?

Netflix’s Adrian Cockcroft described an organization with little need for operations staff, because the cloud let them automate so much of the old work. John Allspaw at Etsy called “NoOps” “the dumbest marketing term ever coined in my field.” Julian Dunn wrote a post titled “Chef, devops, and the death of system administration,” and argued that “pure systems administration is eventually going to die out as a profession.” Jez Humble argued there’s no such thing as a “devops team,” and then conceded that somebody has to build the platform developers use to self-serve. Around the same time, James Bach and Michael Bolton drew a line between “testing” and “checking,” so that automating the checks wouldn’t be mistaken for automating the tester.

Same dynamics.

In an idealized version of product development, I’ve always imagined the cross-functional team taking precedence. It has an identity of its own. Makers. Value generators. People with different skills, perspectives, and experiences coming together to figure out what is worth building, how to build it, and how to learn along the way. Inclusive building. The team is the unit of value creation, not any particular function or discipline. The team collectively owns the problem, the discovery, the decisions, and the outcomes.

What I think is happening right now with the “software factory” is that the narrative is emerging primarily from within the engineering community, partly for the psychological and identity-related reasons I’ve been discussing.

There’s also a practical reason.

Some of the earliest and most measurable productivity gains from AI have been in software engineering. So it’s understandable that engineers are among the first to experience both the extraordinary possibilities and the threats to their established expertise. And it’s understandable that they’re imagining the future through the lens of their own craft: orchestration, pipelines, infrastructure, automated testing, and factories.

It’s perfectly logical, for all the reasons mentioned, that we’d gravitate toward the software factory metaphor. But it’s an open question whether the emerging factory model is actually a good fit for the domain of end-to-end product development, where discovery, design, building, experimentation, and learning are deeply intertwined.

And it’s not just software engineering. Everyone seems to be building a “factory” right now, whether they call it a software factory, a product management system, a GTM factory, a content engine, or something else.

There’s a much broader movement underway. As AI threatens the skills, expertise, and activities that underpin our professional identities, we’re embracing the technology and trying to position ourselves one layer up. Instead of doing the work, we design, orchestrate, and govern the systems that do the work.

It’s a way to preserve our identities, demonstrate our continued relevance, and potentially establish a new source of organizational power.

What isn’t happening nearly as much as it should is a serious consideration of the cross-functional nature of the problem. Most of these emerging “factories” seem to stop at the boundaries of existing professions. Engineering-led software factories are often remarkably abstract about what happens upstream and downstream of software production. Product management factories tend to stop where the software factory begins. GTM factories focus on their own slice of the value chain.

And poor design is sitting somewhere in the middle wondering WTF is going on.

We’re all enthusiastically building systems that preserve our professional identities and potentially give us a new source of power, but we’re still organizing those systems around the very functional boundaries that cross-functional product development was supposed to transcend.

We’re reimagining the future of work one professional silo at a time.

I’ve been isolating in bed with COVID for the last week, with way too much time on my hands to think, watch YouTube, and revisit old favorites, including Sean Lew and Kaycee Rice’s incredible dance to Noah Kahan’s False Confidence.

While the choreography explores the relationship between two people, something struck a chord when I imagined the dancers as different parts of ourselves, sometimes fighting, resisting, supporting, and finding joy in one another.

I wonder why I tear myself down
To be built back up again

That got me thinking about how people (myself included) “self-sabotage” at work. The brain fog has made it hard to write a real piece, but I managed to pull together these thought fragments.

You may be responding to something genuinely wrong. You can find yourself in objectively harmful situations, dealing with toxic behavior, and dysfunctional environments. Recognizing that your response is counterproductive doesn’t (necessarily) mean your perception of the situation is distorted or that the problem exists only in your head.

Self-sabotage can itself be a protective mechanism. As harmful or counterproductive as the immediate consequences may be, the feelings you’re protecting yourself from might seem far more painful or threatening. The behavior may be working against you while also doing something important for you.

Your response may also be rooted in something deeply meaningful. The behavior may be an attempt to protect values, relationships, hopes, or parts of yourself that are sources of strength, meaning, joy, and belonging. The protective strategy may not be working, but that doesn’t diminish the importance of what you’re trying to protect.

We may be protecting what we value by keeping it out of reach. Sometimes our habitual responses allow us to defend our values without fully confronting what it would mean to live by them. We may be avoiding the vulnerability, uncertainty, compromises, or responsibilities that come with actually pursuing what matters to us. In trying to preserve something precious, we may inadvertently prevent ourselves from experiencing it.

We can’t always think our way out of something we need to feel. Thinking, analysis, and even “overthinking” can become learned forms of emotional protection. Intellectualizing can offer a sense of control and distance from painful feelings. That doesn’t make thinking useless, but intellectual understanding isn’t a substitute for emotional experience.

Allowing ourselves to feel can be a powerful act. In difficult situations, one of the hardest things we can do is take a few deep breaths and fully experience what we’re feeling, without immediately reacting, defending, or trying to change the situation. It can feel like surrendering power or letting someone get away with something. But allowing ourselves to feel isn’t the same as giving in. It can free us from our habitual protective responses and give us greater freedom to choose what we do next.

Trying to correct our responses can reinforce the very patterns we’re trying to change. We often imagine that self-improvement means carefully monitoring our reactions, catching ourselves in the moment, and consciously redirecting our behavior. But this can replicate the constant self-surveillance, suppression, and pressure to behave correctly that contributed to the problem in the first place. We risk becoming even more vigilant and self-critical in our efforts to become less reactive.

Self-doubt and rigid conviction can be two responses to the same experience. When we spend years being told our reactions are inappropriate or our perceptions are wrong, we may learn to distrust our own judgment. Or we might learn to fiercely defend our beliefs, even to the point of undermining the very things we care about. Both can become forms of emotional protection. The person who masks may sabotage themselves silently, suppressing their needs and losing touch with their own judgment. The person who fights back may sabotage themselves publicly, damaging relationships and opportunities.

Trying to change others can become a form of emotional protection. We may find ourselves desperately trying to make others more caring, fair, curious, or understanding, partly because we believe we’ll finally feel safe, accepted, or at ease if they change. But there’s only so much influence we have over others. Accepting those limits can bring real sadness, disappointment, and grief. We can acknowledge that loss without excusing harmful behavior, abandoning our values, or giving up on the possibility of change.

The categories we put people into can reveal the roles we’re casting ourselves in. It’s natural to sort people into recognizable types. But when we repeatedly cast others as arrogant leaders, clueless colleagues, or people who “don’t get it,” we may also be casting ourselves as the truth-teller, the misunderstood outsider, or the person who has to fix things. These narratives can make the world feel safer and more predictable. But they can also keep us locked in familiar roles and conflicts, even as we resist being reduced to someone else’s categories.

Work can be an especially difficult environment for navigating identity and emotional protection. Its ordinary mechanisms, including power, evaluation, self-monitoring, self-regulation, and judgments about acceptable behavior, operate through the very psychological dynamics we’re trying to untangle. Complicating matters, the very traits and behaviors that trigger our protective responses, such as dominance, overconfidence, and dismissiveness, can also be rewarded and help people rise to positions of power.

Not everything we feel is something we need to regulate or overcome. It’s human to crave belonging, care, support, camaraderie, and meaningful relationships. When workplaces or people fail to provide these things, our disappointment isn’t necessarily a failure of emotional regulation. Sometimes we’re experiencing a genuine loss. We can acknowledge that loss, grieve what isn’t available, and decide what to do next without treating our needs as something we must overcome.

It’s okay to complain, to feel disappointed, and to be let down. Not every complaint is negativity, and not every disappointment is something we need to reframe or regulate away. Workplaces can fall short of their promises. People can behave badly. Things we care deeply about may never materialize. Talking about these experiences, sometimes just to be heard or find solidarity, is a normal part of being human. We don’t have to turn every frustration into a lesson, a solution, or an opportunity for personal growth.

We can have real adversaries without letting them take over our inner lives. Some people genuinely oppose our values, threaten what we care about, or seek to undermine us. Our anger and resistance can be entirely justified and fiercely passionate. But when the battle consumes us, shapes our identity, or becomes something we can’t let go of, we risk giving those people even more power over our lives. We can stand up for what matters without making our peace dependent on defeating those who threaten it.

Continuous self-improvement can become its own trap. We can turn self-awareness, emotional regulation, and even inner work into another set of standards we must live up to. Every difficult reaction becomes evidence that we have more work to do. The pursuit of becoming healthier, more balanced, or more effective can itself become a protective strategy, keeping us from experiencing the very feelings we’re trying to work through. Instead of learning to accept ourselves, we become increasingly sophisticated at finding things to fix.

Our deepest commitments can come from places of both love and hurt. Our identity can be rooted in both deeply held values and painful personal experiences. These experiences can become sources of tremendous strength, meaning, and positive change, even as they sometimes activate protective behaviors that work against us. We shouldn’t mistake the presence of hurt for evidence that our convictions are misguided, nor assume that the strength and authenticity of our passion mean there is no hurt underneath.

Not every threat response is a false alarm, and not every tension needs to be resolved. We’re often told that our reactions are outdated survival mechanisms. The classic “you’re not on the savannah about to be killed by a cheetah” argument. But reality isn’t neatly divided into real and imagined threats, adaptive and maladaptive responses, or needs we should embrace and those we should overcome. We can simultaneously need belonging and independence, safety and challenge, connection and dissent. The goal isn’t to eliminate these tensions or reprogram ourselves to stop feeling them, but to become more comfortable navigating them.

Acceptance doesn’t mean deciding that we can’t change things. We may be able to change a difficult situation, influence others, or challenge an injustice. Or we may not. The difficult part is accepting that we don’t always know, and that our efforts may not succeed. We can care deeply, take action, and pursue change without needing to control the outcome or make others respond as we hope.

Denying our agency can become a form of emotional protection. Sometimes it’s easier to convince ourselves that we have no choices than to face the uncertainty, responsibility, and potential pain of exercising them. We may have less control than we’d like, and our efforts may fail. But acknowledging those limits doesn’t mean denying the choices we do have.

The search for an explanation can be both liberating and constraining. Discovering why we think, feel, or behave a certain way can bring enormous relief, clarity, and self-acceptance. It can help us better care for ourselves, recognize what we need, and seek accommodations and support. But explanations can also become labels we feel trapped by, or stories about ourselves that limit what we believe is possible. We may swing between finding freedom in an explanation and feeling constrained by it, sometimes experiencing both at once.

Our work and our workplace are not the same thing. We can care deeply about our work without making every workplace conflict a referendum on our values, competence, or identity. Sometimes protecting what we love about our work means accepting the limitations of a particular workplace, choosing our battles, or moving on. We don’t have to win every local struggle to remain true to what matters to us.

Our relationship with work changes as we grow. What we needed, valued, and sought from work in our 20s may be very different from what matters to us in our 40s or 50s. Looking back, we may wish we’d learned certain lessons earlier, avoided particular traps, or cared less about things that consumed us. But perhaps some of those experiences were necessary parts of becoming who we are. Growth isn’t always about learning to do things better. Sometimes it’s about changing what matters to us, what we’re willing to tolerate, and what we no longer need to prove.

Maybe we need to learn to dance with ourselves, rather than constantly trying to fix ourselves. I love Sean Lew and Kaycee Rice’s dance to Noah Kahan’s False Confidence. There’s that line, “I wonder why I tear myself down,” and later, “Surrender yourself.” Sean Lew described his intention with the choreography as creating an experience where two people could be vulnerable and silly together. But I love another interpretation: imagine the two dancers as different parts of ourselves, sometimes fighting, resisting, teasing, supporting, and finding joy in one another. What if the goal isn’t to make one part win, or finally become the person we think we should be? What if we could learn to dance with all these parts of ourselves instead?

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!

Life gets easier when you stop getting pulled into debates over people’s implicit causal claims and start recognizing that many of these conversations are really about values, identity, and worldview. Yours/ours included.

This is difficult because those beliefs can be hurtful, dismissive, or diminishing. And you may have very good reasons to believe the causal claims are wrong. But recognizing what’s happening doesn’t mean agreeing, abandoning rigor, or letting harmful claims go unchallenged. It means having more choice about how you engage, rather than feeling compelled to debate every claim on its empirical merits.

And it takes humility to turn that same lens inward. Our own causal explanations are also shaped by our values, identities, and worldviews. We may be just as invested in defending what we believe as the people whose claims frustrate us. Recognizing this in others is one thing. Recognizing it in ourselves is another.

Four Causality Frames

When talking about individuals, environments, skills, traits (e.g., agency), past experience, company success, etc., it is common to mash up four perspectives.

1. Causality as a working (often implicit) hypothesis. “We’ve seen this approach work in other companies. We don’t know exactly why it works, but it’s worth trying here.”

2. Causality as identity reinforcement. “I’ve worked with exceptional people. I know what good looks like. The problem here is that we don’t have the same caliber of talent.”

3. Causality as understanding what happened and why it happened. “How much of that company’s success came from its people versus the environment they worked in?”

4. Causality as understanding what changes the odds. “What could we change about our environment to increase the odds of developing exceptional people and achieving exceptional outcomes?”

Perspectives #1, #3, and #4 describe different things we’re trying to do with causal knowledge. Perspective #2 is different: identity and worldview influence all three activities, while also becoming causal factors themselves.

Halos

A lot of management discourse runs roughshod over these categories.

We start with a retrospective explanation of why a successful company succeeded (#3), promote it into a claim about what other companies can do to improve their odds (#4), downplay the extent to which our identities, values, and worldviews shaped the explanation in the first place (#2), and then package the whole thing into a punchy management book full of practical advice and heuristics (#1).

See Rosenzweig’s The Halo Effect, Pfeffer and Sutton’s Hard Facts, Dangerous Half-Truths, and Total Nonsense, Stewart’s The Management Myth, and Weick’s Sensemaking in Organizations.

Vibes

The Tech-vibe-osphere is an especially interesting mix of these four perspectives. People share what worked for them (#3), make claims about what will work for others (#4), and turn those claims into practical advice, tools, and heuristics (#1). All of this is deeply intertwined with identity, worldview, and a belief in the transformative potential of technology (#2).

Importantly, those beliefs aren’t somehow separate from causality. They’re part of it.

Our beliefs about how the world works can help shape the world itself. And when things work out, success can reinforce the entire worldview, not just the particular assumptions that turned out to be useful.

• Success validates the doctrine. We succeeded because we embraced the right principles.

• Failure validates the doctrine. We failed because we didn’t embrace the principles sufficiently.

• Skepticism validates the doctrine. Your resistance demonstrates that you lack the necessary mindset.

See Epstein’s Tech Agnostic, Morozov’s To Save Everything, Click Here, Postman’s Technopoly, and Festinger et al.’s When Prophecy Fails. For examples of these beliefs in situ, see Andreessen’s Techno-Optimist Manifesto, Graham’s How to Make Wealth and Founder Mode, Thiel’s Zero to One, and Altman’s How to Be Successful.

The Classics

But the tension is a lot deeper than shoddy research or vibes. These are classic, foundational tensions:

1. Explanation doesn’t necessarily produce actionable knowledge. You might understand the unique circumstances that made one organization successful without learning much about how to improve another.

2. Actionable knowledge doesn’t necessarily produce a comprehensive explanation. You might establish that a particular practice improves performance across many organizations without understanding all the mechanisms involved or why one particular organization succeeded.

3. As we explored above in Vibes, worldview and identity aren’t distinct from either explanation and action. They influence which explanations we favor, which questions we ask, what we’re willing to try, and how we respond to evidence. Our beliefs about what causes success can themselves become factors in producing success or failure. Worldview and identity aren’t outside the causal story. They’re active participants in it.

4. People are going to extract heuristics no matter how hard you try to prevent it. People need to make decisions under uncertainty. They can’t wait for comprehensive explanations or definitive evidence before acting. Simplification isn’t necessarily a failure of reasoning. We want clear answers, generalizable principles, and practical advice. But the closer we look, the more we encounter contingencies, interactions, exceptions, and limits to what we can confidently claim.

See Pearl and Mackenzie’s The Book of Why, Cartwright and Hardie’s Evidence-Based Policy, March’s The Ambiguities of Experience, Weick’s Sensemaking in Organizations, and Gigerenzer and Todd’s Ecological Rationality.

SO…

So what can we do about this?

To start, we can be much more aware of the conversation we’re having, and the transition points between the discussions. We can share stories, develop heuristics, and learn from successful companies (and “failed” companies) without pretending we’ve established universal truths. We can recognize that our identities and worldviews are part of the equation. We can’t just magically set that stuff aside.

Finally, there’s a useful interpersonal skill here.

A lot of tech’s sweeping claims about merit, grit, agency, and mindset are closer to secular theology and folk psychology than serious engagements with decades of research. Once you recognize this, you can stop treating every claim as an empirical argument that needs to be debated, dissected, or disproven. You may be trying to establish what causes an outcome, while someone else is defending a worldview, sharing a useful heuristic, or expressing deeply held values.

We can choose to deeply interrogate our own beliefs, but we live and work alongside people who may not share that inclination. Not everyone has the interest, time, or motivation to examine how their worldview shapes what they notice, which explanations they favor, or how they interpret evidence. What we consider intellectual rigor, someone else may experience as needless complication, indecision, or a challenge to something they hold dear.

Rather than trying to win a causal argument that the other person may not even be having, we can become curious about what they believe, why they believe it, and what those beliefs mean to them.

This doesn’t mean abandoning igor. It means recognizing that we can hold ourselves to a high standard of inquiry without assuming everyone else has agreed to participate in the same exercise.

10 years ago I wrote a post on Medium about Feature Factories that literally changed my life. Funny story: I was trying to get a Medium researcher to understand something. I wrote the post in a couple minutes to “prove” that the punchier, more hard-hitting, more judgmental, and more “oh, I’ve seen that before” a post was, the more traffic it would get. I meant what I wrote, but I was struggling to explain how the longer I spent on a post, and the more nuanced I tried to make it, the less traffic it got. So this was my way to “prove” that.

Anyway, it went “viral,” hit Hacker News, and I eventually got a job I really liked because of it. And it kicked off a lot of my writing for the last ten years. I’ve written close to a 1000 posts since. It has been a fun ride. I don’t write stuff like that anymore, but I love returning to it to explore my thoughts.

Every couple of years since then I have written a retrospective of sorts. Here are some thoughts on the post, ten years later. I have an app called Flowstate that sits you down in front of a blank (full) screen with a timer, and if you stop, try to copy-paste, or try to navigate, it all goes away.

Timer engaged.

You Are Working in a Feature Factory

First, you ARE working in a feature factory. So you don’t need any signs. SOMEONE in your company thinks about product in terms of what features you’ve shipped. Once you come to grips with this, life becomes clearer. They aren’t stupid, either; they just haven’t seen any of this work. Or seen it working somewhere—like working at a feature factory that kicked ass, where they didn’t really understand what made that work (it happens). Or you are working in a/an ___________ factory (more on that later), which is a dominant mindset almost everywhere.

So you are. The trick then is what to do about it and stay sane.

Beyond the Binary

Ten years later, and I’m tired of all the ____ vs. ____. Outcomes vs. outputs. Projects vs. products. I was a major purveyor of this, as well, in countless ___ vs. ___ diagrams. They make work seem like a 0/1 situation when you’re typically doing all of it anyway.

Maybe these things were useful bugworms in executives’ ears, but I’ll always remember sitting around with a team from a company frequently touted as being product-forward and someone saying, “This is weird. We use projects. We have products. We care about outputs AND we care about outcomes. Sometimes we just ship things; other times we do a lot of exploration.” The whole idea that the rest of the world was wrapped around an axle with these false tensions was really funny to them. “Do they honestly think we don’t have executives bearing down on us saying ‘ship faster,’ ‘ship faster,’ or cooking up metrics, or that we don’t have tension between output and proving long-term outcomes? That’s sad… it is the job. I hope they aren’t beating themselves up about this, because it is hard everywhere. Yes, we have more leeway because of the history here, but we aren’t out of the woods.”

Those diagrams, and by extension the feature factory post, were a helpful way to get people talking and made the world nice and simple, but the world isn’t simple.

The projects → products thing caused a lot of companies to name everything/anything a “product,” over-hire product management, set design/UX back, “install” an “operating model” as if it was plug and play, and generally lose sight of first principles. During ZIRP, even “high performing” product orgs tried to go “multi product” and turned everything into products even when it made absolutely no sense to customers. It also had the effect of turning anything further down the stack (platforms, etc.) into a second-class citizen, or forcing it to adopt customer-facing product language to justify existence. Another thing: teams/companies forcing premature convergence, premature hiring, and premature branding around “new product teams,” when the context was completely off. A lot of layoffs were caused by this logic.

Especially in this dynamic climate, it is better to think in multi-quarter bets with a real business case than imagine every team will last forever in its current form (with all the pomp and circumstance of GMs and VPs). Flatter, more grounded in economics, fewer perverse incentives.

More clarifying is the shift in funding/governance mechanisms. That’s the first principle many orgs missed. Somehow “product” became a magic call word and led teams astray. I mention this because “feature factory” and “product centricity” often show up together, and I’ve been thinking about that a lot lately.

Proxies, Trust, and the Work

As proxies go, features aren’t the best, and they aren’t the worst. At least in theory you end up with something reasonably usable. A well-oiled feature factory getting reasonably usable features into production, where things don’t immediately implode and they’re not sitting around digging out from a mountain of bugs, would be a massive step up for some teams.

Similarly, there are a lot of teams seemingly skilled in all things discovery, frameworks, etc.—that can’t ship. They can’t think big, work small. It isn’t that those activities are bad, but they are not really balancing it out on the other side. It can feel sometimes that the team is more comfortable talking about all the stuff they want to do and checking a lot of the theoretically correct things to do, living in Miro boards and docs and strategy meetings, than they are making those tough decisions to put finger to keyboard (or agent to keyboard, or whatever) and making it happen. I say this as a big advocate for many risk-reduction approaches, by the way, but it can feel sometimes that people have lost the plot and they’re trying to reduce uncertainty to the point of being 100% comfortable, vs. taking the plunge.

When you have low trust, or low familiarity working together, or you have a million dependencies to coordinate, sometimes all you can do is rely on proxies. That’s what humans do. I’ve seen high-performing teams reduced to a full, unabashed feature factory motion because anything else would require a leap of faith, a commitment to testing a hypothesis, or… conviction mixed with the confidence that they are supported and can act. Features are as good as you are going to get.

You go through “problem definition” theatrics, but the trust/comfort replacement becomes things people can imagine, things that are tangible, etc. The prospect that things fail all the time is simply not palatable. The team HAS to agree on the proxy to make forward progress; otherwise, it’ll never happen. Look at how transactional project shops work. Yeah, they might pitch outcomes, but because there’s not necessarily high touch with the client, all you’re going to get is agreement on a spec.

And here’s the reality: problem statements, metrics, opportunities, OKRs… these can all be proxies as well. They are an agreed-upon game meant, in some cases, to gloss over existential angst and the fear of actually working together. How many teams do you know who “focus on problems” but somehow never admit they didn’t solve the problem? Or who don’t move the metric but say they are moving the metric? Or who drive themselves in data circles, never revising their metrics? Promotion-driven development is rife in the companies that, in theory, are all about outcomes. In other words, you can run a _____ factory in a million ways, all with seemingly “outcome-oriented” undertones, and never really get to the crux of how hard this work is and how much honesty and trust you need to embrace that.

The Human Stakes

An interesting part of the post was the emotions it (the post) elicited. That feeling of being stuck in a machine that doesn’t really care. Of having people around you who feel your progress can be measured one way when you believe there is another way. Of having people swear up and down that you “just” need to ship X, and everything will work. Of your progress/value being boiled down to how many feature checkboxes you check off a list.

Looking back, it isn’t very well written. There are repeat items. I’m being cranky without giving much depth. But that is in stark contrast to the feelings people have expressed to me over the years about the post. They almost forget the post! It isn’t that important. But somehow it lit this spark for people.

I think this speaks to a much more human thing than just whether you’re feature-oriented, project-oriented, or “outcome-oriented.” We all want a sense of impact in our work, of some sort of epistemic honesty, of making a difference. And we all want to be respected and used for the craft we love… the things we know how to do, and the ways we know how to help. When you don’t have that, you are losing such a huge opportunity as a company. To me, that is the bigger issue here.

Sure, some of the feature factory stuff is about ignorance and people basically never working in an environment that did some of those things and assuming that was the best you can do. Some of it is about out-of-touch leaders who just want output and think their ideas are the best in the world (memo: sometimes their ideas are pretty good). But some of it is the continuous challenge of imbuing meaning in our work and work identities.

It’s a Spectrum

Every problem is a nested solution to a higher-order problem. Every input is an output (to some degree). Every outcome is a tactical, siloed step to a broader, messier, more complex, more nuanced/narrative-filled outcome.

I say all the time these days: “Look, a feature factory isn’t a 0/1 thing.” You’re not in it or out of it. You’re always a feature factory to some degree, even when you think you’re doing validated experiments. Because that near-term impact is locked into a much bigger graph of ideas through linkages with varying degrees of certainty. So if you are in this business, you better get used to that! To quote Greg LeMond, with variation, “It doesn’t get easier; you just start focusing on a higher level of abstraction.”

Platform teams, especially, or anyone further down the stack understand this. You can be as outcome-oriented as you want, but if someone doesn’t buy into your causal chain to impacts on revenue and costs, you are SOL. In fact, you’d be better off running a feature factory in that case while running some experiments/measurement on the side. So to anyone who dreams of hitting the “problem focus” Shangri-La, I’m sorry, but it doesn’t exist. You will STILL be challenged on what you ship. You will STILL be challenged on how it contributes to revenue across some span of time.

Performative Outcome-Centricity

This is the UXR/designer in me speaking, but there’s often so much hullabaloo about outcomes, “jobs,” etc. that people rationalize shipping pretty fricking unusable designs, based on research that was flimsy at best.

This is the reverse of the “ship more” argument above, but I get the feeling that the outcome/goal/problem machinery in companies is often so prevalent, so baked into the “way” for many teams, and so many PMs now have internalized that they are somehow the manager of the “outcome” workstream, that we’ve actually gone way too far. You can make the absolute best case around outcomes, metrics, etc., etc., but end up shipping a product that checks all those boxes under the mantle of being “minimal” or “let’s check the outcomes.” It is the same problem, again, all over again, just with different words. Before it was “ship the feature”; now it is “ship all the outcome frameworks and rituals to show we’re VERY sure this will work.”

The me of 2016 was very sensitive to the outcome side, and it was 10 years ago, but it is like the whole wave that emanated out of that kind of challenge (with all the focus on OKRs, opportunities, Lean UX, jobs to be done, etc.) has come full circle to where on one side you have all this high-level, hand-wavy math, and on the other side you have prompts and specs, and there’s no tinkering, shaping, hands-on-the-thinging actually happening anymore. If there is, it is because someone “just built a prototype for fun,” and teams are like, “OK, ship it.” That’s not a prototype!!!!

This point might not be as fully fleshed out, but you can tell the emotion is there with me. I could just be responding to the chaos of AI at the moment. Another thing: PMs incentivized by the “business case” and “justify every outcome” culture are using AI to create slop tornadoes. LLMs are very good at connecting everything in seemingly realistic ways.

Sometimes Features Are the Answer

This goes without saying, but sometimes the answer is to literally make a list of features and ship them. There are absolutely situations where this is the right thing to do. This makes teams highly uncomfortable. But the interesting part is the debate over when and where that is the right thing to do. There are many, many products, especially now with AI, that are changing some aspect of a motion that has been “solved” for decades. Are you really going to argue with decades of feedback? Where’s the line?

I worked at a company called AppFolio that did a GOOD job of this. They were entering a domain that had been around for a while with on-prem software. They knew they weren’t going to reinvent property management accounting, so they reverse-engineered that. Feature factory for the win. But they also made bold bets on segmentation, where operators would be willing to go with FEWER features in the current landscape, and where new technologies afforded new opportunities. It was a MIX.

And this kind of goes to the idea of what a feature is to begin with. Where do you draw the line? Is an age-old capability that people will JUST NEED a “feature,” or is how you solve it today with AI “the feature”? It isn’t as easy as you think to answer this.

My last company, Dotwork, is/was making the bet that a lot of the long-tail features that legacy SPM providers had built would either not be required or would be so different now with AI that it would be worth a refresh in approach (or avoiding them altogether). Will that bet hold? Or will they get pulled into the old world? Who knows?! That’s the fun of this game.

What Actually Holds Teams Back

This will be a review for anyone who reads TBM, but you have to keep in mind ALL the structural challenges that can hold back a team and keep them stuck in (detrimental) feature factory land. Direct access to customers. Direct access to data. Enough autonomy to avoid premature convergence. Training (yes, sometimes it is a skill issue). The promotion structure, as mentioned above. So. Many. Things.

Yes, I believe we all have agency to TRY something. But that doesn’t mean that something will succeed. When I wrote that, I had not yet worked at Amplitude, met hundreds and hundreds of teams, or observed how crafty people were when it came to running small experiments (good) and what they were up against in their current jobs. A lot of these things are not vibes or mindset—they are literally investments. Money. It costs money to work on your data stack or buy stuff. It takes money to have enough designers on staff to prevent premature optimization. It takes time and money to engage HR in really working on promo structures based on behaviors that counteract the feature factory. If you want to call these “excuses,” that’s fine, but to that I would ask if you have endless political capital, time, and will to do all of this for what will turn out to be but one job in your whole career.

I would challenge folks, however, to get away from 0/1 thinking. An “outcome” in your world might be literally scheduling a short call with a customer using something new. Or instrumenting one data point. Or getting ONE narrative about whether this worked or not.

I hate how people get lulled in by ONLY the best stories, by the highlight reels of highlight reels, by companies literally printing money. As if that is the only way to work and that is the bar. You aren’t seeing the rest. I’ve worked at some pretty great companies, and life is always a continuum between a lot of stuff going wrong, some stuff going meh, and then some standout wins. Long slogs. Murky data. Unclear strategy. A continuous effort to resolve all that.

Experimentation and Conviction

The dream of controlled experimentation. As a general rule, any feature immediately adjacent to cost/revenue, with a short loop for experimentation, should already be the active target of experimentation; otherwise, your company is losing out. Just do it.

But there are many product challenges where controlled experiments are not possible. You are going to need to find other ways to gradually reduce uncertainty. It will not be perfect. I have a sense that when people read the original post, they imagined this utopian setup where, for EVERYTHING you did, someone was going to give you a thumbs up / thumbs down, a % lift, or an “it failed.” It is nice when you can do those things, and you should try, but you can’t carry those expectations to other things you do in product.

Almost by definition, if a strategy is measurable down to a controlled experiment, then it is a short enough loop and a siloed enough / clean enough causal graph that other people are playing the exact same game. There’s a reason why companies COMPETE directly on landing page optimization, etc. But it is also a brutal head-to-head battle. Many of the longer-burn strategic things you do will be more like pseudo-experiments or (insert words here to describe them).

The power of conviction. Data can boost conviction. But conviction can eventually lead to collecting data. At a wide enough span of time, you NEED conviction. In my experience, teams that beat the factory often do so out of conviction. Conviction in that way of working. Conviction triggered by terrible screwups in the past where they were convinced they knew everything, but it ended up backfiring. There is an irrational part of this at play that simply “proving a feature didn’t work” cannot solve. Because depending on their mindset, they’ll just call that an exception.

Conviction is a slippery thing because it can also drive your product over a cliff when you’re unwilling to accept what is happening. But the tension is REAL. Especially if we are attempting to create a future that doesn’t match the past, to bring something new into the world, to do something that on the surface seems irrational right now, you’re going to have to plod ahead and walk the path less traveled.

The Game Starts Before the Team

Beating the feature factory begins with the rationale for forming the team or work group and how the game is established from the very start. It is cliché to always point to strategy as “the problem” (just like pointing to a bad apple is often the easy way out). The causal narrative is too seductively pleasing.

But at some point, someone sold the org on starting the team, and they made a bet that extended beyond features (hopefully). They set the game in motion. They had opportunities to get a real business case in there and to encourage the team to think about being able to rationalize their work in core economics (in a healthy way). They may have assigned a VP, Director, or PM with ways of working locked into their head.

It is VERY DIFFICULT to rewind the clock back to that meeting with finance and change the game from a feature factory game to an outcome/economics-backed game. This is the importance of org design, but going beyond the typical boxes and arrows, journey maps, and JTBD-to-team assignment bingo that all look good on paper because they match a Miro board and nice, neat categories but fall apart the second someone talks about outcomes.

AI Amplifies Both Directions

So much to say, but apparently factories are all the rage right now. Software factories. Spec-driven development. Getting your “swarm” of agents building, etc. A couple thoughts. Imagine the possibilities if you can thoughtfully use AI across the full loop to wiggle out of a feature factory. It is pretty good at instrumenting analytics. It is decent at connecting more signals. It is decent at rapid prototyping. It is decent at re-contextualizing your work for different audiences to elicit the right feedback. You can use AI in so many ways to beat the feature factory. Heck, you can have triple the number of shots on goal.

And, of course, you can let it accentuate all of your bad habits. I heard recently of a team that was AI-PRD-ING it up. Suddenly, everything was clear! The reasonable-sounding PRDs were eliminating back-and-forth. Bad, bad, bad.

They had taken a toxic doc culture and amplified all the crap. And, by the way, they were very “outcome-centric,” because if you really want to make business cases that no one will look at (or they’ll just ask their LLM to look at), look no further than AI. You have teams that were never talking to customers in the first place, talking to machines pretending to be human at your beck and call. This is mind-blowing. Like positioning synthetic personas as an answer to teams looking for the easy way out… they aren’t even in a position to determine where the boundaries are.

I would say that for AI it boils down to amplifying the bad habits, and creating leverage for the good habits.

OK. Nearing the end.

It has been a fun ten years. That post helped me get my Amplitude job, which helped me meet so many great teams, further my understanding, etc. The whole vibe and reality have shifted. The problems and opportunities feel much more serious than whether you ship some features sometimes (or not). You have people blissed out, about to enter an echelon of phenomenal wealth. And people leaving tech. And people pondering whether they might ever get a job again in the industry. I’m projecting my own innocence at the time, of course, but it feels like I was wrapping my head around one tiny part of the iceberg. I’m much more interested in how people show up in the weird places we call work than whether a place passes some kind of arbitrary benchmark of being something or not being something.

Maybe above all things that is what sticks with me.

The desire for impact, truth, craft, etc.

In other posts, I’ve written about the distinction between “the work” and “the workplace.” I want to dig a little more into what makes workplaces unique.

It is not naïve to seek autonomy, mastery, and purpose at work. Given how much of our lives we spend working, it would be strange not to.

The seductive mistake, however, is to assume that companies function like families, guilds, unions, friendships, expeditions, sports teams, congregations, neighborhoods, or communities. Humans organize themselves in all sorts of interesting ways, each with its own purpose, expectations, obligations, and peculiarities.

Institutional theorists Roger Friedland and Robert Alford argued that different institutions have different “central logics.” A family, company, profession, and community may overlap, but they demands different things (from us), and make different promises in return.

Companies are unusual.

They can provide us with meaningful work, friendships, belonging, opportunities to grow, and, importantly, money to put food on the table. But they also combine several features that complicate our relationships within them.

• Our livelihood, career, and reputation are at stake. So high stakes.

• Relationships are temporary, uncertain, and often not of our choosing.

• Power and influence (and protection) are unevenly distributed.

• Performance and accountability are open to competing interpretations.

• We can survive without resolving a conflict (e.g., “lay low” or “wait it out”).

• What protects an individual may harm the team.

• Leaving is possible, but rarely without cost.

This is why companies are not especially well suited to providing unconditional support, lasting membership, or the kind of mutual obligation and reciprocity we might reasonably expect from other relationships. When we imagine companies as families (or teams, pirate ships, professional communities, or congregations), we transpose expectations the institution simply cannot reliably fulfill.

Denise Rousseau calls this a psychological contract, which she defines as “an individual’s beliefs regarding the terms and conditions of a reciprocal exchange agreement.” Because the contract exists in the mind of the employee, it can feel binding even when unwritten or not shared by the organization. A breach can therefore feel like betrayal even when no formal promise was broken.

Well-meaning HR teams and leaders may work tirelessly to create environments of inclusion, engagement, belonging, and psychological safety. That work matters. It can make companies far more humane. The care and relationships can be real. But none of this makes the bargain unconditional. It remains shaped by economics, incentives, unequal power, and the ever-present possibility of exit. The more a company feels like a community, the easier it is to forget the limits of the institution underneath it.

There is a lot of talk about agency, and especially being “high agency.” That may help us improvise, and roll with the punches. But it does not magically change the calculus of company work. The imbalance of power and the cost of leaving remain. The relationship is still conditional.

We also place expectations on ourselves that we cannot reliably fulfill. We can come to see our inability to resolve contradictions built into the institution as a kind of self-betrayal. When the bargain breaks down, the sense of betrayal can turn inward as a kind of self-gaslighting. We beat ourselves up for “caring too much,” staying too long, failing to speak up, failing to leave.

This is where healthy ambivalence helps. We can let the work and the relationships matter without expecting the institution (and the humans representing the institution in various ways) to promise more than it can.

Simone de Beauvoir wrote about the ambiguity of being both free and constrained.

Let us try to assume our fundamental ambiguity. It is in the knowledge of the genuine conditions of our life that we must draw our strength to live and our reason for acting.

We can act, but we always do so within conditions we did not choose or control. Something similar is true here. Work can be genuinely meaningful, and the workplace can remain a conditional bargain. Neither cancels the other out.

Most of us will work for decades. Across that time, we may have several “work lives.” The work itself may follow different arcs and change as we do. We may spend only a few years at a particular workplace, or perhaps a decade. Keeping that difference in view creates a certain freedom, even some levity. A workplace can matter deeply without becoming the whole story. It is one place where the work happens for a while.

And some lighter material… after The Standard Setter, I wanted to follow up with another curious character….

The Case-by-Caser

May I present to you: “The Case-by-Caser.” By repeatedly asking for specifics, they can make any problem not their fault, and any systemic issue magically disappear.

The tactic here is very simple. No matter the problem, keep pushing people to give “specific examples” until you’ve narrowed and flattened the thing down to something innocuous that can ideally be pinned on an individual, or a small group of individuals, or a concrete next step.

The Case-by-Caser makes it very clear that no systemic issues, or anything uncomfortable or messy, will be tolerated. The burden of proof falls completely on the reporter. Anything that doesn’t comport with some arbitrary (and safe) version of specificity will be summarily chastised and challenged.

The beauty of the CBC’s tactic is that, on the surface, specific observations are valuable (especially if you stick with observations and don’t label them). They are salient. They help people grapple with what they are experiencing. The right tactic is to surface broad/diverse observations, and then grapple with sense-making together. Act through “the problem.”

A problem that has stuck around is most certainly impervious to simply reporting a “specific example.” You have to foster a situation where the team can move beyond sweeping statements to something more “tangible,” but that isn’t a switch you just turn on/off.

So asking passes the sniff test.

With the CBC....

The problem is in the complete lack of coherence in their approach.

The definition of specific is completely arbitrary. When it comes to a vague strategy and someone calling that out, they are “uncomfortable with uncertainty!” “Why do you need all of these details?” Yet when it comes to a problem, somehow the tables are turned and you need to define the specifics. Strategy vibes are fine. Problem vibes are not fine.

Why is this effective? No one ever got fired for asking for specific examples. Plenty of people have gotten fired for trying to talk about systemic, messy problems.

So the CBC has a 100% self-sealing tactic. There’s a hard-to-parse undercurrent of fear and doubt. “What’s a specific example?” How do you answer that?

Whenever there’s a problem, the Case-by-Caser confidently points to the fact that they’ve addressed “all specific problems,” and they have a self-sealing argument to their boss.

Is there any way to beat the CBC at their own game? Probably not, especially if they have more positional power than you do. They can always ask for another example.

Stop trying to win the argument. Ask yourself what intervention you can actually make that has some chance of changing the system. You don’t necessarily need the CBC to agree with your diagnosis to start acting on what you’re seeing. Sometimes the most expensive mistake is believing you need permission from the person denying the pattern before you can do anything about the pattern.

May I present to you: The Standard-Setter. The Standard-Setter’s superpower is failing upward while confusing pressure with motivation. They believe everyone has another gear, and that their job is to force people into it.

The Standard-Setter operates from a simple belief: that by merely telling you to “make the impossible possible,” and by “setting extremely high standards,” they can somehow magically make you more effective.

But they often have no idea what they’re actually talking about. They don’t demonstrate the thing by example, or their example comes from a completely unrelated domain. What they have internalized, deeply, is the identity of a high-performance leader: someone who demands excellence, refuses excuses, and gets “more” out of people.

What they often dismiss is the fact that you could get the same results w/o driving everyone crazy and wasting energy dealing with them.

Statistically, it is probably safe to say that we are all “capable of more” under certain contexts, for certain periods of time, and with varying second-order costs. So the Standard-Setter will inevitably accumulate plenty of evidence that what they are doing “works.” Someone rises to the occasion. The mistake is treating those observations as evidence of impact rather than simply evidence that people can respond to pressure.

The Standard-Setter isn’t like a trusted coach who has worked 1:1 with LOTS of people over the years playing a very specific game. No, the Standard-Setter sort of naively adopts the worldview that pushing people harder is itself a form of leadership. And then, oddly, they expect some of the loyalty and trust we might give a great coach without having earned it through expertise, attention, shared experience, or demonstrated understanding.

The Standard-Setter also tends to hallucinate that they have somehow figured out how to motivate *everyone* with their approach, missing that a lot of people don’t respond to pressure, exhortation, or someone else’s intensity. They respond to clarity, trust, autonomy, meaning, mastery, good feedback, and the feeling that their effort is actually connected to something worthwhile.

A great coach or teacher knows this. They don’t try to motivate people the same way.

The Standard-Setter sounds like a broken meme, cajoling everyone with the same platitudes.

Standard-Setters can also make remarkable upward progress in organizations because their style is extremely legible from above. They look ambitious. They can point to moments when teams stretched and “won.” The costs, meanwhile, are often dispersed downward: exhaustion, resentment, churn, and the energy required to manage the Standard-Setter themselves.

If there is one solace, eventually the Standard-Setter has to show what THEY can do, or meet their match in someone with enough influence that they CAN’T bully. The trick only works as long as the Standard-Setter can keep converting positional power into apparent performance.

In this post, I’m going to share ten career traps thoughtful people often find themselves ensnared in.

I’ve found myself in every one of these traps over the years, so I speak from experience. I’ve also watched some of the most thoughtful (and experienced) people I know fall into them, even when they “knew better.” Or perhaps partly because they knew better. As sports coaches sometimes say, we go where we’re looking.

Every trap below begins with a strength or virtue. Curiosity. Empathy. Courage. Helpfulness. Sensitivity. Intellectual honesty. A willingness to question. A desire to make things better. The ability to see patterns other people miss.

What makes these traps interesting is that they usually start innocently enough. You get pulled in through some combination of your strengths, your weaknesses, and your strengths becoming weaknesses.

It isn’t that we have no agency. We do. The hard part is figuring out where the inflection point actually is. In hindsight, it can look obvious. In the moment, it often isn’t.

I’ve recently learned how much patterns, and naming the traps, can help. The trick is figuring out your tripwire: the saveable moment. You have to rehearse it before you’re in the thick of it. Find a friend to help. Plaster your wall with reminders (just off camera).

The Volunteer Trap

When your radar for problems renders you illegible.

aka “What did we hire them to do again?”

You sense incoherence, and you’re eager to help, so you self-volunteer to help out. Or you’re invited to help by people who sense your willingness to help. Many of these problems are not officially part of the mental model for your job (though they may obliquely block your job). They’re lingering problems, and there’s a reason they’ve stuck around. But your optimism and general belief in humanity, seduces you into believing this time it could be different. People are gracious at first. They are relieved, and even invite you in. Then you’re “doing things” people don’t generally understand and can’t explain.

Gradually, you become the figurehead for problems you’ve waded into, and when layoffs come, people “don’t get what you do.”

Saveable moment: You notice you’re stepping into a problem because you can see it and care about it, but it’s not clear who else is willing to own it, support it, or have your back when it gets messy.

See also:

• The Spokesperson Trap. Stepping into a messy, orphaned problem can make you the person associated with it. “What’s going on with X?”

• The Canary Trap. Taking responsibility for problems others avoid can pull more and more of your attention toward what is broken. People might actually use you as an early-detection system.

The Curiosity Trap

“We Want a Fresh Perspective, Just Not That Fresh.”

People are curious. They seek you out. They tell other people that you’ve been chatting “So I was talking to Cutler about this…”

But they’re only pulling out the parts they already agree with and scratch the curiosity itch. They fish for the actionable bits, can’t find them because you never really had a reference point, and you get pegged as “all talk” even if you were offering solutions. Alas, they didn’t interpret them as solutions because they didn’t match their version of solutions (to you, they were).

Someone who was validating you with their curiosity is now turning on you, and the message that “leader doesn’t like X” starts to spread. Your other relationships suffer. What drew them in—the outside voice, the person offering something new—ultimately becomes a source of threat.

Saveable moment: Someone keeps coming back for your perspective, but you notice they are mostly extracting the parts that fit what they already believe.

See also:

• The Thinking in Public Trap. People may seek an outside perspective, then recoil when that perspective comes with visible complexity and unresolved edges.

• The “Let’s Admit We Don’t Know” Trap. A fresh perspective often exposes uncertainty that people were hoping the fresh perspective would resolve. “I thought you could fix this, and now you’re asking questions?!”

The Defender Trap

When you jump to defend, but end up becoming the focus of the fight.

aka “Why are they standing up for people who are obviously wrong?”

You see someone, or a group of people, being ostracized or typecast, and it triggers a need to defend, push back, and come to the rescue. Voice the other side. Challenge bias. You hold on to the idea that it’s a misunderstanding and try to win people over with more information. That comes across as naive and difficult to parse (“I don’t get why they’re standing up for the people who are OBVIOUSLY to blame!”). In the version of the world the antagonizers inhabit, this is a sign of weakness. You become a sponge for people’s anxiety from all sides. Lose sleep. Start being a jerk yourself. It becomes us vs. them, you attract allies who are on people’s shit list, and you’re “so negative.” By that point, you’re also part of the problem because you have trouble offering generous interpretations of people’s behavior. What started as a misunderstanding, is too far gone.

Saveable moment: You notice yourself moving from “I want to make sure this person is being interpreted fairly” to “I need to prove these people are wrong.”

See also:

• The Spokesperson Trap. Defending someone else’s position can make you the most visible carrier of it.

• The Canary Trap. Staying inside a conflict long enough can turn hyper-vigilance into a way of operating.

The “Let’s Admit We Don’t Know” Trap

When your comfort with uncertainty gets mistaken for reluctance, perfectionism, or lack of conviction.

aka “Why are they making this so complicated?”

It’s OK to be uncertain. What really gets you is when people say it’s figured out, and it isn’t. So you ask questions, and seemingly innocent questions challenge the status quo. You get branded a perfectionist, a skeptic. All theory. Not realistic. Once the criticisms or “constructive advice” starts rolling in, you sure START sounding like a perfectionist. You defend your pragmatism with altruism, and your bias for action with apparent reticence. You’re spending most of time trying to defend your feedback and questions vs. actually getting answers. The more defensive you get, the more you’re actually part of the incoherence. What started as a leader choosing to gloss over the inconvenient parts of the story, becomes an all-out assault on your reality and your dignity.

Saveable moment: You have asked the question once or twice, and instead of answering it, people start giving you feedback about how you are asking it.

See also:

• The Right But Early Trap. Admitting uncertainty often means noticing weak signals before others are ready to take them seriously.

• The Thinking in Public Trap. Showing what remains unresolved can be mistaken for not having a point of view.

The “Thinking in Public” Trap

When showing your reasoning process gets mistaken for not having a point of view.

aka “Can we just get to the answer?”
aka “Do they ever just land the plane?”

You break things apart and rebuild them. You take joy in refining ideas with holding your ideas loosely and being willing to crush them. You’re comfortable with holding multiple competing ideas at once. That produces stellar results, especially when you’re able to control your groove and audience, until it becomes your shtick. Over time, you’re known for going deep, and seeing both sides, not driving action. Your thorough, thoughtful, and heartfelt narratives get compared against simple ones. Holding multiple perspectives reads as lack of conviction, and “how can we make this actionable?” follows you even when you self-identify as having conviction and having a bias for action.

As with other loops, soon you’re investing a ton of energy defending yourself from the typecasting, over-compensating, and suddenly you’ve gone from “strategic”, to “they go way too deep all the time,” to “they seem to be selling all the time.” You become self-conscious thinking in public or sharing your mad-scientist vibe.

Saveable moment: You notice that people are reacting to the shape of your thinking more than the substance of it.

See also:

• The “Let’s Admit We Don’t Know” Trap. Showing the unfinished parts of your reasoning (even if it is super fun for you, and some people are fans) can look like indecision.

• The Curiosity Trap. People may enjoy your perspective until the complexity behind it stops being easy to consume.

The Right But Early Trap

aka “Why are they making such a big deal out of this?”

You pick it up earlier, and it bothers you earlier. You’re strong at signal detection and taxed by attention gating. To you, calling it out is the solution. To them, “it’s easy to poke holes in things.” You raise a weak signal, and people react as if you’d asked to change the strategy. It accumulates, you get typecast, and your restraint cracks. Right != right now. And with nowhere for the signal to go, you keep pushing.

Saveable moment: You have raised the weak signal, people have heard it, and nothing is happening.

See also:

• The Canary Trap. Detecting weak signals over and over can leave you scanning for the next one.

• The “Let’s Admit We Don’t Know” Trap. Sometimes the signal you are trying to protect is simply that the situation is less settled than everyone says.

The Spokesperson Trap

aka “Everyone told me this privately.”

People share their tension with you, and you see a pattern across them. But then the question is: who’s voicing this? You end up voicing it, even when you try to create a forum for them. Then even the people who shared their concerns back away. They’re fine voicing it to you, just not being associated with you. It becomes your burden. And then suddenly your call-to-arms. This is the worst of all worlds in a sense. You fail at helping others have a voice AND begin to jeopardize the cause yourself. And if you taunt the elephant in the room, suddenly you’re wrapped up as a spokesperson for “Something no one else is describing.”

Saveable moment: Someone says something important to you privately, and you immediately start thinking about how to surface it.

See also:

• The Defender Trap. Once the issue gets attached to you, criticism of the issue can become criticism of you.

• The Volunteer Trap. Many spokespersons started out as people trying to help with a problem no one else owned.

The Workplace Identity Trap

When your experience in one workplace starts to feel like a verdict on your entire professional identity.

aka “Why do I do this anyway?”

Instead of identifying as a designer, you identify as “design at X.” A manager’s validation means “I did a good job.” A leader listening means “they believe in me.” When you fail there, it’s an identity threat. Even small comments send you into a spiral instead of a “shrug, oh well.” As your insecurity grows, so does the need to be validated by THIS environment, THESE people, and THE culture. It is a drift as old as time. What should be seen as a healthy arc across many companies over decades becomes a verdict on your abilities. Meanwhile, no one will be working in this company in 3-5 years.

Saveable moment: A piece of workplace feedback starts changing how you feel about the work itself.

See also:

• The “Game Is All I Know” Trap. The more local validation matters, the more tempting it becomes to reshape yourself around what the environment rewards.

• The Canary Trap. Enough cycles of conflict and exhaustion can turn “this place is hard for me” into “maybe I’m the problem.”

The “Game Is All I Know” Trap

aka “Wait, which part of this is actually me?”

aka “I don’t know how not to do this anymore.”

You learn to adapt, to play the game, at great expense, and you get good at it. You get rewarded for it. You’re playing the game with pride and dignity. It goes well for you, which is the problem. Your ability to mask effortlessly hides the fact that your core identity and life-force is hurting. You rise, showing your cards gets riskier, and you get more guarded at work and at home. Trapped by your own accommodations, until accommodation becomes your identity. This is a cousin of the work identity vs. workplace identity puzzle mentioned above, but it is extreme because your workplace identity isn’t even a playful dance around “the rules.” It has seeped into your identity all the way through.

Saveable moment: Playing the game gets easy.

See also:

• The Workplace Identity Trap. Adaptation gets dangerous when succeeding in one environment starts defining who you are.

• The Thinking in Public Trap. The better you get at presenting the acceptable version of your thinking, the harder it can become to show the messier version at all.

The Canary Trap

The more sensitive you are to what’s wrong, the more likely you are to become consumed by detecting it.

aka “The canary always dies.”

It starts off great. Full force, a lot of attention, a bit of a platform. The more you notice, the less coherent the company becomes, and the less coherent the company becomes, the more you notice. The more you fight. Flame up, flame out. On to the next company.

Saveable moment: You realize you are spending more time tracking the company’s incoherence than doing the work you came there to do.

See also:

• The Right But Early Trap. Being early over and over can train you to stay on alert for what everyone else is missing.

• The Workplace Identity Trap. Repeated flameouts can make an environmental pattern feel like a personal verdict.

Conclusion

The point isn’t to avoid all of these traps. You probably won’t.

The point is to notice them early enough that you still have your wits about you.

Before you’re exhausted. Before you’re defending your identity. Before every interaction feels loaded. Before you’ve spent so much cognitive energy on the situation that perspective itself starts to disappear.

That’s the saveable moment.

When you can still ask:

• What is actually happening here?

• What am I trying to protect?

• What happens if I do nothing?

• What happens if I step back?

Once the trap has fully closed, those questions get much harder to answer. You’re inside the thing, spending energy just trying to make sense of it.

So the work is not becoming less thoughtful, less sensitive, less helpful, less curious, or less willing to care. It is learning to recognize the moment when those strengths are starting to pull you somewhere you may not actually want to go.

Customer call → synthesize insights → decide what to do about it → do it → ship it → measure impact

Pre-AI, this would involve 1) reading/reviewing a call transcript and your notes, 2) synthesizing that into a set of takeaways either in a document or presented somehow, 3) considering a set of options by talking about those options, writing about them, and narrowing those down to some tangible actions/investments, 4) taking those actions (e.g., building something) using whatever collaborating techniques and “pointers to the work” (e.g., tickets), 5) shipping it, and 6) ideally measuring impact by going into an analytics tool, watching feedback channels, reaching out to customers, etc.

At each stage, you were, in effect, asked to process, think about, discuss, reshape, restate, copy-paste, “migrate” information down the line. There might have been meetings, routines, gates, swapping between tools. With only N hours in the week, you were constantly kicking yourself for not being as collaborative, inclusive, comprehensive, or rigorous/disciplined enough. Yes, this was a pain in the ass, but it was also “positive friction.” Each of these information migration moments was an opportunity, in HCI parlance, to apply a forcing function: to focus conscious attention on something, to avoid automating your thinking, to pay attention, discern, say “no” or “what if.”

The friction was judgement and discretion’s friend. We tend to remember the crappy parts: the meeting prep, the “I have a document with 35 feedback themes and a Miro board. Where the hell do I put this?” We remember that sense of never doing enough.

But it was also valuable.

New Reality (Unless You Push Back)

Say you wanted to just automate everything now with AI. You could effectively:

1. Do your expenses during the call. Just ask the occasional question.

2. Take that three-thousand-word transcript and ask an LLM to “summarize this into key pain points” (the average call can generate dozens if not hundreds of these)

3. Plop those pain points into a “skill” that looks at the current code, maybe even checks analytics, and writes up “specs”

4. Run the “Strategy alignment prioritization” skill (alongside your secret “what I need for my promotion” skill) and sequence the bets

5. Shuttle that into some kind of harness to build the thing

6. Have some other agents review the PR

7. Ship it…

8. Half-heartedly verify the features work, but hey, Playwrite has been doing a good job lately, so automate that

9. Trigger a downstream analysis skill that asks if it “worked”

10. And you could effectively do dozens of these calls, or just monitor customer “voice” channels and not even show up. Promotion! Bingo! What a time to be alive!

Notice all the opportunities for thinking, pruning, shaping, designing, judgement-applying that are lost. AND, noticing all the drudgery that is lost. Noticing how very quickly nothing you are looking at is “real” (original, atomic, as written by a human). You have tens of thousands of words of original feedback, yes, but very quickly all you have is pointers (if you’re lucky and/or smart). Yes, the code is real. That’s why everyone has the utmost confidence in that step. But how did the code get that way? Sure, if it is all obvious slop, that’s one problem. But what if it isn’t? That’s almost worse.

Prior to AI, you might focus on one product area, one opportunity, and methodically work through it. You did the same calls, but those calls didn’t come with hundreds of things you could/can do. The blast radius of any particular thing you were working on was narrower. Very quickly, you amassed more feedback than you could meaningfully act on, support, market, communicate to customers, and keep in your own head.

Now you can go from five customer calls (~8000 words) to 80 “opportunities” to 80 “tickets,” 400 “tasks,” and hundreds of stuff to show customers, to hundreds of bits of feedback on those things, to 50 “feature adoption dashboards” (hidden behind MCP obviously).... Not to mention all the internal call recordings, status updates, PRs, stuff, fluff, slop, 1000 interface variations, etc. And after doing ALL of that, your customer is going to say, “I can’t keep track of everything you’re doing.”

All About Relationships

I recently did an activity where I looked at hundreds of artifacts at my current gig and looked at the “job” each one of them played. Many artifacts contain LOTS of atomic bits of job-doing information.

• Signals: What is observed, recorded, written, or measured

• Insights / Interpretation: What we infer from those signals

• Models / Hypotheses: How we believe things work and connect, including assumptions

• Options: Possible paths, configurations, or interventions

• Choice: The selected option and resulting commitment

• Intent: The future state or direction being pursued

• Actions: What actors do to advance the intent

• Mechanical Change: The specific thing that is modified

• Effects / Impact: The resulting change

• Actors: Who observes, interprets, chooses, acts, or is affected

• Materials: Systems, tools, technologies, artifacts, and infrastructure

• Constraints: Conditions that limit, shape, or enable the system

Whenever I see a simplistic “SDLC” diagram, I laugh because real knowledge work is much more than a couple stages. The ontology is much richer.

Yes, there might be a sort of physics in the flow (e.g., observe, orient, decide, act), but imagine everything above as a graph. Every edge in that graph is a transition point, even when we lump together ideas. A PRD might contain signals, insights, choices, etc., and itself serve as a model, but you are really dealing with a discrete mix of more enduring/lasting ideas and more transient ideas.

Of course, the problem was there pre-AI as well. Very few people thought in this level of detail because “it was too complicated” and “you do this naturally when you’re solving problems.” But the active participation was key.

We tend to think of the nouns. But it is the edges where the work happens. Pre-AI this happened whether we liked it or not. Now…we have excuses.

At work, I was trying to untangle an initiative recently. What I observed was as follows:

• TONS of AI-generated summaries on top of summaries

• Lots of surface area in an attempt to be customer-centric. We had a lot of change in the mix, probably far outpacing the customer’s ability to absorb or provide feedback on that change

• AI is very lazy at telling the difference between things (e.g., signals and insights, intent and actions, etc.)

Unless we are very deliberate, we end up with Linear tickets being a dumping ground for synthesized feedback (AI) and code review (AI), and you couldn’t help but be trigger-happy and just ship, ship, ship.

Principles

Here are some rough principles I’m using to tackle this problem:

• Keep original feedback atomic, and preserve its path back to the source. Transcripts and feedback are records of the original context and the start of a loop. Whenever we break that material into smaller items, such as an issue, observation, theme, or action, each item should link back to the original transcript or feedback. That traceability lets us check what was said and recover the surrounding context. If you can’t link back to something real, stop doing it.

• Preserve both atomicity and coherence. Product artifacts often mash together distinct ideas, such as Intent, Options, and Change, into a single issue or document. AI needs those ideas represented as separate, atomic pieces while keeping their relationships and context intact. Atomicity without coherence leaves fragments; coherence without atomicity leaves ideas mashed together. We need both. Miss either and we’re out.

• Add positive friction when content is copied and recontextualized. At each transformation, make it clear what is being carried forward, what changed, and why. The friction belongs at that moment: enough to make the transformation intentional and keep the source links intact.

• Separate the underlying job from its presentation to different audiences. Different audiences may need different framing, but that doesn’t change the underlying job or intent. Keep the source clear, label each audience-specific version as a variation, and link it back to the source.

• Label AI-generated content by degree of AI contribution. Make the label visible on every AI-generated artifact, with a variation such as “100% AI-generated,” “HITL curated,” or “AI used for editing/grammar.” Keep the label with the content when it is copied or recontextualized.

• Avoid compounding AI flattening. The biggest anti-pattern is AI flattening layered on AI flattening, with no thread back to reality. Each round can strip away more of the original context while making the resulting abstraction look authoritative. Summaries are most useful when they get close to a specific problem, opportunity, or action, and remain linked to the source material.

• Don’t let AI capability turn a tool into a dumping ground. The fact that a tool can process information with AI doesn’t mean everything should be put there and sorted out later. Give each item a clear purpose, and keep it connected to its source and context.

• Treat code analysis as one source of evidence. It can be very helpful to see “what the code says,” but seeing X in the code doesn’t establish that customers experience X, that we’re solving the right problem, or why the code came to be that way. Don’t let the concreteness of code analysis create confidence about the broader product reality that the code alone can’t support.

• Use Linear for bounded team intent. An issue should make clear whose need it represents, why it matters, what problem we’re addressing, and enough of how we’ll address it to make the work verifiable by people or machines. It should capture intent, not serve as a transcript repository.

• Go for depth over breadth in product improvements. If everything changes at once, customers can become confused, their feedback can become scattered and nonspecific, and the data can conflate the effects of different changes. Focus improvements enough that customers can respond clearly and we can learn what made a difference. Being trigger-happy with new features puts us at risk of taking on too much breadth.

• Recognize Linear has two jobs. One is team-visible product and feedback intent: the problem or opportunity we’ve decided to pursue. The other is personal planning and decomposition as work unfolds. Both help people track progress and preserve context, but personal breakdowns can create noise for the team and may fit better in personal notes or another workspace.

Hope sharing this helps you think about how you work!

As a last word, I’d leave with you the question:

Where was positive friction a good thing? And how can you embrace new technologies without losing the good things?

Personality and “strength” tests at work have never sat right with me. Sure, they became fodder for some fun discussions and had that occasional “wow, how right!” horoscope vibe. But they rarely seemed to help with day-to-day work, and they never replaced the hard work of truly getting to know people, including how they interact with others and how different contexts bring out different versions of them.

When building a team, we tend to adopt the sports-team metaphor: find the right people for the right positions. Or, slightly more generously, ask, “How do we bring out the best in this person?” or “How can we get these people with different strengths and weaknesses to do great things?”

Though phrases like “culture fit” acknowledge, at least in theory, that someone might be highly successful in one culture and struggle in another, in practice they often downplay the quirks and idiosyncrasies of the culture itself. The culture gets translated into a set of seemingly context-free strengths: decisive, collaborative, high ownership, low ego, fast-moving, intellectually honest. In short: the way we already are becomes “good,” and then we attach big, admirable words to it. The focus then shifts to figuring out how the individual will “fit.”

Even when we know better, we often take the easy way out when describing other individuals. “Oh, they’re a strategist.” “They’re a people person.” “They have high conscientiousness.” “They’re low in agreeableness.” “They’re very analytical.” The label is convenient because it compresses a lot of complexity into something easy to remember and repeat.

This post is about “types,” cultural norms, and why we should focus much more on how people show up in different contexts than on forming theories around the buckets people fall into.

Types And Other Boxes (At Work)

Most personality frameworks attempt to describe relatively stable tendencies. But what you actually care about at work is more like: “What will this person do in this specific kind of situation, with these incentives, norms, power dynamics, and constraints?”

“What type of person are you?” is the wrong, but convenient, question. A better, but harder, question is: “Under what conditions do you behave differently, and what distinctions are you making that cause you to switch modes?”

Take two people who rank high in conscientiousness and low in neuroticism on the Big Five personality test. They are tasked with figuring out the meeting cadence for the company.

One says, “We’re wasting too much time coordinating. Let’s set a standard cadence, put it on everyone’s calendar, and adjust it in a month.”

The other says, “A company-wide meeting cadence is hard to undo and affects everyone differently. Let’s understand where coordination is actually breaking down before imposing a new default.”

Both responses are perfectly compatible with being conscientious and emotionally stable. They have the same personality traits, based on the model. What differs is how they interpret the decision. How reversible is it? What evidence is required? Who has the legitimate authority to decide? What counts as an acceptable experiment?

High conscientiousness and high agreeableness could plausibly produce either:

“This is chaotic. We need a clear daily cadence, but we should involve everyone in shaping it so people feel heard and can commit to it.”

or:

“A recurring meeting is a significant organizational commitment. We should diagnose the problem carefully and get broad consent before imposing a new default.”

Same broad traits. Very different behavior.

The discussion here extends beyond personality. The same issue shows up in strengths frameworks, skills frameworks, leadership competencies, communication styles, and other models, frameworks, and systems that try to describe people in relatively stable terms. Knowing that someone is “strategic,” “collaborative,” “decisive,” or strong at influencing tells you something. But it still leaves open the harder question: under what conditions does that strength show up, fail to show up, become overused, or look very different?

And don’t get me started on “growth mindset,” a phrase I’ve heard bandied about by people with remarkably fixed ideas about what good thinking, good behavior, and good leadership are supposed to look like.

A Personal Example

I’ll use myself as an example. Over the years, I’ve taken everything from Myers-Briggs and DiSC to StrengthsFinder and more empirically grounded trait assessments like the Big Five.

In most situations, I put a high premium on co-designing the solution with other people. I like getting perspectives on the table, making sure people feel some ownership, and then moving. I’m not especially interested in consensus for its own sake; I still have a bias toward action. But I generally want the action to feel like something we shaped together rather than something that was simply imposed.

In a different kind of situation, though, I can change modes very quickly.

If I perceive someone as abusing their power or influence, generalizing about a group of people, dismissing someone’s experience, or treating another person as if their perspective doesn’t matter, I jump into defender mode. I become much more direct, much more willing to confront, and much less concerned with preserving harmony or being seen as agreeable.

So from the outside, those two versions of me might look inconsistent: collaborative and accommodating in one setting, aggressive and confrontational in another. If someone assigned me Big Five personality traits based purely on my behavior in those two situations, they might come away with very different profiles. But internally, the behavior is connected. In the first case, I’m trying to create shared ownership. In the second, I’m reacting to what I perceive as someone using power in a way that makes shared ownership impossible.

In fact, I even received feedback that I was “polarizing.” This stung. After a lot of soul-searching, I realized that I was showing up very differently in certain situations. The feedback wasn’t wrong: my behavior could be polarizing. But it was also internally consistent. Certain situations pushed me into a much more forceful, aggressive defender mode, while in others I was highly collaborative and accommodating.

“That’s Just How Things Work Around Here”

There’s a strange asymmetry here.

Organizational norms are themselves the accumulated byproduct, or sediment, of people’s behavior. Behavior shapes the rivulets and channels water passes through. But once those behaviors become established, they often get depersonalized into “that’s just how things work around here.” The norms become part of the environment, seemingly detached from any particular individual.

Anyone who benefits from those norms, or contributes to them unconsciously, gets to point to the channels as if they were simply features of the landscape. “That’s the way water flows!”

The person adapting to that environment, however, is treated very individually. They need to read the room, adjust their style, develop better judgment, learn the context-appropriate form of “executive presence,” or learn how to operate in the culture. The behavior that created the context becomes invisible, while the behavior required to adapt to it becomes a personal competency and burden.

Various academic and scientific traditions address this head-on:

• Institutionalization (Peter Berger, Thomas Luckmann, Lynne Zucker): repeated human practices can eventually become taken-for-granted features of social reality.

• Organizational culture (Edgar Schein, Joanne Martin): assumptions and ways of working can become so embedded that people experience them as simply “how things are done.”

• Privilege and social dominance (Jim Sidanius, Felicia Pratto): dominant groups and their ways of operating can become treated as the unmarked, “normal” case.

The burden does not fall evenly. It often falls most heavily on people who are underrepresented twice over: underrepresented in the immediate environment they are trying to navigate and underrepresented more broadly in the profession or industry. They may have fewer people around them whose default ways of speaking, leading, disagreeing, or making decisions resemble their own. So they are asked to do more of the adapting while having less power to define what counts as normal in the first place.

Courage!

The dynamic shows up when leaders throw around words like courage, discipline, “bias to action,” or ownership. These sound like relatively context-free virtues. Who wants to argue against any of those things?

But in practice, organizations don’t reward courage, discipline, action, or ownership in the abstract. They reward particular expressions of them. In one company, courage might mean challenging the CEO in a meeting. In another, the exact same behavior might register as disrespect, poor judgment, or an inability to read the room. In one company, ownership might mean making the decision and moving without waiting for permission. In another, doing that might get you feedback that you failed to bring people along.

Courage becomes speaking up in this particular way. Ownership becomes taking charge in this particular way. Discipline becomes persisting in this particular way. Bias to action becomes moving at this particular speed, with this particular amount of consultation.

If that particular expression maps neatly to how you already behave, it becomes very easy to experience the virtue and your preferred expression of the virtue as the same thing. Now someone new shows up. We think we are evaluating whether someone possesses a virtue, but we may actually be evaluating whether their expression of that virtue is culturally legible to us.

Conclusion

If we actually want to work better with people, it isn’t enough to understand personality, skills, or values in the abstract, yours or theirs. We have to understand how those things show up in distinct contexts and how the context we’re operating in changes what gets expressed.

It helps to understand your own or someone else’s general tendencies. But for team building, it may be even more useful to understand the contextual factors that bring out different versions of that core.

• What kinds of situations cause you or them to switch modes?

• What are you or they noticing in those situations that someone else might not notice?

• What assumptions are you or they making about risk, authority, fairness, reversibility, or responsibility?

The goal isn’t to abandon the idea that people have relatively stable tendencies. It’s to understand that those tendencies are expressed through context. Knowing your own or someone else’s “type” may tell you something about a center of gravity or area of inertia. Knowing the conditions that pull you or them away from that center may tell you much more about what it will actually be like to work together.

I recently started a new job, which means I’m spending a lot of my time trying to figure out how everything works: the product, the workflows, the history, the people, the artifacts, and all the context that everyone else has accumulated over time. So instead of trying to turn that experience into a neat argument, I thought I’d just write down what one of those days actually feels like.

8:30. Kid-school tornado is over. Second cup of coffee.

I’m building an elaborate “subway map” with stops, lines, and transfer points to wrap my head around a product. Certain stops can share lines, lines can loop, and transfer points let you “transfer” information, artifacts, handoffs, outputs, etc. I also have to account for the different humans and roles on these journeys, the signals that indicate whether different steps are working, and the various decision points.

Imagine a customer journey map turned into a subway system.

Why am I doing this? To make sense of things. To ponder what “end-to-end” actually looks like. To figure out how to pressure-test whether the whole experience fits together.

Will I keep it? Will anyone ever look at it? Who knows.

Customer call.

These sensemaking artifacts always outnumber tickets 8:1 in my world. Try to graft them onto tickets as labels or references, and it always feels disconnected. And one artifact is never enough. I always end up with journeys, a bunch of different map types, docs, atomic insights, metrics, one-pagers, goals, “Jobs,” and principles.

I take a couple of minutes to convert the subway map into a set of tables in Notion, on the off chance that I *do* want to do something with it. OK. That’s pretty effective. It would have taken me a while to set all of that up before. Notion’s AI makes it easy.

Must resist…

Must resist…

Step away from turning Notion into a subway system tool.

Meeting saves the day.

In addition to the subway map, I have a big list of tagged artifacts, lists of data sources and how they connect to the various subway stops, “screens,” and other access points (e.g., MCP, chat in other workbenches). Oh, and I have meeting transcripts, notes, Miro boards, videos of usability tests, and [insert 10 other artifact types].

And the product/experience itself, of course.

One puzzle, since I’m new at a job, is figuring out what is “still valid.”

Do these notes still make sense? Has the customer’s business changed? Is this an AI summary, or did someone actually fret over every word? Sometimes it’s easy to tell. Sometimes it isn’t. Is this definitive and pressure-tested? Does it represent any sort of convergence? Or did everyone glance over the doc and go about their day?

Anyone who has been around for a while probably has a ton of implicit knowledge about the situation floating around in their head. We have a couple of context-sharing sessions, with me furiously taking notes. Extremely helpful! The rest is me doing archaeology, trying to “connect the dots.”

I’m using AI the whole time, but for some reason nothing comes out great. I ask questions across all of these artifacts, and the answers are meh. They point me toward helpful things, but it’s very hard to tell which artifacts are “live” — continuously updated and reflecting current understanding — versus relics and cave drawings.

I’m worried about building shared understanding on top of eroded shared understanding. Or, worse, glossy, coherent-sounding, but ultimately wrong understanding.

I go back to building my subway artifact. There’s a tactile quality to it that I find calming. I can’t rush it.

I feel tempted to let Notion move it forward…

Tempted….

My willpower drops, and I pull the trigger:

“Oh hey, you have information about a lot of other workflows. Can you add the next couple of lines to my subway map?”

UNDO. UNDO. UNDO.

Meeting saves the day.

I can’t explain all the details, but I have to use PowerPoint for the first time in a lot of years. I used to work at a PowerPoint factory at an investment bank on the graveyard shift.

I don’t recognize PowerPoint anymore. I futz around with some AI features that don’t seem to work. I just want to paste without formatting.

Getting hungry.

Lunch (aka “Should I order Door Dash”).

I jump over to Linear and find that the tickets aren’t much good. I mean, they’re perfectly good for what they’re good for, but they aren’t designed for someone parachuting in with very little context. I think to myself, “this is how it should be.”

And then to the code. The code, at least, is definitive. It *is* what’s in production. So that’s helpful. If I want to know what this thing DOES and how it actually works, I’m not too far off.

I play around with AMP for a bit. It seems super powerful.

Some meetings.

More PowerPoint.

More subway system building.

Hear about the Miro acquisition. Miro is one of my favorite ways to work with people.

Some reflections….

You don’t appreciate the power of context until you’re new somewhere. But you ALSO appreciate the active nature of *creating* context through exploration instead of having it spoon-fed to you through a three-times-removed AI Slop Cascade.

I feel alive just trying to make sense of things.

At every step of the way, I find myself wishing someone had more time to work with me to forge even more powerful context.

It’s interesting: 10 minutes with AI can feel super-expansive in its breadth and its ability to answer questions, but it doesn’t have the same flavor as 10 minutes with a new coworker who has a ton of implicit context.

I can certainly see the power and potential of AI, and I enjoy using it in Notion. I haven’t really used AI inside a product like that before. But one thing sticks with me: I see a lot of Notion marketing around context, but I don’t think they’re hyping the act of context *creation and preservation* enough. I hear people talk about a context “battleground,” but it all feels vaguely reminiscent of how people used to talk about knowledge repositories, sources of truth, connected data, etc.

In other words: one part of the equation, and the death of many knowledge-management efforts.

I also catch myself, on a couple of occasions, fantasizing about “connecting” all of my thinking into a “brain.” But I’m quickly reminded that context starts eroding the second the day is over. Some things stay durable, but a lot of it changes subtly.

So that brain needs more information.

My brain is tired.

My book co-author sends me a text to check something out.

I do a walk-and-talk and have AI summarize my reply.

Shoot, I forget the “JUST SUMMARIZE” skill.

Redo.

End of day.

Have you ever felt like a complete weirdo in your company? Like there are only a handful of people who “get you”? Or have you gone to a conference and gotten a little confused because suddenly it seems like you have a lot more in common with everyone? Then you return to work, and somehow the weirdness comes back.

You may be less alone than you think.

One mistake we make is assuming that because an organization has certain rules, and because a handful of high-profile people seem to behave a certain way (and everyone seems to visibly go along with it), that there simply aren’t many people like us there.

Organizations can be more diverse in belief than they appear to be in behavior. What you see is not simply “what people here believe.” You’re seeing at least three things layered together:

1. Power-weighted norms, where some ways of behaving carry much greater institutional force and consequence than others.

2. How people adapt to that environment: what they say, suppress, emphasize, tolerate, and avoid in order to operate effectively within it.

3. The actual people underneath, who may hold a much wider range of beliefs, values, preferences, and ideas about how work should happen.

The key is that we mostly observe #2, attribute it to #3, and underestimate the influence of #1.

Leaders influence what gets rewarded, promoted, tolerated, and interpreted as “leadership material” and “good performance.” People adapt accordingly. That visible adaptation can then look like widespread agreement with the norms themselves.

This can create a reinforcement loop. People see others behaving according to the apparent norm and reasonably infer that those people believe in it. Their own adaptation then becomes another data point suggesting the same thing.

A relatively narrow set of norms can start to look like “what everyone here believes.”

But adaptation is not the same thing as endorsement.

People can have very different reasons and go to highly varying ends to play the part their work demands. They may be optimizing for belonging, safety, ambition, professionalism, coordination, or simply making it through the day. It is easy to see this as inauthentic, but the behavior is visible.

Leaders are adapting too: to expectations from above, peers, boards, investors, customers, and inherited ideas about what leadership is supposed to look like. The fact that someone is rewarded for performing a norm does not mean the norm reflects what they would naturally prefer, or even what they privately believe.

And there’s another factor: a lot of things need to fall into place for people at work to reveal certain beliefs.

• Some of it is luck: you happened to run into each other in the right setting.

• Some of it is time: enough time to create trust and dig into each other’s perspectives.

• And some of it is context: the right conversation, problem, relationship, or moment has to create an opening for that part of the person to actually show up.

Consider how many teams you’ve been on where it took quarters or even years to learn the why behind a certain quirk.

Social media has a similar norming effect. A relatively small, highly visible subset of people can make certain beliefs and behaviors appear far more common than they actually are. We observe what gets surfaced, mistake visibility for prevalence, and adjust accordingly. And some norms simply feel safer to perform than others.

LinkedIn is especially interesting here because we are still, in many ways, at work. People are visible to colleagues, managers, customers, future employers, and professional peers. So what gets expressed is shaped not only by what people believe, but by what feels professionally legible, rewarded, and low-risk.

That can make a narrow set of “safe” workplace beliefs look even more universal than they are.

In closing…

We encounter only a tiny sample of what the people around us think and believe. It is very easy to mistake what has been revealed to us for all that is there.

There may be far more “weirdos” around you than you realize.

For various reasons, it is normal to meet a couple of trusted people who really get you in your company. But you can’t let that convince you they’re the only ones.

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.