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

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.

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.

I’m sure you’re thinking “but I can be angry or sad for hours or sometimes days at a time”, and what’s happening in those cases is that you’re continually retriggering those same emotions over and over again. It’s not the same chemical release over a long time, it’s a continual retriggering of those chemical releases.

What does that mean for practical purposes? It means that if we can interrupt the patterns that we’re following, we’ve got at most another 90 seconds to put up with those negative emotions before we start to feel better.

Why do I only mention negative emotions? Because I’m assuming that you have no interest in interrupting happy emotions. Let’s let the happy ones continue to run.

What could that interrupt look like? It could be as simple as the phone ringing and grabbing your attention. It could be movement to shift your state, particularly movement into a different environment such as walking outside. Just standing up and shaking your body can be a powerful interrupt.

For even more powerful interrupts, almost any of the techniques that I show in the Anxiety Reset will help here. I teach them in the context of anxiety but they’re powerful interruptions and will work in other situations too.

When you’re feeling those negative emotions for long periods of time, you’re just running habitual patterns in your brain, and those patterns can be interrupted.

What’s even better is that the more often we interrupt those patterns, the less we’ll run them. This is just another aspect of Hebb’s law: “Neurons that fire together wire together”. The more we run the same patterns, the stronger they’ll become. The more we interrupt them, the weaker they become.

A related trick is to label emotions when we notice them. The simple act of saying to ourselves “I am feeling angry” or “I am feeling sad” will weaken that effect on us. This technique is called “affect labeling” and is surprisingly effective.

“Behavioral and neuroimaging studies suggest that merely putting feelings into words can serve as a regulatory strategy”
— Levy-Gigi, E., & Shamay-Tsoory, S. (2022). Affect labeling: The role of timing and intensity. PloS one, 17(12), e0279303.

The key point here is that if we’re regularly feeling emotions that we don’t want to feel, there are ways to lessen that, and many of them are quite simple to do.

Standard disclaimer: There are no approaches that work for all of the people, all of the time. If what you’re trying isn’t working for you, perhaps you should seek out a professional to find approaches that will work in your context.

However, for the second tasting, the jams were switched and the subjects were trying the jam that they had rejected, not the one they had picked. Two thirds of the participants didn’t even notice that the jams were switched and happily justified why they had selected this new jam. This happened even when the flavours were as different as apple-cinnamon and grapefruit!

I’ve talked before about how “why” questions can be problematic and this is a perfect example. In this case, the people were doubling down on an answer that was completely wrong. This was not the jam they’d picked the first time, and yet they were completely convinced that it was, and were happy to provide justification for what they considered to be good decision making.

This particular effect is called choice blindness, and is defined as a cognitive bias where people fail to notice that the outcome of a decision differs from their original intention, often fabricating justifications for the manipulated result.

But it doesn’t stop there; the experiment had one more twist. When this was all done, they were given a questionnaire asking about their own decision making process.

“Among other questionnaire items, the subjects had to say exactly how they thought they would feel if they had participated in an experiment that tricked them in this precise way. Of course approximately 90% of the subjects said they would never fall for such a trick.”

Not only are we easily tricked, we’re highly confident that we can’t be tricked, and that blinds us to our own weaknesses.

If we want to make better decisions, we need to be very deliberate about that. It’s too easy to convince ourselves that we’re already great, and then to not notice when the decisions we made are actually quite poor.

An interesting thing with humans is that the first problem we bring up is rarely the real problem. For the browser to have timed out, that means the user had probably already been waiting for five minutes. No wonder they were unhappy.

The fix in that case was to replace 4000 lines of Java code with a page and a half of SQL, taking the execution time from 5+ minutes to roughly a tenth of a second. While the technical details were interesting, for this post I want to focus on the framing of the problem.

They approached me with a problem that wasn’t the real problem. Had I just taken that at face value, we would have found some browser setting to make the timeout longer, and while that would have solved the immediate problem, it wouldn’t have made the users any happier.

Why do we do this? Why do we focus on the wrong problems?

There are a couple of reasons. One is what Daniel Kahneman called System 1 and System 2. Our brains have evolved to optimize for energy consumption and System 1 is very fast and uses very little energy. System 2, on the other hand, is much slower, uses much more energy, and is therefore less desirable. Wherever possible, our brains prefer to use System 1 to make decisions.

Unfortunately while it’s fast, System 1 is often wrong. The example above is a perfect example of System 1 thinking: “Let’s just extend the browser timeout”.

What I did in this case was to ask the kinds of questions that force us into System 2. “How could we shorten the entire time so that we don’t need to change the timeout?” Or “what’s the bigger problem we’re trying to solve?”

Questions that can be answered with yes/no, and questions starting with “why” will tend to keep us in System 1 so we want to avoid them. We want open ended questions and those often start with “how” or “what”.

The key to remember is that the first problem is rarely the real problem. Ask some questions. Dig a bit deeper. Force us both to use System 2, so that together we can find a better answer.

⮕ More on Systems 1 and 2

Another related reason for focusing on the wrong problem is called Attribute Substitution. It’s when we’re faced with a computationally difficult problem, and our brains unconsciously replace that problem with a computationally simpler problem and we solve for that instead. We’re usually not even aware that we’ve done this because it’s happened entirely at an unconscious level (System 1).

The good news is that the same questions that will switch us to System 2, will also help us identify that we’ve been tricked by Attribute Substitution, and will allow us to refocus on the real problem.

⮕ More on Attribute Substitution

In this particular case, we ended up with a solution that made everyone happy. That only happened because we were able to step back and see the problem through the lens of System 2.

The interesting point, at least for this article, is how people developed one or the other of these mindsets.

They found that children praised on their intelligence (ie “you’re so smart”) developed a Fixed Mindset. They did more poorly on future tasks, gave up more easily and when given a choice of working on easy or hard problems, picked the easy ones.

Children praised on the effort they put in (ie “you really worked hard on that one”) developed a Growth Mindset. They were more successful, persevered more with challenging tasks and when given a choice of easy or hard problems, picked the harder ones.

As you’ve probably already deduced, people with a growth mindset significantly outperform people with a fixed mindset.

I was reminded of this when my friend Stacey made this observation on LinkedIn: I think I’ve gone from Sonnet telling me “you’re absolutely right” all the time to Opus telling me my ideas are “smart.”

Notice that in both cases, the AI is praising how smart she is, not how much effort was put in. This will directly encourage a fixed mindset in those who hear this messaging on a regular basis.

I would expect it to be fairly easy to tell these tools to not praise us in that way. The fact that this is the default behaviour is certainly troubling though.

The language we use is critically important, and affects us far more than we think.

It wasn’t a large book, and I quickly read through all of it. Yet, while I now “knew” how to do it, I still couldn’t juggle.

I tried the things I’d read in the book and immediately dropped the balls. I picked them up again and this time I managed a few passes before dropping the ball. Over and over and over again, I picked up the balls and tried again. The more I practiced, the more the knowledge of juggling started to make sense. It became what we often call “muscle memory” but is really just unconscious programming. Through this constant practice, I was able to absorb the knowledge of juggling.

This is the essence of Tacit Knowledge; things that have to be experienced, rather than just read.

If I could have absorbed the lessons just from reading the book then this would have been Explicit Knowledge, but juggling isn’t that.

Why is important to distinguish between these? Because it takes very different approaches to learn tacit knowledge than it does explicit. All too often we think that any problem can be addressed by just watching a video or reading an article, and that’s not true. Some things need to be experienced to be understood.

Almost everything that gets written about here is explicit knowledge. While I can certainly write an article to tell you about the mechanics of juggling, until you actually do it, you won’t have learned what you need to know.

A more concrete example for my audience might be Clean Language. I’ve certainly written about that before and I’ve covered the dozen phrases and some of the mechanics, but unless you’ve actually used Clean Language to solve real problems, you haven’t really learned it. Clean is a tool for the client to find their own answers, not for us to find those answers for them.

At the end of a Clean Language session, we often don’t know what solution the client came up with, and sometimes don’t even know what the original problem was. We gave the client some structure, and they found the answers themselves. Try learning that from a book, without significant practice.

This brings us to coaching and training. There’s a difference between what I can write in an article here and what I can do with people who are getting active coaching or training. The latter is far more comprehensive, both in range and impact.

I’m glad that people read the articles I write. The next step is to experience some of that tacit knowledge, and for that we have to actually interact. I make some time available every week and you can book some of that here. Let’s talk.

The Self-Determination Theory (SDT) motivation model identifies six different stages of motivation ranging from Amotivation (not motivated at all) all the way through to Intrinsic (the work is enjoyable for it’s own sake).

When someone is asking for a deadline, that tells us that they’re currently Amotivated and they want at least some motivation. That deadline will shift us into External motivation which will at least get us moving forward, even if it’s the least effective way possible.

We could give them what they’re asking for, or we could try to get them even further to the right. The best results would come from being Intrinsically motivated, but anything further to the right will be a win.

Do we want to do the bare minimum or do we want much better than that? Obviously, the more motivated we are, the better the results will be.

How would we make that shift to the right? At a high level, SDT tells us that there are three key psychological needs, and the more of these that we have, the further to the right we’ll be. They are autonomy, competence, and relatedness.

Autonomy is the psychological need to feel in control of one’s own behaviors and goals, to feel that we have control over our own decisions and actions. That not to say that we’ll always have complete control of any situation - there will always be laws, or rules that we have to work within. This is a sliding scale where more autonomy is better than less autonomy. It’s ok that I’ve been told what to work on, if I can decide how I’m going to do it. If I’m told both what and how then my autonomy has been stripped away.

Management often struggles to give up control to their people and then when less autonomy is provided, they wonder why people are less motivated.

Autonomy is also a key component of psychological safety, and without that our effectiveness drops as well.

Competence is the need to feel effective and capable, know that we have the skills to achieve our goals. Are we able to use our skills effectively in the organization or have we been put in a silo that only allows us to use a subset of those skills?

Relatedness is the need to feel connected to others and a sense of belonging in a social group. Are we actually part of a team working towards a common goal or are we individuals in silos of our own? It’s worth calling out that while we all need other people, we don’t all need the same types or numbers of relationships. There is no “one size fits all”.

Coming back to our starting point, setting a deadline does provide some motivation, although it’s the least effective form, and can have other negative side effects. If we want better motivation, we need to shift people to the right on the motivation model, and for that we need to look towards autonomy, competence, and relatedness.

As is his habit, Dave started asking questions about who the customers were, and why they wanted this fax system. He wanted to understand not just the specific details of what he was asked to do, but more importantly what problem they were trying to solve, and who they were solving it for. Everyone was focused on just their part and so it took some time to figure out the big picture.

Eventually he discovered that one person in the building was unable or unwilling to walk up two flights of stairs to get the daily faxes, and that had somehow escalated into this massive project.

So Dave walked upstairs, picked up the fax machine and physically moved it down to their desk, completely eliminating the need for a multi-million dollar project.

At this point you must be thinking that is so insane that I must have made this story up. Except that I didn’t, it really happened.

The question is why Dave was the only person in a long line of people who had actually looked at the real need. Probably dozens of people had been involved in discussions and planning around this project. Why had nobody else moved the fax machine?

I don’t know the real reason, but I can speculate. It’s likely that when someone first identified that there was a need to make faxes available, someone else saw an opportunity to do something that either made them look good or was intellectually challenging, and they chose to ignore the fact that it wasn’t really needed. Then as they added to that, they found more and more places that it could be used, whether or not those extra things were important to do. So the scope continued to grow and grow.

Before long, they were looking at a multi-million dollar project, with insignificant business value. Despite the lack of value, you can be sure that someone was going to get credit for delivering this large project though.

Then we couple that with the tendency of people to focus purely on the parts that they are personally responsible for, rather than the larger picture. In some cases, that’s because we’ve deferred to some expert that we assume already did the due diligence, and sometimes its because we just don’t want to.

I worked with one guy who strongly argued with me that he shouldn’t have to update XML files because he was hired to write Java, and another who wouldn’t update a ticket in Jira unless their formal job description explicitly stated that they had to. Some people develop tunnel vision and don’t want to focus on anything other than their own part.

Clearly, this project never should have got off the ground but once it did, other problems appeared.

Commitment bias, also known as the escalation of commitment, describes our tendency to remain committed to our past behaviors, particularly those exhibited publicly, even if they do not have desirable outcomes. … Someone experiencing commitment bias might think “I need to stick with this decision because backing out now would be highly embarrassing.” — The Decision Lab

The one thing I do know is that when the fax machine was moved and the project was cancelled, there were a number of people who were now very unhappy with Dave. They were embarrassed, now that their earlier decisions were under review, and it was obvious that this project never should have been funded.

Not a great outcome for Dave, as the work he’d been brought in for was now cancelled, however it was certainly the correct outcome for the company. They could now refocus on things that actually were important.

There are multiple lessons we can take from this:

1. Sometimes we just need to pick up the fax machine. Look for the simple solution, and that means looking at the bigger picture, not just the piece we were asked to do. Anybody can create something complex but it often takes real experience to make something simple.
2. The more committed we are in a direction, the harder it will be to admit, even to ourselves, that it was a mistake. Commitment bias and the related Sunk Cost Fallacy are very real. The earlier we can make the right go/no-go decision, the easier it will be.
3. It often takes real courage to step up and call out the problems. Building an environment of psychological safety will reduce the amount of courage required, but not eliminate it completely. We still need people like Dave, who are willing to say those things that are hard to say.

If you aren’t familiar with it, LEGO Serious Play is a business facilitation technique for helping groups brainstorm difficult and/or abstract concepts. And yes, it uses LEGO bricks as part of that process.

The kinds of problems that are best for LEGO Serious Play are difficult problems that don’t have simple answers. When I’m working in-person with teams, I regularly use Serious Play for retrospectives, or to create team working agreements.

Why LEGO? Isn’t that just a child’s toy?

There are significant neurological benefits to working this way, and I talked about a number of them in this article on learning with LEGO.

In addition to that, when using a large connected build, like the one described in the W3C threat model, there are powerful insights generated from the positioning of items and the connections between them. Having that physical spacial connection, dramatically helps with brainstorming.

The W3C article only shows a simple connected build so I’ve included this picture from one I was involved in. You can see that there are different kinds of connections, with varying lengths, shapes, and levels of rigidity. There is meaning in all of those attributes and that meaning becomes apparent as the build continues.

It’s been a decade since I first took LEGO Serious Play facilitator training, and I’ve used it a lot since then, always with positive results. If you’re interested in trying this with your teams then let’s talk.

See also: How I teach technical practices with LEGO. Not Serious Play but still LEGO and with many of the same benefits.

That doesn’t mean however, that management, or anyone else, can’t ask what improvements are coming out of the retrospectives. The whole point is to be improving and the team should be able to articulate how they are getting better, without being required to reveal how they got there, or what specific conversations happened.

It is completely reasonable to ask the team to demonstrate that they are improving, and in what ways. We can do that without violating the safety and privacy of the conversations themselves.

If we’re doing a retrospective across two teams and the total number of participants is relatively small then not much changes, aside from the fact that we might want to allocate more time.

As we get more and more participants in a retrospective, however, the dynamic starts to change. The more people we have, the less likely it is for individual people to speak up. If we have four people in the meeting, it’s likely that everyone will participate. If we have a hundred in the meeting, we might only have a handful of people speaking up, while everyone else remains quiet.

Does this mean that we can’t do a large retrospective? Not at all, we just need to adjust our approach a bit.

Recognizing that people are more likely to participate if they’re in a smaller group, we need to subdivide the larger group into much smaller ones, allow them to discuss among themselves, and then bring them back to the larger group to share what they learned.

One other difference, is that with a larger group, we may decide to keep more actions. With a single team retrospective, I always stress that fewer is better, and one is enough. In a larger setting, fewer is still better, but one may be too few. If the larger group is made up of five smaller groups then we may want each of those smaller groups to take some action away. There is no perfect answer here, just be aware that this is a case where we may want more actions than we would, from a smaller group.

Let’s look at some examples. Both of these examples were done in person, but that shouldn’t imply that you can’t do them remotely. You absolutely can.

Example 1 : Using Six Thinking Hats

I had a group of about a hundred people, and only three hours so we had to do some preparation ahead of time. In the week leading up to the retrospective, a survey had been sent out to collect high level themes where people thought we could improve. From these themes, we set up a large room with round tables, where each table represented one of those themes. Each table then used the Six Thinking Hats approach to discuss that specific theme, look for ideas, and subsequently select actions that could be taken around that.

When each group had finished discussing their theme at their table, one representative from each table got up and explained what they’d come up with, to the larger group. There was an opportunity for other tables to ask questions and get clarification on what was meant.

Each table had possible actions and as they’d explained what they’d come up with, those actions got added to the larger pool of possible actions.

Then as an entire room, they looked at all the actions from all the tables and voted on the ones they felt would make the most difference.

Example 2 : Using Open Space

I had an entire IT department of more than sixty people, including management, and a full day allocated for this activity. The individual teams had been doing retrospectives on a regular basis, but this activity was different in that we were looking at the entire system, not just one team, and were retrospecting over a one year period.

I had brainstormed with some of the leads ahead of time and we’d put notes up on the walls to represent a timeline of things that had happened during that year. We were careful not make any of these judgmental; these are merely things that happened. The purpose was to be a reminder of what had happened across the year.

After welcoming everyone and briefly walking through the timeline, we spent about half an hour as an entire group, brainstorming topics. Mostly this was done in silence, which often helps move it along faster.

Once we had a smaller number of topic areas, we used those to populate the marketplace for an Open Space, and ran multiple one hour sessions in an open space format.

It’s worth calling out that due to the way Open Space works, it’s entirely possible that some themes will be completely ignored and that’s OK. The ones that people are passionate about will have been discussed.

When all rounds of open space discussions were complete, someone from each discussion presented what they’d learned and what actions they came up with, just as in the example above.

Then as an entire room, they voted on the actions that were most important.

Conclusion

In both examples, we subdivided the larger group into much smaller groups that could then have candid discussions. Then we brought those findings back to the larger group and selected actions. This takes longer, but encourages participation from everyone and gets better results.

One quick note on doing this remotely. In order to subdivide the group effectively, you’ll need breakout rooms and the ability to move people into breakout rooms quickly. I strongly advise you to have one person allocated to just managing the technology. The facilitator will be busy enough keeping an eye on the people, and if they have to also manage all the breakout rooms, then that’s overwhelming. Get someone to help you.

Just as I did by referencing that book. Go read it ;-)

Probably the thing that annoys me most about the GenAI tools is not the tools themselves, but rather how they are used as that “authority” by people who have no supporting evidence for the claims they’re making.

“I asked ChatGPT and it said…“ but did you actually look for any supporting evidence to verify that what it said was correct? It’s often wrong and any statements it makes needs to be verified.

The tools are quite amazing in terms of what they can do, but they are not “the authority” on any subject. Everything they say has to be verified before being used.

I get frustrated at the constant appeals to authority around these tools, and I find myself tuning out as soon as I hear the words “I asked [AI tool] and it said…“

Yes, use them to help you with a starting point, but don’t stop there. Verify that the information is correct before you start using that in arguments.

In a therapeutic context, we talk about primary and secondary gains for any behaviour. The primary gain are those explicit reasons that we would give if someone asked us why we did that. The secondary gains are all of the other benefits we get from that behaviour that are less obvious. Strangely, the secondary gains are often more powerful than the primary ones.

Let’s look at an example: if someone says that they want to stop smoking then their primary gain is likely around health. They want their health to improve. They want to breathe easier. They have some clear goal in mind for why they wish to stop. If you ask someone why they want to quit, this is a common reason they might give.

Yet, if this were the only gain then it would be easy to quit, and as we know, it’s rarely easy.

Secondary gain for many smokers is in relationships. When they have that smoke, they’re rarely doing that alone. They get together with their fellow smokers and they reestablish social connections. For these people, giving up smoking also means giving up this social connection, and now that’s in direct competition with the health benefits.

This is why so many smokers continue to smoke, even though they confidently state, and often even believe, that they want to quit. The primary gain is theoretical and in the future, and therefore less tangible. The secondary gain is immediate, and powerful. If I quit, I feel the loss of those relationships right away, compared to the potential improved health in the future.

Back to work in progress (WIP). We all understand that finishing work is far more important than starting new work, and yet we continue to start more and more, while finishing very little of it.

The primary gain is in finishing work, and this is what we would tell anyone who asks. I’m starting this because it needs to get done and if I don’t start it now, it won’t get done in time. Yet, if we really think about it, starting each new item makes it less likely that anything else already in progress will get done on time.

The secondary gain in this case, is in avoiding the judgement from not taking something seriously when it’s brought to us. If we don’t start it right away, then we’ll be judged. That judgement is immediate and painful, while the gain from actually completing the work is in the future, with a smaller reward.

• I’m asked for a favour and I want to be helpful so I start that thing.
• A piece of work arrives that is urgent for someone and I want to be a “team player” so I start it.
• I’m waiting for something that’s outside my control and I feel pressure to always be busy so I start something new instead of waiting for the thing that’s blocked.

As the amount of work in progress increases, we get fewer and fewer things done, and the ones that are done, tend to have lower quality. Just as with the smoker whose health continues to decline, we’re getting worse by not staying focused on the primary gain.

How do we reverse this?

If the secondary gains are around relationships then we can find ways to say no that doesn’t damage those relationships. If we can can say “I want to help, but the team agreed that all requests have to go through this process…“ then I’m off the hook. I’m at less of a risk of damaging that relationship, because it’s outside of my control. I’m retaining my secondary gain, which also achieving the primary gain of getting the work done.

Keep in mind that if you’re doing either Scrum or Kanban then there are already rules in place around limiting how much work you can do at once. Scrum does that with a timebox, and Kanban does it with more explicit limits. We don’t have to make up new fictitious rules to get off the hook, those rules are already in place and we’re supposed to be following them.

We should also have team working agreements, and they can include things like this if we need to be more explicit. “Any new requests have to come through our product owner”, for example.

When we see people doing things that are clearly not in their best interest, we should be looking for the secondary gain. What are they getting from this behaviour and how could we replace that if we want them to do something different?

If you haven’t heard of it before, LEGO Serious Play is a business facilitation technique that uses LEGO bricks to work through complex problems, requiring creative solutions.

I was first introduced to Serious Play by Ellen Grove, and watching her facilitate deep meaningful conversations with just a bit of LEGO was astounding. I could see people opening up and sharing things that they might otherwise not have been willing to discuss. I’ve also seen creativity burst forth with new and novel solutions to hard problems.

When I first took the training, I didn’t understand why it worked. I only knew that if I followed this structure, I’d get some amazing results. It’s only later, as I started to study neuroscience and psychology that I began to understand how it was working, and why I was getting the results I was seeing.

Not everything that I do with LEGO is Serious Play btw. I do a number of other exercises with different kits, but that’s not today’s point.

In one case, I had a team that just wouldn’t speak up in a retrospective. I’d watched them for multiple retrospectives over many weeks and it was like pulling teeth to get anyone to say anything. So one week I pulled out the LEGO Serious Play and we filled two full walls of ideas. Things that they’d wanted to say all along, but hadn’t felt comfortable enough to bring up. That’s a typical reaction.

If this sounds interesting and you’d like me to facilitate some Serious Play for your teams, or you just want more information on what I’m doing with it then let’s talk.

Some things I’ve written about this…

• How to run a retrospective with Serious Play.
• How to build team working agreements with Serious Play.
• Some of the science, specifically around learning

We already know from Google’s Project Aristotle that psychological safety is among the most important factors for highly productive teams, yet although this may sound odd, many companies really aren’t interested in having highly effective teams. All they want are teams that are consistent, and predictable. Do we still need to focus on psychological safety for them?

The answer is still yes. Let’s hear from the experts what happens when we don’t have that safety:

When we feel unsafe, Polyvagal Theory tells us that we are either in a mobility response (fight or flight) or a freeze response.

In a mobility response, our prefrontal cortex (PFC) is either partially or fully shut down. “Our prefrontal cortex is partially or fully shut down to allow more resources to be allocated towards fight or flight. The prefrontal cortex is responsible for our higher level thinking so this effectively takes away much of our capacity for higher thought. This affects creativity, flexible problem solving, working memory and other processes. It also has impacts on short-term memory, attention and our ability to make risk-benefit assessments.” (Brann 2022)¹

In a freeze response, our PFC is impacted due to lack of oxygen to the brain. “When you shut down, heart rate slows. Although this reaction works well in reptiles, it is more challenging to mammals, who have a great need to maintain oxygenated blood to their brains. When mammals shut down, there is a massive reduction in oxygenated blood going to the brain. This compromises function and can result in loss of consciousness. What happens to our cognitive function when this occurs? Even if the shutdown is not sufficient to result in a loss of consciousness, it changes our awareness, and there is a massive reduction in cognitive resources. The ability to make decisions and even the ability to evaluate the situation may be compromised.” (Porges 2017)²

In a mobility response, we are more likely to misread social cues, seeing neutral faces as aggressive and fearful faces as angry (Porges 2018)³. Then on top of that, being angry makes us more susceptible to false or misleading information (Greenstein/Franklin, 2020)⁴

We are also distracted by potential dangers and are less capable of following business conversations. “Our middle ear adjusts our hearing to amplify low frequency sounds and to dampen high frequency sounds. This makes it easier to hear predators approaching but more difficult to hear and understand human voices.” (Porges 2017)² This will directly impact our ability to collaborate or hold conversations with others.

We are less capable of effective problem solving. “The very act of preparing for flight or flight uses up oxygen and glucose which are needed for creative insight, analytical thinking, problem solving and short term memory. All of these are impeded.” (Carson/Tiers, 2014)⁵

Then we tire easily. “Our brain is flooded with noradrenaline, which helps us focus but a constant flow of this also tires us out quickly.” (Brann 2022)¹

“Since the PFC is a relatively ‘new’ part of the brain, it is much slower and not nearly as efficient as your nonconscious brain at processing what’s happening in your world. It doesn’t operate with the same strength and quickness as does the amygdala. Your PFC also requires a tremendous amount of resources (oxygen and glucose) to operate effectively and enable you to “brake” any unwanted behavior. Therefore, if you use it too much over a short period, the PFC will fatigue, start to slow, and eventually shut down.” (Porges 2017)²

All of this is bad in the moment, but it gets worse over time if we don’t address it.

“Research shows that with chronic stress, roughly 20% of the hippocampus begins to disintegrate, literally shrinking.” (Carson/Tiers, 2014)⁵

The hippocampus is critical for storing new memories. If we want to be learning, we need this.

“Our body is flooded with cortisol, which while helpful in a short term survival situation, has many negative side effects over the long term. It suppresses the immune system, increases both blood pressure and blood sugar levels, and decreases learning ability.” (Carson/Tiers, 2014)⁵

“To make matters worse, prolonged stress can cause the amygdala to grow in size and strength.” (Arnsten, 2012)⁶ As the amygdala grows, the more likely we’ll trigger the next fear response.

Whether you care about high performing teams or not, not having enough safety in our environment is a real problem. Perhaps it’s time to put some focus here.

Have you ever brought a group together and just said “come up with a bunch of ideas”? How did that work for you?

It might work once, however it doesn’t work reliably or consistently. If we want creativity, we need to create the right context to bring that out, and one of many things we can try is to apply some constraints.

A 2022 paper (Tromp & Baer) took a look at this. If we give someone a blank piece of paper and the instructions to “draw something”, they’ll have a much harder time coming up with a creative idea than if we apply some constraints first, such as “draw a cat on a table”.

Interestingly, we tend to feel more creative when we have no constraints, but we are more creative when the constraints are in place.

There is, of course, a point at which too many constraints can then hamper creativity again, but this isn’t usually our problem, in a retrospective.

So apply some constraints to the approach you use in your retrospectives. Even if it’s simple category based groupings like “mad / sad / glad” or “working well / needs improvement”. These constraints will help.

Constraints aren’t limited to the simple groupings in those examples. For example, Edward Debono’s Six Thinking hats makes for a great retrospective by applying constraints in the form of different lens to see the world. When wearing the white hat, we are constrained by only considering data. With the red, we only consider feelings. One lens at a time.

If you want more creativity, try applying some constraints and see what happens.

For anyone who thinks of people as “resources”, this makes no sense. Surely our people are interchangeable and it doesn’t matter how we put them together into teams or how they might work within that team. Except that it does.

We’re going to consider these teams from two different perspectives

People ≠ Resources

People do not behave like resources. I can move chairs from one room to another and they continue to work just as well as they always have. I can move pens or markers from one place to another and again, there is no difference to ability to do what we need them to. Chairs and markers are resources. We can move them around and it makes almost no difference.

Furthermore, I can mix and match the resources and it makes no difference. I can replace the blue marker with the red marker and can continue to write with either. There are cases where it’s important that I’m writing in red, rather than blue, but that’s a minor difference.

Adding or removing a person from a team will change the dynamics of the entire team, sometimes for a very long time. Adding the wrong person can completely destroy a team. That wouldn’t happen with things that are actual resources. Adding a red pen into a pile of blue pens won’t impact the effectiveness of any of the blue pens.

When we continue to speak about people as if they were resources, we’re conditioning ourselves to believe that they’ll work in a certain way, and then we’re shocked when that doesn’t happen. The words that we use are more powerful than we imagine.

It only becomes worse when we start thinking about “fractional resources”. If I have a jug of water then I can pour half into another container and each container is still equally useful, despite that they have half as much liquid. If I attempt to split a person across two projects then they are not 50% effective on each. If we’re lucky, we’ll get 40% capacity on each project with the remaining time lost to context switching. I’ve seen cases where people get effectively nothing done because they’re just switching back and forth between projects.

Project Aristotle

Let’s revisit the two teams that we started with. Same product, similar work, similar team composition but not operating at the same level of effectiveness. What could explain the difference?

It turns out that Google did research on this exact question, back in 2012. They studied 180 of their own teams to see why some performed so well, and others didn’t, and then published the results of this as Project Aristotle. What the researchers expected to find was that the differences were in the skills of the individual members, perhaps the experience level of those people, or perhaps the tooling that they were using.

What they found instead is that the key differentiators were not in who was on the team, but rather in how the team worked together.

They called out five specific factors:

1. Psychological safety: A strong team culture was correlated with each member’s perception of the consequences of taking an interpersonal risk. Those on teams with strong cultures feel safe taking risks in the face of being seen as ignorant, incompetent, negative, or disruptive. In a team with high psychological safety, teammates feel safe to take risks around their team members. They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.
2. Dependability: On dependable teams, members reliably complete quality work on time (vs the opposite - shirking responsibilities).
3. Structure and clarity: An individual’s understanding of job expectations, the process for fulfilling these expectations, and the consequences of one’s performance are important for team effectiveness. Goals can be set at the individual or group level, and must be specific, challenging, and attainable. Google often uses Objectives and Key Results (OKRs) to help set and communicate short and long term goals.
4. Meaning: Finding a sense of purpose in either the work itself or the output is important for team effectiveness. The meaning of work is personal and can vary: financial security, supporting family, helping the team succeed, or self-expression for each individual, for example.
5. Impact: The results of one’s work, the subjective judgement that your work is making a difference, is important for teams. Seeing that one’s work is contributing to the organization’s goals can help reveal impact.

Of the two teams we started with, one was heavily collaborating and one was largely working as a bunch of individuals. I’m sure by now, you recognize that the higher performer was the team that was actively collaborating.

Unfortunately, improving that effectiveness will never be as simple as saying “collaborate more”. There are many factors involved in getting a team to actively collaborate and the items called out in Project Aristotle are a great starting point.

I personally find that ensemble work (often called mobbing) is a very easy way to build up the first three of these. The fourth requires an understanding of motivation, and the last involves product strategy.

See also: This episode of the Mob Mentality Show where I get into detail about how ensemble work specifically helps with psychological safety.