Streamlining communication in a big engineering organization: Practical steps
Streamlining communication in a big engineering organization: Practical steps
How to set up communication channels to get things done faster with fewer people involved.
In a typical library, you're searching for a book you wanted to read. Books are organized in alphabetical order. You know the author's name, you look at the index, and it tells you on which bookshelf you can find your book. Easy.
Let's imagine a strange library, where books are in chronological order by the year of publication. It'll be harder to find the book you want in this library. You need to know the year the book was published. To find yours, you would have to go through all the books in the library published in a given year.
Let's imagine an even stranger type of library—books are grouped by the color of the book binding. When you have a couple of bookshelves, it looks pretty. However, the approach wouldn't work for a library with thousands of books. This arrangement will make it even harder to find what you need.
A library where the books are stored without any order is complete chaos. Even if you know the book is in the library, you have to look through all the books to find it.
My point is that the arrangement of books provides information. This structure can supply you with accurate information—the book you're looking for is on the shelf #42. Alternatively, the structure can convey little or no information.
This idea of embedding information into the structure is crucial when it comes to organizing the work of several engineering teams.
Let's take the example of a new engineer joining your team. They finished the onboarding, and today is their first on-call shift. They started the day earlier and discovered that some portion of the requests to a downstream service is failing. It's not critical, and the engineer implemented a workaround to address the issues at the moment. To solve the issue permanently, they decided to raise a bug to the team who owns the downstream service.
Wait a minute... How do they know where to create a bug? How do they know how to contact the owners of that service? They don't. And this why they come to you asking whom to contact.
Information in structure
An alternative scenario for this situation can be that for every service in production, there is an automatically managed Slack channel SERVICE_NAME-alerts with all people from the team owning the service.
There is an auto-generated description of the channel: "Hello, this service is owned by the team Sigma. To page an on-call person, use the handle @team-sigma-on-call. To report a bug, use this board.".
In the first example, more people had to spend time and energy to achieve the same result. The second example shows how things are arranged so that one person can find everything they need. The only thing you need to know is that every service has a Slack channel. Knowing the name of the service, you're able to find out proper communication channels for your needs. You don't need people who "know stuff" to help you.
The last example is an illustration of how well-designed communication channels allow to complete tasks faster, with fewer people involved.
Engineers are smart and knowledgeable about technical matters, but they might not apply their knowledge to human systems. As engineers, we reason about time and space complexity of algorithms. These ideas are equally applicable to the business processes—how can we achieve the same outcomes involving fewer people and spending less time?
It's striking how often leaders are ignorant about designing communication channels for their organization.
Communication comes natural to us—humans just talk to each other. Verbal communication works pretty well in a small team. Important information spreads quickly, and everyone is up-to-date with recent developments in a reasonable timeframe. Problems arise as the group's size increases, the overhead of natural communication becomes unbearable.
For example, there will be an internal conference in the company and organizers are looking for speakers. A very senior person is in charge of organizing the event. They bring the topic to their staff meetings, asking directors to look for speakers in their orgs. What do directors do? They bring the topic to their staff meetings and talk to managers in their organization. Eventually, managers bring the topic to 1-1s with peers asking individual contributors.
What happens if there is a person who wants to be a speaker? They reach out to their manager. What does the manager say? They redirect to the next level, and then next. Ultimately, the potential speaker ends up in contact with the person who actually manages the list of speakers.
Many people "worked hard" to share this piece of information through the organization. Delays ate a lot of time to accomplish the task. None of it added value to the end goal. This way, compiling a list of potential speakers could take a few weeks to get done.
Imagine a company where communication channels were well-defined and completely automated. Each department had 'DEPARTMENT-announcements' only directors and senior managers had permissions to post content there. Any changes in organization were automatically reflected in the channel: new joiners, moving teams in the company, etc. Such channels were always in sync with the org structure. Yes, you can use terraform to manage Slack.
More importantly, leaders were using these channels consistently to share information. And people in the company knew where to look for the recent updates.
In that setting, sending a simple message, "We are looking for speakers for our internal conference that will take place next month. If you'd like to give a talk on topics X, Y, Z, please reach out to person A" to a channel with all people from the organization would do the job in a couple of days.
Wouldn't it be the same as sending an email? Email sucks, it's a great tool for asynchronous communication in a small group. It's a great tool to keep track of who said what and keep them accountable.
It's an absolutely terrible tool to share information with hundreds of people. In 2019, HBR published1 that on average, workers receive 120 emails per day. The inbox tends to pile up, and not many people are disciplined enough to keep it in a good shape. Email is a noisy channel. You never know how messy the inboxes of the recipients are and if they read your email at all. There's no way to say that your email is important when there are hundreds already in the inbox. You're not the only one who uses [action required] in the subject.
Implementing a broadcast channel
It must be public
For some reason, many people prefer to make channels private, even if there is no intent to share sensitive information. That contradicts the whole idea. Your message should be discoverable and sharable. Private channels are not discoverable, you must be in the channel to be able to search. Private channels are not sharable—you can't give a link to the post to people outside. In general, by keeping things private you shape the culture of the company, which little by little becomes more private.
Low noise, high signal
If you post updates about the organization in a channel where there are hundreds of messages every day. Very likely people will not notice the message. Limiting access to people who can post helps. Still everyone can reply in a thread, but the channel is clean, and all recent posts are easily searchable.
Reflect the org structure
Once I joined a team, and it took me two months to figure out which email list and channels I should join to stay up with all things that were relevant to my job. This is easily solvable on many levels. Starting from a checklist for new joiners with all communication tools used and how to get access to them. Again, making channels public simplifies this, people can just join, they don't have to ask someone to add them.
Alternatively, if you can afford this, it can be completely automated. Terraform can manage not only your cloud infrastructure, but also day-to-day tools like Slack, Jira, Trello, Asana, etc. It might seem an overkill, but it's surprising how often reorganizations happen in big companies and how long it takes to adjust communication channels.
You cannot over-communicate
No matter how well you design your communication channels, there will be people who miss stuff. It's worth repeating the message through different channels such as emails, town hall meetings, 1-1s. However, all those secondary channels should link back to the original message. Which is the source of truth. Otherwise, it might create rumors.
Effective communication in a big organization requires infrastructure, the infrastructure can be ab enable or a constraint. It's up to you as a leader to make your organization efficient.