Scaling Stripe with Patrick Collison — Class 11 Notes of Stanford University’s CS183C

Here is an essay version of my class notes from Class 11 of Stanford University’s CS183C — Technology-enabled Blitzscaling — taught by Reid Hoffman, John Lilly, Chris Yeh, and Allen Blue. Errors and omissions are my own. Credit for good stuff is Reid, John, Chris Yeh, and Allen’s entirely.

This class was an interview by John Lilly, of Patrick Collison — the founder and CEO of Stripe — on lessons learned from scaling Stripe.

Video of the class, notes are below:

John Lilly: What is the founding story of Stripe?

Patrick Collison: I am skeptical about the “founding mythology” but I can share the story of how we started Stripe.

I started Stripe with my brother John Collison while we were in school together. We first started off building iPhone apps together and using the money we made from them to pay our tuition.

We got into the habit of working on side projects together early and realized it was easy to make money on iPhone apps (this was in the early days of the app store) and one of the things which made it so easy was the ability to charge and pay for things easily.

We were talking about why it was so much more difficult to charge for things online vs. on the app store — most websites made it a huge pain to pay for things. At the time there was this company called Slicehost which was the first really good virtual hosting provider — it made getting a server very straightforward. Our original idea was why don’t we build Slicehost for payments.

Originally we were just going to build a prototype and assumed it wouldn't be too hard. 5+ years later we are still at it — you can call it the world’s longest “yak shave.”

In 2010, we built and released the first version of Stripe — actually, back then it was named /dev/payments (we weren’t great branding experts). We launched it to a few friends to get enough of a sense for the basic experience of charging for credit cards. We just put up a wait list on our site and demand took off, over a couple months we had a huge wait list. We weren’t expecting it.

John Lilly: You created the first version and then how did people find out about it? What kinds of people were signing up?

Patrick Collison: I had been involved in the LISP programming community for a very long time. It’s a very small community and this is when I got to know Paul Graham. We got into YCombinator and built this payment API for developers — many of our friends were doing startups so we had a strong sense on what the community wanted.

We just started showing it to people and getting feedback. All of our first 20–30 users came from YC companies or friends we knew. From there people talked to each other about it — payments were a big pain point.

John Lilly: One of my rules of thumb is put yourself around people who are doing interesting things — then when you do interesting things, other people can see and use it.

What is it like to start a company with your brother?

Patrick Collison: It was good because we were really good at resolving our differences, we had 20 years of fighting between us as experience.

It’s a common case with high growth startups where the co-founding team breaks up — generally it's hard to get the team to persist. It’s easy to stick with it when you have known the person for decades either as a friend or family.

It’s inevitable that tough situations will come up, but it’s how you react that is the challenge.

John Lilly: You also are known for reading a lot of history (including physical books), why do you think it's important to study history?

Patrick Collison: It’s a way to cheat. You could try to pound your head against the wall and think of original ideas — or you can cheat by reading them in books.

If you look at people like Douglas Engelbart — he didn’t just invent the mouse, it was so much more than that.

In his famous video “the mother of all demos” — he invented real time collaboration (Etherpad), video conferencing, live syncing of documents with video conferencing. The way I see it, he invented a better “Google Hangouts” system — and this was in 1968.

What’s surprising is so much of this early work is better than what we have today. Sure we have solved all kinds of scaling issues, deployments, technology — but the core problems of helping people work together were thought about more back then. Their concept of technology was the empowering of humans through technology.

So much of software today is either about 1) basic utility or 2) entertainment vs. the enabling of people. It’s much harder to see the latter. One phrase we use at Stripe is “most tech companies are building cars, Stripe is building roads.”

John Lilly: How big is Stripe now?

Patrick Collison: We are at 330 people and we are around 5 years old now depending on how you count when Stripe started — we launched on September 30, 2011 but had the idea in 2010.

John Lilly: And a year ago Stripe was half this size?

Patrick Collison: Yes a year ago we were 160 people, we're doubling every year.

John Lilly: Can you talk about how Stripe is organized? Do you have VP’s, managers, etc?

Patrick Collison: We are conventionally organized. As founders we have a tendency to do things differently. It comes from a good place but there are two problems with innovating on the organizational model:

1. The standard means of organization helped create Google/Facebook/Amazon/etc. Even if you could organize a company in a better way, do you need to do that?
2. Any alternative you do create, it's hard to get exposure and experience in that model.

Technology tends to change a lot but people and the organization of people are the same systems today.

However, there are areas for improvement. For example with interviewing, everyone copies how other companies interview but even Google has learned that there is no correlation between GPA and performance at the company. Algorithmic style coding interviews using whiteboards don’t work — and even then no one does anything different — this is crazy.

We don’t do this. When people interview at Stripe they write code using their own laptop in any language they like.

John Lilly: Stripe has been known for being excellent at hiring, how long did it take for you guys to move towards interviewing with personal laptops?

Patrick Collison: It’s always hard to know if things are good or bad, or what to attribute success to.

One of our biggest benefits is we were building software for engineers therefore we had a higher affinity towards engineers — how much did this matter? It’s hard to know.

The biggest thing for us was being ok with taking a really long time to hire great people. It took us 6 months to hire the first 2 people at Stripe. The next 6 months after that we hired 3–4 people. We did week long trials with many people and many people didn’t want to join after that.

In some cases we were having 3 month long conversations with people just to see if they would be interested in joining. When you are trying to hire great people there are two options:

1. Filter by expressed interest — secondary filter for who is good or not.
2. Find great people and then convert them to expressed interest.

We took the second approach but it was difficult. Multiple people at Stripe took several years to hire, 5 people took 3+ years to hire. The idea of taking 3+ years to hire someone is crazy, our biggest thing was being way more persistent than others and being ok with taking longer than any reasonable person would.

John Lilly: It sounds like you had product market fit right at the beginning? Was that true?

Patrick Collison: Yes and no.

Yes, in the very beginning — the idea of a credit card API and being easy to implement it in your own product — turned out to be a good idea.

No, from the fact that all of the additional products where we saw real product market fit — happened on top of the first layer we built. For example — Stripe connect — was a product we build for marketplaces (Instacart, Shyp, Postmates, Lyft, Uber) which helps them facilitate transactions between the people on their platforms. The vast majority of these marketplaces are not built on stripe — we had to produce all of these additional API’s on top of our original transaction layer we built.

John Lilly: It sounds like there were successive product market fits spread out over time — fast forward to 2015 — what scale are you at today? How do you talk about scale?

Patrick Collison: We don’t really talk about numbers but we help transact billions of dollars a year and have 100,000’s of businesses on the platform.

John Lilly: When you talk about Stripe Connect, isn’t this the same as PayPal? A peer to peer (P2P) payment network?

Patrick Collison: On the surface level it looks the same.

When you look one level deeper however the critical difference is what Lyft needs to facilitate transactions is very different than what you need to pay your friend.

Lyft is a business mediating the payment — what happens when a ride gets refunded, dealing with tips, chargebacks, different currencies, etc. It’s a very different problem set.

Question from the audience: How did you set up the relationships early with banks?

In the beginning we worked with a friend who ran a payments company in the midwest, we basically built our prototype on top of his platform. In fact in the early days we were processing many of the payments by hand manually.

This didn’t scale however so we asked one of our investors Geoff Ralston to help us with this problem. Jeff had previously started LaLa one of the first legitimate music services which set up relationships with all of the music labels.

He introduced us to Billy Alvarado who actually joined Stripe when we were a 5 person company. He was a business development person — not an engineer — and we were very torn over this decision. The team thought “he doesn’t write code, what is he going to do?”

After much anguish we hired him and he has become one of the most important people in the company. He solved all of our early banking relationship problems and helped teach us how startups could partner with traditional companies.
John Lilly: Given Stripe had a clear value proposition from the early days — how did you decide what new things to do?

Patrick Collison: This is a tough question. Customers typically don’t know what they want and it’s difficult the find the answers through analysis.

Luckily when you are developing product developers, you can cheat and just ask them what you want — developers are outspoken and will also ask you directly. Next the challenge is how to prioritize various features. We spend a lot of time getting to know which customers have good judgements about our product.

There is a quote from Mark Zuckerberg which I like on this subject which is “What’s optional for a 1 year time horizon, might not be good for a 5 year time horizon.” It’s our job to have good judgement on how the pieces fit together.

I’d say about 70% of our new product ideas comes from listening to customers with good judgement and 30% are doing things which ought to be big but aren’t being asked for.

John Lilly: How’s Bitcoin related to all of this? Developers get excited about Bitcoin but it doesn’t feel like it’s a thing yet? Huge yet?

Patrick Collison: Bitcoin is definitely not huge yet.

However you can’t judge decisions by their direct outcomes — instead you should judge decisions by their expected value.

For Bitcoin it’s still small but the potential outcome could be significant. In addition we felt some general affinity towards the Bitcoin community. The distributed systems, decentralized infrastructure, and system of ledger are all cool concepts. Also the original Satoshi paper is one of the first papers which is both a CS breakthrough and a political philosophy breakthrough. So we decided to help out a bit.

John Lilly: Who runs product at Stripe?

Patrick Collison: We don’t have separate engineering and product teams within Stripe, everything is broken up by product engineering teams with one manager for each team. Then I manage all of the managers.

John Lilly: I’ve noticed when the CEO and founders are in the details of the product — this creates instability for the VP of product. Either the CEO is the micromanager of product, the CEO lets the VP of Product run with it however they want, or the CEO just doesn’t care. It’s a tough role to be in.

Patrick Collison: I agree it’s a tough role. Given we don’t have a separate product role, I am fairly involved in our product. The head of product helps staff, build, operate, and works with me.

John Lilly: Has there been any products Stripe has launched and killed?

Patrick Collison: Part of the thing that makes this difficult to answer is — product innovation tends to slow down as you scale.

We built the first product with 3 people, now we are at 300, why are we slowing down? Even as a user of Airbnb/Dropbox/etc., as a user I feel like the innovation has stopped.

What happens is so much additional investment is required to keep up with growth — the original 3 people can’t operate the full system anymore, it’s just so much bigger than when it started.

When you are looking to scale and innovate — this requires hiring many people, training lots of people, having them learn in this emergent process, figuring out how to coordinate together, etc. The net effect is product advances slower.

However, if you do a good job at this, you can look back and scale much faster once your systems are in place. Facebook did a good job at this: moved fast, went into a slow period, then moved quickly again.

At Stripe we haven’t launched many discrete new products — we have shipped many features and experiments but we haven’t killed any full new products. Because we have developers as customers — we run many ideas by them in idea/beta phases and if they don't like it, we stop. Before anything gets to launch we have had pretty exhaustive validation.

John Lilly: Moving to a management question, what do you do differently now that you are past 150 people (Dunbar’s number)?

Patrick Collison: Past 150 has been a big change for us. The biggest is a need for formal explicit communication — specifically broadcast community.

This kind of communication feels very unnatural — no one wakes up in the morning and sets out to talk in bullet points — Here is our 3 bullet points for our Q4 strategy. When you think about it, a startup itself is not a natural environment, there are different things you do that you would not do naturally. You don’t typically grow your social circle 50–100% year over year.

All of the discussions and debates we have — many of our current team weren’t there when we had those. 50% of our entire team wasn’t there a year ago. Each new person that comes in wants to do things different. Part of it is good in the fact that it re-opens issues and part of it is bad, given new people don’t have the full context.

John Lilly: One of the profound realizations I had is the CEO learns really fast but the various layers of the company can't possibly absorb all of this change — so I moved towards speaking consistently and getting alignment the bigger we got.

Patrick Collison: It’s delicate because we want alignment but at the same time if it becomes too rigid it will be problematic because people will want to quit. We need the right amount of structure.

One caveat to all of this is I don’t want to be the person to make all of the decisions — I don't want the organization to do everything I want to do — I want them to do the right things.

When I look at “The Stripe way” it’s a distinct thing and a distinct way of doing things. Sure I am close to it but it’s changing and evolving with all of the people we bring on.

One thing I have noticed for myself is a general shift from speaking to writing. It’s not that I need to speak less but I need to add more writing to my communication. Speaking can only happen once but writing can persist through time, be revised, be updated, and help in clarity.

One of my favorite insights which has had a big impact is a paper from Bruno Latour about the scientific revolution. His argument was the printing press was critical but it’s not because the printing press led to more distribution.

It was because written word was more concrete and rigid. Previously most scientific information traveled through spoken word — but when you are hearing about something from a friend, of a friend, of a friend — who knows how much the facts have shifted. It’s tough to know what is true vs. not.

In writing you can point to paragraph 3, line 2 and can disagree with that point specifically.

Question from the audience: How has the transition from developer to manager been for you?

Patrick Collison: It still pains me, I miss coding. I get this question a lot and yes I miss it a lot.

I think our industry over biases towards founders and the CEO — the media wants to associate a company with the person. The degree in which I am representing of Stripe is overrepresented compared to everyone one. It wasn’t just my transition to management — it was the whole team's transition to a large company.

(I didn’t write down who Patrick was quoting but) Basically the CEO’s job can be reduced to three things:

• Strategy
• Culture (No other person besides the founder/CEO can affect culture to the same degree)
• Selecting senior management of the company (hard for anyone else to do this job) — these people will be the domain experts of their function who are better than you.
• Optional is the product — the CEO can be the head of product or lead some specific function of the product.

That’s it. It’s easy if you can get these pieces right, it’s very difficult to fix things when they aren’t working. It’s a bit simplistic but it’s been helpful for me.