What it’s like to work for Stripe

A company’s culture is something intangible and nebulous, and yet it can be just as important to success as revenues or growth. Culture influences everything, from design and product implementation to the level of support and operations of a company. It’s crucial to get it right.

I’ve been at Stripe for a few months now, and I’ve wanted to write about what it’s like to work there. I’ve never been more impressed by the mechanics and culture of a startup. In fact, I’ve never seen anything quite like it.

Culture can be hard to define, and it certainly can’t be created with mission statements and performance reviews. However, there are certain steps that founders can take to create an amazing place to work. With that in mind, I’d like to give you a taste of what it’s like to work at Stripe.

 Email - complete transparency

By convention, every email at Stripe is CC-ed to lists that go to either the entire company or to any particular team. This includes internal person-to-person correspondence. Our lists include dev, sys, office, product and support. From the internal wiki:

It turns out that Stripe generates a lot of email. In most cases, this is quite an intentional, positive thing — it’s a great communication mechanism, persists forever, and is easily searchable. The reasons for CCing lists, is it’s a really low-friction way to keep everyone in the loop, and that way people can jump in with helpful advice.

It’s also a really good way to preserve openness as we grow (everyone still gets to see all the cool and important things that Stripe is up to) without requiring much extra effort.

This requires a lot of filtering, of course, but it allows me to dip in and out of the company’s fire hose whenever I want. It gives every one of us a tremendous perspective and insight into what other people are working on, and a feeling of connectivity to the rest of the company.

I’ve never before seen this level of access or trust at a company. Other companies preach fearless communication. Stripe practices it.

There are a few other email conventions. For example, whenever a new substantial feature is shipped, an email goes around to the shipped mailing list from the people involved. I get a few of these every day, and they’re often followed by a flurry of congratulations and gratitude from other teams.

 All hands

Once a week, on every Tuesday, the company meets for an all hands. Each team explains what happened in the last week and what they’re planning for the next. Again, this is all about transparency and communication.

At the end of the meeting we address FUD, or fear, uncertainty and doubt. Anyone can raise objections and discuss their concerns. The idea behind this, is that it prevents problems from staying hidden in one small part of the company, and makes sure everyone’s thinking about how to solve the problems we have.

The is the only meeting that everyone is required to attend. Meetings are expensive, so during the week we try to limit them to as few as possible.

 Group activities

When lunch arrives, an IRC bot (appropriately named nombot), announces the fact and the whole team relocates to the dining table. It’s important that everyone gets together at least once a day, and meal times are a good excuse.

Aside from mealtimes, Stripe has a social list, and there are often after work drink-ups, BBQs and parties. For example, we all went to a local theater recently for a showing of The Dark Knight.

In addition to that, once or twice a year we organize company-wide hackathons: we all head together somewhere far away and just hack on new Stripe-related projects.

 Everybody does support

Every single engineer does support, on a bi-weekly rotation. Even the founders John and Patrick. We provide support over an IRC channel, email, and through Stripe answers.

I’ve found providing support to be one of the best ways to learn about the company, how everything works internally, and our customer’s needs. I’ve been writing a bunch of tools to automate some of the most common queries, like chargeback evidence, but at the end of the day we want to ensure that there’s always a human available.

 Hackathons & Capture the Flag

Every so often, Stripe has Hackathons. On a weekend, we invite a few hundred or so people around, break out a truckload of Ikea fold-up chairs, open up the office, order sandwiches, and hack on whatever comes to mind.

With Capture The Flag, we host a series of challenges that involve exploiting security holes. In our first contest, we had people ssh into specially configured EC2 servers. In the CTF this week, we’re doing web vulnerabilities: CSRF, XSS, SQL injection and such.

I should stress that these are all independent initiatives from people inside the company. Anyone can come up with ideas like these and implement them.


Google Chat and group IRC rooms are as integral as email to internal communication. Instead of meetings, we just do short chat conversations. Rather than constantly interrupt people’s train of thought, we prefer to communicate asynchronously. Chat is often the happy medium between the latency of email, and the bother of in-person interruptions.

That said, sometimes it is much better to discuss things face to face. If someone hasn’t got their headphones on, then it’s totally acceptable to come over and ask them for five minutes of their time when they can spare it.

Also, an IRC bot messages me every six hours or so asking me to optionally reply with brief description of whatever I’m working on. It then displays what I wrote on some of our dashboards. This is rather useful, as it gives visibility at a company wide level into what everyone’s doing.

 Paper reading

Once a week, a group of us take a technical paper and discuss it over lunch. This week’s was Characterization and Measurement of TCP Traversal through NATs and Firewalls, about TCP tunneling through firewalls. In previous weeks we’ve covered Bitcoins and C-Store. As someone who missed out on that side of university, I find these particularly interesting. Often the papers are from domains that I have absolutely no previous experience in.


New employees are asked to send in specifications for their “dream machine”, which is then built and waiting for them on their first day. It turns out that the average monitor size at a company is a good tell as to how much employers care about first-class equipment and, in turn, their employees. Stripe gets this right.

For their first few days, new hires spend each day working with a different engineering group: product, systems, growth, ops, support. This is a great way to get familiar with what everyone at the company does, learn the codebase, meet everyone else, and make sure they can move freely across the company if they want to do so later.

 People & teams

None of this would matter if Stripe didn’t have fantastic people. Hiring well is the key to all of this, and people are the foundation of any company’s culture. Frankly, I’ve never seen a team like Stripe’s; we have the best people in the industry.

When you hire great people, you can afford to give them a lot of autonomy. Teams are made up of small numbers of people who propose ideas and then go off and implement them. There are no dedicated managers. So far, we have 31 employees. Each team is small and nimble, and there’s a heavy focus on shipping quality software.

Lastly, people are encouraged to be generalists, and not to be afraid of exploring unfamiliar domains. I’ve been doing a bunch more work with servers recently, and Darragh, who usually runs ops, has fixed the dishwasher.

 Patches welcome

Creating a great culture is key to an enjoyable working environment and ultimately, I believe, a successful company. It’s a shame when that aspect gets blindsided in lieu of other parts of the business, an all too common occurrence.

We’ve learned a few things about cultivating culture at Stripe, and we’re constantly experimenting and evolving. I feel incredibly fortunate to work in such a place, and I’m hoping this piece will be useful for people who want to create a similar environment.


Now read this

Chrome supports TCP & UDP Sockets

Traditionally browsers haven’t been able to make raw socket requests to arbitrary endpoints, mostly due to security concerns. Although the majority of browsers now have WebSockets, the caveat is that the server needs to have specific... Continue →