Working at Stripe in 2015

It’s been over a year since I left Stripe, and I haven’t really written seriously about my time there yet (nearly a decade). Time to jot down what I remember, before it starts to fade (time dilation as a founder is wild, I feel like it’s been several years already).

I was #120 or so when I joined Stripe in 2015. Quite a large group of people, and the way they operated felt really unique then (and still does now). Especially when I hear folks describe the structures at startups of a similar or smaller size! Stripe’s cultural influence on startups was huge, but there's still a lot to learn – interesting to reflect on this in light of Paul Graham’s recent post on Founder Mode.

• Nearly zero PMs and EMs. Engineers were expected to manage the product and themselves. In my half of the org ("the user-facing things"), there was 1 PM and 1 EM – both felt like pretty experimental roles at the time. There were, of course, important non-engineering roles: design, business, support. Dedicated sales folks arrived relatively late (in my year, 2015).
• Relentless dissatisfaction “we haven’t won yet”. "Like many companies, Stripe leaders would review metrics at All Hands. Unlike most companies, whenever we were ahead of target the presenter would, in the same breath, remind everyone of how much there was left to do. Continued success is not preordained. Fight complacency with humility and hunger."
• Extreme writing. The firehose of information.
• Radical transparency. Archive lists. After sending sales emails, I’d often receive replies from random Stripes not on the thread. They’d read my note and wanted to offer feedback. At Stripe, every employee could read all customer facing emails - and many did! In fact it was advised to CC topic-specific company-wide mailing lists every time you sent an email. Transparency ensures the best ideas are surfaced.
• A specific breed of intellectualism, optimism, progress studies. Stewart Brand and Alan Kay.

---

References

Patrick Collison, Does Stripe have Product Managers

There was an old Quora question that Patrick answered at the end of 2012. It's increasingly hard to find Patrick's response on the internet, so I've copied the full text here.

We don’t have any dedicated product managers today. Or, more accurately, engineers manage products themselves. I think there are a few reasons as to why this is working well for us today:

1. The engineers who build our products enjoy, and are good at, figuring out what the product should do — not just how the implementation should work.
2. Most of the people who work directly on the user-facing parts of Stripe have managed products before and enjoy the process of figuring out how they should work and what they should do.
3. We’re still pretty small. So far, our workflow has been to have the people doing the implementation work directly with the rest of the company to figure out the non-engineering work that arises. It works well today, and having the complete picture in someone’s head has a lot of value.
4. The engineers building the product are pretty self-sufficient and are able to hack on most levels of our stack. If someone wants to build even a major new feature, it doesn’t require a coalition of engineers and a manager to oversee the effort.

There are obviously many great product managers in the world. Still, to the extent that having a “product manager” implies having a separation between the person who builds the product and the person who manages it, a few downsides seem to come up repeatedly:

1. They can slow the iteration that’s at the heart of creating great products. If the same person is designing and implementing, the feedback cycle takes place within that person’s head. Even if product managers have equally good ideas, they’re likely not able to experiment with as many of them.
2. Though this certainly doesn’t always happen, I think it’s easy for product management structures to make programming less fun. Most people fall in love with programming because of the ease with which you can jump from an idea to a tangible, working reification. If that path takes a detour through a product management organization, a lot of the joy can dissolve. I’m always worried about trading off enjoyment for ostensible efficiency. Even if it is more efficient, if someone ends up spending 30% less time hacking on a project because it’s just less enjoyable, you’ve probably still lost.

Many people at Stripe have founded start-ups before, and part of our goal in shaping the company isn't just to build a successful product, but also to create the best long-term work environment we can. If something is immediately expedient but will lead great people less satisfied over the long-term, we don’t want to do it.

In building a product, I’ve always thought that “consider doing some things that don’t scale” is pretty good advice: manually add content, go visit your early users in person, review all the contributions by hand, etc. Figuring out how to eliminate the unscalable parts as you grow is much easier than trying to design the scalable solution from scratch.

We‘re trying to do the same thing with the Stripe organization. (Almost all of our emails are internally public. How long can we sustain this? I’m not sure.) We’ve hit lots of bottlenecks, and the claim here certainly isn’t that we’ve figured everything out.

Still, not having product managers is working well today, and my suspicion is that we won’t end up with something that looks exactly like most other technology companies. But it’ll be interesting to see how it unfolds.