CS183C Session 11: Patrick Collison, Stripe
For today’s class session, John Lilly interviewed our special guest, Patrick Collison, Social Media Manager (and founder) at Stripe.
Q: Tell us Stripe’s founding story.
A: I’m always a bit skeptical of founding mythology. For Stripe, it’s not that dramatic. John, my brother and co-founder, and I were both in school together. We were building iPhone apps together, and using the revenue to pay for college. We found it was pretty easy to build something people wanted to buy, but when it came to accepting payments online, it was surprisingly really hard.
I remember using Slicehost, the first really good virtualized hosting provider. You could click “create server” and pick your Linux distro. It really lowered the activation energy to building something. And we wondered why there wasn’t Slicehost for payments. That was how we described the idea to each other.
It was October 2009, and we were walking home from dinner and John said, “It can’t be that hard, why don’t we just do it.” Well, as my friend Avi describes, it turned out to be the world’s biggest yak shave.
Stripe wasn’t called Stripe back then…it was called /dev/payments. You can tell we were great at branding. We launched that prototype in January 2010. Even though it wasn’t public, people kept talking about it. This was surprising to us, since we weren’t a social network, we were an API for taking credit card payments. That summer, we decided to work on it as a bootstrapped “internship”… we never went back to school.
Q: What community did you build on?
A: As a teenager I’d spent a lot of time working on Lisp, and so I’d gotten to know Paul Graham and, through him, Y Combinator. When we built this API for accepting credit card payments, a lot of our friends were interested in using it since they too were working on startups of some sort. Many of the first 20–30 users were all YC companies or friends of people who had gone through YC.
Q: What’s it like to start a company with your brother?
A: The trite answer is that we have 20 years of learning how to resolve problems together. If you look at most high-growth companies, the cofounder set breaks apart. Have a strong, foundational relationship there, where you know the person for upwards of a decade, those teams seem to fare better. It’s a given that bad situations will arise; the question is how you deal with it.
Q: In the really successful companies, the co-founders don’t split.
A: There’s a fairly striking inverse correlation between how long the founders knew each other, and the likelihood of a split.
Q: You spend more time reading history than anyone I follow on Twitter. Why?
A: It’s a way to cheat. Everyone ignores history. All these solutions are written down in books that you can read! Alan Kay calls computer science pop culture. It’s a Brownian motion through the problem space, with no account given to what’s come before. Engelbart didn’t just invent the mouse; he had a better system than Hangouts that he demoed in 1967! The original idea was for software to be a “bicycle for the mind,” to make us more effective. Instead, we’ve focused on more basic utilities, like making a car come here, or entertainment. This also has a lot of merit, but I think there’s been a systematic undervaluing of certain kinds of tools and lack of appreciation for the impact they can have.
Most technology companies are building cars; Stripe is building roads.
Q: It was a quieter time, which resulted in better thought over all. There are so many things that happened in the 60s, 70s, and 80s, that still echo today. Alan Kay said, “Point of view is worth 80 IQ points.”
A: The details really matter in software. Being 90% correct is like being 90% alive. You don’t get a whole lot of partial credit. Part of it is also the ambition. I recommend “The Dream Machine” by Mitchell Waldrop. One thing it makes clear is that it wasn’t inevitable that these things happened; particular people had particular ambitions.
Q: Dynabook and Ubicomp are still the dominant models of computing today (Apple and Google).
Q: How big is Stripe today?
A: 330 people, which is one way of answering that question. We launched publicly September 30, 2011, so we’ve just celebrated our 4th anniversary. A year ago, it was about 160, 170 people.
Q: Talk about how you’re organized.
A: We’re relatively conventionally organized. There’s always a temptation to reconceive the nature of humanity and social structure; you should really try to discourage that inner voice. First, think about all the risks you’re taking in your business. The standard ways of organizing a businesses are empirically sufficient for creating Google, Facebook, etc. Do you really want to add your novel organizational ontology as an additional business risk factor? Second, you’re not going to be very good at anticipating the problems with any alternative that you might conceive, since — chances are — many of the future problems are ones you won’t have encountered before.
Q: This seems surprising. Why be innovative with the product but not with the organization?
A: Well, in technology and product, the right answer at any point in time is a function of the current technological equilibrium. And that’s constantly changing and so it makes sense that the output of the function would be changing. But people aren’t changing a lot and so I think that reinvention makes less sense there. Two discounts to that, though: one, what people generally want is changing somewhat, and, second, people do actually copy a bit too much, I think — there’s too much mimesis. Interviews and hiring processes are one of my favorite examples of this. Laszlo Bock, Google’s head of HR, wrote a great article for the NYT where he said there was no correlation between GPA and how well people did at Google. The data is very mixed on interviews themselves too. Everyone does the same algorithm and whiteboard interviews, and generally everyone seems to know that it doesn’t tell a whole lot about who’s going to succeed. So, we at least try to test the real thing — our engineering interviews are largely writing code on your laptop, which is obviously a lot of what people do after they join.
Q: You guys have a reputation for being excellent at hiring developers. How long did that take?
A: I’ll just caveat everything at the outset with the acknowledgement that it’s hard to know whether we’re actually good or bad. You’re never entirely sure and don’t have counterfactuals! Maybe we’re bad at selecting developers but were lucky in having really great ones apply. Or maybe it was just random.
One thing we may have benefited from is that Stripe builds tools for engineers and developers, so perhaps people had somewhat more affinity for us.
I think maybe the biggest thing, though, was being okay taking a really long time to hire people. Being painfully persistent in doing so. It took us 6 months to hire the first two people. In the 6 months after that, we hired 3 or 4 people. We did week-long trials, some of the candidates didn’t work out, some of them didn’t want to join initially. You have two choices: your first criterion can be quality or expressed interest. It’s much easier to filter by the second one first, but you get better results by first starting with a set of people you know are great. When you try to hire the best people, rather than focusing on people who have expressed an interest, it’s much harder. It’s like trying to turn an aircraft carrier. Chances are, the smartest people you know already have good jobs or plans that they like. There are many people at Stripe who took us years to hire. It seems kind of crazy, right? You have to be way more persistent than any sane person would think.
JL: Airbnb had to acquire Aditya’s company to hire him. It’s so painful when you have just 2–3 people, but when you get one great person, it gets easier to get the next great person.
Yes. One thing that I think is helpful to frame the importance is to think about each person not in isolation but in terms of the fifty additional people who they’re going to hire or who will join because of them. Do you want to hire that tree?
Q: It sounds like you had product/market fit from the very beginning. Is that true?
A: Yes and no. Yes, we had people interested in what we were doing, but no, no one was rushing to invest. A lot of factors came together — the trend towards mobile, the increasing importance of the user experience.
But there was a lot required on top of the initial product/market fit to the extent that it was present. For example, one of the most successful things we launched was Connect. Think of all these marketplaces like Lyft, Uber, Airbnb. Not only do they accept payments, they also have to pay people. Tons of these are built on Stripe. It’s difficult to understand unless you’re actually deep in it. A huge amount of additional work had to happen, which is hard to understand without the context. But that came later.
Because it’s hard to assess from the outside, people don’t get what Stripe does or why it matters. The good thing is, competitors also don’t get it.
Q: Fast-forward to 2015. How do you talk about scale?
A: The current public things we say are, we handle billions of dollars per year for hundreds of thousands of businesses. We’re the default thing that startups use when they need to move money around the internet.
Q: You say you’re not PayPal, but that’s what it sounds like Connect does.
A: Well, this is part of the issue with Stripe in general. These things can sound similar until you get into the details. The critical difference is that Connect helps people build software that coordinates the flow of a network of money. What Lyft does in terms of coordinating the payment between rider and driver — including the issues of tipping, refunds, etc — is very different from a person-to-person payment.
[Missing question/transition here?]
The reason we decided to drop out of school and focus on Stripe full time is because we realized that the market potential is huge. At the time we started, around 2% of all consumer spending was happening through the internet. So it was incredibly early. The internet was reaching the rest of the world, and there were all these nascent markets in China, India, Brazil. Finally, people were building complex payment systems, like Kickstarter, and other crowdfunding platforms. The belief was there are going to be a lot of these, and there will need to be tools and APIs to facilitate them.
Student Question: How did you go about setting up relationships with credit card processors, etc., when you were really small?
A: In the beginning, we worked with a guy I met at a party, whose friend ran a payments company from the Midwest. When you created a Stripe account, John and I would create an account on this company. We did this dozens of times. There were a lot of things which we manually did ourselves for a very long time. Then, we met with Wells Fargo, and they unequivocally said they had no interest in working with us. It was getting frustrating to fill out all these forms, so we asked our investor Geoff Ralston to help. Geoff told us that Billy Alvarado did all his record company deals at Lala. Apple had just bought Lala, and Billy had left, so he was willing to join us.
He was our 5th or 6th employee, and the first who didn’t write code, which was difficult for us. Geoff told me, don’t be an idiot, hire him. If he doesn’t work out, I’ll pay his salary. So we hired him, and he’s still hugely important at the company. He solved the partnership problems. About 2 months after he joined, we had a relationship with Wells Fargo.
Q: How did you assess Billy’s performance?
A: Some of the things were pretty easy to assess, like the Wells Fargo deal. But he helped with so many other things. For example, he asked, how do you do payroll? And we said, well, we divide their salary by 12 and give them the money. No deductions or withholding. He helped us clean up a lot!
Q: How do you understand the market and decide what to build?
A: When you’re building for developers, you can just ask them. Frequently, they don’t even wait for you to ask! We try to pay attention to those we judge to have good judgment.
Mark Zuckerberg says it’s very important for the CEO to be involved in micro product decisions. What’s optimal in a 1-year time frame is often not what’s optimal in a 5-year time frame. The CEO can help bring that time horizon.
We built an integration with Alipay. We’d tell businesses about it and they’d say, “We don’t really sell that much in China.” We’d then tell them, maybe we should think through why you’re not selling that much in China!
Q: Do you guys get excited about Bitcoin? Developers get excited about it.
A: Definitely not huge yet. People have said that you can’t judge decisions by their outcomes, which sounds a bit counterintuitive at first. But what they’re getting at is that you have to look at the EV. It’s not completely clear what will happen with Bitcoin. Even if the probability of success is low, if the potential outcome is big enough, it’s worth paying attention.
The original paper on Bitcoin is the first paper I’ve seen that is both a CS paper and a Political Science paper. It’s a cool idea. So we wanted to help move it along.
Q: Who runs Product at Stripe?
A: We have a bunch of Product Engineering teams (5–6) and some of them have Product Managers. There is a single Engineering Manager who managers all the products, and I manage that manager.
Q: When the CEO is involved in product, it’s brutal to be VP Product. Either you’re micromanaged, or the CEO isn’t involved in product.
A: In many organizations, there’s a separation between engineering and product management. We don’t have a separate product org today. Our engineers and engineering managers are very involved in the product decisions.
Q: How long will that scale?
A: I don’t know. We’re building for other engineers, so engineers are more likely to have good product instincts. And so it may scale somewhat longer.
Q: Have you launched products that you’ve killed?
A: Part of what’s so difficult with a fast-growing product is that product innovation becomes harder and can even slow down. As a user, it felt that way with Airbnb and Dropbox — the product innovation slowed down. But, of course, what’s happening is that people have to shift to operating and scaling. While 10 people can build Stripe, it takes a lot more people to operate Stripe. The net effect is that, in some cases, the product advances surprisingly slowly. You have to hire all of these people, train them, figure out how to work together, and so on. But if you succeed at doing it well, you can really speed up tremendously. Facebook is a good example. But the net effect is that the hysteresis involved in scaling processes yields a strange shape in the product improvement curve.
So, that’s one preface. It’s not like we’ve been shipping tons of new things even though we’ve been building a lot. Secondly, we tend to experiment and hone a lot while in beta. By the time something makes it to launch, we’re generally pretty confident that it’s good. So, the net effect is that we haven’t killed very many things post-launch.
Student Q: Can you talk about acquisition offers you may have had?
A: We’ve been pretty clear that we’re not interested. One tends to think of acquirers as monolithic entities; when you’re talking to a company, you’re talking to a person. We’ve never had any serious conversations. Our prior company had gone through this acquisition process, and it was helpful in being clear on what we wanted.
JL: When you find something special like Stripe, you want to hold on to it.
Q: You have the most up to date payments stack. But your customers don’t want modern, they want it to stay the same.
A: You have to invest to innovate without being problematic on the reliability axis. We built a translation layer so that you can be on any recent version and be okay. We recently deprecated an API version we released in 2010; we went to the three people who were still using it and asked them to move.
You want to get more reliable over time, and you would like to be doing more things over time.
I think Stripe is one of the most reliable infrastructure providers, period. The total availability record for the API as a whole has been remarkably solid. I no longer write the code, so I’m impressed from a slight distance.
Q: What do you do differently now than a year ago? For one thing, you hired Claire as COO.
A: The big change is the need for formal, explicit, broadcast communication. It feels unnatural, especially for me for some reason. Part of the way to rationalize it is to realize that a start up is not a natural environment. The optimal things to do don’t always feel natural. The social groups you belong to don’t typically grow 100% per year.
The new people weren’t there for all the tortured discussions of the past. That can be good, but they also don’t have the context, so it is a delicate balancing act.
JL: As a CEO, you’re running on a tighter loop inside your head than anyone else. You can’t communicate everything that you’re learning all of the time. You value consistency and alignment.
Yes, you want alignment, but you don’t want the company to be overly rigid. That’s part of what makes people want to quit companies. How do you have the right amount of structure AND flexibility?
I’m not the right person to be making all kinds of decisions. In fact, I’m the optimal person to be making a decreasing subset of decisions.
You should generally shift from speaking to writing. It’s not that you should speak less. You need to add writing. Speaking can only happen once, and generally not to everyone. Writing persists through time and can be updated. It also adds rigor and clarity.
I read a paper from Bruno Latour, who talked about the scientific revolution and the invention of writing. His argument is that it’s not that the printing press led to more ideas, but that it added concreteness and rigidity. When you hear something from a friend of a friend of a friend, God knows how much it has shifted and changed. So it’s hard to disagree with it, to weed out and reject the bad ideas. With the written word, it’s much more clear, and you can tell if it’s wrong and needs to be updated.
Student Q: Latour makes the point that writing is open to reinterpretation.
A: Yes, but it’s more rigid than the spoken word.
Q: How did you pick the name Stripe?
A: We thought /dev/payments as a super awesome and cool name. The rest of the world didn’t agree. When we filed our paperwork in Delaware, we were rejected. We had to register as SlashDevSlashPayments. Banks would ask, “What’s the company called?”
We had all these books in the office, and would pick out random words like, carburetor. Someone came up with the idea of coming up with a list of words, then emailing all the owners to find one who was willing to sell for a reasonable price.
We came up with memorable names like PayDemon — we still own the domain! We were also enamored with PayForge…then a friend pointed out the negative connotations.
The owner of Stripe.com responded with a reasonable price. We couldn’t decide between PayDemon and Stripe. So we decided that if we couldn’t decide on a name by December 20, 2010, we’d go with Stripe. Which is what we did.
We were going through the name change checklist — there’s a lot of stuff involved — but we forgot to notify the users. They all emailed us to ask if they were being phished! Admittedly, all of them meant about ten people.
I was reading “The Little Kingdom” by Mike Moritz; apparently that’s how Apple got its name as well — they decided to default to it if they didn’t find a better name by a particular date.
Student Q: Can you talk about shifting from developer to leader?
A: The short answer is that I miss being a developer. The industry overbiases towards founders and CEOs. We all have this narrative bias where we want to associate abstract concepts like a company with a single person. I am the Schelling Point for Stripe.
I’m not sure how to talk about the shift in general and far more people than just me have had to make it at Stripe. Ali Rowghani points out that the CEO’s role can be reduced to three things: The strategy (and if it’s right, it doesn’t take much wall clock time), the culture (no one else can do it to the same degree), and selecting the senior management of the company. The fourth one is optional — the CEO can be involved with one specific function like Product or Sales. I found that helpfully clarifying.
