Internal comms for executives. @ Irrational Exuberance

Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Internal comms for executives.
- What does it mean to be a cost center?

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.

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.

What does it mean to be a cost center?

When I shared my piece on Measuring an engineering organization, one point I made was that focusing too heavily on optimization metrics (e.g. things like CI/CD time) can turn engineering into a cost center. That’s not because optimization metrics aren’t important, they’re extremely important! Rather, it’s inherent to what it means to refer to an organization as a cost center.

First, an obligatory definition from Investopedia:

A cost center is a department or function within an organization that does not directly add to profit but still costs the organization money to operate.

That’s a pretty dry definition! In practice, “cost center” is often tossed around to refer to an organization that is underfunded and whose requests are held to a higher standard. One painful real-life example came from friends at a well-known tech company where only engineers were allowed to eat the free lunch. Other organizations were not invited. When your expenses are being monitored so closely that your organization is excluded from free lunch, that is being a cost center.

However, I think this common usage isn’t very helpful. If “cost center” just means that a function feels underfunded, then every function probably feels like a cost center in a funding era like 2022 when companies are slicing valuations, struggling to raise additional capital, reducing hiring plans, and frequently laying off large parts of their existing teams.

I’ll offer a definition that I find more helpful:

A cost center is a function that is operated by optimizing its existing components.

This definition gets at the root of why I think explaining engineering’s contribution through optimization metrics is a flawed endeavor. When engineering departments ask their CEOs and Boards to evaluate them through the context of optimization metrics (“cycle time decreased by 20% QoQ!”), they are training those bodies to evaluate them as a cost center.

For example, let’s say that you’re reporting on cycle time, and that cycle time has gone up. There’s a potential problem to dig into there, and you will likely create some real value by addressing it. However, what if cycle time went down: that should mean that you’re doing well as an engineering org, right? It might, but it might not. You can be a very effective engineering team and deliver very little impact because you’re shipping the wrong work. You can even be a bumbling, inefficient engineering team but still deliver significant impact by shipping the right work.

Disproportionately impactful engineering teams are distinguished by effectively shipping the right work. System optimization is part of that remit, but only part of it. The larger aspect is shipping the right work, and that’s an aspect where your CEO is actually well-positioned to help you. If your CEO is in the trenches working with you on reducing your build times, then you’re in a lot of trouble (either they aren’t doing their job or they are doing their job and they think you are not doing yours). You should be optimizing the engineering organization’s operations, and should rarely need to surface those details upwards unless you want to occasionally brag (yay, we’re good at this), are asked to provide deeper context, or need to justify an investment.

Conversely, pushing the company to pick the right work to do is very much in a CEO’s wheelhouse, and a place where you should be escalating to get visibility, alignment and support. The first rule of managing up is to focus your manager’s attention on areas where they will be useful and you need help.

Anyway, optimization metrics are very important to running your organization well, are terrible for reporting upward, and don’t forget to focus at least as much on what the team is doing. Most engineering managers default to a focus on efficiency, but in an executive role, you’re held to outcomes first and foremost, so don’t necessarily focus where it feels most comfortable.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!

This email was sent to you why did I get this?    unsubscribe from this list    update subscription preferences Will Larson · 77 Geary St · co Calm 3rd Floor · San Francisco, CA 94108-5723 · USA