Last week I talked about a situation where a tester had been asked to stop rejecting tickets. In that post, I focused on the beliefs in play. Today, I want to talk about leadership in that same situation.
The team lead was in a difficult spot. On one side was a tester whose job is to find problems before the customer does. On the other were developers who’d been told by their own project manager that rejected tickets were the reason for past layoffs. Whether or not that was true, the threat felt real to them, and so they interpreted every rejection as one more step towards losing their jobs.
There are two obvious answers. Keep rejecting tickets, and the product stays in good shape while the developers work with that threat hanging over them. Stop rejecting tickets, and the developers relax while the bugs head for the customer. The team lead picked the second.
The tester then found something that looked like a middle ground. She closed the rejected tickets and opened new bug tickets instead. The bugs still got reported, just less visibly, and the developers still got the bad news, just in a different wrapper.
Chris Voss, a former FBI hostage negotiator, has a story about exactly this kind of compromise.
“A woman wants her husband to wear black shoes with his suit. But her husband doesn’t want to; he prefers brown shoes. So what do they do? They compromise, they meet halfway. And, you guessed it, he wears one black and one brown shoe. Is this the best outcome? No! In fact, that’s the worst possible outcome. Either of the two other outcomes—black or brown—would be better than the compromise.”
Chris Voss with Tahl Raz, “Never Split the Difference”
The workaround is one black shoe and one brown. The product’s problems are now harder to see, and the developers’ fear is exactly where it was.
So what would a better outcome look like? Not a point halfway between the two positions, but one where the product stays in good shape and nobody loses their job over it. Finding that is the leadership job here, and Voss has some useful tools for it.
The first is what he calls tactical empathy. Before anyone can solve the problem, the developers’ fear needs to be acknowledged rather than argued with. One of his techniques for that is labelling1: naming the emotion you’re seeing, out loud. Something like “it sounds like every rejected ticket feels like a mark against you.” That isn’t agreeing that rejections cause layoffs. It’s showing that you understand why it feels that way.
The second is the calibrated question: an open question, usually starting with “how” or “what,” that invites the other side to help solve the problem instead of defending their position. “How do we keep quality up without putting anyone’s job at risk?” is a very different conversation from either “stop rejecting tickets” or “keep rejecting tickets.” It’s also a question the team lead could take to the project manager, or to the vendor, not just to the team.
The third is what Voss calls Black Swans: hidden pieces of information that change the whole negotiation once they surface. The obvious one to go looking for here is whether something in the vendor contract actually penalizes rejections. If it does, the developers’ fear isn’t irrational at all. It’s pointing at a real problem in the system, and no amount of quiet from the tester was ever going to fix it.
W. Edwards Deming put that more bluntly, in a remark from one of his seminars:
“A bad system will beat a good person every time.”
W. Edwards Deming, 1993 seminar2
The developers weren’t bad people, and neither was the tester. Something in the system was making rejections feel dangerous.
Effective leaders don’t accept poor solutions. They find a better way.
One client I worked with had a contract that required the team to deliver a set number of story points every sprint. Another had a contract that required the team to find a set number of bugs every sprint. Both of these drove dysfunctional behaviour and are textbook examples of Goodhart’s law. Deming is often credited with warning that people whose jobs depend on hitting a target will hit it, even if they have to destroy the organization to do it.
In both cases, when leadership was made aware of the behaviour, they changed the rules that the team had to work within. The story point contract had the reference to points delivered removed entirely. In the bug contract, the threat of not finding enough bugs went away. Nobody met the team halfway on the numbers; leadership removed the thing that had set the team against the work in the first place.
None of this is unique to testers or contracts. Whenever two things we care about seem to be pulling against each other, a compromise is tempting because it feels fair. Fair isn’t the goal, though. The goal is an outcome where both of the things we care about survive, and that usually means finding the part of the system that set them against each other.
Anyone can split the difference. A leader finds the better answer.
-
Psychologists call this affect labeling: putting a feeling into words reduces its intensity. I’ve written about using it on your own emotions; Voss points it at the person across the table. ↩
-
The Deming Institute sources this to a February 1993 seminar in Phoenix and notes that the wording varies between accounts: A Bad System Will Beat a Good Person Every Time ↩