Be Nimble, Be Quick

Mitch Woods: Hello everyone and welcome to another episode of Lending Made Easy. I'm joined by our FinTech guru, David Catalano and our ever tech savvy, Brian Peckinpaugh and today we're gonna talk about the benefits of smaller financial institutions investing in technology. So in a world where we're constantly seeing technology advancements, Do smaller banks and credit unions have the advantage of agility and, and can they be more, more responsive to, to changes than a larger institution?

So there's this unique opportunity for a smaller community bank or, or a credit union to level the playing field and even get ahead of a bigger bank, just because they're a little bit more agile, right? So, really the question could be, could technology be the ultimate game changer for a smaller, community bank or, or a credit union?

So David, could you start us off just by sharing your insights? So what's the unique advantage that a smaller bank or a credit union might have when they're implementing a new technology, like a loan origination system? Is being nimble or agile really a significant advantage?

David Catalano: Yeah, I think it is because then they can, they, they have fewer people that need to take advantage of this new technology, so I, I think it's gonna be easier for a smaller group, especially if they've got strong leadership to adopt a new process.when I think about a small institution like what you're describing, I think about commercial lending. And the reason why is the majority of these community banks, smaller banks are commercial lenders. so they typically have a relationship manager that will go onto the community and build a relationship and that that in itself is a phenomenal thing because that's a personal relationship they have with their borrowers.

Typically, these borrowers are substantial to the bank, meaning their, contribution to their revenues and, and, and their profits are, substantial. I see that as a tremendous edge for community banking. But then when you add in the technology side of that, so you can assist that relationship manager in, in delivering on the promises that they're going to make in a timely manner, in a very specific prescribed way, I think that can be an edge. I don't doubt that at all. technology can provide consistency to a process, predictability to a process, eliminate asking for the same thing twice. eliminate entering the same information 10 times. Simply by reusing the same information using a digital workflow. Everyone knows where everything is. That makes a, a commercial customer's experience with the bank improve. Now a great, really, as Bryan says, a great relationship manager, can hide a lot of sins. But if the bank is using technology in a digital platform, they don't need to. Right? And you can be more predictable. and when you tell your customer, I need these four things, I need these thi six things, you can rest in, in the comfort of knowing that's what you need, because you've got this system that tells you what you need.

It tells you what you have, it tells you where you are in the process. So the communication's improved. And if you've got fewer people that you have to get on board with this technology, with this solution, and everybody's excited about it or, most people are excited about it. The people that didn't invent the idea are now less excited, the people that are owning the idea. but, but there's just fewer, fewer to get involved. I, I think you could get greater adoption with a smaller team. You're just more efficient, you're more nimble.

Bryan Peckinpaugh: And I wanna David, hone in on, on something you said there at the end, the, the difference between those who own the idea and those who execute on the idea.

David Catalano: Mm-hmm.

Bryan Peckinpaugh: Because I, I think that's a, a key component of smaller organizations, maybe appearing more agile, appearing more nimble. there's something to be said for how close those owning the idea are to those executing the idea.

David Catalano: Ah,

Bryan Peckinpaugh: Right. The, the larger the organization typically, the further apart those two constituencies are, if I think about a smaller organization, and I'm gonna take it back before they start implementing to, as they are evaluating. You are more likely to have representation from the executors in that process because they are one and the same as the owners of the vision, at those smaller institutions where, the president of the bank might also be an underwriter.

Right. Which we, we don't, we, it's not rare to see in a, a smaller community bank. so those owners and those executors can be, at times the same people. So they're gonna appear more agile because they're bought in from the evaluation process. Right? we talk about it a lot where the biggest killer of technology projects is the lack of change management. But if those who evaluated the software agreed to, yes, we're gonna go with this platform for these reasons, are also part of the team delivering it, they're going to enforce the change management and make sure that it happens 'cause they know it's necessary to deliver on, on their vision.

So I think that's probably a big difference in large versus small. the other piece that I, I think plays into it is, the sizes of those teams. As you mentioned, David, I mean there, there's lots of studies out there on optimal sizes of teams. One of the just inherent things with that is bigger is not always better. There's a reason, there's a saying, too many cooks in the kitchen, and by nature, and this won't happen every time, but those smaller institutions are gonna have smaller teams doing the evaluations, running the projects, et cetera then are gonna tend to be more effective just because they're not having to get sign off from 30 different people, they're trying to get sign off from seven. Right. That's, that's gonna be easier, faster, generally speaking, a simpler process to get everybody on board and everybody signed off. Not always the case, but, but generally speaking, then there's another, another piece of this David, I'd love to talk about, which is, just the consumption of technology by smaller institutions in general, because I, I, I don't think anybody would argue that,The world of, financial services has moved into a tech forward arena. We, we have to be, competitive from a technology perspective. I can't be a billion dollar commercial bank and not have online banking. Other, if I don't, they're gonna go to one of my larger competitors who offer that. So there's, there's table stakes from a technology perspective that, that you have to have.

But my ability to build my own technology, use custom technology, even highly configurable technology can be difficult if I'm a smaller institution. So I think there, there's an imperative there for the smaller institutions to focus not on broad capabilities, right out of the box. You wanna be able to service broad needs but I need to focus on consumability, knowing that again, I have much smaller teams, I have people doing multiple jobs. I need to find things that I can get up and running quickly that I can iterate on to get where I want to go and not try to eat the elephant in one bite. so I think there's, there's a portion of this that is on us as software providers to understand that and understand that need and the difference between a large and a small institution, and making sure that what I deliver to the market is actually consumable, not just feature rich.

David Catalano: I think that's a really good point. Consumable, consumability. They don't need to have everything all at once. They can consume it, smaller bites, digest those bites, and then buy a bite, another piece. Yeah, I, I agree with what you're saying there for sure. Smaller institution, really any institution needs to rightsize those projects. You know and we've seen smaller institutions take on far too many projects and they wake up in two years and they're still working on a component to it. Versus intentionally going in, getting one component up and running into what we call production, going live and then adding another component later.

It makes a heck of a lot more sense, especially if they, after they use the first portions of it, and successfully, and then can optimize that by adding additional functionality or configuration. I agree with what you're saying. 

Also, the, your insights into the idea that the people doing the work are very close to the people deciding on what technology platforms they're going to get, and then the opposite in a larger organization. And we've seen it go the wrong way in larger organizations where, You'll get a C-level, typically a Chief Operations Officer picking the whole solution. from, from his perspective or her perspective they're knocking out lots of other vendors and going with a single vendor to do lots of things. But that one vendor's not always doing everything that, credit would like or Relationship managers would like. So there's always some level of compromise where at the smaller institution you tend to get more people evaluating the solution. and the people that are evaluating it have input and inform that process and can help make that selection criteria and, and own it, or feel like they have a more of an ownership, in the acquisition of that technology.

I think it would be interesting for us to look back on our client base and, and look at, who's consuming most of the product by size. and, and just see who's, who gets better, who gets better utilization, and who, who, who has a better outcome? Is it the smaller FI or the bigger FI? That'd be interesting to see.

Bryan Peckinpaugh: That would be, I, I, it would be a, a very interesting data point. what I kind of at, at the tail end here, kind of come back to that idea of nimble, agile, because I, I would, I would, certainly back the idea that the smaller institution is more nimble and more agile than the larger. Smaller, tends to move faster than large.

Again, another example, there's a reason that they talk about how, fast it. A large cruise ship turns right. They, they, they don't, they don't have very good turning radiuses. But agile and nimble are not in and of themselves An asset or, or valuable because I have to apply them in the right way. Just because I'm agile and nimble does not mean I'm better. I'll use an example of,if you're, if you're gonna try to get into a, a weightlifting program, right? So let's say you, you, you, you've sat around and you've done nothing for, for your life, and you wanna get into weightlifting or running or something like that.

I could be agile and nimble and focus on what the Mr. Olympia's do for their weight training, they all train differently so I can try all of theirs and just keep, trying, failing, trying, failing. Same thing with, running. I could try what the Olympic marathoners do in their daily training and try and fail and try and fail, and I will just continue to fail. I need to follow a couch to 5K kind of idea if I'm gonna start running, I need to start with low weights and just move my body if I'm gonna get into weightlifting. if I try to focus on the end goal and just iterate on those, I can do it very quickly. I can do it very agile. But I'm never gonna get where I want to get.

I need to make sure I create a very deliberate approach. we talk about a digital adoption curve for loan origination here at Baker Hill. If I'm only doing paper and pencil, if I'm at the bottom of that curve, Trying to go all the way to the top where everything's fully automated I've got integrated docs and boarding and e-signature and I'm boiling the ocean 'cause I wanna be like the top five bank that's, that's down the street from me.

It, it doesn't matter what vendor I pick, I'm gonna fail. I, I'm trying to go too far, too fast. I need to work my way in a deliberate manner up that path. I've gotta engage with the solution providers out there and find one who can help me. Now, how do I take incremental steps forward? How do I get better? How do I leverage that agile and nimble, ability of my small institution? To chunk my way up the curve. Not iterate and fail at the top end of it. So make sure you, you partner with a software provider, you find someone who has time and in this space who has done this before, who has walked a, an organization from a billion dollar community bank to a, $20, $30, $40 billion regional player. by helping them bring technology to bear as they grow and as they're ready to consume it, and that can help you with that journey, can tell you the right way to do it. so again, that you don't waste that nimbleness by trying things over and over that they're never gonna work.

Mitch Woods: Yeah, it sounds like it's really understanding what do I really need and then being able to, to apply that right, and, and understanding what's that next step. Finding the partner that's gonna help guide you along the way. I think, Bryan, you brought up a really good point there as we kind of wrap up this episode, that it's all about being deliberate and, and having a plan, but then also having a partner that's gonna help you along the way as well.

Think about your, think about your training program, right? Most people are, aren't just gonna come up with something on their own and be successful. They're gonna follow a couch to 5K, they're gonna follow a, a trainer online, or they're gonna find a trainer locally that that's gonna work with them and have a plan as well. So I think it's a great analogy to think about how a bank or a credit union could, take on projects, especially with a larger technology provider, like a loan origination system, and, and, finding someone that has a good plan for them to help them make the progress and, and see that continuous improvement along the way.

So Bryan, David, thanks so much for your insights today and, and thanks everyone out there for listening to today's episode of Lending Made Easy.