Blog: Continuous learning at Capital One

Melanie Frank, Capital One's Managing Vice President of Cyber Engineering, has spent twenty-two years learning and adapting to the ever-changing environment of the fintech world. In that time, she's developed a leadership style that is driven by continuous investment in her employees and creating a culture where continuous learning and testing is encouraged. 

Perhaps more than any other segment of the tech world, cybersecurity is a space that requires constant vigilance and constant innovation. The threats don’t come in a simplified timeline nor do they care about things like end of quarter goals. With that in mind, Melanie has helped instill the idea that her teams need to focus on continuous improvement as opposed to charging towards a single goal and then moving on. It’s made Capital One agile and flexible.

Recently, Melanie joined our Perspectives in Leadership podcast to discuss the culture she’s helped build, talent retention and talent mobility, the test, build, learn model and much more. What follows is a snippet of that discussion.

*Answers have edited for clarity and length*

One of the stats that really stuck out to me from our 2022 State of Upskilling report was those who’d been in the technology industry the longest and had the most experience were least confident they were going to be able to do their jobs in three years. You’ve been with CapitalOne for 22 years, so I have to ask: how confident are you that your job will look the same or similar in three years?

I’m 100% confident it will be different. What I’m doing now is very different from what I was doing three years ago… and the three years before that… and the three years before that. Sometimes, that little voice inside me is like “but you don’t know anything about X, Y, or Z.” My response is always I didn’t know a whole lot about the things I’m doing now three years ago. 

That’s what engineering school taught me; it taught me to think and solve problems. My experience showed me you just figure it out. And I think that’s what we all like about our jobs right now. There’s this ability to learn and unravel problems that carries over from job to job. It’s the particular problem you’re solving that changes day-to-day.

We've seen it costs 250% of a person's salary to replace them, but an average of $1,200 to upskill existing employees. When building an environment that attracts and retains top talent, what is your team doing or highlighting about your developer experience to retain your current team and recruit new talent?

We’ve really focused on removing friction with automation where possible. When we build automated solutions into our development pipelines, it’s much easier for us to do our jobs consistently and safely. For example, we implemented security scanning tools built into the software pipelines so our engineers don’t inadvertently introduce a vulnerability and then waste time going back to fix it. It’s difficult to introduce that sort of automation when everyone is working in their own unique pipelines, though. So one of our other priorities is converging everyone into one pipeline that we all contribute to and innovate on. That allows us to add more automation and more consistency to our development process. 

There’s a tremendous investment in knowledge, upscaling, and rescaling to move from team to team, so we’re also making the time to train our people.  Each of our engineering teams requires a different set of skills or certifications to qualify for that position, and we want our people to have the freedom to take the time to invest in themselves. There’s so much out there, it seems finding the time is the hardest part, so it has to be one of my priorities to make the time.

Software developers are constantly innovating, but you still have to report return on investment to a board or other stakeholders. How should an organization or a team shift that mindset from OKR-driven goal achievement to continuous advancement and continuous improvement?

If an OKR framework is done right, it tells me what matters most and signals to me how long it should matter. It helps me understand the why so I know I’ve actually achieved the end result or something else now matters more. So I think this type of thinking, when you start, is okay. Ideally, you’d then start measuring as you go, creating a cycle to say we did this, this was the change that came from it, what did we learn, and what are we going to do next. This sort of build, test, learn model works so well, whether you’re focusing on a software product or a team because it focuses on the learning part so you can adjust where you need to adjust in the moment. You may find your original hypothesis was wrong, you need to change what you’re doing, you need to change how you’re doing it or you were wrong on the why.

I think in some cases, whether it’s in product development or continuous investment in yourself, we can all get so focused on the next thing and then the next that we need to carve out time to do the learning piece. For our teams, we started once a month “Invest in Yourself” days because we knew if we weren’t intentional and purposeful, it wouldn’t happen. So we carved out this time for them to do what they wanted and needed to do for themselves, but just to take that step back.

You’ve talked about your build, test, learn model for writing code and building products. But you also mentioned using it with your teams. Can you expand on what it looks like to hypothesize, test and adapt from a team perspective?

I like the classic agile methodology with retrospectives. It’s funny how much of the retrospective ends up being about how we work together, how we worked with other people and how we want to do that differently going forward. I really love when our individual agile teams preserve the ceremony of a retrospective and take the time to ask what worked well, what didn’t and what are we going to purposefully plan to do differently in the next cycle? Otherwise, we can get so focused on backlog items, it’ll be two months from now and we realize we never did the retrospective and maybe we should try it this way. 

I think this is also important at the organizational level. I’ve had organizations deliver me something called the Backlog of Pain, but just having some way for the systemic things to bubble up and become a backlog for leadership. But there has to be a sense of purposefulness to it. We’re adaptive creatures and so these changes will happen naturally over time, but I like when we recognize it.

There have been some things, particularly work from home, that we talked about as offices reopen and we move back to hybrid. We realized we work more effectively in a highly distributed way. We want to make sure we’re intentional about what we learned, what we want to keep from that and how we should adapt as we make this transition. We established this crazy normal and we’re about to move into this new normal. So being intentional around watching the changes is going to be an interesting thing.