Pod Insights Software Engineering Daily Developer Experience at Capital One with Catherine McGarvey About this episode Modern software development is evolving rapidly. New tools, processes, and AI-powered systems are reshaping how teams collaborate and how engineers find satisfaction in their craft. At the same time, developer experience has become a critical function for helping organizations balance agility, security, and scale while maintaining the creativity and flow that make top tier engineering possible.
Capital One https://www.capitalone.com/ is continuously transforming its developer culture, with a focus on faster development cycles, reducing operational overhead, and boosting productivity across the organization.
Catherine McGarvey https://www.linkedin.com/in/catherine-mcgarvey-8ab3247 is the SVP of Developer Experience at Capital One. She joins the podcast with Sean Falconer to talk about what developer enablement means at enterprise scale, measuring developer productivity, being agile in a regulated environment, AI in enterprise development, the future for developers, and much more.
Full Disclosure: This episode is sponsored by Capital One.
https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/10/Rectangle-3-2.pngSean’s been an academic, startup founder, and Googler. He has published works covering a wide range of topics from AI to quantum computing. Currently, Sean is an AI Entrepreneur in Residence at Confluent where he works on AI strategy and thought leadership. You can connect with Sean on LinkedIn.
Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/01/SED1893-Capital-One-Catherine-McGarvey.txt
Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected]
The post Developer Experience at Capital One with Catherine McGarvey https://softwareengineeringdaily.com/podcasts/developer-experience-at-capital-one-with-catherine-mcgarvey/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.
Transcript 0:00 Speaker 00 Modern software development is evolving rapidly. New tools, processes, and AI-powered systems are reshaping how teams collaborate and how engineers find satisfaction in their craft. At the same time, developer experience has become a critical function for helping organizations balance agility, security, and scale while maintaining the creativity and flow that make top-tier engineering possible. Capital One is continuously transforming its developer culture with a focus on faster development cycles, reducing operational overhead, and boosting productivity across the organization. Catherine McGarvey is the SVP of Developer Experience at Capital One. She joins the podcast with Sean Falconer
0:44 Speaker 00 to talk about what developer enablement means at enterprise scale, measuring developer productivity, being agile in a regulated environment, AI in enterprise development, the future for developers, and much more. This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.
1:17 Speaker 01 Catherine, welcome to the show.
1:19 Speaker 02 Thanks, Sean. Great to be here.
1:20 Speaker 01 Yeah, absolutely. It's good to have you on the show. So, you know, I was looking into your background. You have a pretty fascinating background where you've spent some time in startups, you've done some defense consulting, now you're leading a developer experience for like 14,000 technologists at Capital One. Like, how does that diverse experience across this wide spectrum from fast-moving startup world to a large financial institution shape the way that you think about tackling things like developer enablement at such a massive scale?
1:49 Speaker 02 Yeah, I've been super, super fortunate in my career to have these kind of pivots or these opportunities to approach different domains and different sizes. And I think what's really nice about that is you learn a couple of things that often there's not one way to do something and that you've really got to think about what matters in how you're doing software development to the Consumer into the business to really spark down the path of well, what do you have to standardize on? And what can you leave flexibility around? And that's been really great, you know, with the consulting side of startups, I got to be involved in the early days from zero to one and one to a hundred users. And it was amazing to think through long-term architectural design matters a lot less when you're just trying to confirm that you can survive.
2:34 Speaker 02 And you can get those first couple of customers and how much that pivots when you're talking about B to B selling or B to C. Where I am sort of now really thinking through, how do we make sure what we deliver is resilient to customers and is set up? But at the same point, how do you keep it agile so that you're adapting to their feedback back and able to make changes? So it's been nice to draw on different parts of my career to date to really look to how do you bring the mindset of where we're focused now? With this idea of how do you bring that agility and that adaptability to new information? While ensuring you're keeping sort of risk and security and all of those quality concepts really top of mind as well.
3:16 Speaker 01 Um hum. How do you think about developer enablement? What in practice does that actually mean? I think it can mean different things within different organizations, like some people might be focusing purely on how do we increase our velocity or become more efficient? Like, what does this mean in terms of your ownership within Capital One? And how do you think about it?
3:34 Speaker 02 Yeah, so developer enablement, a colleague of mine actually mentioned this term for me and I just loved it. So I've latched on to it. In the past, I've really thought about developer productivity, which comes down to a lot of throughput, speed and quality. Is the team churning out code at a certain rate? Is it at a high enough quality? And is it getting into the hands of users fast enough? And fifteen, twenty years ago, as product managers really stood up as like this role that was critical in the software development process. There was a real shift to be, are we building the right thing? Because it's fantastic if your engineering team can move really quickly. But if it's not connected to something of value, who cares? Productivity without connection to value is like a dying product.
4:16 Speaker 02 So the product management side of this really sparked this idea of let's ensure we're building the right thing. We understand our users as well. And so when I think about developer enablement, it's combining speed and throughput. And how do we give the tools to accelerate that development? But it has to be balanced by, are we listening to users? Do we understand what they need well enough that we're solving the right thing? Those two things in balance, I think, is where enablement's really about. Give them the tools, but the information as well to be able to do their job well.
4:48 Speaker 01 Um hum. And does that need to be something that you're doing? Like, is that one person or one small team owning horizontally across all the engineering teams? Or do you see this as something more like a product manager? That's going to work directly with one sort of cohort of engineers and kind of be trying to answer that question of like, are we building the right thing?
5:08 Speaker 02 I think for every team, the team size is really interesting. You need a sense of the direction that's connected to the customer and someone being that voice. And sometimes that's design, sometimes that's product, sometimes it's both. And sometimes there's multiple people depending on the complexity of what you're delivering needed there. But you need that connection to the team. And you need the swim lane small enough that that team can be effective in solving that outcome or delivering that product. And so that that combination of, again, keeping that team nimble enough and then giving them the information they need to do the job well and having someone to talk to about it empowers them because they're not just picking up a product definition and executing on it.
5:49 Speaker 02 They're understanding it and discussing it and seeing how they can improve upon that experience overall, not just delivering a feature.
5:57 Speaker 01 Um hum, okay. With such a large organization, I mean, we're talking about fourteen thousand people. Like, how do you even measure the success of developer enablement at a scale?
6:07 Speaker 02 I love this question because there's so much going on around developer experience. What do you measure? You know, years gone by, there was a really big, great push around DORA metrics and thinking about, that's really like your throughput, sort of style of, and your recovery style of things. And then there's been the workaround space and really trying to get to the qualitative side of that as well. And I don't think there's one great answer, but there's lots of good things you can measure. I do think measuring the important things matters, but it's, in some cases, it's not the only thing that you, you need to measure. So a couple of things we do look at is we are on this journey of continuous deployments. What is your time between deployments? It's a really interesting one to see. Are you getting
6:48 Speaker 02 your code out there fast enough, quick enough, and adaptable to change on that one? And to be able to do that well, you have to have great testing, you have to have great quality measures. So that's kind of part and parcel of that continuous deployment piece. The next one is, is it actually addressing the need of the customer that you're delivering to? So in my space, I spend a lot of time thinking through, am I solving the outcome for the developer? If my job is to make coding reviews great, and I'm providing tools in that space, is it actually making it great? What's the output of those coding reviews? What's the impact of delivering this tool? Am I getting this NPS satisfaction, other things we can measure? So that's very much tied to what are you delivering? What's the
7:31 Speaker 02 outcome you're expecting to change? And so measuring it from the, are you making the change you're expected there, makes a big impact?
7:37 Speaker 01 Hmm.
7:38 Speaker 02 And so continuous deployment and the tools to enable that. And then is the tool I'm providing, or the service, or the output I'm providing, is it having the outcome that I'm hoping for it to have?
7:49 Speaker 01 Yeah. And is some of this always going to be a little bit dependent on the organization too? You're going to have, but there's probably going to be some overlap, but you might have sort of custom things that you're measuring for success based on maybe where you feel like you have like a pain point today?
8:04 Speaker 02 Yeah, absolutely. And like, I like using specific examples. So we've had teams focused on different parts of the software development lifecycle. And so one of them has been on onboarding. And onboarding is a really interesting thing as you hire or you have people switch teams. Part of it is, am I giving them the right information? And then am I pointing them to where to go to discover things? And then am I giving them the right training and starting positions so that they can commit code fairly quickly in their journey? And so some interesting metrics to measure there is time to first commit. And time to tenth commit are really, really great. And they're kind of standards across the industry for measuring that well. But then there's also like expectations. Does the person joining know there's an expectation on measuring these things?
8:48 Speaker 02 Because if you know you're being measured, that'll change your behavior as well.
8:52 Speaker 01 Yeah, you tend to optimize the things that you measure. So that's why you gotta be careful about what you what you measure.
8:57 Speaker 02 So and you know, developers, I think of all the customers in this space are fantastic at gaming metrics.
9:03 Speaker 01 Yeah, absolutely.
9:03 Speaker 02 That's that's definitely one of the factors you consider as you look at this.
9:07 Speaker 01 And then the onboarding thing's interesting. I would think also that potentially impacts retention or job satisfaction as well. Because presumably, most people starting at a new job wanna feel like they can contribute. They're making a difference. If it takes you six months to get to a point where you've done anything, you've submitted your first P R or something like that. This probably gonna lead to a certain amount of satisfaction for a number of people.
9:31 Speaker 02 Yeah, absolutely. If you know you've been hired to commit code at some level, your job family that you're in. Ideally, you wanna start to show that you can do that because that gives you confidence that you're understanding the space as well. So there's that internal anxiousness about, I wanna demonstrate value as well as that satisfaction of the job is giving me what I expected to.
9:50 Speaker 01 Mm hmm. Yeah. Given that capital ones and a very highly regulated industry. You're gonna have certain compliance and security considerations that probably a regular or software company might not have. How do you end up balancing with the necessary structure? And probably having to slow down and do the right thing while still giving people the freedom to feel like they can work autonomously. They're moving quickly and all these types of things.
10:17 Speaker 02 Yeah, and this is one of the areas that really prompted me to join Capital One in the first place because I was like, how are they doing this so well? And I wanted to kind of come in and learn. And there's some really great strategies Capital One employs to really help enable agility while still maintaining that strong security posture, that strong compliance. And so the strategy that is employed here, which I really love, is this idea of let's make it easy to do the right thing. So all of the practices, the platforms, the services and the model that we operate is, let's give you the best practice and make that your default behavior. And so instead of having to pick through what database to use, this is the one we recommend. And if that one doesn't meet your need, okay, there's things that you can do to go beyond that.
11:01 Speaker 02 And we can get approvals and go through sort of exception processes where needed. But by making it easy to just pick the thing, it doesn't become a question. And that sort of helps with the pattern. So there's lots of best practices built in and then there's standardization. When it is something that should be standardized across the company, we just, the company standardizes and then requires every team to comply to that standard.
11:24 Speaker 01 Hmm.
11:24 Speaker 02 That creates migration and other work from time to time. But you get great lift because you can put controls, you can put best practices into that standard.
11:32 Speaker 01 Hmm.
11:33 Speaker 02 Require less work on the development teams.
11:35 Speaker 01 Yeah, and I guess it gives you some efficiency too when people kind of move around in the organization because
11:40 Speaker 02 Yes.
11:40 Speaker 01 there's kind of one way of doing certain things. So it's going to be familiar each time, even if you're solving net new problems.
11:46 Speaker 02 Yeah, absolutely. And what does happen, and just like at any company, is when there hasn't been a standard, a few different tools start to exist. And then we sort of bring about our standard or approach. And that's working fairly well because it doesn't stop teams from starting that innovation or picking something in an absence of a standard. But it does prompt us fairly quickly to establish, well, what should be the standard here?
12:07 Speaker 01 How do you make that decision about sort of what to standardize or centralize versus what? Giving a team essentially their individual discretion? And then even if there isn't some standard today and an individual team has to make a choice, how do you become aware that that the choice has been made and that there might be a time where you have to decide? For example, I'm sure we're going to touch on this a lot with the world of AI. Like if two years ago, someone started experimenting with an early L O M, then at some point, obviously you want to standardize, but maybe they were solving some very specific problem. Like, how do you even know, become aware as an organization that that's going on?
12:43 Speaker 02 Yeah, you start to see a proliferation of tools or services that are similar. And that's when you start to realize there is overlap in capability. And then we typically will task a team for what's the right answer to the case for this. And you typically pick this up when we see this high leverage. Lots of tools are coming in, which potentially prompts more work on security reviews and other things, just because that just increases the level of awareness we have to do on approvals. But then also we look at things like, is there an open standard? You know, as we look at telemetry, there's a lot that's standardized in the telemetry space. And so picking a standard there simplifies the world for us and it can simplify what tooling.
13:25 Speaker 02 On the L L M and other front, when you're in an industry like we're in where things are rapidly changing, like the change this year has just been so exciting and incredible. The more you tie yourself to one model or one approach, the more you're going to get boxed in.
13:39 Speaker 01 Yeah.
13:40 Speaker 02 Get go, we've been standardizing on what is our success criteria and improving upon it each time for a pilot that we do. And we've been using sort of abstractions to think through, well, if this needs to be a coding assistant, for example, perhaps it uses this API or interface and we're going to go through this review. And then we're going to use that same sort of template if we, when we introduce another or another. So we're getting some lift there, but that's an area in particular where I don't think anyone's declaring one standard right now. I think we're still going, what's the right tool for the right job? And should we revise that with new information coming in?
14:15 Speaker 01 Yeah, I think it's tough when you're in these like in early innovation cycles. Cause it's hard to, it was, you know, it's hard to know what would be the right choice. And the right choice today could change drastically in like a week with the way things are moving so quickly. So you really need to be sort of investing in technology. And if you're building whatever your solution is in a way, that's sort of adaptable to this type of change. Or you're going to hurt your, you know, velocity down the road because you become locked in and tightly coupled to one way of doing things.
14:44 Speaker 02 Absolutely. I think one super exciting thing, though, with these agentic workflows and other tools that is happening in the industry, this idea of lock-in is really interesting because like, how locked in will you be if it's easy to migrate now? Because you have tools that enable that migration.
14:58 Speaker 01 Yeah.
14:59 Speaker 02 I'm excited about just how it opens up doors for us and we're doing a lot of that abstracting and keeping an open mind on areas where there is great innovation happening. And we want to be getting the benefit of it rather than just picking one and waiting.
15:13 Speaker 01 Um hum. Yeah, makes sense. So I know you have rolled out L M powered coding assistant. Could you talk a little bit about what went into that decision-making process? And then what were some of the good things that you saw from this and what were some of the challenges?
15:28 Speaker 02 Yeah, maybe I'll speak about a challenge first, but I think if you go back a year or so ago, where we were with an industry in the messaging around coding assistants and A I tools is there was a lot of fear, a lot of concern that this will replace my job.
15:42 Speaker 01 Yeah.
15:43 Speaker 02 And so there was a fair bit of messaging we had to do and Capital One does this really well. We do this at multiple layers of leaders, including our C E O, speaking about, hey, we want to get lift in this space. And we want to automate anything that isn't part of the creative problem solving of software development. Let's all adopt the tools that create that lift and let's try it and see what works. So our approach was to really roll this out and encourage everyone to use it and see if it works for them and what it works for them. And so we went through a full risk review and compliance review and all the reviews that we do to sort of did a P O C and a pilot and scaled it out and really started to track, well, who was getting benefit from it?
16:26 Speaker 02 And then as part of that, we created some Slack channels and other things where we could surface who's using it the most, what are the things they're discovering? And it's really fun to watch people share their examples of what worked for them or how they used it. And as we've been rolling out other tools sort of since then, continue to use that same approach of letting peers share what's working well and what isn't, so that we can learn from each other. Because it is such an area where there is so much change happening at the moment.
16:52 Speaker 01 Yeah, and I think, you know, in my experience, I've seen a couple of things that can sort of hinder a company's use of these tools. One is that they kind of underestimate the actual learning cycle of how to use these tools properly. So especially with some of the agentic ones where you're doing sort of more of like a perhaps spec-based development. And it is kind of a new way of thinking about doing your development. I think sometimes people can put in a prompt, they don't get what they want, and then they kind of write off the tool that this doesn't work for me. So I think companies sometimes miss thinking through, like, how do we actually make sure that people know how to use these tools properly and get the value out of them? So I'm curious to hear your thoughts on that.
17:34 Speaker 01 And then the other thing is that when it comes to developer sort of efficiency, even if the tools for the coding assistants are working 100% as you would want them to work, the time that developers actually spend coding is maybe 20% of their job. There's all this other time that they're doing other things, you know, whether it's like design reviews or thinking about architecture or stuff like that. So I think sometimes companies are surprised by maybe the ROI ends up being different than what their expectation is because they're thinking about 100% time, but it's actually you're kind of optimizing 20%. So I'm curious to think, see how Capital One is thinking about like that other 80% as well.
18:12 Speaker 02 Yeah, that's great. And I think really great framing about, you know, the day in and day out job is not just sitting there coding and how everyone works. So I think there's a bit to unpack there. The training and the best practices with some of these tools, we've found the more you can make it use case centric, the easier it is for people to understand the value. You know, I feel like a year ago, there was a lot of focus on how do you prompt well? And there's a lot more focus now on how do you tweak your plan to then get the behavior you want to see happening? Even the training a year ago is probably not as relevant as some of the training we'd roll out now on that front because it's just changing so much. But the use case-based training is really great.
18:55 Speaker 02 And we're really thinking about for this type of task, this is the best tool from it and becoming a bit more opinionated. The more we use different approaches, the more we identify this tool's great for this right now. Maybe that'll change, but for right now, this is what we recommend. You know, a spring boot migration or upgrade might use this tool versus a test case generation might be great with this tool. That's an area we're focused on. And then measuring the impact, there's been some interesting thoughts around, to your point, how much time is each developer spending? Programming versus other tasks they might do. And so there was some really interesting stuff in the industry around what do you measure? And I'm very much anti, we don't measure lines of code produced.
19:40 Speaker 01 Hmm.
19:41 Speaker 02 Is that perhaps the worst a coding assistants or agents might produce the largest amount of code? And that's actually not a measure of value in any way. So we were looking at things like, how many suggestions do you accept? As being an interesting thing, but a big part of this is, is the tool providing value to you? And over time, is it creating lift? And so maybe throughput over a long period of time of a team for a year, you might be able to see some impact there. Quality, you continue to measure to see if that's making the the change you wanna see. But then the qualitative of, are you using this tool? And then is this tool providing value? And what do you use it for still being the bigger drivers there? If the quality is continuing to either stay the same or get better.
20:23 Speaker 02 And if the team is able to do a little bit more, then that's really the the outcome and the lift we want. And hopefully do a bit more of the more interesting programming work. As much fun as migrating an old version to a new version or resolving a N P M dependency might be, that's not where I wanna spend my time. Or where I hope most engineers don't wanna spend their time. Or vulnerability patching or any of these other things that are kind of not where their expertise and skill set really show up.
20:52 Speaker 01 Yeah, I mean, I think a lot of development ends up being these kind of tasks of pushing and pulling data. You're pushing data into something and then you're pulling data to something and you're transforming it to, you know, render some view. That is not necessarily the most exciting work all the time. And or even, you know, I remember when I D's like Eclipse brought in. It's like, okay, I have a bunch of private variables. Now I can automatically generate my getters and setters. It's like, okay, fantastic. That was very helpful because writing getters and setters is not necessarily the thing that I want to spend thirty minutes on. If I can do that in five seconds, that's fantastic. But are you seeing that in terms of it being something where it does give people more time to either tackle more complex tasks?
21:35 Speaker 01 Or even sort of shift what the role of a developer is, where it's less about necessarily hands on keyboard, but more deep problem solving? And thinking at maybe a higher level of abstraction?
21:48 Speaker 02 Yeah, I think I was still was still early, but the things we're learning so far is that for those that are kind of newer in their career journey, it is providing tremendous lift, both in understanding code bases, learning new languages, new frameworks, understanding things that already exist about the code base, the dependency trees, there's huge, huge lift in that part of it. For a lot of the remedial tasks, you know, the basics on style and linting and formatting and the improvements you can make there that are just such low level, but provide great value and that consistency for others, it's great. I think we're starting to see that climb up the stack through factoring and other opportunities.
22:29 Speaker 02 But it is still, I think what we're seeing, it's still a bit hit and miss at times. And so we very much have the human in the loop in all parts. And then we still have that code review that goes on as well to really ensure that quality remains high.
22:42 Speaker 01 Right.
22:42 Speaker 02 I think the learning and knowledge piece is really high. And then as we're getting into some of more of these other tools, we're starting to see mass improvements, migrations, things that are very high value but low creative, not high value tasks can be automated really well. So we're getting lift on the things that are high value for a developer. I think we're still pushing on getting lift for the things where it really pushes them fully into that creative problem solving.
23:12 Speaker 01 Yeah, I think one of the things you you mentioned there was like the code review process. And I think one of the reasons why in many ways, like agents and even some of the things that we're doing around, you know, using these models in the workplace, like engineering has kind of been the tip of the spear for that is in part, it's because we actually have some sort of guardrails around what gets produced and whether there's basically built in quality checks. Like if it's code that can be compiled, I can at least compile it and make sure that's syntactically correct. I can run it through unit tests, presumably someone, humans probably got to be involved in the review process. It's going to probably go through multiple stages before it ever hits production. And even when
23:54 Speaker 01 I hit it in production, I might be doing some sort of Canary based rollout. So there's a lot of things that go into it before it lands in a customer's experience, essentially, where in a lot of creative work, it's harder to have these kind of like deterministic ways or process in place to actually validate that what's being produced is correct. So I think that's like a huge advantage for this because evaluating the result is hard in a lot of domains, whereas engineering has some kind of built in ways of doing that. And the other reason I think that engineering is a bit of the tips of spears because engineers historically are very good at investing their time into ways of taking work off their plate, essentially like automating tasks and making it so that they can spend time on other things that aren't necessarily like these like rope tasks. And this is
24:39 Speaker 01 the superpower way of doing some of that.
24:41 Speaker 02 Oh, 100% agree. And I think the qualitative and validation tasks, the testing and other things, there's so much we can get left from the visual testing and behavior clicking through that are more challenging to write those tests, those sort of feature level tests that are really easy for agents and other things to do, which will again provide lift. But you need some balance in the equation today. You don't want the agent writing all the tests and all the code. You know, there's no balance in that setup. So figuring that out as we continue to invest in this space is really exciting.
25:15 Speaker 01 You talked a little bit there about these tools being helpful to like a junior developer, new developer who doesn't necessarily know the codebase. And I would imagine having sort of like a not judgmental, psychologically safe assistant to ask questions to is probably really, really helpful. But do you see a difference in terms of people's either use of the tool or where they find value, depending on like their seniority, where maybe someone who's more senior really knows the system, they know how they want to implement things and maybe they see less value in the AI-powered assistant?
25:50 Speaker 02 I think it's still early days and I think some of this depends on the quality of the model that you're getting. The better the response, the more senior you are, the more you might be expecting from that response to create the lift, whereas you might get that lift as a bit more junior in your career from a perhaps less great response, but good enough to help you understand what you might need to do. But I think as we're unpacking some of these more, some newer tools in this space away from the coding assistance piece, we are starting to see more lift for the senior engineers there. And I think the concept of planning mode and being able to tweak the planning mode effectively will also create great lift too. So starting to see some green sheets there, but we'll see in six months and a year where we are on those.
26:34 Speaker 01 Yeah. I mean, I know all this is early, but do you think that looking ahead a little bit, that this is going to substantially change through the way that, or like the nature of a developer's job? It's not the developer's job's going away, but it's, does the nature of it start to change?
26:49 Speaker 02 Yeah, I think it already has. I think, you know, even if we think about the last year's worth of development, so easier to look back confidently, of course, on this, but on the last years of development, what we've learned is that you can get up to speed on a codebase pretty quickly. You can tweak and validate things in a way that you weren't able to before and you can improve the quality of the frequency of what you're able to produce by using like a coding assistant. And that's exciting and incredible as a change. That means you've got like another person almost sitting next to you, working this through with you. And the next paradigm shift is you've got another person doing the work for you. And so I do think it's fundamentally changing. I think this comes down a lot to
27:32 Speaker 02 learning that the value of the human in that loop is really around judgment and understanding of direction and being able to articulate that clearly and understand the code well enough to ensure it's getting along that path. And this is an area I I'm super excited about innovation for the next couple of years. We will see that, yes, you know, when I think about learning assembly myself, learning C++ like every time there was a big shift there, it really changed what job you were spending time on.
28:03 Speaker 01 Yeah.
28:03 Speaker 02 The day I stopped having to worry about memory leaks and download size, but these were great days for me. And this feels like another big shift, but maybe even bigger than that. But it is, I think, changing the role of the engineer and the expectations of where they spend their time.
28:18 Speaker 01 Yeah, I mean, you're right. This isn't the first time that we've had sort of these jumps in level abstraction. This is maybe a larger leap than we've seen historically versus assembly to C, C to C++. But with each of those transformations, there's also, I think, a pocket of engineers that resist that transformation because they feel like you're losing some connection to essentially what's actually going on underneath the covers. And with that, you're either diminishing the value of the engineer, or it creates too much disconnect between what's really happening at the low level of the system versus what you're actually implementing. Do you have any thoughts on that?
28:56 Speaker 02 Yeah, I think if you're an engineer that values resolving NPM dependencies or migrating from an old version of like a Java library to a new one, then this evolution is not for you, right? This is going to take you out of that space. I think that type of engineer may also love debugging issues. And that's changing as well, but there's still an area where you might really enjoy going after more roles that meet that criteria. So I think if you're challenged by this, it's probably because you love some part of the job that is now able to be handled in a way that wasn't before. And so identify where the joy is and shift to a role where you get that joy.
29:37 Speaker 02 Would be my prompt there. It's worth seeing what the lift you can get out. It's like I I talk about it like having your open book test. And choosing not to use the book. Like, it just feels like you're just missing this big opportunity to get the lift.
29:50 Speaker 01 Um hum.
29:51 Speaker 02 And here at Capital One, we are encouraging our engineering teams to get all the lift they can. We're doing it in a secure way. We're doing it with quality, without validation, with our checks in place. But we want to give our teams all the lift. Why wouldn't we? And others out there are doing it. And so you get the benefit of the industry rapidly innovating. And so that would be my prompt is if there's fear based on it, like explore and see how much you can learn quickly and adapt quickly. And I think the majority of of engineers that came in with the mindset that you called out before, if I want to automate the things that I don't need to do anymore, that so I can get out of doing anything that's not fun. That's the same group that's really gonna continue to try and learn from each new innovation coming out here.
30:37 Speaker 01 Um hum. Yeah. So we talked quite a bit about, you know, using these A I tools around like coding efficiency. But I also mentioned that's like twenty percent of the job. So how are you thinking about that, like other eighty percent? Are there investments that you're making there to also improve or increase efficiency? Or or maybe take certain things that are maybe not the fun tasks off of people's plate?
30:58 Speaker 02 Yeah, that centralized model that we're really working on is aiming to help us here. So if I think about things that aren't code that a developer spends time on, it can be triaging issues in production. It can be getting code to production in the first place, getting that deployment, the test coverage, the sort of predictability of their pipeline. And then it can be like understanding customers, understanding what the feature is in Jira. And then the coordination across teams and things as well. So as a company, we're definitely looking at productivity that matters to a business and A I tools that support there. So you can imagine we've got quite a few different things in play, both P O C and then in use as well, that get us to the point where we can
31:41 Speaker 02 get lift on A I and other aspects of it, you know, when I think about how you're writing your docs and how you can improve. On that and definitely if we can get from AI tools in that space, just as an example. The opportunity on the pipeline piece is really exciting because this is about how do we ensure the pipelines are predictable? How do we help with any errors or issues in a deployment? And how do we, again, make that selective tests run for each deployment? Like, what are some great innovations we can do there to help? Which just ensures that a dev team doesn't have to spend a lot of time on it. And so each part of that SDLC is really important for us to focus in on how do we make it more efficient or more predictable?
32:23 Speaker 02 Or, uh, the very least centralized, so and the engineering team doesn't have to spend time on it. Cause the more time they spend on other aspects of the SDLC, the less time they're spending on their code. And we want to push them back to the code at every opportunity.
32:36 Speaker 01 Mm hmm. Okay. Between all these pieces of, I don't like automation. Obviously you want to have like a strong engineering culture. Now there's automation is kind of taking a step function with generative AI like. What is peak developer productivity look like for organizations? Either in this year or looking ahead to next year?
32:58 Speaker 02 Yeah, I think peak productivity is I have an idea and I can get it in front of a user that day. And that's really the dream of where like a lot of agile development really was. And from a Capital One perspective, that's a, I can get it tested, validated, securely deployed consistently with all of our controls and behavior in place. And so there's very few touches over time where you actually need a human as part of that. And there's a lot you can do with these new tools as well to automate or validate parts of the deployment. Hey, you have these coding standards. Let's confirm that you've met them all. Let's confirm you've passed your test. Let's confirm all of these steps have happened before it gets to deploy.
33:39 Speaker 02 And this idea that, hey, we have a great idea, let's see it in the hands of a customer. That's the thing I'm super excited about because that's what it's all about at the end of the day.
33:48 Speaker 01 That's a good way to think about it. I think you're a hundred percent right. It's really what impact are you having on whoever your user base is that is like really the driving force behind all this?
33:58 Speaker 02 Yes, absolutely.
33:59 Speaker 01 What do you think one sort of common trap or mistake you see with engineering leaders is when they are tasked with kind of fixing developer productivity?
34:09 Speaker 02 I think it's really easy to track every possible metric or to track things that are going to drive the wrong behaviors. Cause I think the point around what you track and people drive to what you track and can game with. So things like number of PRs per engineer.
34:27 Speaker 01 Yeah, just make smaller PRs.
34:29 Speaker 02 Yeah, make smaller PRs. I would now with all these great tools, I can I can generate a whole bunch of PRs for you, you know, that's.
34:35 Speaker 01 Sean submitted a thousand PRs today. Wow, amazing.
34:39 Speaker 02 And we're looking at a whole bunch of what's the right quality bar, but that still enables progress. So like never having escaped defect or never having a error. That's a really extreme quality bar. And so what's the right way to measure to push on that? So each of the measures you pick really do matter and where your team will focus. And so it's easy to call out the bad ones. It's much harder to get the right ones.
35:03 Speaker 01 Yeah.
35:04 Speaker 02 But getting this idea of, okay, let's make it easy to get from code review to production quickly. So there's lots of measures we can do there. I'm super interested in exploring more and more. How do we get from story started to story delivered? That's a really cool one to start to drive that right behavior. And then of course, your point about how much time Devs is spending in code is a really interesting one because it's more about are we utilizing and giving them the information they need to do the job well, which means meetings and architecture reviews and all these discussions. So the worst thing to do there would be to track like calendars
35:42 Speaker 02 or anything like that. The best thing would be to be having your engineering managers and your others really spending time on, are we using our time effectively? Are our meetings effective? Like, there's nothing new there. That's a really important thing to check in on regularly to make sure we're getting the benefit of the team. And that's also an enjoyment factor. If the meetings are effective at getting what you need, that's a great meeting. And if they're not evolving on them as well.
36:08 Speaker 01 Hmm. You said from story start to story end. What do you mean exactly by the story?
36:13 Speaker 02 Yeah, so I would say like you click start on Jira on your backlog ladder to the time it's in production.
36:19 Speaker 01 Hmm.
36:20 Speaker 02 That's your overall cycle time there. And that gets us closer to this idea. We're talking about it. Where do you want to be? With this idea got created and it got deployed to production in front of a user. That encompasses a lot of the creative problem solving. Right? And so that's also one that could be gamed or might not be done well, but you do want an idea of how long does it take from? When we start something to when we deliver it.
36:43 Speaker 01 Hmm.
36:43 Speaker 02 There's some interesting thoughts around. That investment time. When do you recoup that investment time? So if it takes me five day to develop that feature? And I get it into production on the sixth day, how lo- how many days does it take until that feature was actually valuable for me? So it was worth that five day investment. And so interesting schools of thought, if you get really down to the heart of the value and the ROI of doing the development in the first place.
37:09 Speaker 01 Yeah, I think that's interesting. It's kind of like in the world of developer experience. You know, you look at things like time to first API call or something like that as a sort of measurement of success there. And you know, the best companies in the world are able to do that within, you know, a handful of minutes or something. You can essentially touchdown on a page and within three to 10 minutes, you're making that API call successfully. And then there's other places where that might take multiple days. And that directly impacts sort of, you know, the satisfaction and uptick of success for adoption of whatever that API is.
37:42 Speaker 02 Yeah, absolutely. And you know, a lot of that comes down to how self-service is your team? Do they know where the tools are? Can they access them? Do they have the right permissions to find them? Do they know the best practices for that tool? Like, there's a lot around that knowledge share and that discovery where this information is. Especially when someone's first starting and after they've been there for a while, are they still able to find that? When they need it, is it still surfacing in a way that? Makes that easy for them to get to those metrics you just mentioned. All of those are great ones. And then I joke that I don't think that developers are ever Happy. I don't ever, maybe put it this way, I don't ever wanna be responsible for their happiness.
38:20 Speaker 02 I do wanna be responsible for increasing their time and develop a flow state or increasing their joy at the craft. And so regularly asking and pulling and learning what the biggest challenges are and where they are spending their time in a qualitative sense. Does drive great insights and where I can help improve that depth experience and. The worst is when you get an error message that you don't understand, you don't know how to action. And so those are always some of the easiest ones to help impact and make change around.
38:51 Speaker 01 Mm hmm. Yeah. And then in terms of advice around moving to a large organization from like a smaller organization. What would you advise people, you know, engineering leaders making that kind of transition?
39:04 Speaker 02 Yeah, and even just culturally different organizations operate. So I think this advice would be true moving from big to big, just different. Every company is a bit different on how they operate. And I think, I think the first thing you you really have to do is get to know how that company operates. What are the norms around communication? What are the norms around behavior? What are the norms around prioritization? Who communicates it? How often is it communicated? What is tracked? What surfaces at what level? And so to getting a sense of what matters to the company on that, that's sort of the metrics piece. But then also, what's the communication style? How is bad news delivered? Is a really interesting one, just to get a real sense of, does it match what you're used to or does it differ? And what are the things that are really celebrated?
39:49 Speaker 02 I think is another really good one to understand that cultural shift. And one shouldn't assume large means slow. Cause I don't think that's been true. And I've jumped around a bit, company size wise. Large just means that if you can jump on the established pattern or routine. You'll get a lot more lift if you want to try something completely new. It'll be a lot harder at a large company, but if you can identify the routine that exists already and jump on to it and sort of add to it or iterate on it. Then you can sort of really get that speed of change happening as well.
40:25 Speaker 01 Awesome. Well, guys, when we're coming up on time, but is there anything else you want to let our audience know about?
40:30 Speaker 02 I think the exciting thing in this space is there is a lot around where we're heading as an industry that should create more developer flow and developer joy in that flow. And if you're not seeing that yet, or if you're working somewhere where that isn't being championed, that innovation, definitely look around because there's lots of opportunity in this space that I think should highlight and encourage you to increase your skill set and really be valued for your judgment and your experience in this space. And that's what's got me super excited about serving the large audience we have of developers at Capital One. And I think this is a really exciting time to be a developer.
41:12 Speaker 01 Yeah, absolutely. Well, thank you so much for being here. I really enjoyed our conversation. Cheers.
41:17 Speaker 02 Thank you, Sean. Really appreciate it as well.
Previous Flox, Nix, and Reproducible Software Systems with Michael Stahnke Next America Under Surveillance with Michael Soyfer Page updated November 6, 2026 · transcript and summary are machine-generated