Patrick Collison on effectively running a startup

So Patrick, welcome. So Patrick is the co-founder and CEO of Stripe. He launched the startup, we're now a pretty big company, in 2010, correct? With his brother, John. Well, actually, we started working on it full time in 2010.

But actually, to your comment just there about companies launching, it took us quite a while to launch, because we had all these kind of banking partnerships in place and so on. And so we didn't launch until September 2011. We'd been working on it for almost two years at that point. And every time we saw a PG, or really anyone else from YC, all they would ask us is why we had not launched yet.

So some things don't change. That's interesting. So two years until you had to practice. It was, I think, one year and 11 months from first line of code to public launch. Which, to be clear, I don't recommend. That is not a good idea. It's just we had to, because we had to kind of get all these other things in place. It sort of took us so long to be able to publicly launch.

We tried to be very disciplined about gradually expanding the number of users every month. And so even though we weren't publicly available, we got our first production user just three months in. And then every month, we tried to add at least a handful of users. And so by the time we publicly launched, we did have about 100 users. Which, I mean, back then to us, that seemed like a big deal.

But it seemed very large. Speaking of, actually, when I was preparing for this interview, I was trying to jog my memories. And I remember specifically, because your office was near here in Palo Alto. And I remember back then, people would always talk about the Collison brothers running around, going to people's offices, and installing their API into the web apps.

And in true do things don't scale fashion. And I assume you were not only trying to make sure they installed it, but also get user feedback. And it happened so much that actually, I don't know if you know, Paul Graham, PG, now calls it the Collison installation. And this is actually something we tell founders to go do this, do the Collison installation.

Because obviously, in hindsight, it seems so obvious to do. Well, it sort of served two purposes. One is, to your point, it served as a really good way to get user research, and to get UX feedback, and so on.

If you've done this, I'm sure you've had the experience where you design what you're absolutely certain is the most streamlined, user-friendly, straightforward, frictionless way to do whatever it is the product does. And then you present it, and put it in front of a user. And you just ask them to do whatever it is. And they find it completely impenetrable. And they're clicking all the wrong links.

And they can't find the next button, even though the next button is there blinking green and stuff. And so it's invariably incredibly painful, nothing so sobering as watching somebody use the first version of some new product. But the other reason for us was, we would suggest to somebody they use Stripe, or they switch to Stripe, or whatever. And invariably, the response is, oh yeah, sure.

That sounds awesome. But they'll postpone it, and they'll postpone it again. And there's never a moment where it's like, OK, this is the evening where I'm going to switch to Stripe. And so us going and accosting them in person helped, you know, people talk about it in sales. It's always like a why you, and a why this, and a why now, and these kinds of questions.

And going in person kind of created a why now moment. It's like, well, we're here at your house. Did you just show up, or how did you? I don't think we ever actually just showed up. Although, perhaps we should have. But no, we tried to be kind of at least semi-invited. Got it. So Stripe now, today, I mean, you've come a long way since back then.

I mean, it's not even been, it's really been a decade, not even. But I mean, today you're, well, you have 1,300 employees across nine offices across the world. You're doing, I have a list here. You manage 200 million API requests a day. You process billions a year for millions of companies across 130 companies. In your latest round of funding, Stripe is now worth $20 million, billion.

Anyway, the list could go on. I'll stop there. Otherwise, people are going to think I'm your PR agent. But anyway, you've clearly done something right. And so I want to spend a lot of, I guess, the time today talking about running your startup from the perspective of the startup CEO, you yourself. And it's kind of like Zoom.

Like, what do you think about from Zooming in on the day-to-day operations to Zooming out to the long-term strategic decisions? So maybe to help us ease into the discussion, one thing is when you start off, from the very beginning, a lot of friends get together. And they come up with an idea. And they're super excited. And they start working on it.

And then at some point, they need to decide, ah, we need a CEO for this company. And some people aren't meant to be CEOs. But for you and John, I've met both of you. You're very smart, ambitious people with great qualities and attributes that correlate to becoming a great leader. How did you and John decide you would be the CEO? Well, I think Stripe is unusual, where John and I are a few brothers.

We've known each other for a long time. And because of the relationship, we're able to place a lot of trust in each other. And we really do run the company together. There's no major decision that Stripe has made that we've not both been a part of. And it's not always the case that, despite being the CEO, I'm the person who, in the case of disagreement, it's not always the case that I prevail.

Our dispute resolution framework is much more around which of us cares more than which of us holds this title or that. And John's title is president. So there's some, I don't know. Both are significant roles. And so in that regard, I think we're kind of an anomaly. The fact that I became CEO was, honestly, semi-random.

And I would say, yeah, I think because we're brothers, we're able to get to this unusual situation, where we really do run it together. Is there a certain? Which, sorry, may not be a helpful answer. Because perhaps you're trying to encourage all these companies. It's like, shit, one of you guys has got to be the CEO. But. Well, do you think there's a rubric for this?

Here are five questions you should answer. And maybe then you decide. That's a good question. Maybe not. I'm guessing it's quite. OK, well, I will say one thing, which is I think it is important to just have an efficient mechanism for reaching a decision. And it can't be simply orange around consensus.

If there are three co-founders, and none of you quite want to, or nobody is a clear CEO, and you don't have some kind of efficient mechanism for having decisions get made, I think that is a recipe for failure. And even doing some kind of quasi-democratic voting is probably not a great idea either. And so for myself and John, we both have areas we respectively specialize in.

And so that doesn't mean we have absolute autonomy and authority there, but we bias in that direction. So he spends more time, for example, working externally with users. I spend more of my time working internally on a lot of product and engineering things. That's not to say that he doesn't make decisions there, or I don't here. But again, there's a bias in that direction.

And then secondly, we have this additional aspect where, in the case of it being a major decision, and we sort of respectively disagree, then we really do sort of try to make it based on which of us is just more passionate about it. Because that will correlate with the outcome.

If one of us really wants to do something, or thinks that x or y is the right thing to do, simply wanting it to be so passionately is more, I mean, that can become a sort of self-fulfilling prophecy. And so I think it's kind of not irrational to have that be a consideration. Yeah.

And I also see the best teams that work well together are the ones in which everyone, they all want the best idea to win, not their idea to win. And so there's a stepping back and an unselfish kind of way to get to that conclusion. Definitely.

And I think that something that we're kind of lucky about that I think is very, well, exactly to your point, I think is definitely present in sort of the most successful co-founding relationships that I've seen is some degree of sort of dispassion in disagreement. And for us, I think that was kind of easier to get to because we'd been disagreeing with each other for 20 years.

And so it had lost some of the emotional charge. But I think that sort of finding other mechanisms whereby you can get there, such that it's not sort of this, I don't know, this kind of, the notion of disagreeing strongly is not sort of a scary phenomenon.

And the kind of both parties, or multiple parties if there are more than two, are kind of suppressing their feelings for fear of there being this divergence. You have, how many more siblings do you have? Do you have one more brother? One more sibling, yes. Three of us in total. Would you guys, would he join the, or is it just you and John as a special match there?

Well, Tommy, my youngest sibling, he's sort of quite a bit younger than myself and John. So John is almost, or is approximately two years younger than I am. And when we started Stripe, I guess I was about 21. And I think, I guess therefore John was 19. And Tommy was still kind of definitively midway through high school. And so it just wasn't quite practical at the time. Yes, finished high school.

And now I think if you asked him, he'd probably say he'd never throw his lot in with miscreants like us. So in terms of the role of CEO, often people say there's a threshold in time in which, and it's related to product market fit, where you have a role as a pre-product market fit CEO, and then which is completely different from your role as a post-product market fit CEO.

So I want to spend most of our time talking about pre-product market fit, but just to calibrate those questions, what, in terms for Stripe, what was product market fit for you? Like how did you define it? Were there metrics to it? What number of employees you were at when you reached it, so on and so forth? Yeah, that's a really good question.

And I think you're exactly right to kind of divide things into sort of, there's kind of, the story of a startup is two stories. It's a story of getting to product market fit, and then the story of kind of what happens subsequently. And obviously there isn't like a totally definitive binary line between them, but I think it's kind of helpful to frame the narrative in that regard.

And I would say for Stripe, actually around the time we launched publicly, I think is basically when we had it, in that when we launched publicly in September of 2011, we'd kind of rebuilt significant components of Stripe kind of multiple times in response to user feedback.

Like we're kind of on the third version of our dashboard, and the second or third, depending on how you count, major version of our API. And so we'd kind of gone through a lot of iteration in response to kind of the evident challenges that users had or the deficiencies the product seemed to possess.

And when we launched, we were basically immediately bottlenecked on sort of being able to serve user demand rather than generating user demand.

And I think sort of directionally, that's kind of the sort of the inversion that happens where sort of, in the early days, you're sort of really trying to figure out, well, okay, kind of conditioned on or given some user, how do I make sure that it does what they need? And they end up a happy retained user in a sufficient fraction of the cases or whatever.

And then kind of at some point it flows for, okay, the sort of, well, I think it's kind of very different. Do you sort of take a hundred users and some fraction of them on board and some smaller fraction remain engaged or whatever. And so kind of a hundred users, the curve sort of asymptotes downwards.

And then do you take a hundred users and kind of, again, a meaningful fraction end up engaged and they actually tell more people about it or they sort of invite people. I don't mean kind of strictly just in a viral sense, but just kind of generally speaking, does that kind of lead to and generate more demand such that things seem to be sort of in some super linear fashion kind of growing.

And I think when you sort of like being kind of less than one is just very different to being more than one. And it sort of seems, again, when we launched, I mean, that didn't generate that many users. I mean, I don't exactly remember, but let's just pretend that sort of 500 businesses signed up on the day we launched.

But sort of immediately those 500 businesses told other businesses and people heard about it and all the rest. So kind of the next day, we had a lot of businesses as well and so forth, such that from the day we launched, the challenge became keeping up with demand rather than tweaking the product to somehow serve the market. When you launched, how many people were you at that point, please?

We were about 10. So I guess before you launched then, like your day-to-day sounds like it was just, like we were talking about earlier, just running around talking with users and fixing issues. Was that literally every single day was like that or what were you doing every day?

Okay, so not literally every single day, but I would say we really tried very hard to understand in sort of 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 sort of providing support when people were integrating Stripe and it was actually a public chat room, which kind of had some downsides because if we'd broken something or if somebody had some kind of embarrassing issues, sort of everyone would see it.

We thought that was kind of good because it would actually kind of put more pressure on us to sort of have the product be good. We had literally every time sort of for the first, I don't know, call it 10 users of Stripe, every time somebody sent an API request to Stripe, like it sent an email to us. So we were like looking at every single API request.

And if we saw users do something weird, we're like, well, why did they do that? Or kind of where were our docs confusing or whatever?

And so I'd get a dinner in the evening or something and I would put, well, again, it seemed like a lot of the time out of maybe 10 emails because Stripe was not handling a lot of API requests back then, but sort of you're literally looking at sort of each individual action.

And actually Stripe, we just kind of celebrated or at least passed, we're not very good at celebrating, but we passed our seventh anniversary just a few days ago on September 29th. And so I was looking at our sort of, we had an hourly stats email that we used to send. And so on the day we launched, we handled sort of 22 payments in the previous hour, which again sort of seemed huge to us back then.

But I was noticing in that email, I'd actually forgotten this, that we had things like in the email, we literally had a list of businesses that had submitted three or five or something API requests, but it's sort of not gone live. They'd not launched their businesses. We literally just had the emails of all these businesses.

The idea was that we would then kind of, we would literally individually reach out to them. It's like, hey, you kind of seem to use Stripe a little bit, but you didn't go live. Like did we screw up or was the product somehow inadequate or whatever? We did things like every time anyone ever hit an error of any sort, that generated like a high priority email to us.

And so we would sort of try to immediately go solve it. And that also kind of generated sort of, I think this pleasant kind of user experience where, I mean, it's frustrating when you hit an error in some service, but we could then often sort of 15 minutes later, reach out to them and say, hey, we saw that you've encountered this problem. It's all fixed now.

And sometimes we did it even in the case where sort of the users made a silly mistake and that they kind of mistyped an API parameter or something. And we just reach out to them and be like, hey, noticed you had a typo in your code, which perhaps some of them was a little bit unsettling, but at least kind of helped us increase the kind of the throughput of product feedback.

But so, I mean, these are all kind of examples, I'd say of the sort of general pattern of sort of really trying to be kind of hyper attentive to all the micro details of sort of what people were doing the product and kind of iterating rapidly in response to it. And generally speaking, I think that sort of pre-product market fit, metrics are actually relatively unhelpful.

I think you sort of, you really want to buy as very strongly towards kind of as much sort of inspection and kind of high throughput qualitative feedback as possible because probably not that many people are using your product, right? And so, if it's 20 users, you can kind of in some sense afford to just like look at everything they're doing and try to understand kind of.

of you know what's working what isn't. Yeah in some sense it's how much do they you can tell subjectively like how much they love your product or how much are they gonna probably be really upset if it just disappears.

Totally and actually on this point we had a thing at the bottom of every web page and we had a little sort of text box and kind of anchored to the bottom of the of the sort of the browser frame and and sort of you know one line high sort of text input and but we had placeholder text in it to sort of try to prime people to tell us things and so it had you know my my favorite part of Stripe is ellipsis and you know people just fill it out I'm gonna hit enter now but we also of course had you know most of the prompts were negative it was you know 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 and and again we would sort of sort of at that stage you have to be kind of masochistic and so again we'd be sort of always waking up to you know all these emails you know telling us all the terrible things about Stripe but that was you know it's a helpful to-do list for the day ahead.

How did you stay happy if like in the early days I mean what makes you think we did so it was I would say it was well happy is such a squishy concept right and because like there are lots of things that we I guess when I look back and look maybe this is the rationalization I taught myself but when I look back and sort of through life of the things that I'm sort of most glad I did I wasn't exactly happy while doing them like often I was very stressed out or you know I had to work really hard or whatever but sort of the things that kind of post hoc brought the most fulfillment and and you know I think that well you know part of it is there's a rich literature here and so I won't kind of dive too deeply into it but I do think kind of happiness is a is a tricky concept to kind of pin down because you know is that kind of happiness in the moment is it sort of the sense that you have a year later looking back and so on and so I think and you know language is squishy and it's not you know completely specifically defined but I think kind of generally speaking kind of a better utility function and kind of gradient to try to climb is that of fulfillment and and so I would say kind of the experience of doing stripe was it was not especially happy because we were sort of you know constantly sort of incredibly aware of all the ways in which the product was severely deficient and you know 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 you know just just over teenagers trying to compete with PayPal which you know many people told us was not an especially kind of promising Avenue to pursue and so not especially happy per se and but it did feel kind of fulfilling and like I enjoyed working with John and the kind of people who subsequently hired and 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's sort of felt like I mean well 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 your experiments don't work or whatever but sort of in perhaps there's some analog there in terms of them it still feels like it still feels in some sense meaningful yeah they're in some sense I mean it did a day like you said you just you're running around with your head cut off but maybe on a weekly or at least monthly basis is just taking a step back and seeing like what progress have I actually made because week to week it's like 1% here 1% here doesn't seem much but from a monthly basis or you know maybe longer than that it it seems like there's movement yeah and I think that's true and I think I don't know like I think it's almost certainly a bad idea to sort of work on a company or to work on anything if if you're like truly unhappy working on it right and so there's kind of cheerleaders and balancing act there and I think I mean a lot of well there's sort of so many different sort of difficult judgment calls to try to make a startup but you know of course part of it is like if something is making you unhappy or if it just doesn't seem like an especially promising Avenue or it's not really working whatever like your time has relatively high opportunity costs like you don't get to start that many startups in your life right and so kind of knowing when to sort of call it quits I think it is actually I mean sort of you know in startup them we really extol and sort of uphold the virtues of sort of you know determination at all costs you know never quit and so on and you know that's clearly not the right answer and that like sometimes you should quit and so so I think what you're getting at is true and right where I think there does need to be some sort of some happiness satisfaction fulfillment there's a good book of that name satisfaction which I recommend kind of week to week month to month if you're on the right trajectory oh man I wish I had known that I could have you know what I remember when I was trying to when I was about to put stripe myself I had these bad memories of trying to implement PayPal and like stacks the documentation and taking like five days to figure it all out and so I sat down I was like it's because you guys are saying oh it took you 10 minutes I was like no way and it probably took me actually five minutes at that point and I was I was super happy I mean that's like but maybe I should have sent you a review yeah I mean they were great especially if the review had a sort of criticism for us but no it was it's definitely helpful to have competitors with not very good products yes okay so you were in the early days you were doing a lot of stuff yourself at some point I guess two part question one is one of the things that you weren't good at and then two at what point did you hire someone to what what I assume is to do those things well I mean I'm not looking at most things right and I see there's a non sort of false modesty or I don't mean to get artificially self deprecating but sort of for almost anything that stripe has to do there are sort of people who are better at that than I am and so I think to some degree sort of the story of say you know product market fit and to say our current stage is kind of implementing the recognition of that and kind of more and more areas that said I think maybe sort of embedded in that question is you know okay well acknowledging that you're probably not the world's expert in in any single thing it's kind of in what order do you sort of replace yourself and for stripe the sort of the the important thing they were sort of most obviously not that great at was kind of partnerships and you know as it working with the various banks that we have to sort of get on board and so on and so kind of we made them in fact Jeff Ralston who is here in the room today I think sort of was some combination of sort of very supportive and perhaps in the back of his mind sort of slightly pitying you know where he saw us kind of trying to get these partnerships with these kind of big banks in place and we really weren't getting anywhere very fast and so he told us that we had to hire this guy Billy Alvarado and I told us just don't ask me questions just hire this guy and at the time everyone everyone at stripe was an engineer and so we just we kind of couldn't quite understand what a non-engineer would do like you're not writing code what else you know is there and and so we were kind of suspicious of this idea and and we sort of we went back to Jeff we met Billy he seemed like a wonderful guy we really liked him but we couldn't quite get past this okay but like what is it actually how does this work out in practice and so Jeff told us that we should hire Billy and if didn't work it over the first few months or whatever that if it didn't work out Jeff would sort of go back and pay his salary so it's gonna zero risk move for us and and and so and and we did not have a whole lot of money at the time so that was those not insignificant so we we hired Billy and that was sort of an immediately trajectory changing event where you know previously when we gone and talked to a bank I mean I don't know if they're literally doing this but certainly felt they're kind of pushing the security button under their desk it's like why are these guys in my office and and then suddenly things started to go kind of much more smoothly and and Billy is still with stripe today and day has been an enormously kind of a pivotal presence and so that was to note you very helpful advice that is interesting Jeff as an inflection point for stripe never knew cool so it sounds like you had hired actually people before Billy I guess the first your very first hire the third person between with you and John it was an engineer I'm assuming like well he actually wasn't an engineer but he joined stripe and he started to become an engineer so like he'd written a little bit of code previously but he joined him which I mean there's a lot of code that had to be written it was a guy I'd known from college he's actually also Irish and we love code to be written and so he was the kind of person who you know would sort of survey the landscape and just do whatever was was you know most important and required at that time I was writing code and so off you went so kind of the transition from preproduct market fit to post product market fit a lot of CEOs when they think back this is like the one point in which they think I could have done that better so how did you how did you grade your success of that transition because a lot of it is you know just taking stuff delegating stuff better and doing other functions of the business so what exactly was your transition like and you know how would you how could I if I was going in your shoes tell that I was doing it well yes I don't think I did it especially well and I think it kind of you know fortunately sort of you know it worked out but I think if if I was doing it all over again I think we could have sort of accelerated ourselves by a year or two if we'd sort of gone about it in a somewhat more disciplined and kind of self-aware fashion I think the I think one of those kind of pernicious sort of mental models you can have here is the kind of you are on some growth curve and it is sort of your job to sustain or you know marginally inflect upwards or is it kind of somehow and you know that one to them is curling the sport where you're kind of you know wiping the ice while the whatever it is the weight proceeds down along it sorry I'm not Canadian but um and but kind of somehow you're kind of making kind of these very small interventions and perturbations on some underlying growth curve and I think that's an easy mental model to have and I think it's kind of you know actively kind of fallacious and mistaken I think kind of a much better mental model to have is you're serving some market and market is I mean for it's relatively finite in size I mean you can always you know change the project and increase the market size but sort of you know you can you can think of it as being finite and then there's sort of the percentage of the market that you're serving and then you know whatever percentage you are not serving is kind of well you just haven't built the sort of go-to-market functions and organization that's kind of capable or at least has yet sort of brought the product to those market segments and the kind of the growth curve or adoption curve is just kind of a function of of that go-to-market apparatus but basically it's it's 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 I what we did not do but what I wish we did is kind of and maybe whatever you know just after we launched we there's a whole bunch of kind of immediate scaling work we had to do but say six months after launch that we should have sort of mapped out the kind of concentric circles of our market like maybe there's kind of you know very early stage startups that were kind of you know our sort of initial initial constituency then there's kind of all technical startups but you know not necessarily very early stage and there's kind of I don't know you you keep going these kind of successive increments until eventually you get to say all companies handling online payments or something right and I'm gone and sort of figured out okay kind of what's the size of this market sort of you know kind of what fraction of them are we currently serving what would it take to serve more and so on and I think it's quite striking you see that kind of when repeat founders go and start companies they almost invariably are willing to kind of build the organization you know post product market fit though it's invariably willing to kind of build the organization ahead of where things are today and which I think is exactly the right thing to do because they're thinking okay I have the right product now 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 and you know of course it's not like 100% under your control but I think it's much more under your control than then things that people tend to think there's also of course a difference here a major difference when you can use or I think about sort of consumer versus kind of b2b use cases where consumer it's a bit more I mean people don't necessarily know exactly what they want you know what's the the market size for like a news reading app or a dating app or something I mean it's it's it kind of it depends a lot on the product like you know maybe way more people should be reading news or something but for for sort of a for some service or a product that sort of serves a discrete logical concrete function that sort of a set of businesses or entities definitively have or don't have I think it's kind of much more sort of much more rational and much more mappable and I partly had this epiphany when I'm Aaron Levy who's the CEO of box John I eventually we started down Palo Alto we moved up to San Francisco I don't well Aaron Levy had Facebook messaged John and we'd never heard of him and we hadn't heard of most people in Silicon Valley and but he'd Facebook messaged us like very early on asking to invest in stripe and I think John didn't know who's this random guy and so we never replied and but then you know we heard of Fox and we heard of Aaron and you know we read his funny tweets and all the rest and so we moved to San Francisco and and we invited him to our housewarming I think was the first time we'd ever met him and sort of you know like we're not very good at partying and so you know by sort of 11 p.

m. or you know midnight or something kind of everyone was going home and but Aaron was still there and and Aaron stayed under like 2 a. m.

I still remember kind of sitting in our front room telling us how much better it was to be building b2b software than consumer software for this reason we're sort of consumer software it's so hard to predict sort of what people want they don't even know themselves what they want you're kind of you're it's such an amorphous space whereas when you're selling software to businesses you know businesses are kind of are mostly rational are mostly the opposite of inscrutable is scrutable I guess and and so you can sort of work backwards in a way that sort of it's just much more comprehensible and so I still have this kind of you know it's like the angel and demon on your shoulder I still have sort of you know 2 a.

m.

Aaron Levy sitting on my shoulder sort of extolling the virtues of building software for entities that I that know what they want you've made the right choice yeah in some sense that there's a lot less variables or in consumer there's a lot more variables to to consider and they're quite unknown I want to take a step back you talked a little bit about you know thinking about thinking ahead about what your team is or what your company structure is going to look like how do you maybe this is too big of a question so maybe we can whittle it down a little bit but how do you think about that like like I'm sitting if I'm starting a startup today I'm close to maybe a product market fit but before that stage like am I thinking about this sort of thing like what should my team look like what should my culture be and stuff like that I think that I'm well okay so pre-product market fit I mean the goal is really is just to get to product market fish and so I actually wouldn't bother thinking too much but all these kind of distribution mechanics questions now you can get a product market fit sort of relatively quickly and so kind of that pre-product market stage might only last six months you know you're not necessarily like stripe where you're gonna in it for various reasons for multiple years and so it may not last very long however until that point I really think you should just be thinking okay how do I get there the main thing that I think companies screw up at the pre-product market fit stage and is sort of speed of iteration I think okay well what determines or you kind of speed of fruitful iteration and that sort of I mean if you're kind of completely or if you're repeatedly rebuilding our product, but sort of not in response to user feedback.

I mean, that's kind of far less likely to be kind of bringing you in a productive direction. But if you have some kind of meaningful, albeit perhaps small, initial set of users, and you're rapidly iterating in response to their feedback and observed behavior and so on, then I think that's a really good spot to be in.

And I think, again, at that juncture of pre-product market phish, you should be doing everything you can to tighten that sort of feedback cycle. There's a fighter pilot who kind of revolutionized airborne combat in the US in the second half of the 20th century, so the Korean War onwards, called Boyd.

And he had this concept of the OODA loop, which was sort of a similar notion of the most previously people thought you wanted just like the fastest aircraft or sort of the most sophisticated weaponry and so on, where he was all about sort of, no, you actually want aircraft and sort of pilots and training that are really oriented around sort of the fastest sort of responsiveness and iteration to the kind of particulars of the situation in a way that kind of subsequently went on to really inform sort of modern aircraft design.

And so I think you want to be like one of these modern fighters, where you're sort of really optimized to respond as quickly as possible to sort of rapidly evolving situations, again, in this kind of pre-product market stage. And so then from a hiring standpoint, I think it should really be about, OK, well, what's going to get you there faster?

And I mean, I think at an early stage, it's most likely, well, sort of just people who will help you kind of build a product. But of course, not too many, because I mean, at some point, like, you might be able to do more, but you might actually be less responsive, because you're a bigger team to manage or something, right?

And so as an empirical matter, it seems that somewhere between kind of 2 and 10, depending on exactly what you're building, is kind of the optimally responsive size. But I think it really is about that sort of time from observed sort of necessity or deficiency or just characteristic of your user's behavior to executed fix or improvement, and whatever it is that kind of minimizes that.

Is there, I mean, you say 2 to 10, which is helpful, but are there observations or evidence in which you have hit the peak? Like, you should not add an extra, like, this extra person is going to be negative value add to the whole operation.

Yeah, I mean, every person, well, startups in general involve all these kind of impossibly difficult sort of judgment calls in this kind of high dimensional possibility space. And so it would be great if you could sort of collapse it down to kind of a fairly simple set of trade-offs. I just don't think you can.

However, I think in principle, the calculation you're sort of trying to run is, OK, each successive person takes time to hire, and so slows us down in that regard, takes time to onboard, slows us down in that regard, kind of takes time to just kind of meld with the culture and learn the stack and all that stuff. That also takes cost and time.

Then involves subsequent ongoing costs of just like coordination and alignment, and sort of you sort of now have the organization is now distributed across more neurons. And so there's that kind of persistent tax. And that's not just necessarily a linear cost, but it can be sort of quadratic or something, kind of given the multi-way communication problem.

So you have all these costs to an additional person. And so the question is, OK, but this person can also help us get more shit done, right? They can write more code or talk to more users or whatever. And so it's kind of, is that fixed benefit to sort of that additional person worth all these other costs?

Again, with I think the ultimate arbiter being, will we be more responsive to what we're learning about our users given the presence of this additional person? And I think whether or not you will be depends on the complexity of the product and the complexity of the market and all that stuff. But I think that's in principle the calculation you want to be running.

I've heard you said, speaking of hiring people, I've heard you said the key qualities that you look for in a future Stripe employee is intellectually honest, cares a great deal, and just loves getting things done, which are great attributes because some people just don't fit in those categories. So it's good to have the separation there.

How do you, when you meet someone, how do you figure out this is the right person? It's very hard. I wish I had a more sort of definitive rubric and kind of particular set of questions. Although if I had a particular set of questions, maybe they'd stop working because kind of people would learn how to game them or something. And so, I mean, well, it's hard to fake just being smart, right?

And so that one's kind of not as hard to discern. And it's oddly hard to fake being intellectually honest and sort of the characteristics of kind of being able to see multiple sides of a debate or an argument.

Like there are so many kind of complicated questions where sort of the only thing that I'm really skeptical of is kind of certainty in either direction, just because the questions are intrinsically sort of involve very contingent trade-offs. It's also, it's not impossible, but it's hard-ish to fake just being nice.

Like something we hear a lot about at Stripe is just sort of people who are pleasant and warm and sort of just make others happier as a result of their presence. And if, well, perhaps if you can fake that perfectly forever, you know, that's fine, right? Maybe then. But yeah, they're all sort of actually, there's no clear rubric for them. And I'm not sure that a clear rubric could even work. Yeah.

So you talk about get people who help move the organization faster, if at all possible. And I think there are two issues usually that start slowing down the organization as you start scaling, just because each person adds just more complexity to the organization. But also, I think one is asymmetric information, just people that are never on the same page.

And I think you've talked a lot about this, I think. And so everyone can Google around for lectures you've given on this on. You've done email transparency, obviously having metrics transparent to the whole organization.

But the second problem to that is if you fix that, there's also this asymmetric interpretation problem, which is everyone's, there's this like black box function that how people interpretate. Even if all the inputs are the same, the outputs are all different. And especially at your scale now, it's nearly impossible to figure out everybody's function.

So when you're thinking about creating your organization and building it out, how do you reduce that, reduce that noise and try to get everyone on the same page? Well, the first thing is I wish we had actually between, say, 5 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 again, it's just not that efficient, right? And it's sort of, it's necessarily not the case. And so kind of like you can sort of perhaps maintain some kind of fiction for more or less time, but sort of ultimately speaking, there is no way of sort of sustaining that.

And I think that's a relatively common mistake, right? Because, you know, you almost invariably come from some kind of, you know, N musketeers or some small N sort of kind of orientation where sort of there's no particular need for sort of formal decision making mechanisms or sort of, you know, subsequent communication of said decisions or whatever, right?

But then you kind of, you hit 15 people and now there is, and kind of, I think companies don't adjust quickly enough to sort of that new necessity, again, very much us included.

And so I actually think we did relatively well on the kind of ambient availability of sort of context and information and so on, but actually kind of in some sense poorly at sort of deliberate explicit communication of decisions, decisions being, I mean, actual kind of tactical decisions or even, you know, bigger decisions like, you know, what are our priorities the next six months or things of that nature?

And so the high order piece of advice and perhaps I'm over extrapolating from our personal experience, but the higher order advice just kind of reflecting back would be to kind of, it's kind of like the pre and post product market fit thing.

It's sort of actually about the size of the organization where it kind of, when you hit a certain size, again, maybe I'm just gonna say 10 people for the sake of simplicity. It's a bit before, it's a bit after.

I think you need to kind of adjust more deliberately to this kind of explicit communication model of sort of being sort of quite firmly non consensus based and sort of, I mean, nobody likes the idea of sort of being hierarchical. That sounds pejorative, but like in some sense hierarchical. Sort of the top down, like it does move things faster.

Maybe some people don't like that, but it does move faster. That's right, that's right.

And there is this kind of delicate balancing act you want to sort of orchestrate where kind of 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 sort of symmetry breaking mechanisms and ways to sort of 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, I mean, you definitely can be excessively hierarchical.

But sort of how do you sort of facilitate enough autonomy and agency, but also not have things devolve into this kind of, I don't know, sort of uniform morass of sort of, I don't know, all these kind of Brownian motion. And I think that's hard and requires all these kind of ongoing sort of tweaks and nudges. And I mean, it's dependent on the personalities involved and all the rest.

And again, 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, Y's and Z's exist, no one's told me yet. If only there was a formula for everything.

So riding on the same theme, as Stripe grows, you strike me as a company that does the opposite of most companies, which as they get bigger, they just slow down and they get less innovative. But for you guys, and it's hard to even keep up, like you're just pumping out new products which seem to be successful to me, like Stripe Atlas, Stripe Press, Stripe Terminals and so forth.

So in the early days, when there's just nine or 10 of you, if someone had a new idea, it's probably really easy to get to you. And then you guys would decide. How has that changed over time to make sure that someone who's like six degrees away from you, that a good idea actually gets to you? And then how is that decision made to actually execute upon it?

Well, it's very nice to hear you say that it feels like we're getting faster as we get bigger because we're constantly sort of self-flagellating over how like fricking slow we are and like paranoid about sort of, I don't know, degenerating into some kind of sort of immobile stupor.

And so to whatever extent we do get things done or appear fast, I think it's largely because we're very paranoid in this dimension. And I think that kind of the default outcome of companies, of course, as they scale is to become sort of more ossified and rigid and sort of closed to new ideas and directions and things that contradict their prevailing orthodoxies and all of that.

As to how we kind of avoid that, I mean, well, there's lots of kind of obvious things, like partly it's sort of, I mean, having leaders who care about the rate of progress and just love seeing things happen quickly and lots of things of that nature.

I think maybe sort of deeper rooted is we try to be a kind of yes and culture in that, I mean, I personally love just ideas and potential things we could do. And I mean, most of them are, I mean, no matter how good the idea is, sort of we should not pursue most ideas, right?

Even if independently it could be a super successful company or something, but like there is a fairly finite number of things we can do. And so sort of you kind of, on the one hand, need to recognize that intellectually and just like not pursue most things, while on the other hand, enjoying the exercise of contemplating, well, what would it look like if we did it, right?

And so one thing we do every year, for example, is we have this kind of crazy ideas process, we call it, where we literally send a document to the whole company, a hack pod document that's open to everyone and people can sort of add ideas to it that they think are probably a bad idea, but if they worked, might be a great idea.

And it's very important that they have to be probably a bad idea, because if they're like probably a good idea, then I mean, it's not that risky and I mean, kind of by definition, we should probably do it. And so, you know, whatever, maybe we should just do it.

And so people like really self-censor a lot in most organizations, because they don't want to look stupid and they don't want to be sort of associated with just having all these like wacky bad ideas and so on. And so we try to be fairly firm that if you add ideas to this, it has to be probably a bad idea.

And actually a lot of cool things that we've subsequently gone on and done first came from that process, Stripe Atlas, you know, being one of them. And also we sort of helped Stellar get off the ground this sort of cryptocurrency back a few years ago and sort of that also sort of came from this process. And so that's one of the mechanisms by which we try to have a kind of yes and culture.

And I really think there aren't that many, as just as an empirical matter, there aren't that many large organizations that I think sort of really do this successfully.

But I think that sort of the most successful larger organizations somehow do succeed in sort of this iterative, repeated process of kind of augmentation, you know, Amazon and Google being kind of the most prominent examples where, you know, obviously even Google launched, there was no Gmail or YouTube or Android or Google Maps or whatever.

And, you know, Amazon sort of is kind of an even more conspicuous example in some sense of this kind of repeated attach of successful ancillary businesses. And so I think kind of, yeah, there's a very natural temptation as you grow to I think become increasingly close to this. I think it's very important to avoid.

Cool, so I have a couple more questions and then maybe we'll have time to take questions from the audience. One is, looking back, is there something, did you have a strong opinion of, you know, how startups should be run as a CEO that have just completely reversed because you're now the CEO? That's a good question.

Another way to potentially put it is like, what are things that you did where you're like, I know for sure this should have been done and it just turned out to be a mistake? Well, I already mentioned the sort of the consensus orientation.

One that we're going through right now, which is a quite sort of significant divergence is, you know, we were sort of fairly centralized up until sort of relatively recently. I mean, we had some remote employees from pretty early stage, but by and large, Stripe was kind of concentrated in San Francisco.

Last week, we announced our fourth global hub, fourth global hub, and basically what we've decided to do is we're going to have kind of major sort of product and engineering sort of efforts and teams and functions and all the rest in San Francisco, also in Seattle, also in Dublin, and also in Singapore.

And sort of these non-San Francisco locations are not going to be sort of, I don't know, operations offices or satellite offices or, you know, places where we do kind of some localization and local market adaptation. We want to have kind of completely de novo, new products that sort of become super successful. out of these offices.

And that's not the sort of standard, obviously kind of Silicon Valley pattern where sort of Apple and Amazon and Facebook and Google and all these companies tend to be sort of highly concentrated in these sort of very, I don't know, sort of monolithic corporate headquarters.

And our thesis is that, is kind of several folds, you know, partly that kind of the availability of talent is becoming sort of far more geographically dispersed, partly that sort of, you know, the Bay Area is becoming an increasingly untenably expensive location to locate.

And partly that sort of, we really want Stripe to be global infrastructure that works kind of just as well in sort of Asian markets or in Latin American markets or whatever, as it does for businesses in the US and kind of the era of the internet being a sort of predominantly North American or North American and Western European or whatever, the days of being kind of such a phenomenon are over.

And so I think that's sort of a fairly substantial break with kind of, you know, descriptive best practice of the past. I mean, you know, we obviously think it'll work and we wouldn't do it if we didn't, but it is also kind of on some level risky, like we don't have good, you know, prior examples to point to.

And, you know, I mean, there are some great companies in Singapore like Grab and Carousel, but there aren't really any examples yet of sort of American companies establishing kind of major private engineering hubs there. You know, we're pretty optimistic it can be done, but, you know, kind of if it works, you know, we'll be the first or one of the first. Cool. Last question.

So in 100 years from now, what is Stripe gonna be? What do you imagine it to be? Well, we're only seven years old, so that's a difficult question to answer.

I mean, we're trying to build this kind of, this economic infrastructure for the internet and this sort of platform for globalization and kind of sort of technological progress in the sense that like it ought to be just as easy to start a company in sort of, you know, Nigeria as it is in New York.

And it should be just as easy for somebody in Brazil to buy something sort of from any of these companies as it is for, again, somebody in the Western world. And it just seems so crazy to me that sort of that hasn't happened yet. Like it sort of feels that Stripe should have happened 10 or 20 years before it did.

And just kind of, I don't so much think that we're sort of pursuing this kind of unprecedented kind of path breaking or sort of, you know, inconceivable idea so much as kind of correcting a deficiency in sort of a rip in the fabric of internet infrastructure. And so anyway, I think we still have, you know, at least five years to go in sort of correcting this inadequacy.

You know, so what happens after that, I'm not sure. In some sense, in the future, all transactions should be digital and they could very well just be all going through Stripe. I mean, right now like in the US, someone was telling me like 80% of all Americans have done some transaction through Stripe, right? Yeah, that's right.

So in the last 12 months, more than 80% of American adults have bought something from a Stripe business, at least one thing from a Stripe business, which is cool. And you know, it's not just the case in the US. Like in Singapore, where I was last week, you know, that figure is about 70%, right? But I guess we don't think about it.

Well, I think about it more in terms of the things that are possible or get started, as in it's kind of, we think a lot about the rate of sort of new firm creation, what companies are getting started, how successful are those companies, which markets can they serve and so on.

And, you know, every now and again, we look back and we look at sort of those kinds of market coverage stats, but I guess that's not really what sort of, what motivates us. It's more that sort of, are these businesses that should exist and or should be able to kind of offer their products and services, you know, in these places where they currently can't.

And that's, I think, I mean, that's the kind of thinking that we use to kind of inform the product and that sort of is kind of the core locomotion day-to-day. And then maybe the outcome of that is that all these people get to benefit from it. All right, thank you so much, Patrick. This was great. Thank you. Thank you. Thank you. Thank you.