Update: in December 2014 (about a year and half after this post), we blogged about our experiences scaling email transparency.

A few months ago, Alex blogged about how we work at Stripe. In the post, he described how almost all of Stripe’s email is public inside the company. Since then, many people have asked about how this email openness actually works. Is it really the case all our mail is copied to a list? If so, how do we avoid drowning in email?

This post is an attempt to describe a little more about why we do this and how we stay afloat.

Background

Initially, the motivation for having all email be internally public and searchable was simply to make us more efficient. If everyone automatically knew what was happening, we needed fewer meetings, and our coordination was more fluid and more painless if we could all keep up with the stream.

As we’ve grown, the experiment has become about both efficiency and philosophy. We don’t just want Stripe to be a successful product and company. We also want to try to optimize the experience of working here. As as we’ve grown, we’ve come to realize that open email can help.

We value autonomy, rigorous debate, and avoiding hierarchy to the extent that we can. Startups often pride themselves on having a flat management structure but are eventually forced to put a formal coordination infrastructure in place as the number of actors grows. So far, our experience has been that an ambiently open flow of information helps to provide people with the context they need to choose useful things to work on. It doesn’t eliminate the need for other kinds of structure, but it does make emergent coordination much easier and more likely.

It also makes it more likely that controversial issues are addressed as they arise, counteracting inevitable conflict-avoidance tendencies. The open flow obviates a lot of internal politics and avoids the sort of accidental surprises that sometimes crop up in organizations. It also makes everyone happier. Most people at Stripe are information junkies, and are naturally curious about how other parts of the organization work. We want to encourage that.

Tools

While the principles might seem worthwhile, the obvious question is how it can actually work in practice. The amount of email we generate increases at least linearly with number of people. How do we avoid being overwhelmed?

Over the last two years, we’ve gradually added structure as necessary in order to keep things under control. What we have today works pretty well for our current size—around 45 people.

We use Gmail for email and Google Groups for lists. We’ve been able to scale our particular usage with a custom list management interface built on the Google Groups API. The interface makes it easy to manage list subscriptions, get notified of new lists being created, and so on. (We plan to open-source it at some point.)

Once people are subscribed to the right lists, dealing with the large volume of email efficiently is the next step. We use a number of filters to ensure that the traffic gets sensibly handled and categorized. The vast majority of our email is automatically labeled, archived, and then skimmed occasionally. The semantics can get pretty subtle, and Andreas wrote a filter manager that many of us use.

List structure

We have 119 lists as I write this post. Most of the lists are specific to a particular project, but some (such as 311@, if you have an issue you’re otherwise not sure where to send, or shipped@, where you announce something you’ve launched or completed) are company-wide.

In order to make this work, strong and clear defaults are important. Here’s how the structure is described on our wiki:

Stripe lists follow one of these forms:

foo-announce@: Email from the foo project to the company at large. These lists are generally low-traffic, have self-contained postings, and are intended for people who aren’t keeping up with the project in real time. For example, recruiting-announce@ is where we post notifications of job offers and outcomes thereof.

foo@: Email that would be on a traditional discussion list goes here. In other words, pretend that foo-archive@ did not exist. In that universe, would you send you mail on-list or off-list? If on-list, send to foo@.

foo-archive@: Email that you want to grant other people read access to, but don’t have any real expectation of them reading. Use this for email that would traditionally be off-list, whether due to volume or being targeted to a particular recipient or just being generally uninteresting.

foo-bots@: Automated mail for the foo project goes here. Depending on the project, it may be important for you to read this email. (For example, all breakages go to breakage-bots@, and so people who are triaging breakages should watch that list.)

In general, if you’re debating including an archive list, you should probably just include it. This includes internal P2P email which you would normally leave off a list, emails to vendors, and scheduling email. (If the email is sensitive in some way, though, it’s fine to leave it off-list.)

What you should read

• You should definitely read any email sent directly to you.
• You should at least skim (or skim the subject lines of) all emails to the foo@ list for the project you’re currently working on (e.g. product@, ops@, etc.).
• You should feel no obligation to read any foo-archive@ lists. If you find yourself having to trawl through those lists in order to get things done, that means that foo-archive@ is getting traffic it shouldn’t.

You should also keep these conventions in mind when assessing what mail you expect other people to see. In particular:

• You should expect mail sent to a person to be read by that person.
• You should expect mail sent to a project list to be read by most people working on that project.
• You should not expect mail anywhere else to be read by a human.

Email Use Cases

We support the following use-cases. Details about which list to send to in each case is shown below. If you ever find yourself thinking hard about which list to CC, just pick one—it’s not a big deal to have email go to the wrong list.

• human → external human (e.g. Darragh → banking partner):
  • CC a project list (project@): when you want the outside human to know they’re on-list, and respond including the list.
  • BCC a project list (project@): when this is something you’d like others on your project to be aware of.
  • BCC a project archive list (project-archive@): when this is something no one else needs to care about at the moment (e.g. scheduling a meeting time with someone).
  • Leave off list: if there’s personal content that you’re not comfortable with others seeing (this case should be pretty rare, and tends mostly to come up when recruiting friends).
• human → Stripe human (e.g. Andy → Sheena):
  • CC a project list (project@): when this is something that you’d like other Stripes to be aware of or feel invited to participate in.
  • CC a project archive list (project-archive@): when no one else needs to be thinking about this problem and you’re having a direct conversation.
  • Leave off list: when you have constructive criticism relevant only to that person. You should always feel free to point out problems and places for improvement (trying to maximize quality is pretty core to Stripe), but this is one case that’s generally better to handle in private. (Still, broader questions like “should we even be working on this product” are usually best handled on-list.)
• human → project (e.g. Greg → people working on systems):
  • CC project list (project@): always.
• human → company (e.g. Amber announcing the attendance numbers from a hackathon):
  • CC a project announce list (project-announce@): if there is a relevant announce list.
  • CC all@: otherwise (you should feel welcome to post stuff to all@—current traffic is about 10 messages a day).
• robot → project (e.g. PagerDuty to developers):
  • CC a project-bots list (project-bots@): always (note that bots lists all have a Reply-To set to the corresponding project list).
• robot → company (e.g. hourly stats report):
  • CC all-bots@: always

One important property of this setup is that it’s opt-in: no email is automatically made public, and what lists to copy (or not) is a decision that’s taken on a per-email basis.

As with much of what we do, we’re not sure yet how this will scale. Still, most of the experience of a startup is doing things that work well at some size, and then figuring out how to make them continue to work as you grow. The email transparency is something that people consistently identify as one of the best parts of Stripe’s structure, and we plan to work hard to retain its core properties as we grow. If you end up implementing any of these practices in your workplace, I’d be very curious to hear how it goes