Communication is empathy
When I was working at Automattic, we used to say “Communication is oxygen“.
I will communicate as much as possible, because it’s the oxygen of a distributed company.From the Automattic Creed
But as an inner joke among fellow Automatticians was: too much oxygen kills.
The importance of communication
Books have been written on this topic but as a kind reminder, I will just point out what is the most important aspect of good communication in my personal opinion, with a specific focus on software engineering.
Ready for the revelation?
Here it is:
The goal of good communication is to help our colleagues.
And in doing so, helping ourselves.
When we communicate with others about our progress, in fact, when we provide clear timelines and expectations, when we share our concerns and ideas, we put our colleagues in a better place because they can then:
- Report to their stakeholders.
- Know what is going on.
- Know what to expect.
- Make informed decisions.
- Contribute with their own opinions.
If you think the only goal is productivity and efficiency, you are missing one of the most important pieces:
The emotional aspect.
Historically, one of the feelings that drive people crazy is uncertainty.
The human society itself starts to fall apart when its components live through shaky times when the normality gets turned around; we are afraid of losing our jobs, our homes, our freedom, and everything we consider of fundamental importance.
Why is it so difficult?
Let’s keep in mind that we are explicitly talking about engineering here.
Here are some of the major obstacles I have experienced and observed to good communication within the engineering divisions, and between engineering and other departments.
People love it when they feel understood.
The thing with software engineering is, that we think and work on a very abstract level. We talk about algorithms, data structures, network packets, and lots of concepts that sound just alien to many other professionals.
This happens at all levels: happens when engineers commune with customer success, or when the CTO is the only engineer in a room and tries to explain what are the benefits of splitting the monolith into microservices. OK, perhaps this was not the best example, but I am sure you can think of better ones.
IQ vs EQ
Back in the early days of computer science, when computers were not as widely used as today – AKA before being a geek was cool – computer owners were considered nerds with poor social life.
Today, times have changed, but engineers tend to be smart people nonetheless.
And even if they are not the smartest in the room, their thoughts follow non-traditional patterns because of the nature of their jobs.
As a consequence, what is obvious to engineers is not obvious to the rest of the World.
I wish there would be a universal solution – I did not use the expression “silver bullet” on purpose, given the gloomy times we are living in – but the reality is, that communication must be exercised like any other discipline.
Following along the lines of what has been written so far, the first thing to do is
Let’s start with an easy example: what do you do when Customer Success submits a bug?
You are working on the next cool feature and you get bugged with a ticket that will require you to:
- Stop what you are doing.
- Investigate to understand what that’s about.
- Figure out a solution.
- Implement the solution, hoping it works.
Annoying, isn’t it? We have all been there, and it sucks. And sometimes you may have been tempted to postpone the task, especially in absence of clear SLA and SLOs.
But what if you try to change your perspective?
Think about this: your CS colleagues are under pressure from clients, constantly getting poked by impatient or even angry users asking for the most disparate things.
To make it worse, CS reps do not usually have much visibility of the systems and the software. They are sailing blind, kind of.
Here comes empathy. Now ask yourself:
How would you see yourself under such circumstances?
What would help you if you were in their shoes?
It is very likely that your answer includes at least some of the following elements:
- What is going on?
- What is the root cause?
- If the root cause is not clear, then an estimation on when it could become clear.
- If the ticket cannot be taken on in the next X hours/days, an estimate of when it will be looked at would be great.
- Once the root cause is clear, knowing what the plan for the fix is, and when the implementation can start.
- If any provided time expectation is not met, get prompt communication.
With the above information, you would feel in a much better spot.
You would feel safer.
And psychological safety is one of the most sought-after goods these days, especially in a fast-paced, high-pressure field like tech.
As already mentioned, we have only explored the tip of the iceberg about communication.
I always try to keep my posts short and to the point, in a world that is already full of content.
But if you like it, you can subscribe to this blog and will get more in the future.
And perhaps one day I will write a friendly guide to transition from engineering to management positions without losing the handle and losing the fun.