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

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 https://www.developing.dev/p/stripe-cto-on-what-grew-his-career • Youtube https://www.youtube.com/watch?v=hl6Ryc_NUm8 • Apple https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835 Timestamps: (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) Outro Where 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: [email protected] • X/Twitter: https://x.com/dps • LinkedIn: https://www.linkedin.com/in/davidpsingleton/ • Threads: https://www.threads.com/@davidsingleton Where 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/@petermanpod This episode was produced with the help of SF Podcast Studio: https://www.sfpodcast.studio/

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  Teams that are perfectly happy are rarely performing at their very best potential.

• 0:06Ryan Peterman?

  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.

• 0:18Speaker 00

  Funny story.

• 0:20Ryan Peterman?

  Really?

• 0:20Speaker 00

  When I was made a director at Google, they said, hey, the secret is.

• 0:24Ryan Peterman?

  Later, he became the CTO of Stripe and explained how they hire without leaked code.

• 0:29Speaker 00

  The industry was still doing a lot of whiteboard interviews. That's actually like not a great way of simulating what it's like to see an engineer do work.

• 0:37Ryan Peterman?

  We also chatted about the AI startup he left Stripe for. How do you see yourself out competing big names like OpenAI, who probably have interest in this exact thing?

• 0:47Speaker 00

  Uh, I'm gonna choose to answer this question differently. So.

• 0:50Ryan Peterman?

  Here's the full episode.

• 0:56Ryan Peterman?

  The first thing I wanted to ask you is, how did you get into programming to begin with?

• 1:00Speaker 00

  Like many people, I got into computers 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 eighties, early nineties, a lot of kids were like 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 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.

• 1:42Speaker 00

  So my sister and I would notice that like once a quarter, they'd get super grumpy and it's because they were up all night, like tabulating their accounts. And once we 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.

• 2:03Ryan Peterman?

  After you graduated from college, I understand that the first role that you had was at Symbian.

• 2:07Speaker 00

  That's right.

• 2:08Ryan Peterman?

  Can you tell me the story about working at Symbian?

• 2:11Speaker 00

  Yeah, well, so first of all, it's a funny story how I ended up there. I actually originally planned, 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 in England and I had to find a job at pretty short notice. Some folks from Symbian 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 liked the people, but then as soon as I arrived, I realized, wow,

• 2:56Speaker 00

  we are working on technology that we all believe, and I certainly believed was going to have a profound impact on how people use computers at scale. It was just obvious that it was inevitable that we're all going to have these little smart computers in our pockets. But we were inventing stuff there that, you know, 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 Symbian OS and also some of the PC Connect software.

• 3:41Speaker 00

  But then the final couple of years I spent at Symbian, I think were actually pretty formative for me in terms of what came next. So I went from being a, you know, IC 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 Symbian OS into actual handsets, into actual products. So Symbian 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

• 4:24Speaker 00

  project executed again and again and again by teams at different companies. So I worked with companies like Panasonic in the US, Samsung in both Korea and China, Nokia in Finland, et cetera, et cetera. 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

• 5:09Speaker 00

  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 small teams. And as I understand it, they would give multiple teams essentially the same mission, the 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.

• 5:49Ryan Peterman?

  Would you say that that role was similar to the popular role of forward deployed engineer in the industry today?

• 5:55Speaker 00

  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 Symbian. And so, yeah, I guess it was. We didn't call it that back then, and I don't 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.

• 6:34Ryan Peterman?

  So you talked about the 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.

• 6:44Speaker 00

  Yeah, so I was living in London at the time, working for Symbian. And this was immediately post-Google's IPO. And I guess Google, like, we had already recognized that Symbian 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 Symbian 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.

• 7:28Speaker 00

  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.

• 8:13Ryan Peterman?

  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 at a complacency. They're constantly actually almost trying to leave, but that place is treating them so well that they end up staying rather than, you know, job hopping.

• 8:31Speaker 00

  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.

• 9:15Speaker 00

  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/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. And I remember talking to my coworkers and being like, this is bonkers, right?

• 9:57Speaker 00

  We were wasting 2.5 seconds of users' time every time they access this page. And everyone was 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 I 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.

• 10:39Speaker 00

  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.

• 10:51Ryan Peterman?

  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?

• 11:00Speaker 00

  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 the next week, eventually, it was like Germany."

• 11:43Speaker 00

  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.

• 12:03Ryan Peterman?

  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 gonna chase that." And so I could totally see why that was very motivating for you as an engineer.

• 12:35Speaker 00

  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.

• 12:55Ryan Peterman?

  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?

• 13:16Speaker 00

  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 was 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

• 13:58Speaker 00

  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,

• 14:38Speaker 00

  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, 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 first version of Google Translate on the iPhone. And that was cool. It gave

• 15:19Speaker 00

  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 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.

• 15:51Ryan Peterman?

  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.

• 16:07Speaker 00

  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 now at 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 Stripe, I worked with this management coach,

• 16:50Speaker 00

  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.

• 17:24Ryan Peterman?

  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?

• 17:34Speaker 00

  Funny story.

• 17:35Ryan Peterman?

  Really?

• 17:36Speaker 00

  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 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 found 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,

• 18:19Speaker 00

  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 in the code base. And I think that the 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.

• 18:59Ryan Peterman?

  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 IC 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?

• 19:41Speaker 00

  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. Just, 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. Like, that is, you know, 95% of where you need to spend your time. But

• 20:25Speaker 00

  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 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

• 21:07Speaker 00

  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-ation. 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 in 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

• 21:49Speaker 00

  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 like, 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.

• 22:34Ryan Peterman?

  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

• 22:50Speaker 00

  That's right.

• 22:51Ryan Peterman?

  thing for yourself.

• 22:52Speaker 00

  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.

• 23:21Ryan Peterman?

  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?

• 23:37Speaker 00

  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 in 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.

• 24:16Ryan Peterman?

  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?

• 24:29Speaker 00

  The advice that you mentioned, which is, hey, being a manager and being an IC are different jobs, don't try to complete 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 IC 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

• 25:13Speaker 00

  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

• 25:56Speaker 00

  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 it 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.

• 26:38Speaker 00

  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.

• 26:46Ryan Peterman?

  You mentioned at 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?

• 27:09Speaker 00

  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 most fulfillment out of your work is to try and figure

• 27:54Speaker 00

  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 on my own work in that way ever since. And I feel very confident saying, I feel significantly more fulfilled for it.

• 28:37Ryan Peterman?

  I think, I mean, there's so many things to optimize for in 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.

• 28:53Speaker 00

  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.

• 29:00Ryan Peterman?

  At Google, I understand that you went from a entry level IC all the way to VP of Engineering. And that's, you must have a very unique perspective because almost no one gets promoted to levels of that height. So I wanted to ask you, because you went through levels of magnitude of management. I wanted to hear your perspective on the differences.

• 29:23Speaker 00

  Yeah.

• 29:24Ryan Peterman?

  I was curious, the first step is frontline manager versus manager of managers. When you made that jump, what was your biggest skill gap?

• 29:34Speaker 00

  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.

• 30:15Speaker 00

  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,

• 30:58Speaker 00

  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 will 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 like 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,

• 31:42Speaker 00

  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 how do we do things like product reviews? How is our hiring process working? Only in some companies can managers 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

• 32:27Speaker 00

  the organization I was running as if it was a little bit of an operating system. How do 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.

• 32:42Ryan Peterman?

  Am I understanding correctly that if a team is too happy, that's actually a red flag for you?

• 32:51Speaker 00

  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

• 33:31Speaker 00

  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?

• 34:01Ryan Peterman?

  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.

• 34:15Speaker 00

  It's a great.

• 34:16Ryan Peterman?

  You know, teams that are breaking.

• 34:17Speaker 00

  It's a great analogy.

• 34:18Ryan Peterman?

  You should, there should be some downside, that you're too far.

• 34:21Speaker 00

  That's right. Yeah.

• 34:23Ryan Peterman?

  You know, we talked about frontline manager versus manager of managers. Now I'm curious about the step that very few people ever experienced, 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 were VP?

• 34:42Speaker 00

  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 skillsets 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

• 35:26Speaker 00

  had tended to think of like, well, all the other functions kind of exist to like feed the engineers to help. 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,

• 36:10Speaker 00

  you do have this like 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 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, 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.

• 36:56Ryan Peterman?

  Did you ever consider that engineering occasion tool, but for the other roles?

• 37:02Speaker 00

  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 do 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.

• 37:45Ryan Peterman?

  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?

• 37:57Speaker 00

  So there's, 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, more kind of chances to practice this.

• 38:40Speaker 00

  And I got sent along to speak to whole auditoria of Google customers. So I was working on ad stuff at the time. I remember doing one of those in an office near King's Cross 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 definitely still learning to do better.

• 39:21Speaker 00

  Today I use Claude a lot to help with that, but I think if you can condense the most important things you need to convey into a short, clear document.

• 39:36Speaker 00

  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, thirty percent 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

• 40:16Speaker 00

  established, then it becomes really easy and scalable to read things and kind of take it from there.

• 40:23Ryan Peterman?

  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, I'm like, 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, so.

• 40:55Speaker 00

  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 helped 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 other 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

• 41:40Speaker 00

  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 body Language of, you know, the CTO. I find myself kind of keeping that in mind a lot. And I, I'm 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,

• 42:24Speaker 00

  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 a hundred people. And think, what am I actually trying to communicate here and make sure that I'm using the dynamic range?

• 42:43Ryan Peterman?

  A lot of engineers who get into leadership roles, they're tasked with this, you know, giving their top of mind and all hands, et cetera.

• 42:51Speaker 00

  Yeah.

• 42:51Ryan Peterman?

  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?

• 43:09Speaker 00

  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, 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. The least you can do is spend 30 minutes of your time preparing. That'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.

• 43:53Speaker 00

  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, 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.

• 44:38Speaker 00

  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.

• 44:48Ryan Peterman?

  For writing, the thing you called out was condensing the writing. And you recently wrote this post about agents crossing a chasm. And I scrolled to the bottom of it and there's this thing, so it says Ari Grant, a bunch of these people had reviewed it.

• 45:04Speaker 00

  Yeah.

• 45:04Ryan Peterman?

  How important is the people reviewing your writing in that process of condensing?

• 45:10Speaker 00

  Yeah, this is something I learned at Stripe. I used to write blog posts and just throw them out onto the internet. And, you know, 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, 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.

• 45:51Speaker 00

  It's actually quite common that I would share something I've written with, you know, a friend or former coworker 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. All right, 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.

• 46:16Ryan Peterman?

  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 higher. What are those ways that you think are really high leverage ways to scale yourself aside from coaching your direct reports?

• 46:33Speaker 00

  Yeah, so I alluded to this. One of the tools in your toolkit as you become like quite senior is to start thinking about how the organization works, the rituals, the processes. By the way, when I was a early career engineer, I used to think that the word process was kind of like a dirty word. In fact, at 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're 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 9001 certification or something, which is like this British, or 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, gotta, gotta move, right?

• 47:15Speaker 00

  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 out. So I didn't, I'd never really heard the word process before and I thought of processes as this kind of like joke, honestly. And then I found myself being, you know, an organizational leader and I was like, if someone told me, David, just really think about the processes in your org. 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

• 48:00Speaker 00

  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 in 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 directs and having it kind of trickle down. So that's the main tool.

• 48:32Ryan Peterman?

  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?

• 48:42Speaker 00

  I think as

• 48:45Speaker 00

  Someone who is in control of our 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?

• 49:26Speaker 00

  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 boxed into continuing a thing for no particular reason.

• 49:40Ryan Peterman?

  But how do you prevent that if, you know, let's say you're, you know, you're the VP, you're 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.

• 49:52Speaker 00

  I can tell you worked at Meta because you call them SEVs.

• 49:54Ryan Peterman?

  Oh, yeah.

• 49:54Speaker 00

  Yeah, SEVs, incidents, it's all the same thing.

• 49:57Ryan Peterman?

  Yeah, yeah. Well, you know, 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?

• 50:09Speaker 00

  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 it's, 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.

• 50:49Ryan Peterman?

  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 is important. Like if you gave the context behind why it's impactful.

• 51:01Speaker 00

  Yeah, that's a, 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 have completely different outcomes.

• 51:18Ryan Peterman?

  One topic that I want to touch on, and this is something that actually Philip mentioned specifically, which is that, you know, Philip is, there was another 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.

• 51:40Speaker 00

  Wow.

• 51:42Ryan Peterman?

  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 started 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?

• 52:03Speaker 00

  Yeah. Well, so Philip Su 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. It 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, you know, 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

• 52:47Speaker 00

  doing back then. And 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.

• 53:30Speaker 00

  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 hour 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.

• 54:13Speaker 00

  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 in 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 are so many of them that you can't make progress in that little time window and progress runs to a halt. So for, for those teams, that's, 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.

• 54:59Speaker 00

  I remember asking him, so I was like a relatively junior engineer and I was like, "Hey Shannon, why are you never here?" And 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.

• 55:44Speaker 00

  "Make sure the capabilities of the team are very clear so that folks understand if I need to "Implement some like 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 to 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?

• 56:28Speaker 00

  "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 at the work. So the trick is like have enough of an identity that folks think about collectively helping each other and make sure that that

• 57:12Speaker 00

  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.

• 57:20Ryan Peterman?

  And when you say culture, you don't just mean Google, you mean Google London.

• 57:25Speaker 00

  Google London.

• 57:26Ryan Peterman?

  You're a clan.

• 57:27Speaker 00

  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.

• 57:46Ryan Peterman?

  And if I'm understanding correctly, the further away the time zones are, the more independently you'd want each site to be able to execute.

• 57:54Speaker 00

  That's right.

• 57:55Ryan Peterman?

  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 do 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?

• 58:18Speaker 00

  Yeah. So at Stripe, we had a remote hub well before COVID. So we really recognized that there is amazing technical talent everywhere. I mean, certainly all across the US, 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

• 58:59Speaker 00

  hard to make sure that conversations that would happen between individuals on the same team, if they happened to be on a video call or happened 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, 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 that 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 were bought into the decisions once they happened. So those are the most important things, I think, to make

• 59:42Speaker 00

  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, you know, went out for a drink and had a chat about all 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 could 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 and certain circumstances, I think, remote can be, you know, almost as effective as if you're all just jamming

• 1:00:27Speaker 00

  in one spot together. I do personally believe, though, that the very 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 will 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, you know, 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

• 1:01:10Speaker 00

  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.

• 1:01:23Ryan Peterman?

  Coming to the end of your time at Google, I saw that after you were promoted to a VP, you 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 you at that time.

• 1:01:42Speaker 00

  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 or 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.

• 1:02:26Speaker 00

  I think it 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 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.

• 1:03:12Speaker 00

  It was actually Philip Su 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.

• 1:03:25Ryan Peterman?

  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.

• 1:03:33Speaker 00

  We're definitely in a tussle for the best talent in London.

• 1:03:36Ryan Peterman?

  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.

• 1:03:44Speaker 00

  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, to bond with someone that I was sometimes on the other side of the table from.

• 1:03:59Ryan Peterman?

  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 Stripe.

• 1:04:12Speaker 00

  That's right.

• 1:04:13Ryan Peterman?

  I'm curious, what was the company idea? What's the story there?

• 1:04:17Speaker 00

  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. If someone out there wants to build this company, give me a call.

• 1:04:30Ryan Peterman?

  Would you fund it if someone is trying to start?

• 1:04:33Speaker 00

  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, you could get some help. And I actually used 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

• 1:05:18Speaker 00

  forth of actually working for a company. So the idea was essentially like, make it possible to have fractional folks in those, you know, 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, you know, an in-house firm. And we were, we're 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.

• 1:06:03Speaker 00

  What I realized as soon as I spent time with folks at Stripe was

• 1:06:10Speaker 00

  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 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.

• 1:06:56Speaker 00

  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 and 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.

• 1:07:18Ryan Peterman?

  In the post, it almost sounds like you went to them for advice on starting the company. Like, that is correct. So how, when did you realize the conversation was turning towards they're recruiting you?

• 1:07:31Speaker 00

  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 like, oh, that was actually pretty good advice. So I did reach out for advice on 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. But 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.

• 1:08:13Speaker 00

  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, you know, 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.

• 1:08:56Speaker 00

  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.

• 1:09:33Ryan Peterman?

  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 promotion is again, probably very bespoke. So what is the story behind getting promoted from a head of engineering to CTO?

• 1:09:49Speaker 00

  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 can actually help and have enough agency to 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,

• 1:10:33Speaker 00

  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.

• 1:11:12Speaker 00

  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.

• 1:11:30Ryan Peterman?

  Definitely, and I've heard a similar opinion of, you know, at a large company, the organizations within the company are almost strangers as well. So, you know, 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.

• 1:11:49Speaker 00

  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 on 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.

• 1:12:34Speaker 00

  And at Google at that time, it was directors.

• 1:12:36Ryan Peterman?

  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 move fast and break things and all of these principles. Similarly, Google has its own principles. Amazon has its own principles. I thought it'd be interesting to hear your take on which big tech companies engineering culture you thought is most well-designed and maybe less well-designed.

• 1:13:07Speaker 00

  Yeah, well, I'm at a bit of a disadvantage here because I've only worked at Google among the big, 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. The, 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. You know, 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

• 1:13:49Speaker 00

  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, 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

• 1:14:35Speaker 00

  inspiration from, even though I've never worked there. I actually joked with a friend recently, I was 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 this thing called Apple University. Everyone who joins 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 smallest board.

• 1:15:16Speaker 00

  But unfortunately, I've only worked at one big company and I've only really gone deep with leaders at one other.

• 1:15:22Ryan Peterman?

  When I look at Stripe's operating principles, I do see the Amazon influence specifically in it's users first and at Amazon, it's customer obsession. I think those are kind of similar in my mind.

• 1:15:38Speaker 00

  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 for 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 find product market fit in their core, which is, you know, the payment infrastructure for early stage businesses, they've 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?

• 1:16:23Speaker 00

  And so Stripe's 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, you know, they're pretty stable. But you know, periodically they'll revisit and make sure they're still fit for purpose. One of Stripe's 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

• 1:17:08Speaker 00

  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, ah, 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 on how, 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 had started on 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

• 1:17:52Speaker 00

  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 fine, it'll just give you a 404 not find, 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 where something will 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 find, but an object with that ID exists in the other mode. And that's the kind of

• 1:18:34Speaker 00

  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.

• 1:18:52Ryan Peterman?

  I'm curious, depending on the stage of the company, I could see people thinking that, you know, it may 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?

• 1:19:12Speaker 00

  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-founders, 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.

• 1:19:54Speaker 00

  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. Unless 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,

• 1:20:38Speaker 00

  something like that. I think it's true. If you find yourself in an organization that is very intentional about how it works, you just mentioned Stripe, Amazon, they tend to be very effective.

• 1:20:49Speaker 00

  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.

• 1:20:57Ryan Peterman?

  How do you concretely, as an engineering leader, enforce culture?

• 1:21:02Speaker 00

  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 Stripe 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

• 1:21:43Speaker 00

  the culture. And I think if I'd find myself in a, 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, "Oh, 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

• 1:22:24Speaker 00

  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, you know, pleasant and upbeat a way as possible, be a little bit of like, the 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.

• 1:23:08Speaker 00

  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 it up is not okay. And I think that really matters.

• 1:23:28Ryan Peterman?

  With the operating principle, for instance, the 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.

• 1:23:45Speaker 00

  I would definitely try to as much as I possibly could. At Stripe, I personally did this in a couple of different ways. We introduced a mailing list. It got kind of hard to find the right component to file bugs against in 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.

• 1:24:27Speaker 00

  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 it was other people. In, 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, that's a good, good example.

• 1:24:50Ryan Peterman?

  So this walk the store thing, if I understand correctly, you are in an all hands. Dog fooding the product publicly. And if there's a problem, you would.

• 1:24:59Speaker 00

  Exactly.

• 1:25:01Ryan Peterman?

  That could be nerve wracking.

• 1:25:02Speaker 00

  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 like 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.

• 1:25:44Speaker 00

  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.

• 1:26:11Ryan Peterman?

  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 as the CTO of Stripe was, what are the intentional engineering culture changes that kind of enable that type of reliability?

• 1:26:38Speaker 00

  By the way, the team during my tenure, I think we got Stripe to more than five nines of reliability. I hear that last quarter they achieved six nines. That is 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 the 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

• 1:27:23Speaker 00

  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 have 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

• 1:28:08Speaker 00

  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 trade offs between feature work that we do and work they would do for reliability. So we did that by introducing this ops review that I've already mentioned, with 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

• 1:28:49Speaker 00

  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, 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, it was a really special time.

• 1:29:27Ryan Peterman?

  Reliability is, it's not free. It comes with costs in terms of additional machines for redundancy, but also there's a lot of overhead in 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.

• 1:29:46Speaker 00

  Yeah.

• 1:29:47Ryan Peterman?

  Did you ever at Stripe think, is it too reliable? And is it worth that trade off in cost?

• 1:29:53Speaker 00

  Yeah. First of all, I think like on face value, that makes sense. You would think, oh yeah, you need to run way more machines to be reliable. In actual fact, at 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, that's one reason. The other reason is just like, when making changes,

• 1:30:37Speaker 00

  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 over provisioning. 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.

• 1:31:20Speaker 00

  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, 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 trade offs in terms of productivity and certainly not in terms of efficiency.

• 1:32:02Speaker 00

  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 a change to main, 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

• 1:32:46Speaker 00

  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 more fun when you can make a change and the same day you can show it to your friends in the product, like so cool, and your coworkers. And that kind of enabling rapid iteration like that is a lot of how I like to think about the right way to set up engineering systems.

• 1:33:28Ryan Peterman?

  I see. So if I'm understanding, you're, you're saying that with the right investments in shifting left, so catching regressions earlier, you don't even, you don't make that trade off between de-risking. You actually can move fast and be safe.

• 1:33:42Speaker 00

  That's right. There's a good book called Accelerate by Nicole Forstgrun, which touches on a lot of this, not, not quite all of it, but a lot of it. So I recommend that book.

• 1:33:49Ryan Peterman?

  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?

• 1:34:04Speaker 00

  I think the first thing that's important to know about Stripe is we had a lot of amazing engineers.

• 1:34:11Speaker 00

  That actually wanted to work at Stripe and 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 products, 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 work 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 that matters a ton. Of course, we also had to make sure that we were evaluating people in the right way.

• 1:34:54Speaker 00

  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 believe today, that that's actually like not a great way of simulating what it's like to see a real, 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're used to having, and pair a program with an interviewer. And we tried 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 wanted to be meticulous in their craft,

• 1:35:34Speaker 00

  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.

• 1:35:48Ryan Peterman?

  One of the common things I hear about Lee 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 did, how did Stripe do it successfully? Cause Stripe was a, is a very.

• 1:36:08Speaker 00

  I'm not gonna lie, it was hard work. It is the case that interview questions get leaked online. And you know, 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, you know, the people who. Search for 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 like, say thank you to the folks that had 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, that was also really valuable.

• 1:36:52Speaker 00

  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. Like, 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. But they're 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.

• 1:37:17Ryan Peterman?

  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?

• 1:37:33Speaker 00

  It's probably neither necessary nor sufficient. Like, I think you can probably attract great people to work on a thing that's not great if you like 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 the counterfactual. 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 necessary nor sufficient, but it certainly goes a long way.

• 1:38:07Ryan Peterman?

  As the CTO of Stripe, you had proximity to Stripe's leadership team. And I'd love to hear what are the things that you learned from such talented people?

• 1:38:17Speaker 00

  Yeah. So, I mean, I've 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.

• 1:38:59Speaker 00

  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 four 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.

• 1:39:44Speaker 00

  And then reason from first principles will be the right way to move forward.

• 1:39:47Ryan Peterman?

  It sounds like you're saying it is a useful tool, but not in every single place. Cause 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 shortcutting and using the experience.

• 1:40:04Speaker 00

  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.

• 1:40:32Ryan Peterman?

  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.

• 1:40:48Speaker 00

  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.

• 1:41:33Speaker 00

  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 at Android. Nicholas, who's my other co-founder, 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

• 1:42:17Speaker 00

  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?

• 1:42:30Speaker 00

  At Stripe, as really powerful AI models came out like GPT-4, 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 perceive some data, reason, and then take some action. So that was 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,

• 1:43:15Speaker 00

  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.

• 1:43:57Speaker 00

  There is a lot of hard work to do, but I'm excited about what we're doing for for people at scale.

• 1:44:03Ryan Peterman?

  So I'm trying to understand what, you know, 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.

• 1:44:22Speaker 00

  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.

• 1:44:56Ryan Peterman?

  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 OpenAI who probably have interest in this exact thing.

• 1:45:13Speaker 00

  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 like win the market would be the Nokias and the Sony Ericsson'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.

• 1:45:56Speaker 00

  Not, 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 are building agents in this environment?

• 1:46:40Speaker 00

  You know, 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, 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 sdsaa.ai, that stands for slash dev slash agents.ai slash build. That's where you can sign up to be one of our creators in our early access program.

• 1:47:13Ryan Peterman?

  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 a frontline manager?

• 1:47:33Speaker 00

  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 is the short answer. But also, there's so much that is similar.

• 1:48:18Speaker 00

  And, you know, this both feels 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 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.

• 1:48:47Ryan Peterman?

  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.

• 1:49:06Speaker 00

  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, 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

• 1:49:50Speaker 00

  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 it 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, well, we've got this little team on the side building all this mobile stuff, but now I look, 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 gonna be, that's cool. Like I was already working in a bunch of Android apps. I'd

• 1:50:32Speaker 00

  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 org. So 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 advertiser 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.

• 1:51:13Ryan Peterman?

  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?

• 1:51:18Speaker 00

  Yeah, I mean, look, there are a lot of things that with the benefit of hindsight, I would have done differently. Hopefully, I've been fairly transparent in 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 out? 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?

• 1:52:02Speaker 00

  So in many of those meetings where I was sitting there thinking, I don't, I think they're wrong. But I, 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 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 parse 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.

• 1:52:46Speaker 00

  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.

• 1:52:56Ryan Peterman?

  And is one way to know if a company's like that is if the titles are less in your face?

• 1:53:01Speaker 00

  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 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.

• 1:53:45Ryan Peterman?

  Well, I had no idea that early Google also used that title.

• 1:53:47Speaker 00

  Yeah.

• 1:53:48Ryan Peterman?

  I I thought, well, maybe the source was Bell Labs.

• 1:53:51Speaker 00

  I think the source was Bell Labs.

• 1:53:53Ryan Peterman?

  And then.

• 1:53:53Speaker 00

  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 was the progenitor, but it definitely was the way Google worked when I joined Google, which was, you know, two thousand five, two thousand six.

• 1:54:05Ryan Peterman?

  Is there a top recommendation for a book that really impacted your career?

• 1:54:10Speaker 00

  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 like 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 efficient 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.

• 1:54:55Speaker 00

  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.

• 1:55:01Ryan Peterman?

  Habits are very powerful, especially they they compound over time. I'm curious, is there any habit that you took with you throughout your career that really had an impact?

• 1:55:11Speaker 00

  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 a practice that I started many years ago. Certainly during my time at Google was I started writing a essentially a to do list for

• 1:55:55Speaker 00

  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 if I have a great week this week, what did I get done? And I write those things down. And I actually, the doc that I put these in, I call it my rocket doc. Like I gave it the emoji title of a rocket as soon as it Google Docs 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 talk. That has been really great. So being deliberate about what to work on. Later, so you know, I started that when I was, you know, just me

• 1:56:36Speaker 00

  with, you know, folks on my team. Much later, I had the 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 on this stuff this week. So, you know, by middle of the day Tuesday, my EA would ping me on Slack or whatever, depending where I was 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 realized

• 1:57:20Speaker 00

  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.

• 1:57:42Ryan Peterman?

  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?

• 1:57:55Speaker 00

  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 think, where you know a thing and you assume that it's because you're, you know, 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.

• 1:58:22Ryan Peterman?

  Well, thank you so much for your time, David. I really appreciate it. This was a really interesting conversation. Now is your opportunity, if you want to, you know, tell the audience anything and you can go ahead and speak.

• 1:58:33Speaker 00

  We're building a really small, talent-dense team here at Dev Agent, 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 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 Gentik apps and experiences for people, sdsa.ai-build. We'd love to see if we can get you in the Early Access Program.

• 1:59:01Ryan Peterman?

  All right. Thanks so much. Really appreciate your time.

• 1:59:03Speaker 00

  Thanks a lot.

• 1:59:04Ryan Peterman?

  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.