How Capital One supports 14,000 technologists with one pipeline | Ameesh Paleja

27:13We're talking about people's money. People don't mess around with their money all the way down to the individual person. uh hey amish don't mess up my money please but also all i'm sure you're working with like businesses and all of that money is super serious uh in america and around the world so for the listeners it's like in this whole context of the conversation think about components of your product that you have to get right there's no room for this is experimental or Or, yeah, we're just trying to move fast. And if a bug gets released, okay, we could just fix it within an hour. We're not in that mode.

27:55We're in money mode. So that's the mindset. Now, with that, I want to ask you, is there one maybe specific example that you could think of at Capital One where you came in and said, hey, this thing wasn't standardized before? I know you probably can't share everything with us, but one example like, hey, this thing wasn't as standardized as we'd like it. And you dedicated effort to making it standardized. Is there something that comes to mind there? Yeah, I would say a great example of where we went from kind of good to great is our kind of operations and SRE team. When you think about standardization, you have to start all the way at the bottom of the stack and say, our data, our logs, right?

28:45Data is growing so fast these days. It's like a 25 % year on year category. And like you think about, I want to say the last stat I saw was like, where the world is creating like 180 zettabytes of data a year growing at 25%. It's wild. Like, yeah, like you can't even comprehend like that. My brain doesn't work on zettabytes. Like, yeah, right. You know, even exabytes are hard to kind of imagine, you know. So when you try to grab zettabytes, it's wild. And then, you know, the other fascinating stat was in the last three years, something like 90 % of the world's data historically was created in the last three years.

29:26Right. So all data of all time, that's such a wild thing. And so when you think about just a simple foundational piece of like, where do I put my logs? Like I'm collecting more and more things, click streams, events, I'm collecting, you know, instrumentation and longitudinal data. And how do we keep it organized? How do you know, so we start off with great, get great data, right? And then on top of that, once you build that, then you can start building standardized automation to say, okay, I have my metrics, and I have my observability. And then when you have that, you're like, what do I do when there's a problem?

29:59Well, I can build automated playbooks. And then once you have the automated playbooks, now you're like, well, can I have agentic software looking around corners, finding correlated paths that maybe humans wouldn't be observing, but like a machine could look at thousands of variables every second all the time and catch things while there's smoke and not fire. And so our ability to actually drive incredible improvements in reductions of our high severity incidences, our mean time to detection, our mean time to resolution have all improved dramatically. And I have to kind of lay it at the feet of just amazing engineers, amazing data folks all working together in concert to create the standardization, the automation, and the enterprise platforms that are going to actually get us to the spot where we feel very comfortable that we know what's happening in our world.

30:50We know we can analyze all the data. We can quickly find out what the problem is and then quickly resolve it. And the best part, Dan, is a lot of this is automated, right? It used to be that somebody gets paged at three in the morning and, listen, I've carried a pager myself and it's miserable. You're waking up, bleary eyed. You're looking at logs. You're going on Splunk. You're doing this and that. And you're like, where the hell is the problem? And what if the machine just told you that? And we're at a time where that's actually really possible. It's more than possible. It's actually happening right now.

31:24And the folks here have just shown a lot of like awfulness, grit and innovation to kind of make that happen. And it's like a very powerful story for us. Thank you for sharing. That's a great example. Our customer base at Linear B, so I know a lot of the audience is familiar with MTTR, meantime to restore, recovery, change, failure rate. These are things that are tracked. These are things that are presented at board meetings. These are things that you might even, I don't know, a capital one, but I'm sure there are metrics that you need to show to someone. And SRE teams, that can be a high pressure job.

32:03I mean, SRE, like you said, you could be woken up in the middle of the night. You could be on not much sleep. The pressure's on to figure out what the heck is going on here. And I would think that automating that, and I'm sure you're doing stuff with AI and I can figure out the insights and all of that, probably goes a long way to help those folks. And when you were thinking of that initiative going from good to great, is it like, should I be thinking, OK, I need all my logs in one place under one technology? Or is it like, hey, I already had it all in one place, but it's more like, let me put some AI on top of this so I can decipher the insights and I can talk to it.

32:48Like, uh, is there any specifics there? Cause what I'm trying to get to for the audience is like, how do you like think about deducing this problem into like steps, uh, to get to standardization? The decomposition is a, a, a tricky problem, right? It's like, what'd you start with? With something this big, with this many people working on it? I would say, you know, one of the first things is really just break down the problem into it's kind of foundational pieces and then all the steps that you can kind of go up, right? And so as like a simple example, let's pick on data for a moment, right? Okay.

33:26People are writing log files in different ways. The tools that they use that they write them with are different. How do we like, how do we consolidate on like, oh, I'm using UTC over here and I'm using Pacific time over there and the format, some of them are in parquet, some of them are in different formats. Some are using, you know, Apache Iceberg format or Delta from Databricks. Like there's a lot of like, you know, arbitrary uniqueness within the stack and even just the destination of where do we put it. Right. Some of it we're storing in log files. Some of it we're storing in databases. And so picking some choices that I think a lot of times these are just six of one and half a dozen another.

34:08And when you have, you know, 14 ,000 developers working on this stuff, you're bound to get differentiated answers. There's no bad dogs in this, right? But it's like if nobody's actually declared a standard to say, we're all going to write in this format, in this location, so it sits in the lake. And then we have option value to say analytics can run over here. AI can run over here. Operations can run here. But they're all going to leverage the same data source. That becomes an incredibly powerful story. And then, you know, it eliminates a lot of variation that just makes all the automation super painful and kind of it makes the juice not worth the squeeze.

34:47And so, like, the more you can kind of standardize on some of these simple decisions right up front, the easier it gets when you're going up the stack to make some of these more interesting automation capabilities available. That totally makes sense. I wanted to pick your brain on this because it's similar to either the customers that we've worked with or my own experience. When I think about standardization, I think you gave actually the same example. A lot of the times I think about quality. you gave an example like when I think SRE I think okay like helping us improve quality make sure there's not outages and like respond quickly and that type of thing and for the customers that I'm working with and you probably already have this but we think about pull request quality so for example a pull request gets open what are the set of standards across all teams that we at least go through.

35:45It could be, hey, we do an AI code review, but then we have rules that a human needs to review it in some situations. We have test coverage. And the reason for me, when I think about standardization and quality, I think they go together very well, but they also then lead to efficiency. Like if you're in engineering, you kind of know that there's like quality can actually They make you move faster and all of that. So now they'll put you on the spot. I am going to do it. Do you have a standardized like pull request process? Does your team help with that at all? And what do you think about like quality and standardization?

36:28Do those go together for you as well? I love this question. And it's such an interesting topic because there's a lot of nuance buried within it. I'll start off by just simply saying my team owns the developer experience at Capital One, so the full kind of SDLC pipeline. It's an exciting space and there's a lot of innovation going on, but there's a lot that we could bring into the system and a lot of variation that spins up. The first and biggest thing that we did was we consolidated on one build pipeline. So instead of having hundreds of Jenkins instances running around, Gradle doing this and that, right we said hey we're gonna have one pipeline which we actually call one pipeline um we we spent a lot of time and much of the credit of you know our our founder rich and our our board members and our uh executive committee they were all like bought in like when i came into the company i didn't have to sell anybody on this they were like this is important to get standardized on this front and what we found was from a quality perspective right we're able to implement the right tools and the right instrumentation right in the build pipeline so that as we're moving out, do we have the right images?

37:38Do we have, you know, as an example, like, do we have distro-less images that get rid of a bunch of vulnerabilities that we don't need to have, right? That kind of stuff is like, if you're standardized, it's a lot easier, right? It improves our quality. So we're not running around with our, like, heads cut out going, oh my God, log4j this, and we have to, like, everybody's scrambling for the next month and a half, right? We're like, oh, that's one library and everybody picks up a change. We just need to redeploy, right? When we think about things like code reviews and, you know, it's with this size of an organization, you're going to get uneven code reviews on your PRs, right?

38:12You're just like, you're going to have some junior people looking at it. You're going to have some very senior people. You know, we fall into the classic trap of, oh, I submitted a thousand line PR and I get zero comments and i submit unlike the art i get 500 comments on yeah they're like very because who wants to review a thousand line pr it's gonna be hard to get right and so can we put policies in place and that's a different type of standardization right and you know you know i i i kind of look at that and say what are the best practices that we can teach through policy what are the best practices that we can enable uh via kind of ai code reviewers right things like oh you have too many return points in this function.

38:53Your cyclomatic complexity is too high. Refactor this, or there's copy and paste code here. That should be a function and just break it down. All of these things are super powerful. They up-level the quality of all the code that's being developed. And it gets us to a point where I think is the most important thing is that once you enable these things in the SDLC pipeline, you are on a path of continuous development, right? At the end of the day, when I speak to our executive committee and our board and our senior leadership, right, they want to be able to develop and deliver better features faster to our customers.

39:32But I think you and I both know that so many times the defects that you see and the incidents you see are deployment related. Like I pushed out the deal, something broken and I have to roll it all back. So how do we minimize the amount of pain that we feel at that time? So can we have automated testing? How do we, well, you want automated testing? Well, you have to have automated, you know, the right frameworks and the right tools, and those have to be consistent so that people can build on top of them. Then you have the environments. How do you standardize your environments and automate those environments, right?

40:06All of these things lead to a spot where we're actually doing CICD properly. And that creates this ecosystem. And I'm very proud of the folks here that we've been able to increase our number of changes. We dramatically while decreasing the number of defects going out to production because we've implemented all these quality tests and in systems and tools right up front. And Dan, the biggest thing I would say, the biggest kind of unlock was shifting as much left as we possibly could. So wherever we could kind of help the developer on the interloop, on the, in the IDE or, you know, where before they even get to the point where they have to run this test, like how much can they do on their own quickly and efficiently on their laptop when they're, you know, sitting in the airplane or wherever they're working, right?

40:57Give them as much power as we possibly can to debug as much. And then when it goes through the whole pipeline, we're doing all the kind of last validations, the checks and the standardized tooling against it to make sure that we're pushing out great quality code that's been validated lots of different ways. yeah like uh and again like you're in a situation it sounded like you had the mandate of hey let's build features faster which i think most engineering leaders uh get that mandate but we cannot reduce quality and we're probably in this regulated world and we can't get anything wrong so that's kind of a tough challenge now what you had going for you it sounds like is the business was already behind you on standardization like you didn't have to prove why it's important.

41:48For someone listening that wants more standardization, you might not know because you didn't have to do it here, but you might. If I had to prove to my business, like why a standard, let's take the build pipeline because everyone likes that whole, let's say a pipeline from, Hey, developers are starting to code and they're probably using stuff like copilot cursor or like things like that all the way to deploy. If you had to convince the business, why standardizing certain pieces of that pipeline were important? How would you make a pitch to your CEO or whatever? This is a fantastic question. What I would say is that having multiple teams running their own pipelines is basically you're repeating CapEx costs over and over again.

42:34Yeah. So why do that? If you have everybody building V1, let's say you have 10 teams building V1 of this and and the minimum investment that you have to put is at least, let's say, five engineers against it, all of a sudden you have 50 engineers working on V1 of the software, but you have 10 different versions of V1. Why not just have 10 people working on V5 of this thing, where it provides all of these kind of well-managed capabilities that reduce your defect rate, that add all the linters and the static code analysis, the dynamic code analysis, the security analysis, all the things that are causing you problems downstream in your run the engine cost or keeping the lights on cost, right?

43:15Because every team also has that. They have to like, how do I just keep the machine running all the time? So I look at it in two ways. One, we're just being inefficient because people are doing the same work multiple times within the same company. That doesn't make a lot of sense. And with just a small amount of incremental tax, you can actually create a multi-tenant platform that provides a lot of value. But more importantly, you end up on the other side of that, that your daily operational costs, you know, if I have 100 engineers or 1 ,000 engineers working on it, I'm saying 20 % of that time is just fixing bumps and maintenance and, you know, updating this library and, you know, changing this.

43:55That's not very exciting work. And so getting leadership bought on to it is like, I'm going to reduce my run the engine cost down getting engineers bought into it is I'm going to take this boring work off of your plate, right? Like I could have to go do cool stuff rather than like I'm upgrading from Spring Boot version X to Y. Like, look, I'm an engineer. I, you know, I like, that's not exciting. Like I can't imagine anybody on your listenership. This is like, I'm really excited to upgrade to this version of Python. Like that's not a thing, but. I love the answer because you said three things.

44:34I want to summarize it. first of all, the business talks money. You came in and said, I'm going to reduce costs. That was your first point at the end of the day. The second thing that I think your business understands, but most enterprises is, I'm also going to increase quality while I do that. So I'm going to save you money. I'm going to make the quality better, two things. And then, and this is where I think we should take the convo next. You said, I'm also going to make developers happier. I'm also going to now if I could do those three things for you through standardization would you want to do this I think most of the time a smart ceo or the board or whoever you're trying to convince is going to say yes uh amish uh please do that for us and you're going to say no problem thanks I got the buy and I'm going to do it do it for you now you uh again talked about the the build pipeline and I think developers let's talk about the developers and experience and standardization.

45:31I opened up a bit by saying sometimes I've seen developers push back against standardization. Hey, you're going to make me use a certain tool. You're going to make me do this or make me do that. But I've also seen developers get bought in to standardization if certain things happen for them. How do you think, and you can stay in the build pipeline if you want to, you could take it anywhere but like how do you identify these areas hey we should standardize this and i also think that developers will like it like you need both of those to probably go together like how how do you identify that and like what's your thoughts on that i think that that's a it's it's a two-part answer one is what is causing the pain in the in the in the enterprise like if i look at my you know keeping the lights on or run the engine across and i try to break that down and say, where are we spending most of our time?

46:29If you said, oh, it's on, you know, vulnerability patching, as an example, right? It's stuff that we have to do, but it's not exactly exciting. And we spend, I don't know, 10 % of our time doing that. Like, I would say, hey, there's a big opportunity here from a cost savings perspective that we want to do. And then the other side is, you know, that developer happiness and excitement. I want our engineers to feel empowered to work on things that require creative judgment. You know, in this time and age, I mean, like, look, I'm sure you've had everybody talk about AI over and over again. The reality is, is that the world changes every six weeks, eight weeks.

47:10Like, there's something new that comes out. You know, yesterday it was cursor. Today it's, you know, cloud code. The next day will be codex. I'm like, you know, it's hard to keep up. But the reality is that I want our engineers to be empowered to work on the things that get them excited. And part of the way I could figure that out is just actually talking to them. I'm one of them. I feel like I'm one of the guys in the trenches with you. And I wanted to understand deeply what people care about, where they want to spend their time, what's getting them excited. and being able to unlock the right tooling and capabilities, again, in a well-managed way, is important because it keeps their kind of intellectual interest moving forward in the right direction.

47:57So look, one of my biggest goals is how do I create an incredibly powerful and happy community of engineers that are focused on creative problem solving and not mundane work? How can I get the BS work off of their plate is really the biggest thing I can sell engineers on. I agree. I think all of this actually, now that I think about it, fits together. But let me give a try to see if it all works together. So identifying BS work. So the opposite of BS work is I'm solving a complex problem that maybe only I could solve. It's never been solved before. The business is asking me to do it, so it's valued.

48:43and the bs uh side i think for at least for me as an engineer but maybe for most is like kind of those things i'm actually going to go back to quality and some of like i never for example i didn't love reviewing code i didn't love doing security updates um depend about opened up a pr and it's like a patch and it's totally fine i didn't like get distracted there's almost this like ecosystem thing of that surrounds my innovation that kind of wastes my time. And a lot of that could be automated. And if you're able to standardize and then automate that for me, the stuff that's not my core work in the, I would be happier.

49:31And I was wondering if you're able to say, you talked about like the build pipeline, We talked about the SRE side, but if I was moving more left, was there anything that you were trying to go from like good to elite in terms of the developer experience that you all identified? Hey, if we focus in this area of the SDLC, I think we can get that standardization plus the happiness boost. I think we're getting into a little bit of the secret sauce here. But what I would say is that the focus on automating everything except the creative problem solving is like the kind of principle thinking around this.

50:12Right. And so as you think about everything from front end development all the way to back end development and everything in between performance testing. itself is an enormous task, right? When you think about, like, I need to build my unit test, I need to build my integration test. This is an area where, holy cow, you have the right standardization, you have the right standard infrastructure, the right standard tooling, you know, even adoption of things like, as an example, I'll give you, like, Otel, right? We wanted to adopt Otel across the entire enterprise. And you can imagine, you know, the last 10 years, you know, Capital One has been building instrumentation all across, you know, and telemetry all across the company, all in different ways with different vendors and different this and that.

50:58And we just, you know, plugged in, you know, some AI capabilities in Windsurf. And we just said, hey, you know, just submit PRs to everybody. And lo and behold, what would have taken hundreds of thousands of hours now took a thousand hours to get done kind of thing, right? Yes. So there's some really powerful opportunities and i don't i feel like smart engineers i don't have to go and tell them like hey you didn't you didn't have to do all this like hard like busy work right aren't you happy that we standardized to to get this off of your plate so you can work on the cool problems right that's the stuff that like i think gets people excited and bought in um and i i would say the one last thing i'll just add on this is i try to find the hardest skeptics in the company you know own my most curmudgeony, and you have to get the swingers engineers.

51:47And if I can get them bought in, I feel like I've solved it. Then you know you're on track. They'll be my salespeople for me. Thanks for getting into the details because that's the thing that our audience, I think, really appreciates. And you're doing a really great job of that. I am going to take us a little bit higher level now. So I'm going to ask you a question here. How does Capital One define what an enterprise platform is? I mean, you're either building an enterprise platform or you're supplying these enterprise platforms. What are the essential components and why are these platforms so critical to your overall technology transformation and your business strategy and all of that?

52:34I think the simple way to put it, I mean, I would hazard a guess, like kind of the textbook definition is kind of like a set of tools, capabilities, APIs, software services that are common, that are reusable. I would say Capital One adds multi-tenancy on top of that and, you know, well-managed, operationally managed, right? There's a lot of kind of attributes of a great enterprise platform. And you don't have to have all of these, but I would say they're pretty good foundational pieces to say, if I build this, many people can use it. It's reusable in lots of different scenarios. It's well-managed and well-governed.

53:14We're also very mindful of our cost infrastructure and tagging and all the kinds of things like resiliency. right uh you know especially you know you've you've said uh you know we're a well-regulated industry and we're dealing with people's money like of course like yeah i don't want to have to say like oh are you in are you in three az's oh no you're only in one az and in one region like no we want everything in multiple regions multiple az's we want this we want that so when you can combine all these efforts of the kind of well-managed reusable components that enable everybody to go faster that's the thing that i would characterize as a great enterprise platform and as i said it can be all the way down to kind of just standards like api standards to sdks to actual full-blown services it doesn't like you shouldn't necessarily pigeonhole yourself into like it's only you know a a service that you're running or something like that yeah i mean with a company your your size and maybe the amount of like i don't know platforms that you're delivering to your developers.

54:16I know for our listeners or like our customer base, we use a lot of data to decide where in the software delivery process are there bottlenecks. And then we kind of back it up with like surveys. Okay, let's go ask the developers to also see, you know, is that legit of what the data is saying? And then maybe they'd say, okay because we're seeing a bottleneck in the coding uh process from you know the first commit to opening the pr we feel maybe and i'm making this up we feel that we need to bring in some a more ai tooling because we might be falling behind there with all of the things that you could do which is probably a lot how would you even like determine your roadmap of what to do next.

55:06I mean, look, this is a very tricky question. I don't know if there's a perfect answer to the case here. I try to kind of balance a couple of different variables. One is that developer happiness, right? Yes. What is causing kind of frustration or anxiety or fear among people to say like, I can't go faster because I'm nervous about X or Y or Z, right? So does that mean that I have to improve my testing? I have to improve my tooling? in the SDLC pipeline. I want to be able to measure all of this stuff so that I can have an objective and subjective answer. So like you said, what does the data say?

55:43What do our people say? I think it's super important. That efficiency, I think, is an important part of the puzzle, particularly in today's day and age. Again, the second part is what is going to create the most business value and impact? Part of the reason why I took this job is that I feel like there's you know, creating platforms for the whole enterprise. You know, my team owns our app and website. We own our next generation ledgers. We own our marketing systems. We own all these different pieces. And it's not just, you know, while we're talking to a developer audience, the stuff that we do not just affects the developers, but it also affects our marketers, our business analysts, our data engineers, our data scientists, right?

56:26Where we can find these opportunities, I try to kind of think about where the leverage is. And that could be measured in developer happiness. It could be measured in business impact. It could be measured in customer satisfaction scores. And so I work with our product leaders and our business leaders to kind of come up with the right set of kind of heuristic functions. Kind of the F of X of Y says, this is my priority. I don't know that there's a slammed up, like, just do this in this order, and you're going to get it because it really is business dependent. But what I would say is oftentimes the mistake or the anti-pattern here is that people only look at one of those dimensions.

57:06And I think that if you want to be a successful engineering leader, you should be looking at all of those dimensions to help the whole business out, not just narrowly looking at your people or your specific area. Like we're Scotty from Star Trek, right? Our job is to make everybody work and be happy and excited. And sometimes that's firefighting and problem solving, then sometimes that's looking ahead and saying, you know what? We need to be able to go faster than War 5. We need to go better, faster, stronger, right? Like we talked about. Like the song. Well, yeah, I think you're absolutely right that it's not one input.

57:46So it would be a mistake to just look at one input of data and then be like, okay, I'm going to make all my decisions on this. and the other thing that i see um customers doing is they're taking these different data inputs you opened up our conversation of how much data is being created they're taking these different data inputs okay let me measure and benchmark like our sdlc let me see how our developers are doing from like a dsap perspective let me also input like what our business wants to do I'm seeing now, this is what we're doing at Linear B That we can put all of this information Through like an MCP into AI And I can ask a bunch of questions now Which I think is becoming fundamental Now I understand that maybe some of the larger companies Or regulated companies I don't know if that's allowed yet But I do want to tell the audience It's like, if you're not doing that, I think it's available to you.

58:50And the other thing that I want to throw at you here is I think Capital One calls itself a technology company that happens to do banking. So if we're and you have all of this data, if we put all of that together, how do you ensure? I know this is a big question. How do you ensure that 14 ,000 technologists and maybe there's others like not even technologists like how can you access all of this data and daily use and meet all of your governance criteria like that is kind of mind boggling to me like what are you doing there? You know, it's a very challenging problem, to be totally honest. But what I will say is that we have the commitment of investing the right people in the right tooling and capabilities.

59:44So like we have a wonderful, you know, risk organization that's constantly kind of who watches the watchers. You know, they're like, they're looking at us. They have a second line risk organization that's watching them and validating what their concerns are. And we're all helping each other in concert to make sure that we're staying well managed. This is just like one example of this. So what I would say is, is that at this size and scale, investment in the people is incredibly important. Making sure that those people are mission driven and they have the right tools, capabilities and funding to actually do the thing that they're supposed to do, I think is important.

1:00:21And then once you have that in place, then it's like, okay, well now how do we instrument things correctly? How do we, you know, what's that famous Peter Drucker quote? You know, what is, what is measured is managed. I 100 % believe that, right? Me too. And so having the right instrumentation, I mean, LinearBee does that incredibly well across a wide variety of tools, right? Whether it's Git or Jira or whatever you're looking at, that work is gritty and it's hard. And it takes some fortitude to have the mindset to say, I'm going to invest in this now because when I come out the other end, I'm going to be 10%, 20%, 50 % smarter and faster at my deployments.

1:01:03you have to believe that the outcome is going to come and I don't think it's I think if you look around the industry the people who have done the investment and have done the time they're already reaping the benefits and I'm like out of capital one that like we've won little battles and we've been able to say okay we took a small bet here now let's take a medium sized bet now let's take a large size bet right and that results in our ability to create that kind of positive flywheel that long-term investments will yield long-term value for the company. And that's not just people, it's tools, it's capabilities, it's instrumentation.

1:01:46And it may mean that like in the short term, we have to say, I'm not going to build customer feature X because I'm building developer feature Y, but it's going to help me put rocket fuel in the tank. Yeah. I love that. Wow. There's so much to unpack, but I am happy that you kind of ended that by saying, sometimes you do have to also go back to the business and say, if we invest into our infrastructure or DevX or whatever it is that's more internal, I can get you that feature. But it's not only that one feature. It's lots of features that you're going to ask me for at a later date and an accelerated rate.

1:02:30Now, because we're in the era of AI, and I do think AI is a real thing, I'm seeing it. Our customers are seeing it. How do you go about incorporating AI or policies around that when you're in such this regulated world and you can't make mistakes and you got the money thing going on? Is there anything you could tell our audience of how you approach that or guidelines around it is it automation or something different like how are you taking that on boy this is this is a complex question that yes date all the time right and regardless of whether you know uh you're in a bank or you're you're you're working with money or not like i would i would say it's important to be kind of go in eyes wide open uh on this topic because it's going to impact you one way or another right like Like, so I would say, first and foremost, the amount of kind of mutability that's happening on the kind of top of the funnel in terms of tooling and capabilities, right?

1:03:34Like every weekend, I'm like, oh, I saw this new thing on Codex. I'm going to go and try it this weekend. By the time I get to it, there's some other announcement that says, oh, actually, you should try this other thing. And I'm like, I can't keep up with the amount of change. And the power that we have is that we have 14 ,000 developers that are all intellectually curious, right? They're builders. They're excited about this time. I mean, it's a sea change moment in the industry and candidly, the whole world. So, you know, the kind of forward progress that I'm trying to have with the company is can we create environments and sandboxes that are compartmentalized, that have synthetic data, that have like the information and kind of fake or anonymized information that can be kind of played around with.

1:04:19so that we can enable our engineering and product leaders to go and test and play and experiment and explore all these new tools. And once we have that top of the funnel, they immediately say, yes, this is good for us or no, this is not good for us. And we kind of separate the wheat from the chaff. And once they have like, out of the 50 tools that I was looking at, these are the three that I care about. I want to add rigor there, right? So then we say, okay, do they meet our cybersecurity standards? Do they meet our risk standards? Is there DLP? If I put highly sensitive data or PII into the system, is it just going to get leaked into the models and we're going to be in trouble?

1:04:58So we have a pretty rigorous process behind the scenes and a great set of people that are kind of not only establishing today's standards, but also continually updating them because six months ago, MCP wasn't a thing. Today, it's a nice thing. ADA is the next thing. And, you know, again, all of this stuff is changing so fast. So you have to have people dedicated to build craft and possibly updating your policies and standards. But you don't want to cut your own legs out from underneath you by trimming the funnel too high and say, well, we have to have a standards committee doing this. And if it doesn't meet these 50 things right up at the front, then we just can't talk about it.

1:05:37Then nobody wants to explore. So I'm trying to have a balance of how do we enable our builders to explore creatively and have fun with it. But then once we get serious about it and we say, OK, these are the tools that we actually care about. I care about Cursor and Windsurf and Cloud Code. And I want to use these models. And some of them are open source and some are not. right that's the place that i want to have more rigor and and really focus down and and have all of our cyber security professionals and our risk professionals to come in and and really uh give it a good uh uh shaking to make sure that our core tenants and our customer privacy and security is really protected yeah i love how you explained it i love that you think about it as a funnel I think that is the right way to think about it.

1:06:26And what I will say to you, Amish, and everyone listening at one point in the funnel, when you let's say that you pick windsurf, cursor, copilot, and you say like, okay, these are the ones that, you know, made it down to the bottom five. there's a lot going on now to measure the impact. So you can do things that say like, okay, how does windsurf affect my cycle time, my PR size, my MTTR, my CFR? I mean, these are the kinds of things that are out there now. We're doing that with customers. So once you make it down there, you can be a little more data-driven. But I think the takeaway for the audience is that funnel idea.

1:07:09Let's make sure we're opening it at the top So there's because I mean, there's like a new tool every day here. Let's make sure that we're getting enough into the funnel. Let's make sure that it's secure. And then let's see what the impact is. I love thinking of it that way. As we come to the end of the conversation here, is there any either anecdote or success story or something that we didn't touch on that I didn't get to ask you about that you wanted to say? I would say this is that, you know, given your audience, focus on the creative problem solving. Oftentimes we get stuck in arguing about, you know, oh, should I use Kafka or Kinesis or should I use, you know, Iceberg or Delta or whatever?

1:08:00Like those conversations are not moving the ball forward. And right now, engineers have the ability to get an Ironman suit put around them with all of these AI tools. If you want to be powerful, if you want to be creative, you want to be impactful, focus on the things that matter to your business, that matter to your stakeholders. And you can still be incredibly creative without debating whether or not you should rebuild S3 or something silly like that. So I would say focus on the creative problem solving because that's where you as an engineer can unlock a tremendous amount of value and impact for your organization.

1:08:40So that would be the best kind of piece of advice or anecdote, I would say. And this is such an amazing time to be an engineer. I didn't have to age myself for a second. It's like, when I was at Microsoft, I was futzing around with make files. And you debug those for hours and hours. And now I don't know that anybody would even be able to relate to that example. You're chuckling, so you've probably done it yourself. But we're so far beyond dealing with the kind of mundane work that get excited about what you can do, the power that you have in your hands. These tools are incredible. You just have to get good at it.

1:09:17And if you focus on the right things, you're going to unlock so much value for your company. And candidly, you're going to be much happier. So that's what I would leave you with. Amish, thank you so much for coming on Dev Interrupted. I mean, your experience. And honestly, sometimes I think, okay, some of these enormous companies can't have cool stuff going on. There is a lot of cool stuff going on at Capital One. I mean, you are on top of it with developer experience. And also, you know, we talked AI. It seems like a really awesome place to work. And I think getting that insight out into the world is really, really important.

1:10:03Where can our audience go to learn more about the work and Capital One's innovations? Great question. Capitalone.com slash tech. We have tons of blog articles, et cetera. And, you know, what I would say is coming from, you know, 20 plus years in big tech, this is my first job in finance and working for a bank. But we are a technology company that's, you know, working in the banking space. Like we have some great, cool innovations coming out. Like we're one of the largest serverless deployments in the world. There's a lot of cool stuff, a lot of fantastic people. And I appreciate you giving me the time to expose your audience to it.

1:10:44Awesome. And we'll be sure to make sure all of those links are in our show notes. To those listening, join us on LinkedIn to continue the conversation. That's it for this week's Dev Interrupted. See you all next time. And Amish, thanks again for coming on the show. Thank you for having me, Dan.