Avoid Trapdoor Decisions: 5 Lessons Learned from Scaling Stripe

Stripe is really a set of developer tools for building and operating an online business. We work with hundreds of thousands of companies around the world on accepting payments, expanding globally, and increasingly on innovating their business models for the internet and for mobile. I think it's really relevant to the SaaS audience because it's easy to underestimate how complicated a SaaS model gets, and we've increasingly worked to build solutions that you can just integrate with us and spend your time building the rest of your product. We built a new way of planning our products. What are we going to release for our users and working our way back from it. I'm an execution person. I was like, we got to execute on the plan that we made and it's going to make such a difference for our users and since we talk to so many of them, we'll feel it, I think, very acutely. Please welcome Stripe COO Claire Hughes Johnson. Uh, all right, we gotta get off that slide. Um, hi, it's so great to be back at SaaStr. Um, I don't think I've ever had a live band in my life this way before, so that's exciting. Uh, I do want to I'm going to start by saying that I'm a little worried about all the hype that Jason and Malan put out there on my talk. So let's all take a moment and lower our expectations. OK? So just be like, if this is any good at all, I'm glad I'm here. OK, good. The simplest way— I guess they played me describing Stripe, but we actually do more today than we did a few years ago. But we provide a combination of APIs and software. Or dare I say, SaaS, that help companies of every size, yes, accept payments, but also manage billing, tackle fraud, issue cards, and basically run your commerce side of your business online. We work with many of the companies who are here at SaaStr, Salesforce, Slack, Twilio, Zoho, and I hope many of you in the room. In fact, more than 80% of Americans in the last year bought through Stripe, but obviously through a business that ran on Stripe. So they don't know they're buying through Stripe, and that's fine. If you don't know us, I'd love to change that. Our team is in room 111 near registration. We're doing office hours all day. I'll be there after this talk. So would love to talk. But anyway, let's, let's get into some lessons, lessons learned. Before I get into the 5 lessons I'm going to share, I want to talk a little bit about 2 tenets that I think are really important to building a business. So the first one is you need to have a reason to exist. Um, Stripe's is to increase the GDP of the internet. I know that sounds kind of wonky, which is very Stripe actually. Um, but only 3% of commerce happens online today, which is really shocking when you think about how much technology matters to people's lives. And much of the industry's focus has been on increasing access to the internet, which is absolutely critical, but I would argue that access to commerce is equally critical if we're gonna really realize the opportunity of the internet. A lot of you know that Stripe was founded by two Irish brothers, John and Patrick Collison. They grew up in a rural town in Ireland. They were self-taught developers. They built their first company and sold it when they were teenagers. And afterwards, they realized that actually the hardest part of that experience was getting the payment acceptance piece. And that's what led them to found Stripe. And when I think about that story, I think about how concerning it is that there are so many companies around the world today that may not be getting started because of that kind of an obstacle. And that's why Stripe exists. Another tenet that I think is really important is that you gotta add value to the audience, uh, that you're seeking. And it's really true and it's really important if you're disrupting some existing industry, right? Payments has been around for thousands of years, the exchange of value. And at the risk of giving you a full Stripe sales pitch— don't worry, that's my other talk. Happy to give that later. I'd love to talk about what we set out to solve because I think it gives you a sense of the complexity that we entered which in some ways you think, was that a bunch of fools rushing in? But that's what it's gonna look like to change the GDP of the internet, in my opinion. So before Stripe, an online company that wanted to accept payments had to go prove themselves to a bank, which was like a weird catch-22 because the banks would say, can you please show us your payment and your revenue history? And the company would be like, yeah, but I'm new. And then it would just cycle and usually not end in a good place for that company. Then they had to integrate with credit card processors. Let's not forget managing PCI compliance, building the auditing and reporting features you need for that. And what about fraud prevention? I think most people don't know that online businesses are liable for fraud in a way that offline businesses are not. And finally, if you want to go to any other market, you got to repeat it all over again. And that's new integrations, new payment methods, and new compliance schemes around the world. It's pretty brutal, actually. So what did Stripe do? We, we removed a lot of the friction so that a business founder and builder could just focus on what they want to do, which is their product. We abstracted away a lot of the complexity of payments. When I joined Stripe, we only had— so that was in 2014, at the end of 2014— we only had one marketer and three people in sales. And the first thing I had to solve actually was handling our inbound lead volume, 'cause we could not get back to people. That's when you know you're adding value, when people are coming to you before you go out to them with your product. So have a reason to exist. Don't just grow for growth's sake. And solve a problem for your users so well that they are coming to you. I realize that neither of those tenets is particularly earth-shattering, but one of my first rules of communication is to state the obvious. All right. So let's talk a little bit about building Stripe. And hopefully some of this is useful to all of you. Stripe started nearly a decade ago. This photo is from 2012. And I joined, as I said, in 2014. In 2014, there were about 160 people mostly working out of this office you see on 18th Street in San Francisco. And our mission was very much the same, but our organization and the product were really not. The whole company was mostly full-stack developers based here, and there was no org charts. We didn't have a feedback cycle. Luckily, no expense policies. But we really even barely had managers. When internal issues arose, people worked them out either in a meeting altogether or at the coffee machine. And when external issues happened, it's all those hands were on deck, because we were already undersized. For the business we were building at that time, and frankly again when I joined in 2014. This photo is from a company gathering that we had in December. We're now over 1,500 people and we're available in 26 countries. We have teams specializing in everything from security infrastructure to machine learning to banking partnerships and integrations, and we process billion dollars of payments— billions of dollars for millions of customers around the world. But still, we have such a long way to go. When I think about the lessons that brought us to this place, the first one is to have fantastic people, like you see in this picture. The other lessons are the things that have stuck with us despite lots of change. And those are the ones I want to talk about today. So here's the list. I know you're all waiting for the trapdoor part of this talk. And hopefully that's not also a stage feature. But not to ruin it, those are in lesson 4. I can't claim that we're experts on scale. I actually get nervous about claiming that because we have so much left to do. But I do feel we've been able to scale rapidly without losing our roots. In other words, we're growing our company without growing out of what I think is a unique culture. And I'll talk a little bit about that. In fact, in this very first one. So using your principles. Well, what does this mean? Like, let's be honest, every company ends up having some kind of mission statement. The trick is writing down the operating principles that drive it and then using those principles to guide culture and company decision-making from very early on. When John Collison visits a Stripe office, and we have offices now around the world, Dublin, Ireland, of course. But Tokyo, Melbourne, Seattle, New York. And when John goes to those offices and he gets in touch with me or the country manager or the site lead at that office and says, this is really just like Stripe, it is the greatest compliment that they can receive and we can receive as we scale the company. But it doesn't happen by accident. Creating a culture that adheres to those principles and really honors the mission is a lot closer to gardening than architecture. It is not about writing a giant list of maxims and posting them to the wall. It's about living them day in and day out with a lot of deliberate attention, sometimes on a very small scale. And people really underestimate, I think, what that takes. Let me give you just a few examples. So first of all, these, these are operating principles. We've actually worked on them and reworked them a few times. In my opinion, there should be fewer than 10 To be truthful, fewer than this. We really had trouble editing ours down, and I worry not every Stripe could repeat them, which means there's a little bit of a lesson of failure in this one, and I'll admit it. But really, these principles should be like a good brand: relevant, believable, enduring, and deliverable. They cannot just be aspirations. They actually have to be reflections of your DNA. And the way we test this at Stripe is anytime we make an edit, we crowdsource comments across the company in a Google Doc on the changes we're proposing making to make sure they still feel real to people. It's okay for principles to actually change, but the underlying beliefs and assumptions that you cement early on should serve you from tens of people to thousands of people. I think of operating principles really as the Constitution versus the law. And they're founding documents that are going to matter to your future leaders, people you've not yet met. And it will help them decide what to do, I hope, and what not to do. But most importantly, it will help them decide how to do it. One example of how we use our operating principles is in our hiring process. All candidates who come on site for an interview at Stripe get sent a document with our principles outlining how we work and what we value. It's an external-facing version of some of the internal work we have on this. And we ask the candidates to read it. And I don't think you'd be surprised to hear some people actually take themselves out of the process cuz they don't see themselves in how we work and what we value at Stripe. It's pretty rare, but I actually think it's a good thing because we also have candidates who come in and say part of the reason they decided to work at the company was because of that document. You really want to add people who want to be there and who have full information on what you are and what you do. Another way you know your principles are really being used is when you hear people actually using these exact words in meetings and invoking them. Some teams like to invoke certain principles a lot, like our finance team loves efficiency is leverage, and that is code to them for let us cut some costs here. But this can work in sales deals. It can work in internal disagreements. But the true test is really the usage internally. And the way you get there is that you have leaders and early employees really embody the principles and use the language. I think this is kind of like how you teach in medical school, right? See one, do one, teach one. Watch a leader take what feels like maybe a minor decision, which is what software should we start using to send customer emails? And then explain to the room how it's actually foundational to your future scale. And the entire room will shift at Stripe from moving with urgency and focus to reasoning clearly and building a meticulous foundation. The trick is to use the principle in a way that expresses the underlying value. And I'm going to talk a little bit more about decisions, because if you're not making the right decisions in the right way, you're going to end up in one of those trapdoors. Um, I think our most important operating principle, and one that has never changed, is to put users first. Uh, in our onboarding classes for new employees, we get on a support call, the whole class, with a user, and we get their feedback and we hear their experience. Just sends a message that the principles are real. I think more importantly, we use it when we build our products. Uh, we applied this principle when we launched Stripe in Japan in 20— 2014, I think it was end of 2014. So this photo is a classic. Japanese press really likes to take a celebratory photo, especially when you do a partnership. And Patrick got kind of roped into this hand-stacky thing. I got away with a handshake when I was there last year announcing another partnership, but they asked me to high-five and I was like, no, I'm not going to high-five for the photo. Okay. Back to the users. Multi-currency processing in Japan, because most of Japan transacts in yen, was something a lot of our prospective users wanted, and we were hearing from a lot of startups in the ecosystem, but it was not actually readily available in the Japanese financial infrastructure. So we actually did a partnership with a local card company in order to build the rails so that local banks could accept currencies other than yen. Which really meant we had to delay our launch and take the time to build what our users needed and what the market lacked. But it was worth it because it gave us not only something for our users but also something important in the market. And I know you're thinking, wait a minute, that must be increasing the GDP of the internet. Okay, it was just me maybe just thinking that. Um, alright, so let's talk more about users. Let's talk about knowing your forever user. No matter how many employees you have or what markets you operate or what vertical, I think you can often fall down if you don't know your forever user. At Stripe, our forever user will always be the developer, and we're always going to start first with developer tools. Today, our users are fraud teams, support teams, finance teams, even the commerce teams at SaaS companies who are using our billing product. It's for recurring business models. But the developer is the DNA in the company, and it comes from two places. The first is a belief, which is we don't assume that we know exactly what another company wants. We're giving developers at those companies the tools to build what their company needs. It also comes from an insight on which Stripe was built, which is developers are increasingly the decision makers on the software that a company buys and integrates. And if you don't celebrate and build the product for them, you're not talking to the right decision maker in the end. Um, so I think you all might have a different forever user. Could it be an IT manager, an HR person? But I think it's worth talking through what it looks like for us. Um, it started out looking like John and Patrick actually showing up at the offices of sort of technical founder, new startups and asking them for feedback on Stripe. And asking them if they used Stripe. And if the answer was no, they would do— they would sit down, open their laptops, and integrate Stripe on the spot for the company. We used to call it the Collison installation. And there are still founders today who I meet who tell me the time when John and Patrick showed up, or one of them, and helped integrate Stripe for their company. So if you know your forever user, you're showing up at their doorstep a lot early on, and you're always honoring their feedback. Even today we have a mailing list with our leadership team. If we get a certain type of complaint or concern from a user, one of us reaches out. I have had a few people— just yesterday, one named Alejandro asked me if it was really me. How is it that he— because he felt like a small customer. And I was like, no, you're an interesting, important, aspiring, growing internet company, and I want to talk to you and I want your feedback. It's really built into how we do things. It's also built into the experience for the customer. I'm just going to run through a few examples of what we do for the developer audience, but some of these lessons probably apply just a little bit differently for other forever users. Our first lesson is you got to have a speedy on-ramp. Developers don't want to spend 10 minutes filling out information. They want to try the product right away and test it. The inclusive thing to do for our users is to have as many programming languages as you possibly can. It has to be be incredibly diverse. We release an SDK, a developer kit, for every major environment to make it easy for developers to get started. More than you can imagine. Languages I didn't know existed. Let's put it that way. We obsess about our documentation. It became really, really important, especially early on, but still today. Our documentation is much less of a static user manual or what you'd see on a normal site. It's actually interactive. You get code snippets. It can jumpstart your integration. And we built our brand actually on the simplicity and usability of that documentation. Today, if the documentation is not ready or not good, we will not launch. And we have blocked some launches because it was not up to our standards. Support existed at Stripe from the very beginning, and our early support team was engineers, engineer to engineer, developer to developer contact. That's incredibly powerful. Today we have a dedicated support engineering team. They're in IRC, they're in Stack Overflow, they're on email answering questions from developers and fielding feedback internally when we find things aren't working as well for our user. Um, your onboarding, your site and how it engages your user, how you communicate, all should be uniquely designed with your forever user in mind. All right, so let's talk about everyone's favorite thing. I know this. Process. Let me say something controversial. I think process is good. Unfortunately, in young companies, there's like an insanely strong aversion to process because it feels like you're giving something up. You're giving up some kind of freedom. I get it. But here's, here's how I think about it. Say you gave a bunch of people some random sports equipment and you sent them out into a field or into the park and somewhere near here in San Jose that I know is like in downtown San Jose. And you said, "Play." And there's no rules. There's no officiating. There's no rules. There's no sideline. There's no way to win. No objective. You know what's going to happen is someone's going to get hurt. When I tell that story, I always picture someone with a field hockey stick whacking a football into somebody's face. Those things should not be on the same field together. This happens in companies too, by the way. Something goes wrong. Hopefully people aren't getting hurt, but you're losing a sales deal, you have a bad press event, you lose a candidate that you wanted to close. And what happens to companies when something breaks or there's a mistake is they overcorrect. Usually they overengineer and bring in this top-down heavyweight insane thing because this mistake happened, and then people hate it because it's too heavy. So don't overcorrect. There is another way. Lightweight processes increase speed. They increase clarity. I built a really short candidate review process when, for new hires, when we wanted to sign off to make sure that the process had been good and that we wanted to hire that person. It still exists today. I'm shocked, to be honest, 4 years later, because recruiting loves it. The executive team loves it. It's just a Slack channel with a little template. It's like a bot and we all love it and it is very light. So if you can build something that can last for that long, you're on the right track. Speaking of hiring, we used this idea of lightweight process early on when we were starting to hire developers. Now admittedly, it's a little easier because developers were our forever user and we were developing some fans and some folks who were willing to do this. But before we hired some folks again, very early on at Stripe, we just have them come and work in the office. We'd have them do bug squashes, do some integration challenges, work with our engineers on helping improve Stripe. And it was great. It was a great way to gauge employee fit. It was a great way for them to get a sense of the company. There's actually a company in Japan who runs on Stripe called Wantedly that is actually really impressive. It's founded by a woman. She's one of the only female startup CEO founders who's has taken her company public. And what Wantedly does is kind of a similar thing, which is it's like a matching service where a prospective employee says, "I'd like to go work in your office and see it and like get a feel for the place." And they arrange that with the recruiting team, which seems so smart. Like, why don't more people get a chance to go work in an environment? So that's what we did. And a lot of what we built for the integration challenges and the bug squashes are still in our recruiting process. They've evolved from these early days. but I think many of you could employ a similar thing depending on your size. Um, again, this also applies to products. I don't know if you're familiar with our Atlas product. It's a toolkit that helps businesses incorporate and get online. Businesses in the US or around the world. We have a lot of entrepreneurs in countries that don't have access to easy incorporation use Atlas to incorporate in the US. There's really a temptation, and I don't blame you, after talking about the forever users, to over-polish every product launch and to have done all of the heavy lifting to support it. Atlas uses a lot of partnerships, right? There's a tax component to this. There's a legal component to it. And we could have built very heavy integrations with all of those partners. Instead, we did just a lightweight process. Don't tell anyone, but we had 2 Stripe employees faxing in Delaware paperwork for each Atlas user by hand. For a while. And once it was proven, we hired more people, we built the integrations, we built more of the structure of the product. But the initial lightweight approach was a great test of whether this was an interesting product to people and what we needed to build in the future as opposed to building it before the launch. All right, I know you've all been waiting for the trapdoors. They are now happening. We're going to talk about preserving optionality. One of the examples of things that happens when you're growing quickly is you solve something and the minute you solve it, it breaks because you've gotten bigger and you need it differently. This happens with office space, right? The minute you move into one space, if you're growing as quickly as Stripe has— for me, I've been looking at the new office space like the next week after we move in. And when I think about the most valuable currency for a young company, actually for any company, I think it's to preserve optionality and not end up in a trap. Avoid making decisions that are irreversible as often as you can because they take a ton of time and you can't unmake them as easily, which takes even more time when you're faced with having to unmake them. You've probably already made a decision like this. I think hiring a very senior leader can, can be a bit of a trapdoor. Just because they have such an impact on your culture. But you can unmake that. It just can be messy. But what about acquiring a company or publishing your pricing on your site and then realizing, eh, now I want to change it? And you gotta change your pricing in front of everybody. There are trapdoor decisions. Really know when you're making one and try not to make so many in the beginning. This is the decision-making framework I talked about earlier. This is not news. It's not unique to Stripe. Um, Jeff Bezos talks about Type 1 and Type 2 decisions. What's really critical about this framework is just one, know if it's irreversible or very difficult to reverse or very tunable. So know that and then know how high impact it is. I think changing your pricing for your product around the world is in that upper right quadrant. We found this really useful at Stripe. Because luckily a lot of decisions are not in that quadrant, and if you can teach your organization to move quickly and bias toward action almost in every other quadrant, you're gonna be a much faster-moving company. But the other thing is you need the rigor to come, the details, the research, the user experience testing when you're in that upper right quadrant, and everyone needs to learn when you're there. Something that feels actually quite small, but I think is something that benefits a lot from optionality, is giving titles to people. I recognize I say this to you as Stripe COO, so let's ignore that for a second. That's kind of a non-title anyway. But titles are really important to people, actually. There's been some studies where the majority of people would rather have a title, a seniority increase in their title, than a small increase in pay. Like, it's valuable. We're humans. We seek status. Right? We seek survivorship and status. So they're important. But if you go down that path too early, it's very hard to go back. I think most businesses make the mistake of over-structuring and over-committing to the names of people's roles too early. And when the company grows, you're going to need different skill sets, different specializations, more experience, different experiences than you start with. So let's just use, say, marketing as an example. When you're a 50-person company and you've got a couple people in marketing and you hire someone to manage that team, I hope you're not giving them the CMO title. Because what's gonna happen a few years later when you're 50 people in marketing and you want to hire a leader over that person who was managing marketing? You're not gonna have two CMOs. So then you're gonna have to have a very difficult conversation. You might miss You might lose someone who's talented, who's been helping to manage the team, and not benefit from bringing in that experience. It's not going to be a fun conversation. Don't build a lot of that debt too early. For new hires at Stripe, the reaction to not having a title is actually a good signal. We mostly call our roles what they are, like account manager or recruiter. And if they're cool with that, it means they get their culture and they get what stage that we're at. This may change over time, but it has served us incredibly well. Getting people used to flexibility and change early on benefits you more than you realize. It's a great way of making a non-decision that helps you preserve optionality. Let's talk finally about naming things. It's really the sister lesson to preserving optionality, but I think it deserves its own, its own section because this is the thing. I know people ask me, what surprised you when you joined Stripe? And there are surprises. I find the payments industry fascinating. But really the thing that surprised me the most is how many things you have to name. I mean, it's shocking. You name teams, you name products, you name organizations, you name processes. You have to name every freaking thing that is happening around you, even your meeting rooms. And it's exhausting. And then the names do this annoying thing, which is they stick. And they stick in ways that aren't always helpful. So there's 3 things I think you should know. The first is that they stick, and if they're a good name, it really sticks. One of our weaknesses at Stripe is we really love to use the word ops. Ops is super popular. These are all names of teams at Stripe for reals. And, and they all do actually very different things. So it's very confusing that they're all called ops. But we were preserving optionality. We kind of like the idea, look, we're building right now. We got engineers building and we got operators. That's what we got. So you're either ops or you're engineering. Yeah, it's actually been kind of a challenge. It's hard to know what all these folks do. And so there's one solve for it, which is you can just take out the ops and call the team the umbrella name and then build the specialized things underneath. And one thing we have had to do is just use some industry terms for a few things like this is our benefits team. HRBP sounds very corporate, but people know who they are. And that has helped. But I'm going to be honest with you and tell you ops is still extremely prevalent at Stripe. We have an entire organization now called ops. Yet a lot of these teams with ops in the name are not in the organization. Long live ops. Watch out for names that stick and names that get used by everyone. Here's another thing about names. They should help people understand. If you're going to name something, an unusual thing, an abstract concept of fruit. You are gonna spend a lot of money on branding and marketing to explain what that name means for your company. I know this is obvious. Apple is actually a company that I think has done incredibly well cementing what their brand means. But you'll notice that Apple doesn't name a lot of its follow-on products abstract things. They're things like Apple Music. You know what that is. Or you know what the iPhone is. It's a phone with an I in front of it. You know, it's not hard to understand. But it's really expensive to name something, something abstract or that needs explanation. Guess what? We have messed this up. This is a slide with our product names. I think there's a little mix that you're probably noticing here. Issuing is like issuing credit cards, so that's pretty— payments, hopefully you know what payments is. But what about Radar? Radar is our fraud product. Or Sigma, if you think about it for a minute, it's analytics. Get it? The sum. Very cute. We almost called our billing product Orbit, so that would have been really awesome because what does that mean? Some of you guys are looking for subscription billing. I don't know if you would have gravitated toward Orbit. So we've really not learned this lesson, and it's really hard on our sales and marketing teams because they have to explain these products. We don't invest a lot in marketing, so our site has to explain these products. Don't forget to name things descriptive names that help illuminate what they are unless you're ready to invest. All right, I've kind of depressed myself now because that's like one of those trapdoor situations. That I talked about. Okay, here's the ones that's a little more fun. Think about names in a system that helps people understand. At Stripe, we always try to name our conference room something like more interesting than just a number or a very predictable, like, after all the currencies or all the payment methods. We could have done an obvious thing. We weren't sure what we wanted the theme to be early on, and our first naming scheme came from Patrick. If you've read about him or follow him on Twitter, you won't be surprised surprised that his naming scheme was scientific papers. He put copies of the papers up in the conference rooms. And that didn't really last very long. Interestingly, I love human behavior, people actually actively avoided meeting in the germ and penicillin rooms. So we switched to animals, which is good. There's a lot of animals. And as you can see, all the photos on this floor in our building are birds. And the floor is an upper floor. Or get it, the birds in the sky. Anyway, make it make sense in a system. Okay. So names are important. They're going to stick. They're going to become infused in their culture. They're going to be hard to change. And they should exist in a system that makes sense and be descriptive and useful. Really treat it quite as seriously as you would treat naming your company. Thank you so much. I think many of these lessons are obvious. I found that scaling a company is easier to describe that it is to do, because what's happening is it's all happening at once. But when I go to these events, I hope I take away one or two things. I hope you all did as well. And I guess I'll close really with reminding you of what I started with. It's all about the reason you exist and the value that you add for your user. When things get tough for your team, your product, your users, that's the center that will hold. And that is what's the most important lesson of all. Thank you so much.