How to Speak to a Technical Person
A few days ago, my wife and I were grocery shopping. The cashier behind the counter was jolly and chatty. When she took my money, I was due to get $0.25 back in change. Then the following conversation occurred:
Cashier: You're due back 25 cents. Do you want me to write a check?
Me: No, thanks. Cash would be fine.
Wife: Honey, she was joking about the check.
Now, my wife knows me better than I do, and she knows full well that I don’t understand sarcasm. Likewise, I often don’t get jokes where the punchline is still grounded within the realm of possibilities. This cashier could have possibly cut me a check, so I took it seriously. In the moment, I just took it as another “paper or plastic” type question.
Now, I could blame this quirk on my upbringing or my personality, but I really think it stems from my technical background. Every day, as I talk to technical people about technical issues related to computer operations, we have to take our conversation to computer level. Very quickly you realize that computers are as literal as it gets. For example, I once spent an entire day debugging a “F0R LOOP” where there was a hidden zero instead of a letter o. Actually, if you look closely, you'll see that I wrote a zero in the previous “F0R LOOP.”
I could not pick this issue out with a naked eye, but to a computer “F0R” and “FOR” are completely different.
Now, this relates directly to your interactions with technical folks. If you are talking to a tech support person who's trying to assist you through a technical issue or to a developer trying to understand your business requirements, you have to be clear, concise and direct. Otherwise, you may think you're saying one thing (FOR) when they're reading it as something completely different (F0R).
Here are some of the helper points that I’ve picked up along the way that may help you when discussing technical issues:
1. Always put yourself in another person’s shoes, and remember that they're seeing this problem for the first time. Provide all possible info around the issue including:
- The steps you made to arrive to an issue. I’m a huge fan of keystroke actions, but if your issue is only caused by selecting an action with a mouse click, that’s something I should know.
- If the above steps and issue are reproducible? Sometimes glitches happen and then disappear without a trace. Try restarting your software or even your whole machine. If the issue goes away, you likely saved a lot of time that would have gone to opening a ticket and getting restart instructions as a first troubleshooting step.
- Also include the reason this issue may be a priority. Your issue may sound trivial if, for example, you cannot move an application window. But it’s a more serious issue if it prevents you from accessing an important application button.
2. When communicating, take the following into account:
- Are you communicating with a technical person? If yes, feel free to be technical in your description. If not, then describe your issue in a conversational tone.
- When providing the info, are you using lingo that another person may not understand? In my case, I always catch myself referring to SoapUI’s Property Expansion functionality when the other person may not even be familiar with the SoapUI.
3. How is your grammar? Fortunately, you don’t have to be a grammar stickler and worry about things like preposition placements. But there are things you should consider:
- Try to avoid using vague words like “one” or “it” to describe an issue. For example: “When I opened the document, the content was askew. When I tried to print the document, the printer jammed up. It cannot blow up like that!” In the last sentence of this example, are you complaining about the document or the printer? It’s not really clear. So I would repeat myself even at the risk of sounding redundant. It's better to be redundant and clear than to leave the other person wondering.
- Avoid acronyms. Just the other day I had a customer ask me for a POC. While I thought this was a request for “Proof Of Concept”, turns out they were looking for a “Point Of Contact.” If I hadn’t asked them to confirm, I could have wasted a lot of precious time for a proof of concept that no one needed in the first place. Again, don't be afraid to ask questions or be redundant to avoid ambiguity.
So as you encounter technical issues that make you want to through your computer out the window, try to step back, reach out to support and provide a clear statement of the issue and its context. This way, you are giving technical folks the information they need to resolve an issue.