Uncharted Waters

May 14 2019   10:26PM GMT

Serious Communication

Matt Heusser Matt Heusser Profile: Matt Heusser


Yesterday, on the twitters, I had this conversation about communication with Michael Bolton:

Communication With Michael Bolton


It’s a simple answer. It is an easy answer.

And yet, when the tester asks “What exactly do you mean by soak testing?” they are likely to get non-answers. The manager may at first act like the answer is obvious, that everyone knows what it is. Another common response is for them to say “You know, soak testing”, with a slight laugh, making it socially awkward for you to say “Oh course I don’t know, that is why I asked.” If you persist the manager may shift, to say that you, the tester, are the expert. If they are willing to admit they don’t know either, you get to go to the next level. At some point, someone becomes afraid of you talking to “their” customer, and the communication stops.

Now what?

After twenty years of doing this and helping others do it, I have developed a handful of tricks.

Read on, dear reader. Read on.

Kickstarting Communication

The typical response when people have no idea is to pretend, or to pawn it off on someone else. Don’t do that.

Instead make something up.

That is, shout what you plan to do from the rooftops. Feel free to make it clear you do not know what you are talking about. “I have been asked to do soak testing. When I hear soak testing, I think of running a server all the time for a period of weeks to look for memory leaks, so I am going to …”

Explain this at meetings. With the team. Over email. On the wiki. In Jira. In Confluence. On Sharepoint.  In instant messenger. Everywhere. Each of these is a communication method. Notice who responds to what method — and use more of that method for that person. Give no one the opportunity to say “Well, yes, clearly he didn’t know what soak testing was; I wasn’t really in the loop.” Instead, everyone needs to join you in the mission of defining what soak testing is — or else they need to defer to you.

You can do this with anything. What the error messages will be when something goes wrong, what the interface will be to the API, how often the replication process will run. Anytime you can’t get an answer and are blocked make something up.

Part of that might be going to google, or asking people on the internet what a word means.

That is okay.

Doing better than “Name it, Claim it”

If you make something up, there are three possible responses. The first is that your answer is simply accepted. If that happens, you win. In the second case, having something concrete to respond to causes the other person to know what they actually mean. “Now that you’ve said that, no, that isn’t right, what we actually need is …”

That answer is something I hear painfully often. I’ve even said this: “What I am about to say is wrong. I know it is wrong. I do not know what is right. By saying that wrong thing, I hope to kick-start the conversation, to get us to the right thing faster.” Suddenly the room that spent two hours debating and getting nowhere has an answer in ten minutes. That answer involves tell me that I am wrong, that I don’t get it, that my guess was laughable.

I bite my lip and bear it.

Then we have the third option: Your work is approved by management, then nixed by senior management.

When The Work Needs To Be Redone

This is the worst. You did the research, you communicated. You got local buy-in, you got your work approved. Then someone from the client, the same person you tried to reach but were turned away, pops in rejects all your work. This is, of course, exactly what you feared, why you asked the awkward questions, why you documented and shouted your strategy to the rooftops. You might have written that the term could be interpreted in four ways, and you picked way number two because of this or that. Suddenly, two months later, the client pops in, says “nope, meaning number four” and disappears.

Now what?

At this point, you have a few options. You could suck it up, redo the work, and cry into a beverage after work. You could complain about a communication break down … and have your boss tell you to re-do it anyway. If the argument is about process (“how” to do it, such as how to write the code or test or conduct standup meetings) you can try the expertise gambit: “Thank you for your input into how we do our work; I will take it into consideration and let you know our decision.”

That is, you make it clear who is responsible for deciding what. This is drawing a line in the sand. It works better in cultures that are more based on expertise and achievement than in consensus, ceremony, or saving face.

The best choice is likely to get yourself into a position professionally where you can say no, where if you are fired you will have a different job in a week, a better job. That kind of professional position usually takes about a decade to build, but it can be done faster.

So there you have an idea or two on how to proceed in the face of unclear communication.

What are some of yours?

UPDATE: My friend, Kristīne Corbus, tells me she doesn’t expect twenty-somethings to be willing to admit they are ignorant, that they are stuck, that they are making things up. She doesn’t expect them to be vulnerable or secure enough to admit their weaknesses. Please, do me a favor.

Prove her wrong.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: