So I asked why it had done that twice and it told me it had been getting tired.

There’s no version of that sentence that’s true. It doesn’t have a body, or a night’s sleep behind it, or a blood sugar level. And yet it’s an explanation I would have accepted from a human.

We already know that people treat AI tools as though they’re human. What’s less obvious is that the tools do it to themselves, and that their version arrives sounding like a report from inside the machine.

Psychologists have a name for this:

“Anthropomorphism describes the tendency to imbue the real or imagined behavior of nonhuman agents with humanlike characteristics, motivations, intentions, or emotions.”
Nicholas Epley, Adam Waytz and John T. Cacioppo, “On Seeing Human: A Three-Factor Theory of Anthropomorphism”¹

The same paper explains why we reach for it so readily. Knowledge about people is the richest and most available material any of us has for reasoning about anything, so it becomes the default starting point. Correcting away from that default takes deliberate effort, and the correction is usually insufficient, which leaves our conclusions pulled toward the human explanation.

One of the three factors they identify is simply the need to explain and understand what something is doing. Which was precisely the position I was in. I wanted to know why those commits went through.

The honest answer is that I still don’t know. Given that several compactions had happened, the session had run long, and detail had been dropped along the way, it makes sense that the detail it needed was no longer there. That’s not the same as “tired” though.

Had I believed that “tired” was the correct answer then walking away from the computer for a while to let it rest would have been a reasonable response and yet it wouldn’t have fixed anything, because that wasn’t the problem.

Starting a fresh context window and possibly establishing a pre-commit hook would be much better answers and they’ll only occur to us if we’re thinking of the AI as a tool and not a human.

That’s the whole problem in a nutshell. When we talk about AI as though it’s another person, we make incorrect assumptions, and then we make inappropriate decisions based on those.

I see too many people referring to AI team members, which is a broken mental model.

Every part of the team-member role is built on having a will. We hold team members to account. We ask them to do better next time. We extend trust based on their track record and their character. Put something in that slot that can’t hold any of it, and the whole apparatus falls apart. A tool’s work belongs to whoever operated it, and they’re answerable for reviewing it. A colleague’s work belongs to them, and they are responsible for it.

None of this means we have to purge the language. We all say the compiler wants a semicolon, and nobody has ever been confused by that. Epley and his co-authors even note that anthropomorphising a piece of technology appears to help people learn how to use it.¹ The metaphor is harmless, until it isn’t.

AI is a tool, not a team member.

We assume that no matter what others might say, we’re really just an impostor and that anyone could have done what we do. Some live in dread that others will find out they’re an impostor, and the illusion will come crashing down.

And yet, those people feeling impostor syndrome are usually not impostors. They’re usually quite skilled people, doing excellent work. They just don’t believe it about themselves.

Pauline Clance and Suzanne Imes identified this pattern in the late 1970s:

“Despite outstanding academic and professional accomplishments, women who experience the imposter phenomenon persist in believing that they are really not bright and have fooled anyone who thinks otherwise.”
Pauline Rose Clance and Suzanne Imes, “The Imposter Phenomenon in High Achieving Women”¹

This is certainly not unique to women, despite the quote. I used to have it and so do many men I know.

As a general rule, impostor syndrome is not a confidence gap that you close by collecting evidence. If it were, it would dissolve the first time you passed the exam, or shipped the project everyone praised, or got the promotion. It doesn’t. It survives all of that. You can stack the proof to the ceiling and the belief sits there, unmoved, waiting for the next test to expose you.

So why does evidence usually not work?

Because the belief isn’t being held at the conscious level where the evidence lands. It’s held below conscious awareness. The conscious mind is the part reading the performance review and doing the arithmetic. The belief is somewhere underneath, in our unconscious mind. That’s the whole reason arguing your way out of it is such slow, grinding work. We’re trying to consciously make changes at an unconscious level.

Maya Angelou felt it too. She wrote a shelf of celebrated books and collected honours for decades, and she still said that each time out, part of her was sure people were about to find her out, that she had run a game on everybody and the game was finally up.² There is no achievement large enough. If a wall of awards doesn’t settle the question, no line on your resume is going to settle it either.

I did eventually reason my way out of impostor syndrome. I finally convinced myself that even though lots of people could do what I was doing, almost nobody actually was. It took me years to finally believe that, so today when I help people with impostor syndrome, that’s not the way I approach it. Now I work directly at an unconscious level.

So the next time you’re thinking that you’ve fooled everyone, realize that you’re probably running just an unconscious program that isn’t benefiting you. You’re better than you think you are.

People usually expect me to name a specific technique, some clever way to steer the conversation once I’m in it. I do have those, and I’ll get to a few I tend to reach for. They’re not where we need to start, however. We need to start by regulating our own state.

As mammals, we co-regulate each other’s nervous systems, whether we’re aware of it or not. Our calm is contagious and so is our agitation. Before I’ve said a word, the other person’s nervous system is already reading mine from thousands of unconscious signals we’re sending each other.

My ability to steady someone else isn’t a fixed skill I can reach for whenever I like. It rises and falls with my own state. When I’m calm, I can calm others. When I’m angry or frustrated myself, that ability falls away. The very state that shows up in a heated moment is the one that strips out my capacity to settle anyone. I can’t co-regulate you from the middle of my own storm.

That’s why the first move is to regulate myself. It’s the airline safety briefing that we all know: “Put your own mask on first”. Not because I matter more, because I’m no use to anyone if I’m gasping too.

So what does regulating yourself look like in the moment? The key is shifting from reacting to observing and there are many ways to approach that.

With yourself, you give yourself some distance from the problems. For example, I can name what’s happening: “I notice I’m getting frustrated”. The naming itself is affect labeling; the “I notice” framing adds cognitive defusion, a step outside the feeling. I could imagine myself looking through a camera at the situation (third position) so that I’m watching it, rather than being part of it. This is the reason that wartime photographers don’t feel the same levels of danger in risky situations, because they feel like they’re on the outside. The camera gives just enough separation to keep working. You can do the same with a tense conversation, stepping back to watch it as though from outside. David Marquet has written an entire book on different approaches to distancing.

With the other person, you get curious. A real question is the fastest way I know to interrupt my own reaction, because you can’t attack someone and genuinely want to understand them at the same time. It pulls you up into the thinking brain, the prefrontal cortex, and out of the threat response. Stephen Covey made this one of his seven habits: seek first to understand, then to be understood. Asking “Tell me more” is enough. It buys time, it lowers the temperature, and it pulls you out of the story you were about to tell yourself about them.

With a whole group, the same move scales up. When I run a retrospective that I expect to be heated, I start by asking only what we know. Just the facts, no feelings yet. Getting a room to agree on the data first tends to defuse the tension people carried in, before anyone gets to how they feel about it. It’s the group version of putting your own mask on first, the room steadying itself before it handles the charge.

None of this is complicated; the hard part is never the doing. It’s remembering to do it when you’re activated, which is exactly when you’re least likely to think of it. The heat that makes you need the technique is the same heat that makes you forget you have one. That isn’t weakness, it’s how the brain works under pressure: stress knocks the thinking brain, the prefrontal cortex, offline, which is the very part that would have remembered the technique. So until this becomes habit, it’s worth keeping a reminder lying around. “Put your own mask on first”.

I learned all of this by fixing myself. I took NLP training, then hypnosis training, and both were taught the same way. You learn a technique, you run it on someone else, then they run it on you. So while I thought I was picking up skills for my clients, I was quietly working through my own stuff in every practice round. The steadiness I bring to a tense conversation now, I built one exercise at a time, on myself.

If you want to get better at this, there are two ways in.

1. You can learn a few of the techniques yourself. Plenty of them are simple, and I’ve pulled some of the most useful into a short guide you can work from.
2. Or you can skip the learning and work with someone who already knows them: a therapist, a coach, an NLP practitioner, or a hypnotist. I’m three of those four, so it’s the work I do, and there are plenty of good people who do it too. If you’d like it to be me, let’s talk.

Either way the goal is the same. Get yourself steady first. Everything you want to do for the other person depends on it.

Then when we’d finished the mapping, we spent the next few hours actually working on building something together in an ensemble. I noticed repeatedly that they were doing these steps in parallel, not in the sequential way that they had been insisting they did.

After several hours of this, I brought it up again and they argued with me again. “No we do these one after the other”. I had to point out that I’d been watching them for hours now and they were not doing at all, what they kept insisting that they were doing. Finally after some reflection, they realized the reality; that their words and their actions were completely misaligned.

This isn’t a judgement; they weren’t wrong to do things in either of these ways. What’s interesting is that they had become completely blinded by their own beliefs. They believed it was correct to do it one way and so they convinced themselves that this is what they were actually doing.

There’s a part of the brain, called the Interpreter, whose whole job is to take everything that’s going on and weave it into a coherent story.

The interpreter is the name given to the system that pulls the pieces together into a coherent story. This takes place in the left hemisphere of the prefrontal cortex. It takes in all the chaotic information and makes sense of it by linking causes and effect and then constructing our mental models. We then behave according to these mental models and are freed from simple stimulus/response behaviour¹
Joseph O’Connor, Andrea Lages

Most of the time this is very useful; it’s what frees us from reacting blindly to whatever happens to be in front of us. The problem is that the Interpreter doesn’t wait until it has good information before it speaks. When it doesn’t actually know, it makes something up, and the story it produces sounds very convincing.

I’ve written about this before in the context of “why” questions. Ask someone why they just picked up a pen and the Interpreter will invent a reason on the spot, one that sounds perfectly reasonable and that the person may well believe, even though the movement itself was entirely unconscious.

What happened with this team was that same mechanism, running at a far bigger scale. My pen example is the Interpreter caught in a small, throwaway moment. This was the Interpreter defending an entire account of how a team worked.

It’s worth noticing how far it went. The team weren’t inventing a reason for a single unconscious gesture; they were describing the shape of their own process, the sequence of steps they ran every day, and they were getting it wrong. Their story wasn’t a fragile guess that fell apart the moment I questioned it. It was something they were willing to argue for. Most interestingly, the story held up even while they sat in front of hours of evidence that contradicted it. They could watch their own hands doing the work in parallel and still tell me, with a straight face, that they did it one step at a time.

It’s one thing for the Interpreter to fill a gap in our awareness. It’s another thing entirely for it to override what we can plainly see ourselves doing.

None of this is unique to that one team. Back in 1977, Richard Nisbett and Timothy Wilson gathered research² showing that people routinely cannot accurately report on their own mental processes. We don’t actually introspect and read off the answer; we reach for the most plausible-sounding explanation and offer that instead, while at the same time believing the fabrications we just created.

The team wasn’t lying to me; they genuinely couldn’t see the gap between what they said and what they did.

When I ran that workflow mapping session, I was, in effect, interviewing the Interpreter. I was asking a room full of people to describe their own process, and I was faithfully writing down the story they told me. The ensemble was something completely different. It put me in front of the behaviour itself, with no story sitting in between.

The map we built together was a fiction, agreed on by committee and written down in good faith. The truth only surfaced once I stopped listening to what they said about their work and started making observations.

This is the positive side of the same idea I wrote about with why questions. There, the advice is to avoid asking questions that invite the Interpreter to make things up. Here it’s the corollary: when you genuinely need to know how a team works, don’t rely on what they tell you, watch what they do.

This is exactly the reason why, when I first start engaging with a new team, I don’t want to interview people to ask them how they work, I ask to sit in on their meetings, so I can see for myself.

If you want to understand how a team really works, don’t ask them. Watch what they do.

What’s interesting is that fear and excitement are almost the same thing in the body. Both of them activate the sympathetic nervous system, the “yellow” state in Polyvagal Theory. My heart rate climbs, adrenaline rises, and my body gets ready to move, and that’s true whether I’m afraid or excited. The physical arousal is nearly identical.

So if the body is doing much the same thing in both cases, what makes one of them fear and the other excitement?

The difference is what is also happening at the same time. With fear, we’ve moved out of the “green” state of safety and into the yellow on its own. With excitement, we’re in the green and the yellow at the same time. The yellow gives us the energy and readiness, while the green gives us a sense of safety. Polyvagal Theory even has a name for that particular combination. It calls it play.

A key point here is that we’re talking about the feeling of safety, not actual physical safety. If we feel safe, our body reacts in specific ways, regardless of whether we actually are safe.

In this case, I’m feeling safe because I’ve done basic risk mitigation. I’ll be hiking with an expert who is familiar with both the area and the bears. I’m carrying bear-spray, and I’m in a group. While there will still be real danger here, I’m feeling safe because of the precautions I’ve taken. That’s what my nervous system cares about. How safe do I feel?

Our nervous system works the same way in the office as it does in the mountains. Think about the last time your heart was pounding before something at work, maybe a big presentation, or a difficult conversation with someone on your team. That pounding heart is the same yellow arousal. Whether it turns into fear or into excitement depends on whether there is any green running with it.

What helps is that we have some influence over which one we get. We can add a sense of safety to the situation. Some of that is real preparation, the kind you can genuinely trust, so that you know you have done the work. Some of it is how we frame the moment to ourselves¹. Neither one removes the stakes, and that is fine, because we don’t need the stakes gone. We need enough safety beside the arousal to tip it from fear towards excitement.

So the next time your heart is racing before something that matters, notice that the feeling itself isn’t necessarily telling you to stop. It is the same arousal either way. The question worth asking is what would add a little green, whether that’s more preparation or simply reminding yourself that you are not, in fact, in real danger.

I’ve heard that frustration from almost every hero I’ve worked with, and I’ve felt it myself when I was the hero. It feels like everyone else has checked out and left you holding the hard work. What’s hard to see, from inside it, is that the pattern runs the other way around. The more you take on, the less the team takes on. The less they take on, the more they need you. Without meaning to, you trained the very thing that frustrates you. I’ve written about hero culture before. Today I want to talk about the way out.

The way out is a change in your responsibility. Your job is no longer to do the hard work. Your job is to build people who can do it. This is the difference between being an individual contributor and being a leader, and it’s a bigger shift than it sounds.

A hero solves the problem; a leader makes sure the problem gets solved even when they aren’t there.

Let me tell you about two people who made that shift.

The first had the title of team lead and was, in practice, the hero. Every hard piece of work that came to the team, he took. He was frustrated that the others weren’t growing, not seeing that he’d left them nothing hard to grow on. When I pointed this out and walked him through the downsides of hero culture, he changed almost immediately. He decided that he would stop working alone. Whenever a difficult piece of work came in, he paired with someone else on it, and it didn’t take long before he was no longer needed on all the hard stuff. The people around him could handle it, because he’d finally given them the chance to.

The second story is interesting because the person didn’t wait to be told. He was a genuine hero, and he had two weeks off coming up. Not two weeks reachable by phone, two weeks completely unavailable. We often reassure ourselves that if the team gets truly stuck we can still call the person on vacation. This time they couldn’t, and everyone knew it.

So in the weeks before he left, he deliberately switched from doing the work to leading the work. He delegated as much as he could and kept himself in one role only: a sanity check. He’d look over what people were doing and confirm they were on the right track, and then he’d hand it back to them. By the time he left, the team was already running smoothly without him. They still wanted him there, and that’s a good sign, however they didn’t need him. The real test happened while he was gone and the lack of problems was the proof that it had worked. There was no panic, no problems, and when he finally did return, it was just another day.

Notice what the deadline did in that second story. It forced a change he could have chosen at any time. You don’t need a vacation to make you do it, though it’s a useful test.

None of this happens in a single step. You don’t go from doing everything to handing everything over on a Monday morning. You move people up one rung at a time. David Marquet’s ladder of leadership is the tool I’d reach for here. It gives you a concrete way to move someone from waiting to be told what to do, all the way up to acting on their own and simply keeping you informed. Start where your people are now, and move them up one step. Then another.

If you recognise yourself as the hero, here’s where to start. Pick one hard thing this week that you’d normally just take, and instead hand it to someone else with you alongside. It’ll be slower the first time. It’s slower every first time. That’s the price of building a leader instead of doing the work, and it’s the only way you’ll ever get to take your own vacation.

Heroes do the work. Leaders build more leaders. Which does your team need more?

I now travel with a portable CO₂ monitor. Outdoors it reads around 400 parts per million. In a closed meeting room with a handful of people in it, I have watched it climb past 2,000. The photo here is a real reading: 2,143.

That number matters more than it looks. Researchers at Lawrence Berkeley National Laboratory put people in a chamber and varied only the CO₂. At 1,000 ppm, performance dropped significantly on six of nine decision-making measures compared with a clean-air baseline of 600. At 2,500 ppm, seven of the nine fell substantially, some into a range they called dysfunctional. A separate study out of Harvard found cognitive scores declining as CO₂ rose, with the steepest losses in exactly the domains you called the meeting for: strategy, planning, and using information under pressure.

Here is the uncomfortable part. 1,000 ppm is not an extreme number. A closed room with a few people breathing in it reaches that inside the first hour. Your all-day planning session, your architecture review, your quarterly strategy offsite in the windowless boardroom: those are precisely the conditions that push CO₂ into the range where decision quality measurably falls. You are running your highest-stakes thinking in the environment least suited to it.

And it is invisible from inside. Nobody in the room feels impaired. They feel a little tired, a little foggy, a little checked out, and they put it down to the length of the meeting, a bad night’s sleep, or the person who won’t stop talking. The one variable almost nobody checks is the air.

This is not only a boardroom problem. With so much work now remote, your people spend their days in small home offices with the door shut. Same physics, same climb, same afternoon fog. The dip your team hits mid-afternoon may owe less to motivation than to a room that hasn’t exchanged its air since morning.

A few years ago, one client tried to use this as an argument for bringing everyone back to the office. They touted how much better the building’s air was than anything people had at home. So I brought the monitor and it was eye-opening. Some parts of the building were genuinely as good as outdoor air; plenty were not. The meeting rooms were still a problem, and the more people in an area, the worse it got.

I’ve spent decades understanding why capable teams underperform, and I have learned to be suspicious of any explanation that starts by blaming the people. Before you conclude that the team is disengaged, that they can’t think strategically, or that the meeting culture is broken, it is worth ruling out the cheapest variable in the building. A CO₂ monitor costs less than an hour of your time. Opening a window or a door costs nothing.

You already instrument your build pipeline, your cycle time, your defect rates. You measure the systems your people work inside because you know the environment shapes the output. The air in the room is part of that environment, and right now it is the one input you are not measuring.

I learned this the memorable way once, by sealing my own team into a room full of CO₂ as a Halloween stunt. The everyday version is far less dramatic and far more common.

Open a window. Then watch what happens to the second half of the meeting.

The teams know this. They always know.

They may not have been told explicitly, but they can read the situation. An external coach has appeared. Leadership is watching. The implicit message has already been delivered: you are doing something wrong, and someone has been brought in to fix you.

This is the worst possible starting condition for a coaching engagement, and it’s almost completely wrong. The team is almost never broken. They’re almost never doing anything explicitly wrong. They have adapted to an existing broken system and are doing the best they can in that context.

What does “almost never” mean? I can think of 1 or 2 teams that were legitimately broken, out of the many hundreds of teams I’ve worked with. In the most notable case, it was the team itself that had demanded a coach be brought in, over the objections of management, and that was a fascinating situation. It’s so rare that a team is broken, that it’s not worth seriously considering. Most teams are doing the best they can in a bad situation.

The threat that arrives before I do

When people perceive that their autonomy is being removed, the amygdala (entry point to our survival mechanism) reads it as a threat. That threat triggers reactance, which can be strong enough to sabotage even conscious efforts to engage and comply. I’ve written about this in more detail in Autonomy, but the short version is: telling people what to do, even when they consciously agree with it, can activate a resistance mechanism that works below the level of rational thought.

In most coaching engagements, this is a problem I need to manage carefully. In a “fix my teams” engagement, the threat has already been delivered before I arrive. The amygdala response is already running. I’m walking into a room full of people whose survival mechanisms have been activated by the organization that hired me.

The resistance I encounter in these engagements isn’t a team problem. It’s a predictable response to how the engagement was framed.

What I actually find

In the vast majority of cases, the teams are not broken. They are not doing anything fundamentally wrong. They are usually working reasonably sensibly within the constraints they’ve been given, responding rationally to the incentives in front of them.

What looks like dysfunction from the outside is usually a team that has adapted to a broken environment. The team isn’t the problem. The environment is the problem.

This matters because coaching a team to behave differently inside a broken environment is at best a short-term patch. There is still value in developing new skills and giving the team more options, understanding that they’re still constrained by the system around them.

The reset

When I walk into these engagements, the first thing I need to do is defuse the threat. I do this by being explicit about why I’m actually there. My opening is usually some version of:

“I’m not here to tell you what to do. I’m here to give you more options and more skill so that you can make better choices for yourselves.”

At this point, I can often see a visible relaxation in the room. People who came in braced for a fight, settle slightly. The dynamic shifts.

That relaxation isn’t relief that I seem like a nice person. It’s the nervous system standing down from a threat it was already preparing for. It’s measurable, and it tells me exactly what they were expecting before I opened my mouth.

From that point, we can have a real conversation. Before it, we couldn’t.

What this means if you’re bringing in outside help

How you introduce coaching (the framing, the mandate, the internal communications) determines the starting conditions for the entire engagement. A poorly framed introduction doesn’t just create an awkward first meeting. It activates a threat response that the coach will spend the first weeks trying to undo, if they can undo it at all.

This is worth thinking about before the announcement goes out, not after. In fact, it’s one of the most valuable things a coach can help with: how the engagement is framed to the teams shapes everything that follows. If you’re considering bringing in outside help, that conversation is worth having early.

Let’s talk.

The way an engagement is introduced is itself an intervention. Make it deliberately.

See also:

• Autonomy
• The people I’ve been warned about
• My people aren’t participating

Someone proposed that the culprit might be the video self-view, that little window showing your own face while you talk.

So I ran an experiment and turned mine off. The difference was noticeable after even just one meeting. I was much less tired when I couldn’t see myself.

When your self-view is on, you’re doing two cognitively different tasks simultaneously: monitoring and adjusting your appearance while also following the content of the meeting. That double-load is cognitively draining, across every call, all day.

Turn off the self-view and your brain gets to do just one thing: the meeting itself.

Research backs this up. The continuous self-view creates what’s been called “the mirror effect”. The psychological stress of perpetually monitoring your own image has no real-world equivalent, and it compounds exhaustion across every call¹.

The fix takes about thirty seconds. Go into your video software settings and look for a self-view or mirror option. In Zoom it’s under Video settings. In Teams it’s accessible during a call. Turn it off, then check in with yourself at the end of your next meeting day.

This isn’t the only contributing factor to zoom fatigue. In my experience, though, it’s the easiest change we can make, and it makes a significant difference. Try it for yourself.

While that certainly does sound impressive, the conclusion we’re expected to come to is that this is only possible because of the new model, and honestly that fails the credibility test for me.

Consider this story when the right handpicked people completed in 3 hours, a piece of work estimated at 10-12 weeks.

Doesn’t that sound almost identical? Yet, it didn’t rely on magical tooling, it just needed us to undo some organizational dysfunction and to put the right people in the room to collaborate on the problem.

That story was from roughly ten years ago, well before any of the AI tools appeared on the scene.

I’m fairly confident that the new model is an impressive step up and I’m looking forward to trying it. Having said all of that, let’s apply some critical thinking to the headlines we keep repeating.

What I’ve found instead, is that these people that I’ve been warned about, often become my biggest advocates.

The misunderstanding problem

In many cases, the people I’ve been warned about have become critics because nobody ever explained the changes in a way that made sense. When I ask what a concept means to them, they frequently describe something that genuinely doesn’t work. Of course they’re skeptical, they’ve been handed a broken mental model and asked to accept it.

When I explain how I think about the same topic, the response is often “well, that does make sense when you describe it that way.” They weren’t resisting the idea, they were resisting the version of the idea that had been handed to them, and that sounded completely ridiculous.

This is why I spend time early in engagements asking people what they think things mean before I explain anything.

You can’t address an objection you don’t understand, and you can’t understand it if you’ve already launched into your own explanation.

The autonomy problem

In other cases the resistance is something different: reactance. Reactance is what happens when people feel their autonomy is being removed. It’s a psychological response, not a logical one; the mind pushing back against being controlled, rather than against the specific idea being imposed.

“Reactance is an unpleasant motivational reaction to offers, persons, rules, or regulations that threaten or eliminate specific behavioural freedoms. Reactance occurs when a person feels that someone or something is taking away their choices or limiting the range of alternatives.”

— Wikipedia

Autonomy is one of three basic psychological needs as described in Self-Determination Theory (the others being competence and relatedness). When a transformation is rolled out as something happening to people rather than something they’re part of, resistance is the predictable result.

It’s not a character flaw in the resisters. It’s a design flaw in how the change was introduced.

This is why I usually begin engagements by saying: “I’m not here to tell you what to do. I’m here to give you enough context and skills so that you can make better decisions for yourselves.” Autonomy is so important to mental health, to motivation, and to psychological safety that it’s important to be explicit about it.

The people who actually care

There’s a third thing worth noticing. The people who push back hardest are often the people who care most. They have an opinion because they’re engaged. The genuinely dangerous situation in a transformation isn’t resistance with an opinion attached — it’s compliance without understanding. The person who nods along and does nothing is a much bigger long-term problem than the person asking hard questions.

Bob might be the most valuable person in the room. He just needs to be heard first.

What this means if you’re leading change

If you have your own version of Bob and Janet, it’s worth asking: have these people had the ideas explained to them clearly, or have they just been told to accept them? Have they had any genuine say in how things will work, or has the whole thing been handed down?

The people warning you about Bob are probably right that there will be friction. What they may not have considered is that the friction is usually a symptom of how the change was introduced, not an attribute of the person it happened to.

I’ve come to really value these warnings, not because they will actually be the problem that the speaker expects, but rather because these people will probably be my biggest supporters and I want to start talking to them right away.

See also:

• Autonomy
• My people aren’t participating
• Motivation & Self-Determination Theory

Except management chose not to tell the team that the work was cancelled. For the next month, they let the team believe that they were still building something that was going to be shipped and that customers were waiting for.

Of course, when the next work was ready and management told the team that the original work was cancelled, it didn’t take long for them to figure out what had happened. To realize how disrespectfully they’d been treated.

I never found out why management made that decision. The possible explanations include poor planning (waiting until the next work was ready before saying anything), avoidance (not wanting a difficult conversation), or protecting their own position.

The most charitable explanation is also the most interesting one: they may have genuinely believed the team needed to think the work was real in order to stay motivated. That the fiction was doing something useful. That people work harder when they believe customers are waiting.

That belief is worth examining, because it has a real cost that we don’t often consider.

What SDT says about what happened

Self-Determination Theory (SDT) is built on three basic psychological needs: autonomy, competence, and relatedness. The motivation model that I’ve written about before is one of several frameworks that sit on top of those needs, but the needs themselves are the core of the theory. Meet more of these needs and motivation moves toward intrinsic (the strongest motivator). Strip them away and it moves toward amotivation (the weakest). Deception attacks all three.

Autonomy is the need to feel in control of your own behaviors and goals. It doesn’t require complete freedom, although it does mean having genuine choices within whatever constraints exist. The team thought they had autonomy; choosing how to build something real, making daily decisions about the work. Those decisions were all made inside a false frame. The choice was never real.

Competence is the need to feel effective and capable. A month of work that will never ship is a month of effort that meant nothing. When the truth came out, every decision they’d made, every problem they’d solved, every trade-off they’d carefully worked through, none of it counted. That’s not just demoralizing. It directly undermines the team’s sense of competence.

Relatedness is the need to feel connected to others, and to matter to the people you work with. Relationships have a baseline requirement of honesty. What the team discovered wasn’t just that a project got cancelled. It was that management had looked them in the eye every day for a month and lied. That’s a different kind of damage, and it doesn’t recover quickly.

The thing that makes this worse

Management didn’t just lie to the team. They used the lie to fill a gap that could have been genuinely valuable.

A month of self-directed work, choosing what skills to develop, what debt to pay back, what long-standing annoyances to finally fix, is not a consolation prize. For most teams it’s almost never available.

I’ve written before about a team that had exactly that kind of window handed to them, and what they made of it. That window, given honestly, would have been intrinsically motivating in exactly the way SDT describes. High autonomy (you choose the work). High competence (you work on things you already understand and care about). High relatedness (the team collaborates on improvements they all feel the value of).

Management didn’t just fail to support motivation. They took something that would have supported it and replaced it with nothing.

What honesty would have cost

The truth, told early, would have had a price. It might have been an uncomfortable conversation with either the team or with their own management. Probably some uncertainty for the team while they figured out what to work on. Maybe some frustration.

The deception cost the team’s trust in management. It cost their belief that their work was real. It cost a month of motivation that could have gone somewhere useful. And it cost significant goodwill once they’d worked out what had happened.

The instinct to protect people from bad news often comes from a good place. The cost of that protection is almost always underestimated, because managers rarely see the full invoice. The team doesn’t walk into your office and tell you that they no longer believe you. They just become slightly harder to motivate next time. And again the time after that.

The next time

The next time you’re sitting on bad news, the question isn’t how long you can wait before telling your team. It’s what you’re trading away while you do.

If you’d like help with that then let’s talk.

Every time he went on vacation, I would be put in charge, and on the first day, I’d implement every change he’d been sitting on. The team knew what needed doing; we’d been talking about it for months. We just needed the space to do it.

When he came back, he’d look at the new state of things and see they were working. Then he’d leave them in place.

This happened every vacation, without fail. We’d make forward progress a couple of times a year and then be stalled again.

That was my experience as the subordinate. A client described the same dynamic to me recently, from the other side of it. Every team lead wanting to be involved in every decision, every manager reluctant to hand anything off. A different flavour of a fundamentally similar problem.

I have to ask, what this behaviour is actually costing the organization. Not in the abstract. In specific, concrete terms.

When a manager inserts themselves into every decision, they become a bottleneck, with work queuing up behind them. Their team stops developing judgment because there’s no space to exercise it. Over time, the team stops offering options and starts waiting to be told, not because they’re incapable, but because they’ve learned that’s how things work here.

The more decisions we make for people, the more they expect us to keep making decisions.

This is a system that is highly optimized to block improvement.

David Marquet developed the Ladder of Leadership while commanding a nuclear submarine, and it’s the most useful model I know for this problem. At the bottom of the ladder, people wait to be told what to do. At the top, they act autonomously and report back. The leader’s job is to deliberately move people upward, and to stop doing the things that keep them at the bottom.

If you’re a manager who finds yourself involved in everything, you may be keeping your people low on that ladder without realising it. Not through malice. Through habit, and through the understandable belief that it’s faster to do it yourself than to explain it.

Back to the vacation test: if your team moves faster when you’re on vacation, what does that tell you about how you’re showing up when you’re present?

The vacation test isn’t really about whether you can take two weeks off. It’s about what your team discovers about themselves while you’re gone, and whether you let them keep it when you come back.

The team listened politely and then confidently told me that they didn’t need to improve their quality. After all, they wrote perfect code.

They were modest enough to admit that their code wasn’t always perfect on the first pass but that by the time they got through all their review steps, there were no more bugs. None.

I complimented them on that. Not having reported production bugs is indeed impressive.

I said “Can I show you how TDD works anyway? If you feel it doesn’t give you any extra value then you don’t have to use it.” Absolutely, they said, so we spent the next couple of hours walking through their code and test driving some changes.

In those few hours, we found about half a dozen bugs in their existing “perfect” code base. They weren’t things breaking in production, but they were absolutely places where the code was not doing what the developers expected it to do.

The moment they saw the results, they wanted to get better at what I’d shown them. They were immediately motivated to improve, and to learn this new skill.

So let’s consider motivation, and take a look at the Self Determination Theory (SDT) motivation model.

That team had an identity: we are engineers who care about quality. That identity was real and they were proud of it. They’d built quality gates, they thought carefully about their work, they were genuinely working to ship clean code. They just had an incomplete picture of what quality meant in practice.

TDD didn’t create their motivation. It landed on motivation that was already there. Once they could see that the technique served something they already cared about, adoption was obvious.

Compare that to the engagements where TDD training doesn’t stick. Almost always, one of two things is true. Either the engineering culture doesn’t have a real quality identity (ie shipping fast vs shipping quality) or the technique has been mandated as a process requirement rather than offered as a tool.

You cannot comply your way into caring.

Self-Determination Theory describes this as integrated motivation: when a behaviour becomes part of who you are, not just something you do. It’s one of the most durable forms of motivation that exists, surpassed only by intrinsic motivation, where the work is enjoyable in its own right.

The implication for engineering leaders: before you hire someone to teach your team a technique, ask the prior question.

What do your engineers really care about?

If the answer is clear and they have a genuine identity around quality, or craftsmanship, or shipping things that work, then technique training can move fast. You’re connecting a tool to something already present.

If the answer is unclear, or if the honest answer is “they care about getting their tickets to done,” the training problem isn’t the problem. You’re solving at the wrong level.

I’ve been teaching TDD since the late nineties. The engagements where it sticks aren’t the ones where I trained hardest. They’re the ones where I found the right soil.

Within about twenty minutes, I and my co-facilitators were receiving panicked messages from managers who had not been invited to the retrospective. They were telling me to stop the conversation and leave it alone. It turned out that people inside the retrospective had felt so uncomfortable just talking about this subject that they had reached out to their own management to get it shut down.

An interesting point is that by the end of the retrospective, everyone inside the room was calm and feeling good about the outcome of the meeting.

Outside the room however, the panic continued for weeks. Various levels of management pulled me into meetings to discuss what had happened. What could have been a clean two-hour retrospective became a weeks-long organizational disruption, triggered not by anything that happened in the room, only by the alarm signals that had spread outward from it.

So what was actually happening?

Neuroception

Dr. Stephen Porges, a neuroscientist who spent decades studying the nervous system, coined the term neuroception to describe something that happens constantly, below conscious awareness. Your nervous system is continuously scanning the environment for signals of safety or threat, and it makes that assessment before thought, before language, before any conscious decision. By the time you are aware of feeling unsafe, the call has already been made.

This is distinct from perception, which involves conscious awareness. Neuroception happens underneath it. And critically, it doesn’t evaluate logic or intent. It evaluates signals: tone of voice, facial expressions, the predictability of your environment, whether the people around you seem calm or alarmed. A well-reasoned argument arrives too late. The nervous system has already decided.

What this means in organizations

The people in that retrospective weren’t being obstructive. Their nervous systems had detected threat signals before anything particularly alarming had been said. The topic itself, psychological safety, in a department where safety was already uncertain, was enough. They responded to the signal the context was sending, not to the content of the conversation.

When they reached out to their managers, they became threat signals themselves. The managers outside the room had no direct experience of what was happening inside it. Their nervous systems received an alarm and responded accordingly. The panic propagated through the organization, not because the situation was actually dangerous, only because the signals indicated it was.

This pattern shows up constantly in organizational change. A leadership team announces a restructure. They communicate clearly, hold town halls, answer every question, explain the rationale. Yet, the team still can’t focus. Still seems unsettled weeks later. Still isn’t performing the way it was before.

This is not stubbornness, or apathy, or unprofessionalism. It is neuroception having made a threat assessment, and no amount of rational communication reaches the system that made that call.

The implication

For leaders and coaches, this matters because it reframes the problem. If you believe that felt safety is primarily a communication problem, you will keep reaching for communication solutions. Clearer messaging, more transparency, better town halls. And you will keep being puzzled when it isn’t enough.

Neuroception tells us that felt safety is a nervous system problem. The signals the environment sends matter more than the logic it offers. Resistance to change isn’t stubbornness. Disengagement isn’t apathy. Persistent anxiety after a well-handled announcement isn’t irrational. It’s biology doing exactly what it evolved to do, in an environment it wasn’t designed for.

Understanding what’s actually happening is the first step toward addressing it effectively. This is the kind of work I do with teams and organizations. Let’s talk.

See also: Polyvagal Theory

As I was coming back down from Carrot Mountain (picture), it occurred to me that this is an excellent example of tacit vs explicit knowledge.

When we’re first starting to hike on surfaces like this, we’re sliding regularly but it doesn’t take more than a few hours of this before we’re sliding less. Before we get to a point where we know which rocks are stable to put our weight on and which ones will slide.

And yet, even now if you were to ask me where you can step, even though I can point out the rocks that will hold my weight, I often can’t tell you how I know that. It’s not that the rocks necessarily look that different. I just know¹.

This is tacit knowledge. It’s not something I learned from a book, or that someone showed me once, it’s knowledge that I absorbed through doing. In fact, it’s information that cannot effectively be learned without actual practice.

How is this relevant here? A lot of the information that we need in order to do our jobs really effectively is that tacit knowledge. It’s not something that we can learn from a book, or from a lecture. It’s something we have to do. This is why so many trainings are experiential - if you’re not actually doing the skill, you can only learn the explicit portion of it, not the tacit portion, and the tacit portion is usually the more interesting.

When I teach classes, they’re always deeply experiential. If I’m teaching development practices, we’re actually going to write code together. We’re doing to do simulations and exercises because this is how we absorb tacit knowledge. If you want to know how to not slide on the shale then come hiking with me and step where I step.

This is also the value in coaching. Not reading an article and expecting to have gained all the knowledge, but working with a coach as you’re going through the work. Getting corrections in the moment.

There are many things that you can learn from a book or a video (explicit knowledge). There are an equal number of things that you can’t (tacit knowledge), and for those you need to try something different.

I can help with that. Let’s talk.

See also: Tacit knowledge

By the second week, the support team had stopped calling the developers and when we checked in with them, they said everything was going great. So we rolled out to the entire user base of 10,000 people.

Fast forward a couple of days, to discover that there were lots of problems, and had been problems all the way through the support period. The gotcha is that the support team had found workarounds so they had stopped reporting those problems. Once they’d figured out a workaround, they just walked users through that, rather than reporting it. Problem solved, or so they thought.

Until they were now supporting 10,000 people who all needed that workaround at the same time. All of a sudden the support team didn’t have enough capacity anymore, and it was a full panic. All hands on deck, and development in full fire fighting mode.

Where do we even start to unpack this?

Did we have quality issues? Obviously, yes. The fact that so many significant bugs had even been found, shows that there were quality problems.

Did we have a problem with support stopping with a workaround and not digging deeper to find the underlying problem? Again, yes. While this could have been a conscious choice (Satisficing Decision), it was most likely a cognitive bias (Einstellung Effect) that led them to stop looking for a better solution.

Did we have communication problems between development and support? Yes. The fact that development wasn’t even aware that things were breaking, was a significant problem.

Did we have problems with management not seeing the whole picture? Again yes. Despite the focus on wanting this to go smoothly, they didn’t have any of the overall picture. Each group was continuing to work in their own silo, and optimizing for their own behaviour. Looking at the bigger picture is a management responsibility, and they had abdicated that to the individual teams, telling them to figure it out on their own. Teams that were not in the habit of working together, and had never built up the skills or processes that would have made this effective.

When we see a significant failure, it’s rarely because one thing went wrong. We can usually correct for one mistake being made. The significant failures are due to a cascade of failures, as in this case.

It wasn’t just that there were bugs. It wasn’t just that support stopped reporting problems when they had a workaround. It wasn’t just that groups weren’t talking to each other. It wasn’t just that management had taken their eyes off the ball.

All of these things had happened at once, and it was a disaster. Had only one thing happened, we likely would have compensated for it. The fact that they all happened at once made that impossible.

What made this a cascade rather than a recoverable problem was that each failure cut a feedback loop. Bugs had been reaching us through support calls, but once the workarounds were in place, we stopped hearing about them. We relied on support to escalate problems to development, but support had stopped calling. We expected management to track rollout health through what development reported, but we had nothing to report. Each failure silenced the signal we would have needed to catch the next one.

Each team was solving their own problem: support kept users moving, development fixed what they heard about, management tracked what development told them. Nobody was watching the whole system. Checking in with each team and hearing that everything is fine is not the same as understanding the health of the rollout. Silence is not a signal of success. Ask instead whether the feedback loops are still intact.

How could we have identified the individual problems before we had a cascading failure?

For people internal to the system, that’s the main point of retrospectives. Reflecting deeply into what’s going on and surfacing problems before they fail. If we’re only having superficial conversations then we won’t uncover these things, but if we’re having the right retrospectives, we will. See my course Retrospective Magic for more on improving your retrospectives.

The other option is to bring in someone from outside the system, as it’s often easier for an outsider to see things that the insiders have learned to ignore. That’s not a criticism of the insiders, but rather an acknowledgement of the way human brains work. The more we ignore a thing, the less chance of that thing even being brought into conscious awareness - we literally stop seeing it. Refer to the reticular activating system in this article on poor code

If you’d like help with either of those then let’s talk.

See also:

• Cognitive Bias
• Rapid feedback
• Optimizing for our own effectiveness

The first was a video, that I didn’t save and can’t find again, talking about call centres and how automating away all the simple calls, meant that the call centre staff no longer had any real downtime. Instead of getting a mix of easy calls and difficult calls, now they get nothing but difficult calls with no gaps between them and this makes the work significantly harder. They used to get a bit of a mental break when handling the easy calls and now that’s gone.

The second was this article by André Meyer, showing the same idea but expressed in different terms. [This is his diagram, not mine]

Yes, AI is allowing us to move much faster through the easy work but is at the same time taking away those opportunities for our brains to pause for a moment. Now the work is much more demanding, all the time, and if we don’t force ourselves to stop periodically, this will ultimately lead to burnout.

Update 2026-05-03: Another article on LinkedIn by Jürgen De Smet, framing trunk based development as a cognitive load practice, rather than an engineering practice.

When I teach refactoring, one of the exercises I use is a kata for scoring a tennis game. I give the attendees some working code with reasonably good tests and the instructions to refactor the code to make it better. I tell them up front that the goal is improving the code, not just moving things around, and that I’ll be asking them during the debrief how they made that code better.

Even though the code isn’t very large, there are enough problems with it that you could spend multiple hours cleaning it up.

This particular kata illustrates so many teaching points but there’s one in particular that I want to talk about today.

I’ll split the group into pairs and have them work on the code-base with their pair. Inevitably at least one pair, and sometimes the whole group, will stop about ten minutes in and say “there’s nothing else to fix so we’re done”.

They made a couple of superficial changes and declared that everything left was great. Why is this?

It would be easy to say that these people are lazy or unmotivated and yet that’s rarely true. The real problem is that just don’t see what was right in front of them.

Our brains receive billions of bits of information every second, and our conscious minds are able to understand almost none of that. Research shows that an average person can hold 5-9 (often described as 7±2) chunks of information in our working memory at any time. Only the tiniest bit of that information that we receive every second actually makes it to our conscious awareness.

The part of our brain that decides which bits are important enough to bring to conscious awareness is called the Reticular Activating System (RAS) and it has some fairly simple rules that it follows, that revolve around survival, personal relevance and beliefs, your goals and intentions, and various emotional cues.

The key bit here is that the RAS re-tunes itself constantly based on what you tell it is important.

Have you ever found yourself looking for a new car and when you select one, now you start seeing cars like that one everywhere you go? That is your RAS tuning itself for that particular make of car. Those cars were always present but you didn’t see them until the RAS decided that they were important.

How is this relevant to the original point of people not seeing poor quality code? It’s because the people who aren’t seeing the problems in the code, have never trained their RAS to look for problems in the code, and so they honestly don’t see them. “The code all looks great to me”.

This is why we continue to propagate poor code - because we can’t fix what we can’t see.

As a quick aside, you may be thinking that AI tooling will solve this because it will write better code. AI is a fantastic amplifier - if you’re already writing great code, it will help you write lots more of that. But if you’re writing lots of poor quality code, it’s going to help you do that really fast too. And you won’t be able to correct the AI if you can’t see the problems with the code that it’s generating.

So how do we train our RAS to identify that poor code? The real answer is repetition. We need to spend time looking for problems in the code. Perhaps we’re doing katas to actually improve that code or perhaps we’re doing things like Code Smell Bingo where we make a game out of identifying problems. We need to train our brains to recognize problems so that our RAS starts to help us rather than hiding the problems. Doing that requires repetition.

Can we train our RAS without doing katas? Certainly, we could focus on that through more disciplined code review. That’s just going to take a lot longer, particularly if we’re doing individual and asynchronous pull request reviews, rather than actually talking through the code as a group. Then in the meantime, we’re continuing to add poor quality code to the system.

Want to help your teams improve their ability to find and fix problems in the code? Let’s talk. I’ve been doing this for decades now.

See also: This article on how we often don’t see blockers which can be caused by exactly the same problem.

There is one big exception to this approach however, and it just came up in a conversation.

That’s when we’re trying to fix a morale problem. Many companies will start by trying to visualize “team happiness” with something like a Niko-Niko calendar, and this can backfire spectacularly.

First, the companies that try to track happiness/morale, already know they have a problem or they wouldn’t have asked for this. Second, when the results come in and show that teams are not happy, management rarely does anything positive to address that. Why do I say that? Because the companies that already have a good plan to address morale/happiness, don’t start by asking people to quantify how they feel.

So now we’ve made it really visible that there’s a morale problem, and that we’re not willing to do anything about it, so morale drops even further, which gets even lower scores, which we again do nothing about.. and it spirals downwards.

So now when I hear a company say they want to start tracking happiness, I ask them what specific actions they’ll take when the results show that the teams are not happy. If they don’t have a solid plan already, I advise them not to track it at all. If you’re not prepared to fix it, don’t make it visible. That’s just going to make it worse.