How I write group emails at work.

I believe for most folks working in technology, our most important daily contribution is communication. Being an effective communicator is a critical skill for career success in management, but we tend to look at communication as an innate thing that we should avoid training folks in. I think that belief stems from growing up pickled in the liberal arts, where you are trained to view writing as something deeply personal, even an expression of personal style.

As I started exploring into this idea, I became enraptured by the idea that consultancies teach new hires their writing style, for example The Pyramid Principle at McKinsey, and whether maybe more companies should follow suit.

The next step I took was to codify the group emails I send at work, systemizing how I approach writing them. Taking something I already feel confident about and systemizing it was initially awkward, with quality and speed going down as I regressed from skilled amateur to professional email author, but the overall experiment has been enlightening.

I think this kind of codification can be particularly valuable in rapidly growing companies, where you have large influxes of new employees who are unfamiliar with your communication norms, and also the fluxuations in company size require continually rethinking of communication mechanisms.

Without further ado, the four kinds of email I write.

Four formats

When I start writing an email, I try to answer two questions: who is my audience? and what outcome do I hope to accomplish? Based on the answers, I pick one of four formats:

• Brief: a concise email, which conveys information, bolds key components and links to background context. This email has little structure, and especially no narrative, no intro, no conclusion. Do add link to external context so readers can explore topic. The aim is to be as efficient as possible with the reader’s communication bandwidth. I use these for small topics with stakeholders, executives and folks within my team.

• Proposal: if you want to change someone’s mind about something, then write a Proposal. It should start with a Brief, and then follow the inverted pyramid. Start with specifically what you want to do, follow with guiding principles that lead to those specific actions, and then end with surrounding context that was fed into the guiding principles to generate the actions. The most frequent mistake I see is starting with context first, but you want to write the note assuming that most folks will drop off quickly over the course of sentences, so leaving the conclusion to the end means most folks will stop reading before they know what you want to do.

• Context: if you want to periodically convey a bunch of state on a topic to a wide audience, then write a Context email. Structure is to start with a Brief covering the delta from the previous update, and a link to the previous update. Then follow with a metrics review of how metrics have changed since last update. Include a section on project updates, and then finally finish with what you’re doing next. Keep descriptions to a sentence, and link out to background context. The goal is to make this email as dense as possible, and assume many folks will only read the Brief, and most who keep reading will do so to skim the Metrics for surprising trends before moving on. Only a few will read the entire email, but those are the folks who have a dependency on you or who you have a dependency on, so it’s still valuable! The goal of this email is to give enough context as early as possible for folks to get comfortable and stop reading. It should answer enough questions that very few folks finish the email without getting comfortable.

• Narrative: a long email with a complete narrative structure, starting from why someone should care, background and leading through the effort and conclusion. The aim of this email is to provide enough context and information for folks without background in a topic to appreciate why it’s important and why what’s been done is impressive. Always start with a tl;dr section at the top which should follow the “Brief” format. If you don’t add the brief, most folks won’t read the email at all. If you do add the Brief at top, most folks will read that then bail. Only a few folks will typically read these, but those who do will learn a lot, and you’ll probably change their minds about something, which is a rare, valuable thing! These are also great artifacts to reference in onboarding, link to from future Brief emails, and for remembering what you did last year.

Generally speaking, I believe long emails don’t get read, and try to use a Brief whenever possible. Usually when I’m tempted to write a Proposal or a Context, then I’ll write a separate document and write a Brief that links to that document. The exception is when I’m hoping to spur a conversation with a group of folks over email, when I’m hoping folks might read the email when they have a few minutes with access to their email but not documents (probably on their commute), or attempting to follow existing social norms.

Proofreading

I don’t think I would have believed this even two years ago, but at this point I write the vast majority of my emails collaboratively, having at least one other person edit and provide input. Typically that person is either one of my peers or one of the folks I manage, and the goal is to ensure it’s clearly written and has been thought about from a variety of perspectives (for example, employees not working from the San Francisco office).

This has been the most important change in how I write emails, and has significantly increased their quality.

Should you also develop a bit of an algorithm for writing emails? Yes! I think you should. Don’t keep doing it the way you’ve been doing it since your first job / college / wherever you first learned about email norms. It’s powerful to keep experimenting with the basics.