Communication Best Practices
You are reading "Software, My Dream Job," a software engineering newsletter covering one person's perspective from working in the software industry. If you'd like to receive notifications for new editions, click or tap "Subscribe" above.
This month, we'll be jumping from communication tip to tip to share what I consider best practices in the realm of communication for a software engineer, especially in large teams. Let me know in the comments if there's any you'd add or disagree with!
Why
Software engineers, especially in big tech, need to be able to communicate their ideas and solutions with a variety of stakeholders, some technical and some not.
Large teams require complex topics to be communicated between many people with varied skills and experiences, and to have the ability to thread that needle is a sought-after skill, especially paired with the ability to be coding hands-on in these problem spaces.
How - Match Context to Audience
Match the knowledge level of your audience to get your message across. For example, if you are talking to someone in marketing, they likely don't need to know all the cool but technical details of your latest project; they just need to know what it does so they can create messaging around it to help your users. However, suppose you're talking to a fellow engineer, perhaps even someone more senior than you. In that case, you must ensure you cover all the relevant technical details when describing your solution!
Matching your audience's knowledge with your message is key: you want to provide the necessary context without drowning them in complexity.
How #2 - Overcommunicate
Large teams mean there are more than likely people in different time zones and definitely people with differing work hours. This can lead to missing clarity, which can sometimes take hours to iron out.
When in doubt, verify! Over-communication is critical to ensure alignment, especially in our remote/hybrid world. While you can (and should) trust your colleagues, verification removes any shadow of a doubt.
When miscommunication occurs, which is inevitable, own it and work to clarify. Make sure the other party gets what they need information-wise to clarify your original intent while not blaming the other party for not understanding it the first time. Try to piece out what in your delivery caused the miscommunication to learn from it for next time.
领英推荐
How #3 - Compassionate Communication
Put yourself into the other party's shoes to try and understand their perspective and how they are reading your words. Are they so busy they are skimming through super quickly? Are they reading too much into what you were writing when you simply provided a quick unedited note to ensure the lines of communication were open? This all matters!
Whenever possible, be concise. When a message is too long, it is often not read. You can provide a TL;DR, but there are limits to this. If the message is just a few hundred words, you should be able to expect people to read it — too many of us have gotten lazy in this regard and see a handful of paragraphs and ask for a TL;DR. Realize that doing so actually takes MORE time than just reading the message!
That said, being concise is an area I'm constantly trying to improve upon, as I can be overly verbose! By cutting things down to the right length and density, I can be more compassionate in my communication: it should make the reader's job easier!
How #4 - Bump!
Feel free to remind people of a message, especially when you need their input, and they should be able to answer you. However, if you message an exec who is likely underwater on their messages, that's perhaps a time to shift expectations. For a peer — they might've missed it while in a meeting, saw it, and meant to respond but got distracted, etc. If they haven't responded yet and you need their input, make that clear!?
I typically give folks I don't work with a lot ~24 hours, but for close peers who I know should be answering me sooner, I'll remind them after just an hour sometimes.
Also, know which communication medium will work the best! For example, someone might be on top of their email but underwater on chat, or vice versa. So, when you're not receiving a response, try another form of communication; they might not be seeing your messages at all!
Conclusion
Communication skills are one of the most underrated for software engineers, but they truly are required to grow and earn the trust of peers around you. To recap, the tips were:
While not an exhaustive communication guide, these tips will hopefully be helpful, and please feel free to clarify or ask questions about these in the comments :)