Clear communication is key to effective software teams, as context and alignment allow them to deliver the right thing, fast. Without clarity and context, you end up with a group of people lacking direction at best, and total chaos at worst.

This is especially important for remote and hybrid, distributed teams. Being more open, public, and inclusive in the way your team communicates can give engineers greater autonomy to be effective. Creating a culture of knowledge sharing where the correct context is conveyed throughout the entire company helps to head everyone in the same direction, without introducing more distractions and uncertainty.

Default to public

Ensuring key communication happens in the open can be a difficult shift for many organizations, but it’s incredibly important. 

By “default to public” I mean removing direct messages (DMs), private sync meetings, and any other activities where information could be hidden from the broader organization. There are exceptions to this rule, which I will talk a little about later, but not many.

Often the fear of defaulting to public hinges on creating more distractions. While this is true, it’s not necessarily the negative many people think it is.

I have seen multiple scenarios where defaulting to public communication has increased engagement, broadened context understanding, and aligned everyone around the goals they are aiming towards. The element of distraction can be mitigated by being more informative and less disruptive with our messaging, so that if distractions are increasing, they are purposeful, allowing those who need (or want) to know something access to the information.

Get the information you need

Defaulting to public may seem like unleashing a huge flood of information and it may be a struggle to know how to filter it.

This is where managers come in. Managers should help their direct reports navigate this information and foster a culture of concentrating on what is important to know and when. You'll quickly find that if you trust your team, they will only subscribe to the information they know is necessary for their delivery focus. The real bonus here is they now have access to information from across the organization, which will either help give them context for what they are working on, or provide an opportunity to collaborate with others.

Contact flow

When thinking about public communication, the following rule always helps me decide where the message should go:

In the above example:

• Direct message = you contact one person specifically
• Team = you reach out to a specific team about something
• Cross-team = you reach out to a larger group cross teams

This is just a starting point and many other factors might come into play, but this shows how private communication should not be necessary in most cases.

Exceptions to the rule

Private communication still has its place, but it should not be the default for your organization. Communication involving sensitive information, casual chats with colleagues, and direct feedback are some scenarios that should probably stay private.

Default to inclusive

Here, inclusive means making sure the communication you have includes a larger audience by default. This is slightly different from “default to public” and is more about how you communicate to avoid people missing out on crucial information.

We’ve all been in the situation where you come back from a break, or even just a doctor’s appointment, and you’ve missed an important meeting and have to chase up multiple people to try and understand what happened. You also missed your chance to give your input. But there is a better way.

Have an agenda and document for every meeting

Effective meetings need an agenda with specific outcomes. Now, going one step further involves creating a living document to support these meetings. This level of preparation gives you a chance to understand what you want out of the meeting, as well as align others on the purpose (sometimes it can lead to a meeting never even being needed). Having a supporting document sent out before the meeting also builds inclusion for those that might be able to attend, as they now have an entry point to input, or review the meeting notes after.

This is also a great way to agree and document actions and decisions made. It also lessens the likelihood of one individual taking all the meeting notes. It’s important that whoever creates the meeting owns and drives the agenda, but by being inclusive you give all invitees the ability to input and collaborate centrally and publicly.

What kind of supporting document?

This depends on the type of meeting you are having, but there are key things to consider when creating these documents:

• Agenda
  • What is the purpose of the meeting/document?
• Outcome
  • What outcomes are you aiming to achieve?
• Value
  • What is the value of the discussion?
• Input, notes
  • Freeform section for others to input, but also creates notes during the meeting.

Case study

Here are two examples of meetings that aim to gain alignment on a new feature for a product, involving multiple teams on a deadline to deliver before the end of the quarter.

Example one (not defaulting to inclusive)

John books in a 30-minute meeting titled “Alignment on the feature”. There is no agenda attached to the meeting. The invite has gone out to the heads of multiple teams, however, these invitees are not sure what the purpose of the session is and who in their teams would be able to support. Due to this information gap, they decide to go themselves. One of the team leads is unable to attend the meeting.

The meeting starts with ten minutes to go over the purpose of the meeting, using slides to talk through the key points. There are some questions, which take up about 15 minutes, with only two of them being relevant to what John was hoping to talk about. The remaining five minutes are spent quickly making decisions that mean (based on the designs shown in the presentation slides) we will be able to deliver the feature by the end of quarter without any issues.

There were some remaining questions that still need to be answered, and there were no actions covered during the session, but John now has alignment between the different teams (except for the team lead that was unable to attend) that this feature can be delivered by end of the quarter.

Example two (defaulting to inclusive)

John books in a 30-minute meeting titled: “Decision and alignment on feature X to be delivered by end of quarter”. Included with this meeting invite is an agenda:

This session is to discuss the delivery of feature X, with a delivery date of the end of quarter. I would like us all to be aligned on the delivery as well as highlight any issues that might arise from this approach. During the session, I’ll go through these slides (linked) for us to get aligned, as well as use this supporting document (linked) to make sure any inputs and actions are covered for those who can’t attend the meeting. Please raise any questions in the document that we can review during the session.

Outcome:

• Alignment on the expectations of feature X
• Highlight any potential issues, with follow-up actions
• Assess the confidence level of delivery by the end of quarter

The invite has gone out to the heads of multiple teams. As there is an agenda, one of the heads of the teams sends someone who would benefit from this conversation as part of their career development, and another head of team realizes there is no input needed from their team so declines. Another team lead is unable to attend, but after reviewing the linked slides and supporting document makes some notes on the document. “In order to deliver feature X by the end of the quarter we are going to need to do Y, otherwise this is impossible,” they write.

The meeting goes ahead with a quick review of the slides, this takes five minutes, as most have already reviewed the slides and have questions ready on the supporting documents. Some questions had already been answered before the meeting and any remaining questions are covered in about five minutes. Another ten minutes is then spent on the issue raised by the other manager who couldn’t attend. They have provided some helpful supporting information as to why it would not be possible in its current design with some approaches to how it could be done. Actions are written on the supporting document for changes to the design to be done, as well as a quick confidence measurement from everyone. They all felt highly confident.

The meeting finished five minutes early. With a follow-up action to change designs, John is happy that he has all the information he needs to deliver the feature by the end of the quarter.

What did we learn?

Both of the meetings end in the same way, with John feeling like he has everything he needs to deliver the feature by the end of the quarter. However, with the first meeting, this might not actually be the case. Without the input of the person who could not attend the meeting, it’s likely the feature won’t be delivered, or everything would need to be changed in a rush to deliver. 

The second meeting gave one of the team heads an additional chance to help someone with career development. It also meant that one person didn’t even need to attend, which saved them time to focus on something else.

The meeting finished five minutes earlier with supporting written documentation, so although one person couldn’t attend, they had an easy way to catch up on what decision was made.

Default to detail

In order for communication to be effective, it has to be written from the point of view of the reader and the audience that is going to consume it.

Examples

The following are two examples of the same Slack conversation:

Example 1 (not defaulting to detail)

> _Barry(9:00AM):_ Hey everyone, I have a question on project X.

> _Barry(10:00AM):_ This is quite critical, is anyone able to help?

> _Grace(10:30AM):_ Hi Barry, how can we help?

> _Barry(10:36AM):_ Hi Grace, thanks for the assistance. I have a question about the API you are using to update customer information for project X.

> _Grace(10:38AM):_ Sure what's the question?

> _Barry(10:40AM):_ When you call the endpoint I have noticed that some of the header information doesn't make much sense, and I am trying to understand what detail I need to add.

> _Grace(1:30PM):_ Sorry, Barry, I was in a meeting for the past couple of hours. Is it a specific header you are having an issue with, or is it all of them? If so does the document (_linked_) not provide enough information?

> _Barry(2:15PM):_ No problem, so I checked through the document this morning but I don't think it's quite up to date, the issue I am having is with the header `person` .

> _Grace(2:20PM):_ OK, what issue are you facing with `person`?

> _Barry(2:35PM):_ Whenever I call it I am getting a `400: Bad Request`.

> _Grace(2:48PM):_ OK, I can see from the logs we are getting some bad requests, I have updated the document with the correct header requirements. Let me know if that fixes it for you.

> _Barry(2:50PM):_ That's perfect, thank you Grace it's all working now.

Example 2 (defaulting to detail)

> _Barry(9:25AM):_ Hey everyone, I am currently trying to reach the endpoint `/update/customer/id:{customer_id}` but when hitting this I am getting a `400: Bad Request`. After looking through the document (_linked_) I can see that the issue is with the `person` header, which I am seeing in the logs (_linked_), is expecting a `title` field, but I can't see that reflected in the document (_linked_). 

> This is quite urgent for me as I am blocked from moving forward with this new feature until I overcome this hurdle, and another member of my team needs me to release this before they can release their feature too.

> Could you please let me know if I am doing something wrong?

> _Grace(10:30AM):_ Hi Barry, thanks for reaching out, let me get onto that as quickly as I possibly can and I'll get back to you soon.

> _Grace(10:35AM):_ You're right, Barry, the document is incorrect, we are expecting a title and for your scenario to unblock you please see this example (_linked_) and then I will update the main document as soon as I get time. Please let me know if that has fixed your issue.

> _Barry(10:40AM):_ That fixed the issue on our side. Thank you, Grace, have a great day.

What did we learn?

First off, the majority of these conversations should be in threads, but more importantly, there is a huge difference in how the same conversation progressed in example one versus example two.

In example one it took six hours to resolve the issue raised, whereas in example two it took just over an hour. Although it took Barry longer to raise the request in the second instance, gathering all of the relevant information before posting, that extra effort meant that Grace had everything she needed to solve the issue faster.

Although both scenarios ended up with the same outcome, example two is much easier for others to follow, and has a lot more detail.

The above could indeed have been avoided by creating a sync meeting between Barry and Grace, but this relies on Barry knowing who to reach out to get help. It also means that that person needs to drop everything they are doing to help support Barry. Most important of all, anyone else who ends up with this same issue will just repeat the whole process, as they have no visibility of the sync meeting discussion.

Final thoughts

Everything I have discussed here requires a significant culture shift, but by implementing these things over time you will see huge benefits in alignment across multiple teams and clear understanding of your organization’s focus and priorities.

I am not promising that delivery will speed up dramatically as a result, but I guarantee you will be building the right things if everyone is aligned on the context. You will also help save time, support career development, improve documentation, and reduce overall meeting culture.

If there is one takeaway from this article it would be to ask yourselves the following questions:

• Do all meetings have clear agendas with an outcome?
• Are all communications inclusive of everyone, or are we hiding information?
• Is everyone aligned on our vision? If not, how can we communicate this more effectively?
• Is the way you communicate detailed enough to give everyone context?