How does your organization communicate?

One of the most important things you need to figure out as an engineering leader is how your team should communicate with one another. It was important before the pandemic, but is absolutely critical in the work-from-anywhere era we're now living in.

While every organization is different, and will therefore require a philosophy that fits each team's particular needs, I thought I would share some of the general rules of thumb I recommend for the organizations I work in.

1. Use ubiquitous language.

Eric Evans coined the term ubiquitous language in his classic book on designing software, Domain Driven Design (I highly recommend having it on your bookshelf), and the concept remains one of the most important in my day-to-day work.

Essentially you want to have shared definitions of all business concepts across all parts of your organization (both inside and outside engineering), so that you can cut down on basic miscommunications that are the source of a surprising amount of wasted engineering effort.

2. Use different communications channels for different things.

Where do you document your processes?

Where do you ask clarifying questions?

Where do you share meeting notes and decisions?

There's not one right answer (though I have my personal opinions), but you should have an answer. A cumulative time waster is having to randomly search through multiple different repositories of information (e.g. Slack, Confluence, Gitbook, READMEs, emails). Your team will save itself time if they know that each communication channel you use will be used for a specific purpose.

3. Write things down.

This is especially important if you work in a remote-first organization (as most of us in software engineering do now). It is the most scalable way of sharing knowledge across an organization that is larger than a standard team of, say, 4-6 engineers.

What does this look like? Examples include:

  • Meeting recaps noting decisions made
  • Onboarding guides in READMEs and internal wikis
  • Architecture overviews
  • Code review comments in merge requests
  • Descriptive Git commit messages

If you're not writing things down clearly, your team will revert to an oral tradition, where one engineer passes on information verbally to another engineer in order to get their work done. With any team larger than 4-6, this is a huge time waster, and is likely to cause miscommunications.

4. Over-communicate.

In general, it is better to give too much information than too little. Better to tell someone something they already know than to neglect to tell someone something they didn't know (but needed to).

5. Assume good intentions.

The advantage of in-person communication is that you can read the body language, see the facial expressions, and hear the tone of voice of who you are talking to. Misunderstandings can certain happen in person, but they are even more likely in a remote-first environment.

It's easy to misunderstand one another over email, Slack, and even Zoom meetings (especially with the camera turned off). For this reason, err on the side of giving the benefit of the doubt when a misunderstanding (inevitably) occurs.

If someone said something that offended you, don't rush to conclusions and assume that person is out to get you. Assume they didn't mean it and attempt to clarify instead.

6. Practice active listening.

In other words, focus on understanding what the other person is trying to say before preparing a response.

My go-to move here is to essentially repeat, in my own words, what I heard the other person say, and then ask them to confirm whether I got it right or not. If I got it right, I just got positive confirmation. If I got it wrong, I'll get a clarification, after which I'll try again to paraphrase and see if I got it the next time around. I'll keep doing this until I finally got it nailed down.

Wrapping it up.

It's easier said than done, but if you can get your organization to:

  1. Use a ubiquitous language,
  2. Use different communications channels for different things,
  3. Write things down,
  4. Over-communicate,
  5. Assume good intentions, and
  6. Practice active listening

Your team will be in pretty good shape, and will likely have higher morale, better cohesion, and more positive results.