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

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.

Questions from engineers

Q: How can we ensure that the most important topics are adequately discussed in a meeting when there is limited time and risks of certain topics being rushed or overlooked, especially when using a voting system to determine the agenda?

Firstly, I value the team's input, so topics with more votes are prioritized in meetings, even if it means extending beyond the scheduled time. This ensures we address what matters most, acknowledging the team's preparation and engagement. Secondly, we've modified our retrospective format.

Sophia, my co-founder, and I lead monthly meetings to share business updates, project progress, and future plans, keeping everyone informed. This change allows retrospectives to focus on other vital topics, like customer feedback, instead of just celebrating known achievements.

We separate discussions to make retrospectives more interactive and inclusive, covering a range of concerns and achievements, such as new hires. Our approach includes considering vote outcomes, being flexible with time, and segregating standard retrospective topics into other meetings for a more effective discussion.

Q: Do you have any other tips for creating an environment of psychological safety, where people feel comfortable bringing up things that might not be so good?

I always try to lead by example and not be afraid to admit my mistakes. There have been times when I made costly architectural mistakes, like adopting an early-stage tech as a data store, only to realize later that it didn't work out as expected. I would acknowledge these mistakes and learn from them, emphasizing that it's okay to fail because everyone is striving to do their best. As a leader, it's important to show vulnerability and provide guidance on how to rectify mistakes and improve in the future.

In our early-stage startup, we often had big projects and had to undertake significant refactorings. To minimize risks, we implemented an experimentation culture where we broke down these projects into smaller, manageable pieces. This allowed us to evaluate each step and reduce the impact of potential mistakes.

For example, instead of implementing everything in Elasticsearch, we would try it out in small steps and decide if a more durable data store was needed. This approach not only helped in terms of delivery but also applied to other areas, such as trying out new tools. We would introduce flexibility in our communication by suggesting new tools like Miro for the next retrospective, allowing the team to evaluate and decide whether they liked it or not.

Q: How do you determine what should be saved for the retrospective and what needs to be addressed immediately?”

You have to gauge it as it's happening.

There are some things that have to be squashed immediately, like confusion in a conversation. For example, if you can see that people just aren't understanding what they are talking about between each other, you have to step in and say, "Okay, you are clearly running in circles." As a manager, it's a good idea to write these instances down for later use during the retrospective. When the retrospective comes, you can bring up these recurring issues and address them.

This process is highly dependent on what stage you are at in tweaking the communication infrastructure. In the beginning, it's reasonable to assume that everything will have some areas that need improvement. It's important to take notes and see how things can be improved.

However, there are situations where miscommunication can impact something that needs to be delivered faster. For example, if there are classic miscommunications between design and implementation, it can cause slowdowns in delivery time. In these cases, it is crucial to step in and address the issue immediately. This might involve getting three people on a call to clarify the miscommunication. It's a matter of serving the business and avoiding potential delays.

On the other hand, there are situations that can take longer to address because they require more thinking through and applying changes later on.

Q: Can one team have protocols that are different to the ones the company has or may not have at all?”

‍Yes, I believe effective team management recognizes the individuality within teams. Teams are essentially collections of unique individuals working together. It's important to acknowledge these differences rather than forcing a one-size-fits-all approach in communication and work styles. For instance, I personally perform better when I have time to write down my thoughts before discussing them. This preparation helps me avoid presenting unformed ideas that could confuse my team.

Understanding and accommodating individual communication styles is key. While aligning everyone is necessary, we can adapt processes to suit different strengths. For example, implementing a 'request for comments' process allows team members to prepare their thoughts in writing before discussing changes. This approach respects individual preferences while maintaining collaborative decision-making.

The effectiveness of these strategies can vary widely depending on the company's culture and history, like transitioning from a colocated to a remote environment. Such shifts might carry over previous habits, which may or may not be effective in the new setting. Dealing with humans, who are inherently diverse, means there's no universal answer to managing teams effectively.

As a manager, it's my responsibility to identify and champion what communication methods make our team most effective. Advocating for strategies that highlight our strengths is crucial, as it enhances overall team performance and job satisfaction.

Q: Does the way you advocate for communication protocols vary based on your level in the company pecking order? Do junior-mid level folks need to take a different approach to senior folks? What about ICs versus official managers?”

As a founder, I have the influence and privilege to be very open about things that weren't working and suggest better ways of communication.

But if you are a manager, it is your responsibility to listen to the people you're managing. If someone on your team complains about ineffective communication, it's your job to bring it up and advocate for change. As a manager, you need to be a champion for your team, ensuring they have effective processes that prevent burnout and turnover. Empowering people by listening to them is key.

Even as an individual contributor, I would still suggest improvements because managers love it when people bring forth ideas for improvement. It shows engagement and initiative. Being the agent of change, even in a non-managerial role, can be beneficial for your career growth. If you propose improvements thoughtfully, showing that you've recognized a problem and have a solution in mind, people will appreciate it. I cannot think of a situation where someone wouldn't want to get better.

So, while it does matter to consider your role and position when advocating for communication protocols, it doesn't mean you're in a losing position. In fact, it can be a great signal for promotion, as it shows initiative and goes beyond your assigned tasks.

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?

*This post originally appeared on https://betterprogrammming.pub. We’ve republished it here with Łukasz's permission, along with some updates from our recent webinar which you can watch here.