How to Design a Communication Architecture 🏯

A step-by-step approach based on responsibilities.

Hey 👋 this is Luca! Welcome to a 🔒 weekly edition 🔒 of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

---

Last week I published an article about having good 1:1s. After a couple of days, a good friend of mine sent me this old post by Ben Horowitz about the same topic. This bit stuck with me:

Perhaps the CEO’s most important operational responsibility is designing and implementing the communication architecture for her company. The architecture might include the organizational design, meetings, processes, email, yammer and even one-on-one meetings with managers and employees.

And more:

Absent a well-designed communication architecture, information and ideas will stagnate and your company will degenerate into a bad place to work.

This article is from 2012.

If things seemed messy back then, well, look now. We still got the same problems, plus we threw Slack and Zoom in the mix.

So let's say we want to follow Ben's advice, clean up the mess and work on a proper Communication Architecture. How should we start? Let's try to find out 👇

🏯 Communication Architecture

What is a Communication Architecture? It is a system that defines how stakeholders of a process exchange information.

It is a heated topic today, because people know this needs to improve. Common advice you find focuses on two axes:

• ✍️ Written over Verbal communication — create more documentation and share it with stakeholders instead of transferring information in meetings.

• ⏳ Async over Sync communication — prefer async exchanges that do not block everyone's time, and structure your work in a way that you don't need instant feedback from anyone.

This is actually great advice, and you will find several instances of this approach led by successful companies — from radical ones like Doist and GitLab, to Amazon's culture of written memos, and more.

The only problem is that, in most cases, this is just tactical advice. It can improve your communication, but it is not going to fix it if it's broken.

Replacing a meeting with a shared document can be great, but what if it was the wrong meeting from the start?

So let's try to think at communication on a strategic level. For any given process we want to analyze, let's consider four elements:

• 🔍 Scope – inputs, outputs and goals of the process.

• 🏃‍♂️ Activities – the steps required to take inputs and transform them into outputs.

• 👥 Stakeholders – people involved and their role in the process.

• 🧱 Artifacts – given all the above, documents, tools and rituals we can setup to make communication happen properly.

Let's see them one by one 👇