Git gud at communication

Communication skills will make or break your product development process. But communication is hard. It’s hard with 2 people, and its difficulty grows exponentially as you scale. You have to practice and hone it like any other skill. And it is as important as any “hard skill” you have in your arsenal. If you dismiss communication as an unnecessary “soft skill,” you do so at your own peril. If you assume, “I talk, therefore I communicate,” you're fooling yourself.

Bear with me for a brief, ridiculous thought experiment. Imagine your team and customers have telepathic powers:

You would know:

• The priorities that should shape your work
• Everyone's expectations and assumptions about your next project
• What customers need

Your boss and colleagues would know:

• Why you're blocked
• Why tech debt matters
• Your feedback, concerns, and opinion of the roadmap

Sales and customers would know:

• Why your team considers some projects low priority
• When new features are coming
• What features are already available, and how to use them

Product Managers, Agile, and other product development processes solve communication problems. If everyone had telepathic powers, those problems would shrink or disappear. The next best thing to telepathy is a team who excels at communication. If your team communicates to bridge these knowledge gaps, your need for PMs and Agile will shrink.

Being an excellent communicator is also a way to stand out among programmers. Don’t tell anyone I said this, because it’s kind of mean. But the bar for communication skills for developers is low.

I received feedback from our CEO that she didn't understand my new project. We had spent months working on something that she didn't understand or agree with. In the absence of good communication, assumptions fester like mold in a damp basement. Months into building this feature, we needed to rip out and replace some of our foundations.

This was a big problem, and it was all because I hadn't communicated. I like talking. I like writing documents. I wrote an extensive 20 page document that contained every detail about the project. Over Zoom calls I outlined the project in long verbal descriptions. Since I said a lot, I thought I had communicated a lot. But talk is not communication. Extensive documents are not communication either. I said everything to everyone all at once, and communicated nothin’ to no one.

Communication is the transmission of information to a recipient. It's like a completed pass in football. If the receiver doesn't catch and carry what the passer threw to them, that's just some guy throwing balls. If your audience doesn't understand and internalize what you're saying, that's not communication. Communicating in the wrong time / place / medium is as useful as not communicating at all.

I got better at this because I got a ton of feedback. Here are the main tips I learned from this feedback on my communication:

Your CEO needs the bullet points. Customers and sales teams need mockups and prototypes. Developers need detailed technical requirements. Consider your audience, how much information they need, and the easiest medium for them to consume it.

When someone tells you something, take a moment to repeat it back to them in your own words, and make sure you got it. When you are the receiver, double check that what you heard is what the communicator intended to say. This works wonders, especially during conflict or disagreement.

Feedback is one of the most useful and difficult forms of communication. Oftentimes people won’t give you feedback unless you ask for it. So ask! Ask for feedback on everything always. But on this specific topic, spend 15 minutes with each of your main colleagues and ask them:

• Do you know what you need to know about what I’m working on?
• If not, how can we fix that? What do you need to know, and how can I make that information available to you? What medium do you prefer for this info?
• Last week when I explained __ problem to you, did it make sense? Could I have made that easier for you?

This is a fundamental part of the equation. Remember, you're throwing them the football and you're both failing if they don't catch it. Check in. Ask them if it's working. Figure out how you can do better. This will make you better at your job, and it will also make them love you.

People hate reading. People usually aren't listening during meetings. Show people what you mean. Don't describe a bug, record a screencast demonstrating the bug. Make an ugly little mockup of your new feature to show how it works. Verbal / Written descriptions of new features are hard to conceptualize. But a clickable prototype is worth 1,000 words (and it's easy for your audience to understand fast). If you can say what you need to say with a chart rather than a long Slack message, do that.

When you don't understand something, ask stupid questions until you understand. You're smart, and there's a good chance that others don't understand either. (Politely) requesting clear communication improves things for everyone.

It is easy to send bad Slack messages / emails. A bad message is long, unstructured, and difficult to reply to. Take an extra minute to make your messages easy to read and easy to reply to. Here's how:

• Put action items up top. If you're asking a specific set of people to reply to a specific question, say so at the very top of the message.
• If your message is long, write a TL;DR version in bold.
• If you're asking to set up time for a meeting, list a few options and let them choose.
• For a long complex message, provide it in a few forms. For example: "Here's the TL;DR version. Below is a detailed outline of the decision I want your feedback on. I also recorded a quick screencast to show you what I mean if you're tired of reading. Here's the link."

My old employer used to have everyone create a “user guide.” It's a user manual for how to interact with us. Here’s mine:

• I respond well to direct feedback. I do not like the ambiguity of “reading between the lines.” Tell me exactly what you need from me, and you'll get it.
• I’m a verbal processor. If our conversation requires significant back and forth, I prefer to get on a quick call.
• For project management or complex decisions, let's make a collaborative document. I do my best thinking in long form writing.

Write this up for yourself. What medium of communication do you prefer? When are you online? What’s your tolerance for meetings versus long slack messages? Share this with your team.

Also, ask them for theirs! Meet them where they are and do them the honor of communicating in a medium that works for them.