B (3:17)

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?

A (3:34)

Yeah, so developer enablement, a colleague of mine actually mentioned this term for me and I just loved it. So I've latched onto 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 the code at a certain rate, is it at a high enough quality? And is it getting into the hands of users fast enough? And 15, 20 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. So the product management side of this really sparked this idea of let's ensure we're building the right thing and we understand our users 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 is really about give them the tools but the information as well to be able to do their job well.

B (4:49)

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?

A (5:08)

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 it'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 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, they're understanding it and discussing it and seeing how they can improve upon that experience overall, not just delivering a feature.

B (5:57)

Okay. With such a large organization, we're talking about 14,000 people. How do you even measure the success of developer enablement at this scale?

A (6:07)

I love this question because there's so much going on around developer experience. What do you measure? Years gone by, there was a really big great push around doors, aura, 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 work around 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 a lot 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 is a really interesting one to see. Are you getting 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. 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 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. 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?

B (7:49)

Yeah. And is some of this always going to be a little bit dependent on the organization too? You're going to have. 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.

A (8:04)

Yeah, absolutely. And like, I like using specific examples. So we've had teams focused on different parts of their software development life cycle. 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 am I pointing them to where to go to discover things and then am I giving them the right training and starting position 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 10th commit are really, really great. And the 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? Because if you know you're being measured, that will change your behavior as well.

B (8:52)

Yeah, you tend to optimize the things that you measure. So that's why you gotta be careful about what you, what you measure.

A (8:57)

And you know, developers, I think of all the customers in this space are fantastic at gaming metrics.

B (9:03)

Yeah, absolutely.

A (9:04)

That's definitely one of the factors you consider as you look at this.

B (9:07)

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 want to 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 PR or something like that, that's probably going to lead to a certain. Manage the status satisfaction for a number of people.

A (9:31)

Yeah, absolutely. If you know you've been hired to commit code at some level by your job family that you're in, ideally you want to 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 want to demonstrate value as well as that satisfaction of the job is giving me what I expected to.

B (9:51)

Yeah. Given that Capital One's in a very highly regulated industry, you're going to have certain compliance and security considerations that probably a regular sort of software company might not have. How do you end up balancing, like 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.

A (10:17)

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, 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. 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 that require less work on the development teams.

B (11:35)

Yeah. And I guess it gives you some efficiency too, when people kind of move around in the organization, because 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.

A (11:46)

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 the absence of a standard. But it does prompt us fairly quickly to establish, well, what should be the standard here?

B (12:07)

How do you make that decision about sort of what the standardized or centralized 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 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 LLM, 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?

A (12:43)

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 it as 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 on the LLM 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. So, yeah, get go. We've been standardizing on what is our success criteria and improving upon it each time for every 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?

B (14:15)

Yeah, I Think it's tough when you're in these like in early innovation cycles because it's hard to. It was, you know, it's hard to know what would be the right choice in. The right choice today could change drastically in like a week from now 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 velocity down the road because you become locked in and tightly coupled to one way of doing things.

A (14:44)

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 how locked in will you be if it's easy to migrate now because you have tools that enable that migration? 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.

B (15:14)

Yeah, makes sense. So I know you have rolled out LLM 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?

A (15:28)

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 and the messaging around coding assistance and AI tools is there was a lot of fear, a lot of concern that this will replace my job.

B (15:42)

Yeah.

A (15:43)

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 CEO, 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 POC and a pilot and scaled it out and really started to track well who was getting benefit from it. 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.

B (16:52)

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. 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, whether it's like design reviews or thinking about architecture and 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 the 100% time, but it's actually you're kind of optimizing 20%. So I'm curious to see how Capital One is thinking about like that other 80% as well.

A (18:12)

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 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 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 would 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 is that perhaps the worst 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 change you want to 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 and if the team is able to do a little bit more, then that's really 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 NPM dependency might be. That's not where I want to spend my time or where I hope most engineers don't want to spend their time or vulnerability patching or any of these other things that are kind of not where their expertise and skillset really show up.

B (20:52)

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 into something and then you're transforming it to render some view that is not necessarily the most exciting work all the time. Or even I remember when ides 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 30 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 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 attraction?

A (21:48)

Yeah, I think I was still. We're 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, refactoring and other opportunities. 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.

B (22:42)

Right.

A (22:42)

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

B (23:13)

Yeah, I think one of the things 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 using these models in the workplace, engineering's 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 going to be involved in the review process. It's going to probably go through multiple stages before it ever hits production. And even when 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 a tip of the spear is 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 rote tasks. And this is the superpower way of doing some of that.

A (24:41)

Oh, 100% agree. And I think the qualitative and validation tasks with testing and other things, there's so much we can get lift from the visual testing and behavior of 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.

B (25:16)

You talked a little bit there about these tools being helpful to like a junior developer, new developer who doesn't necessarily know the code base. 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 they maybe they see less value in the AI Powered assistant.

A (25:50)

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 seen 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. Some of these. More. Some newer tools in this space away from the coding assistant 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 shoots there, but we'll see in the six months and a year where we are on those.

B (26:34)

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 sort of the way that. Or like the nature of a developer's job? It's not that a developer's job is going away, but does the nature of it start to change?

A (26:49)

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 in the last years of development, what we've learned is that you can get up to speed on a code base pretty quickly, you can tweak and validate things in a way that you weren't able to before, and you can improve the quality or the frequency of what you're able to produce by using a coding assistant. And that's exciting and incredible as a change, that means you've got 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 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'm super excited about, the innovation for the next couple of years, we will see that. Yes. You know, when I think about learning assembly myself, learning C, every time there was a big shift there, it really changed what job you were spending time on. The day I stopped having to worry about memory leaks and download size. These are 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.

B (28:18)

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?

A (28:56)

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 NGO 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 would be my prompt there. It's worth seeing what the lift you can get out. It's like I talk about it, like having your open book test and choosing not to use the book. It just feels like you're just missing this big opportunity to get the lift. 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 engineers that came in with the mindset that you called out before of, 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 going to continue to try and learn from each new innovation coming out here.

B (30:37)

Yeah. So we talked quite a bit about using these AI tools around coding efficiency, but I also mentioned that's like 20% of the job. So how are you thinking about that? Like other 80%. Are there investments that you're making there to also improve or increase efficiency or maybe take certain things that are maybe not the fun tasks off of people's plate?

A (30:58)

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 AI tools that support there. So you can imagine we've got quite a few different things in play, both POC and then in use as well, that get us to the point where we can get lift on AI and other aspects of it. You know, when I think about how you're writing your docs and how you can improve upon that and definite lift 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 their deployment. 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 or at the very least centralized. And the engineering team doesn't have to spend time on it because 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.

B (32:37)

Okay. Between all these pieces of like automation, obviously you want to have like a strong engineering culture. Now there's automation's kind of taking a step function with generative AI. Like what is peak developer productivity look like for organizations either this year or looking ahead to next year?

A (32:58)

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

B (33:48)

That's a good way to think about it. I think you're 100% right. It's really. What impact are you having on whoever your user base is really the driving force behind all this?

A (33:58)

Yes, absolutely.

B (33:59)

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.

A (34:09)

I think it's really easy to track every possible metric or to track things that are going to drive the wrong behaviors because I think the point around what you track, people drive to what you track and can gamify. So things like number of PRs per engineer.

B (34:27)

Yeah, just make smaller PRs.

A (34:28)

Yeah, make smaller PRs. I would now with all these great tools, I'm can, I can generate a whole bunch of PRs for you. You know, that's the sense.

B (34:35)

Sean submitted a thousand PRs today. Wow, amazing.

A (34:39)

And we're looking at a whole bunch of what's the right quality bar. But that still enables progress. So like never having escape 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. Yeah, 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 are 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 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.

B (36:04)

Yeah.

A (36:05)

And if they're not evolving on them as well.

B (36:08)

You said from story start to story end, what do you mean exactly by this story?

A (36:13)

Yeah, so I would say like you click start on JIRA on your backlog item to the time it's in production. That's your overall cycle time there. And that gets us closer to this idea we were talking about of 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. There's some interesting thoughts around that investment time. When do you recoup that investment time? So if it takes me five days to develop that feature and I get it into production on the sixth day, 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.

B (37:09)

Yeah, I think that's an 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 a handful of minutes or something. You can essentially touch down on a page and within three to ten 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 the satisfaction and uptick of success for adoption of whatever that API is.

A (37:42)

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 of 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 want to be responsible for their happiness. I do want to be responsible for increasing their time in developer flow state or increasing their joy at the craft. And so regularly asking and polling and learning what the biggest challenges are and where they are spending their time in a qualitative sense does drive great insights on where I can help improve that deaf 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.

B (38:52)

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.

A (39:03)

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. I think the first thing 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 sort of getting a sense of what matters to the company on that 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. I think is another really good one to understand that cultural shift. And one shouldn't assume large means slow because 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 onto 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.

B (40:25)

Awesome. Well, Catherine, we're coming up on time, but is there anything else you want to let our audience know about?

A (40:30)

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 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 larger audience we have of developers at Capital One. And I think this is a really exciting time to be a developer.

B (41:12)

Yeah, absolutely. Well, thank you so much for being here. I really enjoyed our conversation. Cheers.

A (41:17)

Thank you, Sean. Really appreciate it as well.