Running Your Company by Patrick Collison

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. Why should we started working on it full-time in 2010? But it actually 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. And we'd been working on it for almost two years at that point.

And every time we saw PG or really anyone else from YC, all they would ask us is why we did not launch. Some things don't change. That's interesting; to two years until you have to! It was, I think, one year and 11 months from sort of 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. And because it sort of took us so long to build a publicly launched, we tried to be kind of Airy disciplined about sort of gradually expanding the number of users every month.

So even though we weren't publicly available, we got our first user, like first production user, just kind of three months in. And then have every month we tried to add at least kind of a handful of users. And so by the time we publicly launched, we did have about a hundred users, which I mean back then to us seemed like a big deal. That seemed very, 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. I remember back then people would always talk about the Cullison brothers running around, going to people's offices and like installing their API into the web apps. And you know, in true "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, but PG now calls it the Cullison installation. And this is actually something we give and we tell founders to go do this, do the Cullison installation, because obviously, you know in hindsight it seems so obvious to do. Well, it sort of served two purposes. One is, to your point, I mean, it's a really good way to kind of get sort of user research and to get kind of UX feedback and so on.

And I mean if you've done this, I'm sure you had the experience where you design what you are absolutely certain is the most streamlined, user-friendly, straightforward, frictionless way to, you know, do whatever it is the product does. And then you kind of, you present it and kind of put it in front of a user and you just kind of ask them to do whatever it is. And you know, they find it completely impenetrable, and like they're clicking all the wrong links and they can't find the next button even though the next button is there blinking and green and stuff.

And so it's invariably so incredibly painful at the sort of nothing, so sobering, as watching somebody use kind of that the first version of, you know, some new product. But the other reason for us was, you know, we would suggest to somebody they use Stripe or they switch to Stripe, whatever, and you know invariably the responses, "Oh yeah, sure, that sounds awesome." But you know, it can be postponed and locals phone it again, and just like there's never a moment where it's like, "Okay, this is the evening where I'm going to switch to Stripe." And so us going and sort of accosting them in person sort of helped, you know, create a "why now" moment. It's like, "What, we're here at your house? Did you just show up or how did you...?"

I don't think we ever actually showed up, although perhaps we should have. But, you know, we tried to be kind of at least semi-invited. So Stripe now, today, I mean you've come a long way since back then. I mean, it's not even, it's really been a decade, not even.

But I mean today 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 dollars—billion. Anyway, let's keep going on. I'm not gonna stop. They're all there, otherwise people 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 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, you know when you start off, you know one from the very beginning a lot of friends get together and they come for the idea and they're super excited, and they start working on it, and then at some point they need to decide, "We need a CEO for this company." And some people, you know, aren't meant to be CEOs but for you and John, you know, I've met both of you. You're very smart, ambitious people with great, you know, qualities that end attributes that correlate to becoming great leaders. How did you and John decide you would be the CEO?

“Well, I think Stripe is unusual for, you know, John and my RFC brothers. And we've known each other for a long time. And, you know, because of the relationship, we real sort of place a lot of trust in each other. And we really do run the company together. And there's no major decision that sort of Stripe has made that sort of that we've not both been a part of. And, you know, it's not always the case that, you know, despite being the CEO that kind of I'm the person who like in the case of disagreement, it's not all, it's not all the case that I prevail. Instead of our kind of dispute resolution framework, it's kind of much more around which of us carries more than kind of which most holds this title. Earth. And I mean John's title as president. And so it was kind of some both are significant roles. And so, yeah in that regard I think we're kind of an anomaly. He said of the fact that I became CEO was honestly semi-random, and I would say, yeah, I think because we're brothers being able to kind of get to this unusual situation where we really do run it together.”

Is there a certain, would you, sorry, may not be a helpful answer because perhaps you're trying to encourage all these companies. It's like, you know, "What do you got, guys? Has got to be the CEO." But do you think there's like a rubric for this of, you know, here are five questions you should answer. Maybe then you decide...

That's a good question. Um-hmm. You know, yeah, I'm guessing it's quite okay. Well, I wasn't, one thing which is I think it is important just have an efficient mechanism for reaching a decision. And it can't be sort of, you know, simply orange around consensus. Right? If there's sort of three co-founders and sort of none of you sort of quite want to or, you know, nobody's a clear CEO and you don't have some kind of efficient mechanism for that, of having decisions get made, I think that is a recipe for failure. And even, I don't know, doing some kind of, you know, sort of quasi-democratic voting is probably not a great idea either.

And so for myself and John, we kind of both have areas we kind of respected, we specialize in. And so that doesn't mean we kind of have absolute ultimate authority there, but so do we be kind of biased in that direction. So he spends more time, for example, working externally with users. I spend more of my time working to have internally on, you know, 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 second, we have this kind of additional aspect where, you know, in case of a major decision, and we should respectively disagree, then we really do sort of try to make it based on sort of which of us is kind of is just more passionate about it. And because that will correlate with the outcome. One of us really wants to do something or think that, you know, X or Y is the right thing to do simply sort of wanting 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, I also see like 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, you know, something that working on Lucky about that I think is very well exactly to your point, I think he's 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, you know, for us I think that was, you know, kind of easier to get to because you know we've 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 that this kind of but the notion of disagreeing strongly is not sort of a scary phenomena and that 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?

“Via one more brother. One more sibling, yes. Okay, three of us in total. Would you guys, would he join the, or is it just you and John are the special match there?”

Well, the Tommy, my youngest sibling, he's sort of quite a bit younger than myself and John. And so, you know, John is almost approximately two years younger than I am. And you know 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 wasn't quite practical at the time. Yes, finished high school. And now I think, you know, if you asked him, he probably said he’d never throw his lot in with, you know, miscreants like us.

Yeah, cool. So in terms of the role, is to you often people say there’s a threshold in time in which, and it's related to product market fit, where that 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 or their metrics to it? Number of employees you were at when you reached it, 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 and 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 see for Stripe and actually around the time we launched publicly, I think is basically when we had it.

And that we when we launched publicly in September 2011, you know we had 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, and 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, you know, evident challenges that these 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 inversion that happens. First it is, you know in the early days you should have really trying to figure out well, okay kind of, you know, conditioned on or given some user how do I make sure that it's if it does what they need and you know they end up a happy retained user in, you know, a sufficient fraction of cases or whatever.

And then kind of at some point it flows for, okay the sort of, well you know, I think it's kind of very different. Do you sort of take, you know a hundred users and you know some fraction of them onboard and some smaller fraction you know remain engaged or whatever? And so kind of 100 users, the curve sort of a sort of asymptotes downwards and then you take 100 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 even have strictly just in a viral sense, but it's kind of generally speaking just that kind of lead to and generate more demand such a thing soon 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 think I could remember but let's just pretend that sort of 500 businesses signed up on the day we launched.

But 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 at that point?

“We're about 10.”

So I guess before you launch then, but your day to day sounds like it was just like, we were talking about earlier just running around talking with users and fixing issues. What was that? Literally every single day was like that? Or what were you doing?

Okay, so not literally every single day, but I would say, and we really tried very hard to understand into the very granular detail what exactly it was that people were doing, you know, where they were tripping up and so on. It's 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, you know, if we'd broken something or if somebody had some kind of embarrassing issue, sort of everyone would see it. But we thought that was kind of good because it would actually can put more pressure on us to sort of have the product to be good. And we had literally every time, for the first I don’t know, call it 10 years 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, you know, if we saw users do something weird, why did they do that? Right? Or kind of where were our docs confusing or whatever? And say, you know, I get a dinner in the evening or something. And I’ve, but you know, well again it seems like a lot that I might have you know maybe 10 email lists 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, and we just kind of celebrated or at least passed, I'm very good at celebrating, but we passed our seventh anniversary just, you know, 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 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 gonna if they did not launch their business. Wheeler just had the emails of all these businesses. The idea was that we would then kind of, we literally individually reach out to them. It's like, "Hey, you can have seemed you strive a little bit, but you know you didn't, I 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 it sort of tried to immediately go salvage. And that also kind of generated sort of I think this pleasant kind of user experience for, I mean, you know 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 the tubes have been counted, the problem, it’s all fixed now."

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

But so I mean these are all kind of examples I would 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 with 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.

And I think you should have, you really want to bias 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, you know, 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, you know, what's working what isn't, in some sense it's how much do they, you can tell actively like how much they love your product, 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 webpage, we had a little sort of text box and kind of anchored to the bottom of the sort of thumb of the browser frame and, sort of a, you know, kind of one line high sort of text input and but we had placeholder text in it I had to sort of try to prying people to tell us things and so it had, you know, "My favorite part of Stripe is...," 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 problems were negative. It was, you know, like, "The worst thing about Stripe is..." or "The worst thing that this page is..." or "I really hate the way Stripe does..." or whatever.

And again, we would 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 it was, you know, if I helpful to-do list for the day ahead.

How did you stay happy? If look in the early days I mean for every story it complains, what makes you think…?

We did so it was... What happy is such a squishy concept, right? And because like there are lots of things that we are... 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, there are 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 to the things that kind of post hoc brought the most fulfillment.

And, you know, I think that well, you know, part of it, there's a rich literature here and so I won't kind of die too deeply into it but I do think kind of happiness 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 reddit line is that of fulfillment.

And so I would take an 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 seemed 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, but it did feel kind of fulfilling. And like I enjoyed working with John and the kind of people we separately hired. And it was really fun working with the kinds of kind of customers we were serving and they're 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 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 appreciating all these kind of haven’t used to sort of try to better understand - and I'm guessing day to day it's sort of not especially happy because most of your experiments don't work or whatever, but sort of in for perhaps there's some analogue there in terms of them it still feels like it was in some sense meaningful.

Yeah, in some sense, I mean, it did add a, like you said, you're running around with your head cut off, but maybe on a weekly, or at least monthly basis, just taking a step back and seeing like what progress have I actually made because week to week, it's like one percent here, one percent here, it doesn't seem much. But from a monthly basis or, you know, maybe longer than that, it seems like there's movement.

Yeah, no, I think that's true and I think III don't know like I think it's almost took me a bad idea to sort of work on a company or to work on anything if you're like truly unhappy working, right? And so there's kind of charities and balancing act there and I think, I mean a lot of well they're sort of so many differences of them difficult judgment calls to try to make in a start-up 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 is actually, I mean sort of you know in start-up them we really extol and serve 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's like sometimes you should quit. And so, um, so I think how much of getting it is true and right for I think that does need to be some sort of some happiness satisfaction fulfillment.

This 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'd 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 ten minutes!" It's like "No way!" And it probably took me actually five minutes at that point. And I was super happy, I mean that's like... but maybe I should have sent you a review.

Yeah, especially if the review noted sort of criticism for us but no, 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, too, two-part question. One is, one of the things that you weren't good at and then too, at what point did you hire someone to what I assume is to do those things?

Well, I mean I'm not that good at most things, right? And I say there's a non-sort of false modesty or I don't mean artificially self-deprecating but said for almost anything that Stripe has to do, those are the people who were 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, you know, say our current stage is kind of implementing the recognition of that in 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 playing out the world's expert in any single thing, it's kind of in what order do you sort of replace yourself? And for Stripe the sort of the important thing they were sort of most obviously not that great at was kind of partnerships and, you know, working with the various banks that we had to sort of get on board and so on.

And so kind of we made them, in fact, Geoff Ralston, who is here in the room today, I think sort of was, you know, some combination of sort of very supportive and perhaps in the back of his mind 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 sort of getting and they were 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 at Stripe was an engineer, and so we just, we couldn't quite understand what a non-engineer would do, like you're not earning code, what is, you know, is there? And so we were kind of suspicious of this idea.

And we sort of we went back to Jeff, we met Billy, he seems like a wonderful guy, we really liked him, but we couldn't quite get past this, "Okay, but like what does it actually, how does this work out in practice?" And so Jeff told us that we should hire Billy and it didn't work over the first few months or whatever, that if it didn't work out, Jeff would go back and pay his salary. So it's kind of a zero risk move for us.

And so, and we didn't have a whole lot of money at the time so that was not insignificant. So we heard Billy and that was sort of an immediately trajectory changing event for us. No previous leaving me gone and talked to a bank—I mean, I know they're literally doing this—but it certainly felt they were kind of pushing the security button under their desk. It's like, "What are these guys in my office?" And then suddenly things start to go kind of much more smoothly.

And Billy is still with Stripe today and day has been an enormously kind of pivotal presence. And so that was turned out to be very helpful advice.

That is interesting just as an inflection point for Stripe. Never knew. Cool. So it sounds like you had hired actually people before Billy, I guess first your very first hire, the third person between with you and John, it was an engineer I'm assuming?

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 a lot of codes, so I had to written. It was a guy I'd known from college; he's actually also Irish, and yeah we love code to be written. And so he was the kind of person who, you know, would sort of survey that landscape and just do whatever it was, you know, most important and required.

And at that time, I was writing code. And so he went, so kind of the transition from pre-product market fit to post-product market fit I want to see use when they think back—this is like the one point in which they think I could have done that better. So how do you create 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 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 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 kind of somehow and, you know, that much of them is curling the sport where you're kind of, you know, wiping the ice while the overt is the weight a precedes down along it; sorry I'm not Canadian, but um.

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 I have a much better mental model to have is you're serving some market and that market is... I mean for its relatively finite in size.

I mean you can always, you know, change the product and increase the market size but sort of, you know, 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 is 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 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 I, what we did not do but what I wish we did is kind of maybe whatever, you know, just after we launch me, there’s a whole bunch of kind of immediate scaling work we have 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, there were kind of a, you know, our sort of initial constituency. Then there's kind of all technical startups but not necessarily very early-stage and it's kind of, I don't know, you keep going these kind of successive increments until eventually got to say all companies handling online payments or something, right?

And I'm gonna sort of figure it out, okay kind of what's the size of this market sort of, you know, kind of what fraction of 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-prime market it.

So it's invariably willing to kind of build the organization ahead of where things are today, which I think is exactly the right thing to do because they're thinking, okay, I have the right product now that's gonna 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 don't 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 market size for like a news reading app or a dating app or something? I mean it's a kind of it depends a lot on the product. Like you know maybe when more people should be reading news or something, but for sort of a, for some service or a product that sort of serves a discrete logical concrete function that sort of set of businesses or entities to finish early have or don't have, I think it’s kind of much more rational and much more mappable.

And I partly had this epiphany Vienna Aaron Levie, who's the CEO of Box. John and I eventually we started in Palo Alto, we moved up to San Francisco. I don't well Aaron Levie had Facebook message on and we've never heard of him and 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 this is a 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've read his funny tweets and all the rest and we moved to San Francisco 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 a sort of 11:00 p.m. or, you know, midnight or something, kind of everyone was going home and but Aaron was still there and Aaron stayed on like 2:00 a.m.

I still remember kind of sitting in our front room telling us how much better at would-be building B2B software than consumer software for this reason. Our sort of consumer for 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 in 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 scrutiny, I guess, and you can sort of work backwards in a way that sort of, it's just much more comprehensible.

And so um, 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, - am Aaron Levie sitting on my shoulders of extolling the virtues of building software for entities that know what they want.

You've made the right choice, yeah. In some senses there's a lot less variables or in consumer there's a lot more variables to consider and they're quite unknown.

I want to take a step back, and 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 I mean 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 am close to maybe a product market fit, but before that stage like am I thinking about this sort of thing?

I watch my team look like what should my culture be and stuff like that, I think that then—well, okay, so pre-prime market fit. I mean the goal is really is just to gas to product market fish and so I actually wouldn't bother thinking too much about all these kind of distribution mechanics questions now. You can get probably a good fit sort of relatively quickly.

And so kind of that pre-primary at this stage might only last six months; you know you're not necessarily like Stripe, or you're gonna in it for various reasons for, for first of multiple years, right? And so it may not last very long. However, until that point, I really think you should just be think about, okay how do I get there? The main thing that I think companies screw up at that pre-product market at this 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 national response user feedback, I mean that's, that's kind of far less likely to be kind of bringing you in sort of a productive direction. But if you have some kind of meaning, albeit perhaps small initial set of users and your rapidly iterating in response to sort of their feedback and sort of observed behavior and so on, then I think that's like a really good spot to be in.

And I think again at that juncture a pre-prod market fit stage, it is kind of this you should be sort of doing everything you can to tighten that sort of feedback cycle. And there's a fighter pilot who kind of revolutionized airborne combat in the US and said of the second half the 20th century—so Korean War onwards—and called Boyd. And he had this concept of the OODA loop, which was sort of a sort of a similar notion.

I was the most improve you see people thought you want to just like the fastest aircraft or said that, you know, most sophisticated weaponry and so on where he was all about sort of, no you actually want an aircraft that instead of pilots and training that are really oriented around sort of the fastest sort of responsiveness in iteration to the cut 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 sort of these modern fighters every year sort of really optimized to respond as quickly as possible to sort of rapidly evolving situations, again, and it's kind of pre-primed market at stage. And so then from a hiring standpoint, I think it, I think it should really be about, okay well what's gonna sort of 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 help you kind of build the product, but of course not too many because I mean at some point like not 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, you know, two and ten depending on exactly what you're building is kind of the optimally responsive size.

But I think it really is about that sort of him time from observed sort of necessity or deficiency or just you know characteristic of your users’ behavior to executed fix or improvement. And whatever it is that kind eyes is that is there. I mean you say two to ten, which is helpful, but is there are there observations or evidence in which you have hit the peak like you should not add an X, like this extra person is going to be negative value add to the whole operation?

Yeah, I mean every person, every person—well startups in general involve all these kind of impossibly difficult judgment calls in this kind of, you know, 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 that is, I don't think you can. However, I think in principle the calculations that are trying to run is, "Okay, and each successive person takes time to hire and so slows us down in that regard, takes time to unmoor, slows that in that regard."

And it takes time to understand, meld with the sort of culture and learn the stack on the stuff. That also takes constant time. Then involves subsequent ongoing cost of just like coordination and alignment and sort of, you know, you should now have, you know, the organizations that are distributed across more neurons. And, and so there's that kind of persistent tax and that's not just necessarily a linear cost but it, you know, it can be sort of, you know, quadratic or something kind of given, you know, the multi-way communication problem.

So you have all these costs to an additional person, so the question is, "Okay, but this person can also help us with like 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?

And again, 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, you know, whether or not you will be dependent, the complexity of the product and the complexity of the market and you know all that stuff, but, but I think that's in principle the calculation you might be running.

I've heard you said and speaking of hiring people, I've heard you said, you know, 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 that separation there.

How do you, when you meet someone, how do you figure out this is the right person?

It’s very hard. And I wish I had a more sort of a sort of definitive rubric and kind of particular set of questions although if I had a particular set of questions maybe, you know, they'd stop working because kind of would learn how to game them or something. And I mean 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 so the characters who kind of being able to see multiple sides of a debate or an argument, like there are so many kind of complicated questions for, so the only thing that I'm really skeptical of is kind of certainty in either direction just because, you know, 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. And like something, something we care a lot about it's Stripe is just sort of people who are pleasant and warm and sort of just, you know, make it others happier as a result of their presence. And you know, if, well, you know, perhaps if you can fake that perfectly forever, you know, that's fine, right? But yeah, there all and sort of actually there's no clear rubric for them and I'm not sure that the peer rubric could even work.

Yeah, so you talk about like 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 'cause each person adds just more complexity than organization but also I think one is asymmetric information, just people don't want that guard, never on the same page.

And I think you've talked a lot about this. I think, and there so everyone can Google around for lectures you've given on this, on you've done email transparency. You know, obviously, you know, 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 just like black box function that how people interpret eight.

Even if all the inputs are the same, the outputs are all different. And it's official at your skill now, it's nearly impossible to figure out everybody's function. So when you're thinking about creating your organization and building it out like how do you reduce that noise and try to get everyone on the same page?

Yeah, well, the first thing is I wish we had actually between say five and fifty people, and I think we were 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 I've seen a, it's just not that efficient, right? And it's sort of, it's necessarily not the case.

And so kind of you like you can sort of perhaps maintain some kind of fiction for, you know, more or less time, but sort of ultimately speaking the third there is no way of sort of sustaining that. And I think that's a relatively common mistake, right? And because you know you almost invariably come from so some kind of, you know, n Musketeers for so small and sort of kind of orientation whereas it is 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 can hit fifteen 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 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 higher order piece of advice and perhaps I'm over extrapolating from our personal experience but hydra advice just kind of reflecting back would be to kind of it's kind of like the pre and post-pop probably market fit thing.

It’s sort of, it's actually about the size of the organization. When you hit a certain size, again maybe I'm just gonna say ten people for the sake of simplicity a bit before it's a bit after, I think you to kind of adjust more more deliberately to this kind of explicitly eunuch ation model of sort of of being sort of quite quite firmly non-consensus based.

And sort of, I mean nobody 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.

Yes, it does, that's right, and there is this kind of delicate balancing act you want to sort of orchestrate. We're 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 have shots get called.

But on the other side, you really do want people to have this kind of strong ownership mentality and and real sense that sort of they they can cause think things to change or identify problems or sort of inject new ideas, even in unrelated areas. And so it's this delicate act where, I mean you definitely can be excessively hierarchical but sort of how do you sort of facilitate enough autonomy and agency them but also not have things devolve into this kind of, I don't know, sort of a uniform morass of sort of all these kind of of a Brownian motion?

And I think that's hard and requires all these kind of, you know, ongoing sort of tweaks and nudges. And I mean it’s dependent on the personalities involved and all the rest. And again I, you know, I really wish there was kind of the sort of wrote simple, "I'll just do XX and Z, and you'll be good."

But sort of if such XX Z's exist, you know, no one's told me yet.

If only there was a formula for everything. So riding on the same theme, you know, as Stripe grows you strike me as a company that does the opposite of most companies, which was 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 Terminal, so and so forth.

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

Well I'm, it's very nice to you say that I feel that we're getting faster as we get bigger because you know we're constantly sort of self-flagellating over how like freaking slow we are and like paranoid about sort of, I don't know, degenerating into some kind of, you know, 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 how we kind of avoid that.

And 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 and just love seeing things happen quickly and lots of things of that nature. And I think maybe sort of deeper-rooted as 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 or 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 comfort 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 it looked like if we did it right.

And so, you know one thing we do every year for example is we have this kind crazy ideas process we call, where we literally sent a document to the whole company a hackpad document that 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 ply do it. And so we know whatever it may be just do it and so people like really self-censor a lot in most organizations because they don't look stupid and they don't 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, it has to be probably a bad idea. And actually a lot of cool things we've subsequently got on and done the first came from the process, Stripe Atlas, you know, being one of them. And also we helped stellar it could off the ground this sort of cryptocurrency back a few years ago instead 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 and there aren't that many large organizations that I think sort of really do this successfully. But I think that sort of the the most successful of larger organizations somehow do succeed in sort of this iterative repeated process of kind of augmentation, you know Amazon and Google being have the most prominent examples for, 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 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 is 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 are 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 to see you?

It's a good question and 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 they just turned out to be a mistake?

Well I already mentioned the set of consensus orientation when they were going through right now which is a quite sort of significant divergence is a, you know we were sort of fairly centralized and up until sort of relative recently. I mean we had some remote employees from pretty early stage but so by and large Stripe was kind of concentrated in San Francisco.

A.m. Last week we announced our fourth global hub and basically 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, and sort of these nonsensical locations. They're not gonna be sort of, I know operations offices or satellite offices or, you know places where we do have some localization and local market adaptation, we want to have kind of completely de novo new products that sort of become super successful started out of these offices.

And that's not the sort of standard obviously kind of Silicon Valley pattern and we're 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, so monolithic corporate headquarters. And our thesis is that it's 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 going an increasingly untenable expensive location to locate and partly that sort of we really want Stripe to be global infrastructure that work kind of just as well in instead of you know Asian markets or in Latin American markets or whatever as it does for businesses in the US. And have the era of the internet being asleep predominantly North American or North America 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 them 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 like Grab and Carousel but 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, 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 a hundred 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. We're trying to build this kind of this economic infrastructure for the International, sort of platform for globalization and kind of technological progress in the sense that like it ought to be just as easy to start a company in, 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 so from any of these companies as it is for for again somebody in 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 ten or twenty 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. I am sort of a inconceivable idea so much as kind of correcting a deficiency and instead of as a rip in the fabric of Internet infrastructure.

And so anyway, I think we still have you know at least five years to go instead of sort of correcting this inadequacy.

Yeah, 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, it's just the all going through Stripe.

I mean right now, like in the US someone's telling me like 80% of all Americans have done some transaction Thursday, right?

Yeah, that's right. So in the last 12 months, more than 80 percent 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 I was last week, you know, that that figure is about 70 percent, 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 and it's kind of we think a lot about the rate of sort of new firm creation, what companies are getting started, how successful of 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, but I guess that's not really about sort of them what motivates us is it's more than sort of are these businesses that should exist and or should be able to kind of offer the present 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's it is kind of the the core on locomotion day-to-day. And then maybe the outcome of that is, is that all these people get to benefit from it. All right, thank you so much, Patrick. This is great.

Thank you [Applause].