Delivering Difficult Messages

Recently, I attended a workshop run by Fiona Charles that focused on how to deliver difficult messages – a crucial part of any testing role because it is literally our job to identify problems (or potential problems) and communicate them to the business or stakeholders.

Fiona’s approach to the workshop was interesting – she asked us, in groups, to develop scenarios where someone has to deliver a difficult message, and to define the characteristics of the situation, the speaker, and the receiver. We then role-played these scenarios and analysed how the message was delivered and received.

While the discussion elicited some interesting points, the idea that struck me more than anything else was this: to help you to deliver difficult messages, ask yourself the difficult questions.

Let me explain.

Two scenarios played out last night. The first saw a development manager having to front up to a project manager and reveal that they had found that their COTS product didn’t do what they needed it to, and so their imminent release was in jeopardy. They found this out last minute because it had only just been passed to the testers.

The second scenario saw a tester having to pull a general manager away from his beer at 4pm on a Friday to tell him that they had found a show-stopping problem with the release that was due to go out on Monday. This was especially problematic because whole company’s future depended on a successful release.

While at surface level these two messages seemed similar (a problem found late in the piece jeopardises a big release) and could certainly be classed as difficult (after all, the receiver of the message didn’t want to hear it) they’re actually quite different.

See, in the first scenario, the development manager or his team had made a mistake. They had made an assumption that the claim about a feature made by the provider of the third party product was accurate and hadn’t validated it in their context. Only when the integrated solution was handed to the testers did it become apparent that this claim was invalid.

Of course, it’s not just their fault. Why were the testers only getting involved (or only allowed to get involved) at the last minute? Why was a proof of concept not done on the COTS product if the feature was so integral to the integrated solution? These are questions that could and should be asked of the project manager who, in this instance, was receiving the message.

But ultimately, the development manager had been remiss. He should have ensured that the key feature of the COTS product they were integrating with did what they had assumed it would do. And so this is a difficult message because not only does the receiver not want to hear it, but because the speaker doesn’t want to deliver it, and admit that they’re culpable.

In the second scenario, the speaker was unafraid to deliver the message because she had not been remiss. She was able to credibly justify why the problem had been found late in the piece – the issue found was a deadlocking problem when multiple users accessed the same component, and it was found late because only once the component of the product had been completed were all three testers able to use the solution in parallel.

As such, this message wasn’t so difficult to deliver. It’s still communicating bad news, but it is done from a position of credibility. This enabled the speaker to calmly lay out the problem, justify why it was found so late, and then engage the receiver in a conversation focused on solutions and problem solving.

So, the key to being able to deliver difficult messages is to not make mistakes! That way, the messages become less difficult. It’s still not nice to have to say “hey, we’re screwed”, but it at least gives you the ability to have a reasonable, respectful conversation that faces facts and gets on with the important business of solving the problem.

But of course, nobody makes mistakes on purpose, so simply saying “don’t make mistakes” is a gross oversimplification.

Rather, I prefer to think that if we are continuously asking ourselves the difficult questions (and answering them honestly) we are far less likely to make the sorts of mistakes that result in our having to deliver difficult messages.

For instance, if the development manager from the first scenario had stopped and questioned whether he was comfortable with the assumptions he and his team had made, they would likely have identified their problem earlier and actually had a good message to deliver: “Hey, we have a problem, but good news, we were on the ball and found it early enough that it can be fixed”.

We’re never going to be able to eradicate mistakes entirely, and so having the tact and poise to deliver difficult messages effectively remains a crucial skill for testers. But in many ways that’s a reactive solution. I prefer to focus on preventative solutions.

By continually asking ourselves the difficult questions and making sure we can answer them, we are less likely to find ourselves needing to deliver those difficult messages.