How to Communicate With Empathy
Lesson Learnt and Framework to Adopt Effective Communication
Have you ever been in a room where various stakeholders seem to be talking to each other, but no one understands what is going on?
I have.
I was pulled into a Site Incident where I needed to discuss and troubleshoot the root cause of the problem.
It was a large system that we needed to troubleshoot, so there were various stakeholders involved.
Analyst, product, and the teams.
The analysts talked about the data they saw and asked engineers why such data occurred. Engineers use their "programming language" to explain to the analyst how the system operates and why it behaves that way. Meanwhile, the product interrupts them and asks about the impact of this incident.
They are all troubleshooting the same system in a different language.
A lot of the time, being a great communicator is a force multiplier because you are communicating something that can be understood by any people who have access to that documentation at any time.
Knowing how to communicate effectively helps speed up your deliverables and development process tenfold.
What is it mean by great communication?
Know What to Say
I spend most of my early career learning about explaining.
We spend most of our time growing our coding and system design skills so that we know how to present the right trade-off and come up with the best solution.
The next level of projecting your ideas with influence after providing facts and trade-offs is tailoring your answers to the audience you are speaking to.
This is about the content of the message itself.
Knowing the person you are talking to is key to projecting the correct message in their head. The reason is that the words we speak are packed with many emotions and experiences associated with memories, meanings, and images.
For instance, when someone discusses an error when a customer is trying to purchase something, that idea of error handling can be the representation of many perspectives and depths of the semantic networks.
For a program manager, an error in payment processing brings a negative connotation to their mind.
They may associate errors with a drop in conversion rate and a decrease in revenue.
They think that the error in payment processing has something to do with the faults in our system - there is a bug somewhere that hasn't been discovered yet.
For engineers, an error in payment processing is a misunderstanding of the system's assumptions.
It doesn't necessarily mean it is "bad" and that the engineer has more nuance as to "Why" the customers failed to go through the payment flow.
We have started to think more deeply into the analytical side as to whether this comes mostly from our system or from our third-party payment providers. Then, we start to go even deeper into what these error types are, etc.
Combining all these various elements creates the language of the mind, which forms our semantic network.
Our job is to distill these elements from our semantic network and transform them into a low bandwidth mechanism that is the spoken words. Our listeners receive those words and unfold them into experience, emotions, and clarity based on their semantic network.
Being able to project what to say is to attempt to send the necessary message to the other person so that we have the same alignment of the depth of the semantic network.
Clarity is More Important Than Precision
Clarity in communication saves time and resources.
Elon Musk said that it is more important for your audience to understand the concepts or instructions you are conveying instead of every detail of that technicality.
This is focusing on "How to say".
It is about conveying your message in a straightforward, understandable manner and ensuring that all the terminology, language, and explanations are digestible to anyone, regardless of their technical background.
This helps in facilitating a more informed and faster decision-making process.
Precision is important as well. However, it can obscure the bigger picture or essential decision points if the details become too dense for the audience to navigate.
Avoid jargon or technical complexities unless they add value to the listener.
For instance, if you received an email from your manager requesting additional resources for your project, outlining the situation, the resources needed, and the expected outcomes. The clarity lies in how you present your case, ensuring your request is understood without ambiguity.
This ties back to back with whom you are talking. However, even speaking with engineers and projecting your points, why, and how helps create clarity in your communication.
Engage in Active Listening
The best communicators are the ones who listen. Understanding and sharing the feelings of others while fully concentrating on what is being said to you helps build reciprocity and trust.
Active listening helps enhance your problem-solving skills by understanding the nuances of what is being communicated by your stakeholders. It also clarifies additional ambiguities that you and your stakeholders have so that you can reach the desired conclusion.
Sometimes, you forget what it's like to be a beginner again because you have been acclimating to that domain for a long time. We often speak the language calmly and have the assumption that our audience has the same semantic understanding of the context. You face the challenge of sharing your logic with everyone on the team. The bigger that knowledge gap and the more people involved, the more challenging it is to share your knowledge effectively.
With Active Listening, you can adapt your message to their feedback, which bridges the knowledge gap between all parties.
One tip I use to showcase active listening is re-entering or paraphrasing their points to confirm my understanding of their statement. It demonstrates that I value their input and am engaged in finding a solution.
Tips on How to Communicate with Empathy
Semantic Tree Traversal Way of Explaining Concepts
If you haven't deployed, your change and the product are asking you what the status of this change is.
When your brain decrypts these words, it starts retrieving the most appropriate semantic tree to that question and decoding it into words.
The root of this tree will be something like, "The change is not yet deployed."
This is the most fundamental part of answering this question.
The answer is not helpful, but it addresses the questions.
Our mind usually will start to unfold multiple traversal layers through the branches of the tree by automatically thinking about all the possible scenarios of what the next questions will occur once we respond.
"The change is not yet deployed."
"Why is the change not yet deployed."
"Because it is blocked by John."
"Why is it blocked by John."
"Because he wasn't happy with this one code change in the PR."
Our brain is phenomenal in construing questions and perceptions in a split second. With an addition of obviating awkward pauses, we start saying something like this:
"The change is not yet deployed because it is blocked by John. He wasn't happy about the code changes in the PR because ….."
Before we even realize it, we have been too deep in the trenches.
That program manager may only need one or two level information nodes from the root, but we gave them ten levels deep.
The fundamental revelation in this tree traversal way of explaining things is to start with the most basic and high-level semantic context before exploring those points further.
The highest level of semantic context on the tree is the root. The root will be vague, broad, and high-level - leaving out many important or unnecessary details based on the audience receiving that message. Many people will want more information after you present them with the root. However, when you tell them in the semantic context of the root, anyone inside or outside the team can understand them.
Then, you can start expanding down the branches of that semantic tree as you see someone ask more clarifying questions.
This is how my brain works each time I try to explain technical problems or justify extending a project deadline by:
Start Broad: explain in high-level overviews that anyone can understand and set the stage for deeper conversation.
Ask for feedback: check in with your audience, pause and let them think, and use your body language skills to see if they need more detailed information before proceeding to more complex details.
Adjust Based on Audience: adjust your explanation by zooming out with a simpler explanation or go deeper into the technicalities if there's interest and understanding.
Let's think about some examples of implementing this tree traversal in explaining things:
Explaining to the Program Manager a Higher Level of Effort to Integrate a new Payment Method
Imagine that the program manager wants to onboard an alternative payment method (APM), such as Apple Pay, into the current system, which only accepts credit cards.
Begin with the new payment method, a novel integration that hasn't yet been implemented in the current system. Therefore, the initial implementation will take considerable time to initiate.
Then pause.
At this point, the program manager usually sides with "how" or "why" questions - which means a justification to explore the first level of details.
"The initial implementation will take considerable time because 1) Research on which third-party payment provider is suitable to integrate with our system. 2) gather information on the new payment method API, and it needs to adapt our system with this API."
Now, we have more information regarding "why" it takes considerable time. At this point, the message is transmitted into their system, they decode it to the semantic context they understand, and they agree it needs to take a lot of time.
What if they don't?
They will either challenge your statement or ask further clarifying questions.
Now, we can go even deeper into the more specifics to illustrate "why" it takes a long time to do by giving a couple of examples, such as "Aligning API takes a long time because we need to ensure:
data encryption and security
understand and design the system in a way that is reliable under different scenarios
understanding compliance and financial regulations for this new APM to our target market
With all these reasons, it requires careful review and adjustments."
This can go deeper again into the "technical" stuff by having to explore various failure scenarios that will occur with this new payment method and have to translate those new failure scenarios with our existing system. Also, the idempotency key occurs…etc.
However, at this point, if they agree with your explanation, then it can just stop there.
Explaining Customer Double Charging Issue during a Site Incident
In this scenario, all stakeholders (engineer, product manager, and manager) are pulled into a war channel to troubleshoot and understand the underlying cause of the double charge. You know the underlying root cause and will need to explain the root cause and remediate steps to all stakeholders in that room.
Begin with a simple statement that a flaw in the transaction processing flow led to a double charge. This tree's root states the stage to all stakeholders without assuming technical knowledge.
Traverse the first level of details. Explain that the issue originated from a bug in the code responsible for handling transaction failures. Instead of marking the transaction as failed, the system retried the transaction, which led to a double charge. This has impacted X amount of users being double charged.
At this level of specificity, the high-level management and the program manager understand the high-level root cause of the problem and its impact.
For engineers from the direct team or technical stakeholders who want more depth - start delving into how the retry logic was mistakenly triggered due to the misinterpretation of payment gateway responses and how the concurrent transactions were adequately managed.
If you imagine being in the war room, the first and second-level stakeholder would have left the room right now and prepared the next steps in their report. The ones who stay in the war room are the ones who want clarification and a deeper level of understanding.
Explaining Tech Debt
This is more nuanced. It is more convincing other people of "Why" this technical debt needs to be addressed.
However, the tree traversal method still holds.
Start by setting the stage.
"We currently have just one monolith codebase in X repo that we want to transform into microservice for better troubleshooting and fast iteration."
Then, if further questions are asked, especially why, explain the conflict of the narrative and focus on the benefit and outcome of the new idea.
"As our team grew and wanted to adopt multi-tenant infrastructure, working new X payment method requires 2 engineers and 1 sprint. Adopting microservices will still reduce the number of errors and save time. Now, instead of 2 engineers, we only need 1 engineer, and it can be done in a couple of days. Instead of weeks."
Now, if the stakeholders see the value of the technology in terms they understand, things can stop here before explaining deeper down "what" exactly causes such a problem in the long run.
Getting To Know the Person You will be Talking to
The more that we learn about the other person's background and motivation, the easier it is to give them the necessary information. Too little information frustrates them, and too much information confuses them. Therefore, here are some checklists before you explain and provide information to a stakeholder.
How much context does this person have?
You can determine this by how much time they dedicate to the domain.
What does this person care about?
People care about different things. Some people care more about getting things done first. Some people care about building a system for the long run. Some people care about avoiding duplication and DRYing (Do not Repeat Yourself ) things.
What is this person's background?
What's the person's past experience? What's the scale and kind of problems they used to solve? What's their old way of doing things? What did they get bitten by? Understanding the person's background helps you understand where they are coming from. The better you understand that, the easier it is for you to address their concerns.
Is the person the decision maker? Who else do you need to talk to?
If the person is new to the domain, they might feel uncomfortable making decisions. If that's the case, think about who these people this person might consult with and consider if you should get on the same page with those people as well.
Cater Information for Them by Active Listening
At the end of the day, everyone desires to be heard. If people feel like they are not being heard, they will focus more on expressing their thoughts than listening to what you say. Therefore, it's important to listen attentively to what people say and ensure they feel heard before expressing your views. Understanding the perspective of others and the reasoning behind their proposals is crucial. If you pay attention to their point of view, they will be more likely to pay attention to yours. The goal is to foster a discussion where everyone feels comfortable participating rather than being lectured.
Deliberate Practice Helps You Communicate with Empathy
The more you deliberately practice these methods, the more natural you will become.
I needed to pause a bit further - telling the other party to give me time to think. Construct those thoughts on a piece of paper and project them.
Each time when I fumble during a meeting and realize that my explanation didn't go as smoothly as I thought, I self-analyze my interaction after that meeting and give some retrospective on myself to do better the next time.
I also noticed some of the more well-spoken colleagues in the team and asked them for tips and advice on how their mind works.
Overall, communicating well is continuously learning about the craft by observing and experimenting with how the other party reacts and being humble in asking for feedback afterward.
I hope you learn some tips from this article! Communication is a science, but it is also an art. I still have a long way to go to learn to be a great communicator. What about you? I would love to hear about your experience and thoughts!