“The single biggest problem in communication is the illusion that it has taken place.”

— George Bernard Shaw, Nobel Prize-winning playwright

Understanding Communication Infrastructure

In the last few weeks, as part of my own product research, I’ve interviewed over 60 engineering managers. My goal was to learn more about what processes, channels, and techniques they have developed to improve communication within their teams, and the insights from these conversations have been counterintuitive and surprising.

When I ask EMs how they manage their team, I usually get a very elaborate and descriptive answer about their delivery process; I hear about Jira implementations, documentation, prioritization, and many other topics related to structuring work. However, I hear a lot less about communication infrastructure.

Communication infrastructure is the intentional design and use of channels, spaces, and tools that have a unique purpose and are part of a communication system that allows the team to have effective feedback loops.

Engineering a good communication infrastructure is about designing the purpose and protocols needed to get the best out of the communication activity and then implementing tools that facilitate that protocol.

For example, many teams use Slack, but many managers struggle to keep up with the quick decisions made in multiple channels. The problem is not Slack but the protocols and rules around it.

A common case is teams using direct messages in Slack instead of discussing issues in public channels. This behavior leads to a lack of context, missing opportunities for learning, and a lack of visibility on decisions. In this case, the infrastructure is broken; you have a tool with no defined purpose and no protocols to keep it effective.

The protocols you put in place say much about what you value within the team.

If transparency is a value, then what are the specific protocols that support that daily?

There is no better place to exercise your values as a team than in how you engineer communication. In this article, I share some abstractions and specific recommendations that can help design better protocols and get more clarity from every interaction between team members.

Developing Protocols

“Communication works for those who work at it.”

— John Powell, film composer

The first step in designing your infrastructure is to look at the recurrent conversations you have within the team. Here are some examples:

• Pull request reviews
• Status updates
• Rubber ducking and debugging chats
• Rolling out of new features
• Dealing with blockers
• Cross-team sync meetings
• Performance feedback
• Career development
• Reviewing team structure and dynamics
• Retrospectives
• Postmortems
• Planning in general (sprints, ShapeUp, etc.)
• Strategic product decisions
• Scoping/requirement definition
• New tooling discussion

Now, let’s take one of those conversations and review some of the challenges I heard from engineering managers. Let’s pick retrospectives.

The most common challenges people share are:

• People are too quiet or disengaged during the retrospective.
• People show up without any topics for discussion.
• The session is too long. We spend two or more hours on a call getting topics ready, grouping, voting, and only then having a discussion.
• Nothing happens after the retrospective, and the actions are never completed.

I can relate to those challenges; I have participated in or run retrospectives for the last 15 years of my engineering career.

Here’s a protocol I’ve found helpful to avoid common challenges. There are many obvious things here, but you would be surprised how easy it is to ignore them and underestimate their negative impact on the conversation.

It is not about micromanaging the team but setting up the protocol, so the team can relax and communicate smoothly.

Retrospective protocol example

Before the meeting

• Arrange a recurrent event in everybody’s calendar.
• If the team needs to reschedule, do not skip the retro; instead, find a better time within a couple of days and adjust recurrent events.
• Send reminders to the team about adding/gathering their topics for discussion at least three days in advance.
• Send additional reminders to team members who have not added a topic yet.
• Gather topics and organize them into groups the day before the retro call.

During

• Record the call for those who could not attend and for additional note-taking.
• Start the call addressing what action items from previous retros got done or not and why.
• Make sure the retro is not just about the work done, but there is also space to discuss team dynamics or feedback on the retrospective itself.
• Agree and assign action items.

After

• After the call, send a quick summary of any decisions made and the list of action items.
• Prioritize and add items to specific tools (Jira, Linear, etc., etc.)
• Review if items have been executed before the next retrospective, at least one week before the next one.
• Rinse and repeat.

The protocol above helps engineers think about topics in advance; it promotes asynchronous preparation so the call can be focused on the discussion, creates accountability by reviewing previous tasks at the start of the session, and provides space to evaluate the session’s effectiveness.

Additionally, these protocols enable anybody on the team to run the protocol themselves, so they are less dependent on you running these sessions. Once you have a protocol, you can look into tools to automate tedious things like scheduling, reminders, templates, recording, note-taking, follow-ups, etc.

The key point for protocols is that they can not always rely on your memory and ability to stay perfectly organized. Things change fast, shit happens. You need a resilient protocol conducive to your team having an opportunity to step back, share learning, and take action for improvements.

You can’t just adopt or buy tools and hope for the best. Returning to the Slack example, you can’t just open several channels and hope communication will flow efficiently. Even at the level of ceremonies, although they have an inherent structure, you still have to design protocols for those that work specifically for your team.

“Early in my career as an engineer, I’d learned that all decisions were objective until the first line of code was written. After that, all decisions were emotional.”

― Ben Horowitz, The Hard Thing About Hard Things

Having experienced both roles in the past, being an engineering manager is not that different from being the CTO of a very early-stage startup. You need to hire, define the values and culture of your team, put in place protocols to maximize the impact of every team member, and deal with stakeholders (investors, customers), etc.

As an EM, my main job is to build the systems that help people flourish, so I always start with the protocols that help team members step back, express concerns, share ideas, bubble up problems, and take action on those.

At a minimum, I suggest having a good protocol for one-on-ones, retrospectives, async check-ins, and ad-hoc meetings.

These protocols are normally underpinned by general rules you agree with your team. Rules are not about trying to control the team; rather, they are about building a shared common sense.

Here are a couple of examples

• If you spend over five minutes on Slack explaining something, jump on a call — it will be faster.
• If a decision was made in a call — write it down immediately and share it publicly.
• Always start with the users and their experience. Everything can be worked out from there.

This checklist has been copied verbatim from the “Communication” section of my previous company’s employee guide. These guidelines set the way we used Slack, Trello, and Notion. And remained mostly unchanged when we had to move to Jira and Confluence. Furthermore, at some point, the team came up with a protocol for dealing with our Pull Request process because they noticed inefficiencies after we migrated to a mono repo. I didn’t even write the initial proposal; the team drove it.

Having clear protocols also helped fill roles when somebody was unavailable. For instance, when I couldn’t organize the retrospective, anybody on my team could take over confidently.

Before You Bounce: Recap

Managers, at the most basic level, are in the business of information management: collection, summarization, and distribution. Thinking intentionally about your communication infrastructure is part of that role. Here’s what we covered:

1. Identify your recurrent conversations.
2. Forget about the tools and design protocols conducive to supporting healthy behaviors and the values you would like to see in your team.
3. Write it down; you will evolve it over time.
4. Automate as much as possible — do not rely on memory or people’s ability to be organized and disciplined, including yours.
5. Set general rules for what to do, when, and where (Consider this a README for your team).
6. Discuss the protocol often to check if people find it helpful and change them accordingly.

“Communication is the real work of leadership.”

— Nitin Nohria, former dean of the Harvard Business School

I would love to hear about your firsthand experiences — what specific protocols have you implemented in your team? How have they influenced the communication dynamics? Were any particularly successful or not as effective as you hoped?

If you found this article helpful, you may also like what we do at Collie.

Collie helps engineering managers have better conversations and make the most out of every meeting.

Communication Infrastructure for Engineering Managers was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.