Recently, a coworker and I were discussing an article on the Test This blog about tester communication skills. It presented some nice ideas about making communication more effective coming from testers, but I thought that it could be expanded to be more universal. Clarity of communication is important. So why is it such a common failure point among internal interactions? I don’t think there’s a definitive answer to this question. At least, not something that will work for everyone. People are different, have quirks and prefer different types of communication. However, I do think that there are some simple ways to improve communication that can have positive effects on daily tasks. As I mentioned above, the points from the Test This blog are excellent. I’ll reiterate a few of them below.
Be Specific. I can not reiterate this point strongly enough. It’s easy to fail to notice you’re not following this point. Everyone, at some point, has gone back to review a case or an email conversation months after it originally happened and completely forgotten what the discussion was about, even though you have a record of the whole thing in front of you. In any communication, (verbal, emails, cases, tickets, business requirements, etc) the use of specifics can reduce confusion, improve documentation, and prevent many other issues. For example, the difference between “this doesn’t work” and “The application shows a flashing blue line when I click the ‘exit’ button” is huge. While it does take a little extra time up front, you’ll save yourself repeated explanations in the long term.
Context. One of the most common mistakes in inter-office communication is the assumption that other people know and understand the context of the topic at hand. You can easily confuse or cause offense to someone without even realizing you’re doing it. Prefacing a discussion with a quick summary, or background, can usually alleviate this. These details matter, and can translate in to a greater understanding of what’s happening as a task is passed down the chain. A question without context can be dangerous. For example, say a new hire is working on a project, and asks another developer for a good way to do task X, not giving context to the area of the project they’re working in. A solution to that problem already exists in the area they’re working, but not in a more general sense. The new hire would have saved themselves a significant amount of work if they had been clearer up front. The difference between “What’s a good way to do X” and “Hey, I’m working in area B of project A, and I’m trying to do X. What’s a good way to do this?” is significant.
The six month litmus test. In six months, will you remember what “the menu bug” is? What about a new hire, who wasn’t around for the verbal part of the discussion? Will they be able to infer all the information they need from business requirements, or will they be able to reproduce a bug from the information in the ticket? Will another developer understand the reasons why a case was resolved just by reading the ticket? If the answer is no, you need to add more details. You should be able to infer the important details six months down the road, or these communications are not clear enough. If a customer support ticket is resolved with the word “fixed”, it’s not clear as to what was done. When another customer inevitably has that same problem, you now need to do all the legwork a second time. A detailed explanation in the case would have saved you a lot of time and effort.
The stigma of asking questions. At some point in their lives, many people become discouraged from asking questions. A simple question can often save significant frustration in the long term. Why is this support case urgent? Because this client has a history of problems. Why do we have to change the name of this product? Because it means something dirty in Germany, where we’re trying to break in to the market. Why can’t I reproduce this bug? Because it was originally discovered on a 32 bit machine, and you’re trying to reproduce it on a 64 bit machine. Why can’t we use new technology XYZ? Because we need to maintain support for legacy customers who’s hardware doesn’t support XYZ.
It’s ok to say “I don’t know”. When you don’t know the answer, say you don’t know. Guessing can lead to confusion, misinformation being spread, and to you looking bad. While it may look bad to say “I don’t know” in some situations, giving a wrong answer will almost always look worse. For example, when asked the question: “Will our software be compatible with Windows 8 without any code changes?”, and you haven’t actually tested it, it’s better to say “I don’t know, we need to test that” than “Yes, it should”, in case the software doesn’t actually work. A sales person could have sold a million dollars worth of software based on your answer, only to realize that you were wrong when the client tries to use it.
Language matters. Always avoid phrases like “That’s impossible” or “I don’t believe you,” as well as the use of absolutes like “always” and “never”. Not only are they rarely true, but they can be very offensive to the people they are directed at. The use of words like “dumb”, “stupid”, or other pejoratives should also be removed from your work vocabulary. A phrase like “This stupid widget never works properly” doesn’t communicate any useful information, and can seriously undermine the relationship with the person who is responsible for fixing the problem.
Body language matters too. When speaking to someone in person, their body language can often say something different than what they are verbally communicating. Simple things like looking at your computer screen while someone is talking to you, can make them believe that you’re not listening to what you’re saying.
So, what are some ways to improve in these areas?
- Pronouns. “I clicked on it”. “She said to do this”. Use of general terms like this can cause a disassociation between the discussion and what’s being talked about. These terms can be misinterpreted, if there are multiple subjects being referred to. Say “I clicked on the edit button” or “Susie said to do this” instead.
- Observations. Sometimes there is important information contained in an observation, that doesn’t get communicated to other people. It could be assumed that the observation is common knowledge, or that it is unimportant. “Every time I go to the page, my CPU spikes to 50% usage. I figured it happened to everyone.” Leaving these details out can often mask a problem. Don’t decide a detail is unimportant, let the person on the other end of the communication make that decision.
- Confusion. If you find that your point isn’t being understood, or isn’t coming across quickly, change tactics. If you’re finding verbal communication isn’t driving the point home, draw a picture. If people find that your writing is confusing, consider having a peer review it. Don’t bang your head against a brick wall trying to make something work that simply won’t. Change it up, or ask for help.
- Repetition. Different people absorb information in different ways. You need to be able to adjust to that, but the burden of communication falls on both parties. It’s a good practice to repeat back, in your own words, what you understood something to mean. This creates an understanding between both parties that information was properly communicated. If you can’t find common understanding, bring in a third party to mediate discussion.
- Internal timers. If you have difficulty with internally managing whether you’re speaking too long during a meeting, set yourself a timer. Most cell phones have a timer function, and using it can train you to speak more succinctly in a short period of time.
- Examples. Speaking in the hypothetical just doesn’t work for some people. Sometimes an example of what you’re trying to say will convey the message in a clear and concise manner that no amount of exposition can manage. Providing both exposition and an example will greatly strengthen your points.
- Templates. There are times where you find yourself repeatedly asking for the same information to be provided. If this happens with any regularity, providing a template can drastically improve the quality of information reported to you. Some time back, we had a problem with the consistency of information provided in escalated support cases and internal bug tickets. We found ourselves asking the same questions of the people who reported the problems, over and over. Different people would provide different levels of detail. In some cases, that was fine. In others, it required a lot of extra effort to find out this information after the fact. Sometimes, the problem wouldn’t be investigated until days later, and by that time the specifics weren’t as fresh in the person’s memory. After brainstorming a way to improve things, we added a simple template on all newly created escalations and bug tickets that had fields that simply needed to be filled in, instead of a blank text box. After that was implemented, we saw a significant increase in the quality of reporting, as well as the turnaround time in resolving these problems.
- B-Line Medical | How to write a good bug report
[...] name, it’s important that they’re clear and well written. I’ve ...n