Patrick Collison on Hiring at Stripe and the Role of a Product-Focused CEO | Blitzscaling 11

This is session 11 of technology enabled Blitzscaling, a Stanford University class taught by Reid Hoffman, John Lilly, Alan Blue and Chris Yeh. This class features John Lilly interviewing Patrick Collison, the co founder of Stripe. This podcast has been produced by Greylock Partners. For more podcasts, class notes, slides and videos, please visit greylock.com okay, so this.

Is class number 11. I think this is the midpoint. Very exciting. So we're talking about scaling from scaling to village. And we're very lucky to have Patrick Collison, who I think you will all find super interesting and super thoughtful. So just let's welcome Patrick.

Thank you.

Thanks for coming.

Thanks for having me.

He walked in with a book made of paper, which is always very exciting. So can you just tell the story about starting Stripe? Tell the founding story?

Yeah, sure. And by the way, apologies if suggesting this be off the record suggests that there'll be all these sort of salacious details or something. But mostly I think it's much better in these to sort of be able to just sort of directly share everything and not have the process running in the back of your mind of sort of trying to run the filter on what makes sense for public consumption. Because a lot of this stuff is sort of. This is not like a company that started 10 years ago. This is kind of happening kind of week to week and month to month. But the general story of Stripe is, well, I'm always a bit sort of skeptical of kind of founding mythologies around companies in that I'm pretty sure they get sort of heavily edited kind of post facto. For Stripe, at least, it's really not that dramatic in the sense that John, my co founder and brother, and I were in school together, we were both in the east coast, and we started building these iPhone apps together. And we were basically sort of paying our college tuition out of the revenue cone from these iPhone apps. And so we'd kind of gotten into the habit of just working on various side projects. And we kind of had realized that it was surprisingly easy to make money out of iPhone apps, right? And part of the reason it was so easy is because it was so easy to charge for things. And then we kind of were wondering, despite building all these things for the past couple of years, why do we never charge for anything online? We realized, well, it's such a pain in the ass to sort of accept payments on the Internet. You have to sort of hop through all these hoops and basically get a mortgage or so it felt kind of just in order to sort of literally receive dollars from users of your software. And so I remember using. I'm not sure if anyone else here has used this, but there was a thing called slicehost, which was kind of the first really good sort of virtualized hosting provider. I mean, EC2, I think was maybe around the same time, but EC2 required all this, like, crazy Java command line hackery. It wasn't as easy to use as it is now. Slicehost was really straightforward. You could click Create Server, select your Linux distro, and 30 seconds later there's a root password emailed to you. And it was really transformative because now getting just your own server was just super straightforward. And it meant that it really lowered the activation energy and the barrier to entry for going and building something. And we wondered basically why there wasn't Slice host for payments. So I actually remember it was in October 2009, John and I were walking back from dinner together and we'd been sort of battling around this idea for a while, Slice of payments. And I remember him commenting to me that we should build a prototype. It probably won't be that hard.

Simple question leading to 20 years of work.

Right? Well, so Avi Bryant, who works at Stripe, calls Stripe the world's biggest ever yak shave. And so maybe in another five years we'll get back to building side projects. But do you guys know what that.

Can you explain what yak shaving is?

God, kids these days. So yak shave is sort of when you're sort of building something or working on some problem and you realize that kind of some other abstraction is kind of inelegant or you should have some other thing. And so you start going and fixing that and you realize, well, really, in order to fix that, this thing has to be this other way and whatever. And so you kind of get seven layers down and you kind of forget where you even started because the stack has gotten so deep. And so there's actually a great XKCD comic. Yak shaves. I think he's like, surrounded by sharks or something. He started trying to fix his tv. I don't know. Anyway, if you search XKCD Yakshave, it illustrates the concept.

It's tangentially related to bike shedding, but it's slightly different.

Right, right, right. I think there's an original parable about shaving a yak and you have to buy scissors and whatever else. But anyway, so we decided to build the prototype and we launched the first version of it in January of 2010 to just a couple of friends. It was kind of Built with duct tape and wire, really. The foundations upon which it was built were fairly flimsy, but it was enough to just get a sense for the basic product experience what it would be like. You instantly start charging credit cards just with a kind of a curl command. Stripe wasn't called Stripe back then, it was called Dev Payments because you can tell we were great branding experts, but we wondered what it would be like to have a payments API that was as straightforward as just the interface to a node and the device file system. You have dev mouse or dev audio or whatever. And we launched that prototype in January 2010 and it just sort of took off by word of mouth, where we sort of. It wasn't even launched publicly, but we kind of had this ever accumulating wait list through kind of people telling their friends about it or whatever. And this was kind of really surprising to us because, I mean, again, it's like an API for charging credit cards. It's not a social network. And so the fact that people were talking about it and telling others about it was kind of quite surprising to us. And so then that summer we decided to go and work on it for the summer as a kind of bootstrapped internship. And we've basically been on leave since then.

I'm sure you'll go back soon.

That's what my mom often tries to ensure. Yeah.

So you had gone through starting a company before, you and your brother, right? Shapa Shuppa. Right.

So Shapa is the architect.

Another excellent branding.

Yeah, yeah. Right. So we'll actually get to the story of how we found the name Stripe. It was actually literally randomly chosen. But anyway, so we'd previously started this other kind of company together, which was basically kind of predicated on the notion that there was surprising illiquidity in sort of used items. That sort of part of what, when you buy something new, kind of part of the service that a store provides is kind of to solve the information problem of like, where can I get a thing?

Right.

And so kind of you can kind of think of the Internet as a coordinating force in some way and sort of how can you kind of expose all this sort of latent presence of all this stuff in sort of a more effective way? And it didn't really work as we thought, so we went back to school.

Well, but you kind of teamed up with. That's when you got involved in YC the first time, is that right?

Yeah, it's like a kind of complicated story. And so it involved merging with another company and then that company got Acquired. And so it was actually like a really good learning experience. It was kind of when we raised our first investment and hired our first people and so just kind of got a sense for how a startup worked in the work.

I guess I was taking the long way out. I should ask directly, which is you said you created this payments API and then people just started talking about it. I guess my question was going to be what people and how did they find out? So I guess when I was implying that you built on top of a community, was in some part connected to.

Yc, that's very true. So I had. I've been involved in sort of Lisp programming for a real long time and I presume folks here know about Lisp and it's sort of its state of morbidity. So it's a pretty small community. And through that I got to know Paul Graham, who of course was working on YC and kind of this other company we'd started had sort of gone through yc. And so, yeah, as a result, when we went and we built this payments API for developers, sort of incredibly straightforward to get started. We actually sort of, a lot of our friends were thinking about starting companies or had started companies or things like that. We had some sense for that community in general. And that was actually sort of quite powerful because exactly to your point, there were sort of people you just go and show it to and get some feedback from. And you kind of knew who was on the cusp of needing to start charging for their software, who was running out of money, they might need some revenue or whatever the case might be. And so I think that for the first maybe 20 or 30 users or thereabouts, they were almost all YC companies or friends of people who he knew had gone through YC and things like that.

Yeah. So one of my rules of thumb is try to put yourself around people who are doing interesting things. And then when you find interesting things and they start talking about them, that's a pretty good signal.

I think that's very true.

And so I remember maybe this must have been summer 2010 or 2011, people would start talking about you guys about DEF payments around here. And I guess you had come and done the YC class in 2010, 10 here. Is that what you did?

Or did you Stripe actually never kind of formally went through yc, YC invested.

Is that true?

But it never went through the program itself.

Huh, that's interesting. That's news to me. So, okay, so we're going to go into Stripe in a second. Can you talk about what it's like to start coming with your brother.

Yeah, I guess you don't know anything else I was going to say. Right. So the kind of trite answer I often give is that it's kind of good because we have a chance to really get good at resolving our differences from a pretty early stage. We've 20 years of fighting in various ways behind us. And even though that's kind of facetious in some way, I do think that the common case for the really high growth startup is for the co founder kind of set to break apart. Like it generally doesn't persist. And so I mean, just you look at most companies, right, sort of there's some schism or disagreement or whatever, that kind of proves insurmountable. And I think that sort of having a really strong kind of foundational relationship there, sort of, you know, a filial relationship is I guess, one version of that. But even if it's not that sort of, I think the cases for sort of, you know, the person for like upwards of a decade, those in general seem to fare kind of much better. And so in that sense, I think it's been basically really helpful where we have the kind of relationship where there's no difficulty in telling the other person that you're really screwing this up. Right. Or this is like completely broken or whatever the case might be, because it's a given that sort of those situations are going to arise. And so the question is only kind of how do you, how effectively can you react to them?

We'll come back to that as we talk about how you're growing in a little bit, how you bring other management into that. And then I guess my observation would be a lot of founders split, but the really successful companies, that doesn't happen. So Larry and Sergey, Jerry and Dave, Reed and Alan were together so many, many, many persist.

That's true, that's true. And in those cases, I think, or at least last I went through it, I went through kind of 20 companies and it seemed that there was a fairly striking kind of inverse correlation between just length of or duration, that they kind of known each other beforehand and kind of the subsequent outcome.

Yeah, I think that's right. And we'll find, we'll hear from Nurev on Thursday about his relationship with Sarah Leary. That's a decades longer relationship as well. Which actually another point which is you read a ton of history. So Patrick's a very. There are a few interesting people that follow him on Twitter and Patrick's one of them. He'll be embarrassed that I said that. But the most recent thing he tweeted out is history about Xerox parc, which everybody should look at the history of Xerox parc, because holy smokes, a lot of stuff came out of that place. But why do you. You spend more time reading history of everything, really, than almost anybody I follow on Twitter. Why do you do that?

It's a way to cheat and that you, everyone else ignores all the good ideas from history. And so you can just be much smarter by just. You could just try to think all these incredibly original thoughts by sort of sitting down and sort of staring at the wall for days on end, or you can sort of cheat by just. I mean, they are in fact written down in books. You can just read. And again, I can mean that a little bit facetiously, but I think that sort of. Alan Kay is this quote about, about computer science where he calls it sort of pop culture. But by sort of, which he means that sort of for most kind of communities or sort of, again, subcultures or whatever the case may be, there's a progression, right? Things build upon what came before. Whereas in computer science and in so much of technology, it's sort of just this like Brownian motion through the problem space and sort of with no account given to kind of what's come previously. And I think that sort of we as an industry do ourselves an enormous disservice by sort of being so blind and kind of blithely ignorant to it. And right from sort of Engelbart doing sort of the first demo. I mean, we've all kind of heard of Engelbart as inventing the mouse, whereas sort of in actuality, what he invented was sort of so much more than that. He basically invented Etherpad or like the first kind of real time collaborative word processor. He had like video conferencing integrated with the word processor. You could annotate and hyperlink documents together in real time. Like, he basically had a better system than Hangouts, as far as I'm concerned, that he demoed in, I guess it was 68 or whatever. 67, yeah. And then if you look at sort of what came out of PARC or so much of kind of this early work, that frankly it's better than so much of what we ended up with. Now, that's not to say there hasn't been sort of a lot of value in kind of what's ensued. I mean, we've solved all kinds of sort of deployment problems and technological problems and scaling problems and so forth. But in terms of sort of the core ideas behind so much of it, I think that sort of, in some ways there was much better thinking among some of the kind of the creators and kind of in a substantial way, I think that the line of thinking around sort of the early conception of so much of this kind of software technology was about kind of empowerment of humans. And the kind of the phrases that were battered around were things like intelligence augmentation, intelligence amplification, augmenting human intellect, things like that. So this is kind of the original kind of bicycle for the mind idea, which I think is sort of incredibly potent.

Right.

Kind of how can we leverage this software to make us more effective at whatever it is that we might be doing? And then I think that sort of so much of kind of what's happened with the Internet or kind of the modern technology industry as we know it is either sort of a very kind of basic sort of functionality around sort of utilities. Right. So it's not about sort of higher level intellectual functions. It's about just. I mean, not that it's not valuable, but like, how do I get a car to come to here? I'm really delighted that that service exists, but it's not sort of part of that original line of thinking, or it's about basically entertainment. It's about sort of the Internet as sort of a more interactive version of television, which also, you know, has some merit. I mean, it's not entertainment has merit, but sort of. I think there's been a significant loss of that. And I think that people. I mean, this is kind of a longer conversation, but basically, to answer your question, I think there's kind of a systematic undervaluing of. Of tools and sort of undervaluing and lack of appreciation for the kind of impact that that can have because it's harder to perceive. And when you do something directly, you can see what it is, whereas when you're enabling something, you have to kind of make that additional leap. And kind of a way we often praise it for Stripe is that most technology companies are building cars, whereas Stripe is building roads. And it's that kind of distinction.

I promise I'm going to get to scaling. I just want to spend a little bit more time on this. So a lot of things really spoke to me on that. So meeting Doug Engelbart. So Doug came in. Have you met him? Did you meet him before he died?

Sadly, no. We had Alan Kay and Stuart Bryan to speak at Stripe recently, but I never met Doug.

So, Alan, I want to talk About a second too, because so Doug came to visit us. Apple. So Doug was at Xerox parc. And I remember he came in and we showed him Demos in probably 1999. He's like, finally somebody did this. That I said 30 years ago. And that happened like five times during our demo. Like, okay, fine. But I think a lot of what happened was that it was a quieter time, it was less noisy, and so more people were thinking harder. And so I think that resulted in better quality of thought overall about what's happening. And it's just shocking to me that so many things happen in the 60s and 70s and 80s that are echoing now. And even Alan Kay, his other quote was that point of view is worth 80 IQ points, which, what a brilliant quote. It's like try to figure out the right problem and if you look at it from the right point of view, you win.

Right? Yeah. And I think it's really easy to have this kind of, kind of in a historical sense, this rose tinted sort of view of history and sort of. I think there is kind of occasionally kind of a facial way in which people say that X or Y has been done previously and so there's nothing interesting actually being done today and so forth. And I think that sort of that misses the fact that so much of sort of the details really matter in SAFTRA and that you can be sort of 90% correct, but you know, that's like being merely 90% alive. Right. And that sort of. You don't get a whole lot of partial credit. But yeah, I mean, I wasn't around, but I'm very curious sort of why it was that their kind of why this perspective did differ. And I suspect part of it is that it was quieter. I don't know, maybe there was less Facebook, Twitter and TechCrunch and all the rest. Yeah, maybe speaks my own discredit, but I think also part of it is just kind of the ambition, honestly, in the sense that there's a great book that I'd recommend you all read called the Dream Machine by Mitchell Waldrop, which I think is certainly at least the best history that I know of about the early days of technology and the Internet and the computer revolution. And one thing that it makes clear is how it wasn't, at least the book's argument and thesis goes, it wasn't inevitable that sort of so many of these things happened or some of these kind of ideas were percolating. It was sort of particular people who had particular ambitions. Folks like Licklider sort of originally at mit, who kind of funded a lot of the work that sort of led to the Internet and sort of then I guess his intellectual descendants like Engelbart and Kay and so forth. And I guess the optimistic view would be that sort of a lot of that kind of ambition about sort of the, the power that software can have on society sort of can in fact be reclaimed or at least that we're not sort of going to necessarily fall victim to the noise that surrounds us today, the Twitters.

Yeah, well, that's why I'm spending a little bit extra time on this though.

I'm actually, I should just say I think Twitter is a tremendous force for good.

I kind of live on it. So I make fun of it and I'm a little bit self conscious about it. But then the other thing I was going to say is that my models of computing are Alan Kay, the Dynabook, which essentially describes Apple and client computing, and Xerox Parc Ubicomp, which essentially describes terminals and Google. And those are still the two dominant models of computing today, 50 years later. And so when I look at client or server, it's essentially Xerox and Xerox. Yep, actually that's kind of it. Okay, so I was going to ask you what a philopolist is, but I'm going to wait till the end because I'm excited about that. He had a word in his eight word Twitter bio that I had to look up, but I like it now. So let's talk about Stripe. So how big is stripe now? Today?

I think it's around 330 people. 330 and it's only as one metric at least.

And it's five years old.

Yeah, it's actually a bit hard because, you know, do you count from. I mean basically that dinner when so John misled me or sort of from when he first launched it or whatever. But generally what I sort of count from is when we launch publicly because we had fewer than 100 users at that point. And we launched publicly to the world September 30, 2011. And so we kind of just celebrated our fourth birthday post launch. And so we're kind of effectively on the order of five years from kind of really working it full time and then four years from public launch.

Okay, so you're 330 people now. A year ago, were you half that size?

Yeah, probably this time a year ago, maybe 160, 70 people.

Oh yeah. So about doubling every year now. Yeah. What was it that Eric Schmidt said? Doubling every year is possible? Quadrupling Every year is really hard.

Certainly we could not quadruple every year.

Yeah. So talk about how you're organized.

My turn to evening class. But I'm hard to mention just in general, how the company works.

Yeah. How you run. Do you have vice presidents? Do you have ICC managers? Does everybody do whatever they want? And Holacracy. What happens is.

Right. So the harder bit, I suppose, is that we're relatively conventionally organized. And that sort of. I think the. I mean, there's always such a temptation sort of when you're starting out to go and sort of reconceive the nature of humanity and how people can collaborate and coordinate and so forth, and that basically you should really kind of try to discourage that inner voice. And I think it sort of comes from a good place where you want to kind of reconceive all of these things. Right. But there's two problems with that. The first is that you kind of need to think about sort of what risks you're taking in the business. And sort of empirically the standard means of organization are sufficiently effective to create the Googles and the Facebooks and the Intels and so forth of the world. And so, I mean, even if just posit that sort of, you're actually capable of conceiving a more effective way of having tens, hundreds, thousands of people working together, whether you actually need that to achieve your actual goals. And the second one is that probably all of the problems with any alternative that you could conceive are things that you haven't been exposed to to date. You just don't have the life experience to sort of anticipate. And so basically, whatever you think you should probably do instead, you're almost certainly wrong.

So let's stay on that for a second. That's an unusual thing for a Silicon Valley person to say.

Don't innovation.

Maybe old people know what they're doing because they've done it before or they've lived through it. Can you break that apart a little bit?

Yeah.

As an old person, I'm excited about this line of questioning.

I think that, well, technology changes a lot. Right. And so I think sort of the right answers, sort of given the right answer, is a function of the current technological equilibrium. Right. And so if an old person thinks that such and such is a bad idea or something like that, I mean, there's an excellent chance that now, some period of time later, they're wrong because that dependent variable has changed. Right. But people aren't changing a whole lot. And so whatever the optimal system was kind of some period of time previously, I think still is your default prior. Should be still probably a pretty good idea. I'll caveat that with. I think if you just kind of look at the history of Silicon Valley, things are in fact changing, even though people themselves aren't changing that much because I guess just the environment, people's expectations and so forth are changing. And secondly, I think that sort of a discount factor on sort of how well we do things is that people do copy too much. That's kind of this mimetic force at play. My favorite example of this is kind of standard Silicon Valley interviews. I can't remember his name. Google's Laszlo Bach. Laszlo Bach, right. Wrote this great article for the New York Times where as I recall, he sort of admitted that they'd observed almost no correlation between GPA and indeed Google sort of interviews themselves and sort of the subsequent performance at Google. Right. That certainly was the case for gpa. I can't remember if it was the case for the interviews. But essentially every company does the same kind of algorithm style interviews and coding on the whiteboard and so forth. And essentially everyone, at least almost everyone I've talked to kind of knows that it doesn't really work and yet nothing changes. And it just seems so insane.

Right?

And as far as I can tell, it's sort of, you want to, you want to be successful, you look at what the successful company does. They do algorithms and interviews on the whiteboard and so forth. And so despite the fact that most technology companies are not about writing algorithms on whiteboards that you sort of wanted to translate and to bring across what it is that they do. And it's just like surprisingly robust and resilient. And so we don't do that. We just try to think about, well, what it is that the people at Stripe are actually doing day to day. I mean, they're writing code on their laptops. And so our interviews are largely, we've wrote a core answer about this, but it's largely writing code on your laptop in the environment you're familiar with and experience with and so forth. And it works really well. And then when people join, they're generally pretty good at writing good code on their laptops. So there is this again, sort of discount factor where I think people just, there's too much inertia in the existing ideas. But having said that, in terms of just the organization of a large group of people, default is to trust the mechanism.

Yeah, masturbation. It's a lot like technology, which is core processes that run a Lot you really. It's really worth figuring out from first principles. And for you, that's recruiting. And sometimes. And there's a number of things, but invention is really hard. And invention without. And dealing, because it means kind of dealing with unintended consequences. There's a lot of things that happen when you do things differently than everybody's done it. There's no maps, there's no guidance.

I think there's also kind of a question of sort of the cost benefit. Right. In the sense that if you can be sort of somewhat better, even epsilon. Better on recruiting, sort of maybe that actually matters. Right. Whereas for a significant fraction, sort of the things that have to happen in a company, I mean, you can fail if you screw them up, but they're not going to be sort of the things that sort of create outside success by themselves. And for those, again, it's just probably, even if you kind of posit that you're right, that you can do them better than all of your kind of mistaken predecessors, is it really worth spending your time there? Because, I mean, fundamentally, that's the most constrained resource.

Right?

Yep.

Okay, so you talked about your laptop interviews. You guys had a reputation, I think, well deserved for being excellent at hiring very, very, very good developers. And how long did it take before you started doing laptop interviews? Has it changed now that you're 300 people?

Yeah. So I think the. Well, it's also hard to know for anything that was like, good or bad at Stripe one. It's hard to know whether it is actually good or bad or whether that's just pretty. I mean, in the case of hiring actually things, we lucked out. But anyway, you're never sort of entirely sure. But then secondly, how much was kind of. You can never kind of piece apart the attribution of all different factors. Right. And so, for example, one thing I think we benefited from was the fact that Stripe builds software and tools for developers, for engineers. And so I think there's kind of more of an affinity than for some randomly selected other product. How much did that factor matter? I don't know. Right. Potentially all of it can be attributed to that. And in fact, the different ways in which we do interviews is completely inconsequential. I don't quite think that's true. I think probably the biggest thing that aside from how we interview folks that we did differently is just being okay, taking a really long time to hire people in that the received wisdom is work really hard to hire the best people. You're like, gee, thanks, I was going to do the opposite. But now that you've said that, work really hard to hire the best people. And so I guess the question is sort of to what lengths should you go? And kind of, what does that actually mean in practice? And in practice, it means being okay, waiting a really long time to hire people and having to be sort of painfully persistent in doing so. And so it took us, let me think, took us a year. Well, it took us, me, six months to hire the first two people.

Yeah. So that's the same story that Sam Altman told about Airbnb, I think maybe nine months.

So a person per quarter. Even though we had this kind of network already and knew all these people, we managed like one every three months. And then in, I think the six months after that, we maybe hired another three or four people kind of on that order. We did sort of week long trials with them. We had some of them kind of not work out. We, in many cases, they sort of thought they didn't want to join. And so it was kind of this like three month life conversation about, I mean, therapy session of sort of, you know, what the best thing for these people to be doing would be. And I mean, this is, I think, what you find when you're sort of trying to hire the best people, because you can kind of go either sort of. You can filter first by kind of by expressed interest or something, and then you can sort of secondarily filter for, okay, which ones are good, or you can first look for the good ones and then try to sort of convert them to expressed interest. And I think that the latter is the more effective way to go about it. But then that means you have to sort of turn this aircraft carrier where, I mean, if you just think kind of X ante about the aircraft carrier.

Is the candidate you want to go get.

Exactly. Right, yes. Bit of a torture metaphor. But if you just think about sort of the smartest people you know, and you want to get them to work on your thing, I mean, chances are the smartest people you know are working already. Yeah.

And they like their jobs.

They have like pretty good paths ahead of them. Right. And sort of to kind of consistently try to rotate these just takes a really long time. And so there are multiple people at stripe now today who took us several years to hire. I can think off the top of my head of five people who took three plus years to hire. And the idea that when you're so early in the company's history that you should be kind of investing in people for whom it might Take that length of time to hire them. It seems kind of crazy. Right? And so I think maybe the, apart from interviewing people sensibly, I think the big thing that people have to keep in mind in early stage company recruiting is just you have to be way more persistent and be okay with it taking way longer than any sane or reasonable person could think it should take.

Yep. I think that's what Drew Houston says about Aditya. He says they tried to get a ditch in Ricci, who runs engineering for over a year. He had to acquire his company to get him to do it. Yep. I was reminded that I'm involved in a search company in Palo Alto and it's about two years old. But the painful, the vicious cycle is that you're going so slowly when it's the first two or three people and you're like, holy smokes, if we could just get another set of hands. But you don't want to do it. But we talk a lot in this class about compound interest and the value of compounding interest. If you get just one great person, that makes it marginally easier to get the next great person.

So I think that dynamic in spades. And then kind of. Secondly, I think another way to think about it that makes the importance of it and the potency kind of tier is that you have to kind of imagine the light cone or kind of the tree of all the people this person will hire. And so rather than just thinking about it as kind of do I want this person or not? It's like, do I want this person? And the 50 people who I think that they will hire? Because even if they don't literally hire 50 people, they will be kind of so influential in determining sort of the self selection of those 50 people. And so you're kind of, you're really picking this kind of this giant branch of a potential future organization.

And then there's something where you get to a critical mass and suddenly you get a new chunk where they all believe that it might not be crazy to go work for this startup.

Yes. In our case, it took a long time, couple years probably. And that kind of also gets into sort of networks and so forth, where sometimes these things can sort of compound more rapidly because they're not completely independent variables. Right.

So it sounds like you had the sense that you had product market fit at the very beginning. You did this thing and people started talking about it. Is that true?

Yes and no. So yes, in the sense that kind of, from the very beginning, shockingly, this idea of, I mean, again, it really doesn't sound promising. I think certainly all the people we talk to didn't think so. Sort of a credit card API that was really simple to use over Curl and you could set up instantly. You're not immediately like, all right, let me invest. And indeed most people weren't. But that in fact turned out to be sort of a pretty good idea. And sort of it ended up kind of playing into all these kind of larger secular trends and like the rise of mobile and the shift from sort of advertising based business models to transaction based business models and things like that.

Even though there wasn't that much that was really associated with mobile.

No, but I think it was just kind of that sort of. There was actually, it was kind of a period of high turnover in the industry and so kind of more things were getting kind of rebuilt from scratch and so forth.

Right.

And also product experience was becoming more important and so kind of just bouncing people to some other website to pay was just not viable in mobile. Right. So there was kind of that. But then I think kind of the second aspect in which the product market fit wasn't quite there from the outset isn't sort of the additional stuff that sort of happens kind of on top and that, for example, one of the most successful things we've launched is a thing called Connect, which basically enables people to sort of to pay other people with Stripe is kind of the very short way of describing it. And so you think about all these new marketplaces, right? And so Instacart and Postmates and Doordash and Ship and so forth. Right. Are you an investor in Ship?

No.

Okay, sorry, Touch Bark, but I like.

Them all, I use them all.

Okay, yeah, great. Lyft, Uber, Airbnb and so forth.

Right.

And so tons of these companies, in fact, I think the vast majority are built on Stripe. Right. But that required this additional set of APIs that we call Connect, sort of in order to do so and to sort of coordinate all these payments and keep track of them and sort of help them handle the tax issues and the whole ensemble of factors. And so there were kind of a lot of sort of additional APIs we ended up building on top of like this really basic kind of transaction processing part that I think people sort of don't quite. Or it's difficult to understand. Right. Because it's kind of like AWS in that people kind of know. Well, they do kind of the EC2 thing and the S3 thing and there's a bunch of other things and kind of. Unless you're actually in the details, building infrastructure, it's pretty hard to keep track of all the other things. And I think sort of Stripe has had a similar dynamic where that initial component was very good product market fit, too. But there was actually, in order to actually get here, a huge amount of additional work that kind of had to happen. And the invention that had to happen, that just basically hard to understand without a lot of context. I think that's something that kind of, for better or worse, Stripe has kind of faced for its history where people kind. Well, because it's kind of hard to assess from the outside unless you kind of know a lot about the domain. Kind of the bad part of that is people just kind of don't get what Stripe does or why it matters or kind of in what way it manifests the consequence. And the good part is competitors also.

Right.

Don't really get it. Right. And so Stripe got to this point sort of pretty easily. And so it kind of cuts both ways.

That brings up a lot of different questions. So one of the things I heard in there is that there are successive product market fits. There are different signs. They come in. They don't all come together. Sometimes they're spread out. Sometimes you have to get product market fit in one place to let you build, to realize you don't have it in another place.

Yes.

Does that sound right?

I think it's exactly right.

And then, so Fast forward to 2015. So what scale are you at today? How do you talk about scale when you're talking in public?

Well, this gets to sort of another issue of sort of to what degree you should be forthcoming about your business metrics. And we've always kind of been of the school of not being. Yeah. Okay. And so I think the current public things we say are we handle billions of dollars a year for. We actually recently started saying hundreds of thousands of businesses. That's kind of about it. But I mean, it's. Strides become kind of the default thing that technology companies use when they want to move money around on the Internet.

That's a somewhat broader thing than saying you have hundreds of thousands in billions. So that's saying you're the default is a good thing to say something you want to say. Sorry, I'm trying to back out to a different set of questions. So talked about scale. Let's talk about. Oh, you talked about connect. So I was reading one interview where basically somebody said, well, look, don't we have PayPal? Isn't PayPal fine? You said, well, PayPal's not really what we do PayPal is for person to person transfer, party to party transfer. That's kind of what you described when you were talking about connect to me.

Right? So, and this is a great example of where kind of at a high level, you're like, oh, aren't these where.

The VC doesn't understand at all what you're doing? So.

Or to the interviewer, I'm not sure which interview this was, but where, like, it really gets down into details. And so kind of the critical difference is are you building software that sort of coordinates these, this kind of network of money flowing? Right? I mean, like, what Lyft needs or what Instacart needs is very different to the experience of, oh, I'm going to pay my friend with Lyft. It's. I mean, you're kind of mechanically sort of coordinating this payment between the rider and the driver and sort of that Lyft is mediating that payment. And then there's sort of all these additional considerations around it for, like, what happens if it has to get refunded. Or like, actually the amount can be different because you can give a tip to the driver and maybe it'll get charged back later and has to work in different countries. And so kind of in practice, completely kind of different problem spaces. I guess the problem face of person to person payments is like, how do I do really frictionless onboarding? And honestly, how do I have people not forget about it? Because people don't actually in practice pay their friends all that often.

Whatever.

There's like super different problem spaces, but at a high level, you're right. Both involve money going from one person to another. And so without really being kind of basically without talking to the people building the apps, instead of hearing their issues directly firsthand, they do kind of sound superficially similar.

And so I guess that then you would say that your product suite now is a really straightforward and authentic expression of your original thing, which was people make apps and they'd like to get paid for them and then paid by their customers and sometimes pay their suppliers out. Is that.

Yeah, no, I think that's basically right. So the way we kind of came to think about it was there's kind of two dimensions or maybe three to it. So the reason we decided to drop out of school or maybe go on leave was because we realized that just in general, the market as a whole was actually tiny. And so you kind of hear transactions on the Internet that's kind of been done or something. Right? But then you sort of just look at it from a high Level standpoint. And you sort of look at the total figures and about, you know, certainly at the time, 2% of all consumer spending was kind of happening through the Internet. Right. And so kind of as a total industry sort of commerce on the Internet was kind of 2% of the starting blocks. And so whatever had happened to date, it was still sort of incredibly early in terms of the ultimate curve of what was to come. The second one was just kind of more directly looking at the global aspects, where the smartphone is, how the Internet was reaching the rest of the world. And again, we were really early in that process happening. And so there are all these incredibly promising nascent markets and China, India, Indonesia, Brazil, et cetera. And then the third one, kind of to your Connect point, was that businesses were building these kind of increasingly just complicated transaction oriented services. And I mean, Connect is a good example, but crowdfunding is another. Right. Sort of Kickstarter does not monetize or facilitate advertising. They facilitate just this completely new kind of transaction. Right. And so realizing that this was increasingly sort of at the core, like not just partial, but at the core for kind of the next generation of companies were doing like, if you think about it, Airbnb, Uber, Kickstarter, Instacart, Lyft, everybody.

Interesting.

Yeah. These new kinds of sort of real world economic relationships were sort of an integral part. And so the belief was that, well, there's going to be a lot of those and sort of the use cases are going to get richer and more complex over time and there needs to be sort of a completely integrated set of tools and APIs to facilitate the whole thing.

Okay, so I'm going to ask a bunch of questions about engineering and stack and product definition in an organization, but you guys get bored if you don't ask questions. Do people have questions at this point or should we keep going?

How did you go about setting up the sort of back end relationships with the credit card processors and all that when you were really small? Right, Good question. This was one of the hardest parts. So in the beginning we sort of worked with.

That.

I might leave off the record, but in the beginning we worked with. There was a guy I met at a party and his friend ran a payments company. It was like a tiny little operation based out of the Midwest. And they agreed to sort of let us build a prototype on top of their thing and just kind of didn't ask too many questions. And so when you sort of instantly created your stripe account, John and I got an email and we'd go and like fill out the paperwork and submit it to this company and instantly set up your stripe for your real. But manually. Manually.

How many did you do it like that?

Dozens. And actually, that worked really well because the salient point was they didn't have to do it, the user didn't have to do it, and we were fine doing it for them. And actually, it's a separate line of conversation, but there were a lot of things where we just sort of manually did it ourselves for a very long time. And then we went and we met with Wells Fargo and sort of described what we were doing to them, and we got an introduction through somebody and so forth, and they sort of unequivocally said that they had no interest in working with us. And so it's like. And then it was getting sort of increasingly frustrating because it was growing and we had to fill out more and more of these forms. Right. But we sort of had no route to something better. And so we asked, actually, one of our early investors for advice on this. It was a guy called Jeff Ralston. So Jeff had been the CEO of lala, which was kind of like an early version of Spotify, and they were like, one of the first kind of legit, legal kind of music services. And they'd gotten deals done with all the record labels. And so we kind of thought, you know, who do we know who got a deal done with the bank? Well, Jeff got a deal done with the record labels. I mean, if you can deal with the record labels, you can deal with anyone. And so we went to Jeff and we basically said, you know, help. And he was like, oh, I didn't actually do all these deals with the record labels. It was actually one of lala's co founders, Billy Alvarado. And so he pointed us to Billy. And so John and I met with Billy, and he had actually. So Apple had bought lala and Billy had just left, I think. I don't know, maybe Billy was bored. And so he's like, all right, I'll help you kids out a little bit. And so he actually ended up joining Stripe as maybe the fifth or sixth person. And we were like, he wasn't an engineer. And so at the time you had.

A BD guy as your fifth or sixth person.

Yeah, yeah. And we were really torn over it.

Because it was like, it's super surprising for a company that's so Engineering.

No, no. And we were like, he doesn't write code. I mean, should we hire a person who doesn't write code? Right. Like, what does one even do that's not writing code. And so we're sort of sharing this kind of inner anguish with Jeff. And Jeff, to his credit, was sort of commendably patient and like, patrick, stop being an idiot. I don't think he said idiot. I think he said something stronger. But for the sake of the record, I'll say he called me an idiot. And he's like, you should just hire Billy. And I remember he promised me that if it didn't work out, he would go back and retroactively pay Billy's salary. And so he was like, so there's no downside for you. And at the time, we didn't have a whole lot of money, so that mattered. Yeah, absolutely. And so then we hired Billy, and Billy is still at Stripe, and one of the most important people at the company. How did you actually start and to finish the story? So then basically, Billy went and solved Wells. And so, I mean, there's a whole kind of separate line of conversation to be had about sort of how to do business development effectively. And we were really bad at it in the beginning. I think it's actually a very interesting question. How should a startup partner with other entities? And obviously, that's a pretty important part of what Stripe has to do. And Billy taught us a hell of a lot. But about two months after Billy joined, we had the requisite relationship with Wells Fargo.

Wow. I was going to ask, how do you even evaluate how he's doing? Because he's such a different background, such a different skill set than you. I guess he just did magic things like bring Wells Fargo, and you see, that's probably good enough.

Yeah. We were kind of at the point where there were sort of fairly discreet things that kind of had to happen or not. And so in that sense, it was kind of fairly accessible. But there were also just, like, a bunch of things where he knew that. I mean, he'd basically been through kind of a real startup before in lala. And so, for example, I remember him asking pretty early on how we do payroll. And we're like, occasionally we multiply the agreed salary by length of time since people were last paid. And then it's like, give them that money. And he's like, what about deductions and tax and all these things? And we're like, really? Yeah. Wow. Awesome. And so there's a lot of altered cleanup that Billy helped us through.

It's good to have people who clean up. Okay, so I think I know this question. So I think you guys had such a clear product value proposition. I was going to ask about how you decided what things new to do. So I think I have a guest now listening to you talk, but can you talk about it for a second?

Yeah. So I think this is like a pretty hard question when you're building a consumer product because consumers don't really know what they want, right? And that like this is the challenge for Facebook where you're, you're dealing with all these mercurial teenagers and sort of the greatest minds of our generation are sort of staring in tent at all this data trying to figure out what do the millennials want. But it's very difficult. And to be clear, to their credit, they've done a fantastic job of keeping abreast of it with all the acquisitions and so forth. But it's hard, you can't figure it out through analysis or at least people haven't figured out how to yet. Whereas when you're building for developers, you can just cheat again, you can just ask them, right? And in fact, even if you don't ask them, they're probably tell you frequently relatively vocal in their preferences and desires. And so, I mean, that's a little glib, right? I was going to say it right, because you prioritize and know which one's right. And so we pay a lot of attention to sort of who we judge, who we judge to be the ones with good judgment. And you also have to sort of fit the whole thing into kind of a long term perspective of sort of how these pieces fit together and how the product ought to evolve and so forth. One of the. I remember Mark Zuckerberg commenting at one point and I think this is kind of good advice that this is like in general, I think kind of the Valley over mythologizes kind of the role of the founder and the criticality of that person, so forth. But he commented that it's very important for the CEO to be sort of integrally involved in a lot of the kind of the micro product decisions because what's optimal to do on a one year time horizon is obviously often quite divergent from what's optimal to do on a five year time horizon. And it's just difficult for anyone other than the CEO, and especially the CEO founder to have as long kind of a time horizon kind of in their optimization function. And so I think there's a fairly important aspect there. But yeah, for us it's I would say kind of 70% listening to the people who we think either have really good judgment or are themselves likely to become really big. Because just in and of itself though. Exactly. And then maybe the other 30% sort of doing things that we think ought to be big, but for some reason we're not being asked for. And so sort of a good example of this is we build this integration with Alipay. Alipay is kind of like the PayPal of China. As with sort of. So many of these things in China have this kind of.

They're pretty big.

Exactly. Kind of growing pretty fast, eye watering stuff. It's going to be bigger tomor. And we'd kind of have all these conversations with businesses who are like, and we now have this Alipay integration so everyone in China can now buy from you. And the business would say, well, I don't know if that's kind of relevant to us. We don't actually sell that much in China. We're like, let's just think through the logic of that statement and why it might be that people in China aren't buying from you. And then they often be like, ah, good point. And add Alipay into things could go well. But yeah, 70%, I would say being led by the smart companies and developers.

Right. And then how do you. Well that. Two different questions. So how does bitcoin relate to something like that? So bitcoin looks like developers get very excited about it. Do you guys get excited about it? Like how do you think about bitcoin if all developers say, oh my gosh, let's do this Right. Doesn't feel like a thing. That's huge yet. Yep.

Definitely not huge yet. I think that you have to be sort of somewhat okay with sort of making, I guess multiple people have kind of made the statement that you can't judge decisions by their outcomes. And kind of at first blush that sounds like a strange statement, but I think kind of what I get at is this idea that sort of you have to judge decisions by their EV rather than by sort of the particular outcome that in fact resulted in.

And so EV expected value.

Sorry. Yeah. And so even, I mean certainly at the time and even now it's not completely clear sort of what happens to bitcoin. But I think that sort of, I mean even if the probability is relatively low, sort of the potential significance of some success outcome is kind of large enough that it's probably worth kind of keeping abreast of it. And also, I guess we sort of felt some just general affinity to that community. I mean I don't personally nor I guess at stripe sort of subscribe to these sort of crypto anarchist, sort of let's liberate ourselves from the tyranny of our monetary oppressors. Kind of school of bitcoin, but it's.

Bigger than it sounds like.

It's bigger than you think. I think I just realized recently that probably that the original paper on bitcoin from Satoshi is probably kind of the first paper that sort of both a paper in political science and in cs.

It's a beautiful. Everyone should read. At least it's seven pages long. It's beautiful and slightly insane, but Beautiful.

Yeah, insane in a good way mostly. Yeah, I mean, whatever. The first block has the New York Times from around the financial crisis and so forth. So anyway, definitely a strong political agenda. But I think the kind of the distributed systems aspect and honestly the idea of sort of a decentralized infrastructure that sort of can be a system and a ledger and so forth for sort of so much of the substrate. I mean, that's kind of a cool idea, right? And so we wanted to do a bit to help move it along.

Okay, so who runs product at Stripe?

So well, we have a bunch of different product engineering teams. Some of those teams have product managers on them. Not all of them do without actually counting maybe five or six of those teams. And not all of them are kind of formally broken out yet and so forth. And then there is a single engineering manager who manages all of the managers on those teams. And then I manage the product managers.

Reporting an engineering manager.

So the product managers report to the. There's basically a single manager for each of the product teams. And that person manages the product manager.

Cross functional manager manages engineers and product.

Okay, so the problem is that I guess there's product managers and then this is like product and sort of the engineering of the product. But just the simplification, oversimplification is that there are these products with teams associated with them. There's a single manager who manages all of the products, and then I manage that manager. And so kind of who runs product Stripe? Well, I mean, it sort of depends on the product because the team does kind of first and foremost and then I guess also sort of that manager and then on some level me.

Yeah, I mean, I guess the reason I asked is because you just noted how important it was to have a CEO and founder in the details of a lot of things. And that tends to create a structural instability for what Valley usually calls DP of product. That's a brutal role because you're either in a company where the CEO founder is micromanaging product, or you're in a company where they totally empower you to run product and then you have the message of the CEO doesn't care about the product. And so it's a hard place to be.

Yeah. And so I mean the, I guess part of what you're getting at is in a lot of companies, sort of there's this separation between say the engineering kind of org and the product management function. And then sort of the VP product, the person overseeing this product management function, if the CEO is really closely involved, that becomes of a pretty thin or at least difficult role.

Right?

Well, I've never seen one, but okay. Yeah. Whereas in our case we don't have a separate product org. And so again, this engineering manager, I mean there's a vast amount in that job, even sort of leaving particular product decisions aside because it's all the questions around sort of how do we staff them and build them and execute them and operate them and all these kinds of questions. And so she's sort of fairly involved in the actual product decisions, sort of as am I. But I think it avoids the kind of VP product issue because even if there was zero product decision in the role, which there isn't, but even if there was zero, there's still a huge amount in all the other parts making things work.

Yeah, exactly. Yeah. That's interesting. I wonder if that will scale. I wonder how long that will scale. It's a little bit unusual not to have them separated out at some. Eventually you get some product scale.

Yeah. Well, again, I think part of this comes to the way in which the stripe is different where sort of, I mean, we're building not solely, but in large part for other engineers. And so I think engineers can have excellent instincts for sort of what the right product to build is. Whereas when you're trying to kind of empathize or put yourself in the shoes of some completely different kind of user, then perhaps kind of the impetus for a separate product or is greater.

So interesting. So you've done product extensions, you've done new things, you did connect some other things. Have you launched products that you've killed?

I guess there's and availability bias and the ones that immediately come to mind, but.

I don't.

We haven't launched. Well, actually part of, I think what's. What's so difficult and feels so tragic when you're in the throes of it of sort of a fast growing startup is that product innovation slows down and you're like, why would that be? I mean, you guys launched with whatever 10 people, now we're 330 people, how could it possibly slow down? And I remember sort of observing this even before I was kind of in it myself, where for Airbnb and Dropbox and these other companies, it felt to me, just as a user, that basically the product innovation slowed down. And I guess what happens is there's so much investment that's required. So one, there's sort of investment required just to kind of keep up with the growth. Right. And so, I mean, the 10 people who built kind of the original stripe, they weren't capable of operating current stripe. Operating current stripe requires sort of all of these resources. Right? But then additionally, you have to sort of. I mean, because you're looking to do more things and both iterate on what already exists and build new things and so forth. And so you're learning how to sort of walk and chew gum and juggle and tap dance and all these things kind of in parallel. So that requires hiring a lot of people. And then you have to kind of train all of those people and just kind of how the company works and the product works and all the rest. Then they kind of have to all learn in this kind of emergent process of how to coordinate together and then actually relearn that several times because it's sort of constantly shifting as this dynamic equilibrium beneath them, whatever. And so the net effect is that the product actually advances surprisingly slowly. I think the flip side of it is that when you come out of it, if you do it well, then it's like stand back right where it can be so fast. And I think Facebook is actually a good example of a company that sort of went through the slow and then really sped up, but sort of. The mobile years were.

The early mobile years were pretty hard.

Yeah, exactly. But the rate of product improvement actually kind of has basically this surprising shape. And also you can measure in different axis in terms of kind of sustaining improvement versus kind of new axes and orthogonal improvement and so forth. Anyway, all of which to say we haven't launched all that many kind of discretely new things, things you could conceivably then kill. I mean, we've built little features and things like that that haven't worked out super well. We've tried experiments and so forth that haven't worked, but nothing kind of apocally kind of new. Although part of that also gets to, I think, how we build products, which is we were pretty. Again, because we work with developers and because they'll give you pretty good feedback, we often run ideas by them. We'll build a little beta we'll test with them and so forth. And then if they don't like it or they don't think it's a good idea, then we'll kind of just stop working on it. Right. And so by the time something gets to launch, it's generally gone through sort of quite a bit of validation. And the things that have been sort of really. Launch. Launched. Pretty useful. Exactly.

Okay, so a couple more things. Oh, sure.

Can you talk about any early acquisition offers you may have had? Yeah. So we've always been pretty explicit, like in the press and in any meetings we've had and so forth, that we're just not that interested in it. And so you can't be somewhat successful or. Well, to get. The strip has been successful sort of, for any company. I think it's kind of hard for that to happen without all these potential acquirers just kind of. I think sniffing around is kind of the right term. They don't necessarily have that much interest, but they're kind of interested. And also, one tends to think of potential acquirers, or even just other companies in general, as monolithic entities. Coming back to the BD point, I think one of the critical realizations is that companies are composed of a pretty diverse array of individuals, and you're not talking to a company, you're talking to a person, and you just kind of really piece that apart. And so anyway, we never had any serious discussions with any acquirer in the history of Stripe, and we were sort of pretty quick to close off any kind of significant conversations just because it wasn't what we were about to do. Actually, that was one place where our prior company had kind of gone through this talent acquisition, but we'd gone through an acquisition process, and I think that was kind of helpful in showing us kind of what that looked like. And it enabled us to, I think, be much just clearer ourselves in terms of what we wanted.

I think once you've been through an acquisition process for an okay company, I think it really encourages you to notice what's special and what's working in the place you're at, because it never quite works out the way you want. And it also just highlights. It's unusual for companies to be as special as Stripe or as special as the other things. And when you find something like that and you really have it working, you really want to hold onto it. Let me ask a technology question so I would view. I think you look around and say, well, Stripe's probably the most modern payment stack today, so how do you. But you're Also growing your customer base. Your customers don't necessarily want the most modern payments that they want the one that's stable and the one that works doesn't change all the time. And so how are you going to think about technology change going forward?

I think that is a great question. And it's something we're sort of mindful of from the beginning in developing Stripe, that you sort of have to build all these things and sort of invest in different ways to enable you to kind of innovate sort of without being problematic on that kind of other reliability access. So, for example, we have this kind of really complicated versioning system for the Stripe API where there are all these different translation layers composed sort of help turn one API version into the prior one. So basically people can be on almost any version that we've had over the last couple of years and everything works just fine. We recently went and deprecated a Stripe API version from like 2010 that was kind of like a big deal for us. And we looked through and there were like three people still using it. And so we're like, all right, you know, we can reach out to these people and tell them that we're no longer going to support it, but sort of as a default matter, basically anything we ever release, we're going to sort of commit to keeping it to work. And that kind of required, like that's.

Easy to say and fairly hard to do that.

Well, exactly, it's pretty hard to do that and also enable you to sort of change lots of things.

Right.

And that's kind of where this translation layer kind of comes in. And so that's kind of an example of the kind of thing that you have to do in order to enable that. But for us, it's a constant process of sort of revisiting that. Right. Because I mean, you kind of these two axes again, of sort of reliability and sort of, I can't hate to say innovation, but innovation. And you're trying to expand on both because you actually want to get more reliable over time, obviously.

Right.

And also kind of the difficulty in being reliable over time just because there's more stuff sort of increases. And you would also like to be doing more things over time. And so I think we have a pretty good sense for kind of what the right side of trade offs might have been kind of a year ago, but sort of in the current state today, it's something we're literally. I was having this discussion last night with a group of people and I will say that sort of, I mean, It's a general thing. And I think this is just like a testament to the engineers. I think Stripe is just one of the most reliable infrastructure providers, just period. Right. In that the total availability record for kind of the API as a whole has just been kind of remarkably solid. And I don't know, I guess I no longer write code. And so this is kind of no credit to me. I mostly just. I'm sort of impressed from a slight distance.

Okay, so we'll ask a couple of management questions and we'll open it up. So you said 330 people. So the Dunbar's number. Well, in the rearview mirror, 150 people was over a year ago, probably. So what do you do differently now? I mean, you went off and you hired Claire as coo, right?

That's right.

What else do you do differently now than you would have done a year ago? And how do you think about this stage from a managing the company standpoint?

I think the big change. I'm sure other speakers have said this or. Well, actually, first, I should preface everything I say here by. I mean, I guess it's. I feel like I'm sort of a bad person to be speaking on this stuff because, I mean, you have had or will have all these other speakers who sort of have actually solved all these issues. And so you should sort of discount everything I say with the fact that this is somebody who's currently trying to figure it all out. And probably at least 50%, optimistically, of what I say is mistaken, but at least I can. No comment.

But I don't pay pretty close attention.

When Patrick says that at least I can give you some bad ideas you can kind of benchmark others against. So the big change, and the most kind of striking thing for me, and maybe this partially comes from my personality, where I am kind of introverted, is the need for sort of just formal, explicit communication, broadcast communication. And it feels sort of. I don't know, I mean, it's unnatural. Right. And like, nobody sort of wakes up in the morning and sets out to speak.

Some bullet points.

Yeah, exactly. Right.

Three priorities for this morning.

Thought I'd give an Update on our Q5 strategy. And so there's sort of a lot of that. That just you have to learn to be okay with. And I think part of the way to rationalize it is that a startup itself is not a natural environment. So you're absolutely correct that sort of your natural instincts are going to. I mean, the optimal things for you to do are going to differ from what feels natural because the startup itself is not natural. Sort of the social groups that you're a part of, that you participate in, they don't generally grow at 50% or 100% per year. And kind of a different sort of set of behaviors are required to enable that. And so that's kind of the primary one. And then let me highlight this again.

So half the people at stripe weren't there 12 months ago.

Half, yeah. No, it blows my mind too.

So half the people, whatever your last annual off site was or whatever you did, didn't hear anything Patrick said in the deck you wrote a year ago.

Right. And every discussion we had and debate and, you know, tortured sort of questioning and so forth, like they weren't there for that. And, you know, we might have spent months on it and sort of a new person comes and like, oh, and I don't think we should be doing that. We should do this. Right. And of course they do with the very best of intent. And in fact, a large part of that is what's good about hiring new people is they sort of help they reopen some things. Exactly. They reopen things. They have a better sense for how to do things. They bring you perspectives, sort of all that stuff. Right. But they also just don't have the context. And so it's this kind of very delicate sort of balancing act.

I think this is a profound realization that almost every good CEO goes through, which is they realize that their job is to communicate that you're running on a tighter loop inside your head than anywhere else. So you're learning all the time. All the time. All the time. And the organization, one layer, two layers, three layers away from you can't absorb that change and you can't communicate all what you're thinking all the time. And so it's all about consistency and alignment. Almost everybody I talk to values alignment the longer it goes.

Sure, yeah. Although again, I think there's sort of a delicate sort of superposition of things required there where sort of, on the one hand, yes, you want alignment. On the other hand, the company is sort of overly rigid or prescriptive or whatever. I mean, that's pretty problematic. That's the kind of thing that makes people want to quit companies because sort of their particular perspective or the thing that they want to do is divergent from this calcified edifice that is the company. Right. And so it's kind of how do you have sort of the right amount of structure and flexibility and all those things?

I think you're trying to. My two cents are you're trying to teach people how to think in the right ways, and you're trying to teach people how to. You're trying to create the conditions so that they would make roughly the same decision as whether you're in the room or not.

Yeah, even that's a little stringent. And caveat it with I'm definitely not sort of the right person or the optimal person to be making all kinds of decisions. In fact, I'm the optimal person to be making a decreasing fraction of decisions. Right. And so it's not precisely sort of to do what I would do were I in the room, but I don't know, some version of like.

Well, the stripe.

The stripe there is sort of in the multidimensional space of philosophies and kind of perspectives, there's kind of a stripe blob, basically, and sort of I maybe am closer to its center of mass than others because I've been around longer and maybe had a bit more influence. But it is distinct and it's shifting and it ought to shift.

That is not what you expected him to say. Multi dimensional philosophical space where stripe blob.

The stripe blob. Right. I think it really has a ring to it and. Well, a corollary of all of that in terms of just the kind of the solicitous required. I think the kind of. The more general version of it is that just you should generally shift from speaking to writing. Oh, you think that? Yes. I mean. Or rather it's not that you should necessarily speak less. You should probably still speak. Right. But at least I think so. I don't know if anyone else thinks so, but you need to add writing. Right. Because speaking can kind of only happen once and generally not to everyone, or probably become super boring if it's to everyone. Right. That's this giant production, whereas sort of writing persists through time. Right. And can be revisited and can be updated and so forth. And also has sort of a helpful, at least in the good cases, sort of rigidity and clarity to it. And so one of my kind of favorite things I realized, just ones that kind of had the biggest impact on me over the last maybe two years was reading this paper from, I think it was Bruno Latour, and he was talking about the scientific revolution, Right. And the invention of writing. And kind of. We've all heard that sort of the writing and the inventing of the printing press was sort of critical in enabling it. And they're basically Gutenberg, scientific revolution, job done. And his argument at least goes that it was actually kind of much more nuanced than that. Where it's not that sort of writing or the printing press sort of per se enabled more distribution, which automatically led to more ideas, because people still talked a lot previously and people had a pretty good sense for sort of the total space of ideas. And so simplistically, the printing press could come along. It doesn't substantially change things. But the additional property of the printing press, beyond just kind of dissemination that it added was concreteness and kind of rigidity. Rigidity. And so when you're hearing something from a friend of a friend of a friend recounting something that happened a year ago, God knows how much it's shifted and changed. And because it's not really rigid, it's this just again, amorphous blob. It's hard to disagree with it because who knows exactly what they said. And so it's hard to weed out and reject the bad ideas. Whereas when it's writing, you can point to paragraph three, sentence two. This is wrong. And it does not match my data.

Right.

It's actually kind of that aspect that was so critical. And so anyway, going back to the writing version, I think that it's much more clear and it can be wrong and it can be updated in a way that I think is really helpful.

And that's super interesting. I could talk about that a lot. I feel like the way you communicate really shows through in your product a lot of times. Like we came in Bugs and Bugzilla, Mozilla, and it created very well. Anyway, it's an interesting. A lot of artifacts get. Get created. So let's do a question. You had a question. This is sort of tangentially related, but.

Latora also makes the argument that interpretation is really the big issue with writing. So the idea says not the language is permanent, except it's the right for reinterpretation. The point that writing is really always open to reinterpretation.

So it's risk of saying that.

It'S rigid is what makes it so blank.

So the question is just that writing is all like Latour, the guy that Patrick quoted would have said that writing is always ripe for reinterpretation. But I think Patrick's making the point that it's just simply more rigid than just spoken.

Sure. Right, Right.

It's on a spectrum, Right?

Yes.

Sure.

Though it sounds like there might be a. Oh, sorry. Next version of the class. I guess we can tour deep, deep.

Dive a couple of philosophical blob questions.

Yeah, you mentioned pick the name Stripe Just by random. Oh, right, yeah. So it's also an embarrassing story. Well, it's kind of a helpful exercise in humility because. To just remind you of just how mistaken your past self could be. Or wrong. So, anyway, devpayments we thought, was super awesome. Cool name. The world didn't quite agree when we went to incorporate with Delaware. We duly filled out dev payments on the paperwork. It was rejected because we had actually checked, can you have a slash in the name? And you can, but you can't have a leading slash. But of course, being determined entrepreneurs, we overcame that and we incorporated as S L A, S H D E V S L A. It was really bad. And then we'd get mail, whereas, like, slash character dev. Yeah, there were many problems with this name. And then you'd have to go and have a meeting with a bank and be like, all right, the last question about. It's like, what's the company called? And then basically everything fell to pieces. So you wonder why we couldn't work with Wells. So we kind of eventually came to realize that we needed to change the name and we just couldn't come up with a good name. I guess many people have been through this and it basically resorted to us. We had all these books in the office and just like opening books and being like, actually, one of them was a motorcycle repair manual because John was riding motorcycles. And so we were like, carburetor, probably too hard to spell. And so you'd flip another few pages and it's like wheel, that's a bit generic. And so we were literally reduced to picking random words late at night. And then one of the folks at Stripe had the bright idea of, well, why don't we just assemble a big list of words and email all of the owners of the dot com domains. We just kind of see if the words were actually available to, again, just kind of reduce our search space a little bit. And so we assembled a list of like 100 words that all seemed like generally cromulent words and just emailed all the owners, and only 10% of them responded. And of those 10%, you know, most of them wanted millions of dollars, whatever, Right. And so we kind of assembled a partial list that way. And then we also just kind of continued our own creative process, which we've already established was awesome. And so we came up with memorable names, like paydemon.

With an A. Undoubtedly.

We bought both versions. We still own both versions, actually. And if you do a whois on paedemon.com. and so, yeah, we Thought it was super clever because we could have this awesome mascot, although maybe BSD confusion issues and. Yeah, well, it was great. We really liked the idea of building things and so the act of creation and so forth. And so we thought we're kind of enamored with Payforge, this kind of blacksmith idea. And then of course a friend pointed out that other connotations like, ah, good point. And so we're really struggling. And so we, the owner of Stripe.com generously responded to us and had an offer that was at least within our plausible budgetary range. But we couldn't decide between Pay Demon and a Stripe. I swear I'm not making this up. And so this is the part where the kind of humility comes in. It's like, Jesus Christ. So we decided that if we could not settle on a name by, I think it was December 20, 2011, we would just like no, 2010, December 20, 2010, we would just default to Stripe. And we couldn't think of a more compelling name by December 20th. And so stripe it became. And then we sort of. The second part of the story is we. We hadn't launched at this time, but we had a handful of beta users and we kind of were going through the rename checklist, right? And so you'd like buy new SSL certs and move all the servers and regex g sub over the code base and all the stuff, right? Do the images, like a lot of stuff to change a name. And somehow we neglected one of tell the users. And so all these people, I mean all these people being like 10 of them, but all these people went to log into their dev payments accounts one morning and were like redirected to Stripe. And so we got a few emails, am I being phished? Or whatever. But we reassured them and that was that. And actually made the very last kind of detail in that story is I was then reading the Little Kingdom by Mike Moore. It's this kind of history of Apple and apparently Apple went through sort of a similar thing where they couldn't think of a good name. And so they set it sort of the same timeout of if we haven't thought of a better name by such and such such date, screw it, Apple. And so we subsequently learned there was some precedent.

One more question.

Can you talk about your transition from a developer, someone who is technical, someone who worked on the product, to a manager? Yes. So it still pains me a little bit, honestly, in that I really miss coding. And so I often kind of get this question of do I Miss it or not? And kind of what does that feel like? And just the short answer is, yes, I miss it. Well, I guess so many things then to say about sort of the ensuing transition to both being a leader and a manager and so forth. And on some level it reduces to, I guess, kind of how do you run a company? And a lot of things to be said there. I think just one thing I'll sort of flag is that in general, I think the industry both kind of over biases towards founders, but also towards CEOs in that I guess we all sort of have this kind of narrative sort of bias or something where we, we want to associate kind of abstract concepts like a company with particular people. And so kind of like I am the shelling point of Stripe and sort of being the CEO, but kind of the degree to which I am sort of sitting here and representing Stripe, I am sort of in general, in aggregate, sort of vastly overrepresented relative to everyone else. And so I guess to kind of follow that thought, I think that sort of it's not so much my transition to management or whatever, it's a lot of people at Stripe collectively transitioning to running an organization. There's a pretty large skeleton there. And actually one of the very clarifying realizations for me was Ali Roghani commented that basically the CEO's job can be reduced to just three things, or possibly four, and that everything that's not one of those three, or again, potentially four, is out of scope. And the three that he identified were the strategy. And kind of ideally, if the strategy is right, that doesn't require much wall clock time, right, because you keep doing the same thing. And secondly the culture, because there's no other person who can do it, or there's no person who can do it to the same degree, who has the same moral authority. And then the third one being sort of selecting the senior management of the company because again, no one else can do that. And those people will ideally be sort of domain experts who know far more than you and are much more effective in sort of particular areas. But you have to hire, select them, ensure that they're effective, everything else right. And so in his kind of ontology, that's it, that's the job.

It's pretty close.

It's easy if you get it right. It's obviously incredibly hard. Can you fix a broken culture? How does one sort of in the abstract come up with a good strategy? I mean, they're really hard when they're not working, but I think when they're working, it can go pretty smoothly. And then the fourth one, which he described as being optional is the product. Basically, the CEO can be the head of product, and maybe even that varies depending on sort of the company that you can sort of the CEO can also be involved with sort of one specific function, right? In that maybe at some companies the CEO is also the head of sales. And I think that's probably sort of a little bit kind of simplistic and kind of reductionist and so forth. Although maybe I'm just trying to make myself feel better or something, but sort of that was one of the most helpfully clarifying things that I kind of heard about that transition.

Okay, I think we're done for the day. I mean, maybe Patrick can stay for a couple minutes, but we should let him go too. So anyway, thanks for class and we'll see you all.

Thanks for having me.