Communication for Engineers
A version of a talk I gave at Duolingo's internal Engineering Summit
Duolingo recently hosted its first “Engineering Summit,” which was a one-day event filled with talks given by our software engineers to benefit other software engineers at the company. I gave a 20 minute talk in the Career Development track about communication for software engineers. This is a slightly edited version of that talk to make it suitable for software engineers at any company.
![A view of the inside of PPG Paints Arena before the start of the Duolingo Engineering Summit. A view of the inside of PPG Paints Arena before the start of the Duolingo Engineering Summit.](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4ca7bb2e-fe6f-44ef-82db-90af26714895_640x480.jpeg)
Communication for Engineers
You’ve probably noticed that, while you are an engineer and we focused on technical skills in the hiring process, Duolingo has an entire pillar devoted to “communication and leadership” in the career ladder. Here are some of the things we expect from you.
Shares knowledge and best practices with other engineers outside their teams (e.g. teaches a Duolingo University course, gives Q&A or Assembly talks, gives talks in conferences, writes blog posts).
OK, this makes sense! I should be able to communicate with other engineers. I get that.
Can communicate about projects clearly to people of all backgrounds.
Huh. I need to communicate with anyone? That’s a little harder.
Gives great updates on their projects to anticipated stakeholders proactively, without needing prompting or instruction.
Wait a minute! I’m an introvert and pretty shy. I’m just supposed to talk to people without invitation now?
So yes, Duolingo expects engineers who can communicate well. Communicating well is hard for everyone, but there are some common misconceptions and roadblocks specific to engineering that I want to cover before I talk about specific tips to improve communication.
The Myth of the Solo Engineer
The first misconception is the myth of the solo engineer.
We celebrate the contributions of individuals to the field of computer science: Grace Hopper, Tim Berners-Lee, Linus Torvalds. Celebrating these individuals, it is easy to assume the most important work that happens in this industry is solitary. College reinforces this, since most of the work you do is on your own and earns an individual grade.
The reality is building software at scale isn’t just about people sitting alone and typing on keyboards; it has just as many scenes like this picture and they’re just as important to the project. Let me tell you the story behind this photo. It’s 23 years old, taken the day we released Windows XP to manufacturing. The people in this room called themselves the Windows War Team — you can see it on some of their shirts.
![1629331491219.jpg 1629331491219.jpg](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbc3c248e-5f64-44f2-97dc-703d868fc470_1333x1000.jpeg)
I don’t know if they were thinking of this scene from Dr. Strangelove when they picked the names “war team” and “war room,” but I’d like to think they did.
To explain the significance of the photo, I want to rewind two and a half years before the war team photo was taken. I was a new hire into the Windows NT division, which at that time had over 4,000 people trying to ship what was then called Windows NT 5.0. It was already years late when I started and showed no sign of ever shipping. A few months after I started, the company made a leadership change. I still remember receiving the email announcing it: One corporate vice president out, another corporate vice president and a project manager in. Because it was so many levels above me in the corporate hierarchy, I assumed it would make no difference. This is just the first of many things where I was very wrong in my career. Changing just two people in an organization of 4,000 lead to one of the most amazing transformations I’ve ever seen. The Windows team gained clarity and focus and delivered two of the most significant operating system releases in history in the span of 2.5 years: Windows 2000 and Windows XP.
Here’s the thing I want you to realize. There’s 99.95% overlap between the developers, testers, program managers, executives, and marketing personnel who worked on the dysfunctional team that didn’t know how to ship and the team that transformed the PC market of the 2000s. The basic work of specifying, developing, and testing the software did not change. What did change is how we communicated with other teams and how we made decisions.
Let’s go back to the war team photo. The war team brought leaders from every single team across all of Windows met once a day during the endgame of both Windows 2000 and Windows XP. The room was packed and it was probably a horribly expensive way to handle things — I shudder to think of the salaries paid for that roomful of people. But the War Room accomplished a few key things. First, if someone brought an issue to the War Room that needed a decision, then all of the key decision makers were already there. Decisions could be make quickly. Second, because there were representatives from all teams in Windows in the War Room, when decisions were made, it was a very effective means to make sure the information spread to where it needed to go. Changing the way the team communicated changed the way the team performed.
Now I’m not advocating that every software team should have a War Room; it was a specific solution for its time and place. But it was an important lesson for me early in my career about the importance of communication, which I summarize like this.
All problems worth solving require a team.
The natural state of any team is chaos and confusion.
The antidote to chaos and confusion is effective communication.
Even though this showed me communication was important, I still had another obstacle to overcome to be an effective team communicator myself: The myth of shameless self promotion.
The Myth of Shameless Self Promotion
Here are two things that are true about me that might be true about many of you, too:
I don’t like looking foolish so I don’t like sharing my half-baked plans.
It feels like shameless self-promotion to talk about the projects I’m working on and why they’re important. I’d much rather quietly work on things and just trust that the coolness of my work is self-evident.
Here’s a story of how these tendencies lead me astray. During the Windows XP release, I worked with a team on a new file system feature in Windows. Since the feature wasn’t part of the Windows XP release, it didn’t have anyone from the testing team working on it. I decided to fill the gap of “we don’t have testers” by writing a stress test suite for this new feature. I can tell you now that to this day, this is the most technically complicated and impressive piece of software I’ve worked on. But back then? Remember my two tendencies: I don’t want to share half-baked plans, and I’d rather just work on things and let the output speak for itself. Because of this, I worked on this in complete secrecy. For months. I was young, I didn’t have kids or much of a social life, so this is how I chose to spend my evenings and weekends. When it was done, I wrote up a document about it, sent it to the team, and waited for them to shower me with praise because what I worked on was obviously so amazing.
Instead, they reacted mostly with confusion. Where did this thing come from? When we were still working on getting the basic functionality correct, was a stress test really the best use of resources? How were we supposed to integrate this test into our team processes, anyway? The test eventually got incorporated into our way of working, but I made things much harder with how I approached it.
The way I’m telling the story now may make it seem obvious: Don’t work on something in secret for months and then spring it on people all at once. That’s bad communication. It makes me think of Dr. Strangelove again. For those who haven’t seen the movie, I’m about to spoil the end: To give themselves an edge in the Cold War, the Russians have built a Doomsday machine: A system that will respond to any nuclear attack automatically with overwhelming destructive force. The strategy here is once the United States realizes that there is no hope that human error, delay, or second thoughts to avoid retaliation for a nuclear strike, then the United States will be completely deterred from launching a strike. The problem? Nobody knows about the Doomsday machine, so it has zero value for deterrence.
I’ve realized the same is true, at a much smaller scale, for most things that engineers work on. It’s not enough to do the work; everyone else needs to know you’re doing the work so they can reflect that in their planning. I hope none of you have done something as extreme as my work-in-silence or as ill-conceived as the Doomsday machine. However, if you felt a tinge of recognition when I described my tendencies, there’s a good chance you’re closer to a Doomsday scenario than you’d like.
OK, we’ve talked about why communication is important and some engineering tendencies that might stand in your way. Now I want to cover some concrete tips for better communication.
Tip #1: Learn the Classic Style
I’ll admit this is a new one for me: The Classic Style is something I learned about when I was researching this talk and it nicely frames many of the things I wanted to talk about, so I’m going to do my best to explain it to you now. It directly applies to writing, and I’m going to talk a lot about writing here, but there are elements that are meaningful for all communication.
The heart of the classic style is its metaphor for what communication is. Before I came across the Classic Style, I defined communication as the process of getting an idea out of my head and into your head. This is true, but too general to be useful. The Classic Style’s metaphor isn’t as general but it’s more proscriptive. In the Classic Style, the heart of communication is some external truth.
My job is to direct your attention to that external truth. I want my prose to be as clear as a window to avoid distracting you from the truth I want you to notice; I want it to sound as natural as speaking. You, the reader, are just as intelligent as me. We are working collaboratively instead of combatively; I don’t have to stick in all sorts of qualifiers in my writing because you’re not going to try to pick it apart. It’s not a debate. You will recognize that truth I see once I can steer your vision to it.
In Classic Style, that’s what communication is about: Noticing things, and then helping others notice them, too.
The most useful thing about this metaphor, which applies to written and verbal communication, is it directs your attention to this key question: What’s the clear and simple truth that I want to direct your attention to? If I can identify that — and it often takes a lot of work to figure out what I’m trying to say — I’m at least halfway to writing something easy to understand.
Note what’s not important in the Classic Style: What was the journey I had to take to notice this truth? Classic Style says: leave that out. Are there falsehoods that distracted me from the truth? Leave those out too, especially if the reader is unlikely to think of them unless you point them out. Most of the things you’ll work on as an engineer have some kind of expected truth for you to communicate. Focus on those.
Here’s another reason why approaching things with the metaphor of the Classic Style is helpful: In a lot of technical and business communication, it can be helpful to include a summary at the top of your document. When you’ve found your clear and simple truth, you’ve found the contents of your summary.
Another tenet of the Classic Style is that writing should mirror speaking. This quote is from the book that defined Classic Style.
The idiom of classic style is the voice of conversation. The writer adopts the pose of a speaker of near-perfect efficiency whose sentences are the product of the voice rather than some instrument of writing… Classic style models itself on speech and can be read aloud properly the first time.
Writing doesn’t often sound like this. For example, this is a quote from Orwell’s Politics and the English Language:
Objective consideration of contemporary phenomena compels the conclusion that success or failure in competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account.
Nobody talks like this! Try to avoid writing like this. In this particular case, Orwell was giving an example of how bad writing can butcher good ideas. He had rewritten this passage from Ecclesiastes:
I returned and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.
This particular English translation is over 400 years old and it’s of a text that’s several thousand years old. Other than slipping in the word “happeneth” it sounds like something that could be spoken today. That is the ideal of the Classic style. One concrete tip you can take to improve your writing: Read it out loud. If you stumble over it, so will your readers.
Note as well that Classic style isn’t confined to talking about concrete observable things in the physical world. “Time and chance happens to all” is a pretty abstract truth, but appropriate use of metaphor and concrete imagery turns the abstract into something that can be seen with the mind’s eye. That’s important for us as engineers, since almost everything we work with is an abstraction. Spending time thinking of ways to make abstract ideas concrete in the mind’s eye will improve your communication.
Tip #2: Be a Good Listener
Here’s my #2 favorite trick for being a good communicator, and one I don’t see enough people talk about: Be a good listener.
Great listening is the foundation of great communication. When I’m trying to communicate with someone in-person — say, in a meeting — I spend as much or more mental energy listening to others and trying to understand their point of view as I do trying to convey my own point of view. If you’ve been in meetings with me, I hope you’ve noticed that I’m quiet a lot of the time, and that many times when I do talk what I’m doing is paraphrasing back what I’ve heard someone else say to make sure I’ve understood it correctly.
Listening well and carefully is one way to combat the curse of knowledge. The curse of knowledge means that once you understand something, you tend to forget how hard it was to gain that understanding, and you also over-estimate how much people understand. This blocks clear communication. Remember that in the classic style, communication is about directing your attention to some truth. If I don’t do that at the right level of detail, I can fail. That’s one reason why I spend so much time listening to others; it helps ground me in what they already understand, so I can skip detail, and where their understanding is a little shaky, so I should provide more detail.
For what it’s worth, good old-fashioned active listening improves your credibility and makes you a more persuasive communicator. I learned this doing high school debate. I was a successful debater not because I was particularly eloquent or had mastered classical logic and rhetoric. Instead, I had a template for arguing that my coach taught me and I used over and over because it worked so well: I listened to my opponents and make sure I understood their arguments, I would paraphrase back my opponents’ arguments to the judge, after paraphrasing I would point out some flaw in their argument, and then finally I would start talking about how my own arguments addressed these flaws. This worked because it showed the judge that I wasn’t trying to win by repeating the same points over and over, or by talking louder than my opponent, or by having the snappiest one-liners. I showed the judge that I understood my opponent’s arguments, and coming from that point of understanding I rejected those arguments. It made me credible and made it easier for judges to reject my opponents’ arguments as well.
Most opportunities for professional communication aren’t debates. Some are, though! Perhaps your team is trying to settle on a strategy or technical direction and is considering different approaches. If you find yourself in a debate, by all means try the “listen / paraphrase / point out flaw / present counterargument” template.
Tip #3: Use the Voice
My third tip applies only to verbal communication: Use the Voice. I’m so glad that the Dune movies were so popular because it gives me the perfect metaphor for something I want to cover next.
When my kids were younger, I spent a couple years helping coach their middle school speech team. Both my boys noticed that I had a different way of speaking when I was demonstrating things for the team than when I just talked to them, and they’re absolutely right. I’ve got my public speaking voice, and I’ve got my chat-around-the-dinner-table voice, and they’re not the same. My public speaking voice is louder. I’m a little bit more varied in tone and pacing. I pay more attention to enunciation. It’s not just my voice: My posture is different, I use more body language than I usually do. It doesn’t feel unnatural, like I’m acting, but it’s a different mode than I can switch on and off as needed.
So why do I use The Voice? For the same reason they use it in Dune: For primal and illogical reasons, it works. If I speak clearly and loudly, demands that you to pay attention to what I’m saying. If I seem confident about what I’m saying, then you’re going to give my thoughts more consideration.
I believe three things about The Voice.
It’s a valuable skill anyone can learn with practice.
There are more opportunities to practice it than you think. Yes, I’m standing on a stage now, but also every time I speak up in a meeting or give a status update in a standup, I’m using The Voice.
It’s a skill not everybody has today.
The first step in developing The Voice is cultivating deliberate practice. Find places to speak, such as status meetings, when you do speak be conscious of speaking loudly and projecting, and then get feedback from trusted peers about how it’s going. I’m happy to give other tips if you find me later.
Conclusion
A lot of what I’ve talked about here is simple, but this is a classic case of when simple does not mean easy. Given that none of us are mind readers, it’s amazing communication works at all. I want to leave you with this quote from George Bernard Shaw: “The single biggest problem in communication is the illusion that it has taken place.” Expect communication to be difficult. Expect it to take effort, and expect there will be the occasional miscommunication. Give yourself grace when that happens.
Finally, remember that communicating well is an acquired skill, not an innate gift, so it will improve with practice. As an engineer, you have lots of opportunities to practice!