Refactoring

Refactoring

Share this post

Refactoring
Refactoring
How to Design a Communication Architecture 🏯
Copy link
Facebook
Email
Notes
More

How to Design a Communication Architecture 🏯

A step-by-step approach based on responsibilities.

Luca Rossi's avatar
Luca Rossi
Apr 23, 2021
βˆ™ Paid
15

Share this post

Refactoring
Refactoring
How to Design a Communication Architecture 🏯
Copy link
Facebook
Email
Notes
More
Share

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 πŸ‘‡

This post is for paid subscribers

Already a paid subscriber? Sign in
Β© 2025 Refactoring ETS
Privacy βˆ™ Terms βˆ™ Collection notice
Start writingGet the app
Substack is the home for great culture

Share

Copy link
Facebook
Email
Notes
More