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

15:46David Singleton:And so I think if you derive a lot of energy from something, just go at it.

15:51Peterman: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:07David Singleton: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?

16:40David Singleton: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, 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 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.

17:15David Singleton: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:24Peterman:I mean, eventually, though, you grew to a VP at Google. So I can't imagine you were still taking on feature work when you're, you know, that level of org leader, right? Funny story. Really?

17:36David Singleton: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 engineeringation 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.

18:13David Singleton:And I was running that almost as like a GM, you know, products, engineering, business partnerships, user experience, et cetera, marketing, everything. It was great. I still find it was incredibly valuable to actually experience the tool chain that the engineers in my org were working in. It just made it much easier for me to ask smart questions, to actually see what was necessary to unblock them. So periodically, during that period, it was probably once every two, three months, I would find a way to go and do a little project in the code base. And I think that the context that that gave me back then made me a much more effective VP engineering.

18:54David Singleton:And so I still do that today and did that for my whole career at Stripe.

18:58Peterman: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 when I think about going deep versus scaling yourself, 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:41David Singleton: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, quite appropriate to keep my skills fully sharp. By the time I was in these org leader, managers of multiple managers kind of roles, it certainly would be pretty damaging if I was trying to code the whole time. There's so much work to be done in those jobs to help the team have the right context, to unblock things, to have the right partnerships in place, especially in a large company like Google to work across the company so that folks know what you're up to.

20:20David Singleton:That is the work. That is 95 % of where you need to spend your time. But I do have this deep, not just belief, but experience that carving out a little bit of time and being quite deliberate about it to go and 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.

21:03David Singleton:Maybe I could just skip forward here a little bit and share like, so how did I do this at Stripe? I would take time at least once a quarter, except maybe the final quarter of year, which was always pretty busy, to go and join a team for a few days and complete a small real project. And I called it engineer-ication. 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.

21:39David Singleton: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 and can wait a few days, just don't bother me because I'm doing this thing. Every single time I would make a very detailed friction log. Here are all the things that we ran into that were frustrating. And that served as great input for me as CTO there. I was thinking a lot about how much and where should we invest in developer productivity. So I really kind of this visceral sense of how things were going. And it also served as a great resource for me to ask all of the right questions when it came to operational reviews and so forth.

22:13David Singleton: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:34Peterman:So if I'm understanding correctly, that first case on the iOS team, you were hands on through and through. You were an individual contributor as a manager. But the latter thing that you're recommending as an org leader is more of a educational thing for yourself.

22:52David Singleton:It's important to embrace it as an opportunity to show what you've seen to everyone else. It can give context. I find that the reports that I'd write from my engineerication were useful not only for me conveying 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:22Peterman:Eventually, you mentioned 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:37David Singleton: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.

24:11David Singleton:It's awesome. Get a chance to kind of make sure that I'm keeping some of those skills sharp.

24:16Peterman: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:29David Singleton:The advice that you mentioned, which is, hey, being a manager and being an IC are different jobs. Don't try to conflate them together. That does resonate with me. I've given that advice to many people. I think if you are considering becoming a manager, the best way to do it is not to try to kind of join it on the side of something you're doing. try to find an environment where you can do that like full time really focus on it put your own 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 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 luxury, but there are larger companies that will make that possible.

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

25:59David Singleton:I think luckily a lot of companies, companies like Google and Meta have really cultivated this idea that the IC career ladder can go all the way up. And so you don't just have to have these big teams in order to win. But back then I would see a lot of folks that wanted to switch into management because it just felt like the right thing to do or the way that you kind of like progress your career. And being a good manager and being a manager that actually like feels fulfillment out of the job, it does require you to actually like take a lot of energy and get a lot of energy from getting more out of other people.

26:31David Singleton:And that's not for everybody. So like really reflect on whether that's something that gets you excited. And if it is, give it a try. If you're in an environment where you can try and go back amazing, if you aren't, give it a try. And I'm sure that there are other ways that things can go in future.

26:46Peterman:You mentioned that Google and Meta, there are these parallel tracks and they can go equivalently as deep, but there are differences between the roles and there's probably differences between the progressions. Let's say you're someone in the audience who's hell bent on, I just want to go up. What path would you recommend or do you have any thoughts on that?

27:09David Singleton: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 out what do you want out of it?

27:56David Singleton: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 i feel very confident saying i feel significantly more fulfilled for it

28:36Peterman: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. That's okay, because the carrot for them is the thing that they want to chase.

28:57David Singleton:I think it's just like, make sure you're chasing the right carrot.

29:00Peterman:At Google, I understand that you went from an entry-level IC all the way to VP of Engineering, and you must have a very unique perspective. 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. So 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:34David Singleton: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 was 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.

30:09David Singleton:And I'm grateful to the folks that put that thing together because there's a nice program of investing in those folks. I don't think I deserved it. The reason is that award was voted for by the teams. So whichever team gave the most votes to their manager, that manager got the great manager award. And what I learned later, especially as I started managing managers, was that those teams that are perfectly happy are rarely performing at their very best potential. In order to have the biggest impact, it's really important to 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 wait but as a manager you start to realize oh here's a manager in my orbit you know in my team who has a really good sense of what we're trying to do is really good at like moving all the distractions out of the way and actually 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.

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

32:22David Singleton:As a software geek and a distributed systems geek, I find it quite exciting to think about the organization I was running as if it was a little bit of an operating system. How 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:42Peterman:Am I understanding correctly that if a team is too happy, that's actually a red flag for you?

32:50David Singleton: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 desire to change things and were put into a position where they thought a lot about their impact actually tended to have had the best time in retrospect.

33:35David Singleton:At Stripe, I learned about this thing called type two fun. It's the fun that 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 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 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:01Peterman:That makes sense, yeah. And I think that's a really interesting, I guess, spectrum that you call out in the happiness of teams. It reminds me also of there's a similar concept with teams that are not breaking anything is probably moving too slow. It's a great analogy. There should be some downside. Otherwise, you're too far. That's right. We talked about frontline manager versus manager of managers. Now I'm curious about the step that very few people ever experience, which is you went through senior management all the way to VP. What's the difference between your role as a senior manager versus when you were a VP?

34:42David Singleton: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 of skill sets that have to come together to make this happen? And that does change your perspective. Certainly for me, it changed my perspective quite a lot.

35:18David Singleton:Much earlier in my career, I had tended to think, Google, by the way, was a classically engineering first company in those days. I had tended to think of like, well, all the other functions kind of exist to like feed the engineers to help us all have impact. Not true, by the way. I think if you are working in an environment where you don't have the other functions to help make sure that you're solving the right problem, You're getting the right user input. You've got the right business deals in place to have the potential for a lot of impact. You're going to have much less fun and much less impact in the world.

35:49David Singleton: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 on most of my teams all the way along. But when you're managing a function that you have yourself been part of before, you do have this 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.

36:45David Singleton: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:56Peterman:Did you ever consider that engineercation tool, but for the other roles?

37:02David Singleton: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 sales people 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.

37:43David Singleton:But it's a useful tool.

37:44Peterman: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:57David Singleton:So there's two forms of communication, at least writing and speaking. So let's start with speaking. The number one way to get better at speaking to large audiences is practice. I remember very early in my career being like really quite nervous when I had to present to, I think at that time was like the whole Android org or something like that. And it's pretty hard when you're nervous to kind of very clearly think about what you're saying and communicate it really naturally. I was very fortunate to have a super supportive manager at the time who said, yeah, okay, if you want to get better at this, we'll just give you more at-bats essentially.

38:34David Singleton:It was in London, so they didn't say that. More kind of chances to practice this. And I got sent along to speak to a 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.

39:13David Singleton:Then there's, you know, communicating in writing, this is something I'm definitely still learning to do better. Today, I use Claude a lot to help with that. But I think if you can condense the most important things that you need to convey into a short, clear document, that can be incredibly valuable. Because I can talk to one person, and it takes a certain amount of time. I can talk to a whole audience of people, and maybe you know 30 % are really paying attention you kind of forget over time if you get a really good document out there people will pass it to each other they'll read it once they might come back to it again later it's an incredibly leveraged way to communicate at scale but I also think you have to do both of these things I think people like to listen to folks that they feel like they have some kind of personal relationship with and the personal relationship really only comes from like live conversations.

40:14David Singleton:Once a really strong personal relationship has been established, then it becomes really easy and scalable to read things and kind of take it from there.

40:23Peterman:There are a lot of people that speak a lot, but I don't think they speak like you speak. Like I watched, you gave like a keynote in 2019 for Stripe Sessions and you came onto stage and immediately within a second this guy's confident he knows what he's saying so there's something different about the practice that you did or you know because their managers all speak all the time but i've been to many you know all hands or people are zoning out so

40:54David Singleton: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 in how i speak it really is the case though, that if you had tried to put me on that Stripe Sessions 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.

41:31David Singleton:One thing that happens as a, you know, relatively senior leader is you're essentially always on stage. As you walk around the building, you know, in the office, folks pay a lot of attention to like how you're doing. Like they'll take a lot of their own confidence in the plans of the company from the body language of, you know, the CTO. I find myself kind of keeping that in mind a lot. And 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 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.

42:24David Singleton:But also, if everything's always done in the dumps and never going to work, then you're never going to help people get excited about running over the hill. I find it was valuable to take a moment before I'd open my mouth in any meeting, whether it was one person or 100 people, and think, what am I actually trying to communicate here and make sure that I'm using the dynamic range?

42:42Peterman:A lot of engineers who get into leadership roles, they're tasked with this, giving their top of mind and all hands etc and yeah i think 95 of those if not more everyone's got their laptops out and it's kind of you know most of the message is falling flat do you have any tips on how that manager can do storytelling in a way that the org is actually going to pay attention yeah number one

43:11David Singleton:prepare i have made this mistake many times where i'd be told oh just show up and give us a bit of your top of mind. I'm like, okay, great. I'll show up and I'll give you a top of mind. It's like, oh, what's on top of my mind right now is that I'm kind of hungry. And you know, I'm not going to say that. It's incredibly important to prepare. Think about what is the most useful context for that audience to hear about and put some thought into it. You know, they're all spending 15, 20 minutes of their time listening to you. The least you can do is spend 30 minutes of your time preparing. That's thing one.

43:37David Singleton:I think thing two is there was a leader at Google called Alan Eustace. I think he was VP of all engineering at Google when I was a kind of entry-level engineer, who always did this amazing thing when he would come up to answer questions or explain things, which was he'd be asked a question and rather than just answer the question, he always took the time to take one step back and explain the context behind the question and why it might matter so that folks who weren't already immediately familiar with the problem at hand could actually both understand what was going on and could actually learn something broader from that.

44:14David Singleton: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. 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

44:47Peterman:i just told you that's another trick for writing the thing you called out was condensing the writing and you recently wrote this post about agents crossing a chasm and i scroll to the bottom of it and there's this thing so it says our re grant a bunch of these people had reviewed it yeah how important is the people reviewing your writing in that process of condensing yeah this

45:10David Singleton:is something I learned at Stripe. I used to write blog posts and just throw them out onto the internet. And, you know, I get pretty good feedback about them sometimes. There's one about a neural network controlled car that I wrote, got a lot of coverage. But I would see people at Stripe writing really good documents and crediting the people who'd reviewed them. And I was like, oh, that's interesting. And so I started doing it. I started sending drafts of things that I thought were important to other people. And it improved the quality of my writing immensely. Because, of course, as an author of a piece, you always have a mental model of like, what am I trying to convince someone of or convey?

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

46:16Peterman:Before we leave just general management practices, I think we talked a little bit about scaling yourself. And you said it was especially important as a senior manager and hire. What are those ways that you think are really high leverage ways to scale yourself aside from coaching your direct reports?

46:33David Singleton:Yeah, so I alluded to this. One of the tools in your toolkit as you become quite senior is to start thinking about how the organization works, the rituals, the processes. By the way, when I was an early career engineer, I used to think that the word process was kind of like a dirty word. In fact, 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 maybe it's international quality certification anyway everyone was supposed to do that of course nobody did that because you're just like well i know what i need to get done i'm like under a lot of pressure gotta gotta move right but sometimes afterwards someone will 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 process as this kind of like joke honestly and then i find myself being an organizational leader.

47:30David Singleton:And I was like, someone told me, David, just really think about the processes in your org. And I was like, oh my God, no. And then I realized, hang on a second, like think from first principles here, what are they actually talking about? And they meant like the rituals and how we work and how we get stuff done. And actually like really leaning into getting those set up right is incredibly impactful. For instance, one of the things that I did with the help of some folks who reported to me at Stripe was set up a set of meetings, which we called ops review, which actually kind of nested in the org.

48:01David Singleton: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 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.

48:31Peterman:So that's the main tool. You mentioned hating processes, and I think that's pretty common among engineers. How do you decide when the process is net positive versus net negative?

48:42David Singleton:I think as someone who is in control of a process or is like responsible for running it, Your job is to make sure that it only exists as long as it is clearly a net positive for everyone that's 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.

49:19David Singleton:But because it's their thing, it's kind of their job. It's very hard for them to say, is it actually fit for purpose? But then, you know, running large organizations, our jobs are like, let's make sure that we just don't do that. There's always tons of work for everyone to do. So no one should feel like they're box into continuing a thing for no particular reason.

49:40Peterman:But how do you prevent that if, you know, let's say you're, you know, you're the VP or the manager and you say, okay, we need a sev review process. And you go to some tech lead and you say, hey, this is your thing now. I can tell you worked at Meta because you call them sevs.

49:54David Singleton:Oh, yeah. Yeah. Sevs, incidents, it's all the same thing.

49:57Peterman:Yeah, yeah. 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? I don't know.

50:09David Singleton:I think it's possible to build teams of program managers that are really passionate about the why behind what they're doing. The program management group was something that I helped set up at Stripe. And I feel pretty confident saying that the vast majority of folks there were really just making sure that we were doing the right thing and very focused on impact for Stripe's users. A lot of that, by the way, comes from company culture. Stripe has a set of operating principles and the first one of those is users first. So everyone's always looking through the work they're doing to say, why does this matter?

50:43David Singleton: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:49Peterman: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. Yeah, that's a good observation.

51:03David Singleton: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:19Peterman:One topic that I want to touch on, and this is something that actually Philip mentioned specifically, which is that, you know, Philip, 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. Wow. 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:03David Singleton: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 was like, hey, seems like we should probably talk, which was amazing. And I really respect that. By the way, one thing I love about Silicon Valley, which I think is kind of, yes, it exists right here in literal Silicon Valley, but also it's kind of a state of mind of these ambitious tech companies, is the idea that even some of the fiercest competitors, folks will help each other in the craft.

52:46David Singleton:And that's kind of what Philip and I were doing back then. And I think we actually were genuinely able to help 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.

53:18David Singleton:When I was at Stripe, we had a very vibrant engineering site. So I was based in San Francisco. We had a very vibrant engineering site in Seattle, completely different setup because it's in the same time zone and therefore you can do different things. So I'm going to start with the, you're quite far away. So in that setup, it's important to think about how can we enable the team that are on the ground in London to actually be able to unblock themselves the very most and run as autonomously as possible so that they need to use that little, you know, one 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.

53:58David Singleton:So what I really kind of like pushed very hard on when we were doing that was that every team in London engineering had to have a clear and complete mission, meaning they knew what they were doing at a very high level, like this is the goal. And they were given a lot of autonomy. And then they were given like all of the equipment to go off and execute that pretty autonomously. And that means that, you know, for eight hours of the day, when Mountain View is not around, everyone's just cranking along. And then, you know, a few things come up that you need to reach out to another team for. You can solve them in a little time overlap.

54:29David Singleton:The worst way to set up a team like that would be to have half the team in Mountain View and half the team in London, because then you come up with a hundred things every day where two people need to kind of have a conversation to unblock it. And there's so many of them that you can't make progress in that little time window and progress grinds to a halt. So for those teams, that's the right setup. The other thing that I realized was oftentimes the engineering site lead for Google London, I think two before me, one of the things that I noticed was he didn't spend very long in London. I remember asking him, so I was like a relatively junior engineer.

55:02David Singleton:I was like, hey, Shannon, why are you never here? He's like, hey, you have to understand the best thing I can do for London is be in Mountain View and be kind of like creating like good personal relationships with all the people whose work we are part of, make sure they know what we're all up to, and then bring a lot of context back here to enable us all to operate very autonomously. And he was right. I really appreciated what he did for us all. And then I tried to do the same thing later when I was in the other position, which was I would travel a lot to California so everyone else didn't have to.

55:36David Singleton:They could if they wanted to. I mean, this was a different era where that was always possible at Google. And a big part of that job was just like, make sure the team is visible, make sure the capabilities of the team are very clear so that folks understand if I need to implement some 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 or helped set up or whatever, always had a little bit of its own culture.

56:15David Singleton: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? 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.

56:45David Singleton: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 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:20Peterman:And when you say culture, you don't just mean Google. You mean Google London. Google London. Like your clan. Yeah, we made T-shirts.

57:29David Singleton: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:46Peterman: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. That's right. You know, when COVID happened, I think there was this big move towards remote being more and more acceptable of a collaboration model. But now that you're starting your own company and when you think about teams in this post-COVID environment, which one do you think is optimal? Do you think it's a team purely in person is better? Do you think full remote is best, is hybrid best? What are your thoughts on that?

58:18David Singleton: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 hard to make sure that conversations that would happen between individuals on the same team, if they happen to be on a video call or happen to run into each other in person, got written up for the rest of the team so they weren't left out of the conversation.

59:12David Singleton:They could follow along. and then any critical decisions came with a doc which meant that yes it's slightly slower to make any given decision not always actually because the deliberation you put in writing is often like a big part of what makes more effective decisions in the first place but because every decision was happening in a document everyone had a chance to understand the context contribute their ideas follow along and then kind of more bought into the decisions once they happen so those are the most important things I think to make remote teams work well. And if you do them, remote teams can work very well.

59:46David Singleton: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 on the weekends and so forth, that we come away feeling like significantly more bonded and able to do good work together than if we'd never spoken to each other before. And if you do that on a cadence, it can be every six months, teams can then be incredibly effective even when they're not together.

1:00:18David Singleton:So all of these things are worth doing to make remote teams effective. And for certain companies and certain teams in certain circumstances, I think remote can be almost as effective as if you're all just jamming 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'll talk more about it in a little bit, but we are all here together in San Francisco. And for this stage of the company, I'm excited that that's the right model. As the company grows, I'm sure we will revisit that because there are amazing people that won't be able to come and join us to work together in San Francisco.

1:00:57David Singleton:So I think it's a balance. I think it is very hard to build a huge company today where you just don't decide to lean into how do we make sure that distributed, which is like different offices around the world, and remote, which is folks that are not necessarily able to get in the same room together, work works well. And so it's just like something that in our industry we all have to get used to and kind of lean into.

1:01:22Peterman: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? I don't even know what further it looks like or what was keeping it at that time.

1:01:42David Singleton:Yeah. And honestly, I don't even know what further it would have looked like there. But the short answer is unfinished business. So I think Google made me a VP not long after we'd shipped the first version of Android Wear. And we had a bunch of like really exciting plans and projects that we had already kind of, I had already kind of kicked off with a bunch of handset watch manufacturers. And I was just like really excited to see those over the line. So that'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.

1:02:24David Singleton:And I was still learning a lot. 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. And 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.

1:03:00David Singleton:And I realized I haven't learned very much and I'm here to learn. So what's going on? So that was the thing that was kind of the wake up call. And then also I happened to end up having some conversations with a good friend. It was actually Philip 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:25Peterman: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:33David Singleton:We're definitely in a tussle for the best talent in London.

1:03:36Peterman:It's just so interesting that actually that's the number one person you're thinking about banding together with for, you know, starting a new venture.

1:03:44David Singleton:Well, I guess we, you know, find that we had a lot of mutual respect for each other. And those are kind of some of the best relationships to form in business. I feel very privileged to have been able to bond with someone that I was sometimes on the other side of the table from.

1:03:59Peterman: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. That's right. So I'm curious, what was the company idea? What's the story there?

1:04:17David Singleton: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:30Peterman:Would you fund it if someone is trying to start it? Sure.

1:04:33David Singleton:Send me a note. At the time, we saw kind of the rise of the gig economy, you know, the Ubers and Lyfts of the world. and I actually had like this little side project where I was making these journals and wanted to sell them and I find that in order to do that side project I needed legal help and I needed a graphic designer and it was quite challenging to find those folks. There were some new platforms like Fiverr where you could get some help and I actually 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 in more professional job families could actually take advantage of this trend, but also benefit from some of the stability benefits packages and so forth of actually working for a company.

1:05:20David Singleton:So the idea was essentially like make it possible to have fractional folks in those legal graphic design kind of job families that you could recruit as a company on a platform. They'd be employed by our firm and we would invest in their professional development. So a lot of the stuff that we've talked about before. And then they would be able to benefit from lots of diverse work and also the career development that you would get if you're working for an in-house firm. And we were planning to build that platform. As it happened, we ended up not starting a company at that stage because I ended up, well, complicated personal things.

1:05:56David Singleton:We decided that it wasn't immediately the right moment, but also I ended up as part of that spending time talking to the folks at Stripe. What I realized as soon as I spent time with folks at Stripe was that company at that time had this, still does, has this incredible mission. Their mission is to increase the GDP of the internet. It really is literally 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.

1:06:38David Singleton:I realized that what Stripe does is really important in the world. And then to my surprise, a lot of what they needed back then to scale the company was things that I'd done before. Like, for instance, I'd run the London engineering office at Google, and we were looking to open engineering offices around the world at that time. I had a lot of experience in building new products at Google, and we wanted to do some of that as well. So I really very quickly fell in love with, correctly fell in love with both the mission at Stripe and felt really kind of drawn to something where I thought that I could do something profound for a good number of years.

1:07:16David Singleton:And so I joined and it was awesome.

1:07:18Peterman:In the post, it almost sounds like you went to them for advice on starting the company. That is correct. So when did you realize the conversation was turning towards they're recruiting you?

1:07:30David Singleton:I did first reach out for advice. By the way, someone once told me, anytime you want money, ask for advice. And anytime you want advice, ask for money. And at the time I was like, that's such a cynical view. And then so many times since it's kind of come back to me, I'm like, oh, that was actually pretty good 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 if I reach out to folks at Stripe, I'm going to be able to learn a ton.

1:08:03David Singleton:And they'll give me some tips and maybe they might even invest or something. That's why I reached out. The first conversation was lots of advice and was super valuable, which I appreciated. But Patrick, who's co-founder and CEO there said, hey, and I'm going to be in town soon. So let's get together. And again, I thought we were talking about advice. But from the very beginning of that conversation, I presume he was approaching it as a hiring conversation. I was just learning so much about Stripe and felt really, as I said, drawn to the mission, that it became immediately obvious to me that this was the next place that I wanted to have the next chapter of my career.

1:08:38David Singleton:And look, since then, I have hired a bunch of senior execs. And it really is a very, to be able to find and attract and then make sure that they're a good fit, the very best senior people, it's a very custom process and you know it's important to have a systematic approach but for almost every person that you'll end up hiring that 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.

1:09:25David Singleton: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:34Peterman: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? Yeah.

1:09:49David Singleton: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 make things happen? And so I don't think we were ever particularly formal about what the job really was.

1:10:20David Singleton: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 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 that 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. 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.

1:11:09David Singleton:And that's where these titles kind of actually start to matter. So I really like that kind of a culture where we're not necessarily listened to because we have a title. And that's certainly the culture at Stripe. And it's the culture I seek to build here as well. But it's also the case that when you think about interfacing with the rest of the world, this can matter.

1:11:30Peterman: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 it's helpful when the director is reaching out as opposed to this person in engineering is reaching out that they'll get alignment and stuff like that.

1:11:49David Singleton:It makes sense. I mean, at one point, I'm rewinding back to Google now. At one point when I was made a director at Google, they sent all the new directors off on a training course. And they said, hey, the secret is, I don't know if this was true or not, but the secret is it's really directors that run this company. because it was the spot in the organization where all of the kind of detailed plans were being transferred between each other. And knowing that cohort was incredibly valuable. And I think there's something to that. So you have to think about your org design and like who does what. And having some set of people and different scale of organization, it's going to have different forms.

1:12:26David Singleton:Having some network of people that are making sure there's like really high fidelity of context being transferred is incredibly valuable. And at Google at that time, it was directors.

1:12:36Peterman:You mentioned org design. And as a CTO, I imagine that was something that you thought about a lot. I see all these famous engineering cultures. You know, Facebook has its own thing with, you know, move fast and break things and all of these principles. Similarly, Google has its own principles. Amazon has its own principles. I thought it'd be interesting to hear your take on which big tech company's engineering culture you thought is most well-designed and maybe less well-designed?

1:13:07David Singleton:Yeah, well, I'm at a bit of a disadvantage here because I've only worked at Google among the big engineering companies, and I kind of know some of the others by reputation. The culture of Google, which I joined, was phenomenal. It was a place where everyone was there to do big things. There was the ability and the encouragement to try to have a lot of impact. Everyone was given a lot of agency. The one thing I would say is I don't think it was very deliberately designed. To be clear, it wasn't total chaos. There was an org structure. But I think it grew up mostly organically, or at least in large part organically.

1:13:40David Singleton:By contrast, I think there are companies that have been much more deliberate about the structure they put in place. Amazon comes immediately to mind. As we were designing a lot of the both org structure and ways of working as we scaled Stripe, I tended to look at companies like Amazon who'd been very deliberate in their design for inspiration, very fortunate to have been able to talk to a lot of senior leaders there and get their tips. In fact, the ops review that I mentioned earlier that we ran at Stripe and continues to run at Stripe 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.

1:14:18David Singleton:And we tried to take the good bits of that that were applicable to the size and culture of Stripe and apply them. So Amazon is definitely the company with the very systematic org and operational design that over time I've taken a lot of inspiration from, even though I've never worked there. I actually joked with a friend recently, 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.

1:14:51David Singleton: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 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 smorgasbord. But unfortunately, I've only worked at one big company and I've only really gone deep with leaders at one other.

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

1:15:37David Singleton:I think that's right. 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. Think through, why are we doing what we're doing? What's the ultimate end? And another one of Stripe's operating principles, and by the way, just folks may not be familiar with this, operating principles are a little bit different from values. So this is something I really respect about the early Stripe team. Once they had found product market fit in their core, which is, you know, the payment infrastructure for early stage businesses, they do much more now.

1:16:14David Singleton:But once they find that early stage product market fit, they took a little step aside and thought about what is it about how we're working that makes us most effective? And so Stripes Operating Principles, they're not abstract. They're very concrete, and they are distilled from the behaviors of the most effective Stripes. That means they've also been mutable over time. They revisit them periodically. Not very often because they're pretty stable, but periodically they'll revisit and make sure they're still fit for purpose. One of Stripes Operating Principles that really motivated me and sticks with me and is something that I take forward is being meticulous in your craft.

1:16:48David Singleton:so that means you know taking pride in how well things are done for the sake of how well they're done so you know making sure that engineering systems are designed well making sure that we can offer reliable services to users actually taking the time to polish the edges a little bit taking the time to take a blog post and get some external people to review it before you publish it that's kind of all being meticulous the thing that's interesting about that is a lot of people will you can look at that and say does it make any sense like surely just like focus on the cold hard numbers it's been my experience that there is something that is hard to quantify that actually has a very dramatic impact 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 in stripe when they were much smaller and the person i would be talking to was often the cto and they'd say hey i just got to tell you like i was the one that did the stripe integration back in the day and you know what i was so inspired by the error messages on stripe that i kind of brought some of that energy into our own culture and at stripe if you use the api instead of like you know if you call most apis and the resource you're looking for is not 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 for something to be not found they paid attention to the fact that this went this was a piece of friction for a lot of users and if you request a resource from the other mode instead of just a straight up 404 which is obviously what every engineer would implement as a first cut it actually takes the time to run some extra code and say hey not fine but an object with that id exists in the other mode and that's the kind of thing that's like meticulous in your craft and people remember it.

1:18:38David Singleton: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:52Peterman:I'm curious, depending on the stage of the company, I could see people thinking that, you know, it might be too early to be thinking about those things and maybe go more with that less intentional Google approach that you were talking about. How do you see that? Like with the stage of the company, when do you start thinking about, we need to scale this culture?

1:19:12David Singleton:Yeah, that's a good question. I'm building a very early stage company right now. I think it matters to care about culture from day one. So me and my co-finders, literally the day that we incorporated the company, we went out for a drink and spent some time writing down what we think our values are as we build this company. And that's been useful. We've certainly been paying attention to that as we think about people that we're hiring and the ways that we're running things and so forth. It's also the case that running an early stage company is an exercise in being smacked in the face quite often.

1:19:45David Singleton:The world will surprise you. And so it's important to have values that help you know where you might want to compromise and where not. At the same time, I think it would be way too early for us right now to kind of spin up a, you know, every week we're going to think about what we can do that contributes to the company culture. It needs to be kind of more organic at this stage. But I do think it's something that, obviously I've worked in much later stage companies as well, I think it's something that you do have to be very intentional about all the way through because fundamentally companies are just large groups of people.

1:20:19David Singleton: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 eats execution for breakfast, something like that. I think it's true. If you find yourself in an organization that is very intentional about how it works, you just mentioned Stripe, Amazon, they tend to be very effective. And some of the companies I worked at very early in my career were not intentional about this and have not lasted.

1:20:55David Singleton:So I think it matters.

1:20:57Peterman:How do you concretely as an engineering leader enforce culture?

1:21:02David Singleton: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. It has to be authentic. So it is, first of all, important 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.

1:21:38David Singleton:And all the other operating principles. So it was very hard for me not to just like show up oozing the culture. And I think if I'd find myself 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 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.

1:22:16David Singleton: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 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 and 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.

1:22:59David Singleton:And the culture that we had at that company was that, you know, we really all treated all of our resources like our own and we cared about all the other people. And I saw that person stop, go to the kitchen and clean up the spill. And they clearly had way more important things to do that day. What were they signaling? It is worth my time to do this thing that someone else walked by. So that behavior of like making a mess and not cleaning up is not okay. And I think that really matters.

1:23:28Peterman: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:45David Singleton: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.

1:24:16David Singleton:Sometimes I'd even like, you know, if it was like a copy change, I'd say, here's maybe the change we could make to make it as easy as possible. But that is a good way to kind of be clear about you know what the bar might be much later we set up a system of like actually we called it walk the store we'd actually like use the product in some company-wide meetings sometimes it was me sometimes there's other people 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 so this walk the store

1:24:51Peterman:thing if i understand correctly you are in and all hands dogfooding the product publicly and if there's a problem you would exactly say okay that could be nerve-wracking yeah another practice

1:25:03David Singleton: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 i was using the product a lot of us probably work on products that it's not super easy for us to use every day. Maybe you're working a piece of infrastructure. Your user is another team at the company. But finding some time every week or month or every six weeks to actually put on a different hat, your user's hat, and go through the process of using your product and write a friction log, which is everything that you ran into that was a little bit frustrating or a little bit weird, and then use those to inform your team's priorities.

1:25:42David Singleton:That's a really valuable tool. At this company, Dev Agents, we're building a platform for AI agents for consumers, but there's also a developer and creator experience. And we go through a process every single week of using everything and writing these meticulous friction logs that then informs what are we working on next. Of course, we want to hear from our actual users as well. It's just such an incredible tool. And that's another place where if you write those things and send them around, you can really kind of highlight what is good enough and what the bar is in the product.

1:26:11Peterman:One thing that Stripe is really famous for is there's this 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:38David Singleton: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 an incredible feat. So, you know, kudos to everyone there who's working on reliability. And for a business like Stripe, it really matters. You know, every second of downtime is like huge dollar losses on behalf of businesses. And they've got it like into like very, very minimal amounts of time in the year. It starts with being incredibly intentional, as you kind of correctly called out. At Stripe, we had a really amazing and difficult, but ultimately incredibly fulfilling year in 2020, which is obviously with the pandemic, suddenly there was a huge desire for a lot of offline business to go online.

1:27:24David Singleton: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.

1:28:01David Singleton:But at scale, reliability really mattered. So it actually was mostly a kind of like cultural change that was important to realize in order to pull this off. And as you said, there's a lot written about this. So 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. We 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.

1:28:46David Singleton:So it really is like get a lot of conviction that it matters and then set up a repeatable system that causes everyone to be able to have the right input and then look at it often enough to take the right action. The other thing that is really awesome about that period of time at Stripe is that all of that progress was made against the backdrop also of just massive improvement in other infrastructure traits, because we started measuring everything in a very systematic way and bubbling it up to a lot of people across the org, we were able to start making a lot of progress on not just reliability, but things like efficiency and performance as well.

1:29:24David Singleton:So it was a really special time.

1:29:27Peterman: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 and probably slowing things down. You know, let's do more diff reviews. Let's have incident reviews. Let's really make sure that if it's touching a risky code path, we go a little slower. Yeah. Did you ever, at Stripe, think, is it too reliable and is it worth that trade-off in cost?

1:29:53David Singleton: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.

1:30:33David Singleton:So that's one reason. The other reason is just like when making changes, there are not enough guardrails or systems to prevent things that engineers are trying to do legitimately to improve the product, to have them like break stuff in the system. And if you find yourself here, then you have to think a lot about things like 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.

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

1:31:54David Singleton:And actually, 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. 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, if you merge the change to main, it was going to production pretty much directly the same day through a kind of very deliberate set of gradual release processes, all fully automated.

1:32:31David Singleton: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 merged your change and then like maybe every two weeks, someone would take the time to cut a release branch, test it, sometimes a lot manually, fix up some of the rough edges with some cherry picks and then that would go to production. It would sit there and not change for two weeks. So if you were an engineer writing a change, 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.

1:33:06David Singleton: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:28Peterman:I see. So if I'm understanding, you're saying that with the right investments in shifting left, so catching regressions earlier, you don't even, you don't make that trade-off between de-risking. You actually can move fast and be safe. That's right.

1:33:43David Singleton:There's a good book called Accelerate by Nicole Forsgren, which touches on a lot of this. Not quite all of it, but a lot of it. So I recommend that book.

1:33:49Peterman: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:04David Singleton:I think the first thing that's important to know about Stripe is we had a lot of amazing engineers that actually wanted to work at Stripe 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 product, there are many different ways you can use it, but the core is a developer platform. I think it has a deserved reputation for having some of the best documentation in the industry. By the way, there we considered building the docs part of building the product. So it wasn't something that a separate team worked on.

1:34:35David Singleton: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, ship a great product and then people will want to come work on it. And that matters a ton. Of course, we also had to make sure that we were evaluating people in the right way. At the time that I was joining Stripe, the industry was still doing a lot of whiteboard interviews. You'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 not a great way of simulating what it's like to see an engineer do work.

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

1:35:48Peterman:One of the common things I hear about Leacode and why it's used at the largest companies is that to do what you did at Stripe at scale is challenging, maintaining those. People are going to probably leak those questions and all that. So how did Stripe do it successfully? Because Stripe is a very large one. I'm not going to lie.

1:36:09David Singleton:It was hard work. It is the case that interview questions get leaked online. And as soon as that happens, you need a new interview question because you want to make sure that you're fairly assessing people and getting a real read, not the people who searched for it on Google beforehand. So it's hard work. there were a decent number of engineers at Stripe that were very passionate about this. And they also did a good job of kind of getting other people passionate about it. And so it was a volunteer effort to build those interview questions. It's important, I think, as leaders and managers to make sure that folks that contribute to those kinds of efforts are recognized.

1:36:40David Singleton: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, it was also really valuable. and it really just came from like actually caring about it so if you tell me that meta or google don't have the resources to build good engineering interviews i don't believe you 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 by the both amazing companies i'm not criticizing them but i think if you really care about something like this it's possible to apply the hard work to make

1:37:16Peterman:it work well earlier you mentioned you know what stripe did to draw in the talent even pre-assessment and it sounded like you were saying that if you want to attract excellent people build something

1:37:30David Singleton:that's excellent is that right 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 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:07Peterman:As the CTO of Stripe, you had proximity to Stripe's leadership team. I'd love to hear what are the things that you learned from such talented people?

1:38:17David Singleton:Yeah. So, I mean, I've alluded to many of these along the way in this conversation, but I think the thing that I learned most from my friends and peers on the leadership team was the value of thinking from first principles. So I would also say I was not very good at this when I joined. At Google in particular, you know, that company invented a lot of the ways of working in our industry back then and today, and it was very effective you know what an amazing business great products so when i was at google i would often be like well we got to do this thing how did we do it last time and we'll just use that again when i came to stripe it was a very constant refrain and kind of way of framing things that when we were faced with a problem that we need to solve we wouldn't just say how did we solve it last time we would say from first principles what is actually going on here can we deeply understand the dynamics and how can we figure out what to do?

1:39:12David Singleton: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 and then reason from first principles about the right way to move forward.

1:39:47Peterman:It sounds like you're saying it is a useful tool, but not in every single place. Because also, I mean, at this point in your career, you have seen so many patterns and you have had successes that maybe sometimes were shortcutting and using the experience.

1:40:04David Singleton: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 is 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:32Peterman:Coming away from Stripe, I saw you recently left to start your current company, which is Dev Agents. And I would love to hear more about what the company's building. And maybe we can start with the story behind you leaving Stripe and wanting to build this. Sure.

1:40:49David Singleton: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.

1:41:25David Singleton:So I'll get back to those, but let me tell you kind of how we got started. So I mentioned earlier that I started my career in the early days of mobile. So I was working on smartphones before they were a thing. And at that time, I got this like really deep conviction that this technology mattered. And yet we had to solve, you know, building, by the way, we kind of glossed over this at Google. I ended up working as part of the Android team. And Hugo, my co-founder, was part of the very early product team on Android. Nicholas, who's my other co-founder, also designed a lot of the core mobile interfaces and then worked on Chrome.

1:41:57David Singleton:So 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 we're going to use this technology and invent things like the right permissions model, the right application affordances, like how do you structure a UI? I also worked on wearables. How do you get the right UI onto a watch and so forth? And at Stripe, as really powerful AI models came out like GPT-4, I had the opportunity to apply them to problems inside of the business.

1:42:39David Singleton:We were building some of the world's first AI agents. We didn't know to call them that yet. But 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 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.

1:43:38David Singleton:We need a way for people to have access to all of the experiences that have been crafted for them by developers, builders, creators. So that's what we're doing here. The inspiration really did come directly from seeing that this is a very similar moment to that early stage of mobile. And yeah, it's been a lot of fun. There is a lot of hard work to do, but I'm excited about what we're doing for people at scale.

1:44:02Peterman:So I'm trying to understand what is the product here. So it sounds like it's infrastructure, like a consumer would not know the words dev agent. It's that the consumer would see, this is my airline agent and some developer built that. And behind the scenes, they're using what you're offering.

1:44:22David Singleton:We are actually building the platform that they will use to both find those agents in 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:56Peterman: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, how do you see yourself out competing big names like OpenAI who probably have interest in this exact thing?

1:45:13David Singleton:Yeah, absolutely. One of the things that I think about a lot is in the early days of mobile, we expected that the folks that were going to win the market would be the Nokias and the Sony Ericsons of the world. They had 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:56David Singleton:Now, 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 will see it before too long. And it's pretty different. And that's important because I think we have figured out 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?

1:46:31David Singleton: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? and how can they work together in order to work really well for people. And that's what we're kind of laser focused on. So it's pretty different. Watch the space. And in fact, we're right at the moment now where if that sounds exciting and you're the kind of person that likes to tinker with new technology and build things, we'd love to consider having you as an early adopter of the platform, as a creator and developer of these agents and agentic apps.

1:47:02David Singleton:So if you go to sdsa.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:13Peterman: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? How different is it from that first time you were a frontline manager?

1:47:33David Singleton: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. periodically I put a lot more energy into both preparing myself for every week and 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 and you know this both feels feels a little bit like home and also feels like a wonderful new challenge.

1:48:25David Singleton:And you obviously mentioned how competitive the AI industry is right now. That is true. I wouldn't want to work on anything else. Like I really strongly believe that this is a profound leap forward in technology. And I, as a technologist, I couldn't imagine not working on it. It certainly is hard work, which is very rewarding. But I think we're creating a lot of type two fun right now.

1:48:47Peterman: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:06David Singleton: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.

1:49:44David Singleton:And I have made choices to move teams within companies specifically because I thought that was an opportunity to learn things that would put me outside of my comfort zone I mean an example of that I worked on mobile at Google before Android there was then a weekend where I remember 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 we've got this little team on the side building all this mobile stuff but now like 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.

1:50:18David Singleton:And as someone who's working across a bunch of stuff in mobile, the default path for me would have been to, at that time, go join the Android team. I did later join the Android team. But what I decided to do was I thought, well, that's going to be, that's cool. I was already working on a bunch of Android apps. I'd already had the opportunity to inform some of the kind of core of the operating system. But I thought, hey, the best thing for me to learn at Google right now is if I go and work on ads because I had no idea how Google made money. And so I did that. And it put me way outside of my comfort zone.

1:50:47David Singleton:I was already reasonably senior. Most people who were in that org had kind of grown up in the orgs. They knew everything. I had to learn at a tremendous rate. But man, it was awesome. I mean, I now understand how 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:12Peterman: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:18David Singleton: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 on 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. Why do they want to hear from me?

1:51:48David Singleton:I'm just like this, you know, newbie. But actually what you realize as you go through your career is the people who have the very most context for everything going on are the folks that are actually doing the building at the one foot level, right? So in many of those meetings where I was sitting there thinking, I don't, 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.

1:52:28David Singleton: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. 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:56Peterman:And is one way to know if a company is like that is if the titles are less in your face?

1:53:01David Singleton: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 is member of technical staff. And the whole point there was, we're not going to say what your level is in a publicly kind of discernible way, because we want people to listen to your ideas, not just because of like your title or who you are. And I think that's like a trait that's common to organizations that work that way.

1:53:32David Singleton: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:45Peterman:Well, I had no idea that early Google also used that title. I thought, well, maybe the source was Bell Labs.

1:53:51David Singleton:I think the source was Bell Labs. By the way, it's amazing the kind of like family tree of all the practices in our industry. I'm pretty certain that Bell Labs was the progenitor, but it definitely was the way Google worked when I joined Google, which was 2005, 2006.

1:54:05Peterman:Is there a top recommendation for a book that really impacted your career?

1:54:10David Singleton:I'm sure you've heard this one before. High Output Management by Andy Grove. So Andy Grove was the CEO at Intel. And I just talked about the family tree of all the business practices in our industry. It turns out that 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 yeah, give yourself a few hours. It's like interesting, like it's a bit of a page turner.

1:54:46David Singleton:And so many of the practices I'd seen at large actually come from this book. And, you know, there are certainly some things in there which probably don't make so much sense anymore. But as a moment that made me think differently about how to like run everything I do at work, reading that book was pretty pivotal.

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

1:55:11David Singleton:There definitely is one. So for the longest time, I would just kind of do whatever was coming at me. Like I 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, 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.

1:55:45David Singleton: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 myself for every week. I found that a week is the right level of granularity. And so on Sunday nights, I would just take a moment to think, what, if I have a great week this week, what did I get done? And I write those things down. And I actually, the 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 Google Docs supported emojis. And that's kind of like the energy I want out of that thing. And then during the week, that's the thing I come back to all the time.

1:56:24David Singleton: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 RocketDoc. That has been really great. So being deliberate about what to work on. Later, so I started that when I was just me with folks on my team. Much later, I had the privilege of having a couple of tremendous executive assistants that would help me. And something that was a real kind of cheat code, I guess, was I'd share that doc with them. And then I'd say like, our collective goal is to make sure I actually spend my time 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 it's working and say like, how are we doing against these things and start chasing me to do the stuff that I wanted to do.

1:57:07David Singleton: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 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 in an even keel.

1:57:42Peterman:and the last question that i wanted to ask you is you know if you could go back to yourself when you just graduated from college and you were right about to enter the industry and you could give yourself some advice what would you say it's a really good question i think i'd repeat that

1:57:59David Singleton: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 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:22Peterman:Well, thank you so much for your time, David. I really appreciate it. This was a really interesting conversation. Now's your opportunity if you want to tell the audience anything and you can go ahead and speak.

1:58:33David Singleton:We're building a really small, talent-dense team here at DevAgent, 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. You can put my email address in your show notes. But in particular, if you're someone who'd like to tinker with our platform and build some new and exciting Gentic apps and experiences for people, sdsa.ai slash build. We'd love to see if we can get you in the Early Access program. All right.

1:59:01Peterman:Thanks so much. Really appreciate your time. Thanks a lot.

1:59:30Peterman: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.