A couple of weeks ago I came across a post on social media from a tester who’d just had an uncomfortable conversation with one of her team leads. She’d been asked to stop rejecting tickets because some of the developers were taking the rejections personally, as if it meant they hadn’t done their jobs properly.
My first reaction was that the team lead needed to build some leadership skills, and I still think that. Telling a tester to stop finding problems doesn’t fix the problems; it just hides them. My second reaction was to consider the unspoken beliefs in what she was saying.
Adding more context, she explained the developers worked for an outsourcing company, and their project manager had told her that the rejections were the reason they’d had to do layoffs. More precisely, there was a specific belief that “Many rejections == layoffs”.
“Mental models [beliefs] are habits of thinking, learned, repeated and acted on without reflection.”
Joseph O’Connor and Andrea Lages, “Coaching the Brain”
O’Connor and Lages specifically avoid the term belief as they feel it’s too often connected with religious thinking, and they want to be clear what they mean.
They also point out that coaching doesn’t deal with whether a belief is true, only with its effect on the person holding it. This one meant that the tester was being pushed to let poor quality through, and the developers were treating every rejected ticket as a threat to their jobs.
Limiting beliefs often take one of two shapes. Either one thing means another (rejections mean layoffs) or one thing causes another (rejections cause layoffs). This one collapses both into a single equation.
Why do beliefs like this stick so well? Because they live in System 1, the fast, automatic part of our thinking. System 1 is biased to believe. It doesn’t stop to ask whether the evidence is good enough; it takes what’s in front of it and runs. In O’Connor and Lages’ words, “System 1 jumps to conclusions, especially about cause and effect.” Rejections came first, layoffs came after, so the rejections must have caused the layoffs.
She also mentioned that the team had been through layoffs before she joined, and a single significant event is one of the ways O’Connor and Lages describe mental models forming. One painful round of layoffs, and System 1 has a rule it can apply instantly, forever, without ever being asked to justify it.
Doubting is System 2’s job, and System 2 is slow and easily distracted. So if we want to loosen a belief, we need to get System 2 involved, and that means asking the kinds of questions that System 1 can’t answer on autopilot.
There’s a set of 14 language patterns that Robert Dilts collectively called Sleight of Mouth1, and they’re very useful here. Without getting into the theory, here are some examples applied to “many rejections == layoffs”.
-
Reality strategy: “How do you know the rejections caused the layoffs?” Was there a contractual rule for the vendor? Did someone actually say so, or was it inferred?
-
Model of the world: “Some vendors see rejections as free QA that keeps them from losing the client.”
-
Counter example: “Have there been sprints with lots of rejections and no layoffs? Have there been layoffs when the rejections were low?”
-
Intent: “Maybe the rejections are causing some people to become embarrassed and they’re lashing out with threats of layoffs.” Dilts points out that limiting beliefs about other people generally assume some kind of negative intention on their part2. Embarrassment is a far more workable problem than malice.
-
Redefine: “A rejection isn’t a failure report, it’s a defect caught before the customer saw it.”
-
Chunk up: “Are you saying the vendor’s survival depends on never being told about a defect?”
-
Chunk down: “What specifically is causing the threat of layoff?” Beliefs live at a level of generality that makes them hard to examine. Asking for specifics forces the belief to show its working.
-
Metaphor: “If a smoke detector goes off, do we fire the detector?”
-
Another outcome: “The real question isn’t how many tickets get rejected, it’s how many defects reach the customer.”
-
Consequence: “What happens to the vendor when the poor quality that wasn’t rejected reaches the customer instead?” The belief protects the developers this sprint and puts them at greater risk in the next one.
-
Hierarchy of criteria: “Isn’t keeping the client more important than keeping the rejection count low?”
-
Apply to self: “If rejections cause layoffs, should the project manager be worried about people rejecting that explanation?”
-
Change frame size: “Over the length of the contract, which costs the vendor more: rejections now or a lost client later?”
-
Meta frame: “That belief makes sense for someone who’s lived through layoffs. It might not be about the rejections at all.”
None of these argue with the belief directly. Each one asks System 2 to take a look at something System 1 had been handling on its own.
It’s also possible that the reality strategy question turns up something real. If the contract really does penalize the vendor for rejections, then the belief isn’t wrong; it’s pointing at a system problem. That’s no longer something a tester can fix by thinking differently; it’s something leadership needs to change, and that’s a different post.
Around the same time, a manager in a private group I’m part of described a firmware team he’d recently taken over. That team believed two things. First, that code which had already proven itself in the field couldn’t safely be refactored or changed in any way unless a safety issue had been found. Second, that the safety standards they worked under forbade pair programming as unsafe. Every change he proposed got rejected as non-compliant and unsafe.
As far as he could tell, the standards said no such thing, but it didn’t matter.
You might be thinking “so show them the standard.” He could, and I doubt it would help. Producing the document is a counter example, and it’s the pattern most of us reach for first because it feels like it ought to settle things. On its own it rarely does. That belief wasn’t built from the standard, so the standard isn’t going to take it apart. When the belief is coupled to something as important as safety, any challenge is going to feel like a threat, and threat is exactly the condition that keeps us in System 1.
Intent is the pattern I’d expect to land better here. The team’s intent is safety, and so is his. Starting from “we both want this code to be safe, so what’s the best way to verify it?” puts him on the same side of the table as the team, and pairing becomes one more way to get to the thing they already care about.
Consequence is the other lever. Code that nobody dares touch doesn’t stay safe. Over time it becomes the code nobody understands, and that’s its own kind of risk.
O’Connor and Lages suggest that the best intervention for a limiting mental model is to engage System 2 and agree on a small action that will give good feedback. For this team, that might be pairing on one low-risk change and seeing what the experience is actually like. A belief that’s been tested against real experience is much easier to let go of than one that’s been argued with.
None of this is unique to testers or firmware teams. Every team runs on beliefs like these and most of them are never said out loud. They only show up when somebody bumps into one, and from the outside that looks like stubbornness, or resistance.
In both cases the people holding the belief cared about something real. Jobs matter. Safety matters. The belief was a shortcut to protect that thing, and somewhere along the way it stopped doing its job.
Don’t argue with the belief. Unpack it instead, to see what it’s built on.
-
“Sleight of Mouth: The Magic of Conversational Belief Change”, Robert Dilts ↩
-
“Sleight of Mouth Volume II: How Words Change Worlds”, Robert Dilts ↩