The Peterman Pod - Ex-Stripe CTO on What Grew His Career, Hiring Without Leetcode, Coding as a Leader (Career Story)

Episode Date: August 29, 2025

David Singleton was the CTO at Stripe for 7 years before he left to start /dev/agents. Prior to Stripe, he grew from a junior engineer to a VP at Google. I recently asked him about everything he knows about career growth and being an excellent engineering leader. We discussed how Stripe hired at scale without Leetcode, why he thinks all engineering leaders should write code, the book that impacted his career most and many more topics.Episode Links:• Transcript• Youtube• AppleTimestamps:(00:00:00) Intro(00:00:56) Before Google(00:06:34) Joining Google(00:12:56) Deciding to try management(00:24:15) How to decide on EM vs IC(00:28:58) Biggest gap in managing managers(00:34:21) The difference between VP and Senior EM(00:37:43) How to communicate well(00:46:14) How managers can scale themselves(00:51:17) How to build a new engineering site(01:01:21) What kept him at Google(01:03:57) The story behind joining Stripe(01:12:34) Comparing and contrasting cultures(01:20:55) How to set culture(01:29:25) Is Stripe too reliable?(01:33:48) Hiring at scale without Leetcode(01:38:06) Lessons learned working with Stripe's leadership(01:40:31) Why leave Stripe(01:44:55) How his AI startup plans to compete(01:48:46) Career reflections, regrets, what went well(01:54:03) Top book and habit that impacted his career(01:57:40) Advice for younger self(01:59:04) OutroWhere to find David:• If you are a builder: https://sdsa.ai/build• If you are very excited about what they are building and would consider joining his talent dense team, you can email David here: [e-mail]• X/Twitter: https://x.com/dps• LinkedIn: https://www.linkedin.com/in/davidpsingleton/• Threads: https://www.threads.com/@davidsingletonWhere to find Ryan:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@petermanpodThis episode was produced with the help of SF Podcast Studio: https://www.sfpodcast.studio/

Teams that are perfectly happy are rarely performing at their very best potential. This is David Singleton. He grew from a junior engineer to a VP at Google, which is four levels higher than staff. You grew to a VP at Google, so I can't imagine you were still taking on feature work when you're... Funny story. Really? When I was made a director at Google, they said, hey, the secret is... Later, he became the CTO of Stripe and explained how they hire without leak code.

The industry was still doing a lot of whiteboard interviews. That's actually not a great way of simulating what it's like to see an engineer do work. We also chatted about the AI startup. He left Stripe 4. How do you see yourself out competing big names like OpenAI who probably have interested in this exact thing? I'm going to choose to answer this question differently. So here's the full episode. The first thing I wanted to ask you is, how did you get into programming to begin with?

Like many people, I got into computer. as a kid. A computer came into our household for my parents' business, and I ended up teaching myself to code. I think a lot of kids back then, this is like the late 80s, early 90s, a lot of kids were learning to code to write computer games. I coded bespoke business software for my parents' business. I built them an invoicing system. But it was actually like really cool, mostly because I learned that I could do this like really creative thing with this piece of technology. And I was always really inquisitive about how things worked. And then the thing that I'd built, ended up being pretty impactful to our family in that before that my parents did all of their

invoice tabulation for their tax returns manually. So my sister and I would notice that like once a quarter they get super grumpy and it's because they were up all night like tabulating their accounts. And once you built the invoicing software, you could press a button and it came out of the printer. So it kind of showed me that this thing could have a big impact for people. And it's been the impact of building software for people that really kind of gave me the bug to then go on and study computer science and get into the industry. But yeah, that's how it all started. After you graduated from college, I understand that the first role that you had was at Symbian. Can you tell me the story about working at Symbian? Yeah. Well, so first of all, it's a funny story how I ended up there. I'm

originally from Northern Ireland. I planned to go back there to join a software company in Belfast, which is my hometown. But it was an internet boom company and unfortunately kind of went under as the internet bust happened. So there I was in Cambridge and England. And I had to find a job at pretty short notice. Some folks from Symbion visited, and I just thought these are really lovely people, and so I decided to apply for the job there. I was incredibly lucky because for those that don't know it, Symbian built smartphone, mobile phone operating system software before smartphones were a thing. So we're talking here like 2001. And I ended up going there because I like the people, but then as soon as I arrived, I realized, wow, we are working on technology that we all believe,

even I certainly believed was going to have a profound impact on how people used computers at scale. It was obvious that it was inevitable that we were all going to have these little smart computers in our pockets. But we were inventing stuff there that today you and I might take for granted, but we just really had to figure out what you could do. I remember whiteboards where we were drawing what turn-by-turn directions in maps would look like when there were GPS chips in the handsets, which we knew was coming. And we were trying to figure out what's the right way to plug that into the operating system. So super, super fortunate to end up there and find that I was super passionate about what we were doing. I started off as a software engineer, so I built some core parts of the Bluetooth stack on the Simbion OS and also some of the PC Connect software. But then the final couple of years I spent at Simbian, I think were actually pretty formative for me in terms of what came next.

So I went from being a, you know, I see software engineer working in the core to doing this role that we called technical consultant. So I was still an individual contributor, software engineer, but I was assigned to teams from handset manufacturers who were turning the Symbion OS into actual handsets, into actual products. So Symbion arrived as a kind of bag of bits, and you had to put your own UI on top and build a whole bunch of things. So it was actually quite a complex project. So I ended up being the technical lead on the Symbian side for essentially the same project executed again and again and again by teams at different companies. So I work with companies like

Panasonic in the US, Samsung in both Korea and China, Nokia in Finland, etc., etc. And the cool thing is the right way for me to help on each of those projects ended up being quite different. For one of the teams, I was helping them set up source control for the first time. For another one of the teams, I was helping them like debug some graphics thing that they were having problems with. But because I saw how the culture of a software engineering team in different companies impacted how things got built really directly, very early in my career. It gave me this like almost like intellectual pursuit of like, wow, like how you organize teams and how you set them up to have impact can make a profound difference on what the end result is. Just to give you a flavor of that, I'm sure that

these companies work completely differently today, but, you know, Samsung back then, they ran very, very, very small teams. And as I understand it, they would give multiple teams essentially the same mission, same project. And then the team that was finished first was the one that actually got to ship. So imagine the kind of incentive structure that that sets up. Whereas at Nokia, it probably won't surprise you to hear that everything was actually planned in much more intricate detail. Things were definitely much more predictable, but everything took significantly longer. And yeah, I just kind of really became a bit of a geek for thinking not only about what is this software we're writing, but hire teams organized to get it done. Would you say that that role was

to the popular role of forward deployed engineer in the industry today? Yeah, actually, it's a great question. I haven't thought about it that way, but I think that is a really good observation. It was the case that I and people in the same role were tasked with not only helping the customers integrate the thing in their own product, but also to bring back lots of insights and questions and so forth from the customers to inform our future roadmap at Symbion. And so, yeah, I guess it was. We didn't call it that back then, and I think I hadn't even made the connection

until now. But yeah, it's a pretty interesting model. For what it's worth, you know, I was pretty young at that time. I really enjoyed it. I got to travel all over the world. And it was a very rewarding period of my career, even though I probably wouldn't want to do that right now. So you talked about the future companies. And I know we're talking about Google. We're talking about Stripe. I'd love to hear the story about how you got into working at Google. Yeah. So I was living in London at the time, working for Symbien. And this was immediately post Google's IPO. And I guess Google, like we had already recognized at Symbion, realized that smartphones were going to be very important for how people accessed services online. And believe it or

not, London at the time was recognized globally as like a center of excellence in the mobile industry, because there were so many people working at companies like Symbion there. So Google decided to open an engineering office. It had a specific focus on mobile in the early days. And I guess I attended a recruiting event and interviewed. It was a pretty tough process interviewing at Google back then. I did some interviews in London. I flew to California. It was the first time I'd ever been to California as part of that interview process. But what I realized was just through the quality of people I was meeting, but also the energy at the company, I was immediately sure that this is where I needed to be next in my career. And for what it's worth, I never really imagined. I ended up staying at Google for

nearly 12 years. I never imagined staying that long. I thought what I was going to do was go to Google and learn a lot, learn about how you built distributed systems at scale, learn about how, you know, the very best engineering was being done in the industry so I could take it somewhere else. But I ended up staying at Google so long because every 18 months or two years, I'd pick up my head and think about what have I been doing here and realize I've learned a tremendous amount, so I just keep staying because I was learning so much. I've noticed that in a lot of people who, have had a lot of career success and stay at one place for a while, they don't stay there out of complacency. They're constantly actually almost trying to leave, but that place is treating them

so well that they end up staying rather than job hopping. Yeah, I mean, at Google, I probably did six different jobs. Like, you look at them and say that is a very different job with all with very gradual transitions between them. But yeah, the dynamic range of skills that I learned there was incredibly useful and incredibly diverse. In the very early days, it was just an amazing place to be. Incredible talent density. Everyone was really driven to have an impact. And everyone was given a lot of autonomy. So back then, the 20% culture at Google was really true. So I definitely had a thing that my own manager and team were expecting me to get done. But I was really welcomed to pick up a lot of other things, as long as I could get the core done. And I really went to time with that.

So I looked at it as this is my opportunity to learn, and I'm going to go find all the opportunities to learn as much as I can. And I think that's actually why I ended up being kind of given more and more things to do at Google. One example of that is I was working on a feature for Google Maps for Mobile at the time. This is before Android, to be clear. So I was working on a feature for Google Maps for Mobile. And mobile search was growing pretty rapidly. And one thing that I noticed was that every time anyone on a mobile phone would go to Google.com, we would immediately then redirect them to Google.com slash M.

And back then, mobile network run trip times were super long, like multiple seconds, two and a half seconds maybe to follow one redirect. And we were subjecting every mobile user to that. I remember talking to my co-works and being like, this is bonkers, right? We were wasting 2.5 seconds of users' time every time they access this page. And everyone's like, oh, it's kind of too hard to fix that. It's really complicated. It's in this kind of front-end infrastructure that no one really on this team knows how to

work with. I was just like pretty determined that this didn't make sense and it's just software, so we must be able to figure it out. And it was really because I wanted to learn about how that infrastructure worked and I went and chased that. And eventually like merged a change in the main Google Web server and did a whole bunch of stuff on that front end infrastructure to remove that redirect. And that ultimately ended up saving, I did this calculation, like something like 70 years of user time every year or something like that and was pretty impactful. It, I think, had a noticeable impact on usage as well. And you get a real bug for those things.

Like being able to just follow your nose to learn, take agency to do stuff that matters. And I find that just really fun and a great environment to be in and to continue to learn. The thing that motivated you in that agency that worked out for your career, was that the perceived impact that you would have? Or was that the technical curiosity? That's a good question. I'm sure that initially, early in my career, it was technical curiosity. I honestly had no real sense of just how many people we were impacting in the work I was doing at Google, and it was a lot. But I was very technically curious.

And then I worked with a product manager, a good friend of mine still called Gumi, and he then started putting all the product metrics in terms that everyone could understand. So he's Icelandic. And I remember one day the product we were working on, he said, we now have as many active users as the population of the country that I come from. Iceland's not a very big country. But he just kept doing that every week. This week we surpassed the population of Ireland. And this week it was Scotland. And then next week, eventually it was like Germany.

And that was really amazing because I just find myself picturing, like the whole population of Iceland using our product in a day, like really amazing. So I started out with technical curiosity as the motivator. And then it was really Google that taught me to start thinking about how many people you could impact. And that has been the real driver for me behind everything that I've done since. Yeah, that framing. is really powerful, I imagine, in motivating a team to move forward towards things that are impactful. I remember YouTube also had a very similar thing, which was that for a longest time, they were

driving towards it was maybe like a billion, I don't know, minutes watched per some unit of time. And that unifying goal, just everyone's saying, okay, billion's a big number. I'm going to, you know, chase that. And so I could totally see why that was very motivating for you as an engineer. Yeah, I think anytime that you're able to lay out a really clearly defined executable, so it's possible, but audacious goal and like help everyone rally behind it, I think teams often do incredible things to make that happen. And I've been lucky to experience that, you know, as an engineer and then later try to use that kind of tool as a manager and leader. So yeah, you talked about management and I understand that you grew from an IC to a manager

quite quickly. And when people think about the management versus senior engineer fork in the road, it's not a clear-cut decision for everyone. So I'm curious, what was the story behind you making that decision for yourself? Yeah, it's a funny story, actually. I was an IC engineer and was having a blast and was learning a lot. And I think it was because I was around a lot of product managers that were really helping the team see how much impact they had. I remember I walked into my manager's office one day. And I said, hey, Dave, he was called Dave, he still is, he's a good friend. Hey, Dave, I want to be a product manager. And he kind of looked at me askance. He's like, well, if you really want that, we can figure out how to make it happen. But you should be an engineering

manager. And he basically pitched me on the idea that as an engineering manager, I'd be able to feel the same kind of fulfillment in terms of impact that I might in a PM role. And I'd be able to continue to do technical work. So Google at that time had this role, which was variously called TLM or Uber Tech Lead. And he really pitched me on doing that. He's like, you love engineering, you love writing code. So do this. And so for me, that was quite an easy choice. I mean, to be clear, the team needed more managers at the time. So I'm sure I was solving a problem for him. But I do get a lot of fulfillment and energy out of helping people accomplish more together than they might on their own. And then I was able to continue being like super in the details, writing

code, producing designs and so forth. And then as I developed in my career at Google, I ended up taking on more and more teams at the same time. So still managing ICs, but multiple teams at a time. And the management job definitely took over the vast majority of what you would think of as normal work time. But something that was true then at Google was that everyone was encouraged to use their 20% time. So I, this was a period of my life where, my wife was working a very busy job, and I just like was super energized by the work I was doing. So I spent a good couple of years where I was managing teams during the day. And then I would have my own like real personal engineering projects as soon as folks started to go home. One of those, for instance,

was I built the the first version of Google Translate on the iPhone. And that was cool. It gave me a chance to interact with a whole new group at Google. And it was some like hands on engineering work. real engineering work with impact that helped me kind of continue to scratch both itches. And I feel very fortunate to have had that experience. And if you're someone out there who's thinking about, I love writing code, but I think I could have a lot of impact as a manager. I do think if you can find a place where you can continue to do both, it can be incredibly fulfilling.

And of course, I decided to work pretty hard during that period, but I was loving it. And so I think if you derive a lot of energy from something, just go at it. most of the people that I talked to who tried the TLM role, and I asked them, do you recommend it? They tell me no. They say you're doing two jobs at the same time, and it's difficult to excel in either one. So what do you say that? Because it sounds like you're supportive. Yeah. So I understand that perspective. The projects I was managing were different projects from the ones that I was being an IC on. I think if you're trying to be an IC on projects that you're also managing, which by the way I'm doing right and the startup, and having a blast, it can be more challenging because you have to kind of continually

figure out how to make sure that you're putting on both hats. If you're working as an IC on a project that you're also the manager for, it's very easy to get sucked into your own personal work and kind of lose a little bit of track of like, what does every individual in the team also need to be unblocked? And it just requires constant, a constant like prompt to kind of go into this different mode. Many years later, at Striper, I worked with this management coach, a guy called Jeff Lawrence. And he had this analogy he used, which was, when you're a leader, you have to continually step onto the balcony. So, like, you're on the dance floor doing stuff in the, in the org. But you have to, like, prompt yourself to step onto the balcony and then look down at how everything is working. You know, he was teaching me that in a

completely different context, but I think that's actually true for TLMs as well. So I think it's a particularly challenging role to make work well. But I think you can make it work well. And I've certainly had a blast doing it as long as I think through and try to create the moments in the week and the day to do that step onto the balcony thing. I mean, eventually though, you grew to a VP at Google. So I can't imagine you were still taking on feature work when you're, you know, that level of org leader, right? Funny story. Certainly by the time I was a VP at Google, I wasn't a critical contributor in any of the projects, but something I really believe pretty deeply, and I took this into my work at Stripe as well, is that no matter how I'm senior you are, the most effective

leaders find some way to experience the work of the team at what I describe as like the one foot level, the actual work of the team. I find an actual tool for this, which I call engineering when I was at Stripe. But I did this at Google as well. As a VP engineering, I was running this program called Android Wear. It is the foundation of the wearables platform that is in all of the Google Smartwatches today. And I was running that almost as like a GM, you know, products, engineering, business partnerships, user experience, et cetera, marketing, everything. It was great. I still find it was incredibly valuable to actually experience the tool chain that the engineers in my org were working in. It just made it much easier for me to ask smart questions, to actually

see what was necessary to unblock them. So periodically, during that period, it was probably once every two, three months, I would find a way to go and do a little project and the code base. And I think that the context that that gave me back then made me a much more effective VP engineering. And so I still do that today and did that for my whole career at Stripe. I remember when Elon Musk bought Twitter and there was this really strong influence from his side on managers should code. and this push, basically what you're saying, and I guess some of the downstream benefits of it came in, there was a big debate in the industry on that thing.

And, you know, when I think about going deep versus scaling yourself, like the very brainless, quick thing I could think of is, you know, that I see project that you might have done, like the iPhone one, for instance, you could also have positioned someone to do that work and then you go focus on more, you know, high leverage things. So what's the case against that? Yeah.

So these were two very different moments in my career. So when I did the iOS Translate app, I was still like relatively junior. I think it was, you know, first year TLM at Google. So doing a real engineering project end to end was, I think, like, quite appropriate to keep my skills like, you know, fully sharp. By the time I was in these org leader, you know, managers of multiple managers kind of roles, it certainly would be pretty damaging if I was trying to code the whole time. There's so much work to be done in those jobs to help the team have the right context, to unblock things, to have the right partnerships in place,

especially in a large company like Google to work across the company so that folks know what you're up to. That is the work. That is 95% of where you need to spend your time. But I do have this deep, not just belief, but experience that carving out a little bit of time and being quite deliberate about it to go and out. actually work in the same mode as the teams that ultimately the managers of managers are running gives you just this tremendous context. This practice is not new. If you study manufacturing,

there is a practice of managers and senior leaders going and working one day a year or something on the factory floor. So they really understand what they're talking about. And I think this is applying that already known practice to the software industry. Maybe I could just skip forward here a little bit and share like, so how did I do this at Stripe? I would take time at least once a quarter, except maybe the final quarter of the year, which is always pretty busy, to go and join a team for a few days and complete a small real project. And I called it engineer occasion. It's a portmanteau of engineer and vacation because it was really just a few days. And obviously, there are a lot of other things that people expected of me and my role

quite legitimately. But I could take a few days of vacation and it was fine. Everything continued. So I would say, for these three days, think of me as being on vacation. If it's a crisis, I'll answer the phone, we'll get together, we'll sort it out. But if it's not urgent, you can wait a few days, just don't bother me because I'm doing this thing. Every single time, I would make a very detailed friction log. Here are all the things that we ran into that were frustrating. And that served as great input for me as CTO there. I was thinking a lot about how much and where should we invest in developer productivity. So I really kind of this visceral sense of how things were going. And it also served as a great resource for me to ask all of the right

questions when it came to operational reviews and so forth. So that practice was something that I used. And then you really encouraged other managers in the organization to use as well. And not everyone did it, but those who did find it incredibly valuable. And I think it's a good practice, especially if you're working at a large organization and you're thinking, I'm getting a little bit out of touch with what's really going on. Do an engineering occasion. So if I'm understanding correctly, that first case on the iOS team, you were hands on through and through. You were an individual contributor as a manager. But the latter thing that you're recommending as an org leader is more of a educational thing for yourself. It's important to embrace it as an

opportunity to show what you have, what you've seen to everyone else. It can give context. I find that the reports that I'd write from my engineering occasion were useful not only for me conveying, you know, some context, but also for a bunch of other managers like, oh, that's how that thing works. And, oh, I kind of had this mental model, but I see that it's like slightly different, especially all of the infrastructure that we were working on was changing over time. That kind of educational exercise is, I think, the heart of the value. Eventually, you mentioned, you know, transitioning to org leader.

You still got involved here and there, but ultimately you weren't hands on. it's just the nature of the role. To me, you seem like an engineer through and through. Were you ever afraid of losing your technical edge? The really short answer here is not really no, because between opportunities to write bits and pieces of code at work and the ability to invest my free time in programming, I love programming, like truly. I get into flow state when I'm programming, and so if I'm not getting a chance to do a lot of it at work, by the way, right now I get a lot at work. So I don't need to do very much my spare time. In fact, I don't have spare time. I just work on the stuff that we're doing, which is fun. But if I have spare time and I haven't

programmed for a while, then yeah, I'm going to jump in. So for instance, I find the last several years I've been doing Advent of Code in December, it's awesome. Get a chance to kind of make sure that I'm keeping some of those skills sharp. Before we leave the IC versus EM decision, a lot of people in the audience probably making this decision for themselves or kind of near it, how do you think about what's the optimal way to make that decision? The advice that you mentioned, which is, hey, being a manager and being an I see or different jobs, don't try to conflate them together. That does resonate with me. I've given that advice to many people. I think if you are considering becoming a manager, the best way to do it is not to try to kind of join it on the

side of something you're doing. Try to find an environment where you can do that like full time, really focus on it, put your own I see work to one side so that you can think very carefully and really pay a lot of attention to what does it take to make this team the most productive, the most happy, the kind of best version of itself that it can be. When I see people do it that way, they tend to thrive when they try to do both at the same time unless it's very carefully structured. It can be harder. If you find yourself at a company that is willing to let you do that on a trial basis and then make the decision, well, number one, you're very fortunate, because many companies don't have that, you know, luxury, but there are larger companies that

will make that possible. And if that option is on the table for you, I definitely suggest doing that. There are many people I've worked with where they've let me know that they want to go into management. And often the first thing I do is actually try to talk them out of it. It's like, well, why? Sometimes, I think this has changed a lot in the industry over the last five years, but certainly if you wind the clock back 10 years ago, I think there was this kind of real, I don't know, like weird incentive structure where everyone felt like becoming a manager and managing bigger and bigger teams is kind of the prize and therefore I should do that because that's what success looks like. I think luckily a lot of companies, companies like Google

and meta, have really cultivated this idea that the IC career ladder can go all the way up. And so you don't just have to have these big teams in order to win. But back then I would see a lot of folks that wanted to switch into management because it just felt like the right thing to do or the way that you kind of like progress your career. And being a good manager and being a manager that actually like feels fulfillment out of the job, it does require you to actually like take a lot of energy and get a lot of energy from getting more out of other people. And that's not for everybody. So like really reflect on whether that's something that gets you excited. And if it is, give it a try. If you're in an environment where you can try and go back amazing. If you,

if you aren't, give it a try. And, you know, I'm sure that there are other ways that things can go in future. You mentioned that Google and meta, there are these parallel tracks and they can go equivalently as deep. But there are differences between the roles and there's probably differences between the progressions. Let's say you're someone in the audience who's hell bent on, I just want to go up. What path would you recommend or do you have any thoughts on that? I'm going to choose to answer this question differently.

So when I was a kind of like early and mid-career engineer at Google, they had this like very clear incentive structure, which was, you know, you start off as a level two and then you become a level three and then a level four. And it's great. It's like, awesome. I've been put into a game and now I know that the next thing I need to do is figure out how do I get to the next level. I'll be honest, that's what I did for a little while. Luckily, that aligned very nicely with things that I was getting a lot of energy from. But the more I have worked with many, many people and talked to them about their own experiences and even later in my own career, what I've realized is the way to have the way to have, the most fulfillment out of your work is to try and figure out what do you want out of it? You know, is it the flow state from coding?

Is it working on something that's incredibly impactful to many, many people? Is it working with a team that you have a really strong bond with? While so many of these companies that we all work at set up these kind of obvious games to play, take a step aside and try and think, what am I trying to get out of this? And it might be to take the next step on the kind of career. ladder that's been put in front of you, or it might be to do something quite different. And it was by the time I came to thinking about leaving Google that I think I really figured that out. And I've reflected in my own work in that way ever since. And I feel very confident saying

I feel significantly more fulfilled for it. I think, I mean, there's so many things to optimize foreign career. Fulfillment, of course, is the conventional wisdom. And obviously, there's a lot of benefits to it. I still think there are people who will chase the carrot even if you gave them that advice. That's okay because the carrot for them is the thing that they want to chase. I think it's just like make sure you're chasing the right carrot. At Google, I understand that you went from an entry level I see all the way to VP of engineering. And that's, you must have a very unique perspective. Almost no one gets promoted to levels of that height. So I want to ask you because you went through levels of magnitude of management that I wanted to hear your

perspective on the differences. So I was curious, the first step is, you know, frontline manager versus manager of managers. When you made that jump, what was your biggest skill gap? So I actually think that my very early career as a manager at Google, I learned a lot of the wrong lessons. Something that you can do as a manager of one team is you can do everything. that you possibly can to make that team happy. And that is not the same thing as getting the best impact out of that team. And it may actually not be the case that they look back on that time as the kind of best time of their career. And I think that's what I did as an early manager at Google. I actually, I won this thing called the Great Manager Award when I had a single

team reporting to me, which was this like pretty prestigious award inside of Google. And I'm grateful to the folks that put that thing together because there's a nice program of investing in those folks, I don't think I deserved it. The reason is that award was voted for by the teams. So whichever team gave the most votes to their manager, that manager got the great manager award. And what I learned later, especially as I started managing managers, was that those teams that are perfectly happy are rarely performing at their very best potential. In order to have the biggest impact. It's really important to like pretty directly make sure that low performers are being managed. By the way, you can't make a whole team happy without making sure that they feel

like they're surrounded by folks that are all pulling their weight. But as a manager, you start to realize, oh, here's a manager in my orbit, you know, in my team, who has a really good sense of what we're trying to do is really good at like moving all the distractions out of the way. And actually, we'll push the team a little bit to fulfill the most impact that they can. And you know, here's someone else that is doing what I used to do. And the answer there for me was actually go and help them get more out of the team. And so as I became a manager of managers, I think I stepped onto that balcony I talked about earlier, much more and reflected on how is this entire group of people essentially configuring themselves in order to get the most out of everybody.

And then it is also the case that the tools you have available as a manager of managers change. So as a line manager, it's like I need to have the right one-to-ones, the right one-to-one docs and the right goal set for the team in order that they can make progress. And hopefully you also kind of want to get into the craft a little bit with folks to help them. Once you're a manager-of-managers, you can start to think about what are the systems we're running in this organization that will help us achieve our goals best. So, you know, how do we do things like product reviews? is our hiring process working, only in some companies,

can manage just change that, but I've been lucky enough to be at each stage in a state where I could do that. And you really start reflecting on, I need to think about not just how I show up day-to-day, but what tools and systems I'm putting in place for the organization. As a software geek and a distributed systems geek, I find it quite exciting to think about the organization I was running as if it was a little bit of an operating system,

how to all the things that we do every day and every week and every month and every quarter and every year fit together to help us get the most out of everybody. And that's just like a whole new toolkit that you don't think about when you're a line manager. Am I understanding correctly that if a team is too happy, that's actually a red flag for you. So I'm not saying I want anyone to be unhappy. And a key trait of the organizations that I aspire to try to build is that I'd be very happy to do any of the jobs in the organization. I really mean that. But it is the case that I find over time that when I compare the teams that are reporting the greatest happiness to the teams that are reporting

like pretty happy, but I have all this feedback of things that could go better, it is usually the case that if I then grab the same people a year later and ask them, hey, how was it really? The folks that were not perfectly happy and had this like, you know, desire to change things and were put into a position where they thought a lot about their impact actually tended to have had the best time in retrospect. At Stripe, I learned about this thing called type two fun. It's the fun that is, you think of it as some of the best times in your life when you look back on it, but it's kind of hard, you know, in the moment.

And I think as managers, certainly for me as a manager, I want to create a lot of type two fun for the teams that I work with. It doesn't mean it's not going to be, you know, a good sustainable experience. But let's look back on it and think we got a lot done in that time. Does that make sense? That makes sense. Yeah. And I think that that's a really interesting, I guess, spectrum that you call out in the happiness

of teams. It reminds me also of there's a similar concept with teams that are not breaking anything is probably moving too slow. It's a great. You know, teams that are breaking. It's a great analogy. You should, there should be some downside of you too far. That's right.

Yeah. You know, we talked about frontline manager versus manager of managers. Now I'm curious about the step that very few people. ever experience, which is you went through senior management all the way to VP. What's the difference between your role as a senior manager versus when you are a VP? I think this probably takes different forms for different individuals. For me, the thing that defined the difference between being a VP at Google and being a very senior manager was that I took on responsibility for leading functions beyond engineering. by the way, my title was VP engineering, but I think by that stage at Google, we didn't pay a lot of attention to the exact job family that you were in. It's all about like, we're trying to get a thing done. What's the full set, you know, set of skill sets that have to come together to make this happen? And that does change your perspective. Certainly for me, it changed my perspective quite a lot. Much earlier in my career, I had tended to think Google, by the way, was a classically engineering first company in those days. I had tended to think of like,

well, all the other functions kind of exist to like feed the engineers to help us all have impact. Not true, by the way. I think if you are working in an environment where you don't have the other functions to help make sure that you're solving the right problem, you're getting the right user input, you've got the right business deals in place to have, you know, the potential for a lot of impact. You're going to have much less fun and much less impact in the world. But I hadn't really understood that until I was put in the position of leading multiple functions. It is quite a mental transition.

I think there are much better engineers than me that work on my team today and have worked in most of my teams all the way along. But when you're managing a function that you have yourself been part of before, you do have this quite visceral understanding of how to do the work, which is valuable. I have designers who report to me. I can tell you, I am a pretty lousy designer. If you put me in Figma, I will not do a very good job. And yet, I have to figure out how to be a good job.

good manager and leader of those folks. It turns out I actually like care a lot about design and can have really good high bandwidth conversations about a lot of the work. But it took a real adjustment for me to actually feel some confidence in that when I knew that I would not be able to jump into any seat in the organization and perform the job. So that was for me that by the way, a little bit of like a personal confidence thing there as well as here's a whole new set of problems to solve. But that was for me the biggest transition in that jump in my career. Did you ever consider that engineer occasion tool but for the other roles? Yeah.

So I've actually done it. At Stripe, I had a team which was part of the technology org that built tools for sales. Super important for a company like that. And I wanted to understand better how are these tools being used. So I actually did at one point to the equivalent, I think I called it a sales occasion. I went and shadowed a couple of salespeople within the org. super, super useful. I was doing that, of course, mostly to gain context for how we should prioritize work on the engineering side. But yeah, it's a pretty valuable tool. I wouldn't do it in quite the

same way, obviously. So, for instance, if you asked me to do a design occasion, I think I would have to do it more as like a kind of shadow someone than I jump in and do all the work myself, but it's a useful tool. In a previous interview, you had mentioned that communication is incredibly important for senior engineering leaders. What are your thoughts on how to get better at communication? So there's two forms of communication, at least writing and speaking. So let's start with speaking. The number one way to get better at speaking to large audiences is practice. I remember very early in my career being like really quite nervous when I had to present to, I think at that time, was like the whole Android org or something like that. And it's pretty hard when you're nervous to

kind of very clearly think about what you're saying and communicate it really naturally. I was very fortunate to have a super supportive manager at the time who said, yeah, okay, if you want to get better at this, we'll just give you more at-bats essentially. It was in London, so they didn't say that. More, more kind of chances to practice this. And I got sent along to speak to whole auditoria of Google customers. So I was working on ads, stuff. at the time. I remember doing one of those in an office near Kingscross in London and looking out into the crowd. It was one of the first I'd done with, you know, maybe a thousand people in the crowd. And I was to give a live demo and give a kind of inspirational talk about local ads.

And it was really scary. But I did it. There's actually a video of it on YouTube. Of course, I look back on that and think about how, you know, today I probably do a much better job. But it's getting the reps in is what makes that go well. Then there's, you know, communicating in writing. This is something I'm doing. definitely still learning to do better. Today I use Claude a lot to help with that. But I think if you can condense the most important things that you need to convey into a short, clear document, that can be incredibly valuable because I can talk to one person and it takes a certain amount of time. I can talk to a whole audience of people and maybe, you know, 30% are really

paying attention. You kind of forget over time. If you get a really good document out there, people will pass it to each other. They'll read it once. They might come back to it again later. It's an incredibly leveraged way to communicate at scale. But I also think you have to do both of these things. I think people like to listen to folks that they feel like they have some kind of personal relationship with. And the personal relationship really only comes from like live conversations. Once a really strong personal relationship has been established, then, it becomes really easy and scalable to read things and kind of take it from there. There are a lot of people that speak a lot, but I don't think they speak like you speak. Like I watched, you gave like a keynote in 2019 for Stripe Sessions, and you came onto stage and immediately within a second. This guy's confident. He knows what he's saying.

So there's something different about the practice that you did or, you know, because their managers all speak all the time, but I've been to many, you know, all hands or people are zoning out. Well, I appreciate you saying that. I mean, look, I am enthusiastic about what I do, and I think hopefully a little bit of that kind of comes through in how I speak. It really is the case, though, that if you had tried to put me on that Stripe Session stage in 2012, you would have had a completely different conclusion. You would have thought, that guy seems a bit out of his depth. So it really was the practice that help with those things. And I credit the manager that just said, you need to practice this a lot. And I can see that there's something there.

So let's go get it done. One of the thing I want to say in speaking as well is it's not just about giving these big keynote presentations. One thing that happens as a, you know, relatively senior leader is you're essentially always on stage. As you walk around the building, you know, in the office, folks pay a lot of attention to like how you're doing. Like they'll take a lot of their own confidence in the plans of the company from the. the body language of, you know, the CTO. I find myself kind of keeping that in mind a lot. And me, I wasn't ever putting on a weird face or whatever.

But just that means, you know, hallway conversations or this random meeting you're in, it's another opportunity to remind people of like what we're doing and why we're doing it. And so kind of using all of those opportunities to convey an overarching message was something that I learned over time was important and valuable. It's also important to have some dynamic range in how you talk about things. Like, if everything's awesome all the time, well, I mean, everyone knows that everything's not awesome all the time. So no one's going to believe you when it is awesome and no one's going to believe you when it's not. So, but also if everything's always done in the dumps and never going to work, then, you know, you're never going to help people get excited about running over the hill.

I find it was valuable to take a moment before I'd open my mouth in any meeting, whether it was one person or 100 people and think, what am I actually trying to communicate here and make sure that I'm using the dynamic range? A lot of engineers who get into leadership roles, they're tasked with this, you know, giving their top of mind and all hands, etc. And I think 95% of those, if not more, everyone's got their laptops out. And it's kind of, you know, most of the message is falling flat. Do you have any tips on how that manager can do storytelling in a way that the org is actually going to pay attention? Yeah. Number one, prepare. I have made this mistake many times where I'd be told, oh, just show up and give us a bit of your top of mind.

I'm like, okay, great. I'll show up and I'll give you a top of mind. It's like, oh, what's on top of my mind right now is that I'm kind of hungry and, you know, I'm not going to say that. It's incredibly important to prepare. Think about what is the most useful context for that audience to hear about and put some thought into it. You know, they're all spending 15, 20 minutes of their time listening to you. At least you can do is spend 30 minutes of your time preparing. Let's thing one. I think thing two is there was a leader at Google called Alan Eustace. I think he was VP of all engineering at Google when I was a kind of entry-level engineer who always did this amazing thing when he would come up to answer questions or explain things, which was he'd be asked a question. And rather than just answer the question, he always took the time to take one step back and explain the context behind the question and why it might matter so that folks who weren't already immediately familiar with the problem at hand, could actually both understand what was going on and could actually learn something broader from that. I aspire to be like Alan, and I'm certainly not that good. But that really, I noticed that. And it really stuck with me. And again, that's part of the take a beat. Is it possible to take a step back and explain

the context behind what you're about to jump into? It actually always makes it easier for folks to then, like, pay attention. Certainly, if you're talking about something that the people have no idea what it is, they're never going to pay attention. It also helps with a bit of a storytelling arc, which is like, first of all, let me tell you why this matters, then let me tell you the thing, maybe there's another detail, and then let me remind you what I just told you. That's another trick. For writing, the thing you called out was condensing the writing, and you recently wrote this post about agents crossing a chasm, and I scroll to the bottom of it, and there's this thing. It says, Ari Grant, a bunch of these people had reviewed it. Yeah. How important

is the people reviewing your writing in that process of condensing? Yeah, this is something I learned at Stripe. I used to write blog posts and just throw them out onto the internet. And I'd get pretty good feedback about them sometimes. There's one about a neural network controlled car that I wrote, got a lot of coverage. But I would see people at Stripe writing really good documents and crediting the people who'd reviewed them. And I was like, oh, that's interesting.

And so I started doing it. I started sending drafts of things that I thought were important to other people. and it improved the quality of my writing immensely. Because of course, as an author of a piece, you always have a mental model of like, what am I trying to convince someone of or convey, what might they already know? And you'll write it with that in mind.

It's actually quite common that I would share something I've written with a friend or former co-worker or whatever and be completely blown away by the feedback they give me in terms of like, it would surprise me. It's like, oh, I wouldn't have thought you would have asked that question. And then, of course, you can go back and kind of adjust your draft. To be clear, you don't need to do this for every email. That would be a waste of time. But something that you think is an important place you're trying to convey some important piece of information.

It's incredibly useful to run it by some people. Before we leave just general management practices, I think we talked a little bit about scaling yourself. And you said it was especially important as a senior manager and hire. What are those ways that you think are really high leverage ways to scale yourself aside from coaching your direct reports? Yeah. So I alluded to this. One of the tools in your toolkit is you become quite senior is to start thinking about how the organization works, the rituals, the processes. By the way, when I was an early career engineer, I used to think that the word process was kind of like a dirty word.

In fact, it's Symbian. Since the company doesn't exist anymore, I feel a little comfortable sharing some of the stuff that wasn't so good. They had this thing called a process library. And if you were doing anything at the company, you were supposed to go to the process library and look up the process and then follow it. I think this was part of like ISO 9,001 certification or something, which is like this British, maybe it's international quality certification. Anyway, everyone was supposed to do that. Of course, nobody did that because you just like, well, I know what I need to get done.

I'm like under a lot of pressure, got to move, right? But sometimes afterwards someone would come along and ask you, hey, show me the documentation of how you follow that process. So, you know, you grab it and fill it eyed. So I didn't, I'd never really heard the word process before and I thought a process is this kind of like joke, honestly. And then I find myself being, you know, an organizational leader. and I was like, someone told me, David, just really think about the processes in your organ.

I was like, oh my God, no. And then I realized, hang on a second, like, think from first principles here. What are they actually talking about? And they meant, like, the rituals and how we work and how we get stuff done. And actually, like, really leaning into getting those set up right is incredibly impactful. For instance, one of the things that I did with the help of some folks who reported to me at Stripe was set up a set of meetings, which we called Ops Review, which actually kind of nested in the org. So there was a weekly one that I ran

and looked at kind of the most important stuff. But there was a nested set of them that ran across all of the engineering teams and the whole company. And that was a really, really valuable, like, tool to help the whole company pay attention to and improve on a whole bunch of things like reliability and efficiency that, you know, otherwise

would have been very hard to get, you know, impact on through just talking to your job. directs and having it kind of trickled on. So that's the main tool. You mentioned hating processes, and I think that's pretty common among engineers. How do you decide when the process is net positive versus net negative? I think as someone who is in control of a process or is like responsible for running it, your job is to make sure that it only exists as long as it is clearly a net positive for everyone that's, you know, responsible or kind of operating within it. And then of course, there's a really interesting organizational design thing here because in some companies,

I'm not talking about Stripe here. I think we did a really nice job of it. In some companies, there will be a person who's responsible for like executing and overseeing the process that is not actually the person that kind of cared about it existing in the first place or even like brought it in to solve a particular problem. But because it's their thing, it's kind of their job, it's very hard for them to say, is it actually fit for purpose? But then, you know, running large organizations, our jobs are like, let's make sure that we just don't do that. There's always tons of work for everyone to do. So no one should feel like they're box into continuing a thing for no particular reason. But how do you prevent that if, you know, let's say you're, you know,

you're the VP or the manager and you say, okay, we need a SEV review process and you go to some tech lead and you say, hey, this is your thing now. I can tell you worked at META because you call them SEVs. Oh, yeah. Yeah. Seves, incidents. It's all the same thing. Yeah, yeah. That person that was just handed this thing top down, they're unlikely to be passionate about it and really think critically about this is net positive. But how did you do that? I don't know. I think it's possible to build teams of program managers that are really passionate about the why behind what they're doing. The program management group was something that I helped set up at Stripe.

And I feel pretty confident saying that the vast majority of folks there were really just making sure that we were doing the right thing. and very focused on impact for Stripe's users. A lot of that, by the way, comes from company culture. Stripe has a set of operating principles, and the first one of those is users first. So everyone's always looking through the work they're doing to say, why does this matter? And that's something I think is very precious there.

And I certainly bring that mentality to what I'm doing at this company as well. Makes sense. Yeah, I could see the culture of the people you are delegating to is important, but also probably how you delegate, I imagine it's important. Like if you gave the context behind why it's impactful.

Yeah, that's a good observation. If you tell someone do this, well, what else can they do but do that? If you tell them, here's the problem we're trying to solve, and I think that we should probably do this, you go do it and please take agency in making sure that we're really solving the real problem. You're completely different outcomes. One topic that I want to touch on, and this is something that actually Philip mentioned specifically,

which is that, you know, fill up is there's a number, podcast that I did. He was the site lead for Facebook at London. And he said, who did he talk to that gave the best advice on how to start that site? It was David Singleton. It was you. And so he said you had a track record of doing it and you had learned about doing that at Google. And at the same time, I imagine there's a lot of AI companies today that probably start in San Francisco, they're probably thinking about scaling up. How do you get a remote location to carry the right culture so that it's successful? Yeah. Well, so Philip Sue was the Facebook London engineering site leader and I was the Google London engineering site leader at the same time.

And we, of course, find ourselves kind of in this fierce battle for talent, like the number of times that we both had offers with candidates and we would realize, well, we've both been talking to this person was a lot. Eventually, actually Philip reached out to me and he's like, hey, seems like we should probably talk, which was amazing. And I really respect that. By the way, one thing I love about Silicon Valley, which I think is kind of, yes, it exists right here in literal Silicon Valley, but also it's kind of a state of mind of these ambitious tech companies is the idea that even some of the fiercest competitors, folks will help each other in the craft. And that's kind of what Philip and I were doing back then. I think we actually

were genuinely able to help, like raise the bar for engineering. in general in London. But to get back to your actual question, like, what's the right way to set up these effective remote sites? There's a couple of different things. I have had a lot of experience, obviously, of running a site that was quite far from headquarters. So Google's headquarters were in Mountain View. I was running this site in London. That distance means it's a lot of time zones away. So the overlap during the day is very small. So you have to think about that quite carefully. When I was at Stripe, we had a very vibrant engineering site. So I was based in San Francisco. We had a very vibrant engineering site in Seattle, completely different setup because it's in the same time

zone, and therefore you can do different things. So I'm going to start with the, you're quite far away. So in that setup, it's important to think about how can we enable the team that are on the ground in London to actually be able to unblock themselves the very most and run as autonomously as possible, so that they need to use that little, you know, one-r overlap in the day with the folks in California for as few things as possible, because then they're just going to be able to make more progress. So what I really kind of like pushed very hard on when we were doing that was that every team in London engineering had to have a clear and complete mission, meaning they knew what they were doing at a very high level, like, this is the goal and they were given a lot of autonomy,

and then they were given like all of the equipment to go off and execute that pretty autonomously. And that means that, you know, for eight hours of the day when Mountain View is not around, everyone's just cranking along. And then, you know, a few things come up that you need to reach out to another team for. You can solve them a little time overlap. The worst way to set up a team like that would be to have half the team in Mountain View and half the team in London, because then you come up with a hundred things every day where two people need to kind of have a conversation to unblock it. And there's so many of them that you can't make progress in that little time window and progress grinds to a halt. So,

for those teams, that's the right setup. The other thing that I realized was oftentimes the engineering site lead for Google London, I think two before me. One of the things that I noticed was he didn't spend very long in London. I remember asking him. So I was like a relatively junior engineer that I was like, hey, Shannon, what? Why are you never here? He's like, hey, you have to understand. The best thing I can do for London is be in Mountain View and be kind of like creating like good personal relationships with all the people whose work we are part of, make sure they know what we're all up to, and then bring a lot of context back here to enable us all to operate very autonomously. And he was right. I really appreciated what he did for us all. And then I tried to do the same thing later when I was,

you know, in the other position, which was I would travel a lot to California so everyone else didn't have to. They could if they wanted to. I mean, this was a different era where that was always possible at Google. And, you know, a big part of that job was just like, make sure the team is visible, make sure the capabilities of the team are very clear so that folks understand. If I need to implement some mobile browser thing, there's actually a team of experts at the Google London org who used to work on the WebKit project or whatever, right? So like just making sure that context is shared. So that's the best way to set up sites like that. I think the other thing that I would say is every effective remote site that I've worked with or helped set up or whatever

always had a little bit of its own culture. It's useful to have a sense of identity because it creates an opportunity then for folks say, ah, we have a sense of identity so we can rally around this cause, which means that we will actually spend energy to think about how can we help make this better, right?

When you identify with like being part of a clan, you think about how to make sure that this set of people have a great experience. And if you don't have that, the little pieces of friction that people run into, maybe you don't feel like they ladder up to something worth addressing, whereas when there is a sense of identity, it's actually worth leaning into, and that makes the whole

team much more productive. However, it is not a good idea to have a radically different culture from the company that you are part of, because the whole point is everyone's part of that company, and if you start feeling like everyone on the other side of the ocean is bozo, you're never going to have a good time of the work. So the trick is like have enough of a identity that folks think about collectively helping each other and make sure that that identity is rooted in the culture of the whole company because that's what everyone is there for. So those are some of the things I talked with Philip about back then. And when you say culture, you don't just mean Google. You mean Google London. Google London. Like you're a clan. Yeah, we made T-shirts. We had logos that we

put on our laptops and so forth. And we would get together and talk about what's the kind of work that this site's really good at. What would we like to see more of? And then I could make sure that when I was spending time in California that I was talking to folks about that to see if we could create those opportunities. And if I'm understanding, the further away the time zones are, the more independently you'd want each site to be able to execute. That's right. You know, when COVID happened, I think there was this big move towards remote being more and more acceptable of a collaboration model. But now that you're starting your own company and when you think about teams in this post-COVID environment, which one you think is optimal? Do you think it's, you know, a team purely in person is

better? Do you think full remote is best, is hybrid best? What are your thoughts on that? Yeah. So at Stripe, we had a remote hub well before COVID. So we really recognize that there is amazing technical talent everywhere. I mean, certainly all across the U.S. There are amazing engineers that are not in San Francisco or New York or Seattle, and that there is a company we were missing out if we didn't find a way to have great opportunities for those folks to contribute to our mission. And so we put a lot of thought into like, what does it take to make a remote team really effective?

One of those things is document-based communication decision-making culture is incredibly valuable. So we would work pretty hard to make sure that conversations that would happen between individuals on the same team, if they happen to be on a video call or happen to run into each other in person, got written up for the rest of the team so they weren't left out of the conversation and they could follow along. And then any critical decisions came with a doc, which meant that, yes, it's slightly slower to make any given decision. Not always actually, because the deliberation you put in writing is often like a big part of what makes more effective decisions in the first place. But because every decision was happening in a document,

everyone had a chance to understand the context, contribute their ideas, follow along, and then kind of more bought into the decisions once they happen. So those are the most important things I think to make remote teams work well. And if you do them, remote teams can work very well. The other thing that I think is important is there is no substitute for spending time together in person to build up like a personal rapport. But you don't have to spend every single day in person together in order to make that happen. I bet if you and I went out for a drink and had a chat about all kinds of kinds of things, you know, what we like to do in the weekends and so forth, that we come away feeling like significantly more bonded and able to do good work together than if we'd never

spoken to each other before. And if you do that on a cadence, it can be every six months, teams can then be incredibly effective, even when they're not together. So all of these things are worth doing to make remote teams effective. And for certain companies and certain teams in certain circumstances, I think remote can be, you know, almost as effective as if you're all just jamming in one spot together. I do personally believe, though, that the very very, you know, best is if you're actually all jamming in one spot together. So I've started a new company. We're very small right now. Maybe we'll talk more about it in a little bit. But we are all here together in San Francisco. And for this stage of the company, I'm excited that that's the right model. As the

company grows, I'm sure we will revisit that because there are amazing people that won't be able to come and join us to work together in San Francisco. So I think it's a balance. I think it is very hard to build a huge company today where you just don't decide to lean into. How do we make sure that distributed, which is like different offices around the world, and remote, which is folks that are not necessarily able to get in the same room together, work works well. And so it's just like something that in our industry, we all have to get used to and kind of lean into.

Coming to the end of your time at Google, I saw that, you know, after you were promoted to a VP, you've remained in that role for, two years and five months. And my question to you is, what was keeping you in that role for that long if I don't even know what further it looks like or what was keeping it at that time? Yeah. And honestly, I don't even know what further would have looked like there, but the short answer is unfinished business. So I think Google made me a VP not long after we'd shipped the first version of Android Wear. And we had a bunch of like really exciting plans and projects that we had already kind of, I had already kind of kicked off with a bunch of

handset, watch manufacturers. And I was just like really excited to see those over the line. So that, that's what kind of kept me there. It's also the case that at that stage, I definitely felt like I was continuing to learn a lot. And I mentioned earlier, part of my whole philosophy for why stay at somewhere like that for so long is always be learning. And I was still learning a lot. I think I was the first time I was managing some of the new functions that we talked about earlier. So it was awesome. I will say then, so you could easily ask the question, why did you decide to leave Google? There came a year, I guess it was about two years after the moment I mentioned, where I realized I was very happy. And I have so much respect and an appreciation for everything that that company did for me. I was very happy. But I realized, if I think about the last year at this company, what I've done was exactly the same as the year before. When you could change the code names of all the projects, but it was essentially like turn the crank on the same thing. again. And I realized I haven't learned very much. And I'm here to learn. So what's going on? So that was

the thing that was kind of the wake up call. And then also I happened to end up having some conversations with a good friend. It was actually Philip Sue about the possibility of maybe starting a company together. And I realized, well, that would be an amazing learning experience. So that kind of shook me into the mode of like, this is probably the time that I need to think about making the next move in my career. That's so interesting. Because I mean, now that I have more of the contact, actually, you and Philip were not enemies, but, you know, kind of. We're definitely in a tussle for the best talent in London. It's just so interesting that actually that's the number one person you are thinking about banding together with for, you know, starting a new venture.

Well, I guess we, you know, find that we had a lot of mutual respect for each other. And those are kind of some of the best relationships to form in business. I feel very privileged to have been able to bond with someone that I was sometimes on the other side of the table from. So you mentioned wanting to start a venture after Google. And I saw in the post that you wrote actually leaving Stripe that a company is the thing that you were considering doing before you got into Strip. So I'm curious, what was the company idea? What's the story there? Yeah.

So, I mean, I already mentioned that Philip and I kind of bonded. And we were talking about the idea of starting a company. We had what I think is a pretty cool idea. I think it's still a cool idea of someone out there wants to build. this company, give me a call. Would you fund it if someone is trying to start? Sure. Send me a note. At the time, we saw kind of the rise of the gig economy, you know, the ubers and lifts of the world. And I actually had like this little side project where I was making these journals and wanted to sell them. And I find that in order to do that side project,

I needed legal help and I needed a graphic designer. And it was quite challenging to find those folks, there were some new platforms like Fiverr where you could get some help. And I actually use that for some graphic design. But I realized, hey, with this trend towards gig work, it would be really awesome if folks who were, you know, in more professional job families could actually take advantage of this trend, but also benefit from some of the stability, benefits, packages, and so forth of actually working for a company. So the idea was essentially like make it possible to have fractional folks in those legal graphic design kind of job families that you could recruit as a company on a platform, they'd be employed by our firm and we would invest in their professional

development. So a lot of the stuff that we've talked about before, and then they would be able to benefit from lots of diverse work and also the career development that you would get if you're working for an in-house firm. And we were planning to build that platform. As it happened, we ended up not starting a company at that stage because I ended up, well, complicated personal things, we decided that it wasn't immediately the right moment, but also I ended up as part of that spending time talking to the folks at Stripe. What I realized as soon as I spent time with folks at Stripe was that company at that time had this, still does, has this incredible mission. Their mission is to increase the GDP of the internet. It really is literally a bottom

about helping entrepreneurs start companies and scale companies to create jobs, to enable people to move money in ways that they haven't been able to before. And that really deeply resonated with me. Remember that I got into software in the first place by building an enterprise or a very small company invoicing system. I realized that what Stripe does is really important in the world. And then, to my surprise, a lot of what they needed back then to scale the company was things that I'd done before. Like, for instance, I'd run the London Engineering Office at Google, and we were looking to open engineering offices around the world at that time. I had a lot of experience in building new products at Google, and we wanted to do some of that as well. So I really very quickly

fell in love with, correctly, fell in love with both the mission at Stripe and felt really kind of drawn to something where I thought that I could do something profound for, you know, a good number of years. And so I joined and it was awesome. In the post, it almost sounds like you went to them for advice on starting the company. That is correct. So how, when did you realize the conversation was turning towards their recruiting you? I did first reach out for advice. By the way, someone once told me, anytime you want money, ask for advice. And anytime you want advice, ask for money. And at the time, I was like, that's such a cynical view. And then so many times since, it's kind of come back to me, I'm like, oh, that was actually pretty good.

So I did reach out for advice in how to build something. Stripe has this product called Connect, which is it powers these two-sided marketplaces. So it was clearly something that we would have wanted to use to build this company. And I didn't know that much about the space. So I thought, if I reach out to folks at Stripe, I'm going to be able to learn a ton. And, you know, they'll give me some tips and maybe they might even invest or something. That's why I reached out. The first conversation was lots of advice and was super valuable, which I appreciated. But Patrick, who's co-founder and CEO there said, hey, and I'm going to be in town soon.

So let's get together. And again, I thought we were talking about advice. But from the very beginning of that conversation, I presume he was approaching it as a hiring conversation. I was just learning so much about Stripe and felt really, as I said, drawn to the mission that it became immediately obvious to me that this was the next place that I wanted to have

the next chapter of my career. And look, since then, I have hired a bunch of senior execs. And it really is a very, to be able to find and attract and then, you know, make sure that they're a good fit, the very best senior people. It's a very custom process. And, you know, it's important to have a systematic approach. But for almost every person that you'll end up hiring that will be a good fit, they're going to be doing something already that they probably are like super committed to and having fun at. And you need to find the right way to identify them, get on their radar, start out. with an advice conversation and then help them see the opportunity. And then I also think it's incredibly important to like vet along the way, like make sure that this person is actually

really going to supercharge the team. There's a real art transitioning from the, hey, getting to know you conversation to the, let's figure out if this could actually be a fit conversation. And it's a lot of fun. So I understand you took the role as head of engineering at Stripe at the time. And then later you grew to a CTO. And that kind of of promotion is, again, probably very bespoke. So what is the story behind getting promoted from a head of engineering. Yeah. So, I mean, in actual fact, one thing that I did not care about very much when joining Stripe was my title. I was joining the leadership team, like the kind of core leadership team of the company. And that was important to me. Because that was where I felt like if we were going

to get done the things that the company needed done, that that was the right spot to be. So that was the most important thing for me was, you know, am I landing in a spot where I, you know, I, can actually help and have enough agency to make things happen. So I don't think we were ever particularly formal about what the job really was. Later, we decided that it made sense to give the job a title of CTO. I think that was mostly in view of it being helpful to the company to signal that, you know, I was in that spot someone worth listening to. That's right around the time that I started running a lot of these company-wide processes I talked about earlier. It was also super valuable for helping me engage with customers and folks outside of the company. So it's a pretty

natural onboarding. You know, pay attention to internal stuff first. Once you've kind of got your arms around that and what's the business, any senior role, no matter whether it's engineering, design, product, it's really valuable to be able to talk to folks outside of the organization, customers, partners, and so forth. And that's where these titles kind of, actually start to matter. So I really like that kind of a culture where we're not necessarily listened to because we have a title. And that's certainly the culture at Stripe. And it's the culture I seek to build here as well. But it's also the case that when you think about interfacing with the rest of the world, this can matter. Definitely. And I've heard a similar opinion of at a large company,

the organizations within the company are almost strangers as well. So it's helpful when the director is reaching out as opposed to this person in engineering is reaching out that, you know, they'll get alignment and stuff like that. It makes sense. I mean, at one point, I'm rewinding back to Google now, at one point when I was made a director at Google, they sent all the new directors off on a training course and they said, hey, the secret is, I don't know if this was true or not, but the secret is it's really directors that run this company because it was the spot in the organization where all of the kind of detailed

plans were being transferred between each other, and knowing that cohort was incredibly valuable. And I think there's something to that. So you have to think about your org design and like, who does what, and having some set of people and different scale of organization, it's going to have, you know, different forms, having some network of people that are making sure there's like really high fidelity of context being transferred is incredibly valuable. And at Google at that time, it was directors. You mentioned org design. And as a CTO, I imagine that, was something that you thought about a lot. I see all these famous engineering cultures. You know, Facebook has its own thing with, you know, move fast and break things and all of these

principles. Similarly, Google has its own principles. Amazon has its own principles. I thought it would be interesting to hear your take on which big tech companies' engineering culture you thought is most well designed and maybe less well designed. Yeah. Well, I'm at a bit of a disadvantage here because I've only worked at Google. among the big engineering companies, and I kind of know some of the others by reputation. The culture of Google, which I joined, was phenomenal. It was a place where everyone was there to do big things. There was the ability and the encouragement to try to have a lot of impact.

Everyone was given a lot of agency. The one thing I would say is I don't think it was very deliberately designed. To be clear, it wasn't total chaos. There was an org structure. But I think it grew up mostly organically, or at least in large part organically. by contrast, I think there are companies that have been much more deliberate about the structure they put in place. Amazon comes immediately to mind. As we were designing a lot of the both org structure and ways of working as we scaled Stripe,

I tended to look at companies like Amazon who'd been very deliberate in their design for inspiration. Very fortunate to have been able to talk to a lot of senior leaders there and get their tips. In fact, the ops review that I mentioned earlier that we ran at Stripe and continues to run at Stripe, I was very much modeled off of the Amazon one. Charlie Bell was very kind to spend, I think, a nice lunch with me and run me through exactly how it worked there. And we tried to take the good bits of that that were applicable to the size and culture of Stripe and apply them. So Amazon is definitely the company with the very systematic org and operational design that over time I've taken a lot of inspiration from, even though I've never worked there.

I actually joked with a friend recently as like, you know, I would love to work at each of these companies for one project just to experience what it's like. So, you know, I love the products that Apple builds, but they famously have this kind of like, you know, not very transparent within the company culture. It obviously works for them. I think they're also very deliberate about what their org structure is. There's the thing called Apple University. Everyone who joins learns, learns how to work in the Apple way. That's really cool. I'd love to experience it to see, like, what could I take from that? And that reminds me of that time all the way back at the start of my career where I was working with all these different mobile handset manufacturers and realized there are so many different ways to accomplish the same ends. And I'd love to be able to kind of choose from the smorgas board. But unfortunately, I've only worked at one big company and I've only really gone deep with leaders at one other. When I look at Stripes operating principles, I do see the Amazon influence specifically in its users first. And at Amazon, it's customer obsession. I think those are kind of similar in my mind. I think that's right.

You know, users first is the idea that everything that folks do at Stripe is really focused on understanding why it matters to the user. And that's a real maxim that I live by as well. You know, think through like, why are we doing what we're doing? What's the ultimate end? Another one of Stripe's operating principles, and by the way, just folks may not be familiar with this, operating principles are a little bit different from values. So this is something I really respect about the early Stripe team. Once they had found product market fit in their core,

which is the payment infrastructure for early stage businesses, they do much more now. But once they find that early stage product market fit, they took a little step aside and thought about, what is it about how we're working that makes us most effective? And so Stripes operating principles, they're not abstract. They're like very concrete,

and they are distilled from the behaviors of the most effective stripes. That means they've also been mutable over time. They revisit them periodically. Not very often because they're pretty stable, but periodically they'll revisit and make sure they're still fit for purpose. One of Stripes operating principles that really motivated me and sticks with me and is something that I take forward is being meticulous in your craft. So that means, you know, taking pride in how well things are done for the sake of how well they're done. So, you know, making sure that engineering systems are designed well, making sure that we can offer reliable services to users.

actually taking the time to polish the edges a little bit, taking the time to take a blog post and get some external people to review it before you publish it. That's kind of all being meticulous. The thing that's interesting about that is a lot of people will, you can look at that and say, does it make any sense? Like, surely just like focus on the cold hard numbers. It's been my experience that there is something that is hard to quantify that actually has a very dramatic impact and how well products and services that you offer are perceived because you take that time to be meticulous in your craft. I couldn't tell you the number of times that I would meet a Stripe customer,

very large company, that it started in Stripe when they were much smaller, and the person I would be talking to was often the CTO, and they'd say, hey, I just got to tell you, like, I was the one that did the Stripe integration back in the day, and you know what? I was so inspired by the error messages on Stripe that I kind of brought some of that energy into our own culture. and at Stripe, if you use the API, instead of like, you know, if you call most APIs

and the resource you're looking for is not find, it'll just give you a 404 not found, you're stuck. Whereas with the Stripe API, they have this thing called test mode, and oftentimes you have to like switch your integration from test mode to prod mode, and that's oftentimes for something they'll be not find. They paid attention to the fact that this went, this was a piece of friction for a lot of users, and if you request a resource from the other mode, instead of just a straight-up 404, which is obviously what every engineer would implement as a first cut. It actually takes the time to run some extra code and say, hey, not fine, but an object with that idea exists in the other mode.

And that's the kind of thing that's like meticulous in your craft, and people remember it. And so it ends up being incredibly valuable. And so all of this is just to say that being deliberate about operating principles, the ways of working that have brought you where you are, you know, when you have any form of success, is incredibly useful. I'm curious, depending on the stage of the company, I could see people thinking that, you know, it might be too early to be thinking about those things and maybe go more with that less intentional

Google approach that you were talking about. How do you see that? Like with the stage of the company, when do you start thinking about we need to scale this culture? Yeah, that's a good question. I'm building a very early stage company right now. I think it matters to care about culture from day one. So me and my co-finders, literally the day that we incorporated the company, we went out for a drink and spent some time writing down what we think our values are as we build this company. And that's been useful. We've certainly been paying attention to that as we think about people that we're hiring and the ways that we're running things and so forth. It's also the case that running an early stage company is an exercise in being smacked in the face quite often. Like, you know, the world will surprise you. And so it's important to have values that, help you know where you might want to compromise and where not. At the same time, I think it would be

way too early for us right now to kind of spin up a, you know, every week we're going to think about what we can do that contributes to the company culture. It needs to be kind of more organic at this stage. But I do think it's something that, obviously I've worked in much later stage companies as well, I think it's something that you do have to be very intentional about all the way through because fundamentally, companies are just large groups of people. On the last, you do something to bring large groups of people together and kind of give them a shared sense of purpose and alignment, naturally entropy will just take over. And so if you don't invest in culture, you almost by definition will not have a culture. And of course, there are all these

quotes like culture, culture eats execution for breakfast, something like that. I think it's true. If you find yourself in an organization that is very intentional about how it works, who's mentioned Stripe, Amazon, they tend to be very effective. And, you know, some of the companies I worked at very early in my career, were not intentional about this and have not lasted. So I think it matters. How do you concretely as an engineering leader enforced culture? So I think there are basically two ways. One is it's important to just be an amazing exemplar of the culture in the first place. But it also, you can't just kind of make that up. Like it has to be authentic. So it is first of all important like work at a place where the culture is actually a

culture that you really identify with and then like ooze it out of every pore and that really helps. I genuinely was at strike because I really cared about the mission. I really cared about users. I really cared about helping these businesses be able to start and scale in ways that they otherwise would not. I also like really cared about us being able to be meticulous in our craft. So and all the other operating principles. So it was very hard for me not to just like show up using the culture. And I think if I'd find myself in a, in an environment where, the values were not aligned with my personal values, I probably wouldn't have been able to do that, and I probably would not have stayed so long. So that's thing one. Like just you have to live it

yourself and like be the best exemplar. This is a quote from someone, it's well known, but I remember someone, you know, on my team told me this once, which is like, culture is the behaviors you accept, which sounded really weird to me. But the point is, you will have the culture that is the behaviors that you accept. So again, I kind of first heard that. I was like, that's a pretty pessimistic way of looking at it. But actually, it kind of resonated with me and it's true. So if you see someone do something that is clearly not in line with the culture,

if anyone else sees you, see that happen, not kind of talk about it or call it out, that suddenly is the culture that you're going to have across the org. So you kind of have to constantly, in as pleasant and upbeat the way as possible, be a little bit of like the point. police on the culture. This is a random story, but I remember seeing a senior leader once walk up the stairs in the office and someone had spilled a whole bunch of like some drink over the floor and then they just walked on. And the culture that we had at that company was that, you know, we really all treated all of our resources like our own and we cared about all the other people. And I saw that

person stop, go to the kitchen and clean up the spill. And they clearly had way more important things to do that day. What were they signaling? It is worth my time to do this thing that someone else walked by. So that behavior of like making a mess and not cleaning up is not okay. And I think that really matters. With the operating principle, for instance, being meticulous with your craft,

you're saying maybe you see some new UI that's built or some new project. It's not meticulous. It's rushed. You as an engineering leader would, in a, respectful way, call it out. I would definitely try to as much as I possibly could. At Stripe, I personally did this in a couple different ways. We introduced a mailing list.

It got kind of hard to find the right component to file bugs against the bug filing system. So we made it super easy for anyone to report bugs. And then a lot of people would subscribe to that mailing list, so they'd see what folks were complaining about. And I just made it a real kind of ritual that if I saw things that were not kind of at that bar, I'd send them there. I'd try to be as supportive as possible

and kind of suggest how to do it differently. Sometimes I'd even like, you know, if it was like a copy change, I'd say, here's maybe the change we could make to make it as easy as possible. But that is a good way to kind of be clear about, you know, what the bar might be. Much later, we set up a system of like actually,

we called it Walk the Store. We'd actually like use the product in some company-wide meetings. Sometimes it was me. Sometimes there's other people. To be clear, not in a calling people out way, but in a kind of very supportive, like, this is what we're trying to aspire to kind of a way

to help convey that. So, yeah, that's a good example. So this walk-the-store thing, if I understand, you are in and all hands dog fooding the product publicly. And if there's a problem, you would say. Exactly that. Exactly that. That could be nerve-wracking.

Yeah. Another practice, which we use here at this company, and I learned at Stripe is the idea of friction logging. So one of the things that I think any senior leader can do, but I certainly find very effective, was to make sure that I was using the product. A lot of us probably work on products that it's not super easy for us to use every day. Maybe you're working a piece of infrastructure, your user is another team at the company. But finding some time every week or month or every six weeks to actually put on a different hat, your user's hat, and go through the process of using your product and write a friction log, which is everything that you ran into that was a little bit frustrating or a little bit, weird, and then use those to inform your team's priorities. That's a really valuable tool.

At this company, dev agents, we're building a platform for AI agents for consumers, but there's also a developer and creator experience. And we go through a process every single week of using everything and writing these meticulous friction logs that then informs what are we working on next. Of course, we want to hear from our actual users as well. It's just such an incredible tool. And that's another place where if you write those things and send them around, you can really kind of highlight what is good enough and what the bar is in the product. One thing that Stripe is really famous for is there's this, you know, many nines of reliability, just this really legendary engineering feat.

And, you know, of course, there's these engineering blog posts out there that, you know, people can read if they're curious how it's done. But what I wanted to ask you is the CTO of Stripe was, what are the intentional engineering culture changes that kind of enable that type of reliability? By the way, the team, during my tenure, I think we got Striped to more than five nines of reliability. I hear that last quarter they achieved six nines. That is an incredible feat. So, you know, kudos to everyone there who's working on reliability.

And for a business like Stripe, it really matters. You know, every second of downtime is like huge dollar losses in behalf of businesses. And they've got it like into like very, very minimal amounts of time in the year. It starts with being incredibly intentional, as you kind of correctly called. out. At Stripe, we had a really amazing and difficult but ultimately incredibly fulfilling year in 2020, which is obviously with the pandemic, suddenly there was a huge desire for a lot of offline business to go online. And so we ended up being in a state where our systems were scaling much faster than we had ever imagined. And against that backdrop, we knew that we had to

kind of really raise the bar on reliability in order to make sure that we were doing a stellar job of serving those businesses. So it really mattered for the business. But it was actually not something that the engineering org had been kind of wired for before. There were certainly been periods where like, this is an emergency, let's jump in and fix it. But earlier in that company's life, we've been very focused on let's make sure that we can find product market fit for all the things that matter for our users, which I think was the right thing to do. But at scale, reliability really mattered. So it actually was mostly a kind of like cultural change that was important to realize in order to pull this off. And as you said, there's a lot written about this. I won't go into

too much detail. But for me, it started with being intentional and then trying to give every team the tools to actually think about this in a scientific way so that they could make the right tradeoffs between feature work that we do and work they would do for reliability. So we did that by introducing this option that I've already mentioned, also a nested set of systems and meetings with a lot of tools to provide data and then kind of repeating opportunities to look at those data and decide what do we want to do about this in order to make it better. So it really is like get a lot of conviction that it matters and then set up a repeatable system that causes everyone to be able to have the right input and then look at it often enough to take the right action.

The other thing that is really awesome about that period of time at Stripe is that all of that progress was made against the backdrop also of just massive improvement in other infrastructure traits. Because we started measuring everything in a very systematic way and bubbling it up to a lot of people across the org, we were able to start making a lot of progress on not just reliability, but things like efficiency and performance as well. So it was a really special time. Reliability is it's not free. It comes with cost in terms of additional machines for redundancy, but also there's a lot of overhead and probably slowing things down. You know, let's do more diff reviews. Let's have incident reviews. Let's really make sure that if it's touching a risky code path, we go a little slower. Yeah. Did you ever, as Stripe think, is it too reliable and is it worth that tradeoff and cost? Yeah. First of all, I think on face value, that makes sense. You would think, oh, yeah, you need to run way more machines to be reliable. In actual fact, that Stripe, we pulled off the change that I just described while making the system significantly more efficient as well. I think, so I'm not necessarily talking about Stripe here, just like industry-wide. There are kind of two reasons that systems can be unreliable, at least two. One is you're trying to serve more demand than you have capacity for, and there you might decide to like over-provision things in order to, make it work well. And it also may be that you haven't like invested enough in kind of gradual degradation and partial, you know, serving, you know, partial availability and so forth. So that's this one reason. The other reason is just like when making changes, there are not

enough guardrails or systems to prevent things that engineers are trying to do legitimately to improve the product, to have them like break stuff in the system. And if you find yourself here, then you have to think a lot about things like overprovisioning. If you find yourself here, it's actually a completely different set of things that you do in order to fix that. So one of the things that we were able to invest a lot in at Stripe was having a huge amount of infrastructure for automated testing. And yes, there were periods of time where we said, hey, let's have more reviews or whatever, but then by investing in what are our systems to have lots of tests and have gradual deployment

of changes, it actually enabled the entire org to go faster. So I actually think that the industry-wide lesson I would take from the experience at Stripe is how can we have great automated testing and how can we have really good gradual deployment of changes where failures are detected before they are critical? And that goes for like changes that you're making in code, changes you're making in data, changes you're making when you flip feature flags for users, all of these things matter. And if you start paying attention to what's causing problems and then asking, you know, five whys behind them to see what changes can we?

make, I think you'll find that you can cover enormous ground. And actually, you know, in this particular case, we ended up not having to make that many tradeoffs in terms of productivity, and certainly not in terms of efficiency. So it really all was about the right systems for paying attention to the right data and the right mechanisms for gradual deployment of changes so that we would detect failures earlier. And that meant that we could have this amazing environment where every engineer, as they, you know, if you merge the change to Maine, it was going to production, like pretty much directly the same day through a kind of very deliberate set of gradual release processes, all fully automated. And that's a cool environment to work in. This is now

quite popular in the industry and certainly it's how we work at my company today. But when I worked at Google, you didn't get to ship directly to production. You merge your change and then like maybe every two weeks, someone would take the time to cut a release branch, test it, sometimes a lot manually, fix up some of the rough edges with some cherry picks, and then that would go to production. It would sit there and not change for two weeks. So if you were an engineer writing a change, you know, on day one, you'd merge your change, maybe up to two weeks later, someone would try to release it to production, and then it would sit in production for another two weeks. So it was like often a month between making your change and it being like fully live. It's really hard to iterate

in that environment. It's so much. much more fun when you can make a change in the same day, you can show it to your friends in the product, like so cool, and your co-workers. And that kind of enabling rapid iteration like that was a lot of how I like to think about the right way to set up engineering systems. I see. So if I'm understanding, you're saying that with the right investments in shifting left, so catching regressions earlier, you don't even, you don't make that tradeoff between derisking. You actually can move fast and be safe. That's right. There's a good book called Accelerate by Nicole Foresgren, which touches on a lot of this.

Not quite all of it, but a lot of it, so I recommend that book. One of the last things on Stripe is Stripe was very well known for the engineering talent. And I'm curious, what are the material actions that the company would take to hire such strong engineers? I think the first thing that's important to know about Stripe is we had a lot of amazing engineers that actually wanted to work at Stripe. would reach out to us. And usually the reason for that was that they had a great experience with Stripe's product. At the core of Stripe's product, there are many different ways you can use it, but the core is a developer platform. I think it has a deserved reputation for having some of the best documentation in the industry. By the way, there we considered building the docs,

part of building the product. So it wasn't something that a separate team worked on. The product teams worked on that. The APIs are designed nicely. You took real pride in the presentation of both the product experiences and the marketing page and so forth. So to some extent, like, ship a great product and then people will want to come work on it. And that matters a ton. Of course, we also had to make sure that we were evaluating people in the right way. At the time that I was joining Stripe, the industry was still doing a lot of whiteboard interviews. You know, you'll write code on a whiteboard during an engineering interview. Certainly all the interviews I did before Stripe were like that. And we believed and believed today that that's actually like not a great way of simulating what it's like to see an engineer do work.

So at Stripe, we designed an interview process where folks would actually be on a laptop with all the tools that they were used to having and pair program with an interviewer. And we try to give the most kind of realistic experience of work that we could. The programming exercises were very deliberately designed in order to make sure that we were selecting for folks that want to be meticulous in their craft, that did have the core engineering and design and kind of inquisitive skills to go and find the right things that needed to work on. And I think that's a big part of how we were able

to maintain that talent bar over many years. One of the common things I hear about leak code and why it's used at the largest companies is that to do what you did at Stripe at scale is challenging, you know, maintaining those. People are going to probably leak those questions and all of that. So how does it? How did Stripe do it successfully? Because Stripe was a, it is a very logical. I'm not going to lie. It was hard work. It is the case that interview questions get leaked online. And as soon as that happens, you need a new interview question because you want to make sure that you're fairly assessing people and like getting a real read, not the people who searched for it on Google beforehand. So it's hard work. There were a decent number of engineers at Stripe that were very passionate about this. And they also did a good job of kind of getting other people passionate about it. And so it was a volunteer effort to build those interview questions.

It's important, I think, as leaders and managers to make sure that folks that contribute to those kind of efforts are recognized. So, for instance, I would get up at engineering all hands and say thank you to the folks that have done this. Honestly, it contributed to their advancement in the org. You had to get your core work done really well. But if you're doing things like that, it was also really valuable. And it really just came from, like, actually caring about it. So if you tell me that meta or Google don't have the resources to build good engineering interviews, I don't believe you. You know, they could totally do this if they wanted to.

It's really just a case of like a revealed preference of how much they care about it. By the both amazing companies, I'm not criticizing them. But I think if you really care about something like this, it's possible to apply the hard work to make it work well. Earlier you mentioned, you know, what Stripe did to draw in the talent, even pre-assessment. And it sounded like you were saying that if you want to attract excellent people, build something that's excellent. Is that right? it's probably neither necessary nor sufficient. I think you can probably attract great people to work on a thing that's not great

if you pay them beyond market or whatever. But people are really excited to come and work on something that is like demonstrably awesome. So I'd much rather do that than the contrafactual. And then is it sufficient? No. Like it also has to be clear that you can, you know, learn a lot, advance your own career goals, be surrounded by people that you're going to want to spend those precious hours of your life. with. So I think it's neither necessarily nor sufficient, but it certainly goes a long way. As the CTO of Stripe, you had proximity to Stripe's leadership team. I'd love to hear what are the

things that you learned from such talented people. Yeah. So, I mean, I've alluded to many of these along the way in this conversation, but I think the thing that I learned most from my friends and peers on the leadership team was the value of thinking from first principles. So, I would also say I was not very good at this when I joined. At Google in particular, you know, that company invented a lot of the ways of working in our industry back then and today. And it was very effective. You know, what an amazing business. Great products. So when I was at Google, I would often be like, well, we've got to do this thing. How did we do it last time? And we'll just use that again. When I came to Stripe, it was a very constant refrain and kind of way of framing

things that when we were faced with a problem that we need to solve, we wouldn't, just say, how did we solve it last time? We would say, from first principles, what is actually going on here? Can we deeply understand the dynamics and how can we figure out what to do? And another way of thinking from first principles was to go and ask people at multiple external companies how they'd handled similar problems before and then triangulate on the right solution. And that was really eye-opening for me. It's definitely something I try to continue to do today. And it was quite a different way of working. Again, you know, we want to solve a problem. Let's take time to go and talk to for people at other companies that have seen something like this before, that could sound very slow.

But if you're applying that in the most consequential places, it's amazing how much you can benefit from multiple perspectives and then reason from first principles about the right way to move forward. It sounds like you're saying it is a useful tool, but not in every single place. Because also, I mean, at this point in your career, you have seen so many patterns and you have had successes that maybe sometimes we're short-cutting and using the experience. Yeah, I think it's actually remarkable how frequently it does benefit to take a quick step back and think from first principles and actually check yourself and say, you think you've seen this

before, but have you? And then, you know, maybe 80% of the time it's like, yeah, this is the thing I've seen before, go do. But 20% of the time it's like, oh, this is subtly different. Let me go and see if I can get some other opinions. But you're right. It's not a tool to be used in every single thing every day, otherwise everything would grind to a halt. Coming away from Stripe,

I saw you recently left to start your current company, which is dev agents. And I would love to hear more about what the company's building and maybe we can start with the story behind you leaving Stripe and wanting to build this.

Sure. We're building this new company, dev agents. We are focused on building a platform. We call it a next generation operating system to make it possible for AI agents and agentic apps to work for everyone, for people. So we're solving this problem for consumers. There are a lot of companies out there building agents and agent infrastructure for enterprises, and that's a little bit of how I got into

knowing that this was worth solving, but we're specifically focused on how can we apply this technology for everyone. And I think that's like super exciting. And also it means that there's some really big problems to solve. So I'll get back to those, but let me tell you kind of how we got started. So I mentioned earlier that I started my career in the early days of mobile. So I was working on smartphones before they were a thing. And at that time, I got this like really deep conviction that this technology mattered. And yet we had to solve, you know, building, by the way, we kind of glossed over this at Google. I ended up working as part of the Android team. And Hugo, my co-founder, was part of the very early product team on Android. Nicholas, who's my other

co-finder also designed a lot of the core mobile interfaces and then worked on Chrome. So like we're kind of, we're all geeks for this set of problems of there's a technology and we have to figure out how to invent the right patterns to apply it for people at scale. So back then, it was so much fun and so fulfilling to think about all the ways that people were going to use this technology and invent things like the right permissions model, the right application affordances, like, you know, how do you structure a UI? You know, I also worked on wearables. How do you get the right UI onto a watch and so forth? And at Stripe, as really powerful AI models came out like GPT4, I had the opportunity to apply them to problems inside of the business.

We were building some of the world's first AI agents. We didn't know to call them that yet. But, you know, we were using an LLM, having it perceived some data, reason, and then take some action. So that was, you know, some of the first AI agents. And I got really obsessed with the idea that this is as breakthrough a technology as the early days of mobile. And I started tinkering with this stuff in my free time, nights and evenings, and realized many of the problems that need to be solved to make this work for people are analogous to some of the problems that we solved back then. It's important to have some place where agents and agentic apps can exist, where they can have context on the user, where they can work together, where all those problems around privacy and security can be solved,

but in such a way that real value is created for people. And then also, it's a dual-sided marketplace. Just like the early days of mobile, we need a way for developers to have access to a bunch of people. We need a way for people to have access to all of the experiences that have been crafted for them by developers, builders, creators. So that's what we're doing here. the inspiration really did come directly from seeing that this is a very similar moment to that early stage of mobile. And yeah, it's been a lot of fun. There is a lot of hard work to do, but I'm excited about what we're doing for people at scale. So I'm trying to understand what is the product here.

So it sounds like it's infrastructure. Like a consumer would not know the words dev agent. It's that the consumer would see, this is my airline agent, and some developer built that. And behind the scenes, they're using what you're offering. We are actually building the platform that they will use to both find those agents and agentic apps and use them. Dev agents is a company name. It is not a product name. But they certainly folks will eventually be using, you know, the things that we build as a way to access all of the experiences that other people are crafting.

And, you know, as part of that, we need to build all of the right tools and experience for those developers, crafters, to build really powerful and valuable agents. And we have to make them really accessible for people. That's right. The AI industry right now is like a war zone. I mean, there's so much interest. And because of so much interest, there's so many people competing. I'm curious, you know, how do you see yourself out competing big names like Open AI who probably have interested in the SIGs? exact thing. Yeah, absolutely. One of the things that I think about a lot is in the early days of mobile, we expected that the folks that were going to win the market would be the Nokia's and the Sony Erickson's of the world. They had, you know, the first mover advantage. And they did a great job in the early days. But ultimately, what was necessary for mobile to really work really well for

people was to invent whole new paradigms. So like the iPhone had to come along and Android had to come along. So I don't think that it is a kind of foregone conclusion that the folks that are kind of applying technology in any space at the very beginning are the ones that end up making the biggest impact. I think there are amazing companies out there that are going to have a lot of impact. We happen to be taking a very differentiated approach from any of the experiences I see in the market right now. I'm not quite ready to share what it is. But you know, you will see. it before too long and it is it's it's pretty different and that's important because I think we have figured out some of the some of the kind of key opportunities and constraints that are necessary

to make this new technology work for consumers at scale a big part of how we thought about this is not like what is this company doing or that company doing but what do people need like what are the use cases that matter how can we unlock kind of compounding value if multiple developers or building agents in this environment, how can they work together in order to work really well for people? And that's what we're kind of laser-focused on. So it's pretty different. Watch the space.

And in fact, we're right at the moment now where if that sounds exciting and you're the kind of person that likes to tinker with new technology and build things, we'd love to consider having you as an early adopter of the platform as a creator and developer of these agents and agentic apps. So if you go to sd-d-a.a.i, that stands for slash dev slash-a-a-a-a- agents.AI slash build. That's where you can sign out to be one of our creators in our early access

program. Across your career, you started as an IC. You went all the way up to some of the highest levels of leverage in these organizations. And now you're on a small team. And I'm curious, what does the day-to-day look like now? Like, is it, how different is it from that first time you were in a frontline manager? I'd say that the way that I work today is quite different. from the very first time I was a frontline manager, mostly because of just all the experience I've had along the way and the lessons that I've learned. So I am constantly trying to apply all of the stuff that I talked about

in this conversation. You know, I'm stepping onto the balcony to make sure I'm looking at how everything's working periodically. I put a lot more energy into both preparing myself for every week and trying to make sure that the team are prepared for what are the most important things for us to work on this week. Whereas, you know, very early in my career, it was a lot more kind of follow your nose and do kind of the most obvious next immediate thing.

And so quite profoundly different is the short answer. But also, there's so much that is similar. And, you know, this both feels a little bit like home and also feels like a wonderful new challenge. And you obviously mentioned how competitive the AI industry is right now. That is true. I wouldn't want to work on anything else. Like I really strongly believe that this is a profound leap forward in technology. and I, as a technologist, I couldn't imagine not working on it. It certainly is hard work, which is very rewarding. But I think we're creating a lot of type two fun right now. Coming to the end of the interview, I want to do some career reflections going over everything that you've done so far.

So if you were to look back on your career, kind of with this retrospective lens, kind of like an incident almost, you know, what would you say went well? What do you think didn't go well? Maybe we can talk through that. So in terms of things that went well, one, I do think that I was very fortunate in some of the very early, you know, choices or kind of things that I got thrown into. Finding myself at Symbian, which has been completely formative for the rest of what I've done, was honestly pretty random. So I don't know what anyone can take away from that, but that definitely was very useful. I think for me, I mentioned that the reason I stayed so long at Google and, you know, also kind of why I, enjoyed quite a long time at Stripe so much was focusing on always making sure that I was learning.

I think that has been incredibly important and valuable. And I have made choices to move teams within companies specifically because I thought that was an opportunity to learn things that would put me outside of my comfort zone. I mean, an example of that, I worked on mobile at Google before Android. There was then a weekend where I remember very clearly mobile search. There were more queries than desktop search. That was like a real wake-up moment for the whole company. It was like, we got this little team on the side building all this mobile stuff, but now it's mainstream. And we actually did this really brave thing, I think, of like deciding to disband our team and push it out into all the rest of the company. And as someone who's working across a bunch of stuff

in mobile, the default path for me would have been to at that time go join the Android team. I did later join the Android team. But what I decided to do was I thought, well, that's going to be, that's cool. I was already working on a bunch of Android apps. I'd already had the opportunity to inform some of the kind of core of the operating system. But I thought, hey, the best thing for me to learn at Google right now is if I go and work on ads, because I had no idea how Google made money. And so I did that. And it put me way outside of my comfort zone. I was like already like reasonably senior. Most people who were in that org had kind of grown up in the orgs. They knew everything. I had to learn at a tremendous rate. But man, it was awesome. I mean, I know I understand how like

all of those auction systems work. And I understand the publisher and advertising. business model and so forth. I wouldn't know that if I hadn't taken that leap. So focusing on always learning, I think, is something that has stood me in good stead. What about looking back? Is there anything you regret where you thought, you know, I could have changed that and that would have been a lot better. Yeah. I mean, look, there are a lot of things that with the benefit of hindsight it would have done differently. Hopefully I've been fairly transparent than that during this conversation. I mean, I mentioned how I think I was a pretty lousy manager at the start because I was focusing on helping people be happy rather than like, how do we get the most impact? I just.

You know, when I was a very early stage engineer, I didn't speak up in meetings that often because I kind of assumed that my manager and like their manager, like they kind of knew it all. They had it all sorted out. And why do they want to hear from me? I'm just like this, you know, newbie. But actually, what you realize as you go through your career is the people who have the very most context for everything going on are the folks that are actually doing the building at the one foot level, right? So in many of those meetings where I was sitting there thinking, I don't think they're wrong, but they must know, right? I knew because I was the one doing the work.

And of course, you know, now that I have been in those rooms as the more senior person, like, I really wish I created a culture where people would speak up, right? And so that's maybe something that I would try and take away is a mental model what they're thinking about. They're just humans. Everyone's just a human. They only know as much as any human could possibly like pars into their own brain. And if you are the expert and really know something, assume that they're wrong and speak up.

And I find that in the companies that I worked at, that was always rewarded. And it's something I seek to reward in my organizations as well. Obviously, I don't want to give everyone bad advice. If you're in an organization that kind of patently does not reward that, like maybe go work somewhere else. But most good companies work like that. And I think that that's something I wish I'd known a little bit sooner. And is one way to know if a company's like that as if the titles, are less in your face.

Yeah, I mean, I don't think there's any, like, one hard and fast rule for this, but, you know, it's certainly the case that, you know, Google, back when I joined, most people, if you joined at the actual entry level, which I did, you got given a job title, but most people were given this title, which was a member of technical staff. And the whole point there was, we're not going to say what your level is in a publicly kind of discernible way, because we want people to listen to your ideas, not just because of, like, your title or who you are. And I think that's like a trait that's common to organizations that work that way.

It's not the only one. I think just if you see people speaking up and making good points and then they are listened to and, you know, encouraged to speak up again, that's probably another good sign. Well, I had no idea that early Google also used that title. Yeah. I thought, well, maybe the source was Bell Labs. I think the source was Bell Labs. By the way, it's amazing the kind of like family tree of all the practices in our industry.

I'm pretty certain that Bell Labs. Labs was the progenitor, but it definitely was the way Google worked when I joined Google, which was 2005, 2006. Is there a top recommendation for a book that really impacted your career? I'm sure you've heard this one before. High Output Management by Andy Grove. So Andy Grove was the CEO at Intel, and I just talked about the family tree of all the business practices in our industry.

It turns out that like almost every way of working that I ran into at Google and assumed that Google had invented actually came from Andy Grove. So like OKRs are there. He talks about how to do a fashion one-to-ones, et cetera. It's a really short book. I read it on one flight. And it's, I mean, it was a flight from London to Mountain View. So, you know, give yourself a few hours. It's like interesting. Like, it's a bit of a page turner. And so many of the practices I'd seen at large actually come from this book. And, you know, there are certainly some things in there, which probably don't make so much sense anymore. But as a moment that made me think differently about how to like run everything I do at work. Reading that book was pretty pivotal. Habits are very powerful,

especially they compound over time. I'm curious, is there any habit that you took with you throughout your career that really had an impact? There definitely is one. So for the longest time, I would just kind of do whatever was coming at me. Like I'd get email and I'd like work on it or I'd have someone would put a thing on my calendar and I'd do it or I'd have all of the one to ones with my team scheduled so I knew that like I'm going to Brian's one to one tomorrow so I should work on that. So like my calendar and my inbox kind of like ruled me. And I was setting some goals and so forth, but they kind of ruled me. And I realized that's like completely backwards. If you want to, if you want to make something happen, you should just like figure out how to make it happen and go do

those things. So I practiced that I started many years ago, certainly during my time at Google, was I started writing a essentially a to do list for myself. for every week. I found that a week is the right level of granularity. And so on Sunday nights, I would just take a moment to think, what, if I have a great week this week, what did I get done? And I write those things down. And I actually, the dock that I put these in, I call it my rocket doc. Like I gave it the emoji title of a rocket as soon as Google Doc supported emojis. And that's kind of like the energy I want out of that thing. And then, you know, during the week, that is my, that's the thing I come back to all the time. So I'm like, what am I supposed to do next?

Don't go to your inbox. Don't go to your calendar. Go to the Rocket Dog. That has been really great. So being deliberate about what to work on. Later, so I started that when I was, you know, just me, you with folks on my team. Much later, I had the privilege of having a couple of tremendous executive assistants that would help me. And something that was a real kind of cheat code, I guess, was I'd share that doc with them.

And then I'd say, like, our collective goal is to make sure I actually spend my time. time on this stuff this week. So, you know, by middle of the day Tuesday, my EA would ping me on Slack or whatever, depending on where it's working, and say, like, how are we doing against these things and start chasing me to do the stuff that I wanted to do? It was amazing. And they could, like, help make sure that I spent my calendar and so forth on that as well. So that habit is pretty important. I want to mention one other habit as well. Exercise is really important. I realize that every time I was finding myself being like pretty grumpy at work and a bit unhappy. Just because I'd like forgotten that you have to exercise.

It makes endorphins. It makes you feel good. So like if you're ever like in a funk at work, just like make sure that you're like working hard a few times a week. It's amazing how often that was the thing that I just had to do to keep myself on an even keel. And the last question that I wanted to ask you is, you know, if you could go back to yourself when you just graduated from college and you were right about to enter the industry, and you could give yourself some advice, what would you say?

It's a really good question. I think I'd repeat that piece of advice, which is when you're in that moment where you know a thing and you assume that it's because you're not the person who's in charge, just speak up. I think good things happen. And I think that if I'd done it a bit more,

even more good things would have happened in the spots that I was in. Well, thank you so much for time, David. I really appreciate it. This was a really interesting conversation. Now is your opportunity if you want to tell the audience anything and you can go ahead and speak. We're building a really small talent dense team here at dev agents. So there aren't a lot of spots for folks to join. If you think that you really are excited about this and you're one of those people, you're

welcome to send me an email. We can put my email address in your show notes. But in particular, if you're someone who'd like to tinker with our platform, and build some new and exciting genetic apps and experiences for people. SDSa.ai slash build. We'd love to see if we can get you in the early access program. All right. Thanks so much.

Really appreciate your time. Thanks a lot. Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. if you want to drop a review, that'll be super helpful. And if there's any guests that you want to bring on to, please let me know.

I feel like sourcing very senior ICs. There's no well-studied list out there on Google that I can just search this up. So if there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out to them.