Buying vs. Building Technology [Podcast]

When it comes to the decision of buying or building technology, there is no “one size fits all” solution. In this episode, Dallas Wells and Maria Abbe discuss when you should consider building technology and when you should buy instead.

Maria Abbe: Hi, and welcome to the Purposeful Banker podcast, the podcast brought to you by PrecisionLender, where we discuss the big topics on the minds of today’s best bankers. I’m your host, Maria Abbe, Content Manager at PrecisionLender, and today I’m joined by Dallas Wells. He’s our EVP of Banking Strategies. Thanks for joining us. Today we’re talking about a question that’s been vexing bankers for years: Should you build or buy the technology that you need? Dallas, to get us started, why is this question top of mind right now?

Dallas Wells: I think anecdotally for us, we’ve had this conversation with a couple of prospects recently, so it’s got us thinking about it. I think in general for the industry, the simple answer is that people have their budgets back. The industry spent a long time recovering from the ugliness of the financial crisis, and then for years after that, just dealing with the onset of all the new regulations and all the changes that they had to consume, so banks were very internally focused in cleaning up processes and frankly, trying to clean up some of their financial mess too.

Much of that stuff’s in the rear view mirror now, so they’re back to thinking about growing the business and improving the customer experience, and with that comes the need for some new technology and some of the budgets start thinking about how they do that. I think a lot of banks are finally coming back to the table and saying, “Okay, we’re ready to change things. We have the resources allocated for it. Now how do we actually go about doing this? What are we going to do differently or the same than we did last time, based on what we’ve learned?”

Maria Abbe: I see, so during that time, in the thick of the financial crisis, how did banks handle that question?

Dallas Wells: I think this question is always … To me, it’s closely related to the forever question that banks have had, which is do we handle things in-house or do we outsource and find some outside expertise? I think the technology decision goes hand-in-hand with that, and it seems to swing like a pendulum, where the industry and even individual banks will swing back and forth between we’re going to do everything in-house, we’re going to build all our own solutions.

Then they figure out that that’s hard and messy and then they swing back the other way and they say okay, we’re just going to stick to our core competency, so we’re going to outsource everything that’s not just core banking, and we’re going to hire vendors to build all the tech for that. Then they figure out that they’re losing some control in that aspect, so it swings back the other way, so it tends to go back and forth.

I think through the crisis and immediately after, I think banks just out of necessity became very internally focused. They were working on just doing things in-house as much as possible. A lot of that was just limited dollars to spend and cutting expenses where they could. I think that pendulum was swinging towards handle things internally, and now it seems to be heading back the other way.

Maria Abbe: Right. Now is there a one-size-fits-all answer?

Dallas Wells: No, I don’t think so. A bank doesn’t have to have to an ethos across the board that says we always outsource or we always buy the technology we need or we always build it. I think case by case, it’s going to be different. You’ll have some banks that will tend to fall further on one side of the spectrum or the other, usually just based on what kind of resources they have internally and what kind of experience they’ve had with building some of their own stuff. It definitely doesn’t have to be across the board, and I think there are some things that banks should buy and I think there are some things that they don’t need to buy. They can build them pretty simply and cheaply in-house.

Maria Abbe: What are the typical reasons a bank might want to build their own solution?

Dallas Wells: I think the reasoning for that is pretty straightforward, which is control. There’s a lot of very bank specific and customized processes that banks have come up with over the years, essentially things that are very unique to them, so the idea of building your own in-house solution, and that could be an in-house CRM system, it could be a pricing tool. It could something as simple as a spreadsheet to try to calculate your loan loss allowance. All those things I think qualify, where you could buy solutions or you could build something in-house. The reason for wanting to do your own is just control over it. You can build to your own set of feature requests, basically. Here’s the list of features that we think are really critical to us, so we’ll make sure that those are in place and that we can handle those.

I think the other one is … and this one can be misleading, but I think the other one is cost. Vendor solutions have a pretty straightforward price tag, and sometimes there’s a little sticker shock involved with those. The feeling from a lot of bankers is well, surely we can do something ourselves cheaper than that. When you actually do the analysis behind that, that’s really the case. You’re talking about hiring a vendor who has some expertise and some scale and some efficiencies in doing just that thing over and over again, versus a bank that has to figure out what they’re doing and get up to speed on it, build it and then maintain it. There’s a whole lot of hours in there that you have to account for, so it’s not always true that it comes out cheaper. Again, there are some tasks, some functions, that it might make sense, but those are the two primary reasons. There’s just control and then the perception of the lower cost.

Maria Abbe: You talked about it a little bit, but why would a bank decide to buy a solution from a vendor instead?

Dallas Wells: The decision to buy, and this is a decision process that I think has changed quite a bit over the last several years, just because solutions from vendors have evolved quite a bit. Used to, it was you had two options. You can buy this off the shelf, out of the box, canned solution, that would be set up and it meet some portion of your needs, but it was never 100%, but what you paid for was what you got. There was never really no ability to make adjustments to that.

Then the other option was the full custom build, where you had a vendor come in and really customize things to you, so bankers felt like they were always making the trade-off between is it going to meet our needs or is it going to take forever to get this thing in place, and take a ton of time and a ton of money to custom build this thing for us? With the onset of cloud computing and SaaS-based solutions, that’s really changed, so that you can really alleviate both of those issues because you can get solutions that are very highly configurable. You can do a lot of the customization, you can handle a lot of that yourself and it can happen pretty quickly, so you can get something that meets the vast majority of your needs and you can get it up and running really quickly.

Where banks tend to start looking to buy a solution, is where they’re really looking at a solution that’s very critical to the function of their business, meaning that it’s important that they get it up to speed very quickly, so time to value is the critical element. We can’t afford to go multiple quarters or even years, waiting on this thing to be right. We need to stand it up and have it functioning and producing a positive ROI or fixing our issue immediately.

The other thing that goes along with that is just the fact that it’s unacceptable to have bugs in certain parts of your business. You can’t have mistakes or whoopsie type things and things that are customer-facing or where there’s lots of dollars at stake; again, those critical core business functions. Those things, it’s really important to have a solution that’s been vetted by lots of other customers, that’s being used by thousands or tens of thousands of users and has been through multiple exams and just basically has a lot of mileage on the odometer to really prove that it works and to find those little bugs and inconstancies and that those things have been worked out. For those core critical functions, you want things to be fast, you want them to be right, so that’s where banks, especially now, are steering away from trying to build those things in-house and finding some experts who do that. More and more often, that’s in a SaaS type solution, where they still get the ability to customize and configure it to a large degree on their own.

Maria Abbe: Banks are really at a crossroads then, between building versus buying. It sounds like buying a solution from a vendor does sound like the right way to go, but are there some examples of solutions where building could be the right answer?

Dallas Wells: There definitely are, and what things are right to build is going to depend on your institution and what types of resources you have. The problem is, is that I don’t think a lot of banks are always very good at knowing that, especially as they get larger. They have fairly large and pretty skilled IT staffs and good technical resources on their side, so they do have the technical skill-set to be able to build something, and it’s not just make a spreadsheet to calculate a number. I think that’s the classic build thing for a lot of problems that banks have, but it goes beyond that, too. A lot of banks have resources to write code and build some of their own tools, and there are cases where that’s the right answer. I think where that is, is where you have something that is truly unique to you, something that’s very proprietary or a process that’s very different from the rest of the industry.

The thing is, in a very highly regulated business like banking, there aren’t very many of those. There’s not very many things that are truly unique, and we hear from bankers all the time that say, “Hey, we’re really different. The way that we do this is very odd, so we need to make sure that you can handle it.” When we talk through it with them, it’s like okay, that might not be the most common way that it’s done, but we’ve seen this a dozen times before. There’s very few surprises that we get on how things are handled. If there is something that’s truly unique and proprietary, that’s one good thing.

The other one is if it’s just a really simple calculation or analysis, again, those are things that are going to be rare as you get into larger and larger organizations, but for smaller banks … I came from a community banking background and we did things like figure out our marketing budget just with a simple spreadsheet. There’s tons of vendor-based tools out there that we could have used for that, but we would have spent more time buying and learning how to use that thing than actually just plugging the numbers into a spreadsheet. There was no need for us to do that.

It was the same thing for us figuring out dividends. Again, it was a very simple organization. It was pretty straightforward: Where capital needed to be and how much money we were making. The dividend calculation was 20 cells on a spreadsheet. It was not complicated and we didn’t need an advanced capital planning tool running all kinds of Monte Carlo simulations. It was just far beyond what we required, so I think it’s an honest assessment of what are your needs? What are the skill-sets? Then what ability do you have to maintain that thing going forward, and not just key to functioning, but to be able to do what a vendor’s going to do, which is keep improving that product. I think that’s the other missing piece to consider in thinking about building. If it’s simple, if it’s proprietary to you, build away. If it doesn’t meet those two things, then I think you should probably really reconsider that notion.

Maria Abbe: Yeah, and it sounds like when you buy from a vendor, you not only get what is hopefully a top-notch solution, but also a partnership to help guide you through that, what can be mucky process of putting it together and maintaining it.

Dallas Wells: Yeah, that’s obviously … Maybe we’re a little biased in that we’re a vendor working with banks to do this, but what our clients tell us is part of the value is not just the tool. That’s something that we’ve spent years and many thousands of hours building and perfecting and tweaking with a couple hundred of clients and thousands of users and many billions of dollars priced through our tool. They get the benefit of that history, and the tool is good, right? The bugs have been worked out, everything is proven out through audits and documentation that is hard and expensive to replicate in-house, but you also get the benefit of somebody who does pricing all day every day for a whole bunch of different banks.

Again, when they come upon those things that are like hey, we do this really weird, or we’re really struggling with this, we’ve seen it before. We’ve been down that road and we’ve figured out what things work and what things don’t, and that’s part of the value you get, is that knowledge and the fact that we’ve stepped in a bunch of potholes along the way and figured out how to avoid those, so you don’t have to do it the first time through.

Maria Abbe: Right. Now, say for example a bank is looking at two different systems, and they’re at that crossroads of buying versus building. What do you suggest are the types of systems a bank should buy as opposed to build?

Dallas Wells: We touched on it a little bit, as far as those things that are critical to your business. I think the other things that would follow there would be things where there are good, proven solutions. There’s no need to reinvent the wheel, and again to step in a bunch of potholes that have already been stepped in. We see banks that are doing things like trying to build their own in-house CRM system, and the logic is we want it to fit exactly our workflows and we want to make it something we know our staff will use, so we’re going to build this thing on our own.

What you’re effectively saying there is that we think we can do CRM better than Salesforce can, or better than Microsoft can. It’s true that those companies aren’t building just solutions for banks, but they have a whole bunch of banks who use their stuff, and they have thousands of really smart engineers who have been doing nothing but building CRMs for decades. Expecting that you can basically beat that performance is expecting a lot. If you do have those types of resources, those resources could really be used to customize and to integrate that off the shelf CRM system and to make it very highly custom to your bank.

Salesforce is about the most flexible system that you could conceive of, so if you have those kind of technical skills, rather than having built something from scratch, have them take Salesforce and really deeply embed it into all the processes that you have in your bank. Salesforce has already developed APIs and basic plumbing to connect to lots of different kinds of systems, make those things work smoothly, and then you’ve got the help of Salesforce to keep those things maintained and improving and growing, versus trying to invent all those things as you go. CRM, what we do as pricing, we see some banks trying to build their own loan origination platforms. Again, there are proven vendors that do those things really well, so lean on that expertise and stick to the custom in-house build stuff for the things that are truly unique to you, versus something that there’s already a proven solution for.

Maria Abbe: Great. Now, do you have any examples that you can share of banks who are struggling with this question right now?

Dallas Wells: Yeah, what’s actually been interesting in some of the conversations we’ve been having recently, is the size of institutions that we see that are still relying on good old Microsoft Excel to do some pretty key functions at their banks, and they’ve tried to take that and scale it and stretch it way farther than solutions like that were ever intended to be stretched. We’re talking about multi hundred billion dollar asset financial institutions that are trying to basically use an Excel pricing calculator to handle pricing across their commercial organization. They’ve tried to take something that they designed to be a calculator and they’re trying to mold it into the modern requirements of a pricing system, which is workflow around that and integration to systems all around, and how do you approve pricing? How do you collaborate on pricing? Excel was not designed to do any of those things, so we’ve seen a couple of organizations that have spent literally millions of dollars and multiple years trying to stretch those things to make them into these custom solutions, and they just don’t scale very well. We haven’t seen anybody that’s been really successful with that.

For obvious reasons, it’s tough to do across a very large organization. We’ve seen some more community regional banks struggling with the same thing as they cross that 10 billion dollar mark, headed towards 20. They really start to stretch the limits of what you can do with just calculating a number in Excel. As the expectations of how they measure and apply risk to new pricing, as they try to do that inside of Excel, what inevitably happens is they can make the numbers accurate. That’s what Excel’s good at, is measuring a number. What they get bad at is making it something that can actually be useful and applied out in the sales process.

If you’re a spreadsheet nerd, they’re very impressive. We’ve seem some huge complex spreadsheets that are … We’ve seen a few that you put in your inputs and then you push go and you have to come back 10 minutes later when it’s done chugging through all the calculations. You can see the thousands of hours of labor put into those things, and the number that comes out is accurate; we don’t question that. The question is how is that useful? How do you actually negotiate a deal with that as the back end of what you’re trying to figure out? We’re seeing this struggle frankly more often than we expected within institutions of this size.

Again, I think it’s coming up more often now just because banks are coming back and reevaluating and saying hey, this has been a pain point for a long time. Maybe now is the time that we rethink this and think about better integrating these systems, better incorporating all the data that we have and making this a viable thing for our end users, our producers, to be able to use with customers and end up with a better experience and more profitable deals for the bank.

Maria Abbe: Great. Thanks so much, Dallas, that was really insightful. That will do it for us today, thanks for listening. You can always find more information about today’s episode at precisionlender.com/podcast. If you like what you’ve been hearing, make sure to subscribe to the feed in iTunes, SoundCloud or Stitcher, and we would love to get ratings and feedback on any of those platforms. Thanks for listening. Until next time, this has been Maria Abbe and Dallas Wells, and you’ve been listening to the Purposeful Banker podcast.