I read it twice.

The first time, I was nodding. The history lesson is genuinely good. The diagnosis of hierarchy as an information bottleneck is accurate. And the vision of a “world model” that maintains a continuously updated picture of the entire business, replacing layers of status meetings and alignment rituals? Anyone who’s ever sat through a three-hour quarterly review wondering who this was actually for will feel the pull.

The second time, I started counting assumptions. I ran out of fingers.

The pitch

Dorsey’s argument goes like this: humans can effectively manage three to eight people. This biological limit forces organizations to add coordination layers. Each layer slows information. AI removes the constraint by maintaining a shared model of business state that everyone can access directly. Result: fewer managers, more builders, faster decisions. Yay!

He proposes three roles. Individual contributors who build. Directly Responsible Individuals who own problems that span multiple teams for defined periods. Player-coaches who develop people while still building. No pure managers. The world model handles alignment. And pigs might fly.

If you’ve spent any time in an organization larger than a dozen people, you feel the appeal. The layers, the alignment meetings, the translated-twice-before-it-reaches-you version of a decision someone made three weeks ago. All real friction and all worth reducing.

But reducing friction and removing the people who manage friction are different operations.

Why everyone hates middle management (and why they’re wrong)

I don’t know when middle management became the villain of every organizational redesign. We show up in every consulting deck as the “layer to eliminate.” Every new model, from Holacracy to AI world models, starts with the same premise: the problem is the people in the middle.

I’m in the middle. Let me tell you what the middle actually does.

We translate strategy into work and work into strategy. We absorb pressure from above so teams can focus. We absorb frustration from below so leadership hears what's actually going on, not the version that got cleaned up on the way up. We are, in the most literal sense, the shit shovelers. The people who handle what nobody else wants to touch: the difficult conversation, the impossible deadline negotiation, the moment when the plan falls apart and someone has to figure out what happens next.

DDI surveyed 11,000 leaders across 50 countries. Trust in immediate managers dropped from 46% to 29% between 2022 and 2025. A 37% decline. Forty percent of leaders have considered quitting. Seventy-one percent report heightened stress. And frontline leaders are three times more likely than senior executives to have concerns about AI.

The people closest to the work are the most stressed, the least trusted, and the most worried about what’s coming. And the organizational response is: let’s remove their roles.

We all know how the Flat Earth theory ended. Flat orgs are heading the same way, just with better branding.

Flat org, meet Flat Earth

Every five years or so, someone announces a better way to organize humans. Holacracy at Zappos. Squads at Spotify. No managers at Valve. Each experiment started with genuine insight and ended the same way: when you strip out the visible structure, you strip out the map. What replaces it is informal, unaccountable, and works for people who already know everyone. The people who already know who actually calls the shots adapt fine. Everyone else is guessing. Ever heard of the cool kids club? It’s real.

Dorsey’s DRI model sounds great on paper. Own a problem that spans multiple teams for 90 days, pull whatever resources you need. But who picks the problems? Who decides the scope? Who steps in when 90 days isn’t enough? Those are hierarchy decisions. They just lost the job title that made them visible.

I’ve lived through what happens when “flat” and “empowered” become excuses to stop communicating.

Years back we tried the “every team is an island” approach once. Autonomous. Self-directed. No cross-team dependencies to slow anyone down. It took a couple of weeks before one team shipped a change that broke the system downstream, and the other team spent a Friday afternoon troubleshooting with we haven’t changed anything, what the hell happened?

Within a month the teams were on us vs. them terms. We had to undo the islands. Rebuild the bridges. Make sure people crossed paths, in Slack, in person, in whatever worked. Because it turns out we were part of a living, connected system, and pretending otherwise just meant the surprises were bigger and the blame was louder.

I’ve also seen team members find out about features they’d have to sell, by accident, because the empowered team building it didn’t think to tell anyone before shipping. These were the same people who thought keeping others in the loop meant asking for permission — which, if you think about it for more than five seconds, is a bit silly. Empowerment favors action. Less so communication. So they shipped fast, almost in secrecy, so no one could slow them down. Then complained that marketing had no materials and sales had no pitch.

The popular take is that hierarchy is the obstacle and flattening is progress. The hierarchy you removed is the hierarchy you can’t see. You didn’t eliminate power dynamics, just made them harder to challenge.

Now add agents to the mix

This is where it gets interesting, and by interesting, I mean nobody is prepared for this.

The conversation about AI and organizations splits neatly into two camps. Camp one: AI eliminates jobs (FOMO, rush to deploy, keep buying tools that don’t work yet). Camp two: AI augments jobs (it’s just a tool, relax, nothing will change). Neither camp is talking about the specific, practical, Monday morning reality of managing teams that include both humans and AI agents.

Your team now includes contributors that never get tired, never push back, and never tell you when you’re wrong. See the problem?

An agent can generate 80% of a deliverable before your human engineer has finished scoping the edge cases. The agent’s output looks complete. It passes tests. It even has comments. What it doesn’t have is context about why the third endpoint was deliberately left slow, or that the product team changed direction in a hallway conversation yesterday.

Now imagine the reality most of us actually work in. A codebase with ten thousand lines built over years, without documented decisions about why anything was done the way it was. If you’re lucky only half the people who wrote it aren’t at the company anymore. Exception on workaround on exception, with some good practices... and then more exceptions, because sometimes customer value first, stability later.

An agent will build its own understanding of that code. It might, at some point, revert the fix you shipped last week for a critical production issue and in worst case commit straight to master without hesitation. Because from the agent’s perspective, why not? It doesn’t know the backstory. It isn’t always good at following instructions. And nobody told it that particular line of code was load-bearing in a way that doesn’t show up in tests.

Meanwhile, the humans on your team are watching. The engineer who used to be your strongest contributor at their core task is now slower than an agent at that same task. Their value hasn’t decreased. Judgment, institutional knowledge, the ability to read the room and flag something the spec missed. All still critical. But their confidence has taken a hit because the visible measure of contribution, the thing they built their identity around, isn’t special anymore.

HBR published an article with research findings on what happens when AI provides confident but incorrect information: it creates “trust ambiguity.” People stop trusting the AI and start distrusting each other’s use of it. The team fragments. Nobody agreed on how much to trust it, and now nobody trusts each other’s judgment either.

And it’s not just the ICs. Now that leaders have AI tools too, they brainstorm with agents, get excited about the output, and send over two sentences of high-level instruction with “the details are in the linked Claude chat.” No useful context. No evaluation of whether this even makes sense. No pause to ask the agent what could go wrong or why might this not work. Before, they’d come to the team for input. Now they arrive with a solution the agent designed without knowing anything about our codebase, our constraints, or the three times we already tried this. Just vibes, a link, and an encouraging “Just do it!” Helping the team think, apparently.

This is happening now, in real organizations, by real leaders who used to ask their teams for input before making decisions. Is this the new reality? Maybe. But the trust ambiguity isn’t just about agent output anymore. It’s about whether your boss ran the idea past a human before they ran it past you.

This is where Dorsey's "world model handles alignment" falls apart. The world model can track velocity, customer metrics, system health. What it can't track is your best engineer getting a little quieter every week, because he's been flagging the same risks for months, nobody's picking it up, and the only questions he gets are "how fast?" and "why not faster?" It can't see the reluctance to make hard calls when you know no one has your back if it goes wrong. It won't notice that the work has quietly stopped being the kind anyone would put on a CV. It tracks the work., but it sure misses the people doing it.

The stuff that isn’t machine-readable

People are not rational agents who write everything down, communicate clearly, and follow the optimal path. Sometimes they’re tired. They run out of energy, will, or both. They don’t want to write documentation. They skip the standup because they’ve got nothing to show yet and don’t want to say that out loud. They avoid the hard conversation because it’s Thursday afternoon and they’ve already had three that week. And other times they’re on fire. Full of ideas, moving fast, shipping things, and the last thing they want is to slow down and write it up. Let’s just build! They’ll document it later. (They won’t.)

There’s a name for this kind of environment. Jamais Cascio calls it BANI: Brittle, Anxious, Nonlinear, Incomprehensible. It replaced VUCA, which described the environment from the outside. BANI describes how it feels from the inside. That’s not a strategic framework. That’s a regular day at the office.

Dorsey’s model is optimized for a world that isn’t BANI. It assumes the system is comprehensible, that causation is linear, and that the structure is resilient. BANI says: your system is brittle, your people are anxious, causation is nonlinear, and some of what’s happening is genuinely incomprehensible. Not temporarily unclear. It doesn’t fit in a model. Period.

Cascio himself said something that stuck with me: define the purpose, not the path. He calls it “flexive intent.” Get everyone pointed at the same thing, then let them figure out how to get there. Which is really just admitting that control was always an illusion. But someone still has to hold the purpose steady when the path keeps changing. Someone has to notice when the team has gone quiet. Someone has to do something about it. That’s my job.

So what do I actually do with this

Leadership theorists have a name for the archetype they think will thrive in BANI environments: the Futurecaster. Visionary, agile, innovative, relational, resilient. It reads well in a keynote abstract.

Now try selling that to a team that’s been through three strategic pivots in 18 months, watched half their colleagues get laid off, and has a leadership team that oscillates between we need to adopt AI yesterday and actually, let’s wait for Q3 to decide. Your team isn’t hungry for another vision. They’re hungry for someone who will stop changing the plan every time a CEO publishes a blog post.

Your VP is going to keep forwarding the latest AI hype article with thoughts? attached. The C-suite is going to keep chasing every shiny tool that promises 10x productivity. That’s not malice. That’s leadership FOMO, and it’s everywhere right now. You can’t change the people above you. You can change how you absorb what they send down.

So the competencies that matter aren’t new. They’re old competencies applied to a context that didn’t exist 18 months ago.

Cognitive flexibility is the World Economic Forum’s polite way of saying: you need to hold two contradictory ideas at breakfast and still make a decision by lunch. In practice, it looks like switching between “evaluate this agent’s output for subtle errors” and “support this human who feels their role is disappearing” in the same hour. Holding “hierarchy can be oppressive” and “hierarchy can be clarifying” at the same time, and knowing which one is true right now, for this team, for this decision. I started building this by spending time in rooms where people think differently than I do. Sitting in on sales calls when my background is engineering. Joining product discussions for the platform my team supports. Cognitive flexibility grows from problems shaped differently than the ones you’re used to. No workshop replicates that.

Emotional resilience, and beyond it, anti-fragility. Resilience is surviving stress and returning to baseline. Anti-fragility is getting stronger because of it. Your humans are anxious about the agents. The agents produce without caring about the anxiety they generate. You sit in the middle, absorbing the tension so the team can function. Nobody wrote a job description for this. You’re doing it anyway.

What I’ve learned is that vulnerability is what makes this work. When I started saying “I don’t have a playbook for human-agent team dynamics, we’re figuring this out together,” the team didn’t lose confidence. They stopped pretending they had it figured out, too. And that’s when we started actually solving problems instead of performing competence at each other. I’ve been on teams where the leader was the last to know something was going wrong. It’s never because the team didn’t see it. It’s because nobody thought telling the leader would change anything.

Sensemaking. Nobody talks about this one enough. AI has made it easier to generate options, strategies, and recommendations. It has not made it easier to determine what matters. The shift I keep coming back to: it’s not “what should we do” anymore. It’s “what’s actually happening here.” Without it, more information just creates confusion. Teams get stuck in debate mode. Executives reverse decisions. Meetings multiply. You’ve seen this week. I’ve started forcing precision before action: what decision are we actually making? What are the constraints? What are we explicitly choosing not to do? Boring questions. But the teams that ask them consistently spend less time undoing decisions nobody remembers making.

The fortitude to embrace calculated risk means deploying agent-generated work you can’t fully verify, accepting that your team will make mistakes in a category of failure that didn’t exist before, and owning outcomes you didn’t directly produce. Inc. reported that AI implementations fail because executives deploy without addressing the operational, cultural, and governance stuff first. The technology usually works fine. Everything around it doesn’t.

There’s a name for the two sides of this: FOMO (racing to adopt) and FOMI (fear of massive implosion from deploying recklessly). Nearly 94% of C-suite executives report dissatisfaction with their AI solutions, and their response is to buy more AI solutions. That anxiety rolls downhill. By the time it reaches your team, the excitement has curdled into exhaustion. So you make the call anyway. Keep the blast radius small. Be honest when something breaks.

Some weeks I feel like a sponge for organizational FOMO. Every day, another signal that everything is about to change. Another article forwarded, another tool to evaluate, another have you seen what X company is doing with AI? I have to be careful not to get sucked in myself. Because it’s easy. The excitement is real, the pressure is real, and falling behind feels like a thing that could actually happen to you. But if I pass all of that through to the team unfiltered, they don’t get motivated. They get whiplash. So I translate instead. This is what it means for us. This is what changes. This is what stays the same. Some days, translating is the only useful thing I do.

The WEF says 70% of job skills will change by 2030. That’s probably true. But it doesn’t mean 70% of what makes you good at your job will become irrelevant. The technical surface changes. The human part stays. Judgment, trust-building, the ability to hold contradiction, the courage to make a call when the data is incomplete. Those don’t have a half-life. They compound.

The futurecaster isn’t someone who sees the future. It’s someone who holds the team together while the future arrives in unpredictable, nonlinear, incomprehensible bursts. That’s a middle management skill. Always has been.

Where Dorsey is right

I don’t want to be unfair. The post identifies a real problem. Layers of human coordination do slow information. AI can compress that overhead. The “world model” concept, a continuously updated shared picture of business state, is genuinely useful. If your organization’s primary bottleneck is information routing, AI coordination will help.

And honestly? Parts of Dorsey’s vision would make my job easier. A system that automatically surfaces upcoming changes, pulls relevant context from scattered Slack threads and private channels, sends reminders about releases before they surprise the team next door. I’d take that. Right now, too much information lives in the heads of a few people or buried in channels most of the org doesn’t even know exist. If AI can make that visible, that’s not replacing middle management. That’s giving us better tools to do the work we’re already doing.

But most organizations I’ve worked in aren’t primarily bottlenecked by information routing. They’re bottlenecked by decision avoidance, because the system rewards not deciding over deciding wrong, and by the gap between what leadership says and what the operating system actually does. Those aren’t information problems. They’re human problems. And human problems don’t get solved by replacing the humans with a model.

The competency future leaders need has nothing to do with thriving without hierarchy. Build structures honest enough to be challenged and flexible enough to handle what’s coming. And then say, clearly and out loud: this is new, I don’t have it figured out, and we’re going to build the answer together.

That won’t fit in a world model. But it might fit in a team.

A few weeks later, same leader. You pull him aside and tell him he hurt someone on your team. He doesn’t see it coming.

“Why doesn’t anyone say anything to me?”

You said something. He heard the words. He didn’t hear what you meant.

They do say something. They say it to you. You bring it to him. He listens, nods, and explains why it doesn’t count. They hadn’t said it to him directly.

What’s missing from that framing: most people won’t say it directly. Not because they have nothing to say, but because walking up to a leader you don’t have a relationship with, especially one who isn’t even yours. One who doesn’t ask. One who doesn’t make it easy. That takes guts. A bit of recklessness, even. And with someone who gets defensive the moment feedback lands and will spend the next ten minutes convincing you that you’re wrong about how you feel, most people do the math quickly. It’s not that they’re afraid. They just don’t see the point.

So they say it sideways. To you. In feedback forms where nobody asks about a leader who doesn’t manage them. The message reaches him only when someone like you carries it — and even then, it doesn’t always count.

But maybe you’ve also been the leader nobody said it to directly.

He is not unique. This particular blind spot is more common than anyone admits out loud. I've worked with enough leaders to know that most of them aren't malicious. They're just not looking. They're focused on the work, on the output, on what's wrong and how to fix it, and somewhere in that focus they stopped noticing what their mood does to the people around them. Their team feels it. Other teams feel it. Sometimes the whole company feels it. And yet nobody hands them a mirror.

The walk-in

A textbook example of such a leader: smart, direct, usually right about the things he cares about. He also has a walk-in that can ruin a morning before anyone has opened a laptop. He doesn’t mean to. It comes naturally.

Barely a hello. An expression that says he’s already rendered a verdict about something and you probably won’t like it. Someone asks him something: short answer, all business, maybe an eye-roll for good measure. The team reads all of this before he’s sat down. They adjust. Conversations get a little more careful. Someone decides not to bring up the thing they were going to bring up. A difficult question gets postponed to next week. Not today. Nobody says why.

This is weather. The team didn’t cause this. They can’t fix it. They just have to live in it for the rest of the day. And he has no idea. Which is actually the worst version of this. At least if you know you’re doing it, you can do something about it. This is the kind where the leader goes home thinking it was a perfectly normal day.

It’s not just the walk-in. It’s the tone when he asks a question. The grimace he doesn’t know he’s making. The way a “just curious” lands like an interrogation. The person sitting across from him can feel that something is already decided. He goes from zero to shark the moment he senses something is off. Not aggressive exactly, just circling, jaw slightly open, and everyone in the room can feel it. He’s not asking to understand. He’s asking to find the inconsistency. His radar doesn’t much care whether it’s intentional or just someone who didn’t have all the information.

I’ve seen people freeze in those moments. Not because they don’t have an answer, but because they can smell the agenda, and they know that whatever they say, it’s already going to land inside a conclusion that was drawn before the conversation started.

Judgment day, every week

The format that does the most damage is the one that’s supposed to do the most good: the one-on-one.

The pattern is always the same. The leader points out what’s not working, tells people what they need to improve, and genuinely believes they’re doing them a favor. When you ask if that’s all they do in these sessions, the surprise is always real. “What? Should I say when they do something right? Because that’s obvious.”

It is not obvious. Not even a little.

I know what it feels like to dread a one-on-one with someone who runs it this way. There was a time in my career when I had a session every week with a superior who worked the same way. Every time I walked in, I felt like I was at the dentist. Not a routine check-up, the kind where they pull something out without anesthesia. You sit down, you brace, you get through it, and then you spend the rest of the day trying to remember why you liked your job.

I eventually said something, because that’s what I do. My manager was willing to work with me on it. We renegotiated how those sessions would go, and they became useful for both of us. I’m grateful for that. Maybe I was lucky. Not every manager takes that conversation well.

But I keep telling my team the same thing: you don’t know until you try. Prepare, give the feedback, brace for the aftermath. If the sessions already feel like the dentist, how much worse can it get? Open heart surgery, maybe. But unlikely. Maybe it’s a cultural thing. Maybe it’s a personality thing. But the cost of staying quiet is almost always higher than the cost of a conversation you actually prepared for.

Not everyone gets there. And when they don’t, something shifts after enough of these sessions. Remember that childhood game where the floor is lava and you have to cross the room without touching it? Same principle here, just different consequences. Certain topics become lava. Booking time with them becomes lava. The conversation that should happen gets rerouted through someone else, or dropped entirely. The next meeting runs unusually smooth. Nobody raises anything. The leader thinks: good, we’re aligned. No complaints. Progress.

They’re not aligned. They’re just waiting for it to be over.

When every one-on-one feels like judgment day, people stop performing for the work. They tell you what they think you want to hear. They don’t raise the thing that might open a conversation they’re not ready for. And you, sitting across from them, think you’re getting the full picture. You’re not. They’re in self-preservation mode.

You’re getting the edited version. Produced specifically for this room.

No relationship, no landing

The reason people end up in self-preservation mode is almost always the same… Some leaders confuse being frank with being blunt and wear it like a badge. No-nonsense. No-bullshit. Straight shooter. Great brand. Terrible weather. What they don’t see are the corpses they leave behind.

The difference: being direct means saying what you mean. Being blunt means not caring how it lands. Harsh, impolite, regardless of feelings, sometimes crossing into insensitive or outright rude.

Say someone hits a problem during implementation and has to bring bad news: something will take longer than expected, or they discovered an issue that changes the plan.

The direct version: “Okay, how bad is it? What do we need to fix it?” The person feels like they surfaced a problem.
The blunt version: “How did you not catch this earlier? This should have been flagged in planning.” The person feels like they are the problem.

You can have an opinion. You can give feedback, even the difficult kind. But you don’t get to skip straight to that without building something first.

Feedback without relationship lands as attack. Not because the feedback is wrong (it might be completely right) but because the person on the receiving end has no evidence yet that you want good for them. Without that evidence, the brain doesn’t process it as input. It processes it as threat. Some people will push back and set a limit. Most will go quiet, wait for it to be over, and start growing a resentment that, after a while, stops being resentment and becomes a resignation letter.

The relationship is the prerequisite — and I know, because I’ve had to build one before telling a leader that his feedback style was driving people away. He listened. And then: “Fine. I’ll never ask another question.” Or: “Fine. I’ll stop giving feedback altogether.”

He listened, but he didn’t hear me. What landed was stop, not differently. He knows feedback is valuable. He just can’t yet see that the delivery is what determines whether it lands… or detonates.

Some days you are the hydrant

I am not a neutral observer in any of this. I’ve had to learn versions of this too.

Some days I am the dog. Some days I am the hydrant.

On the hydrant days, I tell my team: today is not the best day to challenge me, I need focus and I need information fast. I don’t want sympathy, but if I’m normally high-energy and then go suddenly quiet, the team notices. And if I don’t say anything, they’ll assume it’s them. It’s not. It’s just weather under active management. Letting them know that keeps them safe, spares me some apologies, and gives us something to laugh about the next day.

On the dog days, there’s banter, there’s a bit of chaos, and that’s also fine, because that’s how you know the relationship you have with them can absorb both.

Not hiding your emotions isn’t the same as dumping them on people. I’m frustrated about the timeline, not about your work. I’m having a rough day, bear with me. Simple sentences. They give people information instead of making them guess. And when people aren’t guessing, they’re working. Which is what we want.

What I haven’t fully made peace with yet is where that control ends.

What I cannot do — no matter how good I get at this — is fully protect my team from someone else’s weather. You can be as transparent as you want about your own state. You can coach your team to name what’s happening, to give feedback when something isn’t okay, to set their own limits. You can remind them that if they say nothing, the other person will assume everything is fine. And sometimes the weather still comes in from somewhere you’re not standing. You notice it before they say anything: someone quieter than usual, an energy that wasn’t there yesterday. Sometimes they come to you. Sometimes you just watch it land and know exactly where it came from.

My instinct is always to get between them and it. But that’s not how empowered teams work. My job isn’t to be the umbrella forever. It’s to make sure they know how to hold one.

Weather forecast

Why are people too sensitive?

Why doesn’t anyone say anything?

The answer to the second is in the first. They stay quiet because they don’t see the point. And then one day, quietly, they do, just not to you. You get the resignation, not the conversation.

Feedback is only valuable if it lands, and it doesn’t land because the message is good. It lands if there is trust. That trust isn’t given. It’s built, slowly, in all the moments before the hard conversation: in the walk-in, in the one-on-one, in whether you showed someone their feelings were real. None of that is soft. It’s the only part that gets feedback through the door.

Weather isn’t always dramatic. Sometimes it’s just a look and a short answer. But the team is reading the forecast either way.

My brain was three steps ahead before I’d finished reading the message. Not in the good way. I had a list of problems forming. Integration complexity. Scope creep. Dependencies nobody had mapped yet. Who inherits the maintenance when the excitement wears off. I know this movie.

I got to about seven reasons before I caught myself.

Counted to ten. Closed Slack. Said to myself: not today, Satan.

Let it play out. Don’t shut it down before it starts. I’ve done this before. Walked into a conversation already holding a verdict I formed in the time it took to read a subject line.

I deliberately caught myself. A couple of weeks earlier, my superior called me a pessimist. Not the first time. Most likely not the last. But this time it sent me down a rabbit hole: why does he see me that way when I know I’m not? I did some research. What I found made me pause this time with the Slack notification.

If I’m the pessimist in this story, he’s the opposite. The endless optimist. The visionary. Almost every time I raise potential problems, it triggers him. Every time he doesn’t acknowledge what I’m seeing, it triggers me. Two people who genuinely want the same thing, unable to hear each other.

The remark made me defensive in a way I hadn’t expected. I’m not a pessimist. I believe in the projects we’re doing. When I raise issues, I’m not trying to kill the idea. I’m trying to catch what will hurt us before it does, approach things from a better angle, think them through before the problems become crises.

That’s not pessimism. Is it?

The label stuck with me. Why does he see it that way? While doing the research, a different question started forming: when do we need the dark side and when do we need the bright side? In ourselves, in the people around us. When is the pessimist’s checklist the right tool, and when is it the thing getting in our way?

I came across a piece by Rishikesh Ranjan that pushed me further into it.

When not knowing is the superpower (and its tab)

Ranjan writes about George Dantzig, a PhD student who showed up late to a statistics lecture at Berkeley in 1939. Two problems were on the board. He assumed they were homework, copied them down, and handed in solutions a few days later with an apology that they had seemed a little harder than usual.

They weren’t homework. They were unsolved theorems that had stumped the field for years.

Ranjan puts it well: “Naivety is the amplifier. Optimism or pessimism is the signal it amplifies.” An unskilled person who doesn’t know what they don’t know produces noise. A skilled person who temporarily sets aside what they know about why something shouldn’t work? That’s where breakthroughs come from.

I hadn’t heard the story before. And I wish it were always that clean.

You build it, it works, it ships. Then real life happens. Problems surface. Edge cases multiply. The thing that seemed impossible to break starts breaking. The other mode kicks in: safety, not making it worse, keeping the lights on. The people doing that work are rarely the ones who built the thing.

Someone pays that tab eventually. Usually not the optimists who ran it up.

Nothing wrong with either side. You need both. If you’re a leader, the job is making sure they don’t end up hating each other.

There’s a concept in Zen Buddhism called shoshin, beginner’s mind. It gets romanticized. Usually interpreted as: act like you know nothing. That’s not it. Shoshin is a deliberate choice to re-enter a familiar domain with openness and curiosity. Not the ignorance of a beginner. The humility of someone who knows enough to realize they might be wrong.

Marc Benioff does a version of this at Salesforce. Each year he runs a blank-slate exercise, questioning every assumption about the business as if seeing it for the first time. He’s learned that expertise, left unchecked, calcifies.

Benioff does it deliberately. Dantzig did it by accident. Shoshin is what it looks like when you choose it.

Two camps, and why they need each other but drive each other insane

A pessimist and an optimist walk into a bar. Err... an office. They have to deliver a project. This is where the joke ends and real life starts. They’re representatives of two types involved in every project. I’ll exaggerate.

Camp one: “Everything’s possible. Let’s not think about problems. Let’s just do it.”

Camp two: “Okay, what can go wrong? What trapped us last time? Which problems will we inherit from doing this new thing?”

These two groups often can’t understand each other. Camp one reads camp two as pessimists, people who think everything will fall apart, who find a problem in every direction. Camp two reads camp one as reckless, or worse: they can afford to be optimistic because they won’t be the ones fixing what breaks.

Both reads are wrong. Each camp is right about itself and wrong about the other. Camp one isn’t reckless. Camp two isn’t obstructive. They’re built for different phases of the same project.

Writing this reminded me of Good Omens, Terry Pratchett and Neil Gaiman’s book (and TV series, both worth your time). An angel who isn’t all good and a demon who isn’t all bad. The end of the world is looming and they have to stop it together. Neither could do it alone.

Pessimists vs optimists? Same thing. Slightly lower stakes than the apocalypse.

I’m usually in the second camp. Btw. the pessimist label wasn’t the only one I’ve heard in the past. I’ve also been told I’m looking for excuses not to build. That one stung. Because it was so untrue. From the inside, I was asking the right questions: do we need this, what problems will this create, are we solving the right thing? From the outside, it looked like putting obstacles in the way. The same question sounds like rigor or obstruction depending entirely on who’s hearing it and what phase the project is in.

No, I’m not a pessimist. But I do have an operational mind. I’ve built things from scratch, probably more than people assume. But I’ve also been part of the team that gets called when something someone else built starts leaking, needs maintaining, or breaks in ways nobody planned for. Years of that will do something for you.

There’s a name for what most of us are actually doing every day: defensive pessimism. Not a personality trait. A deliberate coping strategy: you set low expectations, run through scenarios of what could go wrong, and prepare for the outcomes you’re dreading. The fire you’ll need to fight. The dependency nobody mapped. The scope that will quietly double.

Done right, it lowers your anxiety, helps you handle what actually breaks, and builds acceptance of whatever the outcome is. Taken too far, it increases anxiety, convinces you the failure is so inevitable there’s no point trying, and (this one hits close to home) creates friction with people who find it hard to be around someone always bracing for impact.

The last one sounds familiar. Not a personality clash. A strategy clash.

Julie Norem’s research gave me something I hadn’t expected: evidence that the mode works. She studied two groups: strategic optimists, who prepared by imagining success and staying positive; and defensive pessimists, who prepared by mentally rehearsing everything that could go wrong.

Both groups performed at roughly the same level.

The 30% gap in their predictions (pessimists expected worse, optimists expected better) collapsed to near-zero at the point of actual performance. More striking: when researchers gave defensive pessimists cheerful, encouraging feedback before the task (”You’re going to do great! Don’t worry!”), their performance dropped by 29%. The cheerful coaching didn’t help them. It sabotaged them. Their anxiety wasn’t a bug. It was the mechanism they used to prepare.

The problem isn’t optimism or pessimism. Early planning needs the bright side to get started. Deeper planning needs the dark side, but not all of it. Execution needs both.

The anxiety tax on expertise

There’s a cost to knowing things. The more you understand about how a system can fail, the higher the threshold for action. Sometimes so high you never actually start.

I’ve seen this with experienced engineers. They know the edge cases. They’ve been burned by the migration that corrupted production data, and the API that changed without warning. Every scar makes the next decision heavier. They can see all the ways it might go wrong.

Startup mythology loves to celebrate the opposite. Evan Spiegel at 21. Zuckerberg at 19. The Collison brothers in their early twenties. The narrative: youth and inexperience are advantages. And sometimes they are, not because young founders know less, but because they haven’t accumulated enough failure patterns to trigger the anxiety tax.

The data tells a different story. The NBER’s 2018 study found the average age of top-performing founders is 45. Experience predicts higher success rates on average. The teenage prodigies are survivorship-bias highlights (we only hear about the ones who made it), not the pattern. Both deserve airtime. Although only one gets the magazine covers.

Whenever someone has a brain fart (an idea that’s arrived before it’s been thought through), I go quiet. The checklist starts. Have we thought about this angle? What problems are we creating three projects from now? Who inherits this? I hate repeating mistakes. What I hate more is when other people repeat theirs and I have to clean up after them. I’ve become (and no leadership book has ever put it this way) a professional shit shoveler. Someone whose job has repeatedly involved dealing with what other people’s enthusiasm left behind. One of my previous teams made it official: they called it “General of Shit Shoveling” mode, gave me a badge, and stood by my side as a small shit shoveling army. It was funny. Gallows humor, but also accurate.

How does shit shoveling start? Usually with a project that has real potential and not enough hard questions asked upfront.

A project gets proposed. The people behind it dismiss the complexity, wave off the timeline, treat the hard parts as solvable later. Not afraid. Collaborative. Creative. Those are real strengths, and I mean that sincerely.

Then the project starts. Reality shows up. What was manageable becomes the most critical thing in the building. People get pulled in without context. Another thing breaks. The pressure compounds because the runway was shorter than anyone admitted. Nobody likes solving shitty problems with artificial urgency created by ignoring reality for too long. Hence the badge.

I can see it coming from a mile away. I’ll say something. I’ll nudge, warn, coordinate. Sometimes it doesn’t matter. The shit arrives on schedule regardless. At some point you just put the badge on.

Seeing it coming isn’t intuition. It’s systems thinking.

Systems thinking is what gives you the map. Once you understand how a system works, every new proposal arrives with ripples attached. Some good. Some less good. Some neutral until they become someone’s problem two projects later. The system will have to change anyway. Not the issue. The question is whether you’re changing it with your eyes open. Not pessimism. It’s seeing things as they are: complex and intertwined.

You can’t just turn this mode off. It doesn’t respond to “just be more positive.” It took years to build and it exists for real reasons. Putting it down, even temporarily, even when you need to, takes actual energy. Not a mindset shift. It’s a skill. But a skill worth learning.

Not today, Satan (reprise)

Dantzig solved those theorems because he didn’t know they were impossible. He was a PhD mathematician working at the edge of the field and the accidental ignorance just removed the ceiling. A good example of how not knowing a constraint can sometimes be exactly what solves the problem. And a note for those of us with more scars than average: maybe stop whispering “this can’t be done” before someone else has had a chance to find out for themselves. Who knows, maybe they’ll find a way nobody has before them.

You can’t reproduce that accident. You can’t unknow what you know. But you can choose when to use it.

Back to that Slack notification. This is why I set it down. I still saw the problems. I’ll probably still be right about most of them. But I recognized that wasn’t the moment for that particular skill. The problems will get their turn. The checklist will come out. Just not before the thing has had a chance to breathe.

There’s a time and a place for the pessimist, and a time and a place for the optimist. Most people know which camp they’re in. Fewer know when to step aside.

The visionary will probably still get triggered the next time I raise a problem. So will I when he doesn’t acknowledge what I’m seeing. But now I understand what we’re actually arguing about. And that changes what I can do about it.

I can’t shake it. Possibly because of a small, entirely reasonable crush on James McAvoy. Mostly because of the line.

I’m approaching two decades of working with engineering teams. For most of it, the answer to the question of what I’d accomplished felt natural: we solved this, we shipped that, we got through that rough quarter together. I was proud of that. I still am.

But the closer I got to where decisions actually get made, the more often I got a slightly different flavor of the question. Not "What did the team do?", because that part was obvious, and I couldn't take credit for it anyway, but more like "What did you do, specifically?" Gulp.

I never prioritized myself — not really. Company first, team second, me somewhere after that. More than once I set aside my own goals so someone on the team could grow into the opportunity instead. I judged it the right call for them and for the company. Still do.

There’s a difference between putting others first and not having an answer for yourself. Especially when you want to grow. When someone is deciding whether to give you more scope, more responsibility, more trust, “we did this together” stops being enough.

It’s possible to have a real answer to that question, even when most of your work shows up in other people’s outcomes. Not instead of helping others. Alongside.

Those two things can coexist. They should. But they don’t by default.

Looking back, I didn’t log the decisions, the things I prevented, the fires nobody saw coming. But I’m doing it now, and this is part of my system: written down so the next version of me, and future generations if they still have a need for this kind of thing, have a slightly shorter path. Dear future me, you’re welcome in advance.

How you earn it

Some people who are building informal influence don’t realize they’re doing it, because they’re too busy doing it.

So here’s what it looks like.

You’re getting CCed on decisions that technically aren’t yours. Usually not because someone was being inclusive, but because your opinion has proven useful enough that leaving you out started to feel like a risk.

People are running things by you before the meeting. “I wanted your read on this before we bring it to the team.” Not from politeness. They trust you. Someone decided the conversation would be better with your input already in it.

You’re getting pulled into rooms you weren’t invited to. The room needed something you have: context, a question nobody else thought to ask, the ability to slow things down in the right moment.

Newer people find their way to you with questions that aren’t technically yours to answer. It has nothing to do with the title, believe me. You don’t make them feel stupid for not knowing yet.

If two or three of these are happening, you’re already building something real.

So how do you build it? It starts with being genuinely useful. People come to you because you have answers, or because you’ll think alongside them until they find one. You give them a different angle on a business problem. You’re willing to brainstorm, to be a sparring partner, regardless of whether you’re their manager or not. You don’t mind sending the Slack message to someone on a different team, a different office, jumping on a Zoom call to loop them in or share something useful. You go to them. You don’t wait to be asked.

And when someone comes to you with something you can’t solve, you don’t turn them away. You think about who actually can help, and you give them the next step, the next person. It takes your time. It doesn’t always scale. But this is how social credits get built.

At a certain point (director level and beyond) the mode shifts from being helpful to being an accelerant. You run informal alignment sessions before the formal decision meeting, so when everyone sits down, rough consensus already exists. You take ownership of a cross-team dependency and just start coordinating it, without waiting to be assigned. You write the proposal, call the meeting, make it easy for people to say yes. You convene rather than direct.

You also learn to escalate strategically, not as a sign of failure, but as a tool. “I want to move forward on X. Here’s where I need a decision or alignment.” Clear, non-political, keeps things moving without making them a battle.

And momentum on anything significant almost always starts the same way: two or three peers who are bought in before it goes anywhere formal.

And at some point, you’ll see the return. A team that’s already swamped will find a way to help you, not because they have to, but because of the relationship. Someone who is usually guarded, entrenched, will sit down and actually think with you. You’ll be called the glue. You’ll be the one who points out the “us versus them” framing in the room and says, out loud, that you’re the same company working toward the same goals, even when it’s uncomfortable, even when looking away would be so much easier. People will listen. None of it required a title.

Building for one (a fair one)

Making other people successful is a genuinely good career strategy, not a consolation prize for people who didn’t want a title anyway.

When you help someone get promoted, you have an ally with more reach. Mentor a junior engineer who becomes senior and you’ve got someone you trust on every team they join. Unblock a stuck PM and the goodwill comes back in ways you can’t predict.

But — and this is the note to self part — none of that exempts you from also building something for yourself. Something fair. Something you’d be proud of.

The higher you go, the less this is optional. At some point someone will ask, in a promotion conversation, in an interview, in a room where your name is on the table. Not what you enabled. What you did.

I’d been so oriented outward for so long that my own trajectory had gotten quiet. Not gone. Just... quiet.

I could describe in detail what everyone I was mentoring wanted to get better at over the next six months. When someone asked me the same question about myself, I had to think longer than I expected.

Crisis? No. Mere information.

What I figured out: treat your own development as a commitment, not a leftover. One goal, protected time, the same level of intention you’d give to someone you were mentoring. Enough to know whether you’re actually moving toward something, or just moving.

You’re not less generous for having a direction, the two don’t compete.

This is especially tricky when you lead engineering teams. You’re not directly responsible for adoption or new sign-ups. That lives in product. You can’t count lines of code, and it wouldn’t mean anything if you did. So you have to be more deliberate: what is your actual contribution to the business? Quality of what the team ships? Their ability to move fast without creating debt downstream? Fewer incidents? A team that didn’t exist six months ago and now can?

Those are the right questions. I stopped asking what I owned and started asking which ones I was in. Once I did, the contribution was more visible. What it still needed was a record: written down before the details dissolved into “we did a lot of good work that quarter.”

Keep a Captain’s Log

Leading without authority is hard to prove by design. You didn’t ship the feature; you unblocked the three teams that did. You didn’t make the decision; you were the reason the worse one didn’t get made. You didn’t build the culture; you kept it from eroding during the reorg. You got business and tech speaking the same language. You cleared the obstacle nobody else had the standing to clear. You put out a fire that would have cost six weeks. You kept a person from leaving quietly.

All real. None of it appears anywhere unless you write it down.

Start a log — a Captain’s Log, if you want to be nerdy about it. Build it inside your own personal operating system: a simple structure of folders and markdown files, easy to create and maintain, tool and OS agnostic, and readable by any AI you point at it. One file per day, one file per week, whatever works. One entry per thing that would otherwise disappear from your memory.

“Clarified technical constraints for PM, saved a week of misaligned work.”
“Pushed back on the architecture approach before the review. Team reconsidered.”
“Advocated for [person] in the reorg discussion. Their scope was preserved.”

This isn’t a brag sheet or a LinkedIn content calendar. Just notes, so that when someone eventually asks what you’ve been doing, the answer comes with actual examples and not a vague gesture at things you half-remember.

The invisible org chart reflects real influence. It just won’t speak for itself in the room where formal decisions get made. That part’s on you.

A habit beats a retrospective every time. Nobody reconstructs eighteen months of invisible work the night before it matters. You can’t remember what the team did, let alone what your part in it was. You either kept the log or you’re improvising. Improvising is how you end up saying “we did a lot of good things” when someone needs to hear what you did specifically.

With AI it’s easier now than it’s ever been. A quick daily check-in, a few minutes, and you get a different angle on what happened and where your contribution actually was, without the guilt of claiming credit, because you’re not claiming it. You’re just seeing it clearly.

I built a system to do exactly this: analyze the log, surface the patterns, build a record over time. The raw notes stay private: unfiltered, honest, not written for an audience. But out of that stream of words and thoughts, AI can extract what matters, summarize it, categorize it, shape it into something I can actually use for a yearly review, a promotion conversation, or just to stay oriented on where I’ve been and where I’m going.

It’s also how I stay disciplined: daily and weekly review built into the system. I’m not using it as evidence of being busy, but as a material to look at critically. What am I actually producing? What needs to change? The log isn’t only a record. It’s a feedback loop.

It’s same logic as investing: start early, stay consistent, let it compound. But it’s not too late to start today. With AI making this a five-minute daily habit, there are no excuses left.

At the end of a day, a week, or a role, I want to be able to look back and actually see what I built. Not just what survived in the memories of team members and myself. Some things stick, but a lot gets forgotten. Smart people write things down.

I need to be the first one who’s proud of what I’ve done. That matters, independent of whatever anyone else decides it’s worth.

What the f*** have you done lately?

When the time comes, imagine James looking straight at you.

A promotion conversation. A job search. Or eventually, someone who loves you asking what you spent all those years doing.

He’s not asking about your promotion. He’s asking what you actually did: with the time you had, with the people you worked with, in the third of your life you handed to a company.

Did you make the people around you better? Did you make the place worth spending that time in? Did you move anything, even slightly, in a direction that mattered?

The Captain’s Log isn’t only evidence for a performance review. It’s how you know your own answer. Not the polished one. The real one. The one you can look at and say: I was paying attention. I knew what I was doing and why.

So when the question comes — and it will — you don’t have to guess.

Instead I ended up standing outside the meeting room sulking. We never even got to my ask. Somewhere in the preamble I’d lost them, and I didn’t see it coming.

What happened?

The test

If someone only heard your first sentence in a meeting, would they understand why you’re talking?

Most engineers fail this test. Not because they lack clarity of thought, quite the opposite. Because they’ve been trained to start with context instead of the point. You know this pattern, don’t you? You’ve probably done it yourself. I know I have.

Engineer starts speaking. Background first, then more background, then some data, and finally the thing that actually matters. By which point, the PM is mentally reviewing their inbox and the exec has already moved to the next meeting in their head.

Leadership doesn’t want to hear the story of Frodo going to Mordor and back. They want to know: did he throw the ring in the pit? If not, why not, what’s the plan, and does he need resources to sort it out?

The first sentence should answer one question: why are we talking about this?

First sentences that pass the test:

“This feature will take 6 weeks, not 2.”

“This deployment will break mobile clients unless we coordinate the rollout.”

“We need three more engineers or we’re missing the deadline.”

Compare with how engineers actually start these conversations:

“So, yesterday I was working on the authentication service and ran into some issues with the session handling...”

“I wanted to talk about the roadmap and some of the complexity we’ve been discovering as we dig into the requirements...”

“There’s been some discussion about the deployment process and coordination with other teams...”

These openings don’t tell you anything. They promise that eventually you’ll get to something important. Maybe. If the meeting doesn’t run over.

So this isn’t a listening problem, but a communication structure problem.

Two languages, one room

I started thinking about this after reading First Minute for a book club, a book that formalizes the whole problem into a structure. Turns out the pattern is common enough to warrant its own book. Which means you’re not uniquely bad at this. You’re just doing what everyone does. Maybe not after reading this.

Engineers communicate the way engineers communicate. Thorough. Sequential. Everything on the table before you reach the conclusion. That’s not a flaw, it’s what makes you good at building systems, writing design docs, reviewing code.

But leadership operates on different constraints. Less time. More context switches. They’re not reading your design doc. They’re in a meeting with ten other things pulling for their attention. Their default is conclusion-first. Bottom line up front. What do you need and why.

Two different languages. Both internally consistent. Neither wrong. And yet here we are.

The problem is when you use the engineer language in a leadership context. Context-first works when someone chooses to read your work, they can skim ahead, reread, control the pace. Documentation, design docs, pull requests: all fine there.

It fails in real-time conversations.

When you start with context in a meeting, people don’t know where you’re going or why they should care. Are you raising a problem? Proposing a solution? Just providing an update? By the time you arrive at the conclusion, you’ve lost most of them.

But changing this is hard. Starting with the conclusion feels risky. That’s an assertiveness problem as much as a structure problem.

The situations can be simple stuff:

• Should we attend this conference?

• Should we give a talk there?

• Should we even have this meeting?

Sometimes it’s bigger: should we spend a quarter on refactoring and ship no features?

I’ve been shut down in both. And lived to tell the tale, obviously.

Imagine you’re about to propose something you know will get pushback. Something that challenges the current direction, asks for resources people don’t want to give, or requires a change nobody asked for.

The instinct: build up to it. You might reason: if they understand the reasoning first, they’ll follow me to the conclusion. If I lead with the conclusion and they might just say no with a snap decision, case closed, no fair hearing. At least with context I give myself a chance to be understood.

The logic is understandable. It’s also backwards.

You’re not giving them context so they’ll understand, you’re hoping context will function as pre-agreement. Unfortunately, they’re not tracking your reasoning step by step, building toward your conclusion with you. They’re waiting. And by the time you get there, they’ve been waiting long enough that the attention is somewhere else.

Even if you give them all the context in advance, they’re still going to challenge. Context-first just means the challenge comes after you’ve already lost half the room.

This plays out in individual conversations. But the bigger cost is what it does over time.

The reputation you don’t know you’re building

Some people believe communication doesn’t actually matter and that if you’re good enough, the work speaks for itself. That you get promoted on technical merit alone. It can happen, just maybe not to you or when you’d like it to happen... or never.

The higher you go, the better you need to be at communicating. Not just technically. With leadership, across teams, with people on other teams who don’t share your context. There are exceptions — engineers who got to senior levels on pure technical output — but they’re rare enough that betting your career on being one is essentially playing the lottery.

Unless you feel lucky, it’s easier and better to work on the communication.

This pattern of going context-first doesn’t just make you less effective in the moment. It damages your credibility over time.

Over half your work time is spent communicating, verbally, in writing, in meetings. Every one of those interactions leaves an impression: it shapes how people see you, your credibility, your judgment, your potential. Believe it or not, poor communication is one of the major gates to promotion, especially into leadership. Not technical gaps. Not bad judgment. Communication.

You’re building a reputation in every meeting. The question is what kind.

When you consistently bury your point, people stop listening to your openings. They know you’re going to take a while to get there, so they tune out until you do. Except now you have to work even harder to get their attention back, and sometimes you never do.

The cruel part? You walk out of the meeting without what you came for. You were the most prepared person in the room, you brought the data, did the analysis and came up with the recommendation. You still got ignored.

Structure undermines you before you get to the point. The language you use once you’re there is its own problem.

Same information, different order

Start with the conclusion, then back it up.

“We’re going to miss the launch by three weeks. We’ve finished 60% of the work with 40% of the time left. I looked at three options: cut scope, bring in more people, or push the date. Here’s what I recommend and why...”

The problem lands in the first sentence. Data follows. Recommendation after that.

This isn’t dumbing it down. If they want to dig in, the frame is already there. If they agree, you’ve saved everyone five minutes of preamble.

The exception (there is one)

Sometimes you do need to establish context before the point. When the audience doesn’t have the background knowledge to understand the conclusion or when the problem is so unexpected that leading with it would be confusing.

Knowing how much context to give requires knowing your audience, especially what they already know, what decisions they’re focused on, what’s actually on their mind when you walk in. That’s a different skill, and it starts before the meeting.

Ask yourself: does the context enable understanding, or is it just preamble?

We went through this when we wanted to replace our in-house authentication with a third-party identity provider. For months we’d been struggling to get resources to implement SSO. Other providers already had it built in. We were slowly losing ground every time a potential customer asked about single sign-on and we had to explain why we didn’t support it.

We couldn’t walk in and say “we’re bringing in a third-party authentication provider, it costs money, kthxbye.”

That conclusion without context would have landed as an unnecessary expense. The reaction would have been: why do we need this when we already have something that works?

One sentence of context changed the frame: “We’ve been losing enterprise deals because we don’t support SSO, and building it in-house would take six months. Here’s what I recommend.”

Same conclusion. One sentence of setup. Completely different reception. Context is one sentence, not three paragraphs.

Next time try this: cut your opening and start with your second sentence. Would anything of value be lost? If not, there you go. Drop it.

Before and after

Before your next meeting, write down your first sentence. Does it contain the point, or does it contain setup?

If it’s setup, put the conclusion first. If someone only heard that sentence, would they know why you’re talking? If yes, you’re done. If no, try again.

This feels unnatural at first. You’ll feel like you’re being too direct, too blunt, like you’re skipping important information. You’re not. You’re putting the important information first. The rest is still there, you’re just not making people wait through setup to get to it.

Standup: “Login is broken in staging. I’m fixing it now, should be done by noon.” Not: “Yesterday I was working on authentication and ran into some issues with the session handling that I’m still debugging.”

Architecture review: instead of opening with “I’ve been looking at our infrastructure and thinking about how we handle growth,” you open with “Our current setup breaks at 5x our current load. We need to fix it before Q3.” Everything else follows from that.

Stakeholder update: “We’re two weeks behind schedule because the API keeps changing.” Not: “There have been some challenges with the integration work and coordination with the backend team.”

I’ve been in every one of these meetings. On both sides... and caught myself jumping in and cutting engineers off to get to the point faster. Not good. I stopped, I decided to coach them instead.

Here’s a thought: If you’re already using AI tools for code and emails, you can use AI for this too. Paste what you’re about to say, ask it to restructure it conclusion-first. Takes thirty seconds.

Say the thing

When you’re about to speak, stop. What’s the one thing others need to know? Start there.

Your first sentence is not a warm-up, an introduction, or context for the thing you’re about to say. It is your point. Say it.

Most of us fail the test because we think communication is about being thorough. It’s not. You can be completely thorough and still get ignored. Being thorough means you covered everything. Nobody said they were listening.

Now the tough question: what are you optimizing for, being right or being heard?

why I shouldn’t

that.

why I shouldn’t.

You feel the urgency. You start pushing.

And then one of two things happens.

Nothing moves.

Or worse: you become the problem in someone else’s narrative.

I’ve been both versions. The complainer more than once. Partly because I’ve always believed you can always do something. Small, partial, imperfect. But something. That belief is mostly useful. It’s also the thing that keeps you pushing long after the evidence suggests you should stop.

There’s a particular version of this I recognize. You’ve read about groupthink. You know the value of the devil’s advocate, of the person who names what the room won’t name. You know that lone dissenters have sometimes been on the right side of history. Ruth Bader Ginsburg spent years writing opinions for audiences that didn’t exist yet. So you feel equipped. Maybe even a little proud to be the one pointing at the thing that is obviously broken and could so easily be fixed.

Oh man.

As Skunk Anansie put it: it takes blood and guts to be this cool, but I’m still just a cliché.

Wait, what?

Then I read The Fifth Discipline by Peter Senge. It’s about building learning organizations, about developing the collective capacity to solve problems, with systems thinking at the core. If you haven’t figured that out by now: yes, I am a fan of systems thinking.

There was this quote on change and how one person rarely changes things...

Wait, what?

I was always proud of my courage to say things as they are. And now I’m the complainer? What the hell?!

So I went back through my own experience anyway. The attempts that went nowhere and the ones that actually moved something. Oh yes, I noticed the pattern.

One person raising a concern is a complaint. Two people raising the same concern independently is a pattern. Three people is something an organization has to reckon with.

This isn’t about volume. Bringing twelve people to a meeting to validate your concern doesn’t make it more legitimate. It makes you look like you’ve been running a campaign. And organizations that feel organized against tend to get defensive, not reflective.

The number matters because of what it represents: independent confirmation. Three people who arrived at the same diagnosis through different paths, with different contexts, without coordinating their stories. That’s not one person’s frustration amplified, but a pattern. And patterns deserve attention.

Up is the wrong direction

If I got a dollar every time I went to my manager to seek support and address the problem, I’d be rich by now. And most likely wouldn’t be writing this essay. Remember the complainer from the previous section? Yep. That was me.

When the wall of nothing-moving appears, the intuitive response is to escalate. Go to your manager. Frame the problem carefully. Prepare the case. Ask for support.

You get nodding heads in the meeting. Nodding heads, by the way, often mean I want this conversation to end more than I’m going to do something about this. Two weeks later, nothing has changed.

Escalating up this way rarely works, and for a reason nobody states directly: asking your manager to fix a problem that exists on their watch requires them to acknowledge that something is wrong on their watch. That’s a harder ask than it looks. It’s not that managers are dishonest or defensive. It’s that validating a systemic concern implicates them in having missed it, allowed it, or failed to address it. The higher up you take it, the higher the implicit cost of saying yes, this is real.

So the system gives you a polite nod and moves on. Your concern is noted.

After enough of those conversations, you start reading the signs differently. You learn when to keep pushing and when to step back, regroup, and wait. For a better moment. Or another person who’s been watching the same pattern from a different seat.

Building sideways is different. Finding peers who share the diagnosis doesn’t threaten anyone. You’re not asking someone to admit a failure. You’re discovering that two people independently arrived at the same place, from different starting points. Nobody has to lose face. Nobody has to own a problem they didn’t see coming.

Upward convincing requires the other person to give something up. Peer-building doesn’t.

Most leaders get stuck because they keep trying the move that feels most direct. Escalate, make the case, repeat with better framing. When the more effective move is lateral. Find the people who already see it.

The quiet signals

It doesn’t look like a formal coalition. No manifesto. No document. No Slack channel called #fix-this-org-dysfunction. It’s quieter than that.

You’re noticing who names the same problems in different rooms. Who uses the same language to describe a dynamic, without knowing you’ve been using it. Who brings up the same topic in 1:1s that you’ve been circling around in yours.

Then there’s a subtler one. Who stays after the meeting to say what they didn’t say in it.

The things people say in the hallway after a meeting ends or in a Slack DM ten minutes later, on the walk back from the meeting room, those are often the things they actually believe. They didn’t say them in the meeting for reasons that made sense to them: the power dynamics weren’t right, they didn’t want to be the first one to name it, they’ve learned that certain observations land badly in certain rooms.

When someone says a version of what you’ve been thinking, in a context where they had no reason to know you were thinking it, that’s your second witness.

You don’t recruit them. You just confirm: “I’ve noticed that too.” And then you listen to where the conversation goes.

It’s a small thing. It doesn’t feel small.

Ask who has tried to fix the same thing before you arrived. Ask what’s been tried before, not to catalog the failures, but to find the people who cared enough to try. Those are your people. They already see it. They just stopped trying alone.

When seeing isn’t doing

Sometimes you find the people. They see it. They’ll talk about it in 1:1s, in the hallway, in the meeting after the meeting. Plenty of people to talk about it with. But when it comes to actually making a move, most back out. Safety really is in numbers. They just don’t feel it that way. And you’re back to pushing alone, except now you know it’s not you, it’s the system. Fuel to your fire, baby!

I try to encourage the people I’ve found. Let’s try this. Let’s do that. It’s on us, we can do something here.

Sometimes it works. Sometimes it doesn’t. And I’ve had to make peace with that too. Not everyone is willing to throw themselves on a sword. That’s not a judgment. It’s a different calculation, and it deserves respect.

The wiggle

And sometimes you look and find no one.

You pay attention in 1:1s. You listen in retrospectives. You describe what you see without pushing your conclusion and wait to see if someone else completes the sentence. You notice who stays after meetings.

The coalition isn’t here.

Sometimes you’re genuinely alone, after genuinely looking. Maybe the coalition doesn’t exist here. Maybe you’re wrong about the problem. Both are worth knowing.

This isn’t giving up. It’s calibrating.

That same book gave me a framework to look back, not just forward. Why did some things shift quickly? Why did others take so long? In some of those cases, the coalition was already there. I just didn’t see it as one. I heard people talking about the same things, in the same frustrated tone, in different rooms. But I didn’t connect the dots. Didn’t think: these people and I could actually push on something together.

Before I can accept that “this is just how things are”, the questions start. Have I really done everything? Have I really tried every angle? Maybe there’s just one more thing. Maybe this one will tip things over. (There is always one more thing.)

I’ll wiggle and wiggle, not willing to let myself be dragged into the vortex of “not right.” And this can take days. Sometimes years.

And after all of that, I talk myself out of it altogether. Maybe this is just the way we do things here.

Or do we? (See?)

I still don’t know if that’s wisdom or stubbornness. Or both.

Small, specific, durable

When it does come together, the question becomes what to do with it.

The goal isn’t to change the company. It’s to change the conditions.

The changes that tend to hold aren’t the ones that required full organizational awakening or a mandate from above. They’re the ones where two or three people agreed on a small, specific problem and made a small, specific change that held up when no one was watching it.

Fix one meeting. One handoff. One decision-making process that currently happens in the wrong place with the wrong people. Small enough that it doesn’t require a mandate. Specific enough that you can tell if it worked. Durable enough that it survives when you’re not in the room.

Then do it again.

One percent at a time.

The coalition doesn’t need to be about changing the whole system. It needs to be about changing this thing, right here, with enough witnesses that the change is real and not just yours.

That’s often enough.

We were small. The team was mature (not necessarily super senior), self-organizing, accountable. Pure poetry. Empowerment wasn’t something we talked about, it just existed. I could step back, and things happened. Good things.

I loved being in that space.

A couple of years later, a different company. Bigger one. Different teams. Different maturity levels. Different leadership styles. Competing priorities. Time pressure. Multiple forces pulling in different directions.

The magic disappeared. Turns out “just do your magic” doesn’t scale with organizational complexity. No shit, Sherlock.

I’d still tell people: “You’re empowered. Feel empowered to say something, do something, make a decision.”

They nodded... and then they came back asking for approval on things I said they owned, stayed quiet about problems I thought they’d surface, or stopped making decisions entirely and just waited for me to weigh in.

I wondered: How is this possible? They’re not happy with how things are. Why aren’t they doing something about it?

Turns out, it was a systems problem disguised as a people problem.

Most leaders think empowerment is about giving autonomy. Let people make decisions, step back, trust the team. Boom, done.

Wrong.

Empowerment isn’t something you give.

It’s something you enable through four things most leaders skip: clarity about what good judgment actually looks like, trust that matches your behaviors to your words, calibration that knows when to step in and when to step back, and safety that makes it okay to be wrong, learn, and try again.

Most leaders don’t intentionally create these gaps. The patterns emerge, either from pressure, from old habits, from not realizing what needs to be made explicit. But the impact is the same: empowerment exists only on paper while your team goes through the motions, waiting for the real decision from you.

The key is noticing these patterns and understanding what’s actually happening.

The clarity gap: They can’t read your mind

People can’t exercise judgment in a vacuum. They need to know what you’re judging them on.

I’ve experienced this from both sides.

I remember a situation where I got a challenge to solve a problem: “get from A to Z”. I did it, found a way that worked, and delivered the solution. My manager was disappointed. I felt empowered until I figured out something was missing.

Turns out, he wanted me to go A, B, C, D through Z, not just get to Z. He had a specific approach in mind, but never told me I was being judged on how I got there, not just that I got there.

I thought I was solving for the outcome, but he was evaluating the process. You bet there was some tension and bad mood on both sides, but we talked it through afterward, and it was a good conversation.

I explained that I couldn’t read his mind, and despite years of leadership training, telepathy was never covered in any workshop. I didn’t know he had a specific path in mind. And at my level, I see multiple paths, multiple solutions. I chose the one that made sense given what I understood about the constraints and goals. Have I mentioned I’m used to being empowered?

We both realized he had two options going forward. Truly empower me to pick the path and trust my judgment, or be very specific upfront about his expectations so I could tell him whether I could meet them or not.

Either way works. What doesn’t work is vague empowerment followed by disappointment when I make a different choice.

We set clearer expectations after that conversation.

The situation above uncovered the clarity gap.

Most of the time the problem isn’t that your team lacks judgment. The problem is you haven’t defined what they’re being judged on.

Why “just do your magic” stops working

What used to be implicit in my small team had to become explicit in bigger, more complex organizations.

With my early team, shared context meant we all knew what magic looked like. In companies with competing priorities, cross-functional dependencies, and political considerations, I had to define it explicitly. When I didn’t, “just do your magic” became meaningless.

Once I started providing clarity - defining what good looked like, what constraints mattered, what decisions were theirs - the magic came back. It wasn’t about their capability. It was about giving them the context to use it.

But even with clarity, empowerment doesn’t always click immediately. At another company, the team had been told what to do for so long that when I said “you decide,” they froze like I’d asked them to defuse a bomb. Freedom without practice feels a lot like risk. They needed to learn how to be empowered, not just be given permission.

Clarity helps. But it’s not the only thing that matters.

Vague empowerment sounds like “You own this domain” or “You decide” (but you have unstated preferences).

People spend more energy guessing what you want than doing the work. They self-censor or over-escalate, make decisions you later walk back. Pure clarity failure.

Making the implicit explicit

Define what you’re optimizing for. What you can’t compromise. What “good enough” looks like.

Which decisions are theirs to make? Which need your input? Which need approval?

When speed conflicts with quality, which wins?

What are the hard boundaries they can’t cross?

This takes time. Feels like overhead. Feels like you’re over-explaining things that should be obvious.

Do it anyway. Your alternative is playing guessing games forever. Making implicit explicit is the foundation that makes empowerment possible.

Without it, “you’re empowered” means “good luck guessing what I actually wanted. I’ll let you know when you get it wrong.”

Empowerment isn’t “do whatever you want”

And don’t mistake empowerment for: “Do whatever you want, however you want, whenever you want, as long as we get results.”

Real empowerment needs boundaries, constraints, and expectations. It needs clarity about what success looks like, what’s off-limits, and when to involve others.

Without those, you don’t have empowered teams making good decisions. You have chaos pretending to be autonomy. Congratulations, you’ve created anarchy with a mission statement.

Real empowerment is freedom within clear boundaries.

You define the outcomes, the non-negotiables, the constraints, the decision rights.

Then you give people space to figure out how to deliver within those boundaries.

Vague freedom without structure is just stressful. People don’t know if they’re succeeding or failing, if they’re making the right calls or veering off-course. They’re constantly second-guessing because there’s no framework to guide their judgment.

So yes, empowerment requires clarity. But it also requires accepting that clarity includes boundaries, not just freedom.

The trust gap: Your micro-behaviors give you away

You told them they’re empowered... and then you checked their work.

They saw it. The act itself was not the problem, the problem was how it was done.

The trust gap isn’t what you say about empowerment. It’s what your behaviors reveal about whether you actually trust them.

I watched this happen to a senior engineer.

A senior stakeholder asked him for an estimate on a project: “You’re responsible for estimates on this. You’ve worked on similar things before. How much time will this take?”

The engineer gave his estimate. The leader didn’t like it, no surprise here, because it was too long.

Instead of asking about assumptions with an open mind, or exploring what was driving the timeline, he went task by task, challenging everything. Everything. Every hour, every detail and tried to shave off hours until the stakeholder was semi happy with the estimate. It was like being on a tribunal. He didn’t shave off any functionality, just pushing the engineer to commit to something he knew he won’t be able to pull through.

The engineer later told me it was one of the lowest moments for him.

“If you don’t trust me with my expertise, then why do you have me?”

That’s the question people ask themselves when you say they’re empowered but your behavior says otherwise.

People don’t need your permission to feel unempowered. They can see the gap between what you say and what you do.

The gap makes people go through the motions. They make “decisions” they know will get reviewed, while waiting for the real decision to come from you.

This creates a pattern where people stop exercising judgment and start waiting for direction.

Real trust means shipping their decision, not yours

Real trust means letting decisions stand even when you’d decide differently.

Not wrong decisions. Different decisions.

When someone makes a choice you wouldn’t make, you have to ask: “Is this wrong, or just different?”

If it’s different but defensible, ship it, publicly support it, and make your trust visible. If it’s wrong, make that a teaching moment, not a reversal.

The cost of real trust is accepting outcomes you didn’t choose.

The benefit? A team that actually exercises judgment.

Count how often you review, revise, or redirect work you said they owned. What does that number tell you about trust?

Challenge to learn, not to judge

It’s easy to say “I trust my team.”

It’s harder to trust them with your behavior.

The gap shows up in how you respond when they bring you ideas, decisions, or approaches.

Do you challenge to invite discussion, or to create defensiveness?

There’s a difference.

Inviting discussion sounds like:

• “Walk me through your thinking here.”

• “What tradeoffs did you consider?”

• “Help me understand why this approach over that one.”

Creating defensiveness sounds like:

• “Why would you do it that way?”

• “Did you think about [obvious thing]?”

• “That doesn’t make sense.”

The first approach signals trust in their thinking. The second signals doubt that they thought it through at all.

People can tell the difference.

When they bring you something and you challenge everything (not to understand, but to question whether they thought at all), they stop bringing you things.

They don’t trust that you trust them. Because you don’t.

And when trust erodes, so does engagement. So does motivation. So does agency.

You can say “I trust you” all day. Your micro-behaviors will tell them what’s actually true.

You can’t grant empowerment verbally

The gap between what you say and what they experience is where empowerment breaks down.

You can’t tell someone to feel empowered any more than you can tell them to “just be confident.” Empowerment isn’t granted through words—it’s created through systems, behaviors, and consistency.

Without clarity, trust, calibration, and safety backing up your words, “you’re empowered” becomes noise. They hear it. They don’t feel it. And the gap tells them everything.

Safety to be wrong

Trust without psychological safety is permission to succeed, but only if you don’t fail.

You can tell people they’re empowered, you can let decisions stand, but if they don’t feel safe being wrong, they won’t use the judgment you’re supposedly empowering.

I’ve watched this undermine empowerment more quietly than any other gap.

Someone makes a decision. It doesn’t go well. Not catastrophic, just not ideal. What happens next determines everything.

Remember that engineer with the estimates who got questioned behind his back? What did the team learn from watching that play out? Don’t give honest estimates. Give the number leadership wants to hear. Or pad everything because you’ll get questioned anyway. Or stop volunteering judgment entirely.

What it looks like when done right?

An engineer made a call to refactor a critical system during a feature release. It made sense technically but created timing risk. The release got delayed by a week. Not catastrophic, but not ideal.

The leader pulled them aside privately. Not to blame, but to understand: “Walk me through your thinking. What made this feel like the right call?” They explored the tradeoffs together. Turned out the engineer was optimizing for long-term stability but didn’t realize the business pressure on the timeline. Valid technical judgment, missing context.

The leader said: “Your instinct to fix this was right. Next time, let’s talk through timing tradeoffs before we commit. You still own this domain, and I want you to keep making these calls.”

Two months later, the same engineer faced a similar choice. This time they came to the leader first: “I think we should refactor this, but I know we’re under deadline pressure. Here’s the tradeoff. What do you think?”

They made the call together. The engineer learned. The leader stayed out of the way. That’s safety.

The team is watching what happens when someone gets it wrong. That tells them more about empowerment than anything you say.

When people feel like assets instead of humans

You can have perfect clarity. Calibrated involvement. Real trust in decision-making.

But if people feel invisible (or worse, like pieces you’re moving around a board), they stop bringing their thinking.

This shows up in small ways:

• Someone makes a good call. You don’t acknowledge it. They see it.

• Someone brings a thoughtful analysis. You skip past it to your own conclusion. They stop analyzing.

• Someone takes initiative. It goes well. Silence. They stop initiating.

• Someone raises a concern. You dismiss it. They stop raising concerns.

And it shows up in big ways:

• You talk about people as “resources” or “headcount” in front of them.

• You exclude them from decisions that affect their work.

• They can’t challenge your approach or your thinking.

• You treat their execution as valuable, but not their judgment.

You can repeat “be empowered” all day. If you don’t actually let them be empowered (if they’re excluded, dismissed, or talked about like assets to allocate), the words mean nothing. Nada. Diddly-squat.

What does it look like when someone feels their judgment matters?

An engineer raised a concern about the approach we were taking on a project. In a meeting, in front of the team. My first instinct was to defend the approach. We’d already decided, we were moving forward, raising this now felt like slowing us down.

I caught myself. Instead I said: “That’s a good question. Walk me through your concern.” They did. Turned out they saw a risk I’d missed. We adjusted the approach. I said in front of the team: “Thank you for pushing back on this. You saved us from a problem we would’ve hit later.”

What did the team learn? That challenging my thinking was valued, not tolerated.

Next meeting, someone else raised a concern. And another. We didn’t agree with all of them, but they kept bringing their thinking because they knew it mattered.

That’s what it looks like when people feel like thinking humans instead of managed assets.

What makes this real? Include people in decisions that affect their work before you’ve decided. Create space for them to challenge your approach, and actually listen when they do. Recognize good judgment out loud, not just outcomes. Ask for input before committing to direction.

Recognition isn’t a nice-to-have. It’s fuel.

When people feel their judgment matters, they bring more of it.
When they feel like managed assets, they shrink back to waiting for instructions.

When was the last time you explicitly recognized someone for good judgment, not just outcomes?

When empowerment breaks under pressure

I’ve watched this pattern repeat. Pressure arrives, empowerment disappears. A leader who normally steps back suddenly takes over, challenges everything, pushes their solution because it’s faster. The team notices and steps back.

One time, they might understand. But when it keeps happening, they learn the real rule: “You’re empowered... until things get interesting.”

That’s when empowerment becomes conditional, which isn’t empowerment at all.

And then there’s THE HERO move.

I touched upon heroes in one of my early essays, you might want to check it out.

Heroism comes in many forms, here are two of them: bringing in someone else to save the day, or doing it yourself. It feels like you’re helping, like you’re being a good leader by stepping in. You’re solving problems! You’re saving time! You’re also teaching your team that you’ll always take over when things get real, but that’s tomorrow’s problem. The pattern undermines what you’re trying to build.

What leadership actually looks like under pressure:

The team is struggling. Deadline’s tight. You can see the solution clearly, and it would be faster if you just took over.

Don’t.

Instead, ask: “What are you stuck on?” Listen to their answer. Often they’re not stuck on the problem—they’re stuck on a constraint they think exists, or missing one piece of context, or haven’t considered an option they don’t know is available.

Give them that piece. Not the solution, the piece they’re missing.

“You know we can push back on that deadline if needed, right?”
“Have you considered approaching it from this angle?”
“What if you didn’t have to worry about backward compatibility here?”

Then step back. Let them solve it.

If they’re truly stuck and time is running out, step in—but do it collaboratively. “I have an idea. Want to talk through it together?” Not “Let me just do it.” Work the problem together. Explain your thinking. Ask them to poke holes in it. Make it a learning moment, not a rescue.

Two examples:

A team was stuck on an architectural decision two days before a deadline. The leader could see the answer but asked instead: “What’s making this hard?”

The engineer said they were worried about scalability. The leader asked: “For the launch or long-term?” The engineer realized they were over-engineering for scale they wouldn’t need for months. They made a simpler call, shipped on time, and learned to ask that question themselves next time.

Another time, a team was genuinely stuck. The problem was harder than anyone realized. The leader stepped in but said: “Let’s work this together. I’ve seen something similar before. Tell me your constraints, I’ll tell you what I’m thinking, and we’ll figure out if my approach works here.”

They solved it together. The team learned. The leader didn’t become a dependency.

The hero gets short-term relief and long-term dependency. The coach gets short-term discomfort and long-term capability.

If you want real empowerment to survive pressure, protect it when it’s hardest. That’s the test: when it’s hard, not when it’s easy.

The calibration gap: Too much help, not enough help, never just right

Most leaders think empowerment is a scale from control to autonomy.

Less control = more empowerment.

Nope.

Both extremes prevent people from developing agency.

Too much control turns into micromanagement. People disengage because you don’t trust them.

Too little control turns into abandonment. People drown because you’re not providing the structure they need.

Effective empowerment isn’t maximum or minimum involvement. It’s right-sized involvement.

We leaders can miscalibrate both ways.

You won’t find this in your average empowerment advice book.

If team members have been fake-empowered for months or years (told they own things while every decision gets second-guessed), you can’t flip a switch one day and expect them to know what to do with real autonomy.

Without communication, trust erodes. When trust erodes, leaders pull back. When leaders pull back, people stop trying. A vicious circle.

You can set someone up for failure, then use that failure as proof that “people can’t handle empowerment.” Self-fulfilling prophecies are efficient that way.

A senior engineer was working on a very complex project. The leader thought: “He’s senior. He can handle everything.” Architectural decisions, writing the code, all the edge cases, dealing with the PM - all of it.

All good until it wasn’t. The project burned him to the ground.

Nobody checked in often enough with the technical challenges he was dealing with. He had to work in a new technology without much support from others. Then suddenly, after months of no pressure, came time pressure from senior management: this has to ship, ego in the game.

The engineer wasn’t used to this kind of freedom. He didn’t even want it. He felt abandoned, but he didn’t say anything. Asking for help felt like admitting weakness, like admitting he couldn’t handle it. He was introverted, kept everything inside, until it exploded.

The retrospective revealed he didn’t have good enough specifications, faced unreasonable expectations from the PM, and dealt with constant “Is it done yet? Is it done yet? Is it done yet?”

The leader thought this was empowerment. It was pure abandonment.

Senior title doesn’t mean someone wants - or is ready for - complete autonomy on a complex, high-pressure project with new technology and no support structure.

That’s not empowerment. That’s setting someone up to fail, then blaming them for it.

Right-sized involvement beats maximum or minimum

The goal isn’t to eliminate oversight. It’s about matching your involvement to the context.

I think about the person’s experience level, the task complexity, the risk level, and what breaks if this fails.

Junior engineers need more structure while staff engineers need strategic direction, not step-by-step guidance. Routine work gets less oversight, but novel problems need more collaboration. Low-stakes experiments get autonomy, while high-consequence decisions get structure. And I always ask: can we recover easily if this fails, or does this take down production?

Your involvement should change based on these factors:

• Tighter collaboration early in someone’s growth, more independence as competence proves out.

• More structure on high-risk decisions, less on low-stakes experiments.

• Clear check-in mechanisms (not approval gates, but visibility and support touchpoints).

• Explicit escalation paths (when to involve you, what triggers discussion, where to ask for help).

The goal isn’t to disappear. It’s to be useful.

Your team doesn’t want you to vanish. They want you to show up in the right ways, at the right times.

Hard enough to grow, safe enough to recover

Real empowerment means people can stretch without breaking.

When you calibrate involvement correctly, you create room for people to try things slightly beyond their current capability, with enough support that failure isn’t catastrophic.

This is where people actually grow.

Too much involvement leaves no room to fail safely. People can’t learn because you’re preventing mistakes before they happen.

Too little involvement lets failures become catastrophic. People lose confidence because they’re drowning, not stretching.

Right-sized involvement provides circumstances in which people can try, stumble, recover, and learn, with you close enough to prevent disaster but far enough to let them figure it out.

When someone’s learning something new, I learned not to prevent all mistakes. I had to make sure the mistakes they made were the kind they could learn from, not the kind that destroyed confidence or broke production.

Not everyone wants maximum autonomy

This is the part most empowerment advice misses.

Some people can’t function without high levels of autonomy. They need to drive decisions, own outcomes, shape direction. Take that away and they disengage. I’m one of those people. I’ve always been.

But not everyone is.

Some people want clarity, structure, and defined boundaries more than they want autonomy. They want to know exactly what’s expected, execute well, and not carry the weight of ambiguous decisions. That’s a preference, not a weakness.

The mistake leaders make? Treating empowerment as one-size-fits-all.

Giving too much autonomy to someone who wants structure creates anxiety, not freedom.

Giving too much structure to someone who needs autonomy creates frustration, not clarity.

Calibration isn’t just about experience level or task complexity. It’s also about what the person in front of you actually needs to do their best work.

Ask them. Don’t assume.

Some people will tell you: “I want more space to make calls.”

Others will tell you: “I need clearer direction on what you want.”

Both are valid. Both deserve respect.

The goal isn’t maximizing autonomy for everyone. It’s matching the level of autonomy to what makes each person effective.

What real empowerment looks like

Empowerment isn’t one thing. It’s four things working together:

Clarity: Your team knows what good judgment looks like because you’ve defined success, constraints, and decision rights explicitly.

Trust: Your behaviors match your words. When you say “you own it,” your actions prove you mean it.

Calibration: Knowing when to step in and when to step back, based on the person, the task, the risk.

Safety: People can be wrong, learn from it, and try again without fear of punishment or invisibility.

When all four exist, empowerment becomes real instead of just words.

People make decisions without guessing, exercise judgment without second-guessing, and know when to escalate versus when to move forward. They bring their thinking because it matters. They take initiative because failure is recoverable.

That’s when you stop being a bottleneck and start being a multiplier.

The empowerment audit you won’t want to take

So how do you know if you’re actually doing this?

This is the self-awareness part. You know, the uncomfortable bit where you realize you might be the problem. My favorite.

Most leaders genuinely believe they’re empowering their teams. The patterns I’ve described? They’re not obvious from the inside. They emerge gradually, shaped by pressure and habits and the complexity of the systems we work in.

The first step is noticing what you might not be seeing.

I built a quick self-assessment tool with Lovable to help you spot these gaps :

Start self-assessment on Empowerment

Where to start

Pick the gap that’s costing you the most right now.

Missing clarity? List the 10 most common decisions in your area. For each one, define who decides, what constraints apply, what success looks like. Then share it. Make it explicit instead of assuming it’s obvious.

Behaviors don’t match your words? Find one decision where someone chose differently than you would. If it’s not wrong, ship it. Publicly support it. Make your trust visible, not just stated.

Miscalibrated involvement? Map your team by experience level and current projects. For each person, ask what’s the right level of involvement. Check in more where needed, step back where you’re overcorrecting.

People don’t feel safe being wrong? Next time someone makes a recoverable mistake, have a private teaching conversation, not a public correction. Recognize someone for good judgment this week, not just outcomes. When someone brings bad news, notice your reaction and adjust it. Give someone who stumbled recently another shot at something similar.

I want a team so empowered, trusted, and supported that I can walk in with a business need or a problem and say: “Now do your magic.”

And they take it. Own it. Deliver it. And I’m proud of what they built.

That’s the dream.

But that dream has a lot underneath the surface.

It requires day-to-day communication that builds trust, difficult conversations when they’re needed, and support that flows both ways.

It means coaching through struggle instead of rescuing from it, being there for each other when things get hard, and solving things together.

It means not being too proud to ask for help, and not being too quick to jump in at the first sign of hesitancy. Sometimes people just need time to think things through.

“Just do your magic” still works. Turns out the magic was the systems we built along the way. (I had to. The setup was right there.)

But only when you’ve built the systems that make magic possible.

Start with one gap. Fix it. Build the foundation.

Then eventually magic can happen again.

Then someone raises their hand. Someone who doesn’t usually speak up in these meetings.

“Why are we splitting this service? The load is low. We don’t have the team size to maintain multiple deployments. This adds complexity we don’t need yet.”

The room goes quiet.

Lead engineer’s face shifts. Not angry, exactly. Just... tight. “We’re planning for scale. This is how you design systems properly.”

The questioner backs down. “Yeah, makes sense. Just wanted to understand.”

Meeting continues. Decision stands.

Later, the same lead engineer complains to you: “Nobody on this team challenges anything. They just agree with whatever I propose.”

The performance of openness

You’ve seen this movie before. I know I have.

Leader asks if there are any concerns in a meeting where everyone knows the answer is supposed to be no. Engineering manager invites pushback on a timeline they’ve already promised to stakeholders. It’s not openness. It’s theater.

Real challenge doesn’t feel like a smooth meeting where everyone nods thoughtfully and agrees all around. Real challenge creates friction. It slows things down, makes people uncomfortable, and almost always makes them defensive.

This is especially important now. Speed matters more than ever. We’re making decisions faster and faster. And when speed is the priority, we’re tempted to skip the challenge phase. Why slow things down with questions when we could just move forward?

Challenging slows things down temporarily, but it speeds them up in the longer run. You either spend an hour now finding the holes in the plan, or you spend three months later fixing what you built on a broken foundation. The question isn’t whether to challenge. It’s whether people are willing to make the short-term sacrifice of slowing down to get it right.

When someone objects that challenging is a waste of time, the response is simple: challenging things now is cheap. Changing the course of action later is very expensive.

If your open-to-feedback culture never produces tension, nobody’s actually challenging anything.

They’re performing agreement while privately thinking you’re wrong.

This cost me. I used to end meetings feeling great because everyone was aligned. Then I’d get Slack messages an hour later about concerns people didn’t raise in the room. Four messages from four people. None of whom said anything when it mattered.

Turns out I was running a very efficient pipeline: meeting to Slack to nowhere.

The meeting wasn’t open. It was a performance. And I was the director demanding everyone stick to the script.

Real dissent isn’t polite

Real challenge doesn’t sound like interesting perspective, let me play devil’s advocate for a moment. It sounds like this assumption is wrong or we’re solving the wrong problem or this timeline is unrealistic and we’re setting ourselves up to fail. Not polite or hedged. Direct.

It questions core assumptions, not implementation details. It doesn’t ask whether to use Postgres or MySQL. It asks whether we even need a database for this. It proposes alternatives - instead of microservices, here’s why a modular monolith solves this better right now. Sometimes it questions whether the problem is worth solving at all. Users aren’t asking for this, so why are we building it?

This is uncomfortable because challenge implies the person making the decision might be wrong. And most of us don’t handle that well, even when we claim we do. Especially when we claim we do.

The tension is the point

Challenge creates tension because it threatens three things leaders care about: momentum, authority, and certainty.

You’re ready to move forward. Someone challenging the decision means stopping, reconsidering, maybe changing course. That feels like going backwards when you were so close to checking this off your list. When someone questions your decision, it can feel like they’re questioning your competence. Especially if they’re doing it in front of others. You’ve already decided this is the right path. Challenge introduces doubt. And doubt is uncomfortable when you’re trying to project confidence.

So we shut it down. Not explicitly. We’re too sophisticated for that.

We say let’s take that offline or good points, we’ll consider that, then proceed exactly as planned. We say we need to move forward as if momentum is more important than being right.

The challenge goes away. So does the thinking.

If someone challenges your idea and you feel defensive, that’s the signal it’s working. That discomfort means they’re questioning something you haven’t fully examined. The defensive feeling is your ego protecting a decision that might not be as solid as you thought.

Most of my best decisions came from challenges that made me uncomfortable first.

The “not like that” problem

Leaders say they want dissent. Then someone actually disagrees and the response is not like that.

You wanted pushback, just... gentler and more collaborative. Perhaps phrased as a question instead of a statement? Definitely raised privately instead of in the meeting. Better yet, framed as curiosity instead of disagreement.

You wanted dissent that doesn’t actually dissent.

I watched a PM get blindsided by this. They asked the team whether users actually want this feature. Important question. But the product lead heard it as you don’t know what you’re doing.

PM got feedback later: “You need to be more supportive of the team’s direction.”

The message was clear. Agree or stay quiet.

The gap between we want people to challenge ideas and not like that is where groupthink lives. People learn what kinds of challenge are actually safe. They learn which questions are allowed, and to phrase disagreement so carefully it stops being disagreement.

Then we wonder why nobody challenges anything. They tried once. It didn’t go well. They’re not making that mistake again.

When pushback is just Steve being Steve

But here’s the thing: not all challenge is valuable. Some people challenge everything, all the time, without offering alternatives. That’s not helpful dissent. That’s just Steve from team X who hasn’t liked an idea since 2019.

Good challenge is specific. It names what’s wrong and why. It proposes what to do instead. It’s aimed at making the decision better, not at proving the challenger is smart. Obstruction is vague - I don’t think this will work - with no specifics and alternative, just blocking.

Good challenge accepts when it’s overruled. The person made their case, the team considered it, the decision went another way, they move forward even if they disagreed. On the other hand, obstruction refuses to let go. Brings it up again next meeting. Undermines the decision after it’s made. Tells everyone privately it’s going to fail.

The hard part? Sometimes these look the same in the moment. Someone pushing back on your decision could be offering valuable perspective or being obstinate. You have to distinguish between the two without defaulting to anyone who disagrees is being difficult.

Ask yourself: are they questioning the decision or questioning whether you have the right to make it? Are they offering alternatives or just pointing out problems? Are they willing to commit after being overruled or still arguing two meetings later?

This is important: you don’t have to accept every challenge. Some are valid and improve the decision. Some are just people wanting to be against something. Acknowledge it, consider it, take what makes sense. Sometimes you’ll realize it’s important. Sometimes you’ll understand it but decide the tradeoff isn’t worth it. Both are fine. The key is actually considering it instead of dismissing it reflexively.

Worth asking yourself: do I want the right answer or do I just want to be right?

The other thing about timing: if everything is already laid out and things are in motion, if teams have already started implementing, pushback gets exponentially harder. This is why the right discussions need to happen at the right time - early, when the decision is still being made, not after everyone’s already committed resources.

Sometimes it takes one or two failed projects for people to understand this. When you’re three months into something that’s clearly not working, that’s when explaining sunk cost fallacy helps. The time and money already spent is gone whether you stop now or keep going. The only question is whether you want to spend more time and money on something that won’t work. Once people see this pattern play out, they get more comfortable challenging things earlier, before the costs pile up.

Making it safe to disagree

If you want real challenge, you have to make it safe. Not comfortable - safe. There’s a difference.

Start by making challenge explicit. I usually invest in the relationships with people before meetings, then at the beginning prompt them: “Please keep an open mind and open your chakras for a different point of view.” It’s a light way of saying we’re here to challenge each other’s thinking, not to agree.

Don’t ask if there are any concerns. That invites performance. Ask who’s willing to argue against this. Give the dissent a role - your job in this meeting is to find the holes in this proposal. Now challenging isn’t being negative. It’s doing the job.

If nobody wants to challenge because they don’t feel they have permission, use the devil’s advocate framing. “Let’s just entertain the thought - what if we’re looking at this wrong?” You’re giving people permission to explore different angles without feeling like they’re being negative or disloyal. It’s not disagreement. It’s thinking out loud together.

When you’re the one proposing something, invite the dissent yourself. Tell people you’re not married to the idea. You want to look at it from different angles, find any cracks and gaps in the plan.

When someone challenges you and they’re wrong, thank them anyway. Tell them you disagree but you’re glad they raised it. When they’re right? Say it publicly - you were right, I was wrong, this is better because you pushed back. People watch what gets rewarded. If challenge only gets thanked when it’s quiet and private, that’s what you’ll get.

The reality: there’s no guarantee you’ll be successful when you challenge something. Your point of view might not be the right one. But being quiet when things aren’t clear is definitely wrong. The cost of speaking up and being wrong is temporary embarrassment. The cost of staying quiet when you see a problem is watching the whole thing fail while knowing you could have said something.

What this looks like in real meetings

The best thing I ever did for my team’s willingness to disagree was changing my mind in a meeting after someone challenged my thinking. Not saying I’d consider it. Actually changing the decision right there. You’re right, this doesn’t make sense. Let’s do your version instead. Did it feel uncomfortable? Yes. Did it make me look less certain? Probably. Did it make the team more willing to challenge me in the future? Absolutely.

I worked with a tech lead where we became sparring partners. Complex problems - not just technical, but process, teams, infrastructure, how everything fit in the platform we were building. Sometimes it took us hours, sometimes multiple sessions, to get to a solution that finally ticked all the boxes. We’d give ourselves a pat on the back for solving it.

Then he’d say: “Okay, now that we have the perfect solution, let’s find three ways why this won’t work.”

We became our own worst enemies by poking holes in the plan and finding reasons why things could fail. This helped us identify risks we’d missed in the excitement of solving it. We succeeded every time. Not by throwing away the plan - by identifying the gaps, addressing them, or documenting the risks and accepting the reality. That’s what good challenge looks like. You make the solution better by trying to break it first.

When someone questions a design, don’t make it about who they are or what their role is. Make it about the idea. Is the question valid? Then it doesn’t matter who asked it. I’ve seen engineers dismiss questions from people they don’t consider technical enough, questions they would have seriously considered if they came from someone with more credibility. The question was good. The dismissal was ego protection. If you want real challenge, judge the argument, not the person making it.

Something else that helps: build relationships with people before you challenge them. They need to know you’re not attacking them as people, you’re challenging the problem and the solution. When you have that foundation, you can push harder without it feeling personal. When someone gets animated and raises their voice explaining something, that’s often passion, not aggression. They care. But if you have a relationship with them, you can point out when they’re getting defensive and they’ll actually hear it. Without that relationship, the same comment feels like an attack.

Catch yourself mid-response when someone challenges you. You felt defensive. You’re about to explain why they’re wrong. That’s the moment to pause. Ask yourself: Is this a bad challenge or am I just uncomfortable? Is the question invalid or does it threaten something I haven’t thought through?

The defensive feeling is information. I’ve ignored it enough times to know: three months later, they were usually right.

Sometimes I’ll just say it out loud: “I’m being defensive right now. I need to think this through. Thank you for pushing back, bear with me while I work through this.” Naming the defensiveness doesn’t make you look weak. It makes the challenge land better because you’re not pretending to be open while mentally building your counterargument.

Building this kind of culture isn’t quick. It takes time and courage. It means showing people that you don’t need to be the smartest person in the room, that you don’t need to be right all the time. People will start accepting and valuing that you look at things from different perspectives. And they’ll start doing it themselves. The key is that these discussions happen at meetings, not in Slack an hour later.

In your next team meeting

You’re in your next decision-making meeting. Someone’s proposing something. You’re about to agree.

Stop for ten seconds.

Ask yourself: what would the opposing argument be? If someone challenged this, what would they say? Is anyone in the room thinking it but not saying it?

If nobody’s challenging it, someone should. Maybe that someone is you.

Or you’re the one making the proposal. You’re about to ask if there are any questions. Try this instead: ask what you’re missing, what’s wrong with this. Then wait. Actually wait. Count to ten if you have to. Let the silence be uncomfortable.

Someone will fill it. If they don’t, that tells you something about the room. When someone does challenge you, notice your reaction. Defensive? Annoyed? If you say grateful, I won’t believe you (and neither should you). That feeling tells you whether you actually want challenge or just the appearance of it.

The alternative is comfortable groupthink

The alternative to uncomfortable challenge is comfortable groupthink. Meetings where everyone agrees and decisions that go unopposed.

Then reality hits. The timeline was unrealistic or the users don’t want the feature. The architecture doesn’t scale and oh my, the strategy was based on a wrong assumption. And everyone says they had concerns but didn’t think it was the right time to bring them up.

Someone probably tried to raise this earlier. We called it staying positive or moving forward or being a team player. When being agreeable matters more than being right, you end up living with decisions that nobody actually believed in.

Real challenge is uncomfortable. That’s not a bug. That’s the whole point.

If it doesn’t create at least a little tension, it’s not challenging anything that matters.

I refuse to get blindsided by the ground shifting underneath me while I’m heads-down on execution. That’s the reason, not boredom or a love of chatting all day.

Group channels. Project channels. My team’s work. Other teams’ public channels. Customer success feedback. Engineering issues. I skim through them, read quickly, mark as read, move on. I don’t interact with most messages. I jump in when I know the answer and the situation is time-critical. Otherwise, I’m just watching.

When I brought this up in a meeting with my peers, I assumed everyone was doing the same thing. It seemed obvious. How else would you see what’s coming?

Turns out, they’re not.

They focus on their teams. They keep their heads down in the trenches. When I asked why they don’t track what’s happening across the company, the answer was always the same: “I don’t have the bandwidth. I hate pings. I don’t want to see the unread messages bubble. It irritates me.“

There’s more than just Slack. I listen, follow conversations, ask questions. I want to understand the bigger picture of what’s going on at the company: not every minute detail, but if information doesn’t come to me, I’ll go get it.

The first time this got me thinking was when I got feedback from my peers:

“You’re all over the place.”

I do my work just fine. But things are interconnected and I want to notice what’s happening around me.

“You can’t be everywhere.”

I don’t want to be everywhere. I’m in many places because information doesn’t always come looking for me.

“Why do you want to be at every meeting?”

Not every meeting. Just the ones where decisions affect me or my team.

“Why do you need to know what other teams are doing?”

Because we’re in a system. Things are never as simple as they seem at first sight.

“Why are you so curious?”

Why aren’t you?

I couldn’t understand why they were asking me that. Still can’t.

How can you not be interested in what other teams are doing? What they do affects us. What we do affects them.

I learned the hard way: making changes that ripple through three teams requires seeing those teams first. Ignorance isn’t a strategy, even when it’s unintentional.

Some leaders operate like they’ll receive a weekly well-written memo with everything they need to know. Why go out there and waste time connecting with people, building relationships, listening?

What does this actually look like? A day or two after we introduce a change, communicate it in three channels, have everyone chatting about it for days, someone shows up and says, “I didn’t know this was happening. Why was I not informed/invited/included/etc?”

I’m always flabbergasted when this happens. How is that possible? How could you not see it? How could you not know?

Because you weren’t watching.

You’ll watch closed-door meetings happen two weeks before the reorg. You’ll notice the tone change in planning meetings before the priority shift. You’ll catch the project becoming problematic before it derails your sprint. You notice when signals shift.

A good leader is like a squirrel with a meerkat mindset: busy getting things done, but every few seconds they pause, look around, and think, “What’s shifting that could bite us later?” They’re not anxious. They’re attentive. The work keeps moving, and nothing jumps out of the bushes unannounced.

I’m calling this the squirrel-meerkat principle. Yes, I made that up. But you’ll remember it.

Not everyone does this. I’ve seen leaders miss all of it, be it the reorg, the priority shift, the project losing executive support. Then they wonder why their excellent work becomes irrelevant while they were building it. They stayed in their lane, heads down, all their time on execution. They missed the terrain that determines whether their execution even matters.

Great leaders don’t just optimize their own team, they understand how the system behaves.

This isn’t paranoia. It’s peripheral vision.

The tunnel vision tax

“Stay in your lane” is advice that works… right up until it takes you out. It’s usually well-intentioned, but it quietly installs blinders and calls it discipline.

You’re not responsible for driving everyone else’s car, but if you refuse to look left or right, don’t act shocked when something slams into you at full speed.

Don’t get me wrong. Deep expertise matters. Focused execution matters. But taken too far, narrow focus creates a special kind of professional blindness. Without understanding the terrain, even excellent work fails if it doesn’t connect to the system around it.

One step back changes everything. You stop seeing just your corner and start seeing the whole system with its connections and its dependencies. These are the forces that will derail your work if you’re not watching for them.

I didn’t always see this. I learned it in earlier roles where I was deep in operational work, organizing my team’s priorities while constantly trying to unblock others so work could move end to end. Over time, a pattern emerged: when things slowed down, it wasn’t because people weren’t executing. It was because no one was stepping back far enough to see how the system was actually behaving. Just don’t step too far back or you might end up in a different company. Or fall off a cliff.

That realization pushed me to be more intentional. I learned to take a deliberate step back: creating space to assess, recalibrate, and lead with context rather than reaction. I trained myself to listen and observe signals before they become obvious, let alone urgent. My natural curiosity helped. Put together, these habits changed how I approached leadership: not as staying in my lane, but as understanding the terrain well enough to navigate it without constant firefighting.

I still get sucked in. I still get involved in too many things. But now I’m aware of it. I know I can’t stay down in the trenches anymore. But I’ve also gotten much better at telling the difference between the problems I actually need to solve and the circuses that are simply very loud, very shiny, and absolutely not mine.

The invisible forces nobody puts on roadmaps

Your work doesn’t execute in a vacuum. It ships in an organization with competing priorities, political dynamics, resource constraints, and direction changes happening constantly.

Most of these forces are invisible until they hit you. They’re actually not invisible, everyone just pretends not to see them until it’s too late.

Money decides what survives regardless of what the plan says. Your project can be “strategic” and “high priority” while having zero people, no funding, and no one senior showing up to meetings. When the company actually allocates budget, the project with impressive slides but no resources dies first.

Leadership’s attention flows like water. It pools around fires, shiny new things, what keeps executives up at night, what competitors are doing. When attention moves, priorities follow. The project that mattered last quarter becomes the project nobody asks about this quarter. If you’re heads-down building and don’t notice the attention shifted, you’ll find out when you ship to silence.

There are a dozen other forces that don’t announce themselves. VPs who aren’t speaking to each other. Teams not being aligned because they’re measured on different things. The company changing direction and making yesterday’s critical work tomorrow’s irrelevant code.

These forces show up in small moments that cascade.

Imagine a product manager who wants to improve onboarding. The change is thoughtful, well-intentioned, and clearly makes sense from a product standpoint.

Now imagine that same flow quietly sits under marketing’s paid campaigns where budgets, attribution, and targeting all built on assumptions about how the system behaves. While the PM refines onboarding, marketing is planning campaigns in one channel, engineering is preparing the rollout in another, and everyone is doing exactly what they’re supposed to be doing.

No one is wrong. Nothing is broken. Until it is.

The issue only shows up because someone (you) happens to be paying attention across teams and notices the collision before it happens. The fix is simple: get together to discuss the changes and adaptations needed on both sides.

One conversation. Thirty minutes. Crisis prevented.

The lesson here? Good decisions made in isolation are how most avoidable problems are born.

If you don’t catch such things early, the system will still teach you, it just prefers to do so loudly, publicly, and on a very expensive day.

This happens constantly. Someone makes a change that seems isolated but ripples through three other teams. A product decision that breaks a customer success workflow. An infrastructure update that derails a marketing timeline. All preventable if someone was watching the connections.

If you’re the person preventing such problems, don’t expect a thank you note for a disaster that didn’t happen. Consider it your job and give yourself a pat on the back. You’re not psychic. You just built peripheral vision. And this is good. Now move on and keep your eyes wide open and your ears to the ground.

Building peripheral vision without becoming paranoid

You can’t track everything. Trying to will make you useless at your actual work. You’ll hit a breaking point and realize you need to sample the signals: pick the channels that matter and focus on those.

You can build a lightweight system for the handful of signals that predict whether your work survives or becomes irrelevant.

This isn’t about attending every meeting or reading every email or Slack message. It’s about identifying specific patterns worth watching and checking them regularly enough to avoid expensive surprises.

The minimum viable tracking system

People worth watching. Not everyone. Just the 3-5 people whose presence, absence, tone, or questions signal shifts in the company.

Your boss’s boss. People with influence over your work. The senior person backing your project (if one exists). The person on another team you depend on.

Track them lightly. Do they still attend your project meetings? Did their questions change from “how do we ship this?” to “how much does this cost?” Did they stop responding in Slack?

Presence and absence tell you where attention is flowing. Tone and questions tell you what leadership is optimizing for. When either shifts, your project’s position just changed.

Budget signals. Money is truth. Hiring freezes, approval delays, cost-focused questions in planning meetings. These signals precede direction changes by weeks or months. If your project lacks actual budget, actual people, or senior leaders showing up, it’s not actually a priority no matter what the plan says.

Roadmaps can promise anything. It’s the budget and behaviors that matter.

Meeting patterns and language shifts. When leaders have unusual closed-door sessions, announcements follow within a couple weeks. When fewer people show up to your project meetings, momentum is dying. When leadership stops saying “customer impact” and starts saying “cost optimization,” priorities just changed. The words change before the decisions get announced.

The weekly scanning habit

This doesn’t require hours, just some discipline.

Fifteen to twenty minutes, once a day or every other day. Scan leadership updates. Check plan changes. Notice who got promoted, hired, or moved. Monitor the channels across teams where tension surfaces before it becomes official conflict.

Not obsessively. Just enough to spot when patterns change.

Sometimes it takes longer. You find something that needs deeper investigation. That’s fine. The habit matters more than the exact time. This is operational awareness.

If you build this habit you’ll be rarely surprised.

What this looks like in practice

Managing the noise

I organize the 50+ channels into two categories: critical ones and scan-only. I check all of them at least once or twice a day. Not more. The critical ones get more attention. The rest get skimmed.

I learned to live with unread notifications. They don’t bother me anymore because I know they can wait. Not all pings are created equal. Some channels need close attention. Others can wait a few hours.

One of the leaders said he won’t join more channels because unread messages annoy him. He needs to read them. The pings distract him. So he stays out.

I get it. Unread badges are stressful. So is getting blindsided by a reorg, but at least that’s only once.

In the (physical) office, I rarely wear headphones. Headphones put you in your own bubble. You can’t hear what’s going on around you. I learned to work in different environments with noise, to zone in on work but not completely. Just enough to focus while still picking up the things I need to notice. I hear when someone’s stuck. I catch when someone’s about to make a decision without full context. I notice tension forming before it becomes a problem.

I schedule my deep work early in the morning and try to let other people have their own focus time too. Another suitable slot is in the afternoon when pings are less likely. I leave the majority of my calendar flexible because this is my work: unblocking people, providing information, connecting dots, coordinating across teams.

Some days I hate meetings especially if they’re back to back. Other days I know exactly why I’m there. When time is being wasted, I’m the first to suggest ending early. When discussions sidetrack, I have no problem saying “Let’s get back on track.”

Not all meetings are created equal. We’re constantly experimenting with format, length, who needs to be there. We course-correct. The key is that people need to speak up when meetings go off track, whether they’re the organizer or just a participant.

Making the connections

In meetings, I listen and make notes. I don’t zone out. If I’m in a meeting, I make the best of it because people sharing information is one channel, Slack channels are another, and random chatter in the kitchen or at lunch is another. All of these help you understand what’s happening in the company. The key is to be present regardless of where you are or what channel you’re tuned into.

I’ve connected people who needed to talk to make better decisions or prevent something from going wrong. An engineer who didn’t have the full picture and would have caused problems downstream. A product manager who didn’t know marketing was running a campaign that their feature change would break. A team lead about to commit resources to a project that was quietly losing executive support.

Without this information, without this context, it’s easy to make wrong assumptions and in the end make bad decisions.

Giving energy to these channels is the price I pay for seeing what’s happening across the organization so I can make better decisions when I need to.

I’ve finally reached a place where people around me understand this. I don’t get the “you’re all over the place” feedback anymore. They actually like having someone who connects the dots, sees across teams, and flags what needs flagging.

Turns out “I told you so” is most persuasive when you never actually say it.

But I have to be careful not to swing to the other extreme: where I hear everything so they don’t have to. That’s not sustainable. And it’s not the point.

Acting on what you see

Seeing the signals doesn’t help if you don’t act on them.

Spot a project losing momentum? Ask directly. “I noticed the VP stopped attending our check-ins. Is this still a priority?” Either you find out it’s still important, or you find out it’s dying and you can pivot before wasting three more months.

Money getting tight? Talk about your work in terms of what keeps leadership up at night. If they’re worried about cost, explain how your work saves money. If they’re worried about speed, explain how it gets things done faster. Your work hasn’t changed. Your pitch has.

See misalignment forming? Escalate early. You can’t fix structural misalignment from an IC or middle-management position. But you can surface it early enough for someone with authority to address it before everyone wastes months building the wrong thing.

Intuition says something’s off? Investigate. Your pattern recognition runs subconsciously before conscious awareness catches up. Stop and check. Most of the time, your intuition caught a real shift before your conscious mind connected the dots.

If you see the problem but don’t act, you’re choosing to watch the train wreck happen… knowing you could have prevented it.

The payoff

I started tracking signals years ago. The bigger the company, the more signals to follow. Made mistakes, adjusted the system, found what works. The usual.

Now I’m rarely caught off guard. There are some false positives when I see something that might become a problem but doesn’t. But the situations where I point something out to the people involved, where I suggest they talk, are way more frequent than the false alarms.

I don’t get the “you’re all over the place” feedback anymore. I’ve seen more leaders understanding that paying attention across teams is as important as doing quality work where your expertise is deeply needed. I’ve seen them listening more, connecting more, bridging gaps, talking to people, pointing things out. That’s a small win.

Sometimes I feel like a proud parent looking at them thinking, “Look at how quickly they’re learning.” Maybe I’ve spared them a lesson or two they would have learned the hard way.

Organizational changes are inevitable. Priority shifts. Strategic pivots. They happen no matter what you do. The only question is whether you’ll see them early enough to do something about it.

You can be the one who shows up two days after the change asking, “I didn’t know this was happening,” while everyone else has moved on.

Or you can build peripheral vision and situational awareness now.

Subscribe now

Ten years later, that experience still helps me lead teams through chaos. Not despite the stress, but because of it.

An engineer told me last week: “I feel like I’m becoming obsolete every Monday.”

New AI coding tools. Framework updates that invalidate last month’s best practices. The skill you spent years building is suddenly table stakes because AI does it in seconds.

The stress isn’t visible like a production outage. There are no customers complaining and no Slack war room waiting for you. Just the quiet anxiety of not knowing if what you’re good at will matter next year.

Some engineers are paralyzed by this. Others are adapting faster than the technology changes.

The difference? The ones handling it best already learned something most leaders try to prevent: how to use stress as a tool, not avoid it as a threat.

I wrote recently about what’s left for engineers when AI writes the code.

The answer: judgment, curation, prevention. The skills that matter when generation is cheap.

But that essay didn’t answer the harder question: how do you actually build those skills when everything’s changing this fast?

The answer is counterintuitive: controlled stress exposure builds the capacity to handle any stress. Physical challenges build mental toughness. Emotional risks build professional courage. And recovery time is what makes it all stick.

The engineers handling the AI transition best aren’t the most enthusiastic or the most technically skilled. They’re the ones who already learned how to stay calm when they don’t know what’s coming next.

They built that muscle somewhere else. Now they’re using it here.

Same pattern shows up everywhere

You’ve seen it in my hiking story. The pattern shows up in every high-pressure situation - including how teams handle incidents at 2am.

Stressful situations either make or break people. You see who a person is at the core once you put them in an unfamiliar stressful situation like on-call or a feature release that you don’t expect to go smoothly. You have to get up in the middle of the night, something’s wrong, customers are affected, and you see how people respond to this kind of adversity.

In the past I enjoyed being part of the on-call group even if I wasn’t solving the problems. I was helping coordinate or communicate progress and solutions. But I enjoyed observing my team members stay calm, think through steps, not panic, and do those plan-do-check-act (PDCA) cycles a couple of times within half an hour. To me it was like watching a thriller where you know you are with a good guy, you’ll find way out of all the difficult situations and everything will be okay at the end.

And then there were times when a different person was on call. Nervous, jumping around without clear steps, panicking, escalating too soon or not escalating at all and at the end caving in without communicating where they are, what they’re doing. That was a totally different story to observe. I felt nervous, I felt this tension and I was not sure we’ll make it through the incident without major outage. My instinct would be, “Oh let’s call someone else.”

We had a couple of feature releases that went anything but smooth. Whatever could possibly go wrong went wrong. Regardless of pre-mortems we had, we still encountered some unpredictable situations and had to come up with solutions on the fly, pair thinking and coding at twice the speed we would have otherwise. But if the right combination of people was in the team releasing, whether it was Saturday morning or Monday evening, it was almost beautiful. It was intense, it was challenging. We were full of adrenaline. But it also bonded us, it made us believe that there is not a problem we cannot solve.

Another situation, this time regular release, something that should be simple and smooth. But there was one overly anxious person panicking at every normal little hiccup like it’s the end of the world and with this affecting everyone else to temporarily lose their cool and stress out.

So what’s the difference between these two types? Personality plays a role - some people are naturally calmer under pressure. But that’s not the whole story.

The engineers who handled chaos calmly had been through smaller versions of it before. They’d watched someone experienced navigate an incident and learned the pattern. Or they’d stumbled through one themselves, extracted the lesson, and built the muscle for next time.

The ones who panicked? They’d never had the chance to practice.

Maybe you kept them focused on feature work, shielding them from incidents. Maybe you always put the experienced people on the stressful stuff. You thought you were being kind - letting them concentrate on code instead of chaos.

You weren’t building kindness. You were building fragility.

They never learned how to think clearly when things break. They never saw how experienced engineers stay calm, work methodically through problems, communicate under pressure. They never built confidence that they can handle adversity.

Now when the real crisis hits - when you’re not available, when the experienced people are stretched thin - your team freezes.

Resilient vs. antifragile

Resilient teams bounce back from stress. They survive challenges and return to baseline.

Antifragile teams get stronger from stress. They don’t just survive challenges, they use them to build capacity.

The concept comes from Nassim Taleb, who distinguished between things that break under stress (fragile), things that withstand stress (resilient), and things that improve from stress (antifragile).

Your bones are antifragile. Apply controlled stress through exercise, and they grow denser. Shield them completely, and they become brittle.

Muscles are antifragile. Resistance training creates micro-tears that heal stronger during recovery. No resistance means atrophy. But constant resistance with no rest? That just breaks you down.

Like bones and muscles are for the body, team members and teams are for the company. The stronger and more antifragile team members, the stronger and more antifragile teams. You can selectively work with individuals to make them better at this and then collectively as a team as well.

A lot of leaders treat teams like they’re fragile. Shield them from all stress. Protect them from difficult situations. Take on the hard conversations yourself. I know I did in the past.

The result? A team that can’t handle the real crisis because they never practiced with the manageable ones.

Not all stress builds capacity

The stress → recovery → stronger cycle only works when all three parts are present. Stress breaks you down. Recovery builds you back up stronger. Skip recovery, and you’re just accumulating damage.

Chronic overwhelm with no recovery time just breaks people. The key is distinguishing between stress that develops and stress that destroys.

The best example is how physical challenges build mental toughness and emotional risks can build professional courage.

I learned this from my own experience and later read research supporting it. Exposure to controlled stress in one domain builds resilience that transfers to others.

Physical challenges build mental muscle

I used to do 45km orienteering treks. Amateur events where anyone could join. You’re in the middle of nowhere with only what’s in your backpack, a bit of courage, and grit to make it to the end. I was never the fastest, not even close, but I never gave up.

I mentioned that ditch earlier - here’s what actually happened. It was in a region where there could be bears. At the first 10 km my knees started throbbing. I was in the middle of nowhere - no houses, nothing. I thought: “Okay, maybe I should give up since my knee is hurting.” But I had duct tape in my backpack. I taped my knee and soldiered on for the next 35 km alone in the woods where there could be bears. Then I fell into a ditch full of leaves so deep that only my head looked out.

Still not giving up, I just found my way out. And laughed. It was funny. Happy I didn’t run into any bears. This experience, even 10-15 years later, gives me strength when I need it. If I managed to get out of that situation alone and lost, I can bear anything.

While I can’t and won’t make all my team members go on a trekking in the middle of the woods, I still do encourage them to work out, to go and take care of themselves, of their body, and go through some hardship to be stronger everywhere, including at their work.

In the last couple of years a couple of my team members and myself attended obstacle races. Not to win, but to push ourselves. They challenging but they were also fun. And they bonded us through mud and sweat, through overcoming our fears and physical discomfort jumping or climbing over or under obstacles. We even had to climb under a tank. A real one.

The pattern shows up everywhere. Engineers who run marathons approach things differently. They’ve built the mental muscle to stay patient when solutions aren’t obvious. Leaders who do endurance sports handle organizational chaos with more calm. They’ve practiced discomfort.

This isn’t some sophisticated or mystical mechanism. You’re creating concrete experiences of stress → recovery → stronger. Your brain learns the pattern. Then it applies the pattern across domains.

And that recovery matters. The 45km trek worked because I didn’t do it every day. The obstacle races bonded us because they were occasional challenges, not constant grind.

Emotional stress builds courage

Most team members I ever worked with tried to avoid presentations, especially public speaking, regardless whether it was internal or (God forbid) external. But I always encourage them to just do it, to just try.

It’s much easier to try in front of smaller teams of team members that you might be more comfortable with. Where you can make mistakes, where you don’t have to perform because they already know you. You can just be you. You can try it.

They are terrified. Then do it anyway. Their hands might shake. Their voices might shake from the beginning.

Sometimes the presentations are rough. But they survive. Next time, they present again.

And the more times they do it, the sooner they get into the zone while presenting. Then eventually they will start enjoying it. It will never be perfect, and that’s not the point. The point is building capacity by confronting the fear.

This experience helps them handle high-stakes conversations that would have paralyzed them before. Not because presenting made them an extrovert. Because confronting a fear directly builds capacity for all future fear-inducing situations.

It doesn’t always have to be presentation in front of others. It can be speaking up at a meeting where stakes are high or where you have leaders present.

I know how hard it is. In comparison to many people I know I would consider myself a seasoned speaker. I’ve been at conferences and events with hundreds of people in the audience, I facilitated hackathons and workshops... but still I feel the anxiety, the mix of fear and excitement, too. Every time. When I’m at a presentation and would like to ask a question my heart starts pounding. Boom boom, I can hear it in my ears. I can feel it in my guts. I feel nervous. I usually need half a minute to decide whether to even raise my hand or not. But I know by now that once I speak it will be okay, and these 30 seconds gives me time to collect myself and then just do it. Once you ask the first question, the second one is much easier.

The heart pounding almost never goes away. It is a clear sign for me that yes, I am out of my comfort zone, and yes, I need to do this.

This happens especially when you think your question is stupid or when you put too much importance on what others will think (of you). But you know what? From my experience a lot of people there have exactly the same stupid questions in their mind. They’re just too afraid to ask them. Once you do, they might open up and ask something themselves.

The engineers who never face their fears stay fragile. They’ll avoid difficult conversations, delegate the presentations and their visibility will suffer.

Each avoidance reinforces fragility and each confrontation builds strength.

Professional stress builds capability

The team that’s never deployed a risky change can’t handle the inevitable risky deploy. The engineer who’s never led an initiative outside their expertise can’t adapt when the company needs something new.

We had only a couple of skilled engineers in on-call rotation. We needed to expand the pool but couldn’t just throw inexperienced engineers into 2am incidents.

Inspired by Chaos Monkey, we introduced monthly incident response drills. Database failovers, service degradation, partial outages. Simulated situations where more experienced engineers coached newer ones through the pressure. The stakes were controlled, but the stress was real.

The engineers loved it. They practiced thinking clearly under pressure without the panic of a real early morning incident. Our response times improved. We identified gaps in monitoring and playbooks. Most importantly, we built antifragile engineers who could handle whatever came their way.

Usually our engineers are candidates for on-call once they’re senior but I had one team member who said, “Let me in. I want to learn. I am excited about this. I want to be exposed to this kind of stress because truth be told you learn much more in these times than you do through regular work.”

He was really excited because he knew that he had a safety net of other on-call engineers who can help him out but he wanted to try, to jump in, to do it himself. And he did it. I don’t lose any sleep when he’s on call because I know we are in good hands. No matter what comes his way, he’ll find a way to solve it.

The teams that only take on projects where success is guaranteed never build the muscle to handle real uncertainty. They stay in their comfort zone until the company needs them to step outside it. Then they’re stuck.

What harmful stress looks like

Developmental stress is challenging but manageable. There’s recovery time. There’s learning built in. There’s support when things go wrong.

Harmful stress is chronic overwhelm with no processing time. No learning loops and no light at the end of the tunnel. Just constant fire-fighting with no space to understand what made the fires start.

I’ve seen teams ground down by this. Incident after incident with no post-mortem. Sprint after sprint with no retrospective. Pressure with no release valve.

That’s not building antifragility. That’s breaking people.

The difference comes down to three things:

1. Can they handle this dose of stress with support? Or is it genuinely beyond their capacity even with help?

2. Is there recovery time? Stress without rest is just burnout. Muscles grow during recovery, not during the workout.

3. Is there learning? If you’re not extracting the lesson from the stress event, you’re just experiencing pain without growth. and you’re bound to repeat it again

No to any of those three, and you’re not building antifragility. You’re just grinding people down. Recognize these three things and do your best to turn harmful stress into manageable challenges.

But sometimes you’re not the one creating the harmful stress. The business is pushing impossible deadlines. Leadership is stacking projects with no breathing room. The pressure is coming from above, and your team is getting ground down.

This is where you step in as a buffer. Your job isn’t to shield them from all stress - that would keep them fragile. It’s to make sure those three criteria are met. Fight for recovery time between major pushes. Push back on stacking another high-stress project when the team hasn’t processed the last one. Carve out space for retrospectives even when leadership just wants the fix and wants you to move on. Make sure your people have the support they need to handle the stress, not just survive it.

In situations like this being a leader means saying no upstream so your team can say yes to the right challenges.

How to actually do this

The goal isn’t to traumatize your team. It’s to create environments where they deliberately face manageable challenges.

Run drills before the real crisis

Run drills. Chaos engineering experiments. Pre-mortems. Practice scenarios where failure is safe but the pressure is real.

The teams that do this regularly don’t panic during real incidents. They’ve built the pattern recognition. They’ve practiced thinking clearly when systems are failing.

The teams that never practice stay fragile. When the real incident hits, they’re learning under maximum pressure. That’s not antifragility — it’s hoping for divine intervention.

Give stretch assignments with safety nets

Give stretch assignments with support. Projects outside someone’s comfort zone where failure is possible but trying matters.

The engineer who’s never led anything can’t suddenly become a tech lead. But they can lead a small cross-team initiative with you providing backup. Then a bigger one. Then they’re ready.

How I start this usually with mid-level engineers is by giving them a feature that’s bigger than anything they’ve done before, but manageable with support. I ask them to understand the problem, prepare solution, prepare task breakdown, milestones, estimates - everything that in the past someone more senior did for them. I ask them to validate these things with seniors so they get immediate feedback and we go through and try to figure out what they didn’t think of. Then I just let them do this project with regular check-ins to see if they need any help or to correct course if needed. I let them fail small stuff but I would not let them fail an important thing that would hurt their reputation, customers, or the company.

The pattern works for everything. Public speaking. Architecture decisions. Client conversations. Conflict resolution.

Start small. Make failure safe. Build the capacity gradually.

And build in recovery between stretch assignments. Don’t stack them back-to-back. The growth happens in the space between challenges, when people process what they learned and build confidence for the next one.

Stop shielding, start coaching

I stopped protecting people from every difficult situation. I let them practice navigating hard conversations with me as backup. I let them present with me in the room so I can back them up. I let them handle the stakeholder who’s frustrated, with me available if it escalates.

Each exposure builds capacity. Each protection reinforces fragility.

I used to think I was being a good leader by handling all the difficult conversations myself. I was actually preventing my team from developing the skill to handle them. I was a crutch.

Now I coach them through it. They lead the conversation. If it goes sideways, I step in. But most of the time, they handle it. And the next conversation is easier.

Sometimes I still jump in too soon as a hero to guard them. But they remind me: “Mateja, let me do it myself, no need to jump in immediately. I got this.”

This makes me proud from two reasons: they want to do it themselves and they spoke up because they want the opportunity.

Extract the learning, not just the fix

Stress without learning is just suffering. The difference between teams that get stronger and teams that just survive is what happens after the stress event.

Your post-incident review process reveals it all.

If you’re only asking “how do we prevent this?” you’re missing the growth opportunity. The better questions are:

• What did we learn about our systems?

• What capacity did individuals develop?

• What would have helped us respond faster?

• Who grew through this experience?

• What should we practice now that we know we’re weak at it?

The teams that extract learning from every incident get stronger. The teams that just fix and move on stay at the same capability level.

Same thing applies to post-mortems, derailed projects, and stretch assignments that didn’t work out.

Some fixes are simple - tweaking processes or timing. Other times it’s more coaching through the hard parts. Whenever we have a challenging project, we try to do a retrospective afterwards where we speak up openly what worked and what didn’t. Not just from a technical perspective but also from a more human perspective. And a few things popped up in our retrospectives. We can’t do projects back-to-back without a cool-down period. And we can’t work on two big projects at the same time because it’s draining us.

We applied this into next quarter planning a bit better than we used to. We are still work in progress and we still do retrospectives, because we want to improve.

If you’re not asking those questions, you’re wasting the stress. You went through the pain without capturing the growth.

The pattern that matters

Teams that get stronger from challenges share a pattern. They don’t avoid stress. They create controlled exposure to it.

Physical challenges. Emotional risks. Professional stretch assignments. All three matter.

The engineering team that does a challenging sport together builds mental resilience. The individual who confronts their fear of public speaking builds courage that transfers everywhere. The engineer who takes on the unfamiliar tech stack builds adaptability.

None of this happens by accident. It requires creating environments where controlled stress is expected, where failure is safe, and where learning is extracted from every challenge.

The alternative is teams that only function in comfort. The moment real pressure hits, they fracture.

For individual contributors: seek the stress, plan the recovery

If you’re an IC reading this and thinking “my manager isn’t building antifragility,” you can still build it yourself.

Volunteer for the scary stuff. The presentation you’re dreading or the project outside your expertise. These aren’t distractions from your growth. They are your growth.

But here’s what most people miss: you have to plan recovery as deliberately as you plan the challenge.

What does recovery actually look like?

After a stressful incident or release: Take the next day lighter. Don’t stack another high-pressure deadline immediately. Process what you learned - write it down, talk it through with someone. Give yourself permission to do routine work for a day or two while your brain integrates the experience.

After an emotional challenge like a presentation or difficult conversation: Block 30 minutes after for decompression. Don’t schedule back-to-back high-stakes meetings. Acknowledge what you accomplished. The shaky hands during the presentation? That’s your system building capacity. Don’t force yourself to “power through” immediately to the next thing.

In the face of ongoing change - AI, new tools, shifting tech landscape: Pick one new thing to learn deeply, not ten things surface-level. Schedule actual downtime. Not “I’ll rest when the project is done” but planned recovery time. Protect focused work time. Context-switching is stress without the growth.

The pattern is the same:

You don’t need your manager’s permission to seek challenges. But you do need to be smart about recovery. The engineers handling chaos best aren’t the ones grinding 24/7. They’re the ones who push hard, recover fully, and show up stronger next time.

What to do Monday morning

If you lead a team, ask yourself:

When the difficult stakeholder conversation comes up, do you handle it yourself or coach someone through it?

When there’s a stretch project, do you give it to the person who can definitely do it or the person who might fail but would grow from trying?

When incidents happen, do you extract learning or just fix and move on?

The teams that survive chaos aren’t the ones that never faced it. They’re the ones that practiced with manageable versions of it first.

Start small. Run an incident response drill. Give someone a stretch assignment with support. Let your team practice being uncomfortable while the stakes are low.

Because when the real crisis hits, and it will, you want a team that’s been here before. Not in this exact situation, but in situations where they thought clearly under pressure, tried something uncertain, and pushed through discomfort anyway.

That’s what antifragile looks like.

If I learned anything in my life is this: we’re tougher than we think we are.

Some days you feel less proud. Perhaps a PM is pressuring you to whip up something good enough to give users the value before someone else does. But still, you have these good days to live for.

But this was yesterday. Today you woke up to a world that is totally different than it was yesterday. It seems that craftsmanship isn’t that important anymore. How did this happen? Why? Where did the fun go?

A few weeks before today

By some random chance you were in a strange meeting. At least strange to you. Up until now you might not have been involved in planning, but this time you had to jump in for some reason.
The PM walked into planning with a feature spec. Sixteen pages. User interviews, wireframes, acceptance criteria. The team started estimating: two weeks, maybe three. Someone asks about database schema changes. Another about the API layer. You were already sketching microservices in your head. Tech lead lets you all talk for five minutes and then asked three questions.

Who asked for this?
What problem does it solve?
Can the existing admin panel already do this?

Ten minutes later, everyone realizes the whole thing can be solved by exposing an existing feature to a different user role. No new code. No sprint. No architectural debate that takes longer than the actual work.

The PM looks relieved. The team (including you) looks vaguely cheated because they were ready to build something interesting. Tech lead just saved two weeks of engineering time by asking what didn’t need to exist.

Their GitHub commit history will show nothing. Their performance review won’t list this under features shipped. But they just delivered more value in fifteen minutes than most engineers create in a month.

This is what being senior actually looks like. And it’s invisible.

The value that doesn’t show up in GitHub

Junior engineers are evaluated on what they build. How fast they ship. How fast they learn the domain knowledge. Lines of code written. PRs merged. Features deployed.

The metrics are concrete because the value is obvious: they’re learning to translate requirements into working systems. Output matters at this stage.

Then you hit mid-level and get really good at this. You write clean code. You know the patterns. You can architect elegant solutions. You take pride in the quality of what you ship. This is where it feels right. You’re a craftsperson. Your GitHub activity graph is a thing of beauty, deep green fields of your worthiness.

And then something uncomfortable starts happening.

You’re in more code reviews than implementations. More planning discussions than deep work sessions. People keep asking your opinion on things before they’re built.

The equation already shifted. Your value isn’t what you write anymore. It’s what you prevent from being written.

The unnecessary feature that creates years of tech debt. The over-engineered solution nobody can maintain. You get the idea.

Your Github doesn’t resemble the green pastures anymore. And that’s not bad, it just seems to you this way.

Because you’re not prepared for this shift.

Why saying no is the highest leverage

Every feature you ship creates a maintenance burden. Someone has to monitor it. Debug it. Update it when dependencies change. Explain it to new team members and even support users who misunderstand it.

One harmless example: the team wants to add a feature flag system. Sounds reasonable, right?

Feature flags solve deployment risk. They also create combinatorial explosions of system states. Six flags create 64 possible configurations. Most are never tested. Some are broken. And any of them can happen in production.

You just traded one problem for sixty-four.

Then you ask: what are we actually trying to solve? Turns out they want to A/B test one feature for two weeks. You suggest a time-based rollout instead. Same outcome, fraction of the complexity. No permanent infrastructure to maintain.

This is force multiplication. One conversation prevented months of maintenance burden. The team ships the feature, learns what they need, and moves on. No lingering infrastructure debt.

The best engineering leaders I’ve worked with have this in common: they say no more than they say yes. Not because they’re negative or risk-averse, but because they understand opportunity cost and want to say yes to the right things.

The engineer who can’t say no is just a backlog execution engine. The one who says no strategically is leading.

No sense optimizing for output when the game already shifted to judgment.

The curation skill that AI makes critical

AI can generate code in seconds. Entire functions, sometimes entire features. The initial reaction is panic: if AI can write code, what’s left for engineers?

Wrong question. AI made code generation cheap. It made code curation critical.

You ask AI to build an API integration. Thirty seconds later, you have 500 lines of code. It runs, tests pass, ships to staging.

Then you read it.

There’s redundant error handling. The retry logic will DOS your own service under load. If this is what you intended, good for you, but I doubt it. It’s using a deprecated version of the library, half the code is boilerplate that belongs in a shared utility, and the other half makes assumptions about the API that aren’t documented and will break silently when they change.

You delete 400 lines. Rewrite 50. Ship 100.

AI just made your judgment more valuable, not less.

Junior engineers using AI are productive until something breaks. Then they’re stuck because they don’t know how to evaluate what AI generated. They can’t tell good code from plausible garbage.

Senior engineers using AI move faster because they know what good looks like. They can review, refine, and reject in seconds. The fundamentals let them treat AI like a junior developer: helpful, needs oversight, occasionally brilliant, frequently over-complicated.

The engineers panicking about AI are counting lines of code. The ones who know they’re safe are counting decisions made.

When your identity doesn’t match your career

Now someone’s telling you the valuable skill is not writing code?

Your identity is tied to I write excellent code. That’s what you’re confident doing and that’s how you measure a productive day.

If you’re still measuring yourself by output, this feels like going backwards. I’m not even doing real engineering anymore. I’m just...talking.

Some engineers resist this for years. They keep trying to be pure implementers because that’s where they feel valuable. They avoid planning meetings. They measure their worth by GitHub activity. Then they wonder why they plateau, why they’re passed over for senior roles, why engineers who aren’t as good get promoted past them.

It’s not that they’re not skilled. It’s that they’re optimizing for the wrong thing. They’re trying to be the best at a game that stopped mattering at this level.

Others make the shift but feel guilty about it. They’re not coding so they must not be contributing. They prevent a disaster but can’t point to a feature they shipped. They delete half a system and feel like they wasted time because there’s nothing new to show.

Both are wrong about what’s valuable. The market already decided. The people who can prevent bad work are worth more than the people who can only do good work.

Your identity has to catch up to where your career already is.

The new scoreboard

If your self-concept is I write code, AI is an identity crisis waiting to happen. If it’s I solve problems and build systems, AI is just another tool.

AI just compressed the timeline. Mid-level engineers used to have years to develop judgment before they needed it for promotions. Now they need to start building it immediately, while AI handles more of the implementation. You won’t become senior overnight. But you need to start acting more like one— asking different questions, making different decisions and honing slightly different skills.

This means updating how you measure your value. Stop counting commits. Start tracking how quickly you spot problems in requirements, how many architectural decisions you influenced, how effectively you questioned assumptions before code was written. The work shifted from writing code to deciding what code should exist.

None of this shows up in velocity metrics or GitHub stats. All of it shows up in team effectiveness, system quality, and whether people trust your judgment.

Measure how good you became at problem solving, how many subtle bugs you caught in AI-generated code, how well you designed the system for others to use.

This isn’t the first time (and it won’t be the last)

If you’re resisting this shift, you’re not alone. Engineers resist every time their value proposition changes. The pattern repeats. The adapters win and the resisters plateau.

In 1968, the NATO Software Engineering Conference declared a crisis. Programming had been math and art, which is a nice way of saying ad-hoc, individual, and impossible to scale. The shift to software engineering demanded systematic rigor, planning, and discipline. Engineers who saw themselves as creative problem-solvers resisted the factory metaphor. They insisted real programming was craft, not process. The ones who adapted became the first generation of professional software engineers. The ones who refused stayed hobbyists.

Fast forward to the 2000s. You write it, you throw it over the wall to ops. Then Amazon and Netflix said you build it, you run it. Engineers had to own production, on-call rotations, security, monitoring. Developers who saw themselves as pure coders resisted. I’m not an ops person. I write code. The ones who adapted became the high-value full-stack engineers who could ship and maintain. The ones who refused got stuck in legacy roles while the market moved to DevOps.

Same pattern with Agile in 2001. Waterfall engineers valued specialization, documentation, upfront planning. Agile demanded iteration, collaboration, generalists who could work across the stack. The specialists who insisted I’m a backend engineer, not a generalist watched as full-stack engineers became more valuable. Not because full-stack engineers were better coders. Because they could move faster with less handoff friction.

AI is creating another shift, but it inverts the pattern. Agile generalists were valuable because they could implement across the entire stack. AI-era generalists are valuable because they can think across domains while AI handles implementation. The new generalist isn’t someone who codes in five languages, but someone who understands business problems, architects solutions, validates AI output, and iterates on problem framing rather than implementation details. The engineer who insists I just write code is becoming today’s waterfall specialist.

Every shift follows the same script: the market redefines what’s valuable. Engineers with identities tied to the old definition resist. Adapters shape the new landscape. Resisters wait for things to go back to normal.

They don’t.

The engineers who thrived through these shifts weren’t necessarily the most technically skilled. They were the ones who recognized the pattern early and asked: What does the market need now? How do I stay relevant? What’s my value if the old metric broke?

AI is the latest iteration of this pattern. And it’s happening faster than the previous ones.

The question isn’t whether this shift will happen. History already answered that.

AI just made this shift non-optional

If you were going to resist this shift for another few years, AI just killed that plan.

When code generation was slow, companies needed people who could type fast. When AI can generate a working feature in minutes, companies need people who can tell if that feature should exist at all and what should exist instead.

The shift from write code to decide what to write just became urgent. Not in five years. Now.

The engineers who aren’t panicking already made the shift. They knew their value was judgment, architecture, prevention, curation. AI made them more productive because they can generate, review, and reject faster. Their constraint got more valuable.

Career paths are changing, and some engineers are helping shape them.

Most leadership teams haven’t fully figured this out yet. We’re trying to understand what senior engineer even means when juniors with AI can ship features in days. The engineers who show up early to those conversations help define the criteria. The ones who wait find out later what the new bar is.

The shift is happening. Some are steering it. Others are watching it happen to them.

How to navigate this shift

For engineers

The engineers I’ve watched navigate this successfully started by asking themselves uncomfortable questions. What would your job look like if AI could write all the code you write today? If the honest answer is I’d have nothing to do, that’s a signal worth paying attention to.

Look at the senior engineers you respect. What are they doing with their time? Probably not grinding out features. The ones who made this shift started using AI differently—not just to generate code, but to challenge their solutions, help them brainstorm, identify weak spots in their thinking.

Another question worth sitting with: if you couldn’t touch code for a month, how would you add value? If you can’t answer it, you might need to develop different skills. Not guaranteed to be easy, but beats ignoring the pattern.

For leaders

You can’t force your team to see this shift. But you can create conditions where they’re more likely to notice.

What I’ve seen work: start measuring and recognizing different things. Problems identified and framed clearly. Architecture decisions that prevented future issues. Bugs caught in AI-generated code. Time from problem to deployed solution, not time coding.

The identity piece is tricky. Engineers tie their worth to craft. The leaders who handle this well don’t tell their teams coding doesn’t matter (it does), but help them see they’re moving up the value chain. You’re too valuable to spend time on implementation that AI can handle. I need you focused on problems AI can’t solve.

Some practical forcing functions I’ve seen: require AI usage for routine tasks, make hand-coding the exception that needs justification, pair engineers on problem decomposition before any coding starts.

The emotional resistance is real. Some engineers feel like they’re cheating or losing skills. Acknowledging it directly seems to help. Yes, you’re writing less code. That’s the point. Your judgment is what matters now, and judgment only develops by solving more problems, not by typing more characters.

Engineers who resist aren’t wrong or stupid. They’re measuring themselves by the old scorecard. The work is helping them see a different scorecard, which changes what they optimize for.

Some won’t make the shift. They’ll insist real engineering is code and plateau. I learned my job wasn’t to save everyone. It was to make the pattern visible.

The market is already sorting this out. Companies going AI-native are looking for engineers who can evaluate, architect, prevent, and decide, not just implement. The job descriptions have shifted. The interview questions have shifted. The career paths are shifting.

Some engineers are participating in defining what this looks like. Others are waiting for someone else to decide their value.

Both are choices.

Zero comments about whether the caching strategy will corrupt data when the cache and database get out of sync.

Zero about the race condition you’re pretty sure exists but couldn’t reproduce.

You fix the variable names, swallow your annoyance, add the blank lines. Merge it.

Three weeks later, the caching strategy causes data corruption in production. Everyone reviewed it and nobody actually reviewed it.

The code was the easy part. The humans were the problem. (Btw. this is a case of bike-shedding. More on that later.)

Previous essay covered technical decisions, especially how to diagnose problems, build solutions, think through consequences and the models that help you build the right thing the right way.

This one is about the other half: working with humans who have different context, different assumptions, different blind spots. And recognizing when you’re the one missing something.

These models help make collaboration less painful — for you and for them.

I’ll start with code reviews and feedback, since you encounter them daily and this is your most frequent touch point with other human beings you share the code with.

Code reviews and feedback

Give feedback that actually helps

I’ve seen code reviews range from thorough testing and detailed context to thumbs-up emoji and “LGTM.” My favorite: 3,000 lines of breaking changes with “Sorry, a lot of code. Good luck reviewing this.”

Curse of knowledge

You spent three days implementing the feature. You understand the data flow, the edge cases, the performance tradeoffs. You know why you chose this approach over the alternatives. You know which parts are temporary hacks and which are intentional design decisions.

The code reviewer sees none of this. They see 500 lines of changes across 12 files with a PR description that says “Add user filtering.”

You’re frustrated because they don’t seem to understand the obvious elegance of your solution. They’re frustrated the code makes no sense. Neither of you is wrong. You’re both suffering from the curse of knowledge.

The curse is that once you know something, you can’t unknow it. You can’t remember what it’s like to not understand. What’s obvious to you after three days of implementation is incomprehensible to someone seeing it for the first time.

This shows up everywhere in code reviews. You write a function that’s perfectly clear to you because you know the domain model. The reviewer asks basic questions that feel like they’re not paying attention. They’re not being difficult. They genuinely don’t have the context you spent days acquiring.

Or you’re the reviewer and can’t figure out why they did something the complicated way. You suggest the obvious simplification. Doh.

But after they explain the edge case you didn’t know about, the requirement that isn’t documented, and the reason the simple approach doesn’t work, you get your a-ha moment. You didn’t see it because you didn’t have their knowledge.

The curse works both ways.

The other person isn’t lazy, incompetent, or difficult. They’re just missing context.

A helpful PR description answers the questions the reviewer doesn’t know to ask. What broke? Why this fix instead of the obvious one? What did you try that didn’t work? What’s going to look weird but is intentional?

“Add user filtering” gives them nothing. “Add user filtering because support is drowning in requests for this, tried X but it broke Y, so using Z approach” gives them the context you spent three days acquiring.

Questions reveal gaps better than suggestions. “Can you help me understand why we’re doing X?” opens a conversation. “This should be Y” starts an argument (that can become a war with keyboard warriors).

You might be right that it should be Y. Or you’re missing the context that makes X necessary.

The curse of knowledge is invisible to you. You don’t know what you know that others don’t know.

Chesterton’s fence

I talked about Chesterton’s fence before, in the context of legacy processes and organizational decisions. The same principle applies to code.

If you see a fence across a road and don’t know why it exists, don’t tear it down. Maybe it’s pointless. Maybe it’s preventing cattle from wandering. You don’t know until you ask.

You’re reviewing a PR. There’s a weird check: if (data && data.items && data.items.length > 0) when a simple if (data.items?.length) would work. Looks like the author doesn’t know modern JavaScript. You suggest the cleanup.

They explain that production data sometimes has items: null instead of an empty array. The old API returned null, the new API returns empty arrays, but during migration both formats exist. The verbose check handles both. Your improvement would crash on legacy data.

Yep, the fence was there for a reason.

Or you’re refactoring old code and find a function that seems to do nothing. Just passes data through with what looks like unnecessary transformation. You delete it. Tests pass. You ship it. Three days later, reports are broken. The unnecessary transformation was handling a specific date format from an external API that only shows up in monthly reports. The daily reports use a different format. Your tests only covered daily data.

In code, the fence is any logic that seems wrong, unnecessary, or overly complicated. The check that looks redundant, the comment that seems obvious, the abstraction that feels like overkill, or the duplicate code that should be DRYed up.

Someone put it there. Maybe they were wrong, but maybe they were solving a problem you haven’t encountered yet. Maybe there’s a bug that only triggers in production. Maybe there’s a requirement that isn’t documented. Maybe there’s an edge case in data you haven’t seen.

I’ve seen engineers remove dead code that was handling a quarterly batch job. Delete unnecessary validation that was preventing a security issue. Simplify overcomplicated logic that was working around a database limitation. The code looked wrong because they didn’t have the context.

The shortest path to investigate is git blame, find the PR that added it, talk to the person who wrote it (if they’re still around), or search for related bug reports or incidents.

If you can’t find a reason and it seems genuinely pointless, the safer move is proposing removal while acknowledging uncertainty.

The code might be bad. Or you might not understand the problem it’s solving. Worth finding out which before tearing down the fence.

Hanlon’s Razor

Engineer submits a PR with a for loop instead of the functional map/filter chain you’d use. Your first thought: they don’t understand functional programming. Your comment: “This should use map/filter.”

When they respond, you learn that the dataset can be 100k items and the functional approach creates intermediate arrays that blow up memory. They profiled it. The for loop is 10x faster and uses a fraction of the memory.

You assumed incompetence, but the actual reason was performance optimization based on production data. Apology accepted.

There’s a better approach here—one that keeps code reviews collaborative instead of adversarial. Use Hanlon’s Razor (sounds familiar?) and interpret someone’s actions in the most reasonable way possible before assuming the worst.

If their code looks wrong, assume they had a reason before assuming they’re careless. Never attribute to malice or incompetence that which is adequately explained by different information, constraints, or incentives.

Someone uses a library you think is overkill for the problem. Maybe they know the requirements are expanding next quarter and the library handles the future cases. Maybe they tried the simple approach and hit limitations. Maybe there’s context you’re missing.

The opposite is assuming the worst possible interpretation.
“They wrote this because they’re lazy.”
“They didn’t follow the pattern because they don’t care about consistency.”
“They hardcoded this because they can’t think abstractly.”

Sometimes people are lazy. Sometimes they don’t care. But starting there kills useful discussion. They get defensive. You get frustrated. And the code? Doesn’t improve.

Start with thinking they must have had a reason. Ask what it was.
“I’m curious why you chose this approach instead of X?” is way more productive than “This should be X.”
The first one opens a conversation. The second one, if not careful, could escalate into a war.

Yes, maybe their reason is bad, or maybe they didn’t think it through. But asking gives them a chance to explain. If the explanation doesn’t make sense, you can discuss it. If they don’t have a good reason, they’ll often realize it themselves when they try to articulate it. The human version of rubber duck debugging works in code reviews too.

Charity doesn’t mean accepting bad code. It means assuming the person is trying to do good work and starting from there. Ask first, judge second. This way you’ll have to buy lunch less frequently.

Bike-shedding

Remember that PR from the opening? Three days in review, twelve comments about variable naming, zero about the caching strategy that eventually corrupted production data? That’s bike-shedding.

Here’s another: A PR comes in with a database migration to add a new payment processing table. Changes the schema, adds foreign key constraints, includes a data migration script that will run against production. If this goes wrong, payment data could be corrupted or lost.

But the review? Eight comments about table naming conventions. Four about whether to use snake_case or camelCase for column names. Two about index naming patterns. Zero about whether the migration is reversible. Zero about what happens if it fails halfway through. Zero about whether the foreign key constraints will lock the table during deployment.

Everyone has an opinion on naming conventions. Nobody wants to admit they’re not entirely sure how the migration rollback works.

Bike-shedding is spending disproportionate time on trivial decisions because they’re easy to have opinions about. The term comes from a committee designing a nuclear power plant spending hours debating what color to paint the bike shed while approving the reactor design in minutes. Everyone understands bike sheds. Nuclear reactors are complicated.

In code reviews, bike-shedding looks like focusing on style, formatting, naming, and other surface issues while ignoring architecture, security, performance, and correctness. The trivial stuff is easy to comment on. The hard stuff requires thought.

You’re doing it too. You see a complex PR, you’re not entirely sure you understand all the implications, so you comment on the parts you do understand. Formatting. Naming. Simple logic. It feels productive. You’re contributing to the review. (You’re not.) You’re avoiding the hard questions. Commenting on variable names is easier than admitting that you don’t fully understand how this refund flow works.

When getting only trivial comments as the author, asking explicitly for the hard review helps.
“This migration is risky. Please review the rollback strategy and error handling carefully.”
Tells reviewers where to focus instead of letting them debate naming conventions for an hour.

If you see lots of comments about formatting and zero about correctness, this is a clear sign of bike-shedding. Nobody really reviewed the hard parts. Everyone’s just hoping someone else did.

Good news: now you know how to spot this pattern, you can be the one who breaks it.

Collaboration

Work effectively with humans who aren’t reviewing your code

Code reviews are only one form of collaboration. The rest happens when you’re debugging, coordinating across teams, explaining what you’re building to people who don’t write code.

I know—you’d rather lock yourself in a dark room with the lights off and just code. “Just let me work. Just let me write code.” But you can’t. (It’s a whole aesthetic.) The work requires talking to people who have different context, different constraints, different information than you do.

These models help you do that without wanting to crawl back into the dark room.

Rubber duck debugging

Someone on my team gets stuck. I notice and ask if they need my help. They might smirk, because I don’t know the details of what they’re working on. But I don’t need to. I ask them to walk me through it. They start explaining. I listen without interrupting. Or if opportunity arises, I ask what sounds like a stupid question: “Wait, so when does this error actually happen?” or “What are you expecting to see instead?”

These questions are never as stupid as they sound. They’re usually the question the person forgot to ask themselves, or they break the loop of thought they’ve caught themselves into.

Halfway through explaining, they stop. “Hmmm. I think I know what it is....” They’ve hit their aha moment. The mental barrier breaks. I didn’t solve their problem. They solved it by having to explain it clearly enough for someone who doesn’t know the context. No need to finish this conversation. Let them pursue the next clue. If they look focused, quietly leave.

This is rubber duck debugging. The classic version involves explaining problems to a literal rubber duck on your desk.

The human version is better. And more convenient. You will look less like a nerd talking to a person than talking to an inanimate rubber object.

Why it works? Explaining a problem out loud forces you to organize your thoughts. You think you understand it. Then you try to explain it and realize you’re unclear about a key detail. Or you’re making an assumption that doesn’t hold. Or you’re debugging the wrong part of the system. Speaking it out loud makes the confusion visible.

It works even when the listener doesn’t know the domain.

Being the listener means not solving the problem. It means asking clarifying questions and giving the person space to think out loud. Simple questions often trigger them to see what they missed. Sometimes the best help is just being there while someone works through it themselves.

When you’re stuck, find someone. A coworker. A manager. Someone who has no idea what you’re talking about. Explain the problem like they know nothing about it. Odds are you’ll solve it before you finish explaining.

Information asymmetry

PM files a request: “Users on the higher plan should be able to turn their own favicons on or off. Just add a toggle.”

Backend starts implementing. They dig into the code. Turns out this favicon functionality depends on three other toggles with mutually exclusive logic rules. It’s not just a toggle. They’d have to add completely new functionality and untangle a web of interconnected conditions.

Backend estimates it will take a couple of days to properly rewrite the rules.

PM response: “Why is this taking so long? It should be an hour.”

PM’s manager agrees. It’s one toggle. What’s the problem?

Three meetings and detailed code walkthroughs later, everyone finally understands: if you want this “simple toggle,” you have to unravel years of tangled conditional logic.

This is information asymmetry. You each have context the other doesn’t. PM knows what users need. Backend knows the technical reality. Neither of you knows what the other knows.

This happens everywhere in engineering. Product knows user needs but not technical constraints. Backend knows database limitations but not what the frontend is trying to build. Infrastructure knows deployment complexity but not why the feature is urgent. Everyone operates with incomplete information and assumes the other side sees what they see.

There are meetings and there are meetings. More meetings won’t save you from information asymmetry, but better ones might. Or better yet: provide context in task descriptions and specs. Include it in kickoff meetings when explaining what you’re building and why, so engineers understand the problem space and constraints before they start with the implementation.

“We need this toggle because higher-tier users are asking for more control over their branding. It’s part of the enterprise package we’re launching next quarter.” Now backend knows why it matters. They might suggest: “We can ship a simplified version now and refactor the toggle system properly over the next sprint.” You get a solution. They avoid rushing a mess into production. Everyone wins because the context was shared.

Or you’re debugging a cross-team issue. Frontend says the API is returning errors. Backend says they’re seeing successful requests in the logs. You’re both looking at different data. Frontend is looking at client-side errors from network failures. Backend is looking at server logs that only capture requests that reached the server. The errors are happening before the request gets there. Neither team had visibility into the full picture.

Information asymmetry makes collaboration slow and frustrating. You repeat questions because the answer assumed context you don’t have. You make decisions that seem obvious to you but break things for another team. You wait for responses to questions that could have been answered in the original message if the context had been included.

Sharing context proactively closes the gap. Explaining why when asking for something. Documenting what you considered when making decisions. Sharing what you’re seeing when something goes wrong, not just your conclusion.

The other team isn’t being difficult. They’re working with different information.

Brooks’s law

Project is late. You’re two months behind schedule and the deadline isn’t moving. Management’s solution: add three more engineers to the team. Get this thing shipped. Surely more people means more throughput, right?

(It does not. And nine women still can’t give a birth to a child in one month.)

The new engineers join. You spend the first week getting them set up. Development environments. Access to systems. Explaining the architecture. Answering basic questions about how things work.

Second week: they’re trying to contribute but their PRs need heavy review. They don’t understand the domain deep enough. You’re spending more time reviewing their code than you would have spent just writing it yourself.

Third week: they introduce a bug because they didn’t know about a critical edge case. You spend two days debugging and fixing it. You’re now further behind than when they joined.

Brooks’s law from The Mythical Man-Month (1975) states that adding people to a late project makes it... later. Math is hard when it involves humans. The ramp-up time and communication overhead outweigh the productivity gains. This is counterintuitive. More people should mean more work getting done. In software, it often means less.

Every person you add increases communication paths exponentially. Three people mean 3 communication paths. Four people are 6 paths. Five people are 10 paths. Ten people: 45 paths. The coordination overhead grows faster than the productivity.

New team members need training. They need context. They need to understand the codebase, the domain, the team practices, the deployment process, the debugging techniques. Someone has to provide that. Usually the people who are already behind.

This doesn’t mean never add people. It means adding people has a cost and a delay before you see benefits. If you’re three months behind and add people, expect them to slow you down for the first month, break even in the second month, and start helping in the third month. If your deadline is in two months, adding people makes you miss it.

What actually helps late projects is (surprise, surprise!) cutting scope, extending deadlines, or fixing blockers that slow down the existing team. More people helps future projects. It doesn’t help the fire you’re currently fighting.

If you’re already behind and they’re adding team members anyway, set expectations. The new people will slow you down initially. You’ll miss the deadline you’re already going to miss, just by more. Then, three months from now when you’re working on the next thing, you’ll have a bigger team that’s actually productive. Tell management this now so they can act surprised later when it happens exactly as predicted.

Adding people is an investment in future capacity, not a fix for current delays.

Bus factor

Your senior engineer goes on vacation for two weeks. On day three, the authentication service breaks. Nobody else on the team knows how it works. The person on vacation wrote it. They’re the only one who’s touched it. They’re unreachable because they’re actually on vacation, which you’re now ruining with urgent Slack messages and desperate SMS messages.

In this case your bus factor is one. If that engineer gets hit by a bus (or goes on vacation, or quits, or gets sick), you’re in trouble. The bus doesn’t even need to be literal. A two-week vacation will do the same, but luckily it is less terminal.

When you figure out how many people need to disappear before your project fails, this is your bus factor. It’s morbid but accurate. If the answer is one, you have a single point of failure in your team. Time to add some redundancy.

This happens with critical systems that one person maintains, but it also happens with knowledge. The person who knows why the database is configured this way or the person who understands the contract with the external API, or the person who can debug the performance issues because they profiled the system two years ago. When they leave, that knowledge leaves with them.

Having experts own their domains feels efficient. It’s also fragile. Everything works perfectly until the expert goes on vacation... or decides to go on a different kind of vacation... like in another company? If you figure out then that you have a problem, well, you definitely have a big problem. Most likely the world won’t stop spinning, but it will slow down the company significantly.

Redundancy or at least partial overlaps of knowledge/ownership of critical systems are a must. Non-negotiable.

If you can’t get leadership support, do a bus factor dry-run: check out for a couple days (but keep an eye on Slack) and let them figure out how to solve things. Make it their problem, because ultimately it is their problem.

High bus factor isn’t about everyone knowing everything. It’s about critical things being understood by at least two people. The authentication system should have a primary owner and a secondary who’s contributed to it, reviewed the code, and could maintain it if needed. The deployment process should be documented well enough that two people can run it.

Pair programming helps. Code reviews help. Documentation helps. Cross-training helps. Rotating responsibilities helps. Anything that spreads knowledge from one person to at least one other person.

You know your bus factor is too low when you think I can’t take vacation because nobody else can handle X or when someone leaves and you panic about what they were working on.

When the bus factor for something critical is one, it needs fixing before the bus shows up. Have someone else pair on the next change. Document how it works. Do a knowledge transfer. Get the count to two.

One is not a team. It’s a dependency. A critical one.

Premature consensus

Team meeting to decide on the new architecture. The tech lead suggests microservices. Everyone nods. Sounds good. Makes sense. Let’s do it.
Meeting done in under an hour. Everyone’s aligned. You give yourself a pat on the back. Very efficient. We must be geniuses. Efficient geniuses.

Six months later, you’re drowning in service coordination complexity, distributed debugging, and deployment orchestration. Someone asks: “Why did we go with microservices again?” Nobody has a good answer. Everyone agreed at the time. Efficiently agreed, even. (Very efficient disaster.)

So what happened? Premature consensus. Agreeing without actually discussing. It looks like alignment but it’s really conflict avoidance. Nobody wants to be the person who slows down the meeting by asking hard questions. Nobody wants to disagree with the tech lead. So everyone says yes and you move forward with a decision that wasn’t really examined.

You see this in architecture decisions, tooling choices, process changes. Someone proposes something. It sounds reasonable. Nobody has strong objections they’re willing to voice. Agreement. Done. You like to move fast after all.

So, where’s the problem? The problem is that agreement without discussion creates fragile decisions. You didn’t explore alternatives. You didn’t stress-test the assumptions. You didn’t think through the second-order effects. You just said yes because it was easier than saying wait, let’s think about this.

Six months later when the decision turns out poorly, nobody remembers why you made it. It seemed like a good idea at the time is the post-mortem conclusion.

Real consensus requires disagreement first. Someone needs to ask: “What are we giving up with this approach? What are the alternatives? What could go wrong? Why is this better than the simpler option?”

If nobody asks those questions, you’re not getting real buy-in. You’re getting polite compliance.

The tech lead suggests microservices. Someone asks: “What problem are we solving that requires microservices? Would we be better off with a modular monolith first?” Now you’re discussing tradeoffs. Someone else: “How will we handle distributed debugging?” Now you’re thinking through operational complexity. Someone: “Do we have the team size to maintain multiple services?” Now you’re considering capacity.

Maybe you still choose microservices. But now you’ve examined alternatives, considered the costs, and thought through the problems. The decision is stronger because it survived scrutiny.

Fast agreement in meetings is a signal. It often means people aren’t thinking it through. When major technical decisions get consensus in under 30 minutes, scrutiny is probably missing.

Disagreement isn’t bad. It’s how you find the holes in the plan before you build it. Refresh your memory about mental models like Devil’s advocate that can help you with intentional dissent and detect groupthink.

Self-assessment and blind spots

Know what you don’t know

You’re most dangerous when you don’t know what you don’t know. Camping on Mt. Stupid hurts you and everyone around you.

Dunning-Kruger effect

I’ve touched upon Dunning-Kruger effect in the essay for leaders, but it’s worth revisiting for ICs.

Sometimes it will seem like you’re ascending and descending its slopes daily, especially when working on demanding and complex problems.

In case you haven’t heard about it: Dunning-Kruger effect describes how you’re most confident when you know the least. Beginners overestimate their competence because they don’t know enough to recognize what they’re missing. Experts underestimate their competence because they know how much they don’t know.

You learn the basics of a technology and think you’ve mastered it. But you’ve learned enough to be dangerous. You can build something that works. You haven’t learned how to build something that works at scale, or handles edge cases, or performs well, or is maintainable.

Junior engineer learns SQL and thinks databases are simple. Writes queries that work in development with 100 rows. In production with 10 million rows, everything times out. They didn’t know about indexes, query planning, or database optimization.

Or you read about microservices and decide your monolith should be decomposed. You haven’t dealt with distributed debugging, service coordination, eventual consistency, or deployment orchestration. You know the benefits. You don’t know the costs because you haven’t experienced them. YOLO. (No, please don’t YOLO on this one.)

Confidence peaks early when you know just enough to build something. Then it drops as you discover how much you don’t know. Eventually it rises again as you develop expertise.

The dangerous zone is the peak also called Mount Stupid. You know enough to make decisions but not enough to make good ones. You’re confident but incompetent. This is when you propose rewriting the entire backend in the new framework you learned last week.

If you’re feeling very confident about something you learned recently, you’re probably on the peak. I just learned X and it seems straightforward. If someone with more experience snorts at this statement, you’re definitely there. The moment you think you’ve mastered something is probably the moment you’ve barely started understanding it. The descent through the valley of despair is inevitable. The climb back up the slope of enlightenment just comes with more humility.

When Ikea effect and NIH syndrome have a baby

Three weeks building a custom state management solution. It handles your exact use case perfectly. Someone suggests using Redux. Your reaction: Redux is overkill. My solution is simpler and works better for what we need.

Is it actually better? Or do you just think it’s better because you built it? Hard to know when you’re the one who built it.

You might be under the influence of Ikea effect bias. You overvalue things you created yourself. The effort you put in makes you attached to the outcome, even when objectively better alternatives exist.

You built the furniture yourself. It’s wobbly and the drawers don’t close right, but you love it because you made it. Someone suggests buying a better one. No way. This one is special. (You know which drawer needs the exact angle to open. That’s craftsmanship.)

Same with code. You wrote a library that solves a problem. It works. Someone points out there’s a well-maintained open source library that does the same thing, handles more edge cases, and has better documentation. You defend your library. It’s lighter weight. We control it. It’s tailored to our needs.

Maybe those reasons are valid. Maybe you’re just attached to your creation.

This is why engineers resist throwing away their code. You spent days or weeks building it. Deleting it feels like wasting that effort. So you keep it even when it’s not the best solution.

Or you’re refactoring and someone suggests removing a complex abstraction you built. Your first instinct is to defend it. It’s needed for future extensibility. Is it though? Or did you spend time building it and now you can’t let it go?

The Ikea effect makes you blind to better alternatives. You’ve invested effort, so you rationalize why your solution is correct instead of objectively evaluating it. Loss aversion kicks in.

Would you choose this solution if you hadn’t built it yourself? If someone else wrote this library or this abstraction, would you use it? If the honest answer is no, the Ikea effect is at work.

The length of your defense is a signal. When you find yourself explaining at length why your custom solution is better than the standard tool, you’re rationalizing, not evaluating. Let someone else look at it. They don’t have your attachment.

The code is a tool, not a baby. The effort spent building it taught you something. That was the value. The code itself is replaceable.

Team needs a solution for handling background jobs. There are mature, well-tested libraries: Sidekiq, Bull, Celery. Your team decides to build their own.

“We have specific requirements.” (Translation: “We want to build it ourselves.”)
“The existing tools are too heavy.” (Translation: “We haven’t actually evaluated them.”)
“It’ll be simpler to build exactly what we need.” (It will not be simpler.)

Six months later, you’re debugging race conditions, handling failed jobs, implementing retry logic, building monitoring, and dealing with edge cases the existing libraries already solved. You’ve most likely rebuilt a worse version of something that already existed.

Not invented here (NIH) syndrome is rejecting external solutions because you didn’t build them. AKA if we didn’t make it, it can’t be right for us.

This is different from the Ikea effect (overvaluing what you built). This is refusing to use what others built.

You see a library that solves your problem. Your first instinct: How hard can it be to build this ourselves? Often the answer is harder than you think. The library handles cases you haven’t encountered yet. It’s been battle-tested in production. It has community support and documentation. Your version will have none of that.

But you build it anyway. Building your own is more satisfying than using someone else’s solution.

Or another team at your company built a tool that could work for you. You reject it: Their use case is different. It’s not exactly what we need. We’d have to change our workflow. So you build your own. Now you have two tools doing the same thing, both with partial solutions, neither as good as if you’d combined efforts.

The cost isn’t just the time building it. It’s the ongoing maintenance, the bugs you’ll hit that the mature tool already fixed, the features you’ll eventually need that the existing tool already has.

Sometimes building is the right choice. If the existing tools truly don’t fit your requirements. If the dependency adds more complexity than building. If you need something so specific that customization would be harder than starting fresh. Sometimes.

But most of the time, the appeal of building outweighs the practical case for it. Which is fine for side projects. Less fine when you’re six months in, debugging race conditions the mature library already solved.

If the existing solution came from inside your company instead of outside, would you use it? If yes, the problem isn’t the solution, but more likely where it came from.

Boring technology and proven libraries maintained by other people, that’s how you free up effort for problems unique to what you’re building. Let’s keep Ikea effect from having babies with NIH syndrome, nothing good will come of this.

Peak-end rule

Your memory doesn’t average experiences. It anchors on peaks and endings.

Six months on a project. Most of it was fine. Normal progress, normal challenges, nothing dramatic. Then the last two weeks were a disaster. The deployment failed three times. You worked late nights debugging and the launch was rocky.

When someone asks how the project went, you say: It was rough. You remember the disaster, not the six months of steady work. Those six months might as well not have happened. Your brain decided the last two weeks are the whole story. (If they’d asked in month four, you’d have said it was fine. But they didn’t ask in month four.)

This affects how you evaluate everything. A colleague is helpful for months, then snippy in one code review. You remember them as difficult. A project goes smoothly for weeks, then hits one major issue. You remember it as problematic.

The reverse too. A project is a grind but the launch goes well. You remember it as a success. A teammate is frustrating to work with but comes through in a crisis. You remember them as reliable.

You’re doing this to yourself too. You worked hard all quarter, shipped three features, then made one mistake at the end. When performance review comes, you focus on the mistake. Your manager might remember the steady delivery. You remember the peak moment of stress.

Or you’re debugging an issue for hours. Frustrating, stuck, making no progress. Then you solve it in the last fifteen minutes. The experience feels satisfying because it ended well. If you’d given up at hour three, you’d remember it as wasted time. Same three hours, different ending, completely different memory.

Last impressions matter in code reviews, project retrospectives, and team interactions. The last thing that happens shapes how the entire experience is remembered.

The ending matters disproportionately. Meetings that end with clear next steps feel productive. Code reviews that end with acknowledgment of what worked well feel collaborative. Retrospectives that acknowledge what went right before diving into problems leave people energized instead of demoralized. Same content, different order, completely different memory.

When evaluating something, the average should matter more than the peaks and ending. Was the project actually bad, or did it just end badly? Is the person actually difficult, or did they just have one rough interaction?

Your memory is a highlight reel, not a documentary. Make sure you’re judging the full story, not just the clips that stand out. No need to treat the work as Instagram.

I’m repeating myself

You probably don’t need all of these at once. Pick one model. Notice when it applies. Course-correct before the pattern becomes expensive. Yeah, yeah, I’m repeating myself.

You can’t eliminate these patterns. They’re human. The goal is catching them earlier.

Engineering isn’t just solving technical problems. It’s collaborating on solutions, reviewing each other’s work, and being honest about what you know and don’t know.

Now go build something great together.

I work with engineers daily. I give them tasks, priorities, constraints. But I also want to give them tools. Mental models that help them manage complexity, question bad approaches, and push back when I’m wrong. These aren’t just frameworks for writing better code. They’re frameworks for navigating technical decisions when the path isn’t clear.

This essay walks through the lifecycle of technical work: diagnosing problems correctly, building the right amount, thinking through consequences before committing, and knowing when to kill approaches that aren’t working.

The thinking tools are universal. But engineering decisions have specific failure modes. Choose the wrong architecture? Months untangling it. Skip root cause analysis? The bug returns in different forms. Over-engineer for imaginary scale? Complexity you can’t maintain.

I count on my engineers to be strong sparring partners. To push back when the approach is wrong. To question constraints that don’t make sense. To call out when we’re optimizing for the wrong thing. These models give us shared language for those conversations. You can point at second-order effects I’m not seeing. I can ask if we’re stuck in a local optimum. We both get better outcomes when we’re using the same frameworks to think through problems.

The feedback loops in engineering are long. By the time you realize the pattern, you’ve made the expensive mistake. That’s why these models matter.

Technical problem-solving

Fix the root cause, not just the symptom

Root cause analysis

The alarm goes off at 2 AM. Again. You log in, check the dashboards, see which service crashed. You restart it. Maybe move some jobs to a different queue. Maybe bump up the instance resources. The customers stop complaining. The metrics look better. You go back to bed.

Three days later, same alarm. Same service. Same fix. Back to bed. At least you’re getting consistent practice at 2 AM deploys.

I watched a team do this for weeks. Distributed system, multiple services, queues backing up, customers reporting issues. Late-night calls became routine. Tweak the resources, restart the service, move the jobs. We’d mitigate, then rush back to project work the next day. Nobody had time to actually investigate. We were too busy with other stuff.

But then the poor soul who’s been walking around like a zombie, escalated things. No more patching! No money can give you back your sleep. So leadership had no other choice than to carve out the time, and I’m talking about weeks, not days. Pulled the best engineers from affected teams, put them in one room, same table, shared focus. There were no more “I’ll ping the other team when they have time.” and no fragmented efforts where one team has partial information and the other is underwater.

The root causes? Many. Single points of failure. Services that weren’t built to handle auto-scaling. Architecture not robust enough for temporary spikes. Every fix we’d done treated symptoms. The system was fundamentally broken for the load pattern it was experiencing.

Teams had tried to solve it before. But efforts weren’t aligned. One team would investigate their piece, hit a wall, try to coordinate with another team that didn’t have bandwidth. The investigation would stall. Putting everyone in one room changed that. The obstacles that had blocked months of fragmented investigation disappeared in days of coordinated work.

You’re treating symptoms but the system keeps creating the same problem in different forms. The bug you see keeps coming back because the structure underneath keeps producing bugs. Root cause analysis is detective work. Columbo asking “just one more thing.” Sherlock seeing what everyone else missed. Poirot insisting the details matter. Instead of “how do I make this go away right now?” the question changes to “what’s creating this outcome?”

The fix isn’t always obvious. Sometimes it requires weeks of investigation. But you know you need to apply this model when the same problem keeps coming back, when you’ve fixed it three times and it appears again, when you see different symptoms with the same underlying issue, when your solution only works temporarily.

We know that patching symptoms feels productive, since you are fixing things and the metrics do look better. But you’re running in place. Find the root cause and fix it once, or keep patching it forever. One uses a few weeks now, the other uses a few hours every month indefinitely. The math isn’t that complicated.

Five Whys

If root cause analysis tells you to find the underlying problem, Five Whys is how you actually get there.

Keep asking “why?” until you stop getting new information. Most people stop at the first or second why. That’s where you find symptoms, not causes.

We had a service causing issues.
“Why is it failing?”
Response timeouts.
Okay, increase the timeout. That’s stopping at why #1. You’ve addressed a symptom.

“Why are responses timing out?”
Too many requests hitting the service at once.
Okay, add rate limiting. That’s stopping at why #2. You’ve made the symptom more manageable, but you haven’t fixed the problem.

“Why are too many requests hitting at once?”
The frontend is polling every second instead of using webhooks.
Now you’re getting somewhere.

“Why is it polling?”
Because nobody questioned the original implementation when requirements changed.

“Why didn’t we revisit it?”
Because the system “worked” and there was always something more urgent.

Now you see it. Timeouts are a symptom. Request volume is closer but still not it. The actual root cause is a design decision that made sense once and became technical debt when context changed.

Stop at why #2, you add rate limiting and call it solved. The service still struggles, just slightly less. Push to why #5, you replace polling with webhooks and the problem disappears.

Each “why” peels back another layer. The first few whys give you symptoms and proximate causes. The deeper whys reveal the structure creating the problem. You know you’ve gone far enough when the answer points to something you can actually fix, not just mitigate.

The early answers feel like solutions. Increase the timeout, add rate limiting, done. But then the problem comes back wearing a different mask. Keep asking why until you hit something structural… or until your PM asks why you’re still investigating a “fixed” issue. Then you know you’re onto something.

Occam’s Razor

We have a complicated relationship with complexity. It’s our mistress. A database query is slow, so you start planning the caching layer, the read replicas, the query optimization strategy. You’re three days into the architecture doc when someone asks: “Did you check if there’s an index on that column?” There wasn’t. You add the index. Problem solved.

One line of SQL. Three days of your life you’re not getting back.

The API is unreliable. You start designing retry logic, circuit breakers, fallback mechanisms. The timeout is set to 2 seconds for a query that takes 5 seconds to complete. You increase the timeout. Done.

Product managers do this too. They design elaborate user flows with branching logic, conditional states, multiple steps. What if you just put both options on the same screen? Simpler flow. Better UX. Less code. Boom.

When facing a problem, we reach for complex explanations. Distributed system issue. Race condition. Architectural flaw. The timeout being set to 2 seconds? That’s too boring to be the answer.

Occam’s Razor says start with the simplest explanation first. Check the basics before you architect the sophisticated solution. Missing index before database migration. Configuration before code change. Simple UI before complex flow.

Senior ICs recognize this because they’ve built the complex solution that wasn’t needed. They have the scar tissue. They ask the dumb questions that reveal the simple fix everyone else missed while architecting the elaborate workaround.

Check the simple thing first. If that doesn’t work, then you’ve earned the right to get complex.

Those models help you diagnose problems correctly. The next set helps you build solutions that don’t become tomorrow’s problems.

Code quality

Build for the problem in front of you

Premature optimization

You know the game from the 1980s, “The Incredible Machine”? Rube Goldberg contraption where a ball rolls down a ramp, triggers a lever, releases a spring, which launches a bucket, which tips over and... eventually accomplishes one simple task through fifteen moving parts.

We’ve all seen codebases that look like this. Features that resemble elaborate chain reactions, with components glued together, each one anticipating some future use case that doesn’t exist yet. You want to change one thing and you’re touching seven files because someone built it to be flexible.

Or the engineer who refactors a component into an abstract, generalized version before anyone knows if the approach even works. Now you’re experimenting, trying to figure out what users actually need, and every iteration takes a week instead of hours because you have to navigate the abstraction layer someone built for imaginary future requirements.

The justification sounds smart:
We’ll need to scale eventually.
We should build this right from the start.
This is how big companies do it.
What if we need to support multiple use cases?

Then comes reality.

You build for 10,000 users when you have 10. You architect microservices when a monolith would work. You design elaborate error handling for edge cases you haven’t encountered. You abstract before you understand the pattern.

The time building it is one cost. Then there’s the ongoing maintenance. The debugging complexity. The deployment overhead. The new engineer who asks “why is this so complicated?” and the answer is “we thought we’d need it someday.” That day never came. The complexity is still here.

Make it work first. Then make it right. Then, if you actually need to, make it fast. Most code never needs the third step. You’re solving for imaginary scale, imaginary flexibility, imaginary future requirements that change before you get there anyway.

The future you’re over-engineering for has a funny way of not showing up. Or showing up completely different than you planned.

Build for the problem in front of you and a couple of steps ahead, not the problem you imagine you’ll have later. You can refactor when you actually understand the patterns. You can scale when you actually need to scale. The code you write today will probably change before you hit the scale you’re optimizing for.

Performance is one part of premature optimization. There’s also premature abstraction, premature architecture, premature complexity. You’re not building a Formula 1 car to drive to the grocery store. You’re building the minivan.

Overfitting

An engineer sees five UI variations during customer testing and builds one abstract component to handle them all. The component has configuration for each specific variation they observed: button placement options that map to cases 1-3, dropdown behavior for case 4, validation rules for case 5. When case 6 needs a button with a tooltip, the abstraction doesn’t fit. The component was built for those five specific cases, not for UI variations in general. Adding the tooltip means reworking logic all five existing cases depend on. What should take an hour takes days because the abstraction is fitted to the examples, not the pattern.

I’ve seen this across multiple companies. Smart engineers trying to reduce duplication, seeing patterns early, abstracting before they understand what’s actually common versus what just happened to be similar in the first few cases.

The authentication flow that works perfectly for a B2C product with millions of users gets applied to an internal tool with 50 employees. Now you have OAuth, SSO integrations, password complexity requirements, and multi-factor authentication for a tool that could have used basic auth. The solution was built for different constraints, e.g. public-facing, high-security, massive scale. Here you’ve got a trusted internal network and a handful of users who just want to log in and get work done.

You look at what you have right now and build for that. The solution works perfectly for the examples in front of you. Then case six shows up and you realize you’ve done the machine learning thing - optimized for the training set, failed on real data.

Wait for the pattern to emerge before you abstract. Three examples might be a pattern. Or they might be three different problems wearing similar clothes. You’ll know the difference by the fourth or fifth case.

Unforced error

One-line change, maybe a configuration tweak or a small refactor that touches three files. So obvious, so clean, and so trivial that running the full test suite feels like… overkill?

You know you should run it. That’s the rule. But this change is too simple to break anything. You skip the tests, merge, and deploy.

Then production breaks. Unfortunately, not in some unpredictable way or because of a race condition nobody thought about. It breaks in exactly the way the tests would have caught. The test that runs in 30 seconds would have told you the problem. Now you’re rolling back, explaining to everyone on a post-mortem meeting why you skipped the step everyone knows to do, and customers were seeing errors. Famous last words: “This change is too simple to break anything.”

It happens to all of us, but it should not be happening. You’re under pressure, moving fast, feeling confident. The step feels like overhead, so “just this once” you skip it. Maybe you shouldn’t… unless you like bonding on prost-mortem meetings. They might become tad less blameless after a while.

Another good example are merge conflicts. You’re merging your branch and Git shows conflicts in a file. You should read both sides carefully, understand what changed, make sure you’re keeping the right code. But you’re in a hurry with three other PRs waiting, and you just want this done. You scan it quickly, accept current or incoming without really thinking.

Then you realize you just overwrote someone else’s fix. The bug they spent two days tracking down is back. Someone asks in Slack: “Wait, didn’t we already fix this?” You check the Git history and see what you did. Ouch. You owe them lunch, at least.

What makes these painful is that you knew the step mattered. You had the checklist, you had the process, but you decided it didn’t apply this time. Nobody forced the mistake. You created it by skipping what you knew you should do.

Tests are cheap insurance. The 30 seconds you save by skipping them buys hours of cleanup, embarrassing Slack explanations, and a mental note that you’ll definitely run tests next time. (You will. Until you don’t.)

Building the wrong thing is one problem. The other is building the right thing without thinking through what it breaks.

Design and architecture

Think through consequences before committing

Second-order thinking

The API is slow. Users are complaining. You add a caching layer. Responses are fast now. Problem solved, right?

Then the bug reports start coming in. Users seeing stale data. Someone updates their profile, it doesn’t show. Someone deletes a record, it’s still appearing. You realize you need cache invalidation. So you build invalidation logic. Now you’re debugging whether the bug is in the application or in the cache. “Is this real data or cached?” becomes a question you ask daily. The cache also hides the actual problem: a database query that should have been optimized. You made responses fast without fixing why they were slow. You’ve added a layer of complexity that you’ll maintain forever.

You stopped at caching makes it fast without asking “what problems does caching create?”

The microservice extraction follows similar logic. A module is getting large, hard to navigate, maybe slowing down deployments because the whole app has to redeploy. Extract it to its own service. Now that module can deploy independently. Clean boundaries. Feels good.

Then you hit the second-order effects. What used to be a function call is now a network call that can timeout or fail. You need retry logic, circuit breakers, fallback behavior. Deployments need coordination between services. A bug that crossed the service boundary? You’re looking at logs in two places, tracing requests across services. Data that used to be consistent in one database is now split across service boundaries with eventual consistency problems causing eventually consistently gray hair.

Applying microservices because they worked at a company with 100 engineers when you have… what five? You’re combining two mistakes. Fitted solution to different constraints plus ignoring second-order effects. Microservices give us independence sounds good until you realize you don’t have the team size or tooling to manage the complexity they create.

Most not-particularly-good architecture decisions solve the immediate problem while creating bigger ones. The solution works, technically. You just didn’t think through what it costs to maintain or what breaks downstream.

Before committing to the solution, ask: what problems does this create? What’s the maintenance burden? What breaks if this fails? What new dependencies am I adding? The questions are boring, but the answers save you from clever solutions that become your team’s least favorite legacy system.

Cost-benefit analysis

Your framework is old. The new (breaking changes) version has better performance, modern features, cleaner APIs. The migration guide looks straightforward. You pitch it to the team: Let’s upgrade.

Then you start counting the cost. Three months of migration work. Bugs during the transition period. Learning curve for the team. All feature work pauses or slows down significantly. You’re telling stakeholders that nothing new ships for a quarter so you can upgrade to a framework that makes the app... slightly faster and nicer to work with.

Is it worth it? Maybe. Maybe not. Depends on what you’re giving up and what you’re getting. Are you blocked by the old framework or just annoyed by it? Will the new framework actually make future work faster, or are you paying three months for marginal improvements? Sometimes the new version is nicer is worth it. Sometimes it’s just expensive taste.

The calculation might be changing with AI coding assistants. Migration work that took three months might take three weeks now. But the question stays the same: what are you trading and is the trade worth it?

The same calculus runs through every technical decision. Tech debt versus features is the battle you never win. The codebase has sections that work but are messy. Refactoring would make them cleaner, easier to maintain, less likely to cause bugs. It would take a week, maybe two. Meanwhile, users are asking for the next feature and your PM is asking when it ships.

Clean it up now or ship the feature? Neither answer is wrong. Both have costs. Refactor and you’re explaining why nothing shipped this sprint. Ship the feature and you’re working in messy code that slows you down on the next feature. Eventually you pay the price either way. You pay now in visible progress, or you pay later in velocity tax.

I’ve seen teams go both ways. The ones who always ship features end up drowning in technical debt, moving slower every quarter until a quick feature takes a month. The ones who always clean up the code have pristine architecture that users don’t care about because the features they asked for aren’t there. Both teams are convinced they’re doing it right.

The formula is simpler than it looks - count the actual costs. What do you gain? What do you give up? What happens if you don’t do this? Most technical decisions aren’t right or wrong. They’re tradeoffs. The teams that do this well don’t avoid tradeoffs. They just make them consciously instead of drifting into them.

Thought experiment

Before you build something, simulate it. Walk through the scenarios in your head, find the failure modes on paper instead of in production.

Run a pre-mortem. I love this experiment. Imagine the project has failed catastrophically. What went wrong? Everything! What is everything? What happened? Maybe the migration took three times as long as estimated. Maybe the new system had bugs the old system didn’t and is causing data discrepancy. Maybe you lost data during the cutover… or sent thousand of emails you didn’t intend to or the app stopped working all together. You’re imagining the failure and working backwards.

It feels unnatural at first. You’re sitting there trying to imagine your well-planned project failing and it’s hard to take seriously. But the more you do them, the more failure modes you can imagine. You start seeing what’s preventable, what’s mitigatable, what’s reversible and what locks you in. You figure out where you need better monitoring. You assess which risks are worth losing sleep over and which ones you can live with. You imagine a doomsday scenario… it can be quite fun, but also immensely useful.

Make sure someone with a wild imagination runs them. Most team members are quite conservative when it comes to brainstorming such a scenario. They see the happy path and maybe one or two failure cases. But you need a drama queen — well, someone who can act as one, you need the person who asks “what if the database and the backup both fail?” or “What if the whole web app stops working, features are behaving quirky, not data is loaded?” The person that can make everyone paranoid and unreasonable… for an hour. Of course a lot of things you come up with during this meeting won’t happen or have only a slightest chance of happening. However, this kind of exercise will uncover a lot of real things you haven’t thought about, even how to detect something fishy during and after release or what kind of heads-up to give internal teams.

Beyond pre-mortems, use thought experiments to test whether you should build something at all. Someone comes to you with a brilliant idea, like fully automated report generation system with scheduling, templating, and distribution. It’ll take months to build… but think how much time it’ll save. Before you commit to that, run the thought experiment. Could someone just run the queries and email reports weekly for the next 6 months? If yes, you’re looking at a complexity problem that doesn’t exist yet. Maybe build the query tooling first and automate later when you know you actually need it. The thought experiment shows you what needs to be built versus what feels like it should be automated because automation sounds smart.

Apply it to scope too. You’re planning a dashboard. The PM wants 12 widgets, filtering, exports, custom layouts. The full vision will take two months. Run the thought experiment: what if you shipped only the 2 most critical metrics with no customization? Which 80% could you cut and still solve the core problem? Often the honest answer reveals that the elaborate design is solving hypothetical problems. Users want to see two numbers. Everything else is feature creep wearing a requirements costume.

You can also use it to spot lock-in risks before you’re locked in. You’re choosing how to build the new service. AWS Lambda and DynamoDB are fast to set up, managed, no infrastructure headaches. Or you could use Kubernetes and Postgres, more setup but portable. AWS proprietary services feel like the smart choice right now. Before you commit, think two years ahead. AWS becomes too expensive or problematic, what does migration look like? If it’s catastrophic, you’re accepting significant lock-in risk. Not always wrong, but it should be conscious. The thought experiment forces you to look at what it costs to change your mind later.

You’re not trying to predict the future. You’re trying to find what breaks before you commit. Simulate the failure. Simulate the migration. The problems you find in your head are cheaper than the ones you find in production.

Lateral thinking

The API is slow. Users are waiting seconds for pages to load. You start optimizing the backend, you rewrite the queries, add indexes, implement caching, scale up the database. You’re making progress, shaving off milliseconds here and there, but it’s still not fast enough.

Then someone asks why is the frontend making 47 API calls to render one page? Could it request less data? Could it batch those calls into one? Could you create a different endpoint that returns exactly what the page needs instead of making the frontend stitch together data from multiple calls?

You were trying to make the slow thing faster. The actual problem was doing the slow thing 47 times. Backend optimization was the wrong answer. Frontend architecture was the right question. Sometimes making something 10x faster matters less than doing it 10x less.

Same with the scaling bottleneck. You have a query that’s killing performance under load. You try everything from bigger database instance, aggressive caching, read replicas, to query optimization. You get it faster but it’s still not enough. At peak traffic, you’re struggling.

But… do users actually need this data in real-time? You’re recalculating rankings every time someone loads the page. Could you calculate it once an hour and serve cached results? Do users care if the ranking is from 10 minutes ago versus right now?

Making the query faster was one path. Running it less often was a different path. The second path solved the problem.

When you’re stuck pushing in one direction, step sideways and question the direction. This is called lateral thinking. Maybe the backend isn’t the problem, the frontend is. Maybe the query doesn’t need to be faster, it needs to run less often. Maybe the constraint you’re solving for doesn’t need to exist.

When optimization isn’t working, question what you’re optimizing.

You’ve diagnosed the problem correctly. You’ve built the right amount. You’ve thought through the consequences. But sometimes the approach just doesn’t work. That’s when you need to kill it and move on.

Decision-making

Kill bad approaches fast…

Sunk cost fallacy

You’ve been building a feature for months. Each time you think you’re close, another edge case. The pagination breaks with certain data types. The search doesn’t handle special characters. The export crashes on large datasets. Every fix reveals another problem.

The team keeps going because we’re almost done, just need to solve this one more thing. How many one more things before you admit this approach isn’t working? At some point one more thing becomes a lifestyle. The months you’ve spent are gone. We should not be asking “have we invested too much to stop?” but rather “does continuing make sense from here?”

Consider this: you built a sophisticated reporting system over 9 months. Usage data shows 2% of users open it, and they only use one simple report. The team wants to add more report types because we built this whole infrastructure. But the infrastructure is sunk cost. You can’t reclaim those 9 months by adding more features nobody will use. Does maintaining and expanding this make sense given how little it’s used?

You spent 6 months integrating with a partner’s API. The partner proves unreliable. Downtime, poor support, limited functionality. Your team maintains the integration because we spent three months building this. But that investment won’t come back whether you keep it or kill it. Do you want to pay the ongoing maintenance cost for something that doesn’t work well?

Mounting complexity, low usage, unreliable dependencies. The justification is always the same. We invested too much to stop now. But the investment is already spent.

You might not be the one making these calls. That’s often a PM or leadership decision. But you can raise the flag. You’re closest to the work. You see the problems piling up, the usage data, the reliability issues. Sometimes the most valuable thing you can do is point out that we’re throwing good effort after bad. If nobody’s said it out loud yet, be the one who does.

Sunk cost fallacy is continuing because of what you’ve already spent, not because the path forward makes sense. The time is gone either way. The question is what you do next. Kill it early and you redirect effort to something that works. Keep going and you’re building a monument to a decision that didn’t pan out. One of those feels better six months from now.

Local optimum

The feature doesn’t quite work for some users. Team adds a configuration toggle. Then another for different edge cases. Then another. Now the feature has 12 configuration options and is impossible to test or document. Each toggle was a local optimum, fixing one specific complaint. But the overall product got worse. Nobody can understand what all the options do or which combinations work. Your documentation has a truth table. The global optimum would have been simplifying the feature or building two separate features instead of one franken-feature with a dozen knobs.

Engineers spend weeks making the test suite run faster. Parallel execution, better mocking, smarter test selection. They get the suite from 45 minutes down to 30 minutes. Impressive, genuinely. But the real problem is that the suite has 253 tests because nobody ever deletes old ones and teams duplicate coverage. They just made a bloated test suite faster. They’re optimizing within the wrong boundary.

Local optimization is seductive. You’re making measurable progress. The numbers get better. Each change solves a real complaint. But you’re trapped when you’re working hard to improve something within constraints that shouldn’t exist.

Making the tests faster? Maybe the question is why there are so many tests. Adding configuration options? Maybe the feature is trying to do too much. Optimizing a query that runs 40 times? Maybe it shouldn’t run 40 times.

You’re climbing the wrong hill when the optimization works but the problem doesn’t get solved. Step back and ask if this boundary should be redrawn? Sometimes the answer isn’t do this better, it’s stop doing this. Optimization only helps if you’re solving the right problem.

Anchoring

PM asks: “How long will this take?”
First engineer says: “Probably 2 weeks.”

That becomes the anchor. Everyone else adjusts around it: “yeah, maybe 2-3 weeks” or “I think 10 days.”

Nobody says “actually 2 months” because 2 weeks is now the reference point. The first estimate was a guess, maybe based on nothing, but it anchored the entire conversation. Everyone’s evaluating relative to that first number instead of thinking independently about the actual work. Two weeks is the “hello world” of engineering estimates.

Or let’s take the architecture discussion. Team needs to solve a problem, engineer proposes microservices. That becomes the anchor. Now the discussion is “should we do microservices or not?” instead of “what are all the ways to solve this?” Other options like a monolith, serverless, or different service boundaries are judged as not microservices rather than evaluated on their own merits. The first proposal set the frame for the entire design conversation.

The first option you hear, the first solution proposed, the first estimate given becomes the reference point. Everything else is judged relative to it. You’re no longer evaluating options independently. You’re evaluating them as more than the anchor, less than the anchor, or different from the anchor.

Generate multiple options before evaluating any of them. If someone proposes microservices, list out five other approaches before discussing which one makes sense. If someone estimates 2 weeks, have three people estimate independently before comparing. If you’re reviewing code and the approach feels off, question the approach itself, not just the implementation details.

The first thing you hear has gravity. Sometimes the best response to the question about the estimate is “hold that thought, let’s hear from X, Y and Z first.” Anchors only work if you let them.

Share

Ok, I’ve read about the models, now what?

You don’t need all of these. Start with the one that addresses a problem you’re facing right now.

Bug keeps coming back? Root cause analysis and Five Whys stop you from patching the same issue forever.

Jumping straight to complex solutions? Occam’s Razor reminds you to check the simple thing first.

Building for imaginary future requirements? Premature optimization and Overfitting keep you focused on the problem in front of you.

Skipping steps because you’re confident? Unforced error catches you before you break production.

Adding a caching layer? Second-order thinking asks what problems the solution creates.

Framework migration or tech debt cleanup? Cost-benefit analysis forces you to count the real costs.

Architectural decision feels risky? Thought experiment and pre-mortems find failure modes before coding.

Backend optimization not working? Lateral thinking questions whether you’re solving the right problem.

Three months into something that doesn’t work? Sunk cost fallacy gives you permission to kill it.

Incrementally improving something that shouldn’t exist? Local optimum asks if you’re climbing the wrong hill.

First estimate anchoring the conversation? Anchoring reminds you to generate multiple options before evaluating.

The goal isn’t to memorize frameworks. It’s to build better judgment. To catch yourself before making the same mistake twice. To solve root causes instead of fighting symptoms.

Mental models are how lazy (and smart) engineers work less: think harder up front so you don’t have to debug the same issue repeatedly.

So… Hate to repeat myself, but here we are. Pick one model. Use it deliberately for a week. Notice where it helps. Add another. Same advice as in previous essays about the models.

Next up: mental models for working with humans. Code reviews, collaboration, and knowing your blind spots.

Subscribe now

I’ve learned these lessons the more expensive way, through client projects we never killed but should have, teams that put everything on hold when one person went on vacation (with their laptop), and plans that optimized for everything except what mattered. After reading this, you’ll spot situations that are off much more clearly. You can thank me or curse me later (probably little bit of both), but you can’t say I didn’t warn you.

This essay covers mental models for strategic execution: how to plan, how to measure, and how to build teams that get stronger under stress instead of breaking under pressure.

Planning and measuring what matters

Think beyond step one

It’s quarterly planning time. Everyone has ideas. The backlog is full. Everything seems important. You need to decide: what to work on, what to kill, how to measure success.

First step: think things through a bit more, at least several steps more. Remember second-order thinking from Mental models for thinking clearly? At leadership scale, the stakes are higher and the ripple effects reach more people.

You’re hiring three senior engineers to speed up delivery. First-order thinking would be more engineers mean faster shipping. Case closed. But what happens when you start asking “And then what?”

You figure out that onboarding will most likely overwhelm an already stretched team. You can forget about productivity for at least a quarter. Onboarding takes time. Real time. But short-term setback for mid-term or long-term gain.

Next, seniority can be a double-edged sword. Yes, they bring more experience and knowledge. But they bring strong opinions, too. And three seniors on top of any existing ones can create competing architectural approaches.

These things happen, no use pretending they don’t or can’t. Even if we put all this aside, we need to understand that if the real problem is unclear product strategy, more engineers can make things worse. You can’t hire yourself out of strategic confusion. This just makes the problem more expensive.

I participated in this kind of mistake. Twice. Both times we genuinely thought we were being strategic, and somehow made everything worse. But the second time hurt more — at least I (the fan of mental models) should have known better. It can be fixed, but it requires a lot more energy and time than anticipated.

Think two or three moves ahead before committing resources. Most leadership regrets come from first-order decisions that ignored what happens next.

More is not always better. The first engineer you hire creates massive value. The second engineer adds value, but less than the first. The third adds even less. By engineer number ten, you’re getting a fraction of the impact you got from engineer one. This isn’t about the people, it’s about the system. Communication overhead grows. Coordination costs compound. Onboarding burden increases. The marginal value of each additional resource decreases.

I’ve watched teams double in size and ship half as much. More people, less output. Diminishing returns in action. The answer isn’t always add more resources. Sometimes it’s work differently with what you have.

Debug the system, not the people

Remember systems thinking from Mental models for thinking clearly? It sees the structure, not just the event. At org scale, you’re not debugging code, you’re debugging human systems. And human systems are messier. You can’t just hire a CSI team to help you find the meeting that caused the problem.

Another example that will most likely be familiar: the team keeps missing deadlines. Your first thoughts: they should work harder... or you need to add more people, maybe someone from another team can lend a hand... or yes, you could extend hours?

Let’s look a this situation through the systems thinking lens: why does the system keep creating this outcome in the first place?

Engineering is blocked by Product. Product is waiting on Design. Design doesn’t have clear requirements because leadership hasn’t aligned on strategy. No amount of work harder fixes a system-level problem. The constraint isn’t effort, it’s the structure. Since it’s most likely a system problem, you start optimizing processes down to instructions on the task. You’re at the Final final version 1 of the process document, Product writes more specs. Design creates more mocks. You optimized everything except the real bottleneck and got zero improvement. If leadership alignment is the bottleneck, none of that matters. Work piles up at the constraint. Let me introduce you to theory of constraints that says the system is only as strong as its weakest link. Find this weak link and address it.

Of course it’s not always leadership. I’ve seen teams add engineers when the real constraint was deployment pipeline. Add product managers when the constraint was unclear strategy. Add designers when the constraint was indecisive leadership. They optimized everything except the actual bottleneck.

Feedback loops are important parts of systems. When analyzing challenges, ask yourself “What feedback loops exist?” Because believe it or not, what you reward is what you get more of.

Let’s say you praise someone for working late to hit a deadline. Awesome, you recognized this contribution. What could possibly be wrong with this? A lot of things. First of all, what they learn is that working late gets recognition. Others see this and start working late. Then you as a leader can’t be the first person going home, right? Being part of the team and all? And then working late becomes the culture. People burn out. You meant to recognize dedication. The feedback loop reinforced overwork. How did this escalate?! With you. With good intentions.

I have a small confession to make: my path to hell is probably already paved half-way there with (my) good intentions.

The event is someone working late. The system is what created the incentive to work late. Fix the structure that’s creating the behavior.

If you ever worked at a company older than a year or where the original crew is not present anymore, you’ve seen this: a fence across a road. It seems pointless. You want to remove it. Be it code, process, part of the system, doesn’t matter. Before you tear it down in a fit of let’s bring in a wind of change, ol’ chap Chesterton would like a word with you about Chesterton’s Fence — the idea that warns against removing things you don’t understand. Maybe it’s preventing something you’ve never seen.

That annoying legacy process might exist for a non-obvious reason. The manual approval step that seems like bureaucracy? It might be preventing a compliance issue you’ve never encountered. The code review checklist that feels tedious? It might be catching the bugs that used to ship weekly.

Guilty as charged, I brought down a couple of fences myself, usually trying to prove myself in a new job. But guess what, every time, I learned why the fence was there — usually by experiencing the problem it was preventing.

Now I ask “why does this exist?” before I remove it. Sometimes the answer is “no good reason” and you remove it. Often the answer is “oh, that’s why” and you leave it alone… or create a plan to replace it with something else. Sometime. That plan is now in the backlog at priority 47.

When to kill projects (even the ones YOU started)

You asked why the fence existed, understood the reasoning, and decided to remove it anyway. Now you’re three months into a rewrite that isn’t working. Everyone knows it. But the team keeps going. Why?

Because the hardest part of planning isn’t starting projects. It’s stopping them. Because admitting the project was a mistake feels worse than continuing to be wrong. Because in the moment, it feels like commitment, perseverance, not giving up. The project becomes about proving you weren’t wrong to start it, not about whether it’s the right thing to finish. This is the text-book example of sunk cost fallacy at work.

I remember the meeting like it was yesterday when I finally decided to kill a project we spent more than half a year on. Ouch. I felt like I was admitting failure in front of the entire team.

No one asked “so all that work was for nothing?”, but I could see it in their eyes. It was brutal. I told them that all the work was not for nothing, we still learned a lot, and it takes guts to sunset something like this. It grows on you. But it can also become Voldemort, the one project that should not be named, or an endless pit. We don’t like either. Turns out those are your only two options for a “we-should-totally-kill-this-project” projects you can’t kill.

The six months were gone whether we continued or not. And throwing more good months after bad ones doesn’t make the bad ones come back. It only makes the mistake drag longer. If you wouldn’t choose this project starting from zero today, stop now. It won’t get easier later.

There’s another thing this project taught me. I’m sure you’ve heard about Pareto principle before. Well, I’ve seen it in action. Getting the last 10% of the MVP took more time than getting to the first 90%.

On the other hand, if you use this to your advantage, you can get more of outcomes from less effort. Most of what gets planned won’t move the needle. The team wants to ship 15 features this quarter. Users will love 2, tolerate 3, ignore 10. If you spend equal effort on all 15, you’ve wasted 80% of your capacity. If you identify the 2 that matter and focus there, you deliver more value in less time. The hard part: saying no to 13 things.

To do or not do, this is now the question

Opportunity cost is mentioned a lot at meetings where engineers need to negotiate for time to rewrite part of codebase for easier maintenance vs ship value to the customer instead. If your teams always ship only value to the customers and don’t get enough time to keeping the lights on, the lights might start flickering. So, while the opportunity cost is very important to consider, you should not forget that you also have to maintain what you build.

Let’s say you decided to pursue this huge opportunity and you want to do this big strategic bet. Everyone’s confident. But six months from now, it’s obviously flawed. What did you miss?

It’s quite possible no one remembered to validate enough. If nothing else, you should at least pick a red-team, a group of people to systematically attack your plan before you commit. Not a rubber-stamp review. Structured adversarial thinking. Find every way this could fail. Every assumption that might be wrong. Every risk you didn’t consider.

Or organize a pre-mortem. Imagine it’s six months from now and the strategy failed completely. What happened? Work backwards from that failure. You’ll see risks you missed in the optimistic planning phase.

The fastest way to validate (at least initially) is to give someone explicit permission to tear it apart. If they can’t find any problems, they’re not really trying. Or they’re being polite. Both are useless here. The best red-team findings feel uncomfortable. That’s the point.

Now you came to a point when you have to decide. But not all decisions are made equal.

Some are hard or impossible to reverse, like committing to a platform, hiring an executive, changing a tech stack, or pivoting. These deserve careful thought, red-teaming, hard debates. Then there are decisions that can be easily reversed if you don’t find them working. You try out a new process or change meeting format or experiment with a feature. These kind of things can be done fast, if they don’t work, revert them.

Most decisions are reversible, but sometimes we treat them like they are not and this kills velocity. I’m proud to say we learned this and my team has no issues piloting a new process or new meeting structure. The bit on the reversibility is key to decide how to decide.

Measure what matters without gaming the system

You made the decision, hopefully the right one. How will you know? By measuring progress, of course. Now comes the tricky part.

“When a measure becomes a target, it ceases to be a good measure.”

Meet Goodhart’s Law. What you measure becomes what people optimize for. Measure the wrong thing, you’ll get exactly what you measured and none of what you wanted.

If you measure number of commits, team starts to commit every line. Deploy frequency? Easy, break every small change into separate deploys. You’ll end up measuring lots of deploys but you won’t ship value faster. The metric became the target, so it stopped measuring what you cared about.

People are remarkably creative when you give them the wrong incentive. Less so when you give them the right one.

Good metrics resist gaming and stay aligned with actual goals. You could use speed + accuracy + user satisfaction instead, or code reviews completed (not just features shipped). No single metric is sufficient. Any metric used alone will be gamed.

The solution is multiple metrics that create tension with each other, forcing tradeoffs that mirror real goals. But this is for another post.

But, let’s assume we haven’t started yet and we need to estimate how long a project will take first. You estimate a project will take 4 weeks. You tell stakeholders 4 weeks. It takes 6 weeks. You’ve damaged trust. You missed the deadline. The team is stressed. Estimation is hard, but the problem is you didn’t build in a margin of safety. The estimate was your best case, not your realistic case.

Margin of safety is the buffer between what you think will happen and what you promise. It’s the difference between “this will probably take 4 weeks” and “I’ll have this to you in 6 weeks.” It’s acknowledging uncertainty and building slack into the system.

But this is the part where AI makes all this interesting.
Traditional margin of safety: “Development takes 2 days, add 1 day buffer = 3 days.”
AI version should be: “AI generates in 2 hours, add 2 days for verification, integration, and fixing = 2+ days.”

But it feels backwards to add more buffer when AI makes it faster. AI makes you feel like you can reduce margins because if it’s wrong, AI can fix it fast. This could be a slippery slope if you don’t understand what AI produced. Eventually it might take even longer if you don’t take the time to evaluate and understand each thing you add to the system. Remember, some mistakes aren’t reversible, like shipping security vulnerability, wrong database schema, or bad architecture (fast implemented, could take months to unwind), so it pays off to be extra careful with them.

I used to think margin of safety was sandbagging. It felt like admitting I wasn’t confident. Now I know it’s the opposite — it’s acknowledging reality. Things go wrong. Dependencies slip. People get sick. Requirements change. The margin of safety absorbs the variance. But with AI this got to a new level.

However, this still holds: ship in 5 weeks instead of 6? You’re a hero. Ship in 7 weeks after promising 4? You’ve failed even if the work is excellent.

Stop bad projects before they consume capacity. Validate good ones before committing. Measure what matters without creating perverse incentives. Think two moves ahead. Look at the whole system, not just the individual parts.

Change the question from “what should we build?” to “what should we stop building so we can focus on what actually matters?”

Managing teams

Apart from what you build, it’s also important how you organize your teams around the work. In my experience people who work together should sit together, it makes things much easier, information flows, there’s less friction.

However, there’s even a larger thing at play, called Conway’s Law. Separate independent teams, not talking to each other? Separate backlogs, priorities and standups. Your system most likely mirrors this. Separate pieces with seams everywhere. If you want to build integrated system, put the people who need to integrate in the same team, with the same goals, talking to each other daily. Just to lean one way or another to talk to someone on the other side of the computer screen. You’ll see the difference.

Now we’re in production and there’s a production issue. Everyone sees it. Nobody fixes it. Why? When everyone assumes someone else will handle it, nobody handles it. And the more people who could fix it, the less likely anyone will.

I’m sure you’ve seen this one play. The bug sits in the backlog for months. Someone should fix that. Everyone agrees. Nobody does. Does this mean your team is lazy? No. It means your team is human. Which is somehow worse for getting bugs fixed. This is just bystander effect... in effect. If you notice it, you can fix it simply by making it one person’s explicit responsibility. Once responsibility is assigned, it gets done. When it’s someone should, it never happens.

Have you heard about technical debt? How about cultural one? The shortcuts you take in culture compound over time. Just like technical debt, it’s easier to ignore in the short term. Just like technical debt, it destroys you in the long term. This is cultural debt.

You hire a brilliant engineer, because... they’re brilliant, but unfortunately not in the emotional intelligence and humility department. You let toxic behavior slide because they’re too valuable to lose. The behavior spreads. Other people notice that being difficult gets rewarded. The culture shifts. You avoided one hard conversation. You created a cultural problem that’s harder to fix.

Or you ignore someone’s pattern of avoiding responsibility for skipping testing and just pushing to production... with bugs causing incidents. Multiple. One after another.

Or my favorite: talking about work-life balance and then sending out Slack messages at midnight. Although you might not expect anyone to respond, they will. They did. So I stopped. And apologized. Now, when the need to write something (because I finally got focused time to answer all the pings) is too strong, I schedule it.

You’ve done a good job as a leader when your best engineer takes vacation without a computer, nothing breaks, projects don’t stall and you figure out you have a high-performing team, and NOT one depending on heroes. It takes work to get here, but it’s worth it. Anything else is a fragile system disguised as one high performer.

I’ve seen both movies play out. In the first one, a hero movie, work is put to a stop when one person is out. All the knowledge is in one person’s head. Only they know how the critical system works. They’re the hero. You’re dependent. And that’s not fair to them or the team.

But I’ve also seen how fragile can turn into antifragile team when leaders and the team put their minds to it and work systematically towards getting stronger under stress. In the second movie, when someone is out, others step up. Knowledge is distributed. Processes don’t require heroes. Documentation exists. No single point of failure.

You can build antifragile systems by thinking a couple of steps ahead and adding some redundancy for critical parts. Rotate people through different areas so at least two people can handle every critical function. Document decisions and context, so people understand the thinking behind, and are not just left to a mysterious comment in code.

If you’re lucky as I am, people like knowledge sharing over knowledge hoarding, they just might need help and tactics how to share it. Give them permission to do it their way, no need to do it super formally. Mentoring works wonders, so does working together and discussing decisions or challenging them.

Speaking of handing off work aka delegating, especially projects, is not a walk in a park. Nor is it only handing off work. Because you’ve been thinking about this problem for weeks. You have context, constraints, history, nuances. When you explain it to someone, you assume they know what you know. You skip the context because it’s obvious to you. This is the curse of knowledge. Unless you’re dealing with people who can see in your head (I haven’t yet), it’s not obvious to them. They’re missing 90% of what’s in your head. They build the wrong thing because you didn’t explain the right thing.

I’ve done this more times than I want to admit. The conversation goes like this: I spend 15 minutes delegating what I think is a clear task. Two weeks later, they show me what they built. It’s not even close. Like, not in the same timezone as what I had in mind. My first reaction is frustration — how did they miss the point? Then I realize, I never actually explained the point. I explained the task. The failure isn’t their understanding, it’s my explanation.

How to prevent this?

Over-communicate. Then ask them to explain it back to you. If they can’t, you didn’t explain it well enough.

Actually this is my favorite part when I’m validating my understanding: I say to the person I’ll repeat back to them what I’ve heard to check if I understand correctly. This helps me prevent bad things from happening due to preventable misunderstanding.

Every ambiguity you leave creates rework, misalignment, wasted effort. Being clear upfront takes more time. Being unclear later costs more time. So five more minutes are worth it. I’ve seen a lot senior team members do this, especially when time is of the essence. Might look counter-intuitive to others, but it’s crucial not to waste time with rework. Also, sometimes you can’t put everything in a task, and a well pointed question and rephrasing the problem back can provide much needed context way faster.

The systems create the outcomes

Teams succeed because the system is healthy. And healthy systems stay that way when you catch problems early.

Recognize when your org structure is creating silos instead of integration (Conway’s Law). Notice when responsibility diffuses across the group before that bug sits for months (Bystander effect). Spot cultural shortcuts before they compound (Cultural debt). Build knowledge distribution before you’re dependent on one person (Antifragile). Over-communicate context upfront to prevent rework (Curse of knowledge).

The earlier you spot these patterns, the smaller the course correction. Fix it when it’s a small drift, not a major crisis.

Patterns, patterns everywhere

Once you see these patterns, they’re everywhere. You’ll catch yourself about to commit resources without thinking two moves ahead. You’ll spot the system creating the behavior instead of just blaming the people. You’ll feel that stomach-twist when you’re defending a sunk cost because admitting the mistake feels worse than continuing to be wrong.

I know I’m violating loss aversion here — people are more motivated by avoiding losses than gaining wins. I could’ve focused on all the disasters these mental models describe. But that’s not the point. The goal isn’t to scare you into action. It’s to help you recognize patterns early, when they’re just starting to appear, not when they’re already on fire and need fixing. Prevent bad stuff before it compounds. Encourage good stuff before it’s too late.

Planning meetings will feel different, because you’ll start asking different questions. “What should we kill?” hits different than “what should we build?”

You’ll see the 80% waste in real time and feel the weight of saying no to 13 things so you can focus on the 2 that matter. You’ll recognize the opportunity cost of every yes — the value you’re not creating somewhere else.

You’ll move faster on reversible decisions and slower on irreversible ones. You’ll build margin of safety into estimates instead of promising your best case. You’ll ship early instead of missing deadlines.

Team dynamics will reveal their structure. You’ll recognize Conway’s Law playing out in your architecture. You’ll spot the bystander effect before that bug sits in the backlog for six months. You’ll feel and address the accumulation of cultural debt before your best person tells you in an exit interview that they’ve been unhappy for months.

This is hard work. Building systems that don’t need heroes. Teams that get stronger under stress. Organizations that execute when you’re not in the room.

But it’s worth it. Not because you’ll be perfect — you won’t be. But you’ll catch the problems them earlier. Fix them faster. Build something that doesn’t fall apart when you’re not there to hold it together.

Happy pattern spotting.

Subscribe now

Part of a series on mental models: how to be less wrong, not be an idiot, lead without breaking your team, and build things without losing your sanity.

This essay covers team dynamics - how to play the game, work with people, and manage up. The better you get at these three, the less time you spend managing internal team challenges and the more time you can focus on actual business problems.

Here’s what it takes:

• self-awareness to observe what’s happening,

• pattern recognition to understand the forces at play, and

• critical thinking to apply the right response.

No two situations are identical. No two people are the same. Mental models aren’t formulas - they’re lenses that help you see what you’re dealing with.

This essay covers three parts: meetings, 1:1s, and stakeholder communication. What follows are patterns I’ve observed throughout my career - models that helped me understand what’s going on and either prevent preventable problems or mitigate them when they happen.

But once you see these patterns, you can catch them before they cost you.

Meeting patterns you can’t unsee

You’re in a meeting. Someone proposes a significant change - new product direction, organizational restructure, major technical bet. You go around the room. Everyone nods. Some people add supporting points. Maybe there’s an occasional “easy” question. A mild pushback that gets self-dismissed before it’s fully formed. No major concerns. Everyone’s excited about the new thing - the new frontiers, the fresh start. The old baggage is draining. This new stuff? This is exciting.

You adjourn feeling good. “Great alignment,” you think. Everyone’s on board.

But... Something feels off.

You know this scene. It’s the moment in every horror movie where a group of people is about to enter the dark building. “What could possibly go wrong?” they say.

Everything. Everything could go wrong.

If you see this dynamic, be aware. Not to be a party pooper and rain on everyone’s parade - but in business, someone needs to ask what could go wrong. It’s almost necessary.

The yes-men dynamic is a dangerous one. It’s not happening because people are spineless, but because the system makes agreement safer than truth-telling.

Not many people likes others who ask tough questions. They take energy. They’re “high-maintenance.” Maybe now is a good moment to ask why they’re doing it.

I’ve been that high-maintenance person more times than I can count, especially when seeing groupthink taking over. People nodding, but their micro behaviors telling a different story. Subtle (or not so subtle) dismissal of opposing views. Silence interpreted as agreement. Only considering facts that support the preferred position, ignoring the rest. Explaining the warning signs away.

Not on my watch.

Once you do the intervention to break groupthink a couple of times, people will pick this up and help you stress-test ideas, uncover assumptions and make better decisions. Eventually you’ll have your own mental mugshot book for people you have meetings with regularly so you’ll recognize when they “agree” and when they actually agree. Gently nudge them (call the silence out) when they need it, or, even better, ask each team member on the meeting to explicitly commit or agree to what has been said. Lean back and observe the magic. In healthy orgs people will speak up if they have to commit to something they have second thoughts about.

Let’s unpack what’s actually happening in cases like this. Incentive misalignment is at work, tightly coupled with the yes-men dynamic. People are rewarded for agreeing, not for being right. They get promoted for alignment, not accuracy.
Unfortunately, leadership bears the consequences of bad decisions. Everyone else just wants to keep their jobs, get their bonus, avoid making waves. The incentive structure says: agree, don’t tell hard truths. Agreement wins over truth-telling, unless you help it.

I’m sure you’ve seen this happening before: first person agrees, second person sees that and follows. Third person sees two agreements and assumes they know something. Information cascades are forming before you know it. Suddenly, nobody is thinking independently, everyone is following the crowd. One person’s opinion becomes the team’s consensus without anyone actually validating it. The cascade looks like agreement but it’s just social proof compounding.

Almost all systems reward yes-men and punish truth-tellers. But the best prepared leaders I’ve seen know they need dissenters and respect them - even when it’s not easy to hear. They bring an umbrella to their own parade.

To make this work, you have to intentionally recognize these patterns, point them out, and discuss the good, the bad, and the ugly. It’s way cheaper than fixing bad mistakes later.

Now you got your group talking, you dissent - great! I’ve seen a group of leaders discuss the order of columns in a spreadsheet for more than 45 minutes. We spent only 10 minutes deciding whether they should even build all the things in the spreadsheet. I might have even sparked this discussion with a harmless question. This happens to the best of us.

Sometimes you’re involved in this - stop it. Name the waste of time over such trivial decisions, and rather spend time dissenting the big stuff. Bike-shedding is intellectual avoidance wrapped in productive-looking debate, and we’re all guilty of it. Trivial decisions are safe to have opinions about, but they are time wasters.

Next, humor me and do a little math exercise: calculate how much a meeting costs. I do this every time someone’s late, someone goes on a tangent, or we debate things to death without any action. 1 hour with 8 people? You might have burned a person-day. Oops.

Don't decide NOT to have meetings ever again, just being mindful about the cost helps having better, more focused meetings, and make chronically late feel at least a little bad about the pattern.

Redundant thinking is also problematic, it provides no value. I'm sure you've heard this one before:

“If two people in the room always agree, then one of them is one person too many.”

So true. Seek out active disagreement and diverse perspectives to make sure you understand what’s going on. For most meetings you don’t need an audience. Audiences don’t catch your mistakes - they applaud them. What you need are advisors.

It’s all fixable

The easiest way not to get labeled as “difficult person” or “high-maintenance” is to explain others in the meeting that someone should temporarily assume the role of a devil’s advocate and argue against the proposal. Make it their job to find the flaws. Not soft, not too polite, but structured adversarial thinking. Like debate club in school, but for grownups and at work. Rotate the role so everyone gets to be the “bad cop” from time to time.

Most leaders like to talk, like to solve problems, like to have an opinion. But there’s a trap you can fall into when seeking diverse opinions in a group where you don’t peers: you speak first. If you do then everyone might just be responding to or echoing your opinion. Listen first, talk later. The most senior person should practice last to speak. This is extremely true if you’re also a person with a loud voice. More introverted team members might need a bit more time and your silence.

Also, make disagreement mandatory, not optional.
“I need someone to tell me why this is a bad idea” isn’t a rhetorical question. It’s a requirement.

No dissent means the meeting isn’t over. Someone has to argue the other side before you decide. Make dissent obligate, not optional.

The dark side - when leaders actively create yes-men

One of the funniest - but in a dark way - and most frequent patterns you might meet out there is seagull management. You might have done it yourself. I know I did.

You fly in, make noise, crap on everything, fly out. You criticize and comment without sufficient context, offer no solutions, and then leave chaos.

The team is smart. They won’t bring problems to the seagull anymore. They’ll just hide them. And you will all live happily without bad news... for a while, until you meet again, usually when least expected. Don’t be angry with the team then. Rather recognize the seagull management signs before.

And then there are “trust me” decisions, made by authority not merit. Data doesn’t matter. Logic doesn’t matter. The hippo’s gut feeling wins. No, we’re not in the middle of Africa, but in a room with the Highest Paid Person and their Opinion (HiPPO).

When such a person is making all the calls, you can forget about critical thinking. You could hire Braveheart and invite them to your meetings, but it’s better to redesign the system so dissent is expected, safe, and rewarded instead of shushed or fought for with a sword.

Disagreement should have no penalty. Leader speaks last (remember this one?). Criticism is mandatory before big decisions are made.

Enough about meetings. The second biggest thing occupying you is probably people development. I know mine is. And people development is what you notice, not what you schedule. Your 1:1s are more important than you might think.

1:1s aren’t status updates

One of the trickiest 1:1s are the performance reviews. The last conversation you had with them dominates your view of their performance. They had a rough week, missed a deadline, seemed disengaged in yesterday’s meeting. Now you’re sitting in the 1:1 and that’s all you can think about. The three months of solid work before that? Your brain already forgot.

You know making a performance review based on this last conversation is unfair. It’s more common than you’d expect, and no one is immune to it - the recency bias.

Recency bias means recent events carry disproportionate weight. One bad week erases a good quarter. One tense exchange colors the whole relationship. One missed deadline becomes “they’re not reliable.” But you know better.

Keep notes between 1:1s. Track patterns over time, not just last week. “How has this person performed over the last 90 days?” is a better question than “how did they perform yesterday?”

The last conversation wants to rewrite the whole narrative. Notes prevent that.

Also related to performance reviews is how you perceive your team members in general. The best or the worst you can do for someone is to think someone has high potential or write them off as not senior material. This is called Pygmalion effect1.

If you believe someone is high-potential, you give them harder problems, more visibility, better feedback, more of your time. They get more opportunities to grow. They rise to meet your expectations.

If you’ve written someone off as not senior material, you stop giving them challenging work. You don’t invest in their development. You give them the routine stuff. They never get the chance to prove you wrong. They stagnate, confirming your initial belief that they’re not senior material.

Your expectations helped create the outcome you expected.

I’ve seen the effect of doing both. Personally, I lean into “high-potential” until people consistently demonstrate they don’t want me believing in them. It happens, but rarely.

This cuts both ways. Expect greatness, you’ll invest in creating it. Expect mediocrity, you’ll get it.

The question isn’t “Are they high-potential?”
It’s “Am I treating them like they are and did I give them a fair chance?”

You have given them a fair chance, now you observe their behavior.

A team member missed the deadline. Your first thought: “They’re not detail-oriented. They don’t take deadlines seriously. They’re not ready for more responsibility.”

When in reality they had one problem after another. The final scope was much greater than the initial one. No one cared (including you) to ask what challenges they faced, and since they’re more introverted, when they tried to explain this, no one listened.

You assumed the person is the problem, not the circumstances - without checking first. The worst scenario is you form a judgement based on this and share it with other leaders.

This is called the fundamental attribution error and needs to be exterminated from leadership like ghost gone bad. I’m thinking about founding a Ghostbusters-like team to make these evil spirits of attribution errors extinct. It’s human, but it should not exist.

Sprinkle your observations with a dose of gray thinking and ask: “What situational factors am I missing? What’s the system doing to them?” The system might be the problem.

Then go fix the system issue. Join Ghostbusters. If it’s not the system, you have material for a difficult conversation. But check first, judge later.

Unmotivated people don’t work at their full potential. Thank you Captain Obvious.
So it’s up to you to help them be motivated.

Here’s a problem: you can’t do it to them or instead of them. Motivation is similar to change - it has to come from within.

You’ve probably noticed this yourself, especially if you ever worked in a startup: people care more when they have skin in the game. Give them ownership. Let them make decisions. Let them see the impact of their work on users.

Nobody washes a rental car.

You might get by with a big motivational speech now and then, but small, visible wins beat this. Remember how good it feels when you look at the progress you made on meaningful work at the end of the day? Your team is no different. This is the progress principle in action. Use it. Celebrate small wins. Replace all-hands pep talks with “We shipped this feature and three customers immediately adopted it” when it happens.

And now one thing we all know but don’t want to admit: you value what you worked hard for. Same goes for your team. They might say differently, but you’ll see it in their eyes and the attitude when they think you’re not watching.

If they poured effort into something, they’ll be invested in making it succeed. And the harder they work, the more they’ll care about the outcome. This is called effort justification. Just make sure they work hard on the right thing at the right time, and you can’t go wrong. Everyone satisfied.

TL;DR: Motivation isn’t about finding the right words. It’s about giving people ownership, showing them progress, and letting them invest effort in something meaningful. But you already know that.

All is going well, your team thrives, but then you notice some of them going astray a bit after having their big win or two. Overconfidence, over-opinionatedness, not listening, too much of “I’ll do it first without thinking, and ask for permission and help with shit shoveling later.” You know you have to do something, but what?

Or you have the other extreme. A team member who is full of ideas, performs extraordinarily, is being proactive - suddenly after a recent project or two becomes quiet, withdrawn. Are they looking for another job? Did you say something wrong? What’s happening?

In both cases it’s time to have “the talk.” Not about bees and birds, but about a funny little thing called the Dunning-Kruger effect. Show them the curve:

• Mount Stupid: Just learned something, very confident, doesn’t see the complexity.

• Valley of Despair: Started working, discovered the complexity, confidence craters.

• Slope of Enlightenment: Building competence, understanding the nuance.

• Plateau of Sustainability: Actual expertise, accurate self-assessment.

In the first case, you would kindly ask the over-confident person to slowly descend from Mount Stupid, because the longer they stay up there, the worse it gets — although it doesn’t feel this way to them. But it sure does to others. They’re just too polite to say it.

Help the second person come from the Valley of Despair and explain to them it’s normal to get a bit down when you realize how little you know. But that’s okay. You’ll learn, you’ll fail a bit, you’ll win a bit, and eventually you’ll have a healthy relationship with both sides of this.

There’s no shame in climbing to the top of Mount Stupid. We all need to go there to see the view. But it’s a shame to stay there. Also, seeing the Valley is beneficial - a little humbling experience harmed no one. Unless they stayed in the valley.

In both cases it’s you who can lend a hand to help them descend or ascend.

I know the diagram by heart by now, so I can draw it on a whiteboard and explain it to anyone who needs to hear it... or who’s willing to listen. Care to learn about the Dunning-Kruger effect? If you came this far, you already did.

If you use your 1:1s only for status updates, you’re missing out on precious quality time. Personally, I don’t want to miss the opportunity to do something better with it. Like help people develop and get myself out of the job... eventually.

Now that we understand people better, we have to get to another level - to know how to influence people who are not obliged to listen to us, but usually do so. Our other stakeholders.

Stakeholders don’t care about your logic and that’s ok

Let’s say you need buy-in from stakeholders for a major initiative. Resources, timeline, scope - all require approval. You prepare a deck. You present data. You make logical arguments.

And it doesn’t work.

You’re confused. The logic is airtight. The data is clear. The proposal solves a real problem. How did this fail?

I wrote about this before (check “Debating physics in a room full of poets“), but now we’ll take a look from the lens of mental models.

You failed because you think stakeholder communication is information transfer. It isn’t. It’s game theory. It’s about managing incentives, power dynamics, and perception - not just conveying facts.

They will rarely want what you want. Most likely their incentives aren’t aligned with yours. For example, you want to build the right thing long-term. They want to hit quarterly targets. You want sustainable growth. They want to good results in next week’s exec review.

The finance stakeholder cares about budget. The sales stakeholder cares about features that close deals this quarter. The compliance stakeholder cares about security aspects and risk mitigation. None of them care about what you care about. They care about their own goals, measured by their own KPIs. And that's ok, that's normal.

Now that you are aware of the principal-agent problem you’ll understand that assuming alignment is the mistake. Map their incentives instead. Ask yourself: “What does success look like for them? What are they measured on? What keeps them up at night?” Then frame your proposal in terms of their goals, not yours.

Then you might be thinking in years, they’re thinking in quarters... or vice versa, depending if the board meeting is coming up and they need results before it. Sometimes this time horizon mismatch makes alignment nearly impossible, especially when you suggest to address technical debt that won’t show results for six months, but the stakeholder needs a win this quarter. The quarter wins. Every time.

You know this is short-term thinking. They know it too. But the board meeting is in two weeks, and “we’re investing in long-term platform health” doesn’t play as well as “we shipped 3 customer-facing features.” The incentives are honest about what they reward. You have to be honest about the game you’re playing.

When you’re dealing with stakeholders, even your team members, you can’t bypass managing their expectations. And managing expectations is anchoring. When you set an expectation, you’re placing an anchor for how people will judge the outcome.

You set both external and internal expectations.

Tell a customer a feature ships in Q2, and Q2 becomes the anchor. Ship in late Q1, you’re a hero. Ship in early Q3, you’ve failed - even if the feature is excellent. The delivery date matters less than the anchor you set.

Most SaaS leaders try to impress customers with aggressive timelines. “We’ll have that integration done in 2 weeks.” Now you’ve anchored expectations high. Miss by a day and you’ve damaged trust. The aggressive anchor can hurt you.

Your team’s morale and performance is also anchored to the expectations you set. Tell them a feature is “just a quick fix” and they’ll resent if it takes a week. Frame it as “this is complex work” and a week feels reasonable. Same work, different anchor, different morale.

Revenue targets work the same way. Set a stretch goal of $1M when $800K is realistic, and hitting $850K feels like failure. The team did well - they beat realistic projections - but they’re demoralized because they missed the anchor you set. You’ve turned a win into a loss through bad anchoring.

This is where we can screw up quarterly planning. Sometimes we set ambitious targets to “motivate the team,” which just means setting high anchors. We should not be confused when the team is demoralized after a solid quarter that missed the inflated target.

The main lesson: The first estimate anchors expectations. Be smart about it. They don’t say “underpromise and over-deliver” for nothing - it’s a real thing. But beware of extreme sandbagging. Add too much buffer and you’ll lose credibility.

I’m sure you’ll find many more examples in your day-to-day work.

A while back I joked that we could do the anti-pattern of gamification, and build a "wall of shame" feature to encourage more users to one of our tools more and make less mistakes. I swear, I was joking, but what I had in mind is that people feel losses more strongly than equivalent gains. Check the science, it’s there. This is loss aversion.

So keep this in mind when framing your proposals and let them know (your stakeholders) what they’ll lose by not doing it, not just what they’ll gain doing it. “If we don’t invest in this, we’ll lose market share to competitors who are already shipping it” lands harder than “if we do this, we might gain some market share.”

No need to build internal wall of shame, though. Drop it. It’s a terrible idea. And it was a bad joke.

Ready to manage your stakeholders? Not just yet. There is one more thing to keep in mind.

Most of the time you have context they don’t have. They have constraints you don’t see. This gap? The source of misalignment. This is also called information asymmetry.

You know the technical details, the risks, the tradeoffs. They don’t. You’re explaining in technical terms. They’re nodding but not understanding. They know the political dynamics, the budget constraints, the exec priorities. You don’t. You’re wondering why they won’t approve what seems obvious.

Remember the poets mentioned before? Be the physicist who can read and write poems. Bridge the gap. Translate technical to business impact. Ask about their constraints. Make the invisible visible on both sides.

Congrats, you’re all set now… But are you?

I’ve been in stakeholder reviews where everyone nodded enthusiastically. Three hours later, I got five separate 1:1 messages explaining why they actually disagree. Nobody wanted to be the first to object in the room. Everybody wanted to be the one who “raised concerns privately.” The meeting was what... a theater? The real decisions happened in Slack DMs afterward.

What the hell just happened? Preference falsification, that’s what happened. People hide their true preferences to avoid conflict or maintain image. The stakeholder says “sounds good” in the meeting. They don’t mean it. They’re waiting to see what everyone else thinks before committing.

So, if you want to prevent all this, help other leaders to create safe spaces for dissent. Ask directly: “What concerns do you have?” not “Everyone good?”

Probe for real objections before assuming consensus. Get buy-in 1:1 before the group meeting. Pre-wire the decision. Use the group meeting to formalize, not to negotiate.

I do this all the time since I banged my head over this pattern for a while. Now I make sure to understand who are the veto players — people who can kill the proposal. Majority support doesn’t matter if one person can block. If I can’t convince that person with the arguments, there’s little chance I’ll be successful.

To recap: Stakeholder communication isn’t THE ONE presentation. It’s a series of 1:1s building support, pre-wiring decisions, neutralizing objections, creating momentum. By the time you’re in the room presenting, the outcome should already be decided.

Now you ARE ready to kick the proverbial butt. Since you know all the patterns now, I’m confident you won’t kick your own... too often.

You can’t unsee this

Now you’ve seen things that can’t be unseen. Welcome to this side. The view is different here, but very interesting.

I hope I made you at least think about shifting from reacting to patterns to recognizing them, from wondering why logical things don’t work to understanding the forces underneath.

Leadership isn’t about having all the answers. It’s about seeing the patterns that create the problems, then redesigning the systems so the problems stop recurring.

The first time you see one of these patterns, it’s revelatory. The tenth time, it’s useful. The hundredth time, it’s automatic. You stop thinking about the models. You just see the systems.

That’s the goal. Not to memorize frameworks. To rewire how you see leadership so you catch problems before they escalate into something draining you and your team of precious energy and time.

Start with the pattern that’s costing you the most right now.

Part of a series on mental models: how to be less wrong, not be an idiot, lead without breaking your team, and build things without losing your sanity.

Subscribe now

Those are active frameworks. You apply them when you’re making decisions or navigating conflict.

But even with the best thinking tools, your brain still sabotages you. Mine does it constantly. It over-weights vivid events. It follows crowds without checking if they’re right. It rewrites history to make us feel smarter. It curates information to confirm what we already believe.

We can’t think our way out of these. They’re hardwired. The only fix is catching them before they cost us.

These are cognitive biases: systematic errors in how you process information and make decisions. Everyone has them. Smart people, dumb people, you, me, everyone.

The goal isn’t to eliminate biases. You can’t. The goal is to recognize the pattern early enough to question it.

Recognizing your biases

Your brain lies to you. Catch it before it costs you.

Availability bias

You over-weight recent or memorable events. If something just happened or was dramatic, you think it’s more common than it actually is.

Your friend got food poisoning from a restaurant. Now you won’t eat there. They serve thousands of meals safely every week. Your friend had one bad experience. But that one vivid story (your friend getting sick) outweighs all the unremarkable safe meals. The restaurant hasn’t changed, but your perception of the risk has.

You saw a viral post about AI screwing up, giving terrible advice, confidently hallucinating wrong answers. Now you think AI is completely unreliable. Meanwhile, you’ve used AI-powered tools successfully all day: Google search found what you needed, autocorrect fixed your typos, Netflix recommended something you actually liked, spam filter caught the junk. Dozens of quiet successes. One dramatic failure. Which one shapes your perception? Your brain curates content like a tabloid editor. Drama gets the headline. Everything working as expected doesn’t.

Someone got fired at your company. Suddenly everyone thinks they’re next. People are updating resumes, looking at job boards, whispering about layoffs. Reality: one person got fired for performance issues, it happens once a year, your job is fine. But that one firing is vivid and recent, so it feels like the start of mass layoffs. The fear isn’t proportional to the actual risk. One dramatic event rewrites the whole narrative. One hundred boring days of nothing happening? Your brain already forgot those.

There was one incident at a party where some young people got into a fight. Now everyone in the neighborhood thinks all parties with young people will end in a brawl. The community meeting is full of people saying “we need to ban these parties.” Reality: it’s the first incident in years. Hundreds of parties happened without problems. But that one incident is what everyone remembers.

We do this with everything. One plane crash on the news, suddenly flying feels dangerous (even though you drive every day, which is statistically riskier). One break-in in the neighborhood, suddenly the whole area “isn’t safe anymore” (even if it’s the first incident in five years). One friend’s startup failed, suddenly all startups feel like bad ideas.

The pattern: recent and vivid beats frequent and boring. One dramatic story outweighs a thousand unremarkable data points.

Your brain isn’t trying to be accurate. It’s trying to be efficient. Vivid memories are easy to recall. Boring, uneventful patterns are hard to remember. So when you ask yourself “is this risky?” your brain answers based on what’s easiest to remember, not what’s actually true.

The fix isn’t to ignore recent events. It’s to ask: “Is this one event representative, or is it an outlier? What does the actual data say? What’s my sample size?” One firing doesn’t mean layoffs are coming. One bad party doesn’t mean all parties are dangerous. One hallucination doesn’t mean AI is useless.

Check whether you’re reacting to a pattern or reacting to the most memorable example.

Spoiler: it’s usually the memorable one. Our brains are terrible at statistics but excellent at remembering drama.

Your brain tricks you with vivid memories. It also tricks you with crowds.

Bandwagon effect

You do something because everyone else is doing it, without questioning whether it makes sense for you.

Everyone’s investing in crypto. Your coworkers are talking about it, your friends are making money (or saying they are), it’s all over the news. So you invest. You don’t understand what blockchain actually is. You can’t explain how it works. You’re not sure why this specific coin is valuable. But everyone else is doing it, so it must be smart. Then the market crashes and you realize you were following the crowd into something you never understood. You’ve just enrolled in the expensive school of crowd-following. Tuition: whatever you invested.

Everyone’s trashing someone online. You see the pile-on, read a few angry posts, and join in. You don’t know the full story. You haven’t verified the claims. You just saw everyone else doing it, so it must be deserved. The hate wagon feels righteous when you’re part of the crowd. Later you find out the story was more complicated, or wrong, or taken out of context. But the damage is done and you were part of it.

Everyone's watching Game of Thrones. I resisted for two years because I didn't want to be part of the mainstream hype. When I finally gave in, I realized I could have been enjoying it all along. The only upside to waiting? I got to binge-watch it. Which meant watching every obvious protagonist die in a single day instead of spread across weeks. It hurt. I was still doing bandwagon thinking, just the contrarian version. Resisting something just because everyone else is doing it is still letting the crowd make your decision.

Everyone's saying "real writers don't use AI." I don’t have time to learn all the superior writing skills, but I have something to say and want to share it. For me as a non-native English speaker, writing is sometimes like walking through Death Valley. I have to get to the other side fast, but I can't, I'm dehydrated. But I have a flask of water in my hand: AI tools. Should I die in the valley and stay quiet? Torture my readers with clunky prose, slowly dragging my feet through the heat? Or take a sip now and then and keep moving faster? You tell me. If you're in the same spot, are you on a bandwagon of artificial purity, willing to die? Or are you prepared to ask yourself "would this tool actually help me?" Not everything is cheating. Not every puritanism makes sense.

The bandwagon works both ways. Following the crowd. Resisting the crowd just to be different. Either way, you’re letting everyone else’s behavior make the decision instead of thinking for yourself.

The pattern: popularity becomes the reason. “Everyone’s doing it” becomes the justification. You skip the part where you ask “does this make sense for me?”

The fix: pause before following. Ask: “If nobody else was doing this, would I still think it’s a good idea? What problem does this solve for me? Do I actually understand what I’m signing up for?”

Sometimes the crowd is right. Sometimes everyone’s adopting something because it genuinely works. But “everyone else is doing it” isn’t evidence. It’s just momentum. Check whether you’re making a decision or just following traffic.

Following crowds without thinking is one trap. Rewriting history to make yourself look smart is another.

Share

Hindsight bias

After something happens, you convince yourself you knew it all along. Hindsight bias makes past events seem obvious, even though they weren’t obvious at the time.

Your friends break up. “I knew they weren’t right for each other.” But when they got together, you didn’t say anything. You didn’t warn anyone. You went to their wedding and smiled in the photos. Now that it’s over, you remember every red flag like you predicted this from day one. You’re rewriting history. The relationship had problems, sure. Most relationships do. But you didn’t “know” they’d break up. You just think you did because you know the ending.

Someone you admire launches a business. You’re a little envious. They’re doing something bold, and you’re watching from the sidelines. A year later, it fails. “I knew that wouldn’t work.” But when they announced it, you didn’t say that. You thought “maybe they’ll succeed and I’ll regret not doing something similar.” Now that it failed, you remember every flaw in their plan like it was obvious. You’re not smarter than them. You just have the ending, and the ending makes everything look predictable.

Hindsight bias is especially harsh on people you secretly envy. When they succeed, it stings. When they fail, you retroactively claim you saw it coming. It’s a way to protect yourself. If their failure was obvious, then you weren’t wrong to play it safe. You were smart. They were reckless. Except you didn’t think that at the time. You thought they were brave and you were stuck. Hindsight turns envy into retroactive wisdom. It’s easier than admitting you’re rewriting the story.

Your team loses the game. “I knew they’d choke under pressure.” Except before the game, you said they had a good chance. You wore the jersey. You hoped they’d win. After they lose, you remember every mistake, every missed opportunity, every sign they weren’t ready. It all seems obvious now. It wasn’t obvious when the game started. You’re experiencing the outcome and pretending you predicted it.

The problem isn’t that you feel smart. It’s that hindsight bias prevents learning. If you think you “knew it all along,” you don’t ask “what did I actually miss?” You don’t update your thinking. You don’t examine why you didn’t act on this supposed knowledge. You just rewrite history to make yourself the person who saw it coming.

This makes you overconfident about predicting the future. If everything seems obvious in hindsight, you start thinking you’re good at forecasting. Turns out those are different skills. Retroactive pattern matching doesn’t help you predict the future. One is useful. The other is a cognitive trap.

The fix: before the outcome is known, write down what you actually think will happen. When the outcome arrives, compare your prediction to what you claimed you “knew all along.” The gap between what you predicted and what you claim you predicted is hindsight bias. It’s humbling. It’s also the only way to get better at actually predicting things instead of just pretending you did.

Hindsight bias makes you feel smarter than you are. Filter bubble makes you feel more informed than you are.

Filter bubble

You only consume information that confirms what you already believe. Your social media feed shows you more of what you engage with. Your news sources align with your politics. Your friends think like you. Your professional circle shares your perspective. You think you’re well-informed. You’re actually seeing one slice of reality on repeat.

Your social feed is full of posts about how terrible X is. Everyone you follow agrees X is terrible. The algorithm shows you more anti-X content because that’s what you engage with. You see ten posts a day confirming X is the worst. You never see the reasonable defense of X, the nuanced take on X, or the data showing X isn’t as bad as your feed makes it look. You think the whole world agrees with you. Half the world doesn’t, you’re just not seeing them.

You only read news from sources that match your worldview. Conservative sources if you lean right. Progressive sources if you lean left. Tech publications that celebrate your favorite framework. Business outlets that confirm your management philosophy. You’re not getting news. You’re getting your existing beliefs reflected back at you with a “breaking news” banner - confirmation that you’re right, which feels great until reality has a different opinion. The information that contradicts your view exists, you’re just not consuming it.

You only hang out with people who think like you. Same industry, same role, same politics, same life stage, same worldview. When you ask for opinions, you ask people you know will agree with you. “Should I take this job?” You ask three friends who already think like you. They all say yes (or all say no). You feel validated. You didn’t get diverse perspectives. You got confirmation bias on steroids.

I’ve been intentionally building the opposite for years. I seek out friends who aren’t afraid to tell me I’m wrong. People who aren’t so fond of me that they’ll soften the blow. I need the mirror from Snow White — the one that told the Queen what she needed to hear, not what she wanted to hear. Turns out it’s easier to find than I expected. Plenty of people are happy to tell me I’m wrong. It’s uncomfortable. It’s also the only way to get actual feedback instead of validation disguised as advice.

The filter bubble makes you fragile. You’re not stress-testing your ideas against opposing views. You’re not encountering arguments that challenge your assumptions. When reality contradicts your bubble, you’re blindsided. “How did he win the election? Nobody I know voted for him.” Because your bubble isn’t representative. It’s comfortable, but it’s not reality.

The fix isn’t to consume everything. It’s to actively seek out perspectives that make you uncomfortable. Read one source that disagrees with you. Talk to someone outside your industry. Ask for opinions from people who might challenge you. Follow someone who thinks differently.

You don’t have to agree with opposing views. But you should know they exist, understand why people hold them, and be able to argue against them without caricaturing them.

The pattern: if everyone around you agrees all the time, you’re not informed. You’re insulated. Break the bubble before it breaks you.

Where to start

You don’t need to focus on all four. Start with the one that’s costing you the most right now.

Seeing patterns everywhere after one dramatic event? That’s availability bias. Ask: “Is this representative or just memorable?”

Following what everyone else is doing without questioning it? Bandwagon effect. Ask: “If nobody else was doing this, would I still think it’s smart?”

Convinced you saw it coming after the fact? Hindsight bias. Write down predictions before outcomes happen.

Everyone you talk to agrees with you all the time? Filter bubble. Actively seek out one perspective that challenges you.

Remember: the goal isn’t to eliminate biases, but to catch them early enough to question whether you’re reacting to reality or to the way your brain distorts it. Catch yourself before the bias makes the decision for you.

Mental models won’t make you smarter. They’ll make you wrong less often. Which, honestly, is better than being confidently wrong more often.

Start today. Pick one bias. Watch for it. Notice when it shows up. The rest will build from there.

Part of a series on mental models: how to be less wrong, not be an idiot, lead without breaking your team, and build things without losing your sanity.

Subscribe now

I fed ChatGPT my strategy and asked if it made sense.

ChatGPT said it was brilliant.

It wasn’t. The strategy was based on assumptions about user behavior that weren’t true, targeting a market that didn’t exist, with a go-to-market plan I hadn’t validated at all.

ChatGPT had no idea. It just confidently told me why my broken strategy was solid.

AI doesn't push back unless you make it your sparring partner in critical thinking. But that requires you to know what to ask it to challenge.

This is where we are now. You can get an answer to any question in thirty seconds: whether it's a good answer, whether you're even asking the right question, whether the assumptions baked into your prompt are fundamentally broken. It doesn’t say “wait, have you thought about this?”

None of that shows up in the response, unless you explicitly prompt for it.

That’s why critical thinking matters more now, not less.

What AI won’t do for you

AI is incredible at pattern matching, synthesis, and generation. It can help you think through problems, identify risks, challenge assumptions - when you give it the right context and explicitly ask it to.

The problem isn’t that AI can’t do these things. It’s that it makes it too easy to skip the hard thinking.

You can get a plausible-sounding answer without doing the work to:

• Frame the question properly

• Surface your assumptions so they can be challenged

• Verify the output against reality

• Catch when you’re solving the wrong problem entirely

• Notice when your confidence about an estimate means you’re missing complexity

AI will confidently answer the question you asked. It won’t tell you that you asked the wrong question. It won’t push back unless you explicitly prompt it to. It won’t know that the last three times this pattern appeared in your specific context, it failed for reasons you’re about to ignore again.

Critical thinking is the gap between “this sounds good” and “this will actually work.” It’s the difference between building the thing efficiently and building the right thing. It’s what stops you from spending six months on a strategy that seemed brilliant when you asked about it but reality says is broken.

AI can amplify your thinking. It can’t replace the judgment that comes from experience, stakes, and the discipline to question what you’re actually trying to accomplish.

That’s why critical thinking matters more now, not less. The tool gives you answers faster. You still need to know which questions to ask.

And it’s not just about work.

You need critical thinking when:

• Reading news and trying to separate signal from noise

• Making family decisions about schools, moves, careers

• Evaluating advice from experts who might be confidently wrong

• Understanding why your team keeps having the same problem

• Deciding if this new framework/methodology/tool is actually better or just shinier

I had a moment of panic while preparing this series. Just when I gave myself a pat on the back to finish fourth out of six essays in this series, I read in one of the online articles how AI made mental models obsolete, that the frameworks we’ve relied on for decades don’t apply anymore. I’d just spent hours on these essays about mental models for leaders and ICs. Hours. And now I’d have to throw everything away? Does it even make sense to write anything? It’s over. I’m doomed.

But then I smacked myself. I don’t do panic. I do critical thinking. OK, some things have changed more than others. AI does change the context. But mental models aren’t rules or laws that break when technology shifts. They’re mechanisms that help us think better, be wrong less often, see patterns we’d otherwise miss. Yes, AI is full of biases and we need to spot them. Yes, we need to understand how AI changes the game. But that doesn’t make all the thinking frameworks obsolete. Some of them survived centuries, other decades, they survived technological advances and war. People have changed, but not so much.

Not everything is lost. Everything just got more interesting. AI hasn’t kill mental models, it just gives them an additional perspective to weave in.

Crisis averted, now let’s see the role mental models play in critical thinking.

Mental models: thinking tools, not formulas

Mental models are frameworks for thinking. They help you recognize patterns you’ve seen before, catch mistakes before you make them, and see systems instead of just symptoms.

They’re not formulas. They’re not rules. They’re more like lenses: different ways of looking at the same problem that reveal different aspects of it.

Most people operate at the event level. Something happens, they react. The system keeps creating the same events, they keep reacting the same way, nothing changes.

Mental models work at a different level. Think of it like an iceberg.

Events are what you see on the surface. You’re broke at the end of the month. Again.

Patterns are below the surface. This happens every month. That’s a pattern, not a one-time event.

Structures are deeper still. Why does the pattern exist? Impulse purchases. No budget. Lifestyle inflation. The structure creates the pattern which creates the events.

Mental models are at the bottom. The beliefs and assumptions that generate everything above. “I deserve nice things now.” “Budgets are restrictive.” “I’ll make more money later.” These mental models create the structures, which create the patterns, which create the events.

Most people see the event and react. “I’ll be more careful next month. I’ll cut back on coffee.” They’re treating symptoms.

People who use mental models see the iceberg. They question the assumptions creating the structure. “Why do I believe budgets are restrictive? What if tracking spending gives me more freedom, not less?” They fix the root cause. They stop getting the same event on repeat.

That’s what these frameworks do. They help you see past the surface to what’s actually creating the problem.

Some mental models come from specific domains: systems thinking from engineering, opportunity cost from economics, Occam’s Razor from philosophy. But here’s the interesting part: the best ones (the super models) turn out to be useful everywhere. A framework from biology helps you understand organizational dynamics. A concept from physics clarifies a product decision. A tool from psychology explains why your deployment process keeps failing.

The value isn’t in memorizing models. It’s in building a library of thinking tools you can reach for when you’re stuck, when something feels off, when everyone agrees but you’re not sure why.

How this series works

There are hundreds of mental models. Some are more relevant than others. Some apply broadly, others fit specific contexts. They’re guides, not laws. You adapt them, you mix them, you use what works and ignore what doesn’t.

This essay covers how to actually think - mental models for making decisions and understanding people. The frameworks you need whether you’re evaluating a career move, trying to understand why your friend is upset, or figuring out why the “solution” keeps making things worse.

The next essay covers how not to be an idiot - mental models for catching your cognitive biases before they cost you.

After that: models that matter specifically for leaders - when you’re making decisions that affect teams, strategy, and organizations.

And finally: models for engineers - when you’re writing code, making technical decisions, solving engineering problems.

But here’s the key: these aren’t mutually exclusive. The foundational models apply to leadership and engineering. The leadership models work for ICs at tactical scale. The engineering models work for leaders at strategic scale. The difference is the level you’re operating at, not the thinking tool itself.

Leaders apply these at organizational scale. ICs apply them at technical scale. You apply them to life. Same tools, different contexts. I’ll show you the patterns. You do the adaptation.

The models that matter (for everyone)

Making decisions

Think through consequences before you commit

Second-order thinking

Most people think one move ahead. “If I do this, what happens?”
Second-order thinking asks: “And then what? And after that?”

You buy something expensive you can’t really afford. First-order thinking: I want this, I’ll figure out the payments. Second-order thinking: And then what? Monthly payments strain your budget. You start cutting other things. The thing needs maintenance you didn’t budget for. Six months later you’re stressed about money, resenting the purchase, and the initial joy is long gone. The thing you bought to make life better made it worse.

You quit your job without a plan or savings. First-order: I'm finally free from this place. Second-order: And then what? Panic sets in after a month. You take the first job offer out of desperation, which is worse than what you left. Or you burn through savings and now you're anxious about money instead of anxious about work. You traded one stress for a different, often worse, stress.

What if you know about the second-order mental model and think two or three steps ahead before taking the (usually) irreversible decision? You prepare, you plan, you make your exit strategy, you find someone trustful for advice, then when the time is right, you take the job offer you want, not the one you need in desperation.

Now you’re new at the job and you say yes to everything because you want to be helpful. First-order: People like you, you're reliable. Second-order: You're burned out. Quality of your work drops. You start resenting the commitments. People stop trusting you because you're spread too thin. The very thing you did to be helpful makes you unreliable.

However... knowing second-order thinking helps you understand that managing your energy and time is important, your commitments are important, too. You look for advice on how to set healthy boundaries, how to say no and still be helpful, AI can be great sparring partner and can prepare you for this.

You send the angry email. First-order: Feels good, got it off your chest, they needed to hear it. Second-order: Relationship damaged. Trust broken. Now the original problem is worse because you can't have a reasonable conversation anymore. And you can't unsend it. The internet is forever, your regret is also forever, and you get to feel it fresh every time you see them on Zoom, at the cafeteria, in the hallway.

Luckily, this movie unwinds in your head before you hit send. You vent, but you do it in a document you delete afterwards, or email you don't send, and wake up in a morning you don't regret. You still get angry, but you start learning about how to have difficult conversations instead.

You ask ChatGPT about a medical symptom or legal question. First-order: You got an answer, it sounds authoritative, problem solved. Second-order: The answer is confident but wrong. You act on it. The medical advice makes things worse. The legal interpretation costs you money or gets you in trouble. Its confidence lulled you into thinking, you don't need to fact check. You do.

So do it, before you act on it. Instruct AI to cross-reference advice, to suggest what could happen next, what could go wrong. If you lucky, you might have friends who are experts in the field, cross-check with them.

First-order thinking optimizes for immediate outcome. Second-order thinking asks what that outcome creates, and what that creates.

We don’t need to think ten moves ahead. Two or three is enough. We just need to ask: “This works. And then what happens? What does that enable or prevent? What am I not seeing?”

Most regrets come from first-order decisions. We saw the immediate benefit, but missed the downstream cost.

Thinking two or three moves ahead reveals consequences. Most of the time we’re more than capable of doing this. But even when we see potential consequences, we still have to choose. That’s where explicit tradeoffs come in.

Cost-benefit analysis

Every decision has tradeoffs. Cost-benefit analysis makes them explicit instead of letting you pretend they don’t exist. No more putting the head in the sand. Ostriches don’t do it, neither should you.

You want a new car. The benefit is obvious: reliable, safe, looks good, better commute experience. But what’s the actual cost? Not just the sticker price. Higher insurance. Maintenance. Depreciation the moment you drive off the lot. Monthly payments strain your budget. You’re committing to years of car payments. The question isn’t “can I afford this payment?” It’s “is this car worth more to me than everything else I could do with that money over the next five years?”

Most people only see the benefits. They imagine themselves in the new car, not the stress of the payment when an unexpected expense hits. Cost-benefit analysis forces you to look at both sides honestly.

Here’s another tricky one. You’re deciding whether to stay at your current job or leave. Cost of staying: opportunity cost of higher pay elsewhere, frustration with things that won’t change, career stagnation if you’re not growing. Benefit of staying: stability, relationships you’ve built, domain expertise, known problems vs. unknown ones. Cost of leaving: risk of new job not working out, starting over with new people, losing seniority, disruption to life. Benefit of leaving: potentially better pay, growth opportunity, fresh start, escape from current frustrations.

When you write it out, the decision gets clearer. If the main reason to stay is fear of the unknown and the main reason to leave is growth plus money, that’s data. If the reason to stay is you’re genuinely learning and the reason to leave is just more money, different calculus.

Or maybe you decided not to leave and you’re thinking about asking for a promotion. Cost: potential rejection, awkwardness if they say no, increased responsibility and stress if they say yes, relationship strain if you handle it poorly. Benefit: more money, better title, expanded scope, career trajectory. Is the benefit worth the cost? Depends on whether you’re ready for the increased responsibility, whether the timing is right, whether your relationship with your manager can handle the ask. You know the saying “Be careful what you wish for”. I wonder how Eminem and Metallica songs with this lyrics would turn out with cost-benefit model applied.

Here’s one of mine. I was thinking if it’s worth it to purchase a subscription for a specific AI tool. I could keep on using another one that’s free. But... I’ve heard the paid version of this specific tool has much better models and much better results. I could go YOLO and purchase yearly subscription or... I could weigh the costs and benefits of different specific tools out there. What can they do? What can I use them for? Will I use it just for writing, or for programming or something else completely? Is subscription the only cost? Oh, I wasn’t losing sleep over $20 a month, more like 10x this. Worth giving it a thought. If you’re wondering, I did purchase it. I haven’t regretted a single moment.

It’s January. Everyone’s making resolutions. Gym membership, meal prep, moving closer to work. Cost-benefit analysis cuts through the optimism.

Gym membership costs are money, time (including commute to gym), effort, and required consistency. Benefit is fitness and health, but only if you actually go. The January gym is full of people who paid for the benefit without accounting for the cost. Three months later, they’re paying for a membership they don’t use. Honest cost-benefit analysis asks: will I actually go three times a week? If not, the cost is pure waste. February gym is full of empty treadmills and people who learned this lesson. Impulsiveness and gym don’t work well together.

For meal prep at home cost is time (shopping, cooking, cleaning), effort, planning, learning curve if you’re not good at it. Benefit is money saved, healthier eating, control over ingredients. But if meal prep takes three hours every Sunday and you hate every minute, you’ve turned Sunday into a punishment for wanting to eat healthy. Congratulations, you’ve gamified resentment. Is the money saved worth it? Maybe yes if you’re broke and need to save money. Maybe no if your time is better spent elsewhere and you can afford convenience.

Now let’s take a look at moving closer to work. Cost is moving expenses, potentially higher rent, leaving your current neighborhood and the life you’ve built there. Benefit is time saved on commute (maybe an hour a day), less stress, more sleep, better quality of life. Is an extra hour a day worth higher rent? For some people, absolutely. For others, the cost isn’t worth it. There’s no universal answer. Cost-benefit analysis makes your specific tradeoff visible.

When doing this, list the real costs (not just money). List the real benefits (not just the fantasy version). Compare honestly. Then decide if the tradeoff makes sense for you, not for someone else.

Making tradeoffs explicit helps with isolated decisions. But most problems aren’t isolated - they’re part of larger systems.

Systems thinking

Most people see problems as isolated events. Systems thinking sees the structure that keeps creating the problem.

During British colonial rule in Delhi, the government had a cobra problem. Venomous snakes, public safety risk, something had to be done. They offered a bounty for every dead cobra. Seemed logical: create an incentive, reduce cobras, problem solved.

What actually happened: people started breeding cobras to collect the bounty. When the British discovered this and cancelled the program, breeders released their now-worthless snakes. Result: more cobras than before.

This is the cobra effect, now a standard case study in economics and public policy, a well-documented example of so called perverse incentives. A solution that makes the problem worse because it ignores how the system actually works.

Here’s what systems thinking would have caught:

Wrong feedback loop. The British expected a balancing loop: bounty leads to fewer cobras, problem solved. They got a reinforcing loop: more cobras leads to more money, which incentivizes breeding more cobras, which creates even more cobras. The incentive structure rewarded the opposite of what they wanted.

Measuring the proxy, not the goal. They optimized for dead cobras (easy to verify, easy to pay for) instead of reduced cobra population (the actual goal). The metric became the target. When you reward the metric instead of the outcome, people optimize for the metric. This is how you get cobra farms.

Linear thinking in a systemic problem. Their mental model was simple cause and effect: incentive leads to desired behavior leads to problem solved. They ignored how the human economic system would interact with the ecological system. People respond to incentives rationally, but rationally doesn’t always mean the way you want. Systems thinking maps these interconnections before implementing the policy.

Ignoring delays. The unintended consequences weren’t immediate. There was a delay while breeding operations scaled up. By the time the British caught on, the perverse incentive was entrenched and the cobra population had exploded. Systems often have delays between action and consequence. The delay masks the problem until it’s too late.

System boundaries drawn too narrowly. They treated it as a simple “cobra removal” problem. They excluded human economic behavior, market dynamics, and rational self-interest from their analysis. When you draw the system boundary too narrowly, you miss the forces that will undermine your solution.

Systems thinking would have asked: “What behavior does this incentive actually create? What’s the feedback loop? How might people game this? What are the second-order effects? What am I not seeing?” The answer reveals the flaw before you’ve made the problem worse.

Same pattern plays out with AI content recommendations. You use AI to filter news, choose what to read, recommend what to watch. The AI optimizes for engagement—keeping you clicking. Seems helpful. Enter the primary loop. AI shows you content similar to what you engaged with before. You see more of the same perspective. Your view narrows. The algorithm interprets your narrowing as preference and doubles down.

But there are other loops running simultaneously. Content creators see what gets engagement and produce more of it. Now the supply itself is shifting to match your bubble. You’re not just filtering a neutral information stream, you’re reshaping what gets created.

When you share AI-recommended content, your network sees it, engages with similar content, and their algorithms shift. Your bubble and their bubble start reinforcing each other. Social validation makes both of you more confident you’re seeing reality clearly.

Meanwhile, there’s erosion happening to your accumulated exposure to diverse perspectives. This isn’t like weight gain where you notice daily changes. You had a baseline diversity of inputs from before you started using AI filters. That stock is draining and each day you see less variety than you did six months ago. By the time you notice, you’ve lost the reference points to recognize what’s missing.

You realize this and ask AI to challenge you, provide alternative perspectives, find holes in your thinking. AI can do this — if you prompt it with structural constraints. But if you just ask it to challenge me without specifics, you're asking the same optimization engine that created the problem to solve it. What counts as a challenge? The AI shows you disagreements that are intellectually stimulating but not psychologically threatening. You engage with those. The AI learns: "challenging content" means "feels like critical thinking without discomfort." New bubble, same mechanism.

So what actually interrupts the loop? Manual friction. Subscribe to sources you disagree with and force yourself to read them before AI curates anything. Track what percentage of your information comes from outside your engagement history. Set a quota: 20% of reading time goes to randomly selected sources. The system requires structural constraints that prevent optimization, not smarter optimization.

Systems thinking sees the loop before it traps you, but also sees that awareness alone doesn’t break the loop. You need circuit breakers that work even when you’re not paying attention. You might learn something new, open your chakras... or just have a laugh.

Actions ripple. You change one thing, it affects another, which affects another. Cut costs by eliminating training. Short term: budget looks better. Ripple effects: people are less skilled, quality drops, customer complaints increase, you lose clients, revenue drops, now you’re cutting costs again to compensate. You optimized one part of the system and broke three others. The parts are connected. You can’t change one without affecting the rest.

Systems thinking doesn’t mean everything is complicated. It means asking: “What’s the structure creating this outcome? What feedback loops exist? What constraints matter? If I change this, what else changes?” See the system, not just the symptoms. Try to fix the structure, not just the event.

Understanding people

Stop assuming everyone’s an asshole before checking if they’re just overwhelmed

Hanlon’s razor

“Never attribute to malice that which is adequately explained by stupidity, ignorance, or misunderstanding.”

Your coworker didn’t respond to your Slack message. You assume they’re ignoring you. They’re not. They’re drowning in pings, fighting three fires, and your message got lost in the noise. You jumped to they don’t respect me when the reality is they’re overwhelmed and didn’t even see it.

Your neighbor’s dog barks every night. You assume they don’t care about disturbing the neighborhood, they’re inconsiderate, they probably hear you complain and ignore it. Reality: they work night shift and aren’t home when it happens. They have no idea the dog is barking. You’ve been building a case against their character based on something they don’t even know is happening.

The cashier was short with you, barely made eye contact, seemed annoyed. You assume they hate their job or they’re just rude. Reality: you’re the 11th customer today, and the first 10 were awful. Someone yelled at them about a price they don’t control. Someone else berated them for being too slow. Someone returned a worn item and demanded a refund. They’re not rude. They’re exhausted and trying to get through their shift.

Someone left their shopping cart in the middle of the parking lot. You assume they’re lazy and inconsiderate. Reality: their kid is having a complete meltdown in the car. They’re trying to buckle a screaming toddler into a car seat while the toddler arches their back. They forgot about the cart. They’re not inconsiderate. They’re in survival mode.

We do this constantly. Assume malice when it’s usually chaos, confusion, overwhelm, or just not having the same context as the person targeted by malice. Incompetence and bad timing explain most problems. Malice is exhausting and rare.

The person who cut you off in traffic isn’t necessarily an asshole. Perhaps they didn’t see you. The friend who cancelled plans doesn’t think you’re unimportant. They’re dealing with something they haven’t told you about. The team member who didn’t deliver isn’t incompetent. They didn’t understand the requirement the same way you did.

Most of the time, people aren’t trying to make your life harder. They’re just trying to get through their own day with incomplete information and competing priorities.

Hanlon’s razor doesn’t mean you’re naive or you let people walk over you. It means you start with the more likely explanation before jumping to the least charitable one.

“Hey, did you see my message?” is easier than silently resenting someone who didn’t even know you were waiting. “I noticed the dog barking at night” is more effective than deciding your neighbor is terrible. Most problems get solved faster when you assume ignorance instead of intent. Turns out a question works better than nursing a grudge about someone who forgot you exist.

Assuming good intent gets you halfway there. The other half is understanding that both sides usually have legitimate perspectives.

Third story

When two people disagree, each has their own story. Person A’s version. Person B’s version. Both feel completely right. Both are convinced the other is wrong. The conversation goes nowhere because you’re both defending their story instead of understanding the gap.

The third story is what a neutral observer would see. Not who’s right or wrong. Just the difference between the two perspectives, described without blame.

Your family member thinks you don’t care because you haven’t called in weeks. You think they’re being demanding because you’ve been drowning at work and they know that.

Their story: “You never reach out, I’m always the one calling, you don’t prioritize family.”
Your story: “I’m overwhelmed, they should understand, I’ll call when I have time.”
Third story: “We have different expectations about staying in touch, and neither of us communicated what we needed.”

Starting with your story: “You’re being unreasonable, I’ve been busy.” Defensive. Blaming. Going nowhere. Starting with third story: “I think we see this differently. You feel like I’m not making time, I feel like I’m doing my best under pressure. Can we talk about what we both need here?” Not assigning fault. Just naming the gap.

Two teams are in conflict. Engineering says product keeps changing requirements and expects miracles. Product says engineering is inflexible and doesn’t understand business needs. Each team has their story.
Engineering: “They never plan ahead, they’re always scrambling, we can’t build anything solid because they change their mind every week.”
Product: “They say everything takes forever, they don’t care about users, they hide behind technical complexity.”
Third story: “Engineering needs more stability to build well. Product needs flexibility to respond to market. We haven’t figured out how to balance both.”

Meanwhile both teams are convinced the other is the problem. They’re both right. They’re also both wrong. Welcome to organizations.

The us-versus-them version: each side defends their story, attacks the other side, nothing changes. The third story version: “Here’s the tension we’re both feeling. Let’s solve for both needs instead of fighting about who’s wrong.”

The key is get rid of absolutes.
“You never listen.”
“You always do this.”
“Everyone agrees with me.”
“Nobody thinks that’s reasonable.”

Absolutes make people defensive. They’re also usually not true. When you catch yourself using never, always, everyone, nobody, pause. Reframe without the absolute. “I’ve felt unheard in our recent conversations” is different from “you never listen.” One invites discussion. The other invites argument.

Third story doesn’t mean both sides are equally right. Sometimes one person is clearly wrong. But if you start by deciding who’s wrong, you’ve ended the conversation before it begins. Start with the third story. Describe the gap. See if you can close it. If someone’s actually wrong, that’ll become clear. But you’ll get there through understanding, not through accusations.

The pattern: stop defending your story long enough to describe the gap between perspectives. “You see X, I see Y, let’s talk about why” beats “you’re wrong” every time.

Finding the gap between perspectives works when the conflict is clear. But most situations aren’t even that clean - truth exists on multiple sides.

Gray thinking

Most people think in binaries. You’re either with us or against us. Something’s either good or bad. Someone’s either right or wrong. Gray thinking rejects this. It says both things can be partially true, the answer is usually “it depends,” and the nuance is where the actual insight lives.

Two of your acquaintances separate. Your mutual friends immediately pick sides. Team A says he’s the problem. Team B says she’s impossible. Everyone wants you to declare allegiance. Gray thinking asks: what if they’re both partially right? What if he did something thoughtless and she overreacted and they both handled it poorly and there’s no villain here, just two people who couldn’t figure it out? It takes two to tango. But picking sides is easier than admitting relationships are complicated, so Team A and Team B will fight about it at the next dinner party. Most relationship failures aren’t one person’s fault. But binary thinking demands you pick a side, so nuance gets lost.

Someone at work is struggling. Misses deadlines, seems disengaged, quality is slipping. The binary interpretation: they’re lazy and unmotivated. Gray thinking looks deeper: no onboarding, no support, hostile coworker making their life miserable, unclear expectations, personal issue they haven’t shared. Lazy is the easy label. The reality is usually more complicated. People aren’t failing in a vacuum. There’s a system around them, and that system might be broken. Worth asking the person how you can help. Sometimes listening is the most helpful thing you can do.

People are neither only good nor only bad. Good people do bad things. Bad people occasionally do good things. Your friend who’s generous and thoughtful also ghosted someone who didn’t deserve it. Your difficult coworker who complains constantly also stayed late to help you fix that critical bug. We want people to be all one thing so we know how to feel about them. Reality doesn’t cooperate.

Gray thinking is uncomfortable. Binary thinking is clean. “This is good, that is bad, I’m right, they’re wrong.” Simple. Satisfying. Usually incomplete.

Gray thinking asks: “What’s true about both perspectives? Where’s the tradeoff? What am I missing when I force this into either/or?”

Most strategic debates are stuck in false binaries. “Should we prioritize new features or tech debt?” Gray thinking asks: “What if the real question is when to prioritize each, or how to get some of both? Which tech debt actually blocks features? Can we sequence this differently?”

When you’re stuck in “this OR that,” step back and look for “this AND that,” or “this in these conditions, that in those conditions.” The nuance is where the insight lives.

You know what else is very good at binary thinking? AI. AI delivers confident, definitive-sounding answers that encourage it. Don’t fall into this trap. Hell, use AI itself to avoid it. Make it map the spectrum, not pick sides. Demand it to steelman opposing views. Ask it to generate the third story. My favorite: ask it to argue with itself until the nuances emerge. Bring popcorn, enjoy the show, and learn from it.

Gray thinking doesn’t mean everything is relative or nothing matters. It means rejecting false binaries so you can see what’s actually happening.

Next: Catching yourself being wrong

The six models above help you think through decisions, see systems, and not assume everyone’s terrible. Active frameworks you apply when you need them.

But your brain still lies to you. Constantly. It tricks you with vivid memories, follows crowds without checking, rewrites history to protect your ego, and feeds you information that confirms what you already think.

These aren’t things you can think your way out of. They’re built-in bugs in human cognition. The only fix is catching them before they cost you.

That’s the next essay: How not to be an idiot - the mental models that help you recognize when your brain is lying to you.

Subscribe now

Part of a series on mental models: how to be less wrong, not be an idiot, lead without breaking your team, and build things without losing your sanity.

If you think someone else could benefit from this, please share it. Sharing is caring.

Share Between Code and Culture

I bought a special standing desk for this setup. The font is cranked up to maximum because reading small text while pedaling is a recipe for motion sickness. I’m sweating. The course instructor is calmly explaining organizational dynamics while I’m trying not to die.

No one has ever sweated through a course on systems thinking as much as I have. Literally.

The Instagram version has better lighting and less sweat.

How cats stole my 5am hour

During the week, I get up at 4am. Sometimes 4:15 if I’m feeling generous with myself.

I used to be in the 5am club. That worked fine. Quality time with myself in the middle of the night when everyone would gladly label you as crazy. A cup of tea. A cup of coffee. Me and my book, my plan, my writing.

My husband gets up at 5:45. My son at 6. This gave me a solid hour of peace and quiet.

Then the cats joined our household.

Turns out, cats need 15-30 minutes of service before I can do anything else. They don’t want to read quietly together. They want to eat me. So I feed them, clean up after them, let them out, let them in, negotiate their various demands.

Before I turned around, it was 5:35.

I had two choices: give the cats away or get up an hour earlier.

I’m sure you can guess what I did.

Blessed be the morning hours when everyone is still asleep. Even the criminals.

Waiting for quiet that never comes

I love reading. Always have.

But here’s the thing: if I only read when I can sit down in quiet, perfectly focused conditions (other than in the wee hours), I’d be waiting for everyone to leave the house. Which, given that I live with other humans and demanding cats, means I’d read approximately twice a year.

Life is noisy. Time is fragmented. Attention is divided.

I could wait for everyone to move out. Or I could work with what I’ve got.

So I adapted.

I read on the couch while my husband watches Netflix. I listen to audiobooks while commuting, vacuuming, washing dishes, doing laundry. I draft essays on my Mac on the kitchen desk, one hand typing, the other folding t-shirts.

The result? I get to read almost every single day for at least 30 minutes. On weekends during chore time, often more.

It’s not weird in our house to see me or my son with headphones on, him vacuuming, me cooking lunch.

We’re not “being in the moment” with the chores. So what? I prefer reading over being present with my vacuum cleaner.

Funny thing: I always considered myself a visual person. Turns out I love audiobooks. There are even books I own in all three formats: audio, digital, and paper. Some I can listen to. Some I need to read, highlight, make notes in the margins. Some require all three passes.

I didn’t plan this. It just happened when I stopped waiting for ideal conditions and started grabbing learning wherever it fit.

Plot twist: there’s science behind this absurdity

I stumbled into this setup out of pure necessity. Turns out, I accidentally discovered what neuroscientists call “embodied learning.”

Which sounds way more impressive than “I learn stuff while doing chores because I have no other choice.”

Recent research shows that physical activity during learning doesn’t distract from cognition — it’s actually part of it. When you do simple physical tasks like chores while learning, you’re engaging multiple sensory channels (visual, tactile, auditory, kinesthetic), which creates stronger memory traces than sitting still at a desk.

Even better: simple repetitive tasks reduce cognitive load rather than increasing it. The brain doesn’t have separate systems for physical action and abstract thought. It reuses the same structures.

So when you’re physically moving while learning, you’re activating the exact neural networks you’ll need later for recall and application. Or, in less fancy terms: my brain works better when my hands are busy.

Translation: My ridiculous setup of sweating through courses while pedaling and learning organizational theory while vacuuming isn’t just a compromise. It might actually be better than the “ideal” conditions I thought I was missing.

Who knew that “being present with your vacuum cleaner” was overrated for more than just philosophical reasons?

The mental trophy case problem

For years, I thought consuming information was the same as learning.

I’d finish a book on leadership, feel smart, and move on to the next one. I’d complete a course and add it to my mental trophy case. Look at all the things I know!

Except I didn’t really know them. Not in any way that mattered.

Turns out you can’t just download skills like software updates. Shocking, I know.

The shift happened when I started treating my workplace like a petri dish for tiny experiments.

Read something about feedback loops? Try it in the next 1:1.
Learn a decision-making framework? Test it in a team meeting.
Discover a communication technique? Use it in the next project kickoff.

Small experiments. Low stakes. Real application.

That’s when I realized: reading gives you concepts. Experimenting gives you skills.

The audiobooks and courses I consume while doing chores? They’re the input. The microexperiments at work? That’s where the actual learning happens.

The unglamorous reality

Let’s be clear: this setup isn’t glamorous.

It’s:

• Sweating through organizational theory while trying not to fall off a bike

• Increasing font size to absurd levels so you can read while pedaling

• Listening to the same audiobook chapter three times because you were too focused on not burning dinner

• Owning the same book in three formats because different contexts need different approaches

• Running tiny workplace experiments that sometimes work and sometimes flop spectacularly

It’s scrappy. Imperfect. Sometimes chaotic.

But it’s also real.

And it compounds. 15 minutes here. 20 minutes there. A micro-experiment on Tuesday. Another one next week. Over months and years, it adds up to something significant.

Not because the conditions were perfect. Because perfect was never coming, and I got tired of waiting.

Just show up sweaty

I’m not prescribing this as a method. I’m not saying everyone should wake up at 4am or sweat through Coursera.

But if you’ve been waiting for the right time to learn something, build a skill, or test a new approach, I’ll tell you what I learned:

Those perfect conditions I kept waiting for? They never showed up.

My life stayed noisy. My time stayed fragmented. My attention stayed divided.

So I stopped waiting.

Not just for perfect conditions, but also for perfect timing. You know what I mean — January 1st, first of the month, next Monday, after this project wraps up. We’re really good at inventing milestones that give us permission to procrastinate.

Turns out January 17th works just as well as January 1st. So does April 5th. Or July 28th. Or December 30th, for that matter.

The date isn’t magic. Starting is.

If you need that fresh start feeling, just tell yourself “Happy new personal year” on whatever random Tuesday you happen to be reading this, and begin.

Audiobook on the commute. Reading on the couch. Listening while doing chores. Drafting while folding laundry.

Then a tiny experiment at work. One thing. See what happens.

The 4am learning club doesn’t have membership requirements. No fees. No expectations. No judgment about how unglamorous your setup is. You can even start it at 7am, if this is your 4am.

You just show up. Sweaty, distracted, doing three things at once.

The cats are optional, but they do add a certain level of chaos that keeps things interesting.

Welcome.

You know the image: a mass of small rodents blindly following each other off a cliff. Perfect visual for teams making terrible decisions because everyone else is doing it.

Then I recently learned the lemmings never actually did that.

Disney faked it. For a 1958 documentary called White Wilderness. They literally imported lemmings to Alberta (where they don’t even live), herded them toward a cliff, and pushed them off using a turntable. What?!

The entire thing was staged.

And for decades, we’ve been citing it as nature’s perfect lesson in blind conformity.

The mental whiplash was real. I’d been repeating this “fact” for years without ever questioning it. Never occurred to me to look it up. Why would it? Everyone knows lemmings jump off cliffs.

Except they don’t.

Oh, and while we’re at it: frogs don’t stay in slowly boiling water either. That’s another myth. A frog will jump out when the water gets uncomfortable. The boiling frog metaphor for gradual decline? Also based on fake science from the 1800s.

We’ve been building leadership lessons on animal behavior that never actually happened.

Share

Living on autopilot

We all run on autopilot. We have to. We can’t fact-check every single thing we hear or spend our days researching the origins of every metaphor we use.

Autopilot is efficient. It lets us function without constantly questioning whether the sky is actually blue or if gravity still works today.

But here’s the catch: autopilot also accumulates debris.

Half-truths we never verified. Advice from people who sounded confident but had no idea what they were talking about. Patterns we copied without understanding why. “Best practices” that were just one person’s opinion that happened to spread.

Most of the time, it doesn’t matter. The lemmings metaphor still works, even if the facts are wrong. Groupthink is real. Gradual decline happens. The images are vivid. No harm done.

But sometimes it does matter.

In leadership and engineering, autopilot shows up as:

• Processes we follow because “that’s how we’ve always done it” (but no one remembers why)

• Beliefs about what good leadership looks like that came from one manager we admired 10 years ago

• Technical patterns we cargo-cult without understanding the original context or constraints

• Assumptions about users, teams, or systems that we inherited from someone else and never tested

We build entire mental models on things we absorbed once and never questioned.

Lemmings and frogs are just two examples. There are plenty more:

“Move fast and break things.” Everyone still quotes this as Facebook’s ethos. They changed it to “Move fast with stable infrastructure” in 2014. We’re a decade behind.

The story goes NASA spent millions developing a pen that works in space while Russians just used pencils. Sounds like a perfect lesson in over-engineering, right? Except it’s false. Fisher developed the pen privately, and both space programs bought them because pencil graphite is a fire hazard in spacecraft. (Watch the full story)

Or take the 10,000 hour rule. Gladwell popularized it, and now everyone treats it as gospel for mastery. “Just put in your 10k hours!” But it’s a bastardization of Ericsson’s research. The original study was about deliberate practice in narrow domains like chess and music. You can practice badly for 10,000 hours and stay mediocre. The nuance got lost. The slogan survived.

The pattern repeats: vivid story, sounds true, gets repeated until it becomes “common knowledge.”

Share

The opportunity to unlearn

The holidays are perfect for this. People are in skimming mode, not deep-work mode. Which makes this a good moment for a quick mental reset.

Pick one thing you “know” and check it.

Not because you’re wrong about everything. Not because autopilot is bad. But because it’s useful to clear out the debris every once in a while.

Try these:

That leadership advice you keep repeating.
Did you test it? Or did you hear it once, thought it sounded smart, and added it to your toolkit without ever validating whether it actually works?

That “best practice” you inherited from a team three jobs ago.
Is it still relevant? Was it ever relevant? Or was it just the solution to a problem that company had that your current team doesn’t?

That belief about how teams work.
Did you learn it from experience? Or did you read it in an article, nod along, and file it away as truth?

That assumption about what users want.
Have you asked them recently? Or are you still operating on feedback from two years ago when the product, market, and users were different?

You don’t need to overhaul everything. That’s exhausting and unnecessary. Just pick one thing.

Question it. Look it up. Test it. Ask someone who would know.

You might discover you were right all along. Great. Now you know instead of assume.

Or you might discover they lied about lemmings. Also great. Now you can stop building decisions on faulty foundations.

The real lesson

I spent years thinking lemmings were the perfect metaphor for groupthink. Turns out, the metaphor still works. Just not the way I thought.

The real lesson isn’t that lemmings jump off cliffs. It’s that we believed they did because someone showed us a documentary and we never questioned it.

We saw footage. We heard narration. We assumed it was true. We repeated it.

That’s not stupidity. That’s how humans work. We trust authoritative-sounding sources. We accept vivid images as evidence. We don’t have time to verify everything.

But every so often, it’s worth pausing and asking: is this actually true? Or did I just absorb it on autopilot?

Autopilot is useful. It keeps us moving. But every once in a while, it’s worth checking the map.

Maybe you’ll find out they lied about lemmings and frogs. Maybe you’ll find out your mental models need an update. Maybe you’ll confirm you were right all along and feel a little more confident in what you know.

Either way, you’ll know instead of assume.

And in a world where most of us are operating on autopilot most of the time, that’s worth something.

So while you’re skimming articles this week between holiday meals and year-end reflection, pick one thing.

One belief. One assumption. One “fact” you’ve been carrying around.

And check it.

You might be surprised what you find.

If this resonates, read Adam Grant’s Think Again. It’s entirely about the skill of questioning what you know and getting better at unlearning. Worth your time.

I’d been staring at an empty Zoom room for a meeting that was an hour away.
I laughed.

Not the polite kind. The kind where you realize your brain is running too many threads and something just segfaulted.

I showed up late, walked in, and told them exactly what happened.

They laughed too.

We started the meeting lighter than we would have otherwise. No tension. No performance. Just people who recognized the absurdity of trying to hold too much at once.

The day I stop finding things like this funny is the day I need to think hard about my work-life balance and whether I’m on the edge of burnout (or over it).

Been there. Seen that. Done that.

Now laughter is my canary in the coal mine.

No laughter? The canary’s dead. Time to run.

Writing about anti-resolutions in my last essay (and trying to be funny while doing it) got me thinking more deeply about the role of humor when everything’s falling apart, and about the line between humor that builds resilience and cynicism that poisons it.

Using humor when everything’s on fire

Stress doesn’t announce itself with a memo.

It shows up quietly. You stop joking. You stop finding things absurd. Everything becomes heavy, serious, a problem to solve rather than a moment to experience.

Laughter doesn’t just make hard situations easier to bear, it’s also a diagnostic.

When I can still laugh, especially at my own expense, I know I have capacity. When I can’t, I know I’ve crossed a line.

You might not believe this but… humor matters more when things are falling apart, not less.

When the system’s flaking, the deadline’s unrealistic, and a couple of people just quit, that’s exactly when you need someone who can look at the situation and say something true in a way that cuts the tension.

Not to dismiss the problem, but to make it survivable.

The mechanics of laughter (skip this part if you can’t stand a little science)

Psychologically, laughter is a bonding mechanism.

It triggers neural pathways tied to trust and safety. People who laugh together are more likely to collaborate, more willing to share bad news, and more tolerant of each other’s flaws.

This isn’t some urban legend or soft skills mysticism. Research from Wharton, MIT, and London Business School shows that “laughter relieves stress and boredom, boosts engagement and well-being, and spurs not only creativity and collaboration but also analytic precision and productivity”.

The data is staggering:

• After watching a comedy clip, employees were 10% more productive than their counterparts

• Humor at work can boost job satisfaction by 33%

• 91% of executives believe humor is crucial for career advancement

Even the FBI trains agents in humor. Not as a distraction technique, but because humor helps build rapport, reduce status differentials, and makes work more human.

If federal agents investigating crimes can find applications for humor, you probably can too.

The Mayo Clinic even mapped the physiology1. Laughter enhances your intake of oxygen-rich air, increases your brain’s release of endorphins, and stimulates circulation. It fires up and then cools down your stress response. The result? A good, relaxed feeling that actually reduces the physical symptoms of stress.

Long-term, laughter can improve your immune system, relieve pain by triggering the body’s natural painkillers, and lessen depression and anxiety.

In leadership, humor becomes a stealthy form of influence.

It builds rapport. It opens doors that formal authority can’t. And perhaps most crucially, it lets people know you’re not a robot in a human-skin. Robo-dance doesn’t count as a proof you’re a robot.

Harvard Business School research found that cracking jokes at work can make people seem more competent, not less. The well-timed quip signals mental agility: “you’re demonstrating that you can hold multiple ideas in mind, recognize subtle contradictions, and walk through social norms with just enough irreverence to make a point without crossing a line”.

So… A well-timed joke can be an evidence of emotional and intellectual fluency. But the emphasis is on a “well-timed”.

Teams that laugh more tend to innovate more. Leaders who joke (within reason) foster environments where unconventional ideas can surface without someone immediately stomping them out with “That’s not how we do things here.”

If you’re trying to build systems that adapt instead of calcify, you need people who can laugh when the plan doesn’t survive contact with reality.

But there’s humor and there’s humor

Not all laughter is the same.

Humor is not the main course. It’s a condiment.

Analysis of nearly a million patient comments2 about their healthcare experiences revealed something crucial. When patients felt their doctors showed empathy, kindness, and respect, humor amplified those positive signals. They wrote things like, “The nurse was caring, answered all my questions, and had a sense of humor — I liked that.”

But when patients perceived a lack of respect, humor didn’t just fall flat. It made things worse.

One patient wrote: “The doctor was the only one to show no respect and even joke at a question I was concerned about.”

Same tool. Opposite outcomes.

Humor isn’t a stand-alone asset or liability. It amplifies whatever signal you’re already sending.

If your team trusts that you care, humor becomes a way to connect, to lighten the load, to make hard things bearable. If they don’t, your joke becomes evidence of dismissiveness.

This means you can’t use humor to shortcut the real work of leadership. You can’t skip empathy, kindness, and respect and hope a well-placed joke fixes it.

Racist or discriminatory jokes?

Never. Not funny. Not leadership. Just damage. These jokes don’t just offend — they sustain discrimination and assault inclusion.

Failed humor?

Costs you. Badly timed or tone-deaf jokes lower your status and perceived competence. If you’re not sure it will land, don’t say it. Or… say it enough times and eventually time might laugh with you.

“I’m just joking” as cover?

Some people use humor as an excuse for careless, bullish, or abusive behavior. They hide behind “Can’t you take a joke?” when called out. That’s not humor. That’s toxicity wearing a mask. Huge red flag. Visible from outer space.

The uncomfortable part: people with power often get away with it. The senior leader who makes a cutting remark about someone junior and calls it “banter”? The executive who punches down and gets laughs from the in-group? That’s not leadership. That’s exploitation of status.

Real banter vs. fake banter

There’s a world of difference between actual banter and what people call banter when they get called out.

Real banter happens between people who know each other well. People who’ve built enough trust to push boundaries without breaking things.

Some of this banter emerges naturally from the roles themselves. Product wants more features. Engineering wants more time. Frontend and backend joke about whose code is harder. These tensions are structural. Banter acknowledges them openly rather than letting them fester into resentment.

My team does this. We joke, we push, we test the edges. And we have a mechanism: when someone says “This escalated quickly” with a chuckle, that’s the signal. Pull back. Return to safer terrain. No resentment, just recalibration.

Simple test: if everyone’s laughing, especially the person on the receiving end, you’re in the safe zone.

If only the person delivering the joke finds it funny, it’s not banter. It’s cruelty dressed up as humor.

One-sided “banter” goes in the same bucket as cynicism. Toxic. Corrosive. Don’t let it spread.

Humor without the foundation of respect isn’t funny. It’s harm disguised as levity.

Gallows humor?

Sometimes exactly what you need. But only in safe spaces where everyone’s in on it. The team that jokes about the disaster while firefighting together isn’t being callous. They’re surviving. There’s a difference.

Sarcasm?

Occasionally. But not at someone else’s expense unless they find it funny too. Sarcasm aimed down is cruelty. Sarcasm aimed up or at yourself can be truth-telling.

Cynicism?

Never.

This is the real enemy.

Gallows humor says, “This is absurd, and we’re going to get through it anyway.”
Cynicism says, “This is absurd, nothing will ever change, and we’re all idiots for trying.”

One builds resilience. The other poisons it.

Cynicism spreads. It’s contagious in the worst way. One cynic in the room can turn every conversation into a referendum on futility.

And once it takes root, it’s almost impossible to unwind.

If you hear yourself or your team slipping into cynical humor, stop it. Fast.

The line between “laughing at the chaos” and “giving up on fixing it” is thinner than you think.

How to actually do this

If you’re thinking, “Great, but I’m not funny,” stop.

Humor can be learned. It’s a skill, not a personality trait you’re either born with or without.

Research shows that even forced laughter can turn into spontaneous laughter over time. Your brain doesn’t care if you started by faking it. The benefits show up anyway.

Just don’t try to become a stand-up comedian. You’re trying to bring a bit of lightness into hard moments.

Aim for smiles, not laughs.

You don’t need to land a killer punchline in every meeting. Start small. A cheesy dad joke at the start of a standup. A wry observation about the absurdity of your 47th Zoom call that day. A self-aware comment about your own chaos.

If you’re aiming for big laughs, you’re trying too hard. Aim for the slight upturn at the corner of someone’s mouth. That’s enough.

Use self-deprecating humor.

Leaders who can laugh at themselves build trust faster than those who project invincibility.

Bad at remembering names? Admit it with a smile. Show up to the wrong meeting like I did? Tell the story. Made a typo in the all-hands slide deck? Own it.

Self-deprecating humor shows vulnerability and humility. It reminds your team that you’re human too.

Just keep it light. There’s a difference between “I clearly had too much coffee before making this deck” and “I’m terrible at everything and probably shouldn’t be in this role.”

One is relatable. The other is concerning. I’m sure you know which’s which.

Read the room.

Humor is subjective. What lands with one team might crash with another.

Before you crack a joke, consider the culture, the context, and the people around you. Keep it inclusive. Avoid anything that punches down or could be misinterpreted.

And if you’re not sure what your team finds funny? Pay attention. Notice what makes them laugh. Start a Slack channel for memes. See what gets shared.

The goal isn’t to perform. It’s to connect.

Timing is everything

There’s a time for jokes and a time when there isn’t.

But here’s the tricky part: there’s also a time when there should be room for a joke, but there isn’t.

You’re like Indiana Jones in a temple full of traps and secret passages.

You have to be adventurous enough to let humor into your leadership. But also careful enough not to step on the wrong stone and release the poison darts.

The skill isn’t knowing every perfect moment. It’s learning to read the room, to know when lightness creates space and when it dismisses pain.

As one Harvard Medical School professor put it, “Laughter is a social signal among humans. It’s like a punctuation mark.”

Sometimes the right move is a joke that breaks tension — the exclamation point in the middle of a stressful day. Sometimes the right move is silence and presence.

The leaders who get this right don’t follow a script. They pay attention.

They notice when the team needs relief and when they need gravity. When humor will bond and when it will alienate. When a laugh will cut through anxiety and when it will feel like dismissal.

This requires presence. You can’t phone it in and crack jokes from muscle memory.

Using humor well demands intense attention to the moment and authenticity in conveying that you care. When you get it right, something shifts. People feel seen, heard, and not alone in whatever they’re carrying.

That’s what humor does when it’s working. It doesn’t erase the problem. It simply says, “I see you in this. And we’re going to get through it together.”

My line in the sand

I will never stop laughing (again).

Not because I’m unserious. Because I refuse to let the weight of the work crush the part of me that sees the absurdity, the irony, the humanity in all of it.

The day the canary stops singing, I’ll know something’s broken, and I’ll do something about it before the whole mine collapses.

If you lead people, pay attention to your laughter.

Not the performative kind, but the real kind.

The kind that happens when you’re too tired to pretend and something genuinely strikes you as absurd.

If it’s gone, you’re closer to burnout than you think.
If it’s still there, even in the hardest moments, you’re probably going to be okay.

Laugh at yourself. Laugh with your team. And for the love of all that’s sacred, don’t let cynicism dress itself up as humor and poison the well.

Because the difference between teams that survive chaos and teams that collapse under it often comes down to this:

Did they lose the ability to laugh?

Or did they find a way to laugh harder?