Internal comms for executives.

Whenever an executive joins a new company, there is an awkward merger between the executive’s preferred communication style and the norms that organization has already established. I remember a recently joined executive complaining that engineers weren’t reading his emails. He “solved” that problem by sending another email, this one instructing the team that they were responsible for reading their email twice a day.

You won’t be shocked to learn that this didn’t really solve the problem. Most communication was done via chat, and the team didn’t have a habit of checking email. Shifting an organization’s patterns is slow, and requires far more than one angry announcement.

What was educational for me was that the mandate appeared to work! Although many engineers didn’t change their habits, team managers started to reshare key emails in their team chat channels, and everyone was able to continue communicating as they were most comfortable. (Lest you decide to repeat this experiment, I will note that there was some grumbling among the team managers.)

One takeaway here could be that your management team will probably make communication work, one way or another, no matter how poorly you do it. That might even be true, but your goal is to make things run more effectively, not less. Fortunately, you can significant improve the quality of internal communcations within your organization by adopting four practices:

1. Maintain the drip: communicate on a regular basis, even if you don’t have something novel to share
2. Test before broadcasting: review your communication with a few people before sending it, to improve clarity and avoid blindspots
3. Build the packet: ensure every communication has a concise summary, link to background context, and an explicit way to ask questions
4. Use every channel: distribute important information across every relevant channel, including meetings, email, chat, etc

Importantly, these are all mechanical practices. Even if internal communications is something you’ve struggled with in the past, there are no prerequisites to adopting these tools. They don’t require unique literary flair, charismatic public speaking skills, or anything extraordinary beyond the willingness to implement them consistently.

This is an unedited chapter from O’Reilly’s The Engineering Executive’s Primer.

Maintain the drip

Large companies often make their executives seem larger-than-life, but you’re just a person, and you can close the distance between yourself and the team by sending a short, weekly email. These are a good opportunity to let folks know what you’re focused on, what you’re doing, and reassure them that you’re paying attention to their work.

The format here is highly variable: I’ve iterated on my format quite a few times, and you’ll find a format that works well for you. Over the course of each week, I accumulate my weekly updates in one document, then spend about twenty minutes to compile them into the final email. I’d generally email the organization I lead, along with an email group that anyone internally can join, allowing interested folks outside of my organization to also read the updates. (Personally, I’d recommend pre-populating that group with folks I want to read the update, including folks you work closely with on the executive team.)

A typical update is along the lines of:

• One to two sentences about something human. Something that surprised me this week, something that energized me this week, something that made this week stand out for me
• One sentence summarizing any key reminders for upcoming deadlines or dates
• One paragraph for each important topic that has come up over the course of the week. These might be a quarterly planning update, a controversial tech spec, a product launch, a partner escalation, or any other topic that feels important. I usually pick 2 to 3 topics for each week
• A bulleted list of brief updates. These might be an incident review, a tech spec, a product design, an interesting discussion in chat, or anything else I want to create some visibility around
• Close with an invitation for folks to reach out with questions, thoughts, and concerns

It’s a simple formula, but I’ve found they’re surprisingly valuable for staying aligned, and also generate a surprising number of unexpected emails from the team surfacing topics that I wasn’t thinking about at all (and generally should have been thinking about more).

These updates establish a persistent drip of information from you to the wider organization. Some weeks you might have a light update, but rather than folks thinking that you’re not doing much, they’ll be reassured that they are up-to-date on what’s important. Dense updates are good, but it’s the brief updates that reassure the team that you would have updated them if there was something they needed to know.

Test before broadcasting

A surprising amount of executive time is spent cleaning up messes. Some of these messes are externally motivated, like a competitor launching a new product, but a surprising number are self-inflicted. At least half the self-inflicted messes that I’ve seen executives create are caused by unsympathetic or confusing communication, which you can easily prevent by testing your communication before widely broadcasting.

This may not be necessary when you directly know every member of the team, but by the time there are four or five other managers in your organization–around when you reach 40 folks–at least one other person should proofread every significant organizational communication before you share it out. “Significant” meaning a change, decision, or something the team might feel strongly about; “organizational communication” meaning something impacting a wide number of folks, almost always beyond the scope of just one team.

The process here is pretty straightforward: write your communication, and then ask for feedback before sharing it widely. I recommend directly asking individuals for feedback, as that tends to inspire more useful feedback than asking a group (e.g. asking your full team of direct reports), but experiment with different approaches until you find something that works for you. The request should be short and direct, along these lines, “Hey Mary, I’d really appreciate your feedback on the performance review announcement before tomorrow at 9AM PT.”

Some folks have a very negative reaction to the idea of getting their communications reviewed. I was initially frustrated by it as well! It can feel like “wasting” time. What I’ve come to appreciate is that testing the message speeds up the pace of communication, because it reduces the time spent explaining the message. It feels slow, but testing your messaging is better for both your recipients and for you.

Build the packet

Early on with a small team, communication with your organization will be informal. However, as the team gets larger, a bit of consistent structure will go a long way. I strongly recommend structuring every piece of important communication following this structure:

• Summary: the full communication can be long if it starts with a concise summary that answers the key questions: what’s changed? who does it apply to? what do I need to do if it applies to me? where can I find more information? when is it happening? what should I do if I have questions?

  For example: “tl;dr – starting tomorrow (2023/1/20), any proposal for a new service must be made in a tech spec and presented at tech spec review. See go/tech-spec for more details, and ask questions in #tech-spec or reach out to Jenny X”

• Canonical source of information: importance announcements will be shared in many places, but you don’t want folks to assume each notification is the most up to date, canonical place to check for information. Link to the best place for more in depth information, generally a document or wiki

• Where to ask questions: as you communicate to more folks, inevitably there will be edge cases that your announcement misses. For example, the above announcement about new services needing to be reviewed at tech spec review might be missing information about applying that decision to a newly acquired business unit that doesn’t currently work with your tech spec review process.

  The best place to ask questions is usually a chat channel or email list, along with a named individual for folks who are uncomfortable asking in public (typically newer hires or less senior folks who have good questions but are still getting a feel for how communication works)

Earlier, I mentioned the idea of mechnical practices, and building the packet is a particularly good example of a mechnical practice. There’s no artistry here, but consistently following this practice will make it easier to land important communication.

Use every channel

Over time, I’ve developed a theory of organizational communication that I call, “information herd immunity.” It’s simply impossible to ensure every member of a two thousand person engineering organization knows anything. Even if you personally tell each member of the organization that performance reviews are starting next week, and send them an email the day before, some fraction will still be utterly confident that no one told them about performance reviews starting.

Accepting that reality, the secret to successful communication is ensuring that someone on every team knows important information. The best way to do that is to ensure you communicate across every channel, and to even create new channels that are currently missing.

Although the specific communication channels will vary a bit depending on the specific topic, here are some of the communication channels I recommend using:

• Email and chat: most companies rely on either email or chat as their primary communication vertical, but even in a company that predominantly uses chat, you’ll find some individuals who rely more on email and vice-versa. Everything important should be communicated across both
• Meetings: discussed in detail in meetings an engineering organization should run, are an important communication channel. Reiterate important topics in large meetings like a monthly all-hands, and also make sure to discuss the same topics in your weekly team meeting. It’s particularly valuable to establish a communication waterfall from the executive team weekly, to the weekly with your direct team, to your direct team’s weeklies with their teams, and so on
• Meeting minutes: most recurring meetings should generate minutes that document new information and resulting decisions. Sharing these minutes widely is a particularly valuable way to keep more folks aware without them feeling obligated to attend meetings where they might not participate
• Weekly notes: as mentioned above in Maintain the drip, it’s particularly valuable for executives to share weekly notes with their organization. I’ve found that only a subset of folks read these notes, but those that do tend to be loyal readers who propagate the information across their teams
• Decision log: it’s very helpful to maintain a decision log of recent decisions that a given product, team or organization has made. These are particularly helpful for acclimating new members of the team with the status quo and how you got here

Most importantly, communicate across every relevant channel. Any given individual will prefer one or two, and you’ll reach the full team by using all of them.

Communication is a habit

Good communication is a series of habits, and following these practices will raise the floor for communicating with your organization. The final, most important, step to communicating effectively is striking the balance between ensuring that you’re communicating what’s important, and leaving enough negative space for others in your organization to lead. That is the hard part, as it well should be.