In college, I assumed that success in software engineering came from technical skills—that superstar programmers were those that could write the fastest/best/most code. But after entering the industry, I realized that smart software engineers are a dime a dozen. What sets engineers apart isn’t technical ability but communication skills.
Communication is important because software engineers operate within a team and business. You can’t just build what’s beautiful; you need to build what’s right for your company. If your project is falling behind schedule, you need to be able to communicate what’s blocking you to potentially non-technical teammates. And of course, you need to establish rapport with your coworkers.
No set of tips can make somebody a good communicator—it’s a skill that requires dedicated practice. I’m hoping, however, that the tips I’ve included below can help. I’ve collected them in my years as a software engineer and engineering manager. They’re generally organized by communication medium. Some of these tips apply to organizations and others to individuals, though most apply to both.
First up, some general communication tips:
- Assume positive intent. With non-in-person communication in particular, it’s all too easy to negatively misread someone’s tone or intent. Instead, you should assume the best of your communication partner—you’ll find that your work relationships meaningfully improve!
- Be empathetic. Your coworkers, just like you, are trying their best! Answer their questions patiently and promptly.
- If you find yourself getting irritated or angry, remember 1) and 2). If you can, take a few minutes to calm yourself.
- As a senior employee, your communication style becomes especially important: you’re a role model for the rest of your organization. Hold yourself to a higher standard.
- It’s better to over-communicate than under-communicate.
- State your assumptions going in to a conversation. Sometimes, you’ll find that you’re thinking about something completely differently than your conversation partner!
- Don’t be afraid to ask questions if you don’t understand something. If you’re in a meeting, ask right away. If you’re working on something, investigate it yourself for 20 minutes first. This way, you’re not wasting someone else’s time if the answer is trivial, and you’re not wasting your own time by banging your head against the wall. Preet Bharara makes this point much more eloquently than me:
“Asking questions as a junior person leads to deeper understanding. Asking questions as a leader does the same, plus it creates, one hopes, a climate of curiosity and self-reflection, for individuals and for the institution as a whole. And it fosters a culture of thoughtfulness, curiosity, critical thinking, understanding, and challenge, rather than rote acceptance of the status quo. Because that acceptance is how the mighty fall.”
— Preet Bharara, Doing Justice
- A great way to establish that you’ve heard your conversation partner is by restating what they said to you. You may realize that you didn’t have as much understanding as you thought!
- When communicating something important, prefer, in order, a face-to-face chat, a video call, or a phone call. If at all possible, don’t have important conversations over email or Slack.
- Corollary: don’t be afraid to go up a communication level (Slack to phone, phone to video) if the conversation becomes important.
- If you’re messaging or emailing somebody during their off hours and don’t need an immediate response, preface it with “NOT URGENT”. Alternatively, you can schedule Slack messages or emails to be sent at some point in the future.
- When you’re in the office, establish a rule for when you are willing to be disturbed or when you’re in a flow. For example, my coworkers know to not to ask me for advice or make small talk if my headphones are on (which is pretty rare!)
- Use simple words when you can. The goal of communication is to share your ideas, not to show off your SAT vocabulary score.
- Avoid long, complex sentences. If your sentences have multiple commas or dashes, break it up!
Meetings & Calendar
- Meetings need a leader to be effective. Usually, this is the person who called the meeting.
- Meeting also need a well-defined purpose. Some example purposes: “decide which security vendor to go with”, “brainstorm ways to reduce latency”, “share context about a project”.
- A great way to add value to meetings is to take notes and post them after the meeting is over.
- Be reliable—attend the meetings you say you’ll attend.
- If you think a meeting isn’t going to be useful, talk to the meeting owner beforehand. You may be right!
- Make sure to schedule some time in between meetings so you have a chance to get water, use the restroom, or just collect yourself for the next meeting. Google Calendar’s Speedy Meetings setting is great for this—just make sure that you stick to those end times!
- When scheduling a 1:1, put the person you’re talking to first in the calendar invite. Order effects matter!
- Share your personal calendar with your work calendar service. This way, you won’t need to duplicate events to avoid double-booking work and personal events.
- If you use Zoom and Google Calendar, the Zoom for GSuite add-on lets you easily add Zoom calls to your meetings.
- Use Calendly instead of playing availability tag with partners.
- If you must schedule a meeting over email, always include your timezone when sending availability.
- Body language is important, so make sure your webcam shows at least your torso (and make sure your webcam is on during video meetings).
- Turn video on by default in your host settings.
- Corollary: in your Zoom settings, make sure “Always show video preview dialog when joining a video meeting” is turned on.
- Get your video and audio right! Probably millions of man-hours have been wasted on audiovisual Zoom issues. Don’t make that problem worse.
- Consider a virtual background, especially if your room is messy.
- Zoom only lets you host two concurrent meetings. I’ve run into this issue when scheduling simultaneous interviews. One workaround is to have dummy Zoom accounts and admin privileges, so that you can schedule meetings on those accounts.
- For meetings with external partners, turn on the waiting room. This way you can let people into your meeting only when you’re ready.
- Keep yourself muted unless you have something to say. Nobody wants to hear your neighbor’s dog barking in the background.
- Unclack mutes your microphone when you’re typing. This is especially helpful if you have a mechanical keyboard and like to take notes during meetings.
- Respond promptly to emails that don’t take thought (a decent benchmark is “Can I send this email in two minutes or less?”).
- Each email in your inbox should represent a todo item.
- Corollary: if an email sits in your inbox more than a few days, reply to the sender saying that you’ll get back to them in X more days. Leave it in your inbox until it is done.
- Never delete emails. You never know when you’ll need to dig back into your history!
- Gmail lets you undo email sends for between 5 and 30 seconds after sending. Make sure yours is set to 30 seconds.
- Let’s say that Alice intros you to Bob over email. If you respond first, preface your email with something like “Thanks, Alice! Moving you to BCC. Bob, great to meet you! …”, and move Alice to BCC. This way Alice knows that the conversation is continuing without keeping them in the entire email chain.
- When emailing external partners, be professional and polite. Use complete sentences and proper grammar.
- Set up shared inboxes via Google Groups for shared responsibilities. For example, set up
firstname.lastname@example.org inbound engineering issues like bug reports.
- Prefer to communicate in public channels over DMs, especially when asking or answering questions. Chances are somebody else is interested too!
- Use emoji reactions instead of littering the channel with “+1” or “I think this too”
- Teams may find it useful to have two channels: one public-facing channel for inbound questions and outbound announcements and one channel for internal discussion. For example, an engineering team may have
#engineering-private(at Ladder, the convention is that channels suffixed with
-are private, e.g.
- In noisy channels, prefer to have a single top-level message per topic with discussion in a thread. This helps avoid the problem of concurrent conversations happening in the same channel.
- Human-generated and bot-generated messages belong in separate channels. For example, a devops team may have
#alertsfor automatic alerts and
#dev-ops-chatfor discussing those alerts.
- When you have DMs or channels you want to follow up on later, start any message (I like a single period) so Slack keeps track of a draft. Now, you have a list of channels to respond to that you can groom when you are free.
- Mute channels liberally, especially big channels like
- If you’re a Slack admin, consider disabling
- Regularly declare Slack bankruptcy and mark all your messages as read with
- Corollary: Only show unread channels and DMs in the Slack sidebar. Out of sight, out of mind.
- Corollary: star your most important channels. For me, those are
#dev-ops-chat, my team channel, a channel for my reports, a channel with my boss and his reports, and
- When you’re out of the office, add it to your Slack status.
- Use the Google Calendar Slack integration so that your coworkers can see when you’re in a meeting (and whether or not to expect a quick response from you).
- Slack usergroups are great for rotating and group responsibilities. At Ladder, we have a cronjob that sets
@oncallto the current oncall engineer.
- Don’t draft long messages, especially those that mention many people, in the channel you’re posting in. Instead, write it to yourself or to Slackbot first.
- Pair programming is a great way to share context. Although Slack and Zoom screen sharing are often sufficient, Screen is another promising tool that lets viewers take control of the shared screen.
- I’ll occasionally spend an hour watching a newer engineer program in silence—I’ve found this especially effective for sharing potential workflow improvements.
- Establish code review guidelines and shorthand. In particular, it should be clear when a comment is blocking or not. At Ladder, we use the golf emoji (⛳) to signify a non-blocking comment. This repo suggests a more robust set of emoji.
- When dealing with production issues that warrant multiple people investigating, get in the same room or videochat. Assign one person to write down everything that’s happening. Don’t forget to keep stakeholders in the loop about the situation!
- Analogies are a great way to communicate technical concepts to non-technical coworkers. Avoid jargon at all costs.
- Concretize hypothetical examples with names and dates—it’ll make the example easier to understand. For example, instead of saying “How should we handle the case when a Foo has a Bar and then a Baz”, you could say “What should we do when Alice gets a Foo with a Bar on 12/30, then updates to a Baz on 1/1”.