Session Recap: Eating the Elephant: Key Takeaways from Marten vanZwietering at Future Branches Boston 2025

2025, Future Branches Boston, Keynote: Eating the Elephant

Kaitlyn Meade, Event Director, Future Branches: For now, we are gonna be talking about a very interesting subject. It came up at Austin last year, and I was like, you have to talk about this eating the elephant one piece at a time. What do you do when something is so big you don't know where to start? Please welcome to the stage Martin Vince Wheating from PNC Bank.

Give him a round of applause.

Marten vanZwietering, SVP, Sales, Service Strategy, and Modernization, PNC Bank: Thank you. Thank you so much. Can you hear me okay? Okay, let's go. So here we are. That is an elephant. I asked AI to generate an elephant that would look concerned about it being eaten and it didn't really seem like it did the job, but there we go. Alright, what are we gonna cover today?

We're gonna cover problem identification and solutioning. We're gonna go through development pipelines and working iteratively. And we're gonna talk about delivering to customers. And here's me trying to e establish some means of bonafides, by which you might think that I've got some ability to talk to you about these things.

I am Marty Van Sweatering. I have spent my career scaling businesses. I've worked on a few different kind of areas. I spent a lot of time in e-commerce before I moved into fi. Someone earlier asked about accidental bankers. I am an accidental banker. I moved to Buffalo from Vermont. I didn't know anything about Buffalo.

In Buffalo, there is a bank, I won't mention them who are very popular. And so I was like, eh, let's see what we can do here. I have scaled websites from a hundred million to 750 million in about three years. I've implemented content management systems that do things like just in time content and things like that.

And I've also implemented the ability to do an entirely new vertical from a technology perspective. These might feel like disparate kind of things, right? You might be like they have nothing to do with each other. But when I think about these, they really all come to the same thing. They come about problem definition.

They come with solving and building a process to deliver that is repeatable. So a couple of aside, right? This picture, I love it. It looks like there's a fridge in my back garden. But it's actually we're trying to kill the grass and it's gonna be some stone down there. I asked AI to remove the fridge.

It'd also make me a little bit prettier. The first version they did, they actually just completely airbrushed me. So I almost looked like I wasn't there. And then I was like, can you try again? And it replaced me with someone else. So I think I've gotta take something from this that not even AI can help me.

One more thing. I have transitioned into a business role from technology, so I can bore you in two different manners now. Okay, so large transformation feels impossible. And I would make the claim that it's not because we lack talent, it's because we do not know where to begin on that thing, right?

It's a you're trying to replace a core. You're trying to make a monumental change, like a 360 degree view of customer data. Where do we begin? So we start by identifying a problem or opportunity, and we say to ourselves, how do I wish to change? All right, data is important if we do not figure out a way to measure what is there right now.

How are we gonna possibly say when we've been successful at the end of it? So my first thing that I ask is how do I measure this thing? And then the next thing I say is, how do I use this data? I. I might be looking to compare to peers and I'll use resources for that. Generally when I'm looking at replacing a product, one of the first things I'll do is I'll go to, say, a Gartner magic quadrant or a Forester wave, and I'll get a viewpoint of what is considered good in that area.

But that's like the first step. Then you start looking at reports of metrics that I might consider valuable in this area. What does good look like? And I will figure out a way to be able to measure what I have against that thing, or as near as damn if we're talking about like a legacy system, quite often one of the big problems you've got is you don't have good metrics.

You've got to figure out some way of being able to know what success looks like for you. And then now we've got our broad viewpoint of what the area is. What is the solution to meet the need? And I'm gonna say a. I'm gonna say a thing there. You want the minimum viable product, and I mean that in a few different ways.

You want to iterate, but you also want the ability to be able to know what is good for you, right? We don't overtly talk about Salesforce here, right? We've, I've heard it mentioned a few times. It's great content management system. It is what we would cons consider a pass, a platform as a service.

Show of hands. Who here does not know the difference between a SaaS and a pass? Does anyone know? Does everyone know the difference between software as a service and platform as a service? Everyone feeling good? All right. I will go for a software as a service if I am not looking to make a platform that I can build into, right?

There are content management systems out there that are a software as a service. Delivering in Salesforce is incredibly powerful, right? I can build whatever I want to build into it, but it also comes with a ton of overhead. Just delivering in a Salesforce environment is gonna cost you teams. It's gonna cost you like the ability to maybe make a whole new way of working.

I'm gonna add one extra thing in on this slide before I move on, right? I've got a story for you. I once worked at an organization that had six content management systems. That might seem like a lot. It is a lot, right? But I worked at another organization. The had built their own CMS, and so I go in and they're like, it's so successful and it's free.

I'm like, wow, that sounds like a great claim. And I very quickly find that they're being killed by just being able to make a basic functionality, right? So they want to show up really basic stuff like an FAQ that will expand into a list on their website. Stuff that you would get for free in any content management system worth a damp.

And I'm like, oh, that's a bit of a smell. And. We go on this particular company made about $220 million a year from their web properties, right? And they made about 40% of that yearly money, or about $88 million, let's say, between Black Friday. And Christmas and we're getting closer to Black Friday and people start saying these worrying things, right?

Like they start saying, about like how the site's going gonna go down. And so I start doing load testing and I find out that content management system is crushed every Black Friday, right? And their site would go down on their most popular day of the year. That's not free. How? What reality is that free?

This site is costing you like this product that you've made yourself is costing you $5 million probably on Black Friday alone. Know what to measure. Know the costs are not upfront. Costy costs are. What it costs you opportunity or your ability to scale. These are all costs and they're really hard to measure, but if you can measure them, they're very valuable to know about.

Okay, so I'm making a quick claim on build versus buy here, right? These are the things I would think about in build versus buy building costs versus licensing, obviously, right? Like how many teams is it gonna take to build something yourself versus what's the licensing per year? When we start going past that into the complexity.

How large of a system are we talking about? If you're gonna be building it yourself, are you gonna have to build a new way of working framework? If this is large enough that you have to have four teams working on it, now you have to start looking at agile release trains. Not a bad thing to have to be able to do, but that requires a whole new way of working for you, right? Are you at the point in your journey where you really want to be doing that? It's worth checking into that complexity, right? The speed I mentioned earlier, SaaS versus PLA Pass, right? SaaS you can deploy way sooner probably because you're doing configuration based changes to that platform.

Not making components yourself and having to figure out how to deliver. They deliver their upgrades for you. Scaling does this have the potential to what work cross? Vertically. I mentioned before I worked for an organization that had six content management systems, right? Think about the risk in fungibility alone.

My programmers need to be able to talk in like different languages to be able to do essentially the same thing. How wacky is that? My fun fungibility alone is miserable for that. So like when I start looking at that, right? I want to be able to scale any product that I do, ideally cross vertical.

I know we love verticals in banking. It's our favorite, but if you can figure out how to use an enterprise system in a way that will actually work for multiple verticals, you've created a huge win. You've created fungibility of your development crews, you've created the ability to be able to release together.

It's great. But of course then you have the reverse is true, right? What's the old saying? If it's white, make it black. If it's black, make it white. Now you've got this thing. Oh, it's enterprise, let's federate it. You've gotta think about that. And then the upkeep, right? Not just the new development but the infrastructure, patchy, cloud, licensing and security, right?

Like all these things have cost. Anytime I can buy, I do buy because of that. Right? One thing I'll say about speed quickly before I leave this slide challenge your uniqueness, right? If you are saying we need to be able to build this because of this one thing to do with that process, is that really unique to you or have you just not challenged the way you do things?

Several organizations I've worked in have used the phrase, we're not a special snowflake. That's a pretty powerful thing to do. Like people have been saying all day, we all essentially do the same thing, right? More or less with our own things. I would challenge if you really do need to make something way more complex for some piece of your process, be prepared to be adaptable.

All right, so I make this claim quite a lot, right? Good systems are not built, they are composed. Very few parts of our world work entirely in a vacuum. Integrations for data or between user experiences are common and necessary. So even if you're building, you. Bringing in a SAS or a pass, you wanna make these building blocks work together.

Selecting vendors should be at least in part, based on how well they work with the rest of the things that you have in your institution. If they don't, you're gonna spend a ton of money that you don't need. You might really. Realistically wanna go for someone who initially you liked less just because they work better with what you've got.

There's nothing wrong with that, right? Moving to new platforms is a thing, but also be aware of the moment. Where are we right now, kind of thing. All right let's go on. When deciding on SaaS versus pass, think about how customize your complete solution needs to be. I'll often go one way or the other based upon how complex I need this to be, right?

I will choose a SaaS over a pass because for me, the only thing I need to deliver is something that's configurable. I want this product to be this product. I don't wanna build in it. And I've literally had things for things like, incentive management where I chose the solution that was a SaaS over the pass, even though the pass could do more, because that wasn't where we needed, we weren't unique in this, we just needed to provide incentives.

And I'll say one more thing here about uniqueness, we make uniqueness about a process, right? And yet, last night, just for giggle shits, I Googled three of the biggest banks. And I swear to you the websites looked like they'd been created in the early two thousands, right? Where. Is the experience, like we've talked so much about experience in this conference.

Where is the experience to my customer? If you are talking about something that's unique to you and you think your experience is a valuable one, showcase that make a good digital asset management system that integrates well with your properties. Have a way of being able to inside dams, you'll often get a branding portion of your dam.

Have a consistent place where you can easily give assets that are approved by your organization out to others. We want to sponsor an event. Go here. You can download whatever you like. You can use it on your materials. It all scales, or you can scale it inside the thing, whatever else. Be unique, but be unique in a sensible way.

What really drives an experience for your customers. Think about that when you're delivering. Don't make the 2005 website. It's a bloody embarrassment of those three. Only one of them had a graphic on the front page that I would consider worth the damn right. Just the others are just like box.

Yeah. It scales down and stuff, but it's blah, I, it wouldn't encourage me to go there. I just ejected instantly. All right. Meaningful change happens in incrementally, right? So this is my second thing, delivering an iteration. Trying to solve everything at once is a fallacy. You have to decide what's your highest priority, and you have to work with that, right?

Vague ownership and accountability a huge problem, right? Like you have to determine who owns every piece of a solution, right? If you've got something as complex as a content management system. What? Who owns a particular piece of that, right? Who owns the entity page? Who owns a dashboard who can make a final decision?

Your product owners are not your owners, or they shouldn't be. They're the people who determine priority. They're the ones who take the various stakeholders and they say this first, the second. They're not the people who should be in charge of what gets to go on that page. Make your business stakeholders known and accountable.

Analysis paralysis, and I said rebooting here as well. I don't know if this will resonate with any of you, but I've had lots of projects where someone has entered the fray. And the whole project has got rebooted, right? Don't allow that for you have meaningful data that you're building upon, and then when someone new enters.

Don't let them be someone who reboots your entire process, even if they're pretty high up. These are the tenets we made for this thing and we're moving forward to towards that. And then burnout from unclear progress. Anything you're looking to do you want to be able to mark on it and you wanna be able to show when you are winning.

So I'm gonna say a thing, right? What is the biggest advantage of Agile versus waterfall? For me, it's incrementalism. It is the ability to. By me saying that I can deliver this and this and this. And then I can see as the various pieces are going, what epics are we working on this quarter?

What are we working on this print? How are we delivering? That's the real power of agile. It's not that it solves everything in our world, but really unclear progress is a. Damning thing, and if you don't have a good viewpoint in that and good dashboarding for when you're delivering, it's going to make your whole project in jeopardy.

Okay. Effective delivery techniques, if being able to deliver iteratively is key to the process, then be wary of long times. To be able to deliver to production if it takes you a long time to get code out there, or worse still, you have several code releases in the same platform going on at various stages because of governance or whatever else.

Ah, that is killing you because I'm delivering a thing. It's in this thing, it's going through testing, and now it's in production. But meanwhile, oh, we want to change a thing about it. You can't be in this release 'cause this release is already being developed. You can't be in this release. Oh, you can't be in this one.

'cause it's being developed. This one's in testing. Your four releases out, you're now doing four releases a year. The advantage of being able to work iteratively is you should be able to release at least every month, challenge your organization to be able to release regularly. I want to be able to also say, tracking the velocity and the burn up.

All work should be easily visible and attributable. I've got one note on this slide. It says, this looks like a manifesto. So it's incredibly dense. It's not a complete list of all the things that I would worry about, but all of these are smells that I've encountered, dev deployments that include manual steps.

Right now I've got an accountability problem. Deployment should be continuous integration to lower environments. That means that when someone checks in code boop, it goes into the lower environments and people can immediately be testing it, push button to production. No manual steps, no bueno. All models are not created equal.

Rely on technology partners to steer, but in general, things like Bluegreen and hot. Are great plans for how you do it. Bluegreen being, I bring down half the servers, containers, whatever in production I deploy to that. I test it, I flip. Now those ones are in production. I update the other ones and I boom them up.

If I have some problem when the first set are in production, I don't boom these up and I can roll back and just flip back out. Hot, multiple server farms at the same time? Oh, I think I'm over already. Okay. So I'm gonna move a little bit faster. Okay. Feel free to look in look through these and message me about any of them that you want or anything else.

But I will say full aggression tests and overly cumbersome governance processes. These are things that can be solved for, don't allow them to be the status quo. Be someone who works on these difficult things so that you can release in a repeatable way. And I'm gonna say identify stakeholders and decision makers.

One bite at a time. Determine manageable deliveries. Make a deliverable delivery pipeline that can be successful. Build trust through consistency. Most of what we do isn't about being a rockstar. It's about showing up again and again, and that is how you deliver good things to your customers. Your customers being employees, quite often, and I'm just gonna flip past demos and measurements, but it is very important.

I will quickly say focus groups doesn't have to be an expensive thing. I've done focus groups in little things with one way mirrors and all that kind of shit. A focus group can be your mom, right? It doesn't matter who your focus group is, just get it in front of people. Be testing, be demoing and measure everything you do.

Paint the full picture. I've already said that. Remove blockers, build rituals around visibility. Don't just track process, narrate it. Final thoughts. Transformation is messy. The solution is pro is proper deconstruction, not brute force. Anchor to outcomes. Sequence for trust and speed. Automate governance instead of stalling with it and celebrate visible progress.

And by doing so, we create a culture that isn't afraid of the next elephant. We've already learned how to eat one, and we can just continue that process again and again. And we don't have time for q and a. So if you wanna reach out to me on LinkedIn, feel free to do thank you so much for your time.

Kaitlyn Meade, Event Director, Future Branches: Thank you so much, Martin. I appreciate it. No, it's appreciated and I encourage people to reach out either here or on LinkedIn to get more information. And if you have questions about the slides.