Show Notes:
This week we’re excited to share our conversation with Patrick McKenzie. Patrick is many things, but at the moment is primarily a senior individual contributor working on Content and Community at Stripe. Prior to Stripe, Patrick was a successful entrepreneur who started four different SAAS businesses. His blog is a catalogue of knowledge (with 565 essays written) for anyone interested in technology, entrepreneurship, engineering or business. Find it here.
To many (including yours truly), Patrick is an internet legend; he has started four software companies, is a prominent writer, software engineer, marketer and researcher who’s interest spans many fields. I encourage you all to follow Patrick on Twitter at @patio11 if you’re not already - he is one of the few people we can honestly say can make you a more successful entrepreneur just by reading their Twitter feed. Broadly, Patrick and the Stripe team are working on increasing the GDP of the internet. The crazy thing is, they’re succeeding in a big way.
Patrick’s current role at Stripe is, as he says, “squishy” which means he works on many different things, including helping write the Stripe Atlas guides, contributing to marketing efforts, writing code, hiring and much more. Stripe recently announced that they were hiring remotely on a wider scale, so we were able to dig into that decision process and understand more of the internal workings of the remote culture at Stripe.
There’s a lot to unpack here, I could talk to Patrick for an additional hour if it time would allow. Please enjoy our conversation!
Stripe is hiring aggressively for remote roles. If you’re interested in working for Stripe (which you should be), please visit stripe.com/jobs.
If you’re not already using Stripe for your online business, then I don’t know what you’re doing, but you should switch to them now by going to stripe.com and signing up for an account.
Some people don’t know the extent of Stripe’s value to online businesses. If you’re an internet entrepreneur, you can benefit from the Stripe Atlas Guides, the Stripe Sigma business analytics and many other products they offer. Find them all at stripe.com.
Thanks for listening!
Transcript:
Matt H: 00:00:06 Hello everyone, my name is Matt Hollingsworth, and welcome to another episode of The Remote Show, where we discuss everything to do with remote work, with the people who know it best. Thanks so much for listening.
Matt H: 00:00:15 The Remote Show is brought to you by We Work Remotely, the largest community of remote workers in the world. With over 220,000 unit uses per month, We Work Remotely is the most effective way to hire.
Matt H: 00:00:25 My guest on today's show is Patrick McKenzie or @patio11 on the internet. Patrick is a software engineer by trade. Has founded four different small software companies, and now works for Stripe. You all know about Stripe already, but the small version of it is that Stripe's mission is to increase the GDP of the internet. Patrick's role in Stripe is to increase the number of successful software companies on it. On a day to day basis, Patrick writes code, requirements documents, strategy memos, the Stripe Atlas Guides, which if you haven't tried that out, is absolutely awesome. And he also advises Stripe employees, partners, and users. If you're not already following him, you should do so. He's patio11 on Twitter and all other internet platforms. If you're not already using Stripe, I don't know what you're doing, but you should be using Stripe to process payments and build your business online.
Matt H: 00:01:13 Patrick, thanks so much for coming on the podcast, we really appreciate it.
Patrick M: 00:01:16 Thanks so much for having me.
Matt H: 00:01:17 Yeah, super excited to talk to you. Stripe has been one of those companies we've had our eye on, you and what you've been up to. And it's been lovely to watch your progress but yeah, I'm super excited about this and I hope you are, too.
Patrick M: 00:01:28 Yeah, always love talking to smart folks about interesting subjects.
Matt H: 00:01:32 For sure, for sure. So, where I like to start these conversations now, and I found it to be pretty interesting as a jumping off point, is what is it that you've been most proud of, that you've done over the last 12 months?
Patrick M: 00:01:44 Interesting. I've got a two part answer here, so I am a husband and father. I have a four year old daughter, and a two year old son, and so I think that strictly speaking, accurate answer is tempted to work the father thing for what it is worth, and knock on wood, hopefully that is going recently decently in the last 12 months. The more professionally relevant answer is, stretching my wings a little bit at Stripe, between projects that are more similar to the kinds that I've been doing over the last several years, and projects that are different in character.
Patrick M: 00:02:10 One of the things that we've been moving into quite actively is hiring remote engineers. Stripe had not historically been a company that had done that in a considered and scaled fashion, and then we looked at the data early this year and came to the conclusion that, oh, actually that small but mighty team of remote engineers that we had opportunistically hired over the years was extremely outperforming, relative to our various benchmarks for engineer performance. We said, "Wow, if that is working so well, let's have more of that."
Patrick M: 00:02:36 And so, we came to a kind of ambition plan to hire over a hundred remote engineers this year. And that's been an all hands on deck effort for a number of people in the company, myself included. And one of the things that I have been doing the last couple months is setting up a program to do what we call remote coffees, to basically give people the opportunity to help on a Zoom call with some Stripe engineers. Engineering managers hear a little bit about our engineering culture, our practices, what some of our projects that we're working on right now are, and sort of have the opportunities to need to meet their colleagues, before they get into a more formal, "Send us a resume, we will schedule a time for an interview," sort of hiring process.
Patrick M: 00:03:13 And that's been very successful, both from the perspective of meeting a lot of interesting people, being able to give the pitch to a lot of folks, and from the sort of business results' thing, that of what to do for our hiring funnel.
Matt H: 00:03:25 Wow, yeah. Yeah, there's a lot to unpack there, and I would love to get into that a little bit more. But, I think it would be valuable for our listeners just to take a step back, and to talk about your role at Stripe. Actually, I don't know how long specifically you've been working with Stripe. Sounds like you have a pretty unique role, and then I'd love to get into what that role specifically is, and if there is any specifics that you sort of spend your time on most. And why Stripe chose to bring you on, if you can, probably a difficult question to answer, but if you can answer that, I would love to get into that as well. So, what is it that you're doing at Stripe right now?
Patrick M: 00:03:56 Sure, so I've been at Strip about three years, next week. Prior to that, I ran small software businesses from here in Japan, for the last 10 or so years prior to that.
Patrick M: 00:04:06 So, what is my role at Stripe? It's a little bit squishy. There's pluses and minuses to it being a little bit squishy. The easiest thing that doesn't lose too much fidelity to the truth is that I'm a senior individual contributor on the marketing team. But even there, things get kind of fuzzy. So, the first two years that I worked at Stripe, I was working on the Stripe Atlas, which is one of our products that helps entrepreneurs worldwide help get set up on legal and financial rails, to start the company off on the right footing. And even when I was working primarily on Atlas, I was doing a little bit of everything, as one does when one is working on a project that's in the earliest stages.
Patrick M: 00:04:44 I was one of the relatively few people in the team that had an entrepreneurial background. Worked a little bit on the product side of things. If you were an early stage entrepreneur, what do you need, and what can we actually provide you. Worked quite a bit on writing of the Stripe Atlas Guides, or later causing to have written the Stripe Atlas Guides, which are ways to teach people the art and science of running early stage tech companies. I worked at sort of tier three customer service for a lot of Atlas users. We tried to establish the expectation that Stripe Atlas users could write [email protected] with basically any question about their business. And as long as we were legally able to answer it, we would try to answer it. And so we would get things from, "How do I raise investment?" To, "My co-founder and I are going through a break-up. I need a shoulder to lean on."
Patrick M: 00:05:29 And so that is not the typical sort of question that comes into a customer support channel for a company, and answering that was sometimes a bit challenging for us, and so tried A, pitch by not answering those sort of things, and B, kind of build up the process that would allow us to have a good user experience for that unboundly kind of question. Kick started the Stripe Atlas community, which is now run by my colleague, Matt Richmond, and just tried to pitch in on a lot of projects across Stripe. The current rescoped marketing role, I continue to pitch in on a lot of projects, including as we talked about, the recruiting thing with remote engineering.
Matt H: 00:06:02 It sounds like the role that you're in would be only doable by somebody like yourself, so I guess, was it a role that they were specifically looking for, or did the executive team at Stripe know you, and know what your experience was, and then sort of created something around your skill set, assuming that you could of course, contribute in a positive way to Stripe? Was there one way, one process that they had for that, or was that just a job that was posted, I guess?
Patrick M: 00:06:27 I think there's a little of column A, a little of column B. So, Stripe knew at the point when Atlas is off the ground, that they wanted someone to do a lot of writing for the project that eventually became the Stripe Atlas Guides and they have the rough outline of okay, well there are subjects that entrepreneurs don't really understand that well when they start their entrepreneurial journey. Everything from marketing to sales, to bookkeeping, to how does one de-risk a product that you're building. And they wanted to be able to teach that at scale, and so freight find someone that could teach that at scale was, as far as I'm aware, an open job req with a nicely designed page and everything, prior to me being involved.
Patrick M: 00:07:06 And I was sort of a known quantity among a number of people on the internet, inclusive of folks that worked at Stripe at the time, in say early to mid-2016 where that conversation was swirling around internally, and so they reached out to me and asked me if I was interested. At the time, I was still the CEO of my last startup. So, it was said, "Well, flattered to be offered. If there was anyplace I would take a job, that would be Stripe. But, doing the CEO of a startup thing right now." And unfortunately the startup didn't end up working out so, I said, "Well, if you're willing to revisit that conversation, I'd be willing to have exactly one conversation with the company prior to trying to jump in, both feet," on what would have been my fifth or sixth software company at that point. And so went through a interview process and they liked what they heard, I liked what I heard, and so I've been here, mostly happily, for the last three years.
Matt H: 00:07:55 Yeah. So, with that, I would be curious to hear because I've posed to have been following Stripe as many people have, and it's been amazing to see sort of how the business has evolved, based on the core product, of course, payment processing and making that as easy as possible. And it seems like it's going more now into how can you add more value into building startups generally, and building online businesses as a whole. So, I would love to talk about sort of your interest in the Stripe platform, and prior to coming on, what really drew you in, and what got you excited about Stripe?
Patrick M: 00:08:26 Well, the line that I use is sort of an applause line. By the way, I suggest people, when you're interviewing for a position, have a few applause lines ready, because why not? A lot of companies will attempt to qualify us as to whether you're enthusiastic about the product and the mission, et cetera, et cetera, and my applause line, which is a thoroughly literal statement is that, "I fed my family out of a Stripe account for the last six years." Want to continue feeding my family, that would be great. But, I've been the customer, I've run a business online, and I had been using the payments product, since approximately let's see, Stripe came out in late 2010. I think I signed up for my Stripe account in early 2011, and had used that to run two of my businesses to decent at least, by my next petition, so levels of success.
Patrick M: 00:09:08 And the capabilities that it gave me as someone who is a first time entrepreneur for the first business, and not really connected to high quality entrepreneurial ecosystems were pretty amazing. I remember when I started my first software company way back in the day, back in 2006, actually blew 15-25% of my budget on faxing a paper contract internationally to one of the legacy payment providers, so that I could get set-up to take credit card payments, and then after going through, I want to say about two months of underwriting rigamarole with PayPal, got approved to take payments through PayPal, obviously while I work for a direct competitor these days, so I still say shout out to PayPal, they've empowered a lot of entrepreneurs worldwide and I'm extremely happy for their success, and the fact that they do have a pretty quality product in a lot of places.
Patrick M: 00:09:56 Anyhow, I started using Stripe. Stripe was amazing in a lot of ways back in 2011. Very, very clean APIs to integrate against. There was an easy integration story into people's own websites, which was a relative difficult integration story with most of the other providers until quite recently. And the quality of the dashboard experience was, had the impression from the first day that someone must be actually running a business on top of it because it does some things that really are not obvious requirements, but make life much easier for me.
Patrick M: 00:10:26 One, from back in the day, and I'm still impressed by this, is that if you go to the dashboard, and you go to the search box and type in the last four digits of somebody's credit card, which you'll often do in the course of supporting a customer who says, "Hey, I paid for it with a card with the last four of blah, blah, blah, and I didn't get my product, what happened?" If you type in the last four, it will immediately pull up the associated transaction. That is not a thing a PM would obviously come to the conclusion of, "This is something that my search bar needs to do without any further clarification," but that sort of sparkly attention to detail on the product, was a thing that majorly drew me to Stripe, both as a customer and then later as a prospect or an employee.
Matt H: 00:11:07 Yeah. That's, and now being a Stripe user ourselves, that attention to detail is certainly one of the things that I think keeps us happy, and I know keeps us happy and many others happy as well. So, it's very clear that there's a lot of thought that goes into all that kind of stuff, and it's the product, as good as it can be. So, super interesting piece there. Now, when you started at Stripe, was the concept of remote work, it sounds like there may have been some engineers that were working remotely at the time. It sounded like you have some experience as well working remotely. But that wasn't why they adopted, was that correct?
Patrick M: 00:11:41 I believe that runs correct. We've had engineers working remotely since almost the early days of Stripe. I want to say, 10 employees or so in, and there was no formal program, and it hadn't really been scaled to materiality. So I was working remotely for the Stripe Atlas team, which is based out of San Francisco. Well, I was working here in sunny Tokyo, and that was a not terribly common state of affairs back then. It is much more common these days, and we intend for it to become even more common in the future.
Matt H: 00:12:07 So, three was recently an article, I think written, or an announcement that you were looking for ... You were doing a widespread sort of hiring spree, specifically for remote work, and I guess in our mind, not having known that there was remote workers within Stripe already, it seemed like that was sort of the decision that was made at that point. But it doesn't sound like it was a one decision kind of, "This is what we're doing now." It sounded like it was more of a gradual process of coming to that conclusion. Does that sound about accurate?
Patrick M: 00:12:33 Yep. I think that a lot of major strategic initiatives are something which you sort of find yourself, I don't know, the frog boiling metaphor is not exactly the correct metaphor to use in this circumstance. You do something once by accident or happenstance, or because you're trying a portfolio strategy of new experiments that works out. You put more resources into the experiment. It continues working out, and at some point, the organization needs to make a decision of, from the large portfolio of experiments that someone in the organization is running it, at any given time. Which are the ones that the organization as an organism unto itself wants to very seriously dedicate some firepower behind.
Patrick M: 00:13:11 And by the early 2019, we had overwhelming conviction that remote work was the future of, going to play a material part of the future of engineering work, both at Stripe and the industry probably. And we were like, "Well, if we think all the savvy companies are going to be here in five years, our customers are going to be here within five years for the ones that aren't here already. We should certainly steal the market share, and tell that buyer remote team to understand this new and emerging organizational technology, that the industry will be building on in the next couple of years."
Matt H: 00:13:42 And obviously we are a huge proponent of that, and sort of the phenomenon that we've seen over the past, especially two years where this has become more and more popular. But it's quite rare for, well, I shouldn't say it's rare. But, it's more common for companies to start out as remote teams obviously, and it just, logistically easier. It's a broader talent pool to pull from, all that kind of good stuff. Less rent expense obviously, when it comes to having a physical, geographic HQ, but rarely do you see sort of a larger established company deciding that at one point, then this is something that they wanted to take on, and moving towards a fully or more distributed workforce in general.
Matt H: 00:14:15 What was that decision like internally, and in terms of when you did make that decision, what was the next step for you? Was it a matter of coming up with processes, procedures, things like that, or was it kind of building off of what you had already done, or what was that decision like and what was the aftermath of that decision for you internally?
Patrick M: 00:14:31 So, I think there were a number of things that happened. One was we had, had a number of engineers working on Stripe who had successfully worked as remote for a while. We put a person that was basically in charge of the remote initiative at Stripe. His name was [Adeeta 00:14:45], and he is our remote DRI, directly responsible individual. And I believe, my understanding is that he spent quite a bit of time interviewing the existing remotes, asking them what about their experience had been very positive, what mechanisms with respect to big picture thing like management, and little picture things like literally, "What is the kind of microphone that you use, are you happy with it? Tell me about the space that you do remote work from. Are you happy with it?"
Patrick M: 00:15:10 I believe he spent some time himself experimenting with lighting setups, to feel like he could participate fully in remote calls over Zoom, et cetera, et cetera. And so there was a bit if a research process internally. At the same time as the research process was running, there was also a sort of internal socialization/getting everyone on the same page around, "We are still the smallest company in the scheme of things, but we're not the smallest of small companies anymore," so there is a bit of righting a ship that has momentum behind it element going on, where for a number of years, we had been sort of lukewarm with respect to remotes organizationally, and we're saying, "Okay, we are going to make, not exactly 180 degree change with respect to that policy, but we are going to make a material change with respect to policies."
Patrick M: 00:15:53 So, communicate the desirability of that internally, make sure that, for example, it would be a bad thing if like our recruiting department learned, the fact that we were enthusiastically recruiting remote engineers when they woke up and read Hacker News that morning. And so talking to teams internally, talking to teams that had remotes. Asking what they had done to successfully integrate those remotes into the culture of those teams. Reviewing results from our company wide survey, with respect to ... We do a company wide survey twice a year to all employees, and sort of classifying results by remote versus non-remote. And seeing where the underlying issues still were. Seeing what we should prioritize for things to fix in the scope of the next six months or so, and then preparing for, one does not simply wave a magic wand and hire a hundred people.
Patrick M: 00:16:39 Among other things, you have to interview many, many more than a hundred people, and you also have to have more than a hundred open slots in the organization. And people who are definitely willing to have a remote colleague working in one of those open slots. And so there was a bit of a finding the right teams that were hiring folks, and that the internal communication norms that we thought that there first or second remote employee would have a very successful experience from the jump.
Matt H: 00:17:03 Yeah, so it sounds like the more deliberate approach to remote work, and has been, it's pretty early days for Stripe, it sounds like. That being said, it sounds like there's also enough time that has gone past, in terms of the remote teams, that you can pull some data out and you can make some conclusions as to what's working, what's not working. Is there one thing that you can point to, and again, this is a difficult question. Is there one thing you can point to, that has been a major pain point that you maybe didn't expect after the deliberate change to be a more remote team?
Patrick M: 00:17:30 I don't know if I would say this is something that I didn't expect, but one of the major challenges had just been the challenge of hiring at scale. Finding, if you work back from the way that funnel math works, to hire a hundred people, you want to interview some number of hundreds of people, which probably means having initial team screens with low of thousands of people. Which, requires engaging at some level, some higher thousands to low tens of thousands of people. And so just, identify 10,000 people in the world who would possibly be interested in working at Stripe is a non-trivial problem. And then making sure that both our existing hiring technologies port over to people that are the remote candidate pool, which is a different candidate pool than the ones rather that we hire for our outside positions, both in engineering and outside of engineering.
Patrick M: 00:18:18 And we are both attempting to grow rapidly on this, while also attempting to integrate the people that we are hiring, while also attempting to keep the wheels on the straight bus, and those sort of things are obvious challenges. But they don't stop being challenges for being obvious challenges.
Matt H: 00:18:34 Right. That makes sense. And I think you're in a unique position to be able to answer this question, because you've had some remote experience in the past, and it sounds like you've been remote for most of your time at Stripe. Have you noticed a deliberate, maybe not even a policy change, but a way of approaching the culture aspect of Stripe when it comes to remote teams, and it sounds like it's semi-distributed, so you do have an HQ, and there's also engineering teams outside of that, that are fully remote. Is there something within that sort of policy that you have that is getting out in front of the potential downsides of having a semi-distributed workforce, like having people that are in an office, and some people that aren't? Or is that not something that you've considered as an issue, or how do you approach that?
Patrick M: 00:19:15 I think that the situation has been getting quite a bit better over the last couple of years. One of the nice things about this being a formal initiative at Stripe to hire many more remotes, is that there is both a level of understanding that this is a thing that we're committing to, at the same time is the relative proportion of remotes, both organization wide and on particular sub-organizations like say, the engineering organization or any given team that has remotes on it. The proportion is going up and quite steeply. And so, there's no longer either the feeling or reality of being like the only remote on team, or having a unique position where you kind of have to advocate for the unique challenges of your position. The organization is getting better at anticipating your needs.
Patrick M: 00:19:56 Shout out to one person who shipped a particular thing at Stripe. I believe this engineer's a remote herself. She said that, "It was socially awkward when a meeting would be called, and people use the internal system to calendar up the meeting, and book a room for the meeting, and then not add a Zoom link to the meeting." And so as the remote, you would have to ping people on Slack saying, "Hey, I would like to attend this meeting as well, because I'm on the invitation, but I can't attend the meeting unless we make a Zoom room and dial the room into that Zoom link." And so we made a not too complicated bit of software to say, "Okay, if there are two plus people meeting at Stripe in a room, just assume that there needs to be a Zoom link open for remote joining that meeting." And so, now the onus isn't on remotes to say, "Hey, guys, we'd really love to be here. Please include me."
Patrick M: 00:20:45 Considering isolation, that's a little thing. Like it's a tiny stitch in the craw of the person that has to make that ask, perhaps a couple times a day. But like, a tiny stitch in the craw of somebody a couple times a day with respect to their core relationship with their co-workers, is not a tiny thing. Particularly when you aggregate it over hundreds of days, times hundreds of engineers. And so, removing that point of friction forever is a absurdly good use of our internal systems engineering time, right?
Patrick M: 00:21:12 And that's one of the things I love about working here, is that literally every engineer at the company can contribute to internal systems. My one patch that I can remember is making it possible to use digits in someone's internal user name, because I really, really wanted patio11, which is my user name that I've used forever. And at one point, that wasn't possible for technical reasons, so possible now. But yeah, the amortizing of the cost of an internal system thing over many hundreds of engineers in a similar situation gives you quite a bit of business impetus to do, whatever it is that is necessary to maximize the productivity of those people.
Matt H: 00:21:47 Yeah, you mentioned something there as well, that I think is important to touch on, and again, you would have a unique insight here. So, one of the big things obviously with remote work, and one of the downsides is, is that there is that level of isolation that I think is just a structural component of working remotely, obviously. And you don't have that ability to tap on people's shoulders if you want to chat about something outside of work, or even within work. So, is there something that you do individually, that helps with that isolation piece? Is there something you do to make sure that you aren't feeling that level of isolation within your workplace?
Patrick M: 00:22:15 So, if you don't mind, I'll answer it on the team level, prior to the individual level. One thing that I really appreciated that the Stripe Atlas team did when I was on it, and I believe this was spearheaded by our engineering manager, Alex. We'd had one or two people on the team that were remote, for the majority of the team's existence. There was a circumstance which caused us to hire several more remote employees in the moments, and Alex said, "It would be great if all of us achieved a sort of emotional understanding of what it is to be remote. So why don't we all as a team, do an experiment where we just work remotely for a week, and then we can understand what about our team communication arms, about our standing meeting schedule makes life difficult for our colleagues and fix those things. And also just have an emotional understanding of how does the water cooler relationship with co-workers work, when you will only be around the same water cooler for perhaps five or 10 days a year."
Patrick M: 00:23:09 So we ran that experiment, found out some things. There was a great deal of empathizing across team about that, and then made some changes as a result of it. What do I do in my personal life? I make a special effort to invite people to come out to Tokyo, just hosted a co-worker of mine here last week, and while he was in town, did a bit of both actual hands-on work, actual first time out to Tokyo, and a bit of taking him around for things like karaoke, which is both a standard Tokyo socializing activity, also a bit of a hobby of mine. Out to some of the restaurants in my neighborhood, et cetera, et cetera, to give him a slice of life of what I experience every day.
Patrick M: 00:23:47 Similarly, I try to get out to San Francisco when the majority of my colleagues are, as often as possible, to both experience the slice of life, and also to do the sort of hacking or monkey brain thing, with regards to your tribe is whoever you break bread with, right? So, even as a remote employee, it is extremely useful to be able to break bread with your team, as often in a year as you can manage it. There's some very micro tactical things that I've gotten out-sized results on. Sometimes team is just, do something to have a team outing together. Like in San Francisco, there's a bunch of people on the Stripe Atlas team who really like tapioca milk tea. I think it's usually called Boba tea in the United States.
Patrick M: 00:24:23 So, it's like, "I'll get Boba." And when the Atlas team gets Boba, I get Boba. Despite the fact that I can't physically consume with them. So, I go out to the neighborhood Boba shop here in Tokyo, and get a Boba, and then I take a picture of the Boba and send it into our Slack channel, just so everyone could feel that I'm virtually participating in that team bonding activity.
Matt H: 00:24:42 And going back to this, the organizational piece of it, and you mentioned that there was an initiative that you'd done, to make sure that everybody was aware of what it is to work remotely, but is there anything that's encouraged, in terms of daily activity that you have to sort of fight against that level of isolation that people feel on a daily basis?
Patrick M: 00:24:57 I think that we have a lot of autonomy with regards to how we interact with our co-workers and what team communication norms are. So, there is many teams that have different practices there. Some have a standard calendared, sort of like a meeting with no agenda where it's just 30 people in a room, don't talk about work at all, just have the substitute water cooler conversation. I haven't participated in that myself, but I think that, that plausibly it works for people, if it works for people. Some have a, they make a special effort on the team to encourage appropriate level of one to one meetings, just to maintain the team bonds. Some try to, in addition to our cross company meeting that we do once a year where we fly substantially everyone out to HQ, they try to do a meeting once a year where everyone goes to a "third location," to have an offsite and have the opportunity to both do some focus work together and renew acquaintances. So, various kinds of experiments with respect to that.
Patrick M: 00:25:52 I think establishing good, inclusive norms of communication with respect to remote employees is probably the most important thing for a company that is transitioning from a past where they didn't have that many remote employees, to a future where they will have lots. And that means, for example, making sure that important decisions are made in a way that people can participate in, made over Slack or a Zoom call, versus two people talking in the hallway. That important decisions are communicated in a way that people can see it, the decisions that are impacting their work have been made. Stripe had a sort of baked in advantage in that we communication groups in the company to send lots, and lots, and lots, and lots of email. Now, we've written about this online, but A, Stripe sends a lot of email internally, B, the super majority of that email is widely visible within the company.
Patrick M: 00:26:42 And so the fact that many of our big debates as a company were happening over email threads or in a shared Google document helped to have our early remote employees, and the ones that we're employing as the result of this initiatives be more included then in the counter factual world in which, if most of our decisions were made in meetings, then you can't actually be in the meeting, then that does not optimize for your ability to participate in that decision.
Patrick M: 00:27:07 I also think one of the challenges of remote work is the social nature of, when you are the only person calling into a room of 13 people who are all physically present in the room, you're in the meeting, but not really in the meeting. So, there is like a critical mass factor that helps with regard to that sort of thing. Also, it helps to acknowledge that there's a differential there that doesn't go away, even when it's 10 people in the room, and three people outside the room sort of factor. And it's one of the things where, if that is the distribution of your workforce, then you just have to acknowledge that it's a factor and either push the important decisions into places other than meetings or establish communication norms, such as that people understand that, oh, if there's a speed of light play between myself and someone whose opinion I value on this call, then put natural pauses in where we're speaking as such that, they can jump in with what they want to say.
Patrick M: 00:27:56 Or, people have other solutions like holding the talking stick, et cetera, et cetera. Haven't seen that work super well in any participate instantiation, but as the entire industry jumps on the remote train, I think that there will be many thousands of experiments around that. Some of them will bear fruit.
Matt H: 00:28:13 Yeah, no, I'm sure. I'm sure of that. One of the interesting things about watching this phenomenon play out is the technology that has popped up around some of the pain points that come up with remote work, and it's going to be an interesting thing to watch. But, it is also interesting to think about the fact that there are some things that are encroaching on the benefits of remote work, too, which so the nature of being able to put your head down, and work hard on a problem, and without being distracted. So, I'm hoping that there's this sort of a happy medium that gets met here with technology that improves, and efficiency of remote work, and yet doesn't encroach on some of the benefits of remote work, because it's a fine balance, I think.
Patrick M: 00:28:45 I think to the extent that inviting any group of people into your organization helps to bring the figurative DNA to practices, the culture, et cetera, into the organization, to the extent that we think that remote work is delivering on the promise of giving knowledge workers a way to deep focused work, like demonstrating to organizations that deep focused work is so valuable, that you should carve out space to protect it. It's a thing that is difficult to transition from, without a major catalyzing event behind it. But if the inclusion of remote workers is that major catalyzing event, possibly that there will be organizations that manage to leverage that across the entirety of their employee base.
Matt H: 00:29:22 Interesting thing that you mentioned a while back was, well and sort of indirectly I suppose, when we first started our conversation was, just the idea that it might be difficult to separate I suppose, work from time outside of work. So, I guess my question is, within Stripe, and I know that Stripe has a values output, and excellence is a really big part of your culture, how do you manage to make sure that people aren't overworking themselves, and aren't pushing themselves into a place where they're going to be burnt out and unproductive, and still maintain that level of excellence that you expect?
Patrick M: 00:29:50 So, starting from first principles, I don't think that the level of excellence requires overwork. In most cases, I think that overwork tends to cause people to perceive that their output is going up, but generally it decreases the absolute amount of output, and generally causes hits against the quality. And in most cases when we're making the trade-off, we prefer less work done at a higher quality, than more work done at sub-standard quality. We attempt to keep the quality part really high. There's talk about some of the cultures and practices that sustains that later, if you're interested in it.
Patrick M: 00:30:21 Towards the general question of how do we encourage people to draw the balance between work and other responsibilities in such fashion that they can do their best possible work while not dropping their other balls, super candidly, I wish I personally was better on this topic. We attempt to preserve a lot of autonomy for people, such that they're able to make whatever sensible trade-offs, given their particular stage in life. Their particular values, what they're optimizing for right now, et cetera, et cetera.
Patrick M: 00:30:48 There are some trade-offs you can make in remotes, with respect to scheduling flexibility, which are for a variety of reasons, just more difficult if you work in an office every day. It is relatively easy for me, as someone who works remotely, to take off an hour or two in the day, and just shift my schedule a little bit to do something like cover child care for my wife, or run an errand or two. That is more difficult if I was commuting to an office, just by the logistics of like, have to commute in, have to commute out. Have to commute in, have to commute out again. So, that sort of thing can, without doing a big change on the raw number of hours worked, or the amount of output created, create a not enough flexibility dividend with respect to your ability to meet your other commitments during that day.
Patrick M: 00:31:30 Part of it is, sustainability has to start from a culture, and it has to start from people up and down the organization modeling it as something that they truly value, and I think we have mixed results with respect to that. We're a high flying Silicon Valley company, have many hard charging individuals at it, and good for them. Making sure that we can support different work styles as well, is an important thing. Making sure that people feel recognized for the work that they get accomplished, rather than judged on the basis of whether their work style conforms with company normative work style, if that were a thing that existed, is important.
Patrick M: 00:32:05 I think also, there's probably transigent points in the life of a company where, what is it six people or 12 people together, there might very well be a company normative work style, where the right work style is the one that all of your co-workers would adopt, without consciously deciding to adopt it. But when you get to 600 people as the day I joined, or 2,000 people as of these days, the company will sort of, by necessity, have to adjust to the reality of that it has employees that have many different work styles, and we have offices in many different corners of the globe that have sort of very different professional cultures, or cultures with respect to work styles prevailing, and the sorts of folks who usually staff professional positions. And so some amount of adapt into that reality has to happen.
Matt H: 00:32:47 Yeah, no, that's interesting that you mention that the piece of the reality of having different offices, and even in different geographical locations. I hadn't really considered that, because I suppose I haven't really talked to very many other companies that are at your scale in terms of the number of people that are working for you. It sounds like as well, it's really up to the individual to come up with whatever system works best for them, and with the understanding that as long as the product or the output is up to the standard of Stripe, then that sort of is the way that is best suited for them, and that's fine. Is that sort of accurate, or do I have that wrong?
Patrick M: 00:33:15 So, I hoped there would be more support from their manager in their organization, than just saying it's up to the individual to figure things out. Ideally, we have some organizational understanding of what success looks like, and we can model success and have people choose from a variety of options available to them. This is different for different people, in different parts of the organization, and different for different jobs. But, in some jobs, there's sort of a constant cadence of, in sort of a user operations role, there might be relatively constant number of tickets that come in every day, and you do a relatively constant number of tickets every day, and that is what good execution looks like.
Patrick M: 00:33:51 In a job like engineering or design, or writing, you might be doing creative work. Creative work doesn't necessarily schedule in X units of output on Monday, and then X units of output on Tuesday, both because the business needs of the business don't schedule in that fashion, and also because the spirit is willing but the muse does not decide to come in for work that day. And so, you kind of have to adjust to that reality of the work, but hopefully you'll be doing it in the context of an organization that, "This is not the first time we have hired an engineer. We understand that productivity is not a constant, measured over every day, and we've adapted to that reality and adjusted in the context of a helpful, empowering culture, both among your colleagues and your management chain."
Matt H: 00:34:34 I'd be curious to know if there's something, because I was asked this question actually recently, and I didn't have a very good answer, so I'm hoping maybe you could help me out with it. If there's anything specific in the hiring process of let's say, in your case, in the engineering side of things. If there's any specific in terms of personal characteristics that you look for when you are hiring a remote engineer, versus hiring an in-house engineer, is there anything that jumps out at you, in terms of differences that you would look for? Or qualities that would make somebody a successful remote worker verus someone that wouldn't as much? Or, is that not something that really comes up as much?
Patrick M: 00:35:04 A thing that comes up sometimes with regards to early career professionals is that there is sort of a skill curve on learning how to work, and organizational technology, that we as a society have developed for papering over early career professionals lack of that skill specifically, is the office environment. The office environment kind of provides the sense of having someone looking over your shoulder, and sort of enforce discipline with regards to starting, and stopping, and maintaining a pace, and talking to colleagues on a particular cadence, et cetera, et cetera. That sort of enforced discipline does not happen so much, with respect to remote workers. And so you generally have to be at a higher point along the skill curve of core life skills for working at a professional company, and you have to be a little bit better with respect to self-discipline, and self-motivation. And also, I believe those are true and are likely to remain true over the next couple of years.
Patrick M: 00:35:58 In that transitionary state we find ourselves in, I think you also have a little bit more than an office based employee with respect to bearing the organizational burden of making sure conversations between you and people at, say headquarters or whatever office that you're communicating with most frequently, happen. You have to practically cause those conversations to happen, but for like core execution, have projects done for career growth. Hopefully, that will change over time, as we get better at integrating remote folks into the organization, but as a true statement of reality, in September of 2019, you kind of have to be proactive with regards to managing it yourself.
Patrick M: 00:36:33 And so, a combination of those things is both an important thing to assess for. Also, an important thing to level set with regards to candidates, there are people who really, really enjoy having someone who will check in with them regularly and make sure that they're on task, and provide that structure. And we should be up front with remote candidates that, "If you're expecting someone to spoonfeed structure for you, this role at this time, in this company, might not be a great fit for your interests." Conversely, if you are someone who has run a business before, or is just super motivated, and is capable of providing that organizational structure for yourself, then that is great because you very heavily ticked one of the boxes of what we think will likely be a requirement for being successful in doing this.
Matt H: 00:37:18 Yeah, it's always an interesting one. Like I said, I didn't have a very good answer for it, but it seems like it's just one of those things where you just have to be better in a lot of different areas, and not specifically one characteristic or one personality trait that allows for quality remote workers. You're just going to have to be better in a lot of different ways, and maybe that's the answer.
Patrick M: 00:37:35 I think that there's also a component with respect to, the dominant word in remote work is work. It isn't remote. There's no one characteristic, or one skill, or one personality trait that makes a good engineer. People spike differently in different places with that, and even with an extreme level of, for example, core technical acumen with regards to Kubernetes or whatever your tech stack of choice is. You would probably not be all that successful in many jobs, and certainly wouldn't be successful at Stripe, without quite a bit of communication ability. At Strip, in particular, there is a heavy emphasis on written communication, and so people who do well in writing documents, whether it's design documents or arguments for where the business should go, or updates to the company after shipping something, people who do all of that do well. And people who have difficulty expressing themselves in writing, Stripe would be a really difficult company to work for.
Patrick M: 00:38:28 And in a similar fashion, if you're working remote at Stripe or another company, there's some blended collection of skills that are sort of specific to the remote nature of it. There's a larger blended collection of skills that somehow can balance your effectiveness within the team that you're working on, the role that you're working on, the organization that you're working with, and you kind of have to bring a portfolio with enough depth within the right places, and enough breadth overall to be successful.
Matt H: 00:38:54 Yeah, no, I know it's a quite interesting subject, and I hope that it becomes clear for a lot of different people, because I think it's an important one. The one I want to talk to you to, and this might be a difficult question to answer, because projections in general are difficult, but how do you see remote work going within Stripe? Is this something that you're looking to test for, and then maybe expand to other portions of the company? Or, how do you see the future of remote work within Stripe?
Patrick M: 00:39:18 I think we don't have any major announcements to make with respect to this, other than the one that we made earlier this year. From my limited point of view with respect to the outcomes of this experiment/initiative, all speed ahead with regards to remote work. We truly believe deeply, as an organization, at many different levels in the organization, that remote has not been a standard part of all software companies, or all savvy employers of engineering talent in the software, tech, and related industries, over the course of the last 10 years. And we believe strongly that, that will change. My internal time frame for this, probably five years from now, it will be about as common as GIT is, and GIT is pretty darn common at this point. GIT wasn't a veracity of one either, but I think that all the savvy teams in savvy organizations are going to have 10s of percent of their engineering pool, or engineering teams rather work remotely.
Patrick M: 00:40:13 And I say engineering just because I am engineering by trade, and by sort of self-identification. Even if I work on the marketing team, and don't shut code that much anymore, but I think this is probably true of many other techs that work as well. And so, with increasing adoption of this by both our industry, and a variety of other industries, with the technology for it getting better, and sort of organizational comfort levels at this getting higher, as more and more companies experiment with it and see success, and develop these systems and processes and technology that will allow them to achieve higher levels of success in the future, I think the adoption curve is going to start going upwards in a material fashion. And we are trying to race to be there before everybody else is.
Matt H: 00:40:57 Yeah, I know it's great to see Stripe on the wagon for sure, and we're excited about it and excited to see where you go with it. So, I wanted to take another sort of step back here, and I want to talk a little bit about your writing. I'm glad that you mentioned that is one of the core parts of Stripe culture, and what's important to Stripe is writing, and it seems very clear that, that's the case for you. And being a Twitter follower of yours, it's I'm always fascinated by the scope of your interest, I suppose, and just the what the different avenues you go down, and how deep you can go, and it's really just quite something to witness and to see. It's really quite something, so anybody out there who hasn't, isn't following Patrick yet, we'll link to his Twitter feed, and you should start doing so immediately, because it's really amazing.
Matt H: 00:41:48 But I was curious to know, if there's something that you, if there's like a scope of what you find interesting, or what you set out to explore, and then you go explore that thing, or how is it you go about just what you find interesting? What you do deep dives on, I guess is my question. What do you decide to do, to dive deep on in terms of your research?
Patrick M: 00:42:11 Sure, so it's an interesting question. I have very broad intellectual interests, and one of my hobbies is picking up more obscure ones, so generally attempt to go very broad on things, and then occasionally go very deep when the spirit moves me. Sometimes, it's because I'd been capable of diving deep on a subject because there's some actual legitimate business need to understand that subject very well. Candidly, what happens more frequently with me is that, I am exposed to something by business sort of life. The original reason I got into engineering was that, well the original, original reason was that I wanted to play more video games, and writing them would be a great way to have them, but the thing that kept me in the field is that I loved tearing apart complex systems and seeing how they tick.
Patrick M: 00:42:55 And so, when I'm exposed in a material fashion to one of those systems that just floats around our ambient environment, but that we never think of in a very detailed fashion, insurance, or how do stock exchanges work, or how does money move around the global economy, I have a tendency to sink my teeth into something and just not let it go for a while. There are generally being two ways to get information out of this world, other than discovering it oneself. One is reading what other people have written. The other is talking to other people. I'm a little bit shy, so I often end up reading in preference to talking to people. There is a surprising amount of information on Google these days, about basically any subjects that you could possible want to read about.
Patrick M: 00:43:36 So, if you want to dive down a rabbit hole of what the consumer credit reporting regulation looks like in the United States, and read the Fair Debt Collection Practices Act, and the Fair Credit Reporting Act, and the various regulatory state machines around those two, that piece of legislation, and how they interact with the credit reporting agencies, and I feel like I'm getting a little bit off the beaten path, but this is sort of the way my brain works, in that subject seized my interest in 2004 and wouldn't let me go for a few years. And go figure, it turns out that if you end up working at a company that processes credit cards for a living, understanding the credit card ecosystem can be useful. But, yeah, sometimes the idea grips me and just won't let me go for a while.
Matt H: 00:44:15 Yeah, and I've learned so much from you, just from following you on Twitter, so thank you for being so public about that. I appreciate that, and I know many others do as well.
Patrick M: 00:44:22 Thanks very much. I'm patio11 on Twitter if anyone wants to follow me, and also [email protected], if you ever want to send me an email.
Matt H: 00:44:28 Yeah. No, we will definitely link to those things. I'm curious if, writing publicly about the things that you're interested in, what does that, outside of just your own distilling your thought down into whatever Twitter is limiting you to at the time, is there any other sort of major benefit you find in being so vocal and public with the way you write, and what you write, and how you write, I guess?
Patrick M: 00:44:51 Oh, goodness. You could do an entire podcast entirely on that, and the various benefits of having a body of work that are publicly available. I almost certainly would not have my job at Stripe, but for the fact that I wrote several million words on the internet. That's the situation from someone who is in a small town in central Japan at the time. Life would not naturally have exposed me to people at high flying startups in San Francisco, or the Silicon Valley, Bay Area. But, the internet's the love link for us, and if you write interesting things on interesting topics, you can eventually come to the attention of people who might be looking for someone to write, or do engineering, or design, et cetera, et cetera, in places that you wouldn't naturally be. Your name will get brought up in rooms that you wouldn't be in, et cetera, et cetera. So, it is a huge friend catcher, if anyone doesn't follow the Texting podcast, a recommendation for them.
Patrick M: 00:45:42 But, one of the most useful things that I learned from them was this concept of a luck surface area, where the amount of luck that you have in your career, is proportionate to the product of the depth of how much you help people, and the breadth of how much you tell about it. And the writing publicly is one of the highest leveraged things you can do, with regards to increasing that breadth factor, without having to do, "more work." I'd say that in scare quotes because in five million words, or whatever my odometer is up to, they didn't write themselves for free. But, much of both the actual impact I've had with my career, and the benefits that have accrued to my family and myself as a result of my career, are directly downstream of having written a lot.
Matt H: 00:46:28 Yeah, that's fascinating, and I haven't heard it framed in those terms, but I think one of the reasons that you've mentioned is just being helpful, and I've mentioned it in a few other podcasts, but I think being helpful is one of the most underrated skills someone can have, especially when they're starting out their career as, "How do I find somebody that I admire, that I want to work for, and how do I help them?" Is, I think a really easy, in the first principles, starting point to go.
Patrick M: 00:46:51 Mind if I give one more plus on the writing topic, that is less relevant to personal career interests and more relevant to the organizational case for this?
Matt H: 00:47:00 Please do, yeah, please.
Patrick M: 00:47:01 Sure. So, even at Stripe, a company that has a very strong writing culture, I think we internally and externally have not nearly hit the point of diminishing the returns with regards to how much we write. Stripe is growing at a stupendous rate every year, and for the sake of argument, I'll asset that there exists some companies in the world that are growing at 2X per year, in terms of the most relevancy to this discussion and employee count. And a intimidating and un-escapable effect of the math is that, if a company sustains 2X growth in employee count per year, that the first year you work at that company, half of your colleagues will have less than one year of tenure. The second year you work at that company, half of your colleagues will have less than one year of tenure, and the third year you work at that company, half of your colleagues will have less than one year of tenure.
Patrick M: 00:47:46 And this is really, really not the way that organizations are, "designed to work." You have to pour an incredible amount of effort into educating people about both what you do, how you get it done at your particular organization, and the why. Like, "Why was the decision made?" Because there will be people enacting the company ritual or policy, or something three years from now, who were very much not in the room, and you need to kind of have to institutional memory of why you did a thing that way, the both so that those folks can make a determination of, "Have circumstances changed? Should we change this?" Or rather than just keeping it a stuff policy or ritual in all time, because it sounded great to the three people who happened to be in that conference room several years ago, in a country far, far away from us.
Patrick M: 00:48:38 Or, "What is the best possible way among our execution options on the table, to execute on the intents of this policy?" And doing that in a scalable fashion, I think writing is probably the most scalable way to do it, because you can write down your thinking once, and have it read for literally hundreds of years. And the alternative, and something that happens at every organization, I think, is that people maintain sort of like an aural lore of the company, but particularly in a quickly scaling company. The aural lore has some limitations.
Patrick M: 00:49:10 You have to keep the ... because I've played too much World of Warcraft, and because I intentionally want to hang a bow on this topic and say how absurd it is, like if you had an explicit title at your day job of Lower Master, where these are the folks of a wizened countenance, who have been here since before the flood, and understand the rationale for all the decisions, you would literally need that to be pretty much an explicit part of somebody's job, and to have a lot of Lower Masters and some redund Senior Lower Masters, and maybe even some sort of like charting strategy, of which information sits in which Lower Master's head, such that you don't have the bus factor problem with regards to Lower Master availability, and consistency, perch intolerance, et cetera, et cetera.
Patrick M: 00:49:58 So, it's distributed systems problem to maintain your organizational memory, if you don't write things down. If you do write things down, computers are great about preserving documents, so as far as they exist. Peaches and cream, it'll be amazing. So, organize yourself to write much, much more down than you would ordinarily. There are huge, huge benefits to doing so. I perceive Stripe as probably one of the companies in the world that has gotten the most benefit out of the incredible amount of writing we do internally. I think we could probably almost literally increase it by 10X, and still not hit the machine returns.
Patrick M: 00:50:32 I'm doing my gut check of, "Do you really believe that, or does it just sound like something that has the ring of being plausible, and would sound good on a podcast?" And no, I believe my considered second and third thoughts, had to cherry press it, my second and third thoughts are, "No, I really believe it. I could write 10 times as many documents as I do, and would probably have a far greater than 10X increase in effectiveness." Penciling down note to self, "Write more this year."
Matt H: 00:50:59 Wow, that's fascinating, I'm glad that you brought that up. Is there anything that Stripe does internally to make sure that people are quality writers, or maybe improve in their writing skills, or is this something that you guys hire for right away, and if you're not a good writer, then you're kind of not even considered? Is there anything that you do in that sort of realm at all?
Patrick M: 00:51:17 We do definitely assess for writing ability, in that many of our hiring loops. Outside that, I don't believe writing ability is a static thing. I think you can definitely improve if you have deliberate practice. We do attempt to support our professional growth as writers. But candidly, this is one of those areas where we don't have a decision that we're fully happy with. If I had a magic button that could subjectively double the writing skill of a colleague, I would be doing basically nothing out there but mashing that magic button with respect to any member of Stripe I could point it at. Also, if I had that magic button, I should probably found a company to sell that magic button to Stripe and other people. But, that one is what it is.
Patrick M: 00:51:57 I think writing is much like coding. Just a such a highly leveraged skill in so many organizations and so many industries, that we as a society will because never be as good at it as we want to be.
Matt H: 00:52:10 Wow. Yeah, that's really interesting. I've heard that, and not with the same degree I think, as what you just said, but yeah, I know that in our side, obviously writing, and communication in written form is super, super important. So, that's a good wake-up call for people that are out there listening to go brush up on your skills, and make sure that you're getting feedback on all things that you write down, because that's the only way of, you're going to get better. So, yeah, I think it's a really important one. I'm glad that you brought it up.
Matt H: 00:52:35 Patrick, you've been so generous with your time, I don't want to take up too, too much of it, and you're a busy man, so I'll keep this relatively short. But, I do have a couple of closing questions here for you, if that's okay. The first closing question here is, hypothetically, you can't go on your computer or use your phone for one year. How do you spend most of your time? Maybe I'll manipulate that question a little bit and ask, if you didn't work in tech, where do you think you would work?
Patrick M: 00:52:58 Interesting question there. That would be extremely difficult to me, as my wife can definitely attest to. So, because these intellectual interests sometimes grab me and don't let me go. I did have an interest in anti-fraud early in my career, which is plausibly something that could have got me working in the financial industry as an underwriter or a fraud prevention expert, et cetera, et cetera. And although the financial industry and the tech industry are, they will have an increasing convergence over the next couple of years, I believe.
Patrick M: 00:53:26 The thing I really wanted early in my life, was just get paid for living a life of the mind. And so I thought, "Oh, I'll get a PhD, and then become a university professor and teach classes, and just think a lot, and write down interesting thoughts." And then as I got more exposed to academia, it turns out that's not actually what university professors get paid for. Principally, they get paid for filing out grant applications. One of the things that I've like about my somewhat oddly shaped career in tech, is that both as a business owner and now working at Stripe, I really do sort of get paid for living the life of the mind, and so, if there are other plausible ways to achieve that outside of the tech industry, might end up tempted to walk down one of them.
Matt H: 00:54:08 That's a great answer. So, my next question here, is what is your biggest pet peeve in business and in tech?
Patrick M: 00:54:18 I think people over-optimize in the direction of being able to regurgitate "wisdom," rather than being able to seek knowledge. And so there are many, many deep structural reasons why this is the case, but what are the best practices, and memorize them, and then apply them mindlessly. Or, what is the narrative that is presented in high status publications, be it media or some other source of news, information, opinion, advice, et cetera, rather than making considered decisions as to what things you'll get good at, and what getting good at them looks like.
Patrick M: 00:54:55 I believe that most folks don't do enough experimentation with regards to either their core beliefs about their core comparative advantage. Also, probably don't do enough experimentation on just testing the true value of propositions that are really important to them, and it sort of pains me when folks are, I'd say, intellectually uncurious with respect to things that are directly relevant to their interests. I buy that as someone that has a five minute budget of time and attention, you can't experimentally investigate every claim in the world, but I think that most people would do better to subject more claims to more scrutiny, than they do in their resting case in life.
Matt H: 00:55:32 Yeah, that's a really good one. Do you think that, that's changed since you've been working in tech, or is that something that's sort of been constant in your opinion?
Patrick M: 00:55:40 I think that this is an issue that I have more with the human condition, rather than with the tech industry, per se. There is sort of a meme in the tech industry of being very scientific with regards to approaches. Sometimes, I believe that is a meme that propagates because the meme floaters are self-conceptions, more than being an accurate description of how we work. But, I think there is some non-zero degree of truth with respect to it. It would support us titrating up with the amount of science that we have. Also, by the way, to throw myself under the bus there, that use of titrate is a very considered use of the word titrate, because it sounds scientific, even though I'm using it in a metaphorical sense there. And I do that automatically to score applause points with engineers. And I know that it automatically gets me sort of unearned applause from engineers, but yet do it because it is instrumentally effective. So, there is no level at which this is not a problem.
Matt H: 00:56:33 Yeah, I love that question. Really, really interesting answer. So, I have one more question for you before I let you go, Patrick, and again, thank you so much for taking the time. The last question is, what is the best advice you've ever been given?
Patrick M: 00:56:45 Instrumentally, the most important advice I was ever given, and, which I repeat at any opportunity is to charge more. I believe that most people in tech, both those that are selling products, and those that are selling their services to companies have an anchoring of the worth of those products and services, far below their true worth. And that, this is so widespread and the delta between the true worth that are sort of implicit emotional comfort levels, and the anchorings is so wide, such that I can give people the advice, "Whatever you're charging, just charge more to that number," and that ends up being value maximizing advice for more than 98% of the people that I tell it to. Such that, I don't caveat it at all.
Patrick M: 00:57:28 There are people listening to the podcast today, who you are currently wondering, "Am I ready to get a raise?" And the answer is, you have been ready since the day you were first employed in this job, and you should work up the courage to ask to it. You are currently modeling that as being a very difficult, involved process. You will find that after you broach the conversation, that it is given to you almost immediately, and the fact that I've had this conversation in many forums over 15 years and know that one plus of you is going to make $10,000 as a result of executing on this, for literally single digit minutes, blows my mind. And the incredible leverage of that advice is why I'm sort of part committed to it, and part committed to repeating it for the rest of my life.
Matt H: 00:58:11 That's an easy win I think, for a lot of people, and again, you don't get it unless you ask, so I think that's good advice. Well fantastic. Patrick, again, thank you so much. Was there anything else that you wanted to add, before we take off here?
Patrick M: 00:58:23 I think I'm pretty good with respect to the conversation we had today and thanks again for having me. I'm patio11 on Twitter, and also [email protected] if anyone has any questions. We are, as I mentioned earlier, hiring extremely aggressively with respect to remote engineers and a variety of other remote positions. Also, on site positions and let's see if I can do the list of 15 locations off the top of my head. Probably can't. San Francisco, Seattle, New York, Boston, Chicago, Japan, specifically Tokyo, Singapore, Dublin, Mexico City, et cetera, et cetera, et cetera.
Patrick M: 00:58:56 We're hiring all over the place, and we would very much like to make your acquaintance. We would likely be having another remote coffee in the not too distant future. If you follow me, patio11 on Twitter, or follow Stripe on Twitter, you can get the details of how to participate, when that happens. I would expect that to happen at roughly a monthly cadence from here on out.
Matt H: 00:59:14 That's awesome. We'll link to all those things, including the hiring pages that Stripe has up, and again, we're super thankful to you and to Stripe, to be able to talk to you today. And maybe at some point in the future, we'll be able to go into this one again, because I think there's a lot more than we can cover. And this is probably any one of our longest podcasts already, and I'm sure we have another three or four hours of content, if we really pulled it apart. So, thank you so much, Patrick, again, and hopefully I get to talk to you again soon.
Patrick M: 00:59:38 Thanks very much, and anyone, if I can ever help you out, I work for the internet, so drop me a line.
Matt H: 00:59:42 All right. Thank you, Patrick.
Matt H: 00:59:45 Thanks so much again for listening to the show. Be sure to check out weworkremotely.com for the latest remote jobs. And if you're looking to hire a remote worker, We Work Remotely is the fastest and easiest way to do so. As always, if you have someone we should talk to, any advice you have, or if you'd like to advertise on the podcast, please reach out to us at [email protected]. That's [email protected]. Thanks so much again for listening, and we'll talk to you next time.
Matt H: 00:00:15 The Remote Show is brought to you by We Work Remotely, the largest community of remote workers in the world. With over 220,000 unit uses per month, We Work Remotely is the most effective way to hire.
Matt H: 00:00:25 My guest on today's show is Patrick McKenzie or @patio11 on the internet. Patrick is a software engineer by trade. Has founded four different small software companies, and now works for Stripe. You all know about Stripe already, but the small version of it is that Stripe's mission is to increase the GDP of the internet. Patrick's role in Stripe is to increase the number of successful software companies on it. On a day to day basis, Patrick writes code, requirements documents, strategy memos, the Stripe Atlas Guides, which if you haven't tried that out, is absolutely awesome. And he also advises Stripe employees, partners, and users. If you're not already following him, you should do so. He's patio11 on Twitter and all other internet platforms. If you're not already using Stripe, I don't know what you're doing, but you should be using Stripe to process payments and build your business online.
Matt H: 00:01:13 Patrick, thanks so much for coming on the podcast, we really appreciate it.
Patrick M: 00:01:16 Thanks so much for having me.
Matt H: 00:01:17 Yeah, super excited to talk to you. Stripe has been one of those companies we've had our eye on, you and what you've been up to. And it's been lovely to watch your progress but yeah, I'm super excited about this and I hope you are, too.
Patrick M: 00:01:28 Yeah, always love talking to smart folks about interesting subjects.
Matt H: 00:01:32 For sure, for sure. So, where I like to start these conversations now, and I found it to be pretty interesting as a jumping off point, is what is it that you've been most proud of, that you've done over the last 12 months?
Patrick M: 00:01:44 Interesting. I've got a two part answer here, so I am a husband and father. I have a four year old daughter, and a two year old son, and so I think that strictly speaking, accurate answer is tempted to work the father thing for what it is worth, and knock on wood, hopefully that is going recently decently in the last 12 months. The more professionally relevant answer is, stretching my wings a little bit at Stripe, between projects that are more similar to the kinds that I've been doing over the last several years, and projects that are different in character.
Patrick M: 00:02:10 One of the things that we've been moving into quite actively is hiring remote engineers. Stripe had not historically been a company that had done that in a considered and scaled fashion, and then we looked at the data early this year and came to the conclusion that, oh, actually that small but mighty team of remote engineers that we had opportunistically hired over the years was extremely outperforming, relative to our various benchmarks for engineer performance. We said, "Wow, if that is working so well, let's have more of that."
Patrick M: 00:02:36 And so, we came to a kind of ambition plan to hire over a hundred remote engineers this year. And that's been an all hands on deck effort for a number of people in the company, myself included. And one of the things that I have been doing the last couple months is setting up a program to do what we call remote coffees, to basically give people the opportunity to help on a Zoom call with some Stripe engineers. Engineering managers hear a little bit about our engineering culture, our practices, what some of our projects that we're working on right now are, and sort of have the opportunities to need to meet their colleagues, before they get into a more formal, "Send us a resume, we will schedule a time for an interview," sort of hiring process.
Patrick M: 00:03:13 And that's been very successful, both from the perspective of meeting a lot of interesting people, being able to give the pitch to a lot of folks, and from the sort of business results' thing, that of what to do for our hiring funnel.
Matt H: 00:03:25 Wow, yeah. Yeah, there's a lot to unpack there, and I would love to get into that a little bit more. But, I think it would be valuable for our listeners just to take a step back, and to talk about your role at Stripe. Actually, I don't know how long specifically you've been working with Stripe. Sounds like you have a pretty unique role, and then I'd love to get into what that role specifically is, and if there is any specifics that you sort of spend your time on most. And why Stripe chose to bring you on, if you can, probably a difficult question to answer, but if you can answer that, I would love to get into that as well. So, what is it that you're doing at Stripe right now?
Patrick M: 00:03:56 Sure, so I've been at Strip about three years, next week. Prior to that, I ran small software businesses from here in Japan, for the last 10 or so years prior to that.
Patrick M: 00:04:06 So, what is my role at Stripe? It's a little bit squishy. There's pluses and minuses to it being a little bit squishy. The easiest thing that doesn't lose too much fidelity to the truth is that I'm a senior individual contributor on the marketing team. But even there, things get kind of fuzzy. So, the first two years that I worked at Stripe, I was working on the Stripe Atlas, which is one of our products that helps entrepreneurs worldwide help get set up on legal and financial rails, to start the company off on the right footing. And even when I was working primarily on Atlas, I was doing a little bit of everything, as one does when one is working on a project that's in the earliest stages.
Patrick M: 00:04:44 I was one of the relatively few people in the team that had an entrepreneurial background. Worked a little bit on the product side of things. If you were an early stage entrepreneur, what do you need, and what can we actually provide you. Worked quite a bit on writing of the Stripe Atlas Guides, or later causing to have written the Stripe Atlas Guides, which are ways to teach people the art and science of running early stage tech companies. I worked at sort of tier three customer service for a lot of Atlas users. We tried to establish the expectation that Stripe Atlas users could write [email protected] with basically any question about their business. And as long as we were legally able to answer it, we would try to answer it. And so we would get things from, "How do I raise investment?" To, "My co-founder and I are going through a break-up. I need a shoulder to lean on."
Patrick M: 00:05:29 And so that is not the typical sort of question that comes into a customer support channel for a company, and answering that was sometimes a bit challenging for us, and so tried A, pitch by not answering those sort of things, and B, kind of build up the process that would allow us to have a good user experience for that unboundly kind of question. Kick started the Stripe Atlas community, which is now run by my colleague, Matt Richmond, and just tried to pitch in on a lot of projects across Stripe. The current rescoped marketing role, I continue to pitch in on a lot of projects, including as we talked about, the recruiting thing with remote engineering.
Matt H: 00:06:02 It sounds like the role that you're in would be only doable by somebody like yourself, so I guess, was it a role that they were specifically looking for, or did the executive team at Stripe know you, and know what your experience was, and then sort of created something around your skill set, assuming that you could of course, contribute in a positive way to Stripe? Was there one way, one process that they had for that, or was that just a job that was posted, I guess?
Patrick M: 00:06:27 I think there's a little of column A, a little of column B. So, Stripe knew at the point when Atlas is off the ground, that they wanted someone to do a lot of writing for the project that eventually became the Stripe Atlas Guides and they have the rough outline of okay, well there are subjects that entrepreneurs don't really understand that well when they start their entrepreneurial journey. Everything from marketing to sales, to bookkeeping, to how does one de-risk a product that you're building. And they wanted to be able to teach that at scale, and so freight find someone that could teach that at scale was, as far as I'm aware, an open job req with a nicely designed page and everything, prior to me being involved.
Patrick M: 00:07:06 And I was sort of a known quantity among a number of people on the internet, inclusive of folks that worked at Stripe at the time, in say early to mid-2016 where that conversation was swirling around internally, and so they reached out to me and asked me if I was interested. At the time, I was still the CEO of my last startup. So, it was said, "Well, flattered to be offered. If there was anyplace I would take a job, that would be Stripe. But, doing the CEO of a startup thing right now." And unfortunately the startup didn't end up working out so, I said, "Well, if you're willing to revisit that conversation, I'd be willing to have exactly one conversation with the company prior to trying to jump in, both feet," on what would have been my fifth or sixth software company at that point. And so went through a interview process and they liked what they heard, I liked what I heard, and so I've been here, mostly happily, for the last three years.
Matt H: 00:07:55 Yeah. So, with that, I would be curious to hear because I've posed to have been following Stripe as many people have, and it's been amazing to see sort of how the business has evolved, based on the core product, of course, payment processing and making that as easy as possible. And it seems like it's going more now into how can you add more value into building startups generally, and building online businesses as a whole. So, I would love to talk about sort of your interest in the Stripe platform, and prior to coming on, what really drew you in, and what got you excited about Stripe?
Patrick M: 00:08:26 Well, the line that I use is sort of an applause line. By the way, I suggest people, when you're interviewing for a position, have a few applause lines ready, because why not? A lot of companies will attempt to qualify us as to whether you're enthusiastic about the product and the mission, et cetera, et cetera, and my applause line, which is a thoroughly literal statement is that, "I fed my family out of a Stripe account for the last six years." Want to continue feeding my family, that would be great. But, I've been the customer, I've run a business online, and I had been using the payments product, since approximately let's see, Stripe came out in late 2010. I think I signed up for my Stripe account in early 2011, and had used that to run two of my businesses to decent at least, by my next petition, so levels of success.
Patrick M: 00:09:08 And the capabilities that it gave me as someone who is a first time entrepreneur for the first business, and not really connected to high quality entrepreneurial ecosystems were pretty amazing. I remember when I started my first software company way back in the day, back in 2006, actually blew 15-25% of my budget on faxing a paper contract internationally to one of the legacy payment providers, so that I could get set-up to take credit card payments, and then after going through, I want to say about two months of underwriting rigamarole with PayPal, got approved to take payments through PayPal, obviously while I work for a direct competitor these days, so I still say shout out to PayPal, they've empowered a lot of entrepreneurs worldwide and I'm extremely happy for their success, and the fact that they do have a pretty quality product in a lot of places.
Patrick M: 00:09:56 Anyhow, I started using Stripe. Stripe was amazing in a lot of ways back in 2011. Very, very clean APIs to integrate against. There was an easy integration story into people's own websites, which was a relative difficult integration story with most of the other providers until quite recently. And the quality of the dashboard experience was, had the impression from the first day that someone must be actually running a business on top of it because it does some things that really are not obvious requirements, but make life much easier for me.
Patrick M: 00:10:26 One, from back in the day, and I'm still impressed by this, is that if you go to the dashboard, and you go to the search box and type in the last four digits of somebody's credit card, which you'll often do in the course of supporting a customer who says, "Hey, I paid for it with a card with the last four of blah, blah, blah, and I didn't get my product, what happened?" If you type in the last four, it will immediately pull up the associated transaction. That is not a thing a PM would obviously come to the conclusion of, "This is something that my search bar needs to do without any further clarification," but that sort of sparkly attention to detail on the product, was a thing that majorly drew me to Stripe, both as a customer and then later as a prospect or an employee.
Matt H: 00:11:07 Yeah. That's, and now being a Stripe user ourselves, that attention to detail is certainly one of the things that I think keeps us happy, and I know keeps us happy and many others happy as well. So, it's very clear that there's a lot of thought that goes into all that kind of stuff, and it's the product, as good as it can be. So, super interesting piece there. Now, when you started at Stripe, was the concept of remote work, it sounds like there may have been some engineers that were working remotely at the time. It sounded like you have some experience as well working remotely. But that wasn't why they adopted, was that correct?
Patrick M: 00:11:41 I believe that runs correct. We've had engineers working remotely since almost the early days of Stripe. I want to say, 10 employees or so in, and there was no formal program, and it hadn't really been scaled to materiality. So I was working remotely for the Stripe Atlas team, which is based out of San Francisco. Well, I was working here in sunny Tokyo, and that was a not terribly common state of affairs back then. It is much more common these days, and we intend for it to become even more common in the future.
Matt H: 00:12:07 So, three was recently an article, I think written, or an announcement that you were looking for ... You were doing a widespread sort of hiring spree, specifically for remote work, and I guess in our mind, not having known that there was remote workers within Stripe already, it seemed like that was sort of the decision that was made at that point. But it doesn't sound like it was a one decision kind of, "This is what we're doing now." It sounded like it was more of a gradual process of coming to that conclusion. Does that sound about accurate?
Patrick M: 00:12:33 Yep. I think that a lot of major strategic initiatives are something which you sort of find yourself, I don't know, the frog boiling metaphor is not exactly the correct metaphor to use in this circumstance. You do something once by accident or happenstance, or because you're trying a portfolio strategy of new experiments that works out. You put more resources into the experiment. It continues working out, and at some point, the organization needs to make a decision of, from the large portfolio of experiments that someone in the organization is running it, at any given time. Which are the ones that the organization as an organism unto itself wants to very seriously dedicate some firepower behind.
Patrick M: 00:13:11 And by the early 2019, we had overwhelming conviction that remote work was the future of, going to play a material part of the future of engineering work, both at Stripe and the industry probably. And we were like, "Well, if we think all the savvy companies are going to be here in five years, our customers are going to be here within five years for the ones that aren't here already. We should certainly steal the market share, and tell that buyer remote team to understand this new and emerging organizational technology, that the industry will be building on in the next couple of years."
Matt H: 00:13:42 And obviously we are a huge proponent of that, and sort of the phenomenon that we've seen over the past, especially two years where this has become more and more popular. But it's quite rare for, well, I shouldn't say it's rare. But, it's more common for companies to start out as remote teams obviously, and it just, logistically easier. It's a broader talent pool to pull from, all that kind of good stuff. Less rent expense obviously, when it comes to having a physical, geographic HQ, but rarely do you see sort of a larger established company deciding that at one point, then this is something that they wanted to take on, and moving towards a fully or more distributed workforce in general.
Matt H: 00:14:15 What was that decision like internally, and in terms of when you did make that decision, what was the next step for you? Was it a matter of coming up with processes, procedures, things like that, or was it kind of building off of what you had already done, or what was that decision like and what was the aftermath of that decision for you internally?
Patrick M: 00:14:31 So, I think there were a number of things that happened. One was we had, had a number of engineers working on Stripe who had successfully worked as remote for a while. We put a person that was basically in charge of the remote initiative at Stripe. His name was [Adeeta 00:14:45], and he is our remote DRI, directly responsible individual. And I believe, my understanding is that he spent quite a bit of time interviewing the existing remotes, asking them what about their experience had been very positive, what mechanisms with respect to big picture thing like management, and little picture things like literally, "What is the kind of microphone that you use, are you happy with it? Tell me about the space that you do remote work from. Are you happy with it?"
Patrick M: 00:15:10 I believe he spent some time himself experimenting with lighting setups, to feel like he could participate fully in remote calls over Zoom, et cetera, et cetera. And so there was a bit if a research process internally. At the same time as the research process was running, there was also a sort of internal socialization/getting everyone on the same page around, "We are still the smallest company in the scheme of things, but we're not the smallest of small companies anymore," so there is a bit of righting a ship that has momentum behind it element going on, where for a number of years, we had been sort of lukewarm with respect to remotes organizationally, and we're saying, "Okay, we are going to make, not exactly 180 degree change with respect to that policy, but we are going to make a material change with respect to policies."
Patrick M: 00:15:53 So, communicate the desirability of that internally, make sure that, for example, it would be a bad thing if like our recruiting department learned, the fact that we were enthusiastically recruiting remote engineers when they woke up and read Hacker News that morning. And so talking to teams internally, talking to teams that had remotes. Asking what they had done to successfully integrate those remotes into the culture of those teams. Reviewing results from our company wide survey, with respect to ... We do a company wide survey twice a year to all employees, and sort of classifying results by remote versus non-remote. And seeing where the underlying issues still were. Seeing what we should prioritize for things to fix in the scope of the next six months or so, and then preparing for, one does not simply wave a magic wand and hire a hundred people.
Patrick M: 00:16:39 Among other things, you have to interview many, many more than a hundred people, and you also have to have more than a hundred open slots in the organization. And people who are definitely willing to have a remote colleague working in one of those open slots. And so there was a bit of a finding the right teams that were hiring folks, and that the internal communication norms that we thought that there first or second remote employee would have a very successful experience from the jump.
Matt H: 00:17:03 Yeah, so it sounds like the more deliberate approach to remote work, and has been, it's pretty early days for Stripe, it sounds like. That being said, it sounds like there's also enough time that has gone past, in terms of the remote teams, that you can pull some data out and you can make some conclusions as to what's working, what's not working. Is there one thing that you can point to, and again, this is a difficult question. Is there one thing you can point to, that has been a major pain point that you maybe didn't expect after the deliberate change to be a more remote team?
Patrick M: 00:17:30 I don't know if I would say this is something that I didn't expect, but one of the major challenges had just been the challenge of hiring at scale. Finding, if you work back from the way that funnel math works, to hire a hundred people, you want to interview some number of hundreds of people, which probably means having initial team screens with low of thousands of people. Which, requires engaging at some level, some higher thousands to low tens of thousands of people. And so just, identify 10,000 people in the world who would possibly be interested in working at Stripe is a non-trivial problem. And then making sure that both our existing hiring technologies port over to people that are the remote candidate pool, which is a different candidate pool than the ones rather that we hire for our outside positions, both in engineering and outside of engineering.
Patrick M: 00:18:18 And we are both attempting to grow rapidly on this, while also attempting to integrate the people that we are hiring, while also attempting to keep the wheels on the straight bus, and those sort of things are obvious challenges. But they don't stop being challenges for being obvious challenges.
Matt H: 00:18:34 Right. That makes sense. And I think you're in a unique position to be able to answer this question, because you've had some remote experience in the past, and it sounds like you've been remote for most of your time at Stripe. Have you noticed a deliberate, maybe not even a policy change, but a way of approaching the culture aspect of Stripe when it comes to remote teams, and it sounds like it's semi-distributed, so you do have an HQ, and there's also engineering teams outside of that, that are fully remote. Is there something within that sort of policy that you have that is getting out in front of the potential downsides of having a semi-distributed workforce, like having people that are in an office, and some people that aren't? Or is that not something that you've considered as an issue, or how do you approach that?
Patrick M: 00:19:15 I think that the situation has been getting quite a bit better over the last couple of years. One of the nice things about this being a formal initiative at Stripe to hire many more remotes, is that there is both a level of understanding that this is a thing that we're committing to, at the same time is the relative proportion of remotes, both organization wide and on particular sub-organizations like say, the engineering organization or any given team that has remotes on it. The proportion is going up and quite steeply. And so, there's no longer either the feeling or reality of being like the only remote on team, or having a unique position where you kind of have to advocate for the unique challenges of your position. The organization is getting better at anticipating your needs.
Patrick M: 00:19:56 Shout out to one person who shipped a particular thing at Stripe. I believe this engineer's a remote herself. She said that, "It was socially awkward when a meeting would be called, and people use the internal system to calendar up the meeting, and book a room for the meeting, and then not add a Zoom link to the meeting." And so as the remote, you would have to ping people on Slack saying, "Hey, I would like to attend this meeting as well, because I'm on the invitation, but I can't attend the meeting unless we make a Zoom room and dial the room into that Zoom link." And so we made a not too complicated bit of software to say, "Okay, if there are two plus people meeting at Stripe in a room, just assume that there needs to be a Zoom link open for remote joining that meeting." And so, now the onus isn't on remotes to say, "Hey, guys, we'd really love to be here. Please include me."
Patrick M: 00:20:45 Considering isolation, that's a little thing. Like it's a tiny stitch in the craw of the person that has to make that ask, perhaps a couple times a day. But like, a tiny stitch in the craw of somebody a couple times a day with respect to their core relationship with their co-workers, is not a tiny thing. Particularly when you aggregate it over hundreds of days, times hundreds of engineers. And so, removing that point of friction forever is a absurdly good use of our internal systems engineering time, right?
Patrick M: 00:21:12 And that's one of the things I love about working here, is that literally every engineer at the company can contribute to internal systems. My one patch that I can remember is making it possible to use digits in someone's internal user name, because I really, really wanted patio11, which is my user name that I've used forever. And at one point, that wasn't possible for technical reasons, so possible now. But yeah, the amortizing of the cost of an internal system thing over many hundreds of engineers in a similar situation gives you quite a bit of business impetus to do, whatever it is that is necessary to maximize the productivity of those people.
Matt H: 00:21:47 Yeah, you mentioned something there as well, that I think is important to touch on, and again, you would have a unique insight here. So, one of the big things obviously with remote work, and one of the downsides is, is that there is that level of isolation that I think is just a structural component of working remotely, obviously. And you don't have that ability to tap on people's shoulders if you want to chat about something outside of work, or even within work. So, is there something that you do individually, that helps with that isolation piece? Is there something you do to make sure that you aren't feeling that level of isolation within your workplace?
Patrick M: 00:22:15 So, if you don't mind, I'll answer it on the team level, prior to the individual level. One thing that I really appreciated that the Stripe Atlas team did when I was on it, and I believe this was spearheaded by our engineering manager, Alex. We'd had one or two people on the team that were remote, for the majority of the team's existence. There was a circumstance which caused us to hire several more remote employees in the moments, and Alex said, "It would be great if all of us achieved a sort of emotional understanding of what it is to be remote. So why don't we all as a team, do an experiment where we just work remotely for a week, and then we can understand what about our team communication arms, about our standing meeting schedule makes life difficult for our colleagues and fix those things. And also just have an emotional understanding of how does the water cooler relationship with co-workers work, when you will only be around the same water cooler for perhaps five or 10 days a year."
Patrick M: 00:23:09 So we ran that experiment, found out some things. There was a great deal of empathizing across team about that, and then made some changes as a result of it. What do I do in my personal life? I make a special effort to invite people to come out to Tokyo, just hosted a co-worker of mine here last week, and while he was in town, did a bit of both actual hands-on work, actual first time out to Tokyo, and a bit of taking him around for things like karaoke, which is both a standard Tokyo socializing activity, also a bit of a hobby of mine. Out to some of the restaurants in my neighborhood, et cetera, et cetera, to give him a slice of life of what I experience every day.
Patrick M: 00:23:47 Similarly, I try to get out to San Francisco when the majority of my colleagues are, as often as possible, to both experience the slice of life, and also to do the sort of hacking or monkey brain thing, with regards to your tribe is whoever you break bread with, right? So, even as a remote employee, it is extremely useful to be able to break bread with your team, as often in a year as you can manage it. There's some very micro tactical things that I've gotten out-sized results on. Sometimes team is just, do something to have a team outing together. Like in San Francisco, there's a bunch of people on the Stripe Atlas team who really like tapioca milk tea. I think it's usually called Boba tea in the United States.
Patrick M: 00:24:23 So, it's like, "I'll get Boba." And when the Atlas team gets Boba, I get Boba. Despite the fact that I can't physically consume with them. So, I go out to the neighborhood Boba shop here in Tokyo, and get a Boba, and then I take a picture of the Boba and send it into our Slack channel, just so everyone could feel that I'm virtually participating in that team bonding activity.
Matt H: 00:24:42 And going back to this, the organizational piece of it, and you mentioned that there was an initiative that you'd done, to make sure that everybody was aware of what it is to work remotely, but is there anything that's encouraged, in terms of daily activity that you have to sort of fight against that level of isolation that people feel on a daily basis?
Patrick M: 00:24:57 I think that we have a lot of autonomy with regards to how we interact with our co-workers and what team communication norms are. So, there is many teams that have different practices there. Some have a standard calendared, sort of like a meeting with no agenda where it's just 30 people in a room, don't talk about work at all, just have the substitute water cooler conversation. I haven't participated in that myself, but I think that, that plausibly it works for people, if it works for people. Some have a, they make a special effort on the team to encourage appropriate level of one to one meetings, just to maintain the team bonds. Some try to, in addition to our cross company meeting that we do once a year where we fly substantially everyone out to HQ, they try to do a meeting once a year where everyone goes to a "third location," to have an offsite and have the opportunity to both do some focus work together and renew acquaintances. So, various kinds of experiments with respect to that.
Patrick M: 00:25:52 I think establishing good, inclusive norms of communication with respect to remote employees is probably the most important thing for a company that is transitioning from a past where they didn't have that many remote employees, to a future where they will have lots. And that means, for example, making sure that important decisions are made in a way that people can participate in, made over Slack or a Zoom call, versus two people talking in the hallway. That important decisions are communicated in a way that people can see it, the decisions that are impacting their work have been made. Stripe had a sort of baked in advantage in that we communication groups in the company to send lots, and lots, and lots, and lots of email. Now, we've written about this online, but A, Stripe sends a lot of email internally, B, the super majority of that email is widely visible within the company.
Patrick M: 00:26:42 And so the fact that many of our big debates as a company were happening over email threads or in a shared Google document helped to have our early remote employees, and the ones that we're employing as the result of this initiatives be more included then in the counter factual world in which, if most of our decisions were made in meetings, then you can't actually be in the meeting, then that does not optimize for your ability to participate in that decision.
Patrick M: 00:27:07 I also think one of the challenges of remote work is the social nature of, when you are the only person calling into a room of 13 people who are all physically present in the room, you're in the meeting, but not really in the meeting. So, there is like a critical mass factor that helps with regard to that sort of thing. Also, it helps to acknowledge that there's a differential there that doesn't go away, even when it's 10 people in the room, and three people outside the room sort of factor. And it's one of the things where, if that is the distribution of your workforce, then you just have to acknowledge that it's a factor and either push the important decisions into places other than meetings or establish communication norms, such as that people understand that, oh, if there's a speed of light play between myself and someone whose opinion I value on this call, then put natural pauses in where we're speaking as such that, they can jump in with what they want to say.
Patrick M: 00:27:56 Or, people have other solutions like holding the talking stick, et cetera, et cetera. Haven't seen that work super well in any participate instantiation, but as the entire industry jumps on the remote train, I think that there will be many thousands of experiments around that. Some of them will bear fruit.
Matt H: 00:28:13 Yeah, no, I'm sure. I'm sure of that. One of the interesting things about watching this phenomenon play out is the technology that has popped up around some of the pain points that come up with remote work, and it's going to be an interesting thing to watch. But, it is also interesting to think about the fact that there are some things that are encroaching on the benefits of remote work, too, which so the nature of being able to put your head down, and work hard on a problem, and without being distracted. So, I'm hoping that there's this sort of a happy medium that gets met here with technology that improves, and efficiency of remote work, and yet doesn't encroach on some of the benefits of remote work, because it's a fine balance, I think.
Patrick M: 00:28:45 I think to the extent that inviting any group of people into your organization helps to bring the figurative DNA to practices, the culture, et cetera, into the organization, to the extent that we think that remote work is delivering on the promise of giving knowledge workers a way to deep focused work, like demonstrating to organizations that deep focused work is so valuable, that you should carve out space to protect it. It's a thing that is difficult to transition from, without a major catalyzing event behind it. But if the inclusion of remote workers is that major catalyzing event, possibly that there will be organizations that manage to leverage that across the entirety of their employee base.
Matt H: 00:29:22 Interesting thing that you mentioned a while back was, well and sort of indirectly I suppose, when we first started our conversation was, just the idea that it might be difficult to separate I suppose, work from time outside of work. So, I guess my question is, within Stripe, and I know that Stripe has a values output, and excellence is a really big part of your culture, how do you manage to make sure that people aren't overworking themselves, and aren't pushing themselves into a place where they're going to be burnt out and unproductive, and still maintain that level of excellence that you expect?
Patrick M: 00:29:50 So, starting from first principles, I don't think that the level of excellence requires overwork. In most cases, I think that overwork tends to cause people to perceive that their output is going up, but generally it decreases the absolute amount of output, and generally causes hits against the quality. And in most cases when we're making the trade-off, we prefer less work done at a higher quality, than more work done at sub-standard quality. We attempt to keep the quality part really high. There's talk about some of the cultures and practices that sustains that later, if you're interested in it.
Patrick M: 00:30:21 Towards the general question of how do we encourage people to draw the balance between work and other responsibilities in such fashion that they can do their best possible work while not dropping their other balls, super candidly, I wish I personally was better on this topic. We attempt to preserve a lot of autonomy for people, such that they're able to make whatever sensible trade-offs, given their particular stage in life. Their particular values, what they're optimizing for right now, et cetera, et cetera.
Patrick M: 00:30:48 There are some trade-offs you can make in remotes, with respect to scheduling flexibility, which are for a variety of reasons, just more difficult if you work in an office every day. It is relatively easy for me, as someone who works remotely, to take off an hour or two in the day, and just shift my schedule a little bit to do something like cover child care for my wife, or run an errand or two. That is more difficult if I was commuting to an office, just by the logistics of like, have to commute in, have to commute out. Have to commute in, have to commute out again. So, that sort of thing can, without doing a big change on the raw number of hours worked, or the amount of output created, create a not enough flexibility dividend with respect to your ability to meet your other commitments during that day.
Patrick M: 00:31:30 Part of it is, sustainability has to start from a culture, and it has to start from people up and down the organization modeling it as something that they truly value, and I think we have mixed results with respect to that. We're a high flying Silicon Valley company, have many hard charging individuals at it, and good for them. Making sure that we can support different work styles as well, is an important thing. Making sure that people feel recognized for the work that they get accomplished, rather than judged on the basis of whether their work style conforms with company normative work style, if that were a thing that existed, is important.
Patrick M: 00:32:05 I think also, there's probably transigent points in the life of a company where, what is it six people or 12 people together, there might very well be a company normative work style, where the right work style is the one that all of your co-workers would adopt, without consciously deciding to adopt it. But when you get to 600 people as the day I joined, or 2,000 people as of these days, the company will sort of, by necessity, have to adjust to the reality of that it has employees that have many different work styles, and we have offices in many different corners of the globe that have sort of very different professional cultures, or cultures with respect to work styles prevailing, and the sorts of folks who usually staff professional positions. And so some amount of adapt into that reality has to happen.
Matt H: 00:32:47 Yeah, no, that's interesting that you mention that the piece of the reality of having different offices, and even in different geographical locations. I hadn't really considered that, because I suppose I haven't really talked to very many other companies that are at your scale in terms of the number of people that are working for you. It sounds like as well, it's really up to the individual to come up with whatever system works best for them, and with the understanding that as long as the product or the output is up to the standard of Stripe, then that sort of is the way that is best suited for them, and that's fine. Is that sort of accurate, or do I have that wrong?
Patrick M: 00:33:15 So, I hoped there would be more support from their manager in their organization, than just saying it's up to the individual to figure things out. Ideally, we have some organizational understanding of what success looks like, and we can model success and have people choose from a variety of options available to them. This is different for different people, in different parts of the organization, and different for different jobs. But, in some jobs, there's sort of a constant cadence of, in sort of a user operations role, there might be relatively constant number of tickets that come in every day, and you do a relatively constant number of tickets every day, and that is what good execution looks like.
Patrick M: 00:33:51 In a job like engineering or design, or writing, you might be doing creative work. Creative work doesn't necessarily schedule in X units of output on Monday, and then X units of output on Tuesday, both because the business needs of the business don't schedule in that fashion, and also because the spirit is willing but the muse does not decide to come in for work that day. And so, you kind of have to adjust to that reality of the work, but hopefully you'll be doing it in the context of an organization that, "This is not the first time we have hired an engineer. We understand that productivity is not a constant, measured over every day, and we've adapted to that reality and adjusted in the context of a helpful, empowering culture, both among your colleagues and your management chain."
Matt H: 00:34:34 I'd be curious to know if there's something, because I was asked this question actually recently, and I didn't have a very good answer, so I'm hoping maybe you could help me out with it. If there's anything specific in the hiring process of let's say, in your case, in the engineering side of things. If there's any specific in terms of personal characteristics that you look for when you are hiring a remote engineer, versus hiring an in-house engineer, is there anything that jumps out at you, in terms of differences that you would look for? Or qualities that would make somebody a successful remote worker verus someone that wouldn't as much? Or, is that not something that really comes up as much?
Patrick M: 00:35:04 A thing that comes up sometimes with regards to early career professionals is that there is sort of a skill curve on learning how to work, and organizational technology, that we as a society have developed for papering over early career professionals lack of that skill specifically, is the office environment. The office environment kind of provides the sense of having someone looking over your shoulder, and sort of enforce discipline with regards to starting, and stopping, and maintaining a pace, and talking to colleagues on a particular cadence, et cetera, et cetera. That sort of enforced discipline does not happen so much, with respect to remote workers. And so you generally have to be at a higher point along the skill curve of core life skills for working at a professional company, and you have to be a little bit better with respect to self-discipline, and self-motivation. And also, I believe those are true and are likely to remain true over the next couple of years.
Patrick M: 00:35:58 In that transitionary state we find ourselves in, I think you also have a little bit more than an office based employee with respect to bearing the organizational burden of making sure conversations between you and people at, say headquarters or whatever office that you're communicating with most frequently, happen. You have to practically cause those conversations to happen, but for like core execution, have projects done for career growth. Hopefully, that will change over time, as we get better at integrating remote folks into the organization, but as a true statement of reality, in September of 2019, you kind of have to be proactive with regards to managing it yourself.
Patrick M: 00:36:33 And so, a combination of those things is both an important thing to assess for. Also, an important thing to level set with regards to candidates, there are people who really, really enjoy having someone who will check in with them regularly and make sure that they're on task, and provide that structure. And we should be up front with remote candidates that, "If you're expecting someone to spoonfeed structure for you, this role at this time, in this company, might not be a great fit for your interests." Conversely, if you are someone who has run a business before, or is just super motivated, and is capable of providing that organizational structure for yourself, then that is great because you very heavily ticked one of the boxes of what we think will likely be a requirement for being successful in doing this.
Matt H: 00:37:18 Yeah, it's always an interesting one. Like I said, I didn't have a very good answer for it, but it seems like it's just one of those things where you just have to be better in a lot of different areas, and not specifically one characteristic or one personality trait that allows for quality remote workers. You're just going to have to be better in a lot of different ways, and maybe that's the answer.
Patrick M: 00:37:35 I think that there's also a component with respect to, the dominant word in remote work is work. It isn't remote. There's no one characteristic, or one skill, or one personality trait that makes a good engineer. People spike differently in different places with that, and even with an extreme level of, for example, core technical acumen with regards to Kubernetes or whatever your tech stack of choice is. You would probably not be all that successful in many jobs, and certainly wouldn't be successful at Stripe, without quite a bit of communication ability. At Strip, in particular, there is a heavy emphasis on written communication, and so people who do well in writing documents, whether it's design documents or arguments for where the business should go, or updates to the company after shipping something, people who do all of that do well. And people who have difficulty expressing themselves in writing, Stripe would be a really difficult company to work for.
Patrick M: 00:38:28 And in a similar fashion, if you're working remote at Stripe or another company, there's some blended collection of skills that are sort of specific to the remote nature of it. There's a larger blended collection of skills that somehow can balance your effectiveness within the team that you're working on, the role that you're working on, the organization that you're working with, and you kind of have to bring a portfolio with enough depth within the right places, and enough breadth overall to be successful.
Matt H: 00:38:54 Yeah, no, I know it's a quite interesting subject, and I hope that it becomes clear for a lot of different people, because I think it's an important one. The one I want to talk to you to, and this might be a difficult question to answer, because projections in general are difficult, but how do you see remote work going within Stripe? Is this something that you're looking to test for, and then maybe expand to other portions of the company? Or, how do you see the future of remote work within Stripe?
Patrick M: 00:39:18 I think we don't have any major announcements to make with respect to this, other than the one that we made earlier this year. From my limited point of view with respect to the outcomes of this experiment/initiative, all speed ahead with regards to remote work. We truly believe deeply, as an organization, at many different levels in the organization, that remote has not been a standard part of all software companies, or all savvy employers of engineering talent in the software, tech, and related industries, over the course of the last 10 years. And we believe strongly that, that will change. My internal time frame for this, probably five years from now, it will be about as common as GIT is, and GIT is pretty darn common at this point. GIT wasn't a veracity of one either, but I think that all the savvy teams in savvy organizations are going to have 10s of percent of their engineering pool, or engineering teams rather work remotely.
Patrick M: 00:40:13 And I say engineering just because I am engineering by trade, and by sort of self-identification. Even if I work on the marketing team, and don't shut code that much anymore, but I think this is probably true of many other techs that work as well. And so, with increasing adoption of this by both our industry, and a variety of other industries, with the technology for it getting better, and sort of organizational comfort levels at this getting higher, as more and more companies experiment with it and see success, and develop these systems and processes and technology that will allow them to achieve higher levels of success in the future, I think the adoption curve is going to start going upwards in a material fashion. And we are trying to race to be there before everybody else is.
Matt H: 00:40:57 Yeah, I know it's great to see Stripe on the wagon for sure, and we're excited about it and excited to see where you go with it. So, I wanted to take another sort of step back here, and I want to talk a little bit about your writing. I'm glad that you mentioned that is one of the core parts of Stripe culture, and what's important to Stripe is writing, and it seems very clear that, that's the case for you. And being a Twitter follower of yours, it's I'm always fascinated by the scope of your interest, I suppose, and just the what the different avenues you go down, and how deep you can go, and it's really just quite something to witness and to see. It's really quite something, so anybody out there who hasn't, isn't following Patrick yet, we'll link to his Twitter feed, and you should start doing so immediately, because it's really amazing.
Matt H: 00:41:48 But I was curious to know, if there's something that you, if there's like a scope of what you find interesting, or what you set out to explore, and then you go explore that thing, or how is it you go about just what you find interesting? What you do deep dives on, I guess is my question. What do you decide to do, to dive deep on in terms of your research?
Patrick M: 00:42:11 Sure, so it's an interesting question. I have very broad intellectual interests, and one of my hobbies is picking up more obscure ones, so generally attempt to go very broad on things, and then occasionally go very deep when the spirit moves me. Sometimes, it's because I'd been capable of diving deep on a subject because there's some actual legitimate business need to understand that subject very well. Candidly, what happens more frequently with me is that, I am exposed to something by business sort of life. The original reason I got into engineering was that, well the original, original reason was that I wanted to play more video games, and writing them would be a great way to have them, but the thing that kept me in the field is that I loved tearing apart complex systems and seeing how they tick.
Patrick M: 00:42:55 And so, when I'm exposed in a material fashion to one of those systems that just floats around our ambient environment, but that we never think of in a very detailed fashion, insurance, or how do stock exchanges work, or how does money move around the global economy, I have a tendency to sink my teeth into something and just not let it go for a while. There are generally being two ways to get information out of this world, other than discovering it oneself. One is reading what other people have written. The other is talking to other people. I'm a little bit shy, so I often end up reading in preference to talking to people. There is a surprising amount of information on Google these days, about basically any subjects that you could possible want to read about.
Patrick M: 00:43:36 So, if you want to dive down a rabbit hole of what the consumer credit reporting regulation looks like in the United States, and read the Fair Debt Collection Practices Act, and the Fair Credit Reporting Act, and the various regulatory state machines around those two, that piece of legislation, and how they interact with the credit reporting agencies, and I feel like I'm getting a little bit off the beaten path, but this is sort of the way my brain works, in that subject seized my interest in 2004 and wouldn't let me go for a few years. And go figure, it turns out that if you end up working at a company that processes credit cards for a living, understanding the credit card ecosystem can be useful. But, yeah, sometimes the idea grips me and just won't let me go for a while.
Matt H: 00:44:15 Yeah, and I've learned so much from you, just from following you on Twitter, so thank you for being so public about that. I appreciate that, and I know many others do as well.
Patrick M: 00:44:22 Thanks very much. I'm patio11 on Twitter if anyone wants to follow me, and also [email protected], if you ever want to send me an email.
Matt H: 00:44:28 Yeah. No, we will definitely link to those things. I'm curious if, writing publicly about the things that you're interested in, what does that, outside of just your own distilling your thought down into whatever Twitter is limiting you to at the time, is there any other sort of major benefit you find in being so vocal and public with the way you write, and what you write, and how you write, I guess?
Patrick M: 00:44:51 Oh, goodness. You could do an entire podcast entirely on that, and the various benefits of having a body of work that are publicly available. I almost certainly would not have my job at Stripe, but for the fact that I wrote several million words on the internet. That's the situation from someone who is in a small town in central Japan at the time. Life would not naturally have exposed me to people at high flying startups in San Francisco, or the Silicon Valley, Bay Area. But, the internet's the love link for us, and if you write interesting things on interesting topics, you can eventually come to the attention of people who might be looking for someone to write, or do engineering, or design, et cetera, et cetera, in places that you wouldn't naturally be. Your name will get brought up in rooms that you wouldn't be in, et cetera, et cetera. So, it is a huge friend catcher, if anyone doesn't follow the Texting podcast, a recommendation for them.
Patrick M: 00:45:42 But, one of the most useful things that I learned from them was this concept of a luck surface area, where the amount of luck that you have in your career, is proportionate to the product of the depth of how much you help people, and the breadth of how much you tell about it. And the writing publicly is one of the highest leveraged things you can do, with regards to increasing that breadth factor, without having to do, "more work." I'd say that in scare quotes because in five million words, or whatever my odometer is up to, they didn't write themselves for free. But, much of both the actual impact I've had with my career, and the benefits that have accrued to my family and myself as a result of my career, are directly downstream of having written a lot.
Matt H: 00:46:28 Yeah, that's fascinating, and I haven't heard it framed in those terms, but I think one of the reasons that you've mentioned is just being helpful, and I've mentioned it in a few other podcasts, but I think being helpful is one of the most underrated skills someone can have, especially when they're starting out their career as, "How do I find somebody that I admire, that I want to work for, and how do I help them?" Is, I think a really easy, in the first principles, starting point to go.
Patrick M: 00:46:51 Mind if I give one more plus on the writing topic, that is less relevant to personal career interests and more relevant to the organizational case for this?
Matt H: 00:47:00 Please do, yeah, please.
Patrick M: 00:47:01 Sure. So, even at Stripe, a company that has a very strong writing culture, I think we internally and externally have not nearly hit the point of diminishing the returns with regards to how much we write. Stripe is growing at a stupendous rate every year, and for the sake of argument, I'll asset that there exists some companies in the world that are growing at 2X per year, in terms of the most relevancy to this discussion and employee count. And a intimidating and un-escapable effect of the math is that, if a company sustains 2X growth in employee count per year, that the first year you work at that company, half of your colleagues will have less than one year of tenure. The second year you work at that company, half of your colleagues will have less than one year of tenure, and the third year you work at that company, half of your colleagues will have less than one year of tenure.
Patrick M: 00:47:46 And this is really, really not the way that organizations are, "designed to work." You have to pour an incredible amount of effort into educating people about both what you do, how you get it done at your particular organization, and the why. Like, "Why was the decision made?" Because there will be people enacting the company ritual or policy, or something three years from now, who were very much not in the room, and you need to kind of have to institutional memory of why you did a thing that way, the both so that those folks can make a determination of, "Have circumstances changed? Should we change this?" Or rather than just keeping it a stuff policy or ritual in all time, because it sounded great to the three people who happened to be in that conference room several years ago, in a country far, far away from us.
Patrick M: 00:48:38 Or, "What is the best possible way among our execution options on the table, to execute on the intents of this policy?" And doing that in a scalable fashion, I think writing is probably the most scalable way to do it, because you can write down your thinking once, and have it read for literally hundreds of years. And the alternative, and something that happens at every organization, I think, is that people maintain sort of like an aural lore of the company, but particularly in a quickly scaling company. The aural lore has some limitations.
Patrick M: 00:49:10 You have to keep the ... because I've played too much World of Warcraft, and because I intentionally want to hang a bow on this topic and say how absurd it is, like if you had an explicit title at your day job of Lower Master, where these are the folks of a wizened countenance, who have been here since before the flood, and understand the rationale for all the decisions, you would literally need that to be pretty much an explicit part of somebody's job, and to have a lot of Lower Masters and some redund Senior Lower Masters, and maybe even some sort of like charting strategy, of which information sits in which Lower Master's head, such that you don't have the bus factor problem with regards to Lower Master availability, and consistency, perch intolerance, et cetera, et cetera.
Patrick M: 00:49:58 So, it's distributed systems problem to maintain your organizational memory, if you don't write things down. If you do write things down, computers are great about preserving documents, so as far as they exist. Peaches and cream, it'll be amazing. So, organize yourself to write much, much more down than you would ordinarily. There are huge, huge benefits to doing so. I perceive Stripe as probably one of the companies in the world that has gotten the most benefit out of the incredible amount of writing we do internally. I think we could probably almost literally increase it by 10X, and still not hit the machine returns.
Patrick M: 00:50:32 I'm doing my gut check of, "Do you really believe that, or does it just sound like something that has the ring of being plausible, and would sound good on a podcast?" And no, I believe my considered second and third thoughts, had to cherry press it, my second and third thoughts are, "No, I really believe it. I could write 10 times as many documents as I do, and would probably have a far greater than 10X increase in effectiveness." Penciling down note to self, "Write more this year."
Matt H: 00:50:59 Wow, that's fascinating, I'm glad that you brought that up. Is there anything that Stripe does internally to make sure that people are quality writers, or maybe improve in their writing skills, or is this something that you guys hire for right away, and if you're not a good writer, then you're kind of not even considered? Is there anything that you do in that sort of realm at all?
Patrick M: 00:51:17 We do definitely assess for writing ability, in that many of our hiring loops. Outside that, I don't believe writing ability is a static thing. I think you can definitely improve if you have deliberate practice. We do attempt to support our professional growth as writers. But candidly, this is one of those areas where we don't have a decision that we're fully happy with. If I had a magic button that could subjectively double the writing skill of a colleague, I would be doing basically nothing out there but mashing that magic button with respect to any member of Stripe I could point it at. Also, if I had that magic button, I should probably found a company to sell that magic button to Stripe and other people. But, that one is what it is.
Patrick M: 00:51:57 I think writing is much like coding. Just a such a highly leveraged skill in so many organizations and so many industries, that we as a society will because never be as good at it as we want to be.
Matt H: 00:52:10 Wow. Yeah, that's really interesting. I've heard that, and not with the same degree I think, as what you just said, but yeah, I know that in our side, obviously writing, and communication in written form is super, super important. So, that's a good wake-up call for people that are out there listening to go brush up on your skills, and make sure that you're getting feedback on all things that you write down, because that's the only way of, you're going to get better. So, yeah, I think it's a really important one. I'm glad that you brought it up.
Matt H: 00:52:35 Patrick, you've been so generous with your time, I don't want to take up too, too much of it, and you're a busy man, so I'll keep this relatively short. But, I do have a couple of closing questions here for you, if that's okay. The first closing question here is, hypothetically, you can't go on your computer or use your phone for one year. How do you spend most of your time? Maybe I'll manipulate that question a little bit and ask, if you didn't work in tech, where do you think you would work?
Patrick M: 00:52:58 Interesting question there. That would be extremely difficult to me, as my wife can definitely attest to. So, because these intellectual interests sometimes grab me and don't let me go. I did have an interest in anti-fraud early in my career, which is plausibly something that could have got me working in the financial industry as an underwriter or a fraud prevention expert, et cetera, et cetera. And although the financial industry and the tech industry are, they will have an increasing convergence over the next couple of years, I believe.
Patrick M: 00:53:26 The thing I really wanted early in my life, was just get paid for living a life of the mind. And so I thought, "Oh, I'll get a PhD, and then become a university professor and teach classes, and just think a lot, and write down interesting thoughts." And then as I got more exposed to academia, it turns out that's not actually what university professors get paid for. Principally, they get paid for filing out grant applications. One of the things that I've like about my somewhat oddly shaped career in tech, is that both as a business owner and now working at Stripe, I really do sort of get paid for living the life of the mind, and so, if there are other plausible ways to achieve that outside of the tech industry, might end up tempted to walk down one of them.
Matt H: 00:54:08 That's a great answer. So, my next question here, is what is your biggest pet peeve in business and in tech?
Patrick M: 00:54:18 I think people over-optimize in the direction of being able to regurgitate "wisdom," rather than being able to seek knowledge. And so there are many, many deep structural reasons why this is the case, but what are the best practices, and memorize them, and then apply them mindlessly. Or, what is the narrative that is presented in high status publications, be it media or some other source of news, information, opinion, advice, et cetera, rather than making considered decisions as to what things you'll get good at, and what getting good at them looks like.
Patrick M: 00:54:55 I believe that most folks don't do enough experimentation with regards to either their core beliefs about their core comparative advantage. Also, probably don't do enough experimentation on just testing the true value of propositions that are really important to them, and it sort of pains me when folks are, I'd say, intellectually uncurious with respect to things that are directly relevant to their interests. I buy that as someone that has a five minute budget of time and attention, you can't experimentally investigate every claim in the world, but I think that most people would do better to subject more claims to more scrutiny, than they do in their resting case in life.
Matt H: 00:55:32 Yeah, that's a really good one. Do you think that, that's changed since you've been working in tech, or is that something that's sort of been constant in your opinion?
Patrick M: 00:55:40 I think that this is an issue that I have more with the human condition, rather than with the tech industry, per se. There is sort of a meme in the tech industry of being very scientific with regards to approaches. Sometimes, I believe that is a meme that propagates because the meme floaters are self-conceptions, more than being an accurate description of how we work. But, I think there is some non-zero degree of truth with respect to it. It would support us titrating up with the amount of science that we have. Also, by the way, to throw myself under the bus there, that use of titrate is a very considered use of the word titrate, because it sounds scientific, even though I'm using it in a metaphorical sense there. And I do that automatically to score applause points with engineers. And I know that it automatically gets me sort of unearned applause from engineers, but yet do it because it is instrumentally effective. So, there is no level at which this is not a problem.
Matt H: 00:56:33 Yeah, I love that question. Really, really interesting answer. So, I have one more question for you before I let you go, Patrick, and again, thank you so much for taking the time. The last question is, what is the best advice you've ever been given?
Patrick M: 00:56:45 Instrumentally, the most important advice I was ever given, and, which I repeat at any opportunity is to charge more. I believe that most people in tech, both those that are selling products, and those that are selling their services to companies have an anchoring of the worth of those products and services, far below their true worth. And that, this is so widespread and the delta between the true worth that are sort of implicit emotional comfort levels, and the anchorings is so wide, such that I can give people the advice, "Whatever you're charging, just charge more to that number," and that ends up being value maximizing advice for more than 98% of the people that I tell it to. Such that, I don't caveat it at all.
Patrick M: 00:57:28 There are people listening to the podcast today, who you are currently wondering, "Am I ready to get a raise?" And the answer is, you have been ready since the day you were first employed in this job, and you should work up the courage to ask to it. You are currently modeling that as being a very difficult, involved process. You will find that after you broach the conversation, that it is given to you almost immediately, and the fact that I've had this conversation in many forums over 15 years and know that one plus of you is going to make $10,000 as a result of executing on this, for literally single digit minutes, blows my mind. And the incredible leverage of that advice is why I'm sort of part committed to it, and part committed to repeating it for the rest of my life.
Matt H: 00:58:11 That's an easy win I think, for a lot of people, and again, you don't get it unless you ask, so I think that's good advice. Well fantastic. Patrick, again, thank you so much. Was there anything else that you wanted to add, before we take off here?
Patrick M: 00:58:23 I think I'm pretty good with respect to the conversation we had today and thanks again for having me. I'm patio11 on Twitter, and also [email protected] if anyone has any questions. We are, as I mentioned earlier, hiring extremely aggressively with respect to remote engineers and a variety of other remote positions. Also, on site positions and let's see if I can do the list of 15 locations off the top of my head. Probably can't. San Francisco, Seattle, New York, Boston, Chicago, Japan, specifically Tokyo, Singapore, Dublin, Mexico City, et cetera, et cetera, et cetera.
Patrick M: 00:58:56 We're hiring all over the place, and we would very much like to make your acquaintance. We would likely be having another remote coffee in the not too distant future. If you follow me, patio11 on Twitter, or follow Stripe on Twitter, you can get the details of how to participate, when that happens. I would expect that to happen at roughly a monthly cadence from here on out.
Matt H: 00:59:14 That's awesome. We'll link to all those things, including the hiring pages that Stripe has up, and again, we're super thankful to you and to Stripe, to be able to talk to you today. And maybe at some point in the future, we'll be able to go into this one again, because I think there's a lot more than we can cover. And this is probably any one of our longest podcasts already, and I'm sure we have another three or four hours of content, if we really pulled it apart. So, thank you so much, Patrick, again, and hopefully I get to talk to you again soon.
Patrick M: 00:59:38 Thanks very much, and anyone, if I can ever help you out, I work for the internet, so drop me a line.
Matt H: 00:59:42 All right. Thank you, Patrick.
Matt H: 00:59:45 Thanks so much again for listening to the show. Be sure to check out weworkremotely.com for the latest remote jobs. And if you're looking to hire a remote worker, We Work Remotely is the fastest and easiest way to do so. As always, if you have someone we should talk to, any advice you have, or if you'd like to advertise on the podcast, please reach out to us at [email protected]. That's [email protected]. Thanks so much again for listening, and we'll talk to you next time.
← Back