How to Improve your Communication 📣
How to present your ideas effectively, and how to use empathy for good.
A while ago we conducted a comprehensive survey about engineering careers.
It provided many insights, one of which is that people believe non-technical skills are crucial for advancing their careers — even more so than technical ones like coding or system design.
In fact, three out of the top four skills that people want to improve are non-technical.
While I have covered management many times, I never really wrote about how to improve your own communication. Over time, though, I collected a ton of notes on this, by reflecting on what helped me during my career, and by speaking with some truly excellent communicators.
So, this week I compiled all of this into an article that covers the two angles that are the most relevant to me:
🏗️ Structure — how to deliver information in an effective way. I will cover proven frameworks, examples, and mental models that can help you with that.
❤️ Empathy — how to focus on what needs to be heard, rather than what needs to be said. How to communicate in a way that is trustworthy and non-violent.
I will include practical advice about situations you may encounter at work, as well as plenty of additional resources to learn more.
Let’s dive in!
⚖️ Structure and Empathy
Communication is such a wide topic that I won’t pretend to cover it all.
This article focuses on structure and empathy, which is not the only possible angle, but to me it is one of the most useful.
In fact, throughout my career, I have often encountered engineers whose growth and impact were limited by one of these two factors.
Years ago, I worked with a brilliant DevOps engineer who had great tech chops and was capable of breaking down complex ideas perfectly to a non-technical audience. However, he was also rather disagreeable. He took criticism personally and mostly cared about being right. As a result, his good ideas were met with growing skepticism, and people avoided working with him. Eventually, we parted ways, and I suspect he never truly understood why.
Similarly, I know empathetic and trustworthy people who are capable of doing great work, but they struggle to promote it effectively to PMs or executives, due to a language barrier that neither party is able to overcome.
Let’s try to fix both scenarios, starting with the latter 👇
🗣️ The Language Barrier
Building products in tech requires a variety of specialized skills and roles. Engineers are radically different from designers, who are different from PMs and executives.
These people just speak different languages — and they do because they ultimately care about different things.
So, the language clash is most often a goals clash.
🎯 Understanding the What
In many situations, at work, we communicate with others to achieve some goals. We may want a peer to approve our design, an executive to give buy-in on a project, or a PM to green light some estimates.
In these situations, we often focus on our own agenda, while it is helpful to reflect on what the other party wants to achieve. In many cases, their agenda is different, or they do not care about the same stuff as us.
It’s hugely helpful to first think about the key points your audience needs to hear and understand, and then spin your narrative around that. Natural human tendency, unfortunately, is quite the opposite: We start thinking about what we want to tell.
— Corvin Deboeser, Senior Data Scientist
We can be dramatically more successful by delivering information in a way that helps the other party meet their goals, rather than only focusing on our own.
Let’s make a couple of examples:
1) Example 1 — Design trade-offs
Let’s say that, as an engineer, you are presenting the trade-offs between two designs to a PM. You want to build the best technical solution possible, which also repays some debt from the past.
The PM, on the contrary, cares more about velocity and shipping the feature as soon as possible to customers.
A good delivery of your proposal may take this into account and highlight the practical ways in which the better design helps your velocity down the line.
So, here are three ways of presenting the same thing, with increasing effectiveness:
🟠 Okay — this is a better design that will probably take a couple of days more, but it will repay some technical debt.
🟡 Better — this is a better design that will probably take a couple of days more, but it will allow us to cut the time we spend on maintaining this other thing.
🟢 Best — this is a better design that will probably take a couple of days more, but it will allow us to cut the time we spend on maintaining this other thing. Last quarter only we spent 5 days doing that totally useless work, and it’s only going to get worse over time.
By being specific and quantifying the time you are spending on maintenance, you 1) demonstrate care and thoroughness, and 2) speak to the PM’s own worries.
2) Example 2 — Executive buy-in
As an EM you are presenting a piece of roadmap to an executive, to get buy-in. You present reasonable but rough estimates. Many requirements are not clear yet — so you want to make sure you have enough time to build things right, and that you don’t create false expectations by committing on tight timelines when the stuff is still nebulous.