A guide to scaling engineering organizations at Stripe—principles & FAQ
Since joining Stripe in 2015 I’ve worn many hats and taken on many “firsts” for the org — building the first PM team, writing engineering ladders/levels, leading eng/product recruiting, sponsoring /dev/start, setting up review forums for products, candidates and even incidents, and most recently becoming the first member of the leadership team based outside the US.
A lot of these firsts didn’t come easy and have significantly shaped my thoughts and instincts about scaling organizations. The work in this guide was done by an army of people across functions/teams (thank you!), but I’m incredibly proud to have contributed to these efforts along the way. The guide itself is pretty long and I’ve gotten some repeated questions about it, so here are some answers & principles behind the content.
Principles
0. Require active leadership
“Leadership buy-in” or “management support” are often considered prerequisites for organizational programs, but just getting sign-off or resources approved isn’t enough. For the most successful projects I’ve sponsored, I spent significant time in 1–1s and reviews, giving behind-the-scenes feedback (often critical), support (org projects can feel thankless, especially when done on top of “day jobs”), and recognition (celebrate org ships like product ones!). For new forums, I attended almost every meeting for months or even years, to spot improvements and signal their value — if other people’s time is required, they better be valuable enough for my time too.
1. Iterate, iterate, iterate!
When you’re operating in high-growth, you’re constantly dealing with new challenges as your {user base, infrastructure load, number of employees, legal/regulatory/policy requirements, everything?} doubles, triples, and grows in complexity. Accept the fact that ~everything you set up today will stop working at some point, so design for flexibility (not perfection) in your systems. In the same way you would launch a new product, start with a clear goal, run betas to test your hypotheses, roll things out widely when they’re working, and change things up when they’re not. Create a continuous feedback loop (and action the feedback!) to keep everything running well.
2. Size & scale really matter
The lessons in this guide came from growing Stripe from dozens to hundreds of engineers, while I led teams ranging from 15 (when I started) to 180+. I also wrote it entirely while working in San Francisco, but have since been on rotation in Singapore building a new team in a new country. All of the specifics were heavily shaped by the size and scale of Stripe at the time, and shouldn’t just be applied to your org as written — the best lessons are not the specific things we tried, but rather the meta-ones around iteration, feedback, and creating transparency.
FAQ
Q: Shouldn’t this guide be called “scaling software engineering organizations”?
A: Yea, you’re right :)
Q: What program did you use to create the diagrams in?
A: We have an incredible design team so it’s really the person (aka the talented Mercedes Bazan) that’s the answer, but she used Sketch.
Q: How does the recruiting process changes across offices? What do you do differently (if anything) to keep engineering culture aligned?
A: We believe in maintaining a consistent and fair recruiting process across all of Stripe, so we try to keep as much the same as possible. The main differences are logistical or geographic ones, such as sourcing markets (e.g. where candidates currently live) or where they do their in-person interviews (e.g. the office closest to them). That said, we’ve hired folks from/into different geographic regions, and for engineering commonly include interviewers from multiple offices on the same loop. For example, all of our recent hires here in Singapore interviewed with people based across {US, Singapore, Dublin} and went through the same interview content as everyone else we hire.
Q: What does “lurking” mean at Stripe, and do the norms mentioned apply to other communication channels (e.g. Slack) or just email?
A: From patio11 via https://news.ycombinator.com/item?id=18614460: “Stripe’s usage of “lurking” is a bit idiosyncratic. (There are a couple of other words like this, distributed in a glossary, the majority of which is less idiosyncratic word usage and more industry- or company-specific jargon.) In the sense used here, “Lurking into someone’s thread” means sending an unsolicited comment to a thread you were not an expected participant on.” Yes, the norms tend to apply to other communication channels as well.
