Let that developer talk to the people using the software and all of a sudden they’re getting feedback. They start to understand why the feature is being built. They start to understand what problems the customer is trying to solve, and they start to empathize with that person.

I’ve been giving that advice for years, based purely on my own observations. Teams that regularly interact with their customers are more motivated and deliver better solutions than those who don’t.

The Agile Manifesto even has a line about this: “Business people and developers must work together daily throughout the project.”

So I wondered if there was any research that backed up my observations and there is, although it’s not specific to software development.

Adam Grant and his colleagues ran an experiment in a university call centre.¹ The callers phoned alumni asking for donations, and a good chunk of that money paid for undergraduate scholarships. None of the callers had ever met one of those students.

Thirty-nine callers, split three ways. One group was called into a break room for ten minutes and met a scholarship student. They asked him about his classes, how he’d earned the scholarship, what he planned to do after he graduated. Five minutes of conversation, at most.

The second group sat in the same room, for the same ten minutes, with the same manager. They read a letter from that same student about what the scholarship had meant to him and discussed it amongst themselves. They just never met him.

The third group carried on as usual.

A month later they measured everyone again.

“The intervention group increased significantly in persistence (142% more phone time) and job performance (171% more money raised); the control groups did not.”
Adam Grant et al., “Impact and the art of motivation maintenance”¹

Phone time in that first group went from 108 minutes a week to 261. Weekly donations went from $186 to $503. Neither control group moved at all.

The letter group is what convinced me. Same manager, same attention, same room, same information about who benefits from their work. The only difference was whether a human being walked through the door. Reading about the customer did nothing.

So I went looking for the catch, because that result is almost too good.

There is one, and it’s in the third experiment of the same paper. This time they varied two things independently: whether people had contact with the person they were helping, and whether the work visibly mattered to that person. Contact on its own did nothing. Three of the four groups all landed between 25 and 27 minutes of effort. The only group that moved was the one that had both, and it landed at 30.

Contact alone isn’t enough. Contact is how we find out whether the work matters, and allows us to understand that we’re doing this for a person.

Grant found something similar a year later with lifeguards at a community recreation centre, a different group of people doing a completely different job.² One group read four stories about lifeguards performing rescues. The other read four stories about the skills and career benefits other lifeguards had gained from the job.

The first group went from signing up for 7 voluntary hours a week to 10, and their supervisors rated them as more helpful than before. The second group dropped to 6 hours, and their supervisors rated them as less helpful.

Telling people the job is good for their career made them worse at it.

So what does this mean for a team? Not that we should schedule a customer visit and tick the box. The demo where a stakeholder nods politely at a screen share isn’t the mechanism, and neither is a persona on the wall or a carefully worded user story. Those are weak proxies for the real thing, which is a person, in the room, whose day is measurably different because of what we do all day. Take away either half and the effect disappears.

A quick disclaimer: I didn’t find research directly for software teams. The evidence is call centres, swimming pools and hospitals. The closest thing we have in our own field is a review of 92 studies of what motivates software engineers, where the most frequently cited motivator was identifying with the task: knowing its purpose and how it fits into the whole.³ That’s a related finding, but not quite the same.

Back to the point we started with, the closer the developers are to the customers, the better the results, and the more motivated we all are.

I run across teams who really seem to understand agile. They’ve read the books. They can tell you exactly why we work in small batches. They’ll argue about it over a drink.

Then I sit in on their daily scrum and watch them follow the old three questions while other team members disengage. I watch them follow the Connextra story format (“As a [role], I want to [action] so that [reason]”) without questioning whether it’s made the description useful or not. I listen to people say no blockers when clearly they have blockers, and they can’t hear the disconnect in their own words.

These behaviours that I’m seeing are often referred to as cargo culting¹, where we follow the form without thinking about whether we get any value out of it.

This is where we come to my incorrect mental model. I assumed that this was largely a motivation problem. I thought that the more motivated we were (further right on the diagram), the more we would care about being effective, rather than just following the routine.

Then I found some research that proved me wrong.

Tanja Elina Havstorm spent three years embedded with three software teams at a manufacturing company in Sweden, watching how they actually used their agile practices.² She catalogued 36 deviations across the daily scrum, the sprint demo, continuous integration, and visualization.

She classifies every action she saw three ways: what kind of action it was, whether the reasoning behind it succeeded, and what motivated it. That gives us eight patterns, five of which are cargo culting.

Compare the last two columns. Motivation doesn’t line up with cargo culting at all; internalized motivation appears twice in the healthy patterns and twice in the broken ones. Reasoning lines up perfectly.

The autonomous end of the scale, the end I expected to protect us, appears in both groups. It’s in the healthy patterns, where teams have taken the values on board and act accordingly. It’s also in the broken ones. She calls one of those deficient.

“The SDM goals are not perceived as a controlling factor. Instead, they have been fully assimilated by the software developers, i.e., internalized regulated.” Tanja Elina Havstorm, “Cargo Cult in Agile Software Development”²

Those are the behaviours I described at the top. Nobody was reciting the three questions because a manager was watching. They’d taken the goals on board, and the standup was still broken.

External motivation tells us just as little, and it appears in both groups too. A team that was told by management to run a practice can run it perfectly well, without thinking through whether it makes sense.

Being motivated doesn’t mean we’re doing it properly.

There is one place where my instinct held up. The far left of the model is bad every time. Both of the amotivated patterns are cargo culting, and there’s no healthy version of either. Those are the teams running on old habits, or on whatever the industry is excited about this year. In one of her examples, the manager roles survived the transition intact and were simply renamed as Scrum Masters.

Her early framework had intrinsic motivation in it and she had to take it out, because across three years of watching real teams she couldn’t find any. The far right of the model was empty.

Her own definition of the phenomenon uses the word unconsciously.³ Nobody in these teams knew they were doing it, and that isn’t a criticism of them. A team that was aware of the problems would probably have fixed them already.

My mental model around this was completely wrong and it wasn’t until I stumbled across this research that I even thought to question it. How many other mental models that we regularly count on are also wrong?

There are five main groupings in the Kano model, although we often only talk about the first three, which are: Basic needs, performance needs, and delighters.

Basic needs are things that your product must have and yet counter-intuitively, your customers just don’t care about. Imagine selling a mobile phone and claiming “ours has a battery in it!” Nobody cares that it has a battery in it because all mobile phones have batteries in them. Yet, if you shipped one without a battery everyone would be very upset. The customer doesn’t care if the basic needs are there but cares very much when they’re absent, and that’s the key characteristic.

Performance needs are those where more of a thing makes the customers happier and less makes them less happy. Battery life would be a good example. Longer battery life on that mobile phone will make customers happier.

Delighters are where Apple traditionally shines. These are things that no customer asked for. Had you suggested this feature to a customer they might even have shown indifference. “I don’t need that”, and yet once they start using that feature, they can’t live without it. This becomes the differentiator that draws people to the product.

With these first three, there is an interesting behaviour that over time, they shift down and to the right as seen by the large arrow below.

Things that started as delighters become the things that every vendor has to provide. Things that used to make the customers happy, now become basic needs where the customer only notices when it’s absent.

The fourth grouping is Indifferent Quality which is right along the X axis. This is where the customer just doesn’t care whether it’s there or not. Things that the customers are indifferent to, shouldn’t be built, and yet we build lots of these.

If it’s already built, we should be seriously questioning whether we can remove it.

Then the last grouping is Reverse Quality where the customer actively dislikes this. Usually these are features that we put in to justify getting more money out of the customer. We think we can charge more if we add more features, missing the point that this often degrades the whole experience for the customers. As we add more, we generally make it more difficult to use the features that the customers care about.

Adding these features contributes to the “enshittification“ that is widely discussed across products. Just as with indifferent quality, if we’ve already built it, we should be thinking about removing it.

Most feature conversations proceed as though everything on the list is a delighter waiting to happen. The Kano model says otherwise. Some things just need to be there even though the customer doesn’t care. Some truly do add value and some are just waste.

That’s the useful part. It gives you a way to say no to work that would otherwise look like progress. We don’t say “no” nearly often enough, but that’s a different article.

So next time something lands in the backlog, ask which of the five it is. If nobody can say, you’ve learned something already. That tells us we don’t know enough about what our customers actually need.

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.

Why a visualization at all? Because about half of the cerebral cortex is involved in visual processing and that means we’re much better at parsing visual data than raw tables.

I had a situation recently with a client where we were looking at cycletime data in a scatterplot. The data was correct, and yet it was almost impossible to read. A handful of extreme outliers pushed everything useful down into a thin strip along the bottom of the chart. The team’s questions were around patterns in the data but because everything was compressed into the bottom strip, all we could see were the outliers and not the data we actually cared about. A chart that’s accurate and can’t inform a decision still isn’t doing its job.

Note: these charts use fabricated data to illustrate the point. They are not client data.

The first question with any outlier is whether it’s noise or signal. Sometimes the outlier is the most important thing on the chart, the one item that’s been stuck for months and tells you something is badly wrong. Here it was noise. We already knew those few items were slow. What we’d lost was the ability to see everything else. So the goal was never to delete the outliers, it was to stop them from drowning out the pattern.

The obvious move would be to remove the outliers, and that would skew the percentile calculations. The next option would be to force the maximum Y axis lower, which makes the rest of the chart readable while hiding the outliers completely. That solves one problem by creating another.

What we really want is for all the data to be present while emphasizing the parts that are immediately relevant.

Here’s what we ended up with.

We capped the Y axis so the bulk of the data gets the focus, and moved the outliers into a labelled band along the top, each one still marked as an arrow with its real value one hover away. Nothing is dropped and nothing is hidden. Just as important, this changes only what you see. The percentiles and every other calculation still use the real numbers. We improved how the data is displayed without impacting the information in that data.

With the pattern visible again, the team could answer their questions, and they could made better decisions. That’s the whole point of a visualization.

Since this seemed generally useful, this feature is now available in JiraMetrics v3.2.

See also: Survivor Bias, the cost of dropping the data that doesn’t fit the picture.

Effectiveness and efficiency are not opposite ends of anything. They are separate variables that move independently. You can be highly efficient and completely ineffective, burning through work at low cost while delivering nothing the customer wanted. Or you can be both effective and efficient at the same time. The two are related, but not linked.

Then there’s a third variable that gets missed, and it matters just as much: predictability.

The Kanban Guide describes value optimization as finding the right balance of these three attributes: effectiveness, efficiency, and predictability so let’s define them.

Effectiveness is how good we are at getting the customer what they need when they need it. It’s about value.

Efficiency is how good we are at making use of the economic resources at our disposal. This could be staffing costs or equipment, or any of the things that we’re spending our money on. This is all about budgets and costs.

Predictability is how reliably we can say what we’ll deliver and when, then have that turn out to be true. It’s about the confidence others can place in our word.

Any change we make to the workflow is a trade-off across all three. Optimize hard for one and you can quietly damage the others. Squeeze efficiency by loading everyone to capacity and your predictability collapses, because a system running at 100% has no slack to absorb variation. Chase predictability with heavy buffers and padding and your efficiency suffers. Fixate on either and you can lose sight of effectiveness entirely, running a cheap, predictable process that ships the wrong thing.

So do we need all three? Yes. Do we need them equally at every moment? No. A startup searching for product-market fit should lean hard into effectiveness and worry about efficiency later. A mature operation running a known process might rightly prize predictability. The balance shifts with context, and the skill is knowing which one to favour right now without pretending the other two stopped mattering.

An interesting side-note is that many companies will say that they know how they want that balance to look, while optimizing their behaviour in a different way. A classic example in larger companies is the claim that they want to cut costs (efficiency), while heavily over-optimizing for predictability. The reality for them is that absolute cost is irrelevant so long as they can accurately predict what that cost will be. What they want is certainty.

What makes this more difficult is that we’re tuning a complex adaptive system, and it never holds still. The conditions that made today’s balance right will have moved by next quarter. There is no perfect setting that stays perfect; the moment you find it, the system has already shifted underneath you. This is ongoing work, not a problem you solve once.

It’s a mistake to treat any of these three as a single number to optimize in isolation. In a system that never stops moving, have have to watch patterns, not data points, and then we keep adjusting the balance.

There’s one wrinkle worth its own article. There are two different kinds of efficiency, and many places optimize for the wrong one. I dig into that in Keeping people busy.

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.

Have you ever gotten up in the morning and thought “Oh boy, I get to log-in today. It’s going to be great!” Of course, you haven’t. No user ever wants to log-in, so writing the story as “User wants to log-in” completely misses the point.

So why would we even build a log-in feature if nobody wants to do it? Because other stakeholders of the product do care about that. The key here isn’t that log-in is a bad feature, it’s that we’ve completely misunderstood who wants it and why.

When we write a user story, we should write it from the perspective of the person who cares most about it. The quickest way to find that person is to ask who would be upset if we didn’t build it, and why. In this case it isn’t the person logging in. In fact, they may actively not want this.

Write a story from the perspective of whoever cares most about it: the person who’d be upset if you didn’t build it.

Let’s improve the original story: “Corporate risk wants people to log-in before they have access to any confidential information”. Now we’ve identified who really cares and this is becoming a reasonable story. We haven’t necessarily identified that log-in is the right answer to the problem, but we’ve at least correctly identified who wants it.

Someone always brings up “but I do want to log-in so that my information is safe”, which conflates the logging in with the thing they actually do want: safety. You could certainly write a story from their perspective which focused on the safety. “User wants to know that nobody else can access their documents without permission” and that would be an improvement, although it’s still not directly linking the log-in to the safety. Does that person want to log-in or do they want to know their information is safe?

One caveat on my own wording: I’ve said “user” throughout, and that word is normally far too generic to be useful in a story. Log-in is one of the rare cases where it really does apply to everyone, so I’ll give it a pass this time.

Getting the who right is only one piece of what makes a good story; it’s part of a bigger idea I’ve written about before, that a story has to be valuable to someone who isn’t us. It’s something I often see done poorly though. The user is frequently an afterthought, when it’s critical context that helps us understand what problem we’re trying to solve. If we don’t know who we’re building it for, we’re almost certainly building the wrong thing.

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?

The post in question was posted on Friday. For most of that first day it did what my posts usually do, which is a handful of readers an hour, largely driven by social media posts from LinkedIn or Mastodon. Then at 11:00pm, it suddenly became popular. In the space of a single hour the traffic went from seven visitors to a hundred, and then to 2,000.

The traffic doesn’t really ramp up slowly, it’s more like a light switch. One hour you are unknown, the next you are on the front page of Hacker News and the internet is pouring through your door.

It held there for six hours. From midnight to six in the morning the site took between 1,700 and 2,400 visitors an hour.

I wasn’t even aware that any of this was happening until a friend pinged me on Saturday to say I was on the front page of Hacker News.

Then it decayed, cleanly, halving roughly every five or six hours through the day. By evening it was a trickle. By the next morning there was still a bit of incoming traffic from Hacker News, but it was effectively over.

Who were these people? Almost none of them were my target market. Twenty thousand of them had never visited before. They came from 139 different countries, and 99% of them read the one thing they came for and left, most inside a minute. I know what countries they were in, but not how most of them got here: 70% of the visits carried no usable referral source at all, stripped away by mobile apps and privacy settings.

The good news is that my site didn’t fall over. I’ve deliberately kept the site very simple with static pages being served out of an S3 bucket and behind a CloudFront CDN, and this was able to handle the load without significant problems.

The one place it did struggle a bit was somewhere I had been lazy. The post used a single image that I hadn’t optimized for size and that was still about a megabyte. On an ordinary day, serving that to a few dozen people costs effectively nothing. Serving it 22,000 times is another matter. So optimizing my image assets is now on my TODO list.

So what’s the end result? 22,000 visitors, and not one of them booked a call or signed up for anything. A small handful clicked through to a second linked post. The rest evaporated.

Which just goes to reinforce the point that visitor count isn’t the metric we care about. If nobody engages then it doesn’t matter how many people saw it.

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.

They think the meeting is the improvement. It isn’t. The meeting is where you decide what to change. The improvement doesn’t happen until you actually change it.

Most teams I meet are running retrospectives because they’re on the calendar, and nobody questions what’s on the calendar.

They brainstorm, group the stickies, vote, write down the actions, close. Then next time, the actions from last time are still sitting there undone, so they brainstorm the same problems again. No wonder they get frustrated, all we’re doing is rehashing the past.

A couple of times I’ve walked into a retrospective where the team hadn’t done any of the actions from the last one. I asked whether those actions still mattered, and when they said yes, I stopped the meeting. “Then go do them now; this meeting is over.”

The room then goes quiet, and people look at each other, waiting for the catch. Nobody ends a meeting halfway through. You run out the time whether or not there’s anything left to do. So sending everyone back to their desks with time on the clock breaks a rule they didn’t know they were following. Go do the thing you already agreed to do, because the retrospective was never the point. The change was, and the change isn’t done yet.

The retrospective is one of the most important meetings your team has. Run it without improving, and you’ve wasted everyone’s time.

If you want to run retrospectives that actually change things, that’s what my course Retrospective Magic is about.

Every once in a while, though, I come across a team that’s added a second one. They have a Done, and next to it a Done-Done. The story is always the same: Done stopped meaning done. Work would land in that column and then come back, so the team needed a new column to hold the work that was really, actually finished this time.

That extra column is the feedback we should be looking for. Language doesn’t rot on its own; it rots because we aren’t willing to have the hard conversation about what the word means.

Underneath this particular word, the conversation we’re avoiding is almost always about silos. Someone finishes their part and moves the ticket to Done, because from where they sit, it is done. Their part is done, but the overall work isn’t. It’s done when everyone has done their part. Developer-done isn’t done. Tested-done isn’t done. Each group has its own private definition, anchored to the edge of its own silo.

So instead of getting in a room and agreeing on one shared definition that spans all of those silos, the team bolts on another column. The columns are the silos. Done is where development hands off. Done-Done is where the next group hands off. Every qualifier we add is a handoff we didn’t want to talk about.

Once you see this, you see it everywhere a qualifier starts multiplying. Done-done. Final-final. The real deadline, as opposed to the one we told everyone. A word that needs reinforcing is a word people have stopped trusting, and a multiplying qualifier is a conversation nobody wanted to have.

I had a client once that had a Done, a Done-Done, and a Done-Done-Done. And even Done-Done-Done didn’t mean it was in production. It’s time to stop doing that.

Let’s start with the obvious case. A WIP limit is part of a policy that the team agreed to. The policy says what the team will do, and here it says the WIP in a column will not exceed a certain value. So if the WIP goes over that value, then yes, that’s bad. We agreed to a policy and then didn’t follow it. Simple.

Except that original question was asked in the context of working in Jira, and that shifts the focus.

What Jira actually measures

Jira only supports column-based WIP limits. That means what Jira enforces might not capture the subtleties of what your policy actually says.

Imagine your policy reads: the WIP limit for this column is 5, unless an item in the column is expedited, in which case the limit rises to 6. That’s a perfectly reasonable policy, and Jira can’t express it. All Jira knows is the number 5. So the moment that expedited sixth item appears, Jira flags you as over the limit, even though you’re following your policy exactly.

In a case like that, the fact that Jira thinks you’re over doesn’t mean you violated anything.

So is breaching WIP bad?

It depends on what the breach actually represents.

If your WIP measurement accurately reflects the policy you agreed to, then yes, breaching it is bad. You said you’d work one way and then you didn’t.

If your WIP measurement is wrong because your tooling can’t express the policy, then the breach is an artifact of the tool, not a failure of the team.

The lesson isn’t that WIP limits don’t matter. It’s that the number on the board and the policy in your head aren’t always the same thing. Before you treat a breach as a problem, check which one you’re actually looking at.

If you’d like help making better decisions from your team’s metrics then let’s talk. I’m available to help.

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.

The senior couldn’t stop talking about how much he had learned from the junior, in that short time working together. He stressed that together they came up with a much better solution than either one of them could have done on their own.

While this is extreme example, this kind of result when we truly collaborate is typical. Together we come up with much better results than when we work independently, no matter the skill levels of the people involved.

So why don’t we collaborate more? I think there are several reasons.

1. Most people have never experienced real collaboration and they’re convinced that what they already know is as good as it gets. It’s not.

What most teams call collaboration is actually coordination. You divide the work up, each person goes off and does their piece, and then you review each other’s output. That’s not collaboration. Collaboration is working on the same problem together, at the same time, building on each other’s thinking in real time. It’s uncomfortable at first, especially if you’ve spent your career with your own task list and your own sense of ownership. But what I’ve seen again and again is that the discomfort fades quickly once people experience what’s actually possible.

2. We’ve been trained from childhood that individual accomplishment is the only valid way. All the way through school, it’s called cheating when you share your answers with others. And having been trained that way, it now feels uncomfortable to actually collaborate.

We spend 12 to 20 years having that framing reinforced, and by the time we enter the workforce it’s deeply embedded. Most corporate performance management systems reinforce it further: your review is about your contributions, not your team’s contributions. Even when the work itself calls for collaboration, the incentive structure is still measuring individuals. That tension doesn’t disappear just because you’ve decided to work together.

3. There is a shared psychological bias that believes that two people working together will take twice as long to get the work done as those same two people working independently. This is despite decades of research on pair programming that shows the opposite. The bottleneck has never been typing speed, it’s always been thinking speed and we think better when we collaborate.

The math seems obvious: two developers, one task, surely you’re cutting your throughput in half. But it’s wrong, because it ignores where the actual time goes. Laurie Williams’ research at the University of Utah in the late 1990s and the studies that followed consistently showed that pairs take roughly 15% longer to produce code, but that code has significantly fewer defects and requires less rework. When you factor in the bugs you don’t ship and the rearchitecting you don’t have to do six months from now, the economics look very different. The cost you’re seeing is real. The savings are invisible because they’re in futures that never happened.

So here’s my challenge to you: before you decide collaboration isn’t worth it, actually try it. Not someday. This week. Pick one piece of work and do it together: same screen, same problem, both people present and contributing. Not dividing it up, not reviewing each other’s output. Actually working on it simultaneously.

Then pay attention to what happens. Notice what comes up that wouldn’t have come up if you’d been working alone. Notice where the other person catches something you missed, or takes the idea somewhere you wouldn’t have gone. The experience itself is the evidence.

If you’re not sure how to get started with real collaboration, or you’ve tried it and it hasn’t clicked, let’s talk.

See also:

• Pairing
• Ensemble/Mob programming