Skip to content
ClaudeClaude

DoorDash gave every employee Claude Code

DoorDash runs Claude Code across their entire company and recently gave every one of their 4,000 employees access to Cowork. Boris Cherny, who created Claude Code at Anthropic, sat down with DoorDash co-founder Andy Fang to talk about how he’s delivering customer value faster by raising AI fluency across the company. Claude Code: https://anthropic.com/product/claude-code Claude Cowork: https://anthropic.com/product/claude-cowork Office Hours: https://claude.com/office-hours

Boris ChernyhostAndy Fangguest
Jul 7, 202625mWatch on YouTube ↗

EVERY SPOKEN WORD

  1. 0:00 – 0:10

    Intro

    1. SP

      [on-hold music]

  2. 0:10 – 1:10

    Why DoorDash rolled out Cowork + Claude Code company-wide

    1. BC

      I heard that you had a big milestone with Cowork this week.

    2. AF

      Yes. We wanted to kind of raise the floor in terms of the AI fluency of our company.

    3. BC

      Mm.

    4. AF

      So there's clearly people, even outside of engineering, who've really taken off with Claude Code. They like terminal, they're like coding, they're like shipping a bunch of stuff. And a lot of people, even at the executive level, who understand how important AI is, their setups in terms of how they're using AI is still kind of in the very early stages. A lot of people still view AI as just a chat. I, I see a ton of people's eyes light up with like, "Wait, if I connect this to Gmail, or I connect this to Google Calendar, or I connect this to, to Slack, it just like makes me more efficient as a knowledge worker." And I think even just like raising the floor that much, I think was something that we were trying to do with this Cowork rollout. Now that we have a bunch of Claude adoption across the org at DoorDash, we're seeing, you know, massive increases in throughput.

    5. BC

      I wanna get into it a little bit, but before we do, I wanna like step back a bit.

    6. AF

      Sure. [laughs]

  3. 1:10 – 1:58

    Andy’s coding origin story—and his return to shipping code

    1. BC

      Um, how did you get into coding?

    2. AF

      The first exposure I actually had to coding was, uh, when I was nine years old. My mom was trying to get my brother [laughs] to be, uh, occupied for the summer, and so she like sent him to this random coding camp, and then I had nothing to do, so she just like had me join this camp with him. It was intended for him, but I ended up being the one who picked it up. [laughs] Rewinding back a bit in terms of the journey w- I went on with coding at DoorDash, so back in twenty-- rewind back to twenty thirteen, I was, you know, writing all the code directly myself in our dorm room at Stanford. Um, and then after a while, like as the company was scaling, I kind of stopped coding. It wasn't until I was using Claude Code that I actually like was shipping production code in our code base again. So I like had a major comeback. [laughs]

  4. 1:58 – 2:49

    Hands-on workflow: terminal-first, ‘no manual code,’ and parallel sessions

    1. BC

      And then fast-forward to today, uh, tell me a little bit about your setup. Like, how, how do you use Claude Code? Are, are you like in terminal or desktop or how-- Are you on a laptop or on a screen?

    2. AF

      For, uh, coding, I'll just use the terminal usually.

    3. BC

      Mm.

    4. AF

      Or I'll experiment with using the desktop app. I set a goal for myself to like not write code manually.

    5. BC

      Mm.

    6. AF

      So, um, I try to have the agent, Claude Code, basically write everything.

    7. BC

      Do you have like one session at a time? Do you have like a bunch of sessions?

    8. AF

      Oh, yeah. Um, so I have multiple repositories, um, set up, and then I will basically, if I have a repository that I wanna ha-have multiple sessions on, I'll, I'll use like a work tree-

    9. BC

      Mm.

    10. AF

      -um, to, to basically allow myself to code in the repo without conflicts. And then, um, I try to have a couple sessions going at a time.

  5. 2:49 – 3:41

    Model inflection point: from struggling with setup to shipping in 5 languages

    1. BC

      What was like the first experience using Claude Code in this way? Do you, do you remember?

    2. AF

      I distinctly remember like, okay, I'm gonna try to like code actual features in production.

    3. BC

      Mm.

    4. AF

      And I, I made it a goal for myself to not ask anyone for help and see how far I went.

    5. BC

      Mm.

    6. AF

      Unfortunately, at that point, I did not make it to shipping the code in production without help because I, I wasn't able to get the agent to understand how to configure my local environment correctly. Then fast-forward to like, I think it was probably the beginning of this year, twenty twenty-six.

    7. BC

      Mm.

    8. AF

      I did the same thing, and it just worked. And I think you-- I mean, you've definitely seen this. I've heard you talk about this where like there's really been an inflection point with the latest models of being able to just figure things out. Yeah, and I've gotten to a point where like I was shipping in five different languages to production. Um, and I think it's just super powerful, and I think it's very hard to believe it until you actually force yourself to play with it.

  6. 3:41 – 5:40

    Unlearning attachment: throwing away old approaches as models improve

    1. BC

      It's funny, there's this like thing that happens where you, you try something and you use an old model and the product doesn't really work-

    2. AF

      Yeah, yeah.

    3. BC

      -or the MS doesn't work, and then you just like try it again in a couple months, and it might just work.

    4. AF

      Yes.

    5. BC

      And this used to be like the worst idea-

    6. AF

      Uh-huh.

    7. BC

      -before LOMs-

    8. AF

      Right.

    9. BC

      -'cause it, it's sort of like dysfunctional-

    10. AF

      Mm.

    11. BC

      -to take the same idea and then just like try it over and over again-

    12. AF

      Right.

    13. BC

      -because like you should be learning.

    14. AF

      Mm.

    15. BC

      But actually now trying just that same exact idea with a newer model, sometimes it, it just works.

    16. AF

      Something that we've tried to get the teams to unlearn at DoorDash is like, it's okay to throw away your idea.

    17. BC

      Mm.

    18. AF

      Like, 'cause I think sometimes with engineers, you have a real strong affinity to something you've built that works. But I think as the models change and the capabilities change, like, hey, look, like whether it's your setup or like maybe an agent that you're building, it's like you got to reimagine how you're building this stuff with how the capabilities are changing so fast. And so I think it's, as a leader, if you can really lean in and play with this stuff yourself, like, hey, every engineering manager, you should try to set a goal to ship production code. Not like a prototype because like you can, you can ship a prototype on your local setup pretty easily, but like try to go through all the hoops at DoorDash to get something merged in production.

    19. BC

      Mm.

    20. AF

      And do it yourself. It'll open your eyes, both in terms of the capabilities of the models, but also like, hey, for the engineers on the team, what's blocking them or what's causing them-

    21. BC

      Mm.

    22. AF

      -to not move as fast as they ideally could.

    23. BC

      What have you learned with this? Like, i-is it working well? Is every manager like-

    24. AF

      [laughs]

    25. BC

      -heck yeah, let's go? Like...

    26. AF

      I think what's really landed with people at DoorDash is we are here to invest in you all, to give you all the bud- the token budgets and the tools for you to play around, explore these coding agents, and get them to work well for you. And I think that message has really stuck, and I think for managers in particularly, as they've gone and played around with it, they start to understand it too. And so I think, you know, I, I wouldn't say like we're perfect by any means, but I think we're definitely getting people to, to go along the curve.

  7. 5:40 – 6:51

    New bottlenecks: merge queues, CI/CD, code review, and security

    1. BC

      This is just the most fun I've ever had coding.

    2. AF

      Yeah.

    3. BC

      And just building in general.

    4. AF

      Mm-hmm.

    5. BC

      It's like the, the part that I-- You know, I enjoyed the act of writing code.

    6. AF

      Mm-hmm.

    7. BC

      But also the thing that I always cared about the most was the result.

    8. AF

      Yeah.

    9. BC

      And now I can just like-

    10. AF

      Absolutely.

    11. BC

      -prototype really fast and build really fast and-

    12. AF

      Absolutely.

    13. BC

      -it's so much fun, but then it has this other side of like you just have all these agents running, and you're constantly context switching.

    14. AF

      Absolutely.

    15. BC

      And it, it's hard. It, it's a different way of working.

    16. AF

      Yeah, and I think like it's very mentally taxing at times. And then there's also things that, new problems that come up, which I'm sure you guys are dealing with as well. It's like if there's all this code that's being shipped, now people start complaining about, oh my gosh, how long it takes for the code to get merged.

    17. BC

      Mm.

    18. AF

      And like there's so many processes On CICD that we need to reimagine or overhaul as well.

    19. BC

      Mm.

    20. AF

      And you know, we've invested in, like, AI code review agents to make it easier for people to review the code. For example, with security related issues, a lot more security related issues are cropping up, not just at DoorDash-

    21. BC

      Mm

    22. AF

      ... industry wide. Now we need to figure out how to get AI to also help catch these security issues before we ship it to production as well.

    23. BC

      Yeah.

    24. AF

      So it's like kinda like a cat and mouse game in a little bit. As the capabilities are increasing, as the throughput's increasing, making sure that people are catching up and we're using AI to help streamline the automation.

  8. 6:51 – 8:09

    Adoption timeline and governance: fast access with strong security guardrails

    1. BC

      When did you first introduce Claude Code to DoorDash, and how, how did you think about it?

    2. AF

      So it was like sometime in twenty twenty five we introduced Claude Code, and then people started using it. We worked pretty closely with our IT security teams to make sure that, like, hey, we're gonna have a special, like, procurement and review process for these AI tools because the industry and the landscape's moving so fast, we wanna make sure people get access to this stuff pretty much right away. I would say the, the true inflection point I would say is probably at the beginning of this year or late last year. Since then, our, you know, our coding throughput has-- we've seen a correlation with the adoption of Claude Code and basically, like, throughput from the teams. But I would say it all kind of stemmed back to both executive leadership support, but also, like, partnership with IT, security, and engineering to just make sure that like, hey, f- with the tools that are available, like try to get people access to as quickly as possible, and not be so stringent on budgets to start with.

    3. BC

      Mm.

    4. AF

      And just, like, optimize for letting people explore with the landscape.

    5. BC

      Yeah. So it's like give people, like, the, the ability to explore, but then also, like, set the right guardrails.

    6. AF

      Yes.

    7. BC

      Like, like security is, like, non-not negotiable.

    8. AF

      Exactly. Security was very much in the loop, and I think our security team has done a phenomenal job of kind of letting-- like moving quickly with the industry while, like, partnering closely with us to make sure that they're, they have their eyes on the types of tools that we're getting access to.

  9. 8:09 – 9:31

    Creating psychological safety: champions, shared wins, and sharing failures

    1. BC

      So w- with all these, all these different tools with this totally new way of working, how, how do you, like, make peop- people feel safe experimenting with it?

    2. AF

      Early on, our mindset was like, give it, give the tools to the people and see who the early adopters are.

    3. BC

      Mm.

    4. AF

      And just see what they feel like is working. What we've done since then is try to pluck examples of success cases, whether it's particular projects or people who have done a good job, and get them to be the advocates within their team. And I think one thing we've tried to emphasize is try to, as much as possible, get people to produce written artifacts, 'cause that's stuff I can share with the entire company. And so that's-- we've seen some success there, um, but with a organization of our size, it's kinda hard to, like, uniformly enforce that. But that's generally the mindset I've tried to encourage across the organization is, like, each team needs to have their own channels and forums for people to feel comfortable sharing, uh, both the wins and the, like, the shortcomings, to be honest.

    5. BC

      Mm.

    6. AF

      It's like, it's just as important to showcase, "Hey, here's something I did that was cool," vers-- as also important to show, "Hey, here's this workflow that I tried that didn't work," or, "Here's this MCP integration that I did that, like, wasted a bunch of tokens." You know?

    7. BC

      Mm.

    8. AF

      I think we want people to feel comfortable sharing that type of stuff as well.

  10. 9:31 – 10:58

    How DoorDash uses Claude Code today: org-wide usage and the Flux platform

    1. BC

      So you started, you know, using, using Claude Code, and people started advocating for these tools, and then fast-forward to today. How, how does DoorDash use, use Claude Code?

    2. AF

      It's pretty much widespread across the org, um, in terms of people either using Claude Code or using Claude models within, like, other harnesses. We're investing a lot more in automation and basically able to tap into the increased throughput. How do you make sure that's as frictionless as possible? So investments into CICD, using Claude to build AI code review agents for us. We actually have built an internal, um, platform, uh, that we call Flux. It's an infrastructure investment where we have VMs that are in the DoorDash cloud, uh, where you can, like, spin up Claude sessions that are, um, blessed by security to have access to the right type of tools. And that way you can actually fire off Claude sessions in the cloud, and that's actually how our AI code review agent is powered as well as on top of that platform.

    3. BC

      Super cool.

    4. AF

      Yeah.

    5. BC

      That, that's like Agent SDK?

    6. AF

      Yeah, using Agent SDK and, um, the Claude models.

    7. BC

      Oh, cool.

    8. AF

      And so that's been super helpful for us to, um, use those frameworks to basically build that.

    9. BC

      Hmm. Yeah, like the, the thing that you were saying before about how you kind of-- you, you start with the coding, and then you kind of go, like, a bottleneck at a time, and just-

    10. AF

      Yeah

    11. BC

      ... kinda like break down the next wall, like, over and over and over again.

    12. AF

      Absolutely.

    13. BC

      That's, that's just, like, so similar to what we've been going through too.

  11. 10:58 – 12:37

    Cross-functional acceleration: designers shipping code and the 3–5× challenge

    1. AF

      We set some goals for designers to actually start shipping code to production.

    2. BC

      Hmm.

    3. AF

      Um, it, it didn't go com-- a hundred percent smoothly, but I think directionally it was very good because it really forced designers to think about how to get directly embedded into the software development process.

    4. BC

      Mm-hmm.

    5. AF

      So I think that's been really cool to see, and I think it-- we've gotten to a point now where I would say a lot of our best teams have designers and product managers embedded directly in the software development cycle. Um, and they're all using Claude to basically empower themselves. A challenge I've posed to the entire team is, like, try to get projects done in three to five X less time using AI to do so. And I think when you set those kind of constraints, it, um, it's pretty eye-opening in terms of the types of challenges people run into.

    6. BC

      Hmm.

    7. AF

      Um, and so, uh, a lot of it is around how they use coding agents and how people use, like, standardized skills so that people can all get the learnings of the most prolific people. Like, there's an engineer who did a massive, like, uh, code migration that would've historically taken, like, four engineers over a quarter to do. One person did it in three weeks.

    8. BC

      Hmm.

    9. AF

      And I think, um, there's other products where we shaved the timelines by more than half of these massive products that we're trying to launch, and we pulled the launch timelines in significantly. And so I think it's, like, finding pockets where we're seeing those and figuring out, okay, what did you do that was so successful? Getting them to, uh, publish written artifacts, as I mentioned earlier, so that people can, like, see what's going on. Right now, what we're doing is we're, like, handpicking a couple of teams to really dive deep and s-- and give this kind of charter to, um, and just see what they come up with.

  12. 12:37 – 15:29

    What works vs. what breaks: small teams, agent-friendly repos, and process friction

    1. BC

      What are some of the learnings from that? From, you know, like experimenting and figuring out what are the pockets of adoption, what, what works to accelerate development, what doesn't work.

    2. AF

      Yeah.

    3. BC

      Like, what, what's like one surprising thing that works and one thing that doesn't?

    4. AF

      One thing for sure is smaller teams, uh, is a great accelerant. Each person can kind of own a thing or a couple different domains, and you don't have to, like, coordinate as much with each other. Another good learning was actually, like, it actually pays off to do some upfront investment to setting up your code base to be agent friendly. So in one of our successful examples, the tech lead, he jotted down, I don't know, like a couple dozen, maybe fifty plus, like principles of, like architectural principles that he cared about for a particular code base, and he jotted it down in these markdown files within the GitHub repository so that when the agent was coding, that it could reference these architectural principles, and it actually did-- was super helpful.

    5. BC

      Hmm.

    6. AF

      Another thing that was really helpful was standardizing skills across the team. So for example, for mobile development, uh, the team put together skills around basically making it really easy to spin up the simulator and test particular workflows. Things that would be super manual and annoying for an engineer to instrument themselves is now just, like, a skill that you can call and kind of run in the background. So I would say those are some, like, positive use cases that we saw in terms of AI adoption. Uh, a challenge that we ran into was es- you know, particularly for, like, more user-facing, uh, features where, you know, you're not just, like, coding a platform change or a code migration. It requires cross-functional buy-in. You know? You need, uh, the designs to be aligned. You need to make sure that from a product perspective, you're solving the right problems. And we have a lot of these processes that we've put in place for good reason, like around product review or ship review or design review, things that historically were very important for us to get alignment with each other. Uh, but now it's a huge friction point. And so we've had to really build alignment with cross-functional leaders to make sure that if we want to really take advantage of AI velocity, it's not just an engineering problem, it's a whole company problem. Like you-- cross-functional leaders need to be bought in to change the way they work in order to unlock this type of velocity. Like, we need to be okay with not necessarily having product review work in the same way, or do we even need to have product review? Historically, an engineer would have to spend a lot of time getting, uh, design to be pixel perfect. But if the engineers can get it in a workable state, and then we can pass it off to the designer who can get to pixel perfect self-sufficiently, that's really powerful. I think something that we've generally found to be true is the more self-sufficient a team is or an individual is, the faster they can move. And so that's kind of a philosophy that we're trying to really push when we are encouraging people to be more AI forward.

  13. 15:29 – 16:57

    Rethinking org design: self-sufficiency, fewer gatekeepers, more generalists

    1. BC

      So, like, less process, less design docs, less reviews.

    2. AF

      Yeah, and just, like, working directly in prototypes if you're a designer, working directly in the code. Basically streamlining a lot of the process or reimagining it maybe. 'Cause, like, some of this process is there for important reasons. Maybe there's compliance related things that need to go on. But then it's just asking the team, like, "Hey, if we want to shrink the timeline by three X, like, what's a way we can leverage agents to automate a lot of it or make it, uh, faster?" And I think the mindset in terms of, like, how teams should change is like, hey, you don't necessarily need everybody to be a domain expert. In, in fact, you should encourage people to be as fluid across the code base as possible. Like, you know, a lot of our mobile engineers, we actually encourage them now to try to be more full stack, which is a lot more accessible now than it was even a year ago. We still need domain experts in like, for example, iOS, to make sure that, you know, there's particular parts of the architecture or kind of how we manage-- managing memory or latency and performance. But you don't need your whole team to be iOS experts. You can have much fewer of them be gatekeepers and figure out how to build agents to basically check for the things or write in MD files their architectural principles or things they care about. Um, and you have a lot more people who can be generalists and moving across, uh, fluid, fluidly across the code base. And I think that's like a mindset change also that we need to get people more comfortable with as well.

  14. 16:57 – 19:06

    Staffing and sponsorship: giving teams permission to break constraints

    1. BC

      Yeah. How-- So okay, so wh- when, when you have one of these small teams working on something, but you want to give them the space to experiment-

    2. AF

      Right

    3. BC

      ... and to kind of figure out the process.

    4. AF

      Mm-hmm.

    5. BC

      So h- how, how do you think about staffing this team? Like, what, what's like the ideal kind of profile for it?

    6. AF

      We try to make sure that for these teams that we're giving these remits to, we want to make sure that they feel safe in experimenting and pushing here. So I will actually directly lean in, or I'll ask our, like, executives from, like, the engineering or, uh, various adjacent functions to actually lean in with these teams and basically have, like, executive VP level sponsorship on that particular work stream to figure out, hey, what do you-- whatever you need to do to get unblocked, like you have the sponsorship from high up leadership to do so. Because one thing that I've seen not necessarily work as well in the beginning is if you ask people to do this, but they're working within the same confines of, uh, kind of their normal job, then they're gonna give up pretty quickly. Um, unless you've, you empower them to be like, "Hey, you actually, not only are you gonna get token budget to kind of reimagine things with AI, but I want you to raise to us, your cross-functional leadership team, what is hindering you outside of just generating code."

    7. BC

      Hmm.

    8. AF

      And so I think that's worked really well to make people feel safer. Um, we're still trying to figure out how to scale that, but ideally what would happen is as we see these success examples crop up, we share those written artifacts with various leaders so that people can kind of organically try to, um, adopt these practices.

    9. BC

      It's like the limiting factor used to be the speed of coding, and that limited kind of the speed of delivery.

    10. AF

      Mm-hmm.

    11. BC

      That dictated the team setup.

    12. AF

      Absolutely.

    13. BC

      That dictated having to have process and these org reviews-

    14. AF

      Yeah

    15. BC

      ... and kind of like the cadence of exec check-ins and all this stuff.

    16. AF

      Absolutely.

    17. BC

      And now because engineering is so fast-

    18. AF

      Yes

    19. BC

      ... it kind of forces you to rethink all this stuff.

    20. AF

      And there's actually so much more that, like, a team of three to five can do. It's like almost like you kinda wanna like invest in making that unit Move as fast as possible.

    21. BC

      Mm.

    22. AF

      Um, because, like, if you can get that unit to work three to five times faster, then, like, that's totally game-changing for the org.

  15. 19:06 – 22:39

    Measuring ROI: throughput vs. customer value, and the frontier of knowledge work

    1. BC

      Um, okay, I wanted to touch on maybe a few, a few final things. So, um, how are you thinking about ROI?

    2. AF

      Sure.

    3. BC

      So you, you talked a little bit before about first when you're kind of early in the journey, you just want to give people as many tokens as possible-

    4. AF

      Yeah

    5. BC

      ... let them experiment. Now you're thinking a little bit more about ROI. How, how do you think about it?

    6. AF

      I think for engineering, it's a little bit more straightforward because you can actually... I know, like, code throughput's not a perfect metric, and it's a GainMobile metric, but it's directionally kind of correct in a lot of ways. Um, and also the fact that, like, you can get more... You can get the same project done faster with fewer people means that the people you have today, you want them using it as much as possible. I think in knowledge work, I think we're so early, and I think to a point you made, I think there's a lot of things outside of just, like, the triage my email type use cases that I think are really powerful with Cowork that we're just scratching the surface on.

    7. BC

      Okay.

    8. AF

      Like, I think for sales teams, having to do QBRs with, like, tens of thousands of merchants, right? Like, that's a lot of manual work, and if we can really streamline that and make it more accurate and vetted, like, with consistency via AI, that's super powerful. There's two ways that we are thinking about it right now. One is just in terms of, like, raising the baseline, like, how much time are we saving the average person in terms of tasks that everybody needs to do? And then there's what I think actually might actually end up being more impactful is on a per department or domain basis, can we identify particular workflows to automate-

    9. BC

      Mm

    10. AF

      ... that would make it significantly more efficient to, to run that department? So that's kinda how we're thinking about it right now, but in the knowledge work space, to be honest, we're so early that I think, um, we're kind of in an exploration phase there right now.

    11. BC

      Yeah. Okay. So, so for coding, it's about, like, the volume of code increases. So, like, the code throughput you can measure.

    12. AF

      Mm-hmm.

    13. BC

      And then the speed of delivery you, you can measure-

    14. AF

      Yes

    15. BC

      ... pretty easily and just, like, freed up people to do stuff.

    16. AF

      Yeah, and I think ultimately for engineering, well, it's not just engineering because it involves, like, design. It involves cross-functional support. At the end of the day, like, we want customer value to be delivered faster.

    17. BC

      Mm.

    18. AF

      So if we can actually prove that out, not just in terms of code getting merged, but also, like, customers seeing the product live faster, I think for us that's, like, the ultimate success metric.

    19. BC

      Yeah. Yeah. Um, and then, yeah, and, like, for knowledge work, we're still figuring it out. It's still, it's still domain dependent.

    20. AF

      I think there is a lot of value to be had if we can get everybody to be, like, even 10% more productive with-

    21. BC

      Mm

    22. AF

      ... this stuff. That's huge, like, at a company of our scale.

    23. BC

      Mm.

    24. AF

      Like, and so I do think there is value in terms of raising the floor. Um, but I do think with knowledge work, there's still a lot of explorations to be had around domain-specific, uh, workflows.

    25. BC

      And, and I guess it's like it's just back to the way that innovation actually happens.

    26. AF

      Yes.

    27. BC

      Like, if, if you're-

    28. AF

      Yeah

    29. BC

      ... like top-down, like, "Hey, go automate this workflow," you might actually just pick the wrong workflow or the wrong person to automate it.

    30. AF

      Totally.

  16. 22:39 – 25:10

    Finding ‘AI champions’ and closing advice for leaders and new grads

    1. BC

      So, like, famously, you started using AI in coding interviews pretty early.

    2. AF

      Mm.

    3. BC

      I think be- before even we did.

    4. AF

      [laughs]

    5. BC

      Um, and you know, I, I, I think we still don't. [laughs]

    6. AF

      [laughs]

    7. BC

      How, how do you think about it? Like, how do you find these people that succeed in this kind of environment, that are happy, you know, experimenting and that, that enjoy this kind of work?

    8. AF

      I think our mindset is give people the tools and just see who ends up naturally picking it up. You will naturally find out about those people, whether it's through Slack channels or, um-

    9. BC

      They're gonna tell you.

    10. AF

      They're gonna tell you. Yeah, 'cause they, they can... They, they are having so much fun and enthusiasm around it that they can't help but share-

    11. BC

      Mm

    12. AF

      ... the enthusiasm with, um, their peers. So I think it hasn't been that hard for us to find a champion, especially on the non-technical side. And then on the technical side, I think we've, we've just found people who've naturally become power users and taking off with it.

    13. BC

      Um, okay. I wanna, I wanna close with one last question.

    14. AF

      Sure.

    15. BC

      What is your advice for engineering leaders?

    16. AF

      Mm-hmm.

    17. BC

      So, like, other CTO, CTOs and leaders at other companies. And then on the flip side, what's your advice for new grads?

    18. AF

      Sure. [laughs]

    19. BC

      Like, you're in college right now, you're graduating. What would you tell each?

    20. AF

      Man, so I would say for the engineering leaders, make sure you use the AI so that, like, you can encourage your teams to use AI. But also I think it also gives you a sense of empathy in terms of the types of anxiety or stress that engineers might go through to, like, change how they work, and it's like kind of a identity crisis in some ways for engineers. A lot of people are tied to, like, the craft of, like, the code that they're writing, but you kinda gotta let go of that a little bit. And I think as a leader, I think you need, really need to understand that, and the best way to understand that is to play around with it yourself and understand how powerful these tools are, but also how drastically your workflow needs to change. And then also encouraging people to share written artifacts. I'll say that again. It's like that's, in my opinion, the most scalable way to distribute learnings at scale. It's also a, a byproduct of it is you actually end up having artifacts that agents can read.

    21. BC

      Mm.

    22. AF

      Um, so that's, that's what I would say to engineering leaders.

    23. BC

      Mm.

    24. AF

      New grads are picking this up so quickly in a lot of ways. My encouragement is, like, play, like, stay curious, play around with the tools. I think a lot of companies like DoorDash, what we are really excited about with the new grad talent is people who've grown up with this paradigm of working who can surprise us in terms of ways that we can leverage this technology that we didn't think was previously possible.

    25. BC

      Mm. Andy, thank you so much.

    26. AF

      Yeah, Boris, it's a pleasure to be on here. Thanks for having me. [outro music]

Episode duration: 25:11

Install uListen for AI-powered chat & search across the full episode — Get Full Transcript

Transcript of episode hyqLNX3VExQ

Get more out of YouTube videos.

High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.

iOSAndroidClaudeChrome