An Engineer’s Guide to Communication

It’s far too easy to be misunderstood. Trying to get your idea or point across to someone can often feel frustrating and difficult.

You’re not wrong for feeling like you, or they, just don’t get it. It’s tempting to believe that maybe you were never meant to be a good communicator, let alone a public speaker, or an engineering lead. Worse, you may think poorly of someone because they can’t seem to understand what you’re trying to say.

Communication is inherently lossy. What you don’t say is as important as what you do say. How you say it can matter more than what you actually say. It’s even lossier in writing. Communication will likely never be lossless, until we can communicate telepathically, I suppose.

That doesn’t mean you shouldn’t try–I’ve been awkward and shy my whole life, and being a good communicator takes extra effort on my part. But it’s important that I try, even if it’ll never be perfect. Things don’t get better without effort.

“Computers are easy; people are hard”

As an industry, we solve problems with technology. That’s what we were hired to do. The mistake is that we tend to also see communication and people issues as problems we can solve with technology. I’ve been personally guilty of this on more than one occasion.

Why should we learn how to communicate better? It’s because more often than not, software problems tend to be people problems.

My favorite talk from last year, by Bridget Kromhout

It’s easy to believe that, if only we used containers, microservices, serverless, or nocode–that just by using this new technology, we will solve all our problems. Take microservices, for example.

Netflix is famous for supposedly “writing the book” on microservices. You might be forgiven to think that Netflix is successful because we have a microservice architecture. And that if you use it too, you could be as successful.

No. There are no silver bullets. There may never be one in our industry. If you’re not at Netflix’s size, microservices won’t help you, they will in fact slow you down with added complexity. Microservices are not a technical solution. They’re an organizational optimization. They are a way to allow teams to operate at scale, only if they are communicating effectively first.

Listen first, understand second, speak last

To communicate effectively, I practice a simple rule. When I speak with others, I seek to listen first, understand second, and speak last.

When I listen first, I give others a chance to be heard. Everyone wants to be heard.

When I ask questions, I understand what they mean, where they’re coming from, and why they have the opinions that they have.

I speak last, because I get the benefit of hearing everyone’s opinion before I volunteer my own.

When you go to your next team meeting, give it a try. Don’t say the first thing that comes to your mind. You’ll get your turn.

In Netflix’s high trust culture, if we need to make a decision, one of us acts as the informed captain. In a team built on trust, we don’t wait for consensus. We disagree, and we commit. When the captain of any particular decision is reasonably confident of the right bet for us to take, they decide and we take that bet. But to gain commitment, it’s important to listen and understand first.

Communicating non-violently

I have strong opinions about software. You may have them too. Some of us may even feel that not knowing about the link tag (and a laundry list of other things) makes you unworthy of our craft.

It’s fine to have strong opinions and judgments. If you want to communicate with someone though, if you want them to see what you see, you should seek to communicate non-violently. If “violent” means acting in ways that result in hurt or harm, than much of how we communicate could be called violent communication.

When we lead with our judgments–discriminating, speaking without listening, judging who belongs “in our craft” and who doesn’t–people close up to you. You’ll never be able to let them see what you see, or think what you think, if you don’t take the time to understand what they see or think first. Have a little empathy.

If you’re right, all the better, because they’re more likely to accept what you say. It’s a simple framework.

• Observation — facts and data without judgement or evaluation
• Feeling — state how you feel
• Need — state your need underlying this feeling
• Request — a specific action to address said need

The most important part to me is in taking a step back to understand why I feel or judge something a certain way. The leap from observation to judgement happens very quickly. We might observe that someone on your team submits code without writing any tests. That’s fine. The issue is in quickly adding your judgement that they have no respect for the team.

Both of you would agree that they don’t write tests in their pull requests. It’s an objective fact. But before you rush to pass judgment, you should give them a chance to explain.

You could say something like: “When you submit a pull request without tests, it makes me feel worried that we’re introducing regressions.” This gives the person space and opportunity to provide new information. They might say, “I’m sorry, I’m unfamiliar with the testing framework, there was no documentation and I was afraid of asking.” You wouldn’t have known that if you didn’t ask. Now, you’ve uncovered an important issue and can work to solve it together.

Communicating well will make you a better engineer, and a better person. It’s certainly not easy. But it’s important that you try, even if it’ll never be perfect. Things don’t get better without effort.

Thanks to Zach Wentz for reviewing and for sharing “non-violent communication” with me.

Written by Lauren Tan who lives and works in the Bay Area building useful things. You should follow her on Twitter