Communication Techniques in Software Engineering
Tips & techniques in communication for software engineers including how to providing and gathering context
Welcome to The Scalable, blog and newsletter to help you faster in getting promoted to senior position. We are release new content 1-2x a week.
Before we start, kindly follow me on Twitter & Linkedin and share this content to your friends. Enjoy.
Quick Links:
Communication is an essential skill in software engineering. Efficient communication can result in better product quality and faster delivery. I have often observed that one distinct factor differentiating seniors from juniors is their communication skills. In my opinion, seniors tend to have good communication skills. One piece of evidence is that non-technical individuals often seek out seniors for assistance instead of directly approaching the engineer who developed the system. I have inquired about this and received responses such as, "I don't understand what the junior is saying, so it's better for me to ask the senior and wait for them to sync up with their mentee".
But what does good communication mean in terms of software engineering? It certainly does not involve sweet-talking or making empty promises about features. In simple terms, good communication means ensuring mutual understanding between parties. It means that "I understand what you mean" and "You understand what I mean."
From that definition, there are two components to having good communication:
Being good at providing context.
Being good at gathering context.
In one-way communication (sharing knowledge or ordered by superior) you might only need one component. However, in two-way communication (discussions), you definitely need both components.
In today's article, we will discuss various tips and techniques to help you excel at providing and gathering context, depending on the individuals you are communicating with. In software engineering, you typically interact with four types of people: peers, superiors, subordinates, and non-technical individuals.
Providing Context
In communication, providing context means offering relevant information and ensuring that it is understood by the recipients, conveying the intended message clearly. If you often hear phrases like "I don't understand what you mean", it may indicate that you have not effectively provided the necessary context for others to comprehend.
This skill is incredibly important because a failure to do so can lead to discussions filled with assumptions, resulting in increased time to address problems, making incorrect decisions and taking inappropriate actions, among other issues.
Here are some communication techniques to improve your proficiency in providing context.
Provide Background Information
Use this in situation: All situation (except you have already intensely communication with the person about the topics)
I often met an engineers that jump into a discussion without considering whether the other party is prepared for the discussion or not. Like this conversation:
Engineer 1 (E1): Hi, please revert back your formula just for my case. My feature got bugs because of it.
Engineer 2 (E2): Wait... What?
Compare it with:
E1: Hey, currently, one of your codes is impacting my feature, which is
Feature A
that has dependency to yourendpoint X
. It seems like you have implemented a new formula, but in my case, I still need the old formula. Can you implement a condition when my feature hits your endpoints?
Whether you are talking to fellow engineer or even non-tech person, it is important to provide the necessary background information. This includes explaining the situation, goals or problems, relevant information about the topic, and the rationale behind your decision.
By providing this context, you enable your audience to understand the current situation and make informed judgments.
Talk in their languages
Use this in situation: All situation
I have written a brief about this in the article, which you can check out here. In the article, I provide an example of how Tyrion Lannister from Game of Thrones is able to adapt and communicate effectively with different individuals.
Notes: Here, "languages" does not refer to English, French, or other spoken languages, but rather to the level or style of communication that can be understood by the other party.
A good communicator is able to adjust their language level, sometimes toning it down, changing their words, talking around the topic, or being straightforward, depending on the person they are speaking to.
Business Guy (B): Our user asked if we can do custom calculations for the tax.
Software Engineer (SE): I think it's difficult to implement that. All of our functions already rely on the current fixed calculations stored in our database.
Compared with:
B: Our user asked if we can do custom calculations for the tax.
SE: Didn't we agree in the past that custom calculations were not allowed due to government policy? Has there been any change? Have you researched this?
See the differences? If you are a fellow engineer, you might understand the first conversation. However, if you don't fully grasp the context and domain knowledge, the second conversation might be easier to understand
It may not be easy to communicate in a language that the other person understands, but you can follow these tips:
Research and understand the audience: Consider the background, knowledge, and expertise of your audience. You may need to familiarize yourself with the domain knowledge that your audience understands, including the terms and phrases they are familiar with.
Avoid technical jargon: Steer clear of jargon and technical terms, especially when communicating with non-technical stakeholders. Provide explanations when necessary. While using tech jargon looks cool, it often contributes to the perception of "bad communication" among engineers. Use technical jargon only if you are 100% sure that the other party already understands it (typically when communicating with peers).
Experiment and adapt: It may not be easy to determine the appropriate level of communication that will be well-received by both parties. You can try using a specific language level and, if the other party doesn't understand, adjust your approach accordingly.
Use Analogy
Use this in situation: Mainly when converse with non-tech
You might encounter situations where it is challenging to find sentences that your audience can easily understand. In such cases, you can use analogies that are similar to the situation at hand to explain things, enabling the other party to grasp and visualize the concepts more easily.
Let's learn through an example:
Non-Tech Guy: Hey, tomorrow we are going to have a big event, and we expect the traffic to increase 5x. It should be easy to handle, right? Just make your server bigger.
Software Engineer: It's not that simple. Imagine you are running a restaurant with a capacity for only 20 people. Suddenly, you have 100 people waiting in line. It's not just a matter of expanding the physical space; you also need to hire more cooks, waiters, stock up on additional raw materials for food, maybe even pre-prepare some dishes so the chef can cook them upon order, and so on.
By using this analogy, it becomes much simpler for the non-tech person to understand the situation compared to explaining concepts such as horizontal scaling, caching, load balancers, and more.
This technique can still be used to communicate with fellow engineers, but you can utilize analogies related to technical concepts. Personally, I rarely use this technique with fellow engineers.
Use Visuals
Use this in situation: Explaining something hard to explain such as system design
Communication is not limited to verbal expression alone. Non-verbal communication, including the use of visuals, plays an important role. While visuals may not be suitable for every discussion, I highly recommend utilizing them when possible.
Visual says thousands words
I usually employ this technique when communicating with my subordinates (mentees), especially when explaining system design. Utilizing charts or mind maps proves to be very helpful. I rarely discuss this with the managerial level and above, as we typically have a mutual understanding through verbal communication at a higher conceptual level.
Apart from that, when engaging in conversations with non-technical individuals, I frequently utilize this method in certain cases, such as providing infographics.
Ask for Re-explanation
Use this in situation: Converse with your mentee
Remember, the purpose of providing context is to ensure that your audience truly understands your message. However, there is often a bias where people think they understand, but in reality, they have misunderstood. To address this, you can ask them to re-explain the concept using their own words to ensure that both of you are on the same page.
"For clarity, can you please explain in your own words what I've just explained and let me know what actions you need to take?"
You can also summarize the conversation to double-check if both parties are aligned and have a shared understanding.
Gathering Context
Gathering context (in communication) is the process of actively seeking and acquiring relevant information in order to understand the intentions or messages of others. With good context-gathering skills, your communication becomes much more efficient because you can respond with relevant messages.
Let me provide you with a real-world example (which actually happened) of a situation where a software engineer was poor at gathering context.
Background Story:
- In the e-commerce industry, a product manager asks a junior software engineer to display transaction statuses on the website.
- In the database, there are already six transaction statuses: PENDING, VERIFYING, PROCESSING, DELIVERY, DONE, FAILED.
The conversation goes as follows:
Product Manager (PM): Hey JE, for our next project, we need to show transaction statuses in the user transaction history. Our users often inquire about the delivery status.
Junior Engineer (JE): So, I just need to display the 6 transaction statuses, right? Where exactly should I put them?
PM: Yes. You know, on the history page, below the total amount, there's a blank space. Just add a badge with the statuses inside it.
JE: Alright, I'll do it right away.
PM: How long will it take?
JE: Two days.
The product manager didn't create a requirement document because he believed it was just a matter of displaying the status, and other competitor companies have similar statuses implemented well. However, the result turned out to be far from what the product manager expected:
Of course, the product manager is not 100% right in this situation, but I want to focus on the software engineer instead of the product manager. Instances like this often occur where the engineer lacks domain knowledge and misunderstands, leading to a failure in grasping what the PM truly means and consequently working on incorrect requirements.
Note: The situation worsens when the engineer fails to gather any context and relies solely on assumptions.
So, here are some tips and techniques for gathering context to prevent occurrences like this.
Active Listening & Observation
Use this in situation: All situation
Engage in active listening by paying close attention to what others are saying (including small details). Focus on understanding their perspectives, concerns, and goals. Avoid interrupting and ask clarifying questions to ensure a thorough comprehension of the context being shared.
The purpose of active listening and observing your audience is to understand their main goal or point from the conversation. When you understand their goal or what they want, it becomes easier for you to respond effectively.
Breakdown the Discussion into Smaller Parts
Use this in situation: Have long & unstructured explanation
Often, when trying to gather context, you may receive long and unstructured explanations. In such situations, you need to intervene and structure the conversation. One suggestion is to break down the discussion into smaller parts. Here's an example:
S. Engineer (SE): Could you please explain the...
Product Manager (PM): So, the user flow starts with the user creating a loan request, and then the request will be curated by the superiors before...
SE: Sorry for interrupting, but let's focus on the first step, which is creating the loan request, before we proceed to the next discussion.
Breaking down the conversation into smaller parts allows for better focus when gathering context.
First Principle Thinking
Use this in situation: conversing with non-tech or geek engineers who use terms you don't understand and/or encounter ambiguity (something that makes you assuming things)
First principle thinking involves questioning every assumption you think you know about a given problem and creating new solutions from scratch. In first principle thinking, you question assumptions until they cannot be broken down any further.
In the example above, where the junior engineer built something that the PM didn't intend, there was ambiguity regarding the term "status". From the engineer's perspective, it referred to a status stored in the database, while in the PM's mind, it was about a status that the end user should understand. The problem arose because the engineer assumed the definition of "status" in technical terms.
In short, when you have any assumptions, clarify them right away. If there are terms you don't understand, ask until you gain a clear understanding.
Summarize & Explain the Result that Comes to Your Mind
Use this in situation: converse with non-tech individual and/or mentee
Similar to "asking for re-explanation" in providing context, summarizing and explaining the result helps ensure that your understanding aligns with the other party's.
"Hey, let me summarize today's discussion, and please correct me if I'm wrong..."
This approach serves as a double-check to prevent miscommunication and ensure that both parties are on the same page.
Grow Your Empathy
I have already provided you with some tips and techniques to improve your communication through providing and gathering context. However, there are many more techniques and tips beyond that. If you carefully examine them, you will there is a factor that serves as the foundation for the techniques I shared with you.
That factor is empathy.
Empathy is the ability to understand and share the feelings of others as if you were in their own shoes. All the techniques are related to the empathy, but it can be challenging to explain how to cultivate empathy. That's why I provided you with the techniques directly.
Let’s save about empathy in software engineering for another topics.
Conclusion
Effective communication is not a simple task. Throughout this article, I have provided you with tips and techniques to improve your communication skills. However, it is important to understand that communication is more than just exchanging information. Merely knowing about communication techniques does not automatically make you proficient in communication. It requires practice and consistent effort since communication skills are spontaneous and need daily practice. So, learn these skills, put them into practice, and you will undoubtedly become a better communicator.
Thank you for reading today's newsletter! If you find it valuable, don’t forget to: