A Guide to Effective Communication for Engineers
As a technical person, one thing I sometimes find difficult is explaining how I think about things to people. When talking to someone who has enough background knowledge of the area to discuss, I feel like it’s party time. However, if the listener needs more context into the topic, it’s as if I am in a small box. I spoke to my manager about this, and we came up with a great idea — Comms Coaching.
He introduced me to a coworker who is a technical person like me. Unlike me, he can break down complex ideas into simpler terms. We met every week to diagnose my struggles and came up with a plan. I’ll be sharing with you how I improved my communication in weeks. But first, why is communication so important for engineers, and why is it hard to master?
Why is communication essential and challenging?
As human beings, we have to collaborate to survive. Software engineers are no different. Collaboration is essential because we often build products meant to be used by people other than us. Creating these products requires understanding the problem we are trying to solve, sharing project timelines with stakeholders, and requesting clarity on things that do not appear straightforward, amongst other things. To achieve success as an engineer, it is just as important as being technically proficient at working productively with everyone involved in the project, regardless of their technical background.
The major challenge in communicating as an engineer lies in conveying ideas to people who may or may not understand what you do or how you do it but are interested in the end product. Here are some of my learnings over the course of the coaching sessions.
- Know your audience
The first approach is to try to understand the profiles of people I work with on a day–to–day basis. Some of these people are fellow engineers, but they still differ from me in several ways. I might be proficient in a programming language that is unfamiliar to them. They might have core strengths in some computer science fundamentals, which I missed because of a different background. And sometimes, I might even be communicating with people outside engineering who know nothing about software development but understand the business justification behind the product we are building.
I observed several speakers doing a quick survey of the room to understand their audience before a presentation. It might not be easy to do this for everyone you collaborate with within a company. Nevertheless, understanding their job roles and responsibilities could help understand how best to communicate with them. To develop a general intuition about each individual in the company, we created a chart of the various organizational profiles, what they want from me when we collaborate, what I need from them, and what they might know or not know.
Even with this much information, it’s still important to confirm by asking questions. A colleague of mine from technical support recently asked me a question about a feature I helped to build. After explaining the functionality at length to them for a few minutes, I realized something was off. When I asked them if they wanted to know something specific about it, I realized they just wanted to know how to access it on the browser but were too polite to cut my explanation. Moral of the story: confirm your intuition with questions to define the right level of information they need!
2. A different approach for a diverse audience
Now that we know the personas we collaborate with daily, it’s also essential to understand how to tailor our discussions. Effective communication might be a daunting challenge, but one can overcome the challenge with continuous practice. There are some things I consider when talking to different audiences to note:
- Shared experiences: It’s essential to find common ground with the people we communicate with at any point in time. It’s easier to explain a topic by leveraging the knowledge of adjacent issues you both understand. For example, it’s easier to describe one programming language to someone who knows at least another programming language. In the same vein, someone with a linguistics background, despite not knowing anything about programming, might be able to comprehend syntax and semantics within the context of programming languages because they already understand it in the context of natural languages.
- Metaphors: a metaphor is a figure of speech in which one applies a word or phrase to an object or action that is not applicable. Computer Science is, without question, filled with metaphors. In a field with many abstract ideas, engineers have managed to bring these ideas to life in creative ways. For example, the shopping cart on e-commerce websites is not a “real” shopping cart; a web crawler does not have legs like a spider, nor is the world wide web made by an arachnid. These metaphors made these concepts within the grasp of laypeople like we’ve all been at some point. When communicating with people, I try to find established metaphors for complex ideas I have to share. However, tread this path with caution. Misusing metaphors might sometimes pass the wrong message or make things more complicated.
In one of our sessions, I attempted to explain the internet to someone from the middle ages. My first question, piggybacking on the previous point, was: “Does this person know about plumbing?”. Since the answer to this question was “yes,” here is my attempt at offering this explanation:
Imagine having these pipes running from a water source and running into and out of every home. Then there are also pipes through which other fluids flow out of the houses. The internet is similar to these connected pipes, except what flows in the pipes is information.
That might not be the best explanation, but I hope it would have been sufficient for someone in the middle ages!
- Do they need this?: When I find myself spewing technical terms in a presentation, I try to take a step back and ask myself — “Do I need this much detail?” if I had been blocked by an issue while implementing state management using React, for example. How would I communicate this blocker to a non-technical product manager asking me when I will deliver this feature? An approach is to tell them, “It will be ready in two days,” without telling them about my challenge. While this might be okay sometimes, it does not explain why the feature is taking too long.
Another approach is to explain further:
I currently have a blocker with React Query, which is taking some time. I will be talking to a colleague to unblock me today. I plan to deliver this in two days.
This response delivers the complete message, but I suspect the PM was thinking… “What exactly is a React Query?” My preferred approach now is to give them the same level of details without belaboring them with technical jargon. In this case, let’s find a substitute for React Query.
I am currently having a blocker handling some data on the browser, which is taking time. I will be talking to a colleague to unblock me today. I plan to deliver this in two days.
The last response is the same information without technical jargon.
For a better understanding of how to break down topics into simpler terms, we found the following resources helpful:
a. Explain Like I’m Five (ELI5) subreddit
b. Wired’s 5 Levels, where experts explain advanced topics in five levels of difficulty
3. Starting with why
At some point in the life of an engineer, one has to do presentations or get buy-ins from teammates and superiors. It’s easier to be so invested in the topic and think everyone shares the same level of enthusiasm. If you have a presentation and 20 people have shown up, amongst the group are super interested and are sold on the topic already, there might also be some who have maybe less than five minutes to become convinced that listening to you is worth their time. Reaching a decision is also similar because people have to be confident. How do you get your listeners to stay with you till the end when discussing a boring topic? How do you get them to buy into your idea?
One way to do this is by using a “hook .” And an excellent way to use a hook is by starting with “why.” There are many books on this topic, but I found this article on how Canva’s CEO learned to pitch perfectly after being rejected many times. I have found this tip most valuable, and it never fails to amaze me how well it works.
Conclusion
Effective communication is not about using the entire repertoire of your language or technical skills. Instead, it is about concisely giving the correct information. I have learned that understanding the audience and presenting the information in a way that suits them is far more important than my need to express myself the way I want. While I still ramble on here and there, these tips have helped improve how I communicate with others. I hope it works for you, too.
Many thanks to Emmanuel Gautier for being my coach and Matthieu Kern who helped kickstart the process.
