Let’s be real: these are not questions that keep us up at night. Nonetheless, choosing the right channel for the message is a great way to boost productivity and reduce the frustrations of working with others. That’s why we put together this handy-dandy guide to using email, chat, documents, and real-time communication.

You’ll notice a strong bias toward making information discoverable whenever it’s practical (and sometimes when it’s not) so as not to accidentally create information silos. But there’s no sense in overwhelming your colleagues with more information than they can absorb or need, either. So you’ll also find tips for walking the line between sharing and oversharing.

Communicating via email

Best for… sharing content housed in shared docs or Confluence pages with the relevant people. That’s it, really. Be sure to include a note stating what’s in the document and why it’s relevant to them.

For example:

• “Hey team, here’s that project brief I mentioned earlier. Please read through it in the next day or two and drop comments with your feedback. Thanks!”

And remember…

• If you find yourself in a long email thread, it’s perfectly acceptable to say, “Let’s move this conversation to Slack. I’ve created a room called <name> and invited you all” or “Let’s shift this to Confluence, I’ve moved all the content from this thread to a page”.

Communicating via 1-to-1 chat

Best for… quick discussions or questions with a single person. If you don’t need an answer urgently, let them know when you do need it so they can prioritize it appropriately. This is especially important when working with people several time zones away.

For example:

• “I can’t make the meeting, could you fill in for me?”
• “Hey, haven’t seen you in a while – how are you doing? How’s your evil cat? Did those scratches ever heal?”

And remember…

• Compose and send the whole message in one go. Don’t send “Hi!” and then wait for a response before sending the rest. This is distracting and time-consuming because now they have to wait for you to send the real message, and since their concentration is now interrupted, it’s hard for them to do much of value in the meantime.

Communicating via group chat

Best for… quick discussions or broadcasts to a group. Be mindful about sending messages that will trigger a pop-up notification for everyone in the room – e.g., the @here and @channel commands in Slack. Both should be reserved for things everyone really needs to know about right now.

For example:

• “Running late. My cat won’t come out from under the house.”
• “Anyone tried out that new JavaScript framework? Is it any good?”

And remember…

• There’s rarely a good reason to lock down chat rooms. Private rooms are just another silo, after all!

Communicating via shared documents and wiki pages

Best for… content that multiple people will collaborate on, or that is likely to change over time. If your work is in the early stages and you aren’t ready for feedback yet, put a prominent note or banner at the top of the page. Restricting access to the page often leads to the work being shared too late, when it’s hard to incorporate feedback. Plus, locked pages breed a culture of distrust.

For example:

• “Parental Leave Policy”
• “Platform Engineering team goals: FY19 Q3”
• “Photos of Atlassian cats”

And remember…

• Give your pages titles that convey context. “Project plan” might make sense in a certain page or folder hierarchy, but that information isn’t included when sharing the page with collaborators or notifying them of changes. So be explicit in titles, even if you end up repeating context from parent pages.

Communicating via internal blog posts

Best for… internal announcements about point-in-time events and achievements that won’t be updated later. Yes, you could use email in such cases. But putting it on your intranet allows people to share their thoughts by commenting on the page. Nobody wants reply-alls of “Hooray!” or “+1!” cluttering their inbox.

For example:

• “Congratulations to Maria on her promotion to principal engineer!”
• “Cat-lovers club is meeting this Saturday (bring laser pointers)”
• “Jira 9.0 has shipped!”

And remember…

• When sharing, include a useful message so people can decide whether it’s relevant to them. “This is a wrap of our team’s experiment with remote work with lessons your team can learn from” is useful. “Check out this blog” is not.

Communicating in-person or via video call

Best for… anything that can be resolved faster by just talking, plus anything sensitive, difficult, or emotional. Being face-to-face is best so you don’t miss out on non-verbal signals like posture or facial expressions. If you’re spread across different offices, take advantage of all the recent advances in video calling. Tools like Zoom make it easy to fire up a video chat (even if you don’t have a PhD in IT).

For example:

• “Do you have a few minutes to talk about the project’s scope? I’m not sure the discussion in Slack is getting us where we need to be.”
• “After yesterday’s incident, I’d rather you didn’t bring your cat into the office anymore.”

And remember…

• For quicky, impromptu video calls, just take it right there at your desk. Jumping up to find a private room often takes longer than the conversation itself! The sound of you talking is no louder than any other conversations that happen in our work areas, so don’t stress about distracting your teammates. Putting your headphones on is considered polite, though.

.There you have it! These guidelines help Atlassians be efficient and productive while upholding our “open company, no bullshit” value. Both of us (Penny and Sarah, your intrepid co-authors) have been with the company since we were just a few hundred people and can attest to how important open, smart communication practices have been as we’ve scaled. Now, as a team of a few thousand, these practices are more important than ever.

Each organization has its own unique culture around sharing information and using various communication channels. Use this guide as your starting point, and keep iterating to make your comms culture awesome.

This post was written by Sarah Goff-Dupont for Atlassian and republished here with permission.