Patrick Collison

maybe software becomes a bit like pizza. Software should be like pizza in the sense that it should be cooked right then and there at the moment of use. And so it's this quite fundamental shift where you don't want mass -produced industrial -scale software. You want bespoke custom software made for you that moment. That's very fundamentally different. Up until now, the economics of software have been conceived of as fixed costs and then monetized as much as possible. Once there are inference costs and custom creation involved, it really shifts. I don't quite know where it goes, but I think it's going to look very different.

If Stripe is a monstrously successful business, but what we make isn't beautiful and Stripe doesn't embody a culture of incredibly exacting craftsmanship, I'll be much less happy. I think the returns to both of those things in the world are really high. I think even beyond the pecuniary or financial returns, I think that just like the world's uglier than it needs to be. It's a free lunch where like one can just do things well or poorly and beauty is not a rivalrous good. My intuition is that more of Stripe's success than one would think is downstream of the fact that people like beautiful things and for kind of rational reasons.

Because what does the beautiful thing tell you? It tells you the person who made it really cared. And so if you care about the infrastructure being like holistically good, indexing on the superficial characteristics that you can actually observe is not an irrational thing to do. There's a reason there's a very intricate filigree on the $1 bill. Yeah. Banks had it figured out a hundred years ago where bank buildings should be nice. And so we're just continuing that. Lots of the way. But also, if someone really convinced me that the financial returns to craftsmanship and beauty, which I believe are greater, are not greater, I'd still do it.

Life's too short. Take care. Take care.

I think one of the most kind of pernicious mental models you can have here is that you are on some growth curve. I think a much better mental model to have is you're serving some market, and then there's sort of the percentage of the market that you're serving. Whatever percentage you are not serving, you just haven't built the sort of go -to -market functions and organization that's brought the product to those market segments. The growth curve or adoption curve is just kind of a function of that go -to -market apparatus. But basically, it's not some kind of cosmic trajectory. It's something kind of very much of your creation and under your control.

And so what we did not do, but what I wish we did, is six months after launch, that we should have sort of mapped out the kind of concentric circles of our market. Very early stage startups that were kind of our sort of initial constituency. Then there's kind of all technical startups, but not necessarily very early stage. And there's kind of, I don't know, you keep going in these kind of successive increments until eventually you get to, say, all companies handling online payments or something, right? And I've gone and sort of figured out, okay, kind of what's the size of this market? What fraction are we currently serving?

What would it take to serve more and so on? And let's kind of work backwards from, okay, what would the organization look like that was serving the entire market? And let's just start building that organization because, again, the growth curve is under my control. Of course, it's not like 100 % under your control, but I think it's much more under your control than people tend to think. Thank you.

The received wisdom is, you know, work really hard to hire the best people. You're like, gee, thanks, you know, 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. It took me six months to hire the first two people. So a person per quarter, even though we had this kind of network already and knew all these people, we've 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. 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, they have like pretty good paths out of them, right? 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. The big thing that people have to keep in mind in sort of 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 you know could think it should take.

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. And you know 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. Like if you get just one great person, that makes it marginally easier to get the next great person. So I think it's that dynamic in spades and then kind of secondly I think kind of another way to think about it that maybe makes the kind of the importance of it and the potency kind of clearer is that you have to kind of imagine the tree of sort 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.

There's an interesting book, Apprentice to Genius, that follows three or four. It's three generations of scientists. So someone who mentored somebody else, who in turn mentored another scientist. And they're all extremely successful. And the book is kind of this reflection on, I mean, this description of what they all did, but also this kind of reflection on, well, like, what is it that was transferred? And, you know, for example, one thing it describes is, well, one of the most important and subtle questions in science is problem selection. Like just how do you choose what to work on, right? No one tells you what to do. And you do have to answer this question multiple times.

Like with a company, in some sense, you just have to decide like once and then, you know, it's kind of, well, maybe it's an iterative process from there. Whereas in science, you're frequently pursuing, you know, completely new problems. And of course, you need to choose something that's sufficiently important and hard that it would be important if you succeeded, but also that, you know, it's not so intractable that, you know, you can't actually make any progress. And so the book describes how this is part of what the mentees describe that, you know, they learn from their mentors. Another thing they talk about is just learning about high standards and what high standards actually are.

And when I talk to people in other domains, this is so frequently the thing that I hear from them, that when they worked with X person or Y organization or in Z environment or whatever, that they learned what great actually is. And that just permanently changed their sense for what their own standard for their work ought to be. And so maybe one version of the, you know, what people in their twenties should do is, you know, get some ideas to domains you're interested in or care about, but then figure out where can you learn the highest standards, where are the highest standards embodied and where, you

know, where, where can you go and experience that firsthand? Huh.

What is the financial infrastructure for AI agents look like? It's in some kind of extremely primitive way happening today. And I assume it will follow some gradient where some of those decisions are either directly or indirectly being made by an LLM or some LLM equivalent, some almost unnoticeably smooth continuum up to very considerable degrees of autonomy. But it's not that we're going to like wake up some month and be like, oh my God, you know, suddenly the bots have been unleashed. These autonomous transactions conceivably being an important dimension is very true and real and is one of the interesting ways in which the economy, you know, might change and expand over the next decade.

And I think it's possible that crypto plays some role here. We take KYC and AML very seriously for humans. It's a murkier question in the context of some AI agent. And, you know, if we look at crypto as the part of financial services that is de facto exempt from AML by design, maybe that plays a role.

When I look back, and look, maybe this is the rationalization I tell myself, but when I look back through life at the things that I'm most glad I did, I wasn't exactly happy while doing them. Often I was very stressed out or I had to work really hard or whatever, but they're the things that post hoc brought the most fulfillment.

I think that, well, whatever, there's rich literature here and so I won't dive too deeply into it, but I do think happiness is a tricky concept to pin down because is it happiness in the moment? Is it the sense that you have a year later looking back and so on? Language is squishy and it's not completely specifically defined, but I think generally speaking a better utility function and gradient to try to climb is that of fulfillment.

And so I would say the experience of doing Stripe was not especially happy because we were sort of constantly sort of incredibly aware of all the ways in which the product was severely deficient and all the challenges we faced. And I mean, it seems like there was no FinTech category back then. It was just like two teenagers or just over teenagers trying to compete with PayPal, which many people told us was not an especially kind of promising avenue to pursue.

And so not especially happy per se, but it did feel kind of fulfilling. Like I enjoyed working with John and the kind of people we subsequently hired. It was really fun working with the kinds of kind of customers we were serving. They were just sort of businesses doing all these kind of wonderful things and they were kind of really smart people. And it felt that like if it worked, it could be kind of consequential in the world. And so I would say kind of it sort of felt like, I mean, you know, I don't know what it feels like to be sort of a scientist or something, but I'm guessing when you're sort of pursuing all, you have this kind of big question and you're pursuing all these kind of avenues to sort of try to better understand it.

And I'm guessing day to day it's sort of not especially happy because, you know, most of your experiments don't work or whatever, but sort of perhaps there's some analog there in terms of it still feels in some sense meaningful.

I always love the story that, in sort of the famous house that Facebook started in, in Palo Alto, that like, Facebook was not the only company they were working on, right? There was also that peer -to -peer file sharing thing, right? But I mean, Facebook had sort of launched at Harvard, at least in, I think, February of 04, right? And so they're working in that house, you know, that subsequent summer. And I find it very interesting that sort of, you know, call it six months later, it was kind of not obvious that like Facebook was the thing to be working on, right? Right. As you're kind of pursuing multiple ideas in parallel.

And sort of similarly, you know, with Stripe, even though, even once we built this little prototype that, you know, we thought held some promise or whatever, it wasn't like, obviously a great idea or anything, right? And so what we actually went and did was we, we came out to the Bay Area that, again, that subsequent summer, this was for us in the summer of 2010, and just decided to kind of work on Stripe as our kind of bootstrapped internship. And then over the course of that summer, basically, and again, I think there's kind of maybe a lesson here where, you know, I think a lot of really good ideas really don't seem particularly great or big upfront.

Again, certainly speaking from personal experience, Stripe did not. But over the course of working on it that summer and sort of thinking about it and so on, we kind of came to shift from sort of thinking about it, you know, merely as this nice little tool for developers that kind of makes their lives easier, you know, initially, which is kind of what we started out with, to kind of realizing that, well, when you sort of survey the broader landscape, it's not just that it sort of sucks for developers to have to sort of integrate payments initially into their website or service or whatever, but that like the whole edifice is broken, right?

We came to appreciate that sort of what we thought was kind of, you know, this little pond was actually kind of this much larger ocean. And so we see that summer, we kind of made two decisions to drop out of school or, you know, as our mom used to prefer, we call it to take, you know, a leave of absence. And then secondly, we had to go raise some initial money from Sam Altman and Peter Thiel and Sequoia and a couple of others.

I think it's interesting that API design in general doesn't get more study as a discipline and as a practice. I think it plays a significant role in the fate of platforms. When you get API design and architecture right, it can be so enduring over literally multiple decades, even in the face of what are otherwise kind of frenzied evolutions in everything around it. We're all trying to impress upon people at Stripe the importance of multi -decadal abstractions. I think people sometimes respond to that thinking that that's implausibly ambitious. But no, I think that's actually just what happens when you get this stuff right. And if in fact you get it right, you can just reap these, or really the people building on your platform can reap these incredible benefits for a very long time.

Unix, of course, is kind of another example of this where, yes, Unix has tons of shortcomings, but the architecture has basically worked for now more than, I guess, around half a century.

between, say, five and 50 people, I think we are much too consensus oriented. We, of course, weren't completely consensus oriented. I mean, we couldn't have gotten anything done if we were, but I think we kind of biased too much in that direction. And I think that's a relatively common mistake, right? There's no particular need for sort of formal decision -making mechanisms, but then you hit 15 people and now there is. And I think companies don't adjust quickly enough to sort of that new necessity. Again, very much as included. And so the higher order piece of advice, and perhaps I'm overextrapolating from our personal experience, but the higher order advice just kind of reflecting back would be, when you hit a certain size, again, I'm just going to say 10 people for the sake of simplicity, maybe it's a bit before, maybe it's a bit after.

I think you need to kind of adjust more deliberately to this kind of explicit communication model of being sort of quite firmly non -consensus based. I mean, nobody likes the idea of sort of being hierarchical. That sounds pejorative, but like in some sense hierarchical. And there is this kind of delicate balancing act. On the one hand, you want to sort of really prioritize speed and agility, which involves being kind of somewhat hierarchical because those are sort of efficient ways to have shots get called. But on the other hand, you really do want people to have this kind of strong ownership mentality and real sense that sort of they can cause things to change or identify problems or sort of inject new ideas even in unrelated areas.

And so it's this sort of delicate act where how do you sort of facilitate enough autonomy and agency but also not have things devolve? And again, you know, I really wish there was kind of the sort of rote simple, well, just do X, Y, and Z, and you'll be good. But sort of if such X, Ys, and Zs exist, you know, no one's told me yet. Thank you.

We really tried very hard to understand in very granular detail what exactly it was that people were doing, where they were tripping up, and so on. So just to give you some examples, we had a chat room for providing support when people were integrating Stripe. It was actually a public chat room, which had some downsides. Because if we'd broken something, or if somebody had some embarrassing issues, everyone would see it. We thought that was good, because it would actually put more pressure on us to have the product be good. And we had literally every time, for the first, I don't know, call it 10 users of Stripe, every time somebody sent an API request to Stripe, it sent an email to us.

So we were looking at every single API request. And if we saw users do something weird, we're like, well, why did they do that? Or where were our docs confusing or whatever? We did things like every time anyone ever hit an error. That generated a high priority email to us. And so we would try to immediately go solve it. And that also generated, I think, this pleasant user experience where it's frustrating when you hit an error in some service. But we could then often, 15 minutes later, reach out to them and say, hey, we saw that you've encountered this problem. It's all fixed now. These are all examples, I'd say, of the general pattern of really trying to be hyperattentive to all the micro details of what people were doing the product and iterating rapidly in response to it.

And generally speaking, I think that pre -product market fit metrics are actually relatively unhelpful. Because probably not that many people are using your product. And so if it's 20 users, you can in some sense afford to just look at everything they're doing and try to understand what's working and what isn't. And actually, on this point, we had a thing at the bottom of every web page. We had a little text box. But we had placeholder text in it to try to prime people to tell us things. Most of the prompts were negative. It was like, the worst thing about Stripe is, or the worst thing about this page is, or I really hate the way Stripe does, or whatever.

At that stage, you have to be kind of masochistic. And so again, we'd be always waking up to all these emails telling us all the terrible things about Stripe. But that was a helpful to -do list for the day ahead.

The general thing I'd say is, I think working with people you're close to is underrated.

And, you know, I'm doing ARK with Patrick Sue and Sylvana. Fastcrans was with Tyler and Sylvana. Stripe is obviously with John. And actually, John was also, I should mention, instrumentally involved in ARK's formation. Like, it would not have happened without John.

And, you know, could give more examples. But I feel like for all the ventures of any significance in my life, they've, like, not only been with others, but been with other people that I'm very close to and where I had and would like to have an enduring relationship, you know, that outlives them. And, you know, sometimes one hears the advice that, you know, you shouldn't work with friends or maybe you shouldn't work with your partner or something like that. And look, all these things are idiosyncratic and there are instances of every possible permutation. But for me, it's been a really rewarding experience. And, you know, I think John and I can work together for, you never know life, but, you know, I think we'll probably work together for decades.

And I, for us, it's been a really, both an important source of just meaning and, again, fulfillment, but also I think there's a real complementarity. And I think that Stripe would be a less effective company, you know, without either of us. I don't know if you mean from, like, a bandwidth standpoint or something, but I think we both bring different things.