Managing a cloud migration is challenging enough in the best of times, let alone moving the newly merged operations of two financial institutions in the middle of a pandemic. That’s what Truist faced when it was formed through the merger of BB&T and SunTrust Bank to become the seventh-largest bank in the United States. This merged bank faced a considerable challenge in migrating both systems to the cloud. Truist tackled it by employing agile, blending teams from both banks, upskilling its technical talent, and acting like a software engineering shop. Ken Meyer, Truist’s chief information and experience officer, discusses his company’s cloud migration with McKinsey partners James Kaplan and Merrick Olives. What follows are edited highlights from that conversation.
And then there were two
James Kaplan: Tell us about Truist’s cloud journey. How did you get started, and what drove the process?
Ken Meyer: Our journey started back in 2016 [while I was at SunTrust]. We were looking to modernize our experiences and technology, things like speed, security, and reliability. We started looking at our digital channels first, because they were the most client-facing interactions, which made them a great place to start. So we moved our first application, which was great and provided a lot of learnings along the way.
After that, we announced the merger [between BB&T and SunTrust Bank] and built native applications as part of that process. Since then, we’ve really come a long way and now have more than 250 cloud service provider (CSP) accounts, multicloud strategies, and relationships with other partners.
Steadily ramping up migration speed
James Kaplan: How much of your environment is currently in the cloud?
Ken Meyer: It’s hard to say exactly what the percentage is, but we’re starting to migrate more of the channel experiences across the board. We’ve always had a large software-as-a-service (SaaS) footprint and are now looking to leverage cloud to modernize the full stack.
In the early days, we had immediate thoughts to go straight to serverless. But we had to pivot, and we moved away from some of the serverless work because we needed to get more experience and get our sea legs under us a little. Since then, a lot of the stuff that we deploy now is serverless right out of the gate, and we’ve got a mix of different components and different pieces and parts. We’ve learned.
Like any large organization, we have teams that are at different levels of maturation. And it’s not just cloud. It’s how we work. We talk about a Truist triad approach to agile because of how we work between product, design, and engineering. As you get better in all of those areas, everything goes faster. And when you take the power of the cloud and use automation and pipelines to improve not only speed but quality as well, you have better learnings and happier teammates, so it’s really valuable.
As we leverage our current stack with our pipelines every year, we continue to go faster. By June 2022, we probably deployed more features to market in six months than in the entire previous year.
Overcoming resistance and a lack of understanding
James Kaplan: Going back to 2016, how much resistance was there to migrating to cloud, and what did it take to get beyond it?
Ken Meyer: Looking back, I felt a tremendous amount of resistance, but I don’t know now that it was actually resistance. I think it was just a lack of understanding. There were a lot of folks eager to learn who wanted to be part of the journey, and we wanted to make sure this wasn’t something we were doing just for technology’s sake. That became really apparent with the executive leadership, because once I helped educate those individuals and got buy-in, that cleared a path for things to happen.
I think those who embraced and learned cloud have gone on to enjoy a lot of success. People just needed to learn more about what was out there. But you can underestimate how much resistance you encounter even among the application-development community. But if you make it safe for your teammates to learn and fail and to do all the things that come with this journey, then they’re going to embrace it, and they’re going to feel somewhat liberated from the technical debt they might have been saddled with before.
For others, though, it feels like a threat to their very existence. We wanted to make sure people didn’t feel threatened by the infusion of modernization, and many of them embraced it. There are a lot of people who learned a lot of things and are much better informed now about cloud than they were before.
Navigating uncharted territory
James Kaplan: When it comes to migrations, it’s said that a third of the people will run there, a third of the people can be brought there, and a third of the people are really going to struggle. Did you see a similar proportion?
Ken Meyer: I don’t know, because we were really in uncharted territory during our journey. If I think about the timing, we started the journey in 2016, started putting stuff in production in 2017, and in early 2019 announced the largest bank merger in the past 20 years. And then as you start getting excited about this merger journey, the whole world suddenly shuts down during a global pandemic. So you’re forced to send all these people home that you really haven’t had a chance to develop a culture and relationship with.
At the same time, you’re also tackling a merger of equals, which creates a whole new level of complexity, because you’re not just taking one set of systems and moving it to another. Introducing new, native cloud experiences to our clients in the middle of all that was really unprecedented.
Cloud Value Radio
Building skills and engaging developers
James Kaplan: You’ve taken a large team through this journey over the past five years, but you started with a very small team. How did you upskill that team, and what’s happened to them culturally and capability-wise over that time period?
Ken Meyer: Back in 2016, we had some really talented teammates but were very dependent on third parties when it came to our application-development skills. At the end of the day, we knew we needed to be less dependent on others, so we made a conscious effort to start bringing some more of that talent in-house.
We needed to start thinking about becoming a software engineering shop, which is a different mentality than being an integrator of commercial-off-the-shelf (COTS) software applications. So we started educating and training existing teammates and hired some really talented people. In some cases, some of those people worked out phenomenally, but in others, they weren’t the right fit.
The merger also created a unique opportunity for us. I remember my first trip to Raleigh, North Carolina, to meet our new development folks at BB&T. I’m standing in front of all these people I’d never met, talking about how we were moving to the cloud. I’m sure many of them looked at me like I was out of my mind, but they embraced it from day one.
I didn’t create separate BB&T or SunTrust teams; I mixed them together from day one, and we’ve worked on programs to keep people engaged and excited. For example, we’re hosting our first internal developer conference in a couple of weeks, where we’ll have our teammates and partners doing sessions.
When we think about innovation, we know it’s not just going to happen only within Truist. So we also announced an innovators and residents program with partners to bring new people in to create excitement and curiosity among our teammates. When you do that, people say, “Wow, these folks are actually paying attention to what’s going on in the world and are not just worried about their next product.”
The economics of cloud usage
Merrick Olives: You’ve gone through a multiyear change by shifting a large portion of the workload to the cloud. Are you seeing a different economic structure for your IT organization as a result?
Ken Meyer: Yes. You get the benefit of the paying-for-what-you-use concept, but there are some lessons to be learned, because if it’s not done properly, it’s not always cheaper. You have to understand what you’re doing and put the proper controls in place. You also need the right people monitoring usage and keeping their eye on the cloud economics, or that cost curve can get very interesting very quickly.
You also have to think about different use cases. Do you need burst computing? Is this something that’s going to be needed every day? Maybe you only need to run a particular application from 6:00 am to midnight and then shut it down every night. And you might want to increase certain run rates. So what is the opportunity cost of doing things differently?
I think a lot of companies, and we’re no different, struggle with understanding the total ownership cost of legacy technology, because it’s easy to say, “This application’s been here for 30 years, and it’s already amortized and paid for, so it’s free.” But it’s not free. You’re paying for storage, you’re paying for compute, you’re paying for power, and you’re paying for maintenance. So you’ve got to take a more holistic view to decide where you want to be versus where you came from.
The challenge of grooming product managers
James Kaplan: When we see people adopt agile, we hear again and again about the challenges of building that product-manager skill set and getting the business to pony up folks with sufficient authority and knowledge to play that role effectively. How do you work through that?
Ken Meyer: For us, the biggest challenge historically has been moving from a financial-product world to a product-management world. A person who knows everything about deposit accounts, credit cards, or loans may have a great understanding of the intricacies and requirements of a particular product. That doesn’t mean that person’s always the best product manager or product owner when it comes to working with an agile scrum team and delivering that product to market or grooming a backlog or setting priorities. It’s an evolution.
We’ve seen some of those people embrace it, have tremendous career pivots, and become fantastic project managers. But like anything else, you’ve got to be a student of the game, you’ve got to learn, and you’ve got to be open to learning. Those who have embraced that opportunity have done really well. But we’ve also had to hire, because you also have to bring examples into the organization for others to learn from. It’s also important to understand diversity of thought and culture.
A Herculean use case
James Kaplan: If you look back over the past few years, what’s the single highest-value use case you’ve implemented on cloud?
Ken Meyer: Oh, that’s easy. We were saddled with a merger of equals in the middle of a pandemic, and I told my leadership team we were going to build brand-new online and mobile banking capabilities. Then I convinced them that this big conversion should include the deployment of a new user experience by dropping releases along the way to add capabilities—and that we wanted to deploy it to production before doing our back-end system conversions.
Even I, at times, had my doubts we could get it all done. But I have some tremendous teammates and leaders on my team who found a way to ultimately deliver. We essentially launched a single client-facing, mobile, and online banking application suite on top of two legacy back-end banks—which comes back to what I said earlier about becoming a software company. We were running core systems out of multiple data centers and ultimately completed two major bank conversions, one from BB&T to Truist’s target state and then SunTrust to Truist’s target state.
Clients didn’t know any of this was happening in the background, because they’d already been onboarded to the new platform. Even during the second migration—which was the larger and more complex of the two because of some of the core systems—we managed to deploy it over a single weekend.
We kept our digital channels up through the actual core conversion the entire three-day weekend by creating data storage in the cloud instead of shutting everything down. So that was a phenomenal accomplishment from our team, and I couldn’t be prouder.
