Battling Business Nihilism

Cheryl Brown

What does bank technology have in common with a semi truck? And how does business nihilism get in the way of digital transformation? Find out as Q2 Chief Technology Officer Adam Blue joins Dallas Wells for this episode of The Purposeful Banker.

Listen

Transcript

Dallas Wells

Hello and welcome to the Purposeful Banker, the leading commercial banking podcast brought to you by Q2, where we discuss the big topics on the minds of today's best bankers. I'm Dallas Wells. Welcome to the show.

About once a year, we have our Chief Technology Officer Adam Blue join us on the podcast, and he is always good for a philosophical conversation about, well, we'll see whatever happens to cross his mind. We'll have the bleep button ready if necessary, Adam, so we'll just go with it and see where we head with this. But it's that time of year again to have Adam back on the show. So Adam, welcome. Glad to have you.

Adam Blue

Hey, thanks Dallas. Happy to be on today. Whatever happens, you can fix it in post, so, no worries …

Dallas Wells

As we said, it's been about a year, so we'll start with, I don't know, probably the hardest question. What have you been up to? What's been top of mind for our CTO?

Adam Blue

It's been an interesting year. So about a year ago, we had CONNECT and there was a lot of focus on generative AI. I did a talk at CONNECT that people seemed to at least find interesting around generative AI. We're a year into that now, so a pretty good chunk of the last year has been thinking through what does that actually look like for bank, right? What use cases are compelling? Corey Gross and the team have done some really spectacular work. Daniel Wagner has done a lot of actual technical work underneath. Jesse Barbour's been pitching in, and so I think we're just starting to see customers over the last maybe 90 days work with some of the early Andi Copilot stuff, which we're super excited about.

And then we're also starting to get some breathing room from that team to work on internal use cases. And so I had a conversation with the implementations team. We had rebuilt some of our infrastructure to allow for more rapid changes and multitenancy and really what I'll just call general evolution of the technology architecture. And so in doing that, what happens is engineering says, "Oh, wow, we can make these changes and it'd be really great to be able to deploy the software and then make these kind of changes and we can use this new tooling. We can maybe use ..." In one case, we switch a lot of our adapter stacks from C# to Golang, which people were excited about because there's some really nice features in that language. People, they just get excited about new stuff, and so it's just interesting when you can get that intersection of business value and new stuff.

Engineering does all this work and it's really strong work and then you bring it to Implementations and to be fair to them, they're like, "I have to learn what now?" And it's like, "I just spent the last two years of my life with the last new thing you gave me, figuring out how to install it, where the logs are, how to read it, how it works, what breaks, what doesn't break." And so we sat and the team said, "We love all these things that you did very intentionally, but we need some help because some of these aspects of the workflow are actually more challenging than they were previously." Mostly just because people's handles to things get very well-worn and then you replace them and they're like," I don't understand this."

So grinding through that, we posed a really interesting question. It's very early with this, but I just thought given the capabilities of generative AI, particularly the general purpose transformer models, it'd be very interesting to be able to collect the information about an implementation and then the information about support cases, information about products, all in these unstructured text blobs, really. The thesis we have on the table is what if we could train a model that would answer questions about a bank's implementation? And so you could ask it things like why is it set up this way? And then it would relate back to you the set of linguistic tokens and identifiers and sentence fragments that come out of Gong recordings, implementation calls, or fragments of documentation or something from the sales cycle.

One of the things I've learned is everyone who works at Q2 works very hard. They're all very smart. We have a high bar for employees, but the set of information that's required in order to take a bank from the sales cycle to launch and then to maintain it over time is simply more than you can really fit into one person's cognitive capability. It's just bigger. The product is bigger. There's a lot of variation. That's the beauty of the platform is that it can do all those things, but it's a pretty tall ask to say to an implementation engineer, "I really want you to understand the way the product works and then these 13 remote deposit capture integrations. And by the way, I also want you to understand these roughly 40 odd core integrations and then 600 system properties and then whatever."

And all of that complexity has value. Just being able to say, given that someone has general knowledge and a good understanding of the product and the product set, if we could ask a GPT model, explain why we set up statement imaging this way, and then the GPT model grabs those bread crumbs over time, I think it could be really interesting. And it's a thing that I think even customers down the road, once we figure out how to make it very accurate and we have the data on a clean stream, I think customers might also be very interested to know how is this set up? Because one of the big challenges we run into is onboarding new employees on the Q2 side, but also onboarding new employees on the financial institution side. People move teams, they retire, they do whatever.

And so you can end up in this scenario where if we lose some continuity with a customer, I feel like it can be very expensive for them to come back up to speed. And so being able to just capture that knowledge in a way that is more natural than it is today. We've got all kinds of tooling that could tell you, here's the JSON for the configuration of this adapter. And to the average human being, it's like that is of very little use to me. In fact, it may actually be counterproductive because it makes things confusing as opposed to simpler. So this notion of what if we could capture that knowledge in a reasonable way in unstructured text, train a model and then have the model help us?

So that kind use case, I think is very similar to the use cases I'm hearing from banks about we're really just trying to organize knowledge. I talked to one bank at CONNECT who's doing something very interesting. He said, "We have people that have to review agreements to determine whether they're in line with policy or not." This is a task that falls into that quadrant of it's very detail-oriented, but it's also not very inspiring. At the end of the day of doing that, I don't know that anyone is like, "Man, I'm super energized by the work I spent today making sure that all the words on this piece of paper were at least semantically aligned."
So the notion would be they've been training a GPT model with some help from a partner and they're using that to do what I'll call the first pass. And so it will identify, this agreement is actually out compliance with policy in these three key areas, so it gives someone a place to focus. And I think the goal is just could someone do three or four of those in a day instead of doing one or two of them in a day and then have some fraction of that time left over for something else? That kind of assisted use case is what's starting to be really interesting around GPT stuff.

Dallas Wells

That's interesting and especially, I've spent probably too much of a chunk of the last week chasing one of those exact issues where somebody made a decision two years ago to use a slightly older version of a thing inside the Q2 stack. I trust their judgment, right? There's a lot of complexity and they had some good reason for doing that. And I'm also guessing that it's probably documented exactly as they're supposed to do it buried somewhere in Jira tickets or in Salesforce, in a work order, in a requirements doc. It's in there somewhere, but figuring out where that decision was made and why, and maybe that human does or does not work here anymore. It's this interesting thing where I think people fear this technology because in some ways, they're like, "Well, we still want the humans to make those judgment calls," and I don't think that's what you're talking about. The human still made that judgment call somewhere along the line, but we've got a technology that can help us when inevitably we need to understand why, or make a change or something breaks and we got to pull on that thread. That search for the needle in the haystack is really time-consuming for a lot of smart and expensive people who should be doing something better with that time.

Adam Blue

Yeah. It's expensive in two ways too, in my opinion. That's a great example is decisions 24 months ago were probably optimal because they were made by people who are invested in the outcome of the decision, they have available a certain set of information to them, and then they make a decision, it's the right decision. The optimality of that decision decays over time as the information that goes into the decision changes. And so I think there's two challenges you run into. One is, first off, understanding why the decision was made means now you can confidently say, "Well, we should change that” or “We should not change that” because whatever the obstacle was to doing the other thing we could have done, it still exists and we have to deal with it.

The other challenge I think that we run into ... This is a broad challenge in some sense, and I think it fits into some of what's going on and just U.S. culture, politics and the zeitgeist right now, which is when people become less comfortable with the nature of what truth means, and I'm hard air quoting here for those of us listening to the podcast, but when the definition of a truth becomes a malleable thing, then it tends to undermine a lot of trust and a lot of certainty around many things. And then you can end up with this ... We'll coin this term “business nihilism,” which is much less dangerous than your run-of-the-mill nihilism.

Dallas Wells

The regular nihilism.

Adam Blue

Yeah, that's right. This is like a junior form, but basically people show up to work and they're like, "I can't really figure out what happened. I'll never understand why that decision was made and so everything that came before, I'll just totally ignore it. I will make only the best decision now based on the information I have today because I don't have a lot of trust that the information I'm receiving about why the decision was made or how it worked actually worked."

You can see this between groups is generally where you get it, so engineering shipped software that has defects. The team that implements, or supports, or sells or whatever comes back and says, "Here are the defects. I need you to fix them." The way in which those communications happens determines the rate at which software can be delivered. There's going to be defects. Everybody knows that. But if you think as an implementation person or a support person that you can say, "I found a defect," and then someone on the engineering side will say, "That's interesting. Let me take a look. Wow, you really did find a defect. I see why this defect is important. I see why we missed it. Here's a patch." And then you go on with your life. That flavors how much risk you're willing to absorb in doing your job.

If you think you're going to go to a team and say, "I found a defect," and they're going to say, "There's no defect there," and then you prove there's a defect and they say, "Well, that really works as designed. That's how it's supposed to work." And then it's like, OK, now I got to push back on that. And then OK, well, it may work as designed, but there's a flaw in the design. It's like, “Well go fuss somebody in product because it's their job.” That kind of churn in the organization means people say, "It's just not worth it. Maybe I'll make what is locally an optimal decision in the mathematical sense of local," which now occurs to me most people probably don't understand the definition, but you make a decision that's a good decision for you in that project. Don't take the new version because you don't really trust that it doesn't have a defect in it.

And then in turn, what happens is you lose the opportunity to avoid a problem later on, or to advance the software and everything just gets very sticky. Everything gets very muddy. I've seen people that they have an emotional attachment to a semantic version number of a thing, and they'll be like, "4.3.2, hotfix patch level Q, that's the one I roll out right now. That's the one." And I'm like, "There's a 4.3.4. There's a 4.4.1." And they're like, "But I don't know what's in there." That trust loop. I don't think it happens maliciously, it happens because underneath it all, it's so expensive to absorb, and manage, and work through the impact of that knowledge. So when informational trust ...

And I think you can see this writ large probably all over the world, not just the U.S. I just happen to be in the U.S. most of the time, but you can see this kind of thing that's big where people say, "It's so expensive to try and uncover the ground truth of an actual thing that I will simply make decisions that don't require me to understand the actual truth of it, or to really have to absorb any ambiguity or nuance."

It literally just makes me sad because it's avoidable. It's not how people really want to move through the world and not how they want to act. I feel like they're forced into that position. So I'm going to call that business nihilism, which basically says it doesn't matter how we ended up here, the only way we're going to make it any better is for me to make this local decision and completely ignore everything that came before. And it's just like that is probably not going to be the right answer.

Dallas Wells

It's true everywhere, but we'll talk about bank systems, the interconnectedness of them across a stack within a bank and then all the vendors that play there and then customers connecting the outside things. You start to stack those localized decisions on top of each other and you have a very dysfunctional overall system there. Even though there's a better answer maybe on the table, it feels like we have this inability to get there.

Adam Blue

It's very difficult to build systems that are deeply integrated, but not deeply coupled. An example of what I mean about that is—this is not a behavior I engage in because it terrifies me—but you can go get a truck and you can put a boat behind the truck. And a boat in a trailer probably weighs ... It's some significant fraction. In some cases, it could weigh more than the truck, right?

Dallas Wells

Right.

Adam Blue

And then you hook up the lights so when you push on the brake pedal, the lights go on in the trailer so people don't rear end you. That's probably a thing that's kind of important. It seems like that would have value. So that system is pretty well integrated. There's probably a little bit of buffer between the hitch and the trailer because you have two different items of mass with different polar moments of inertia, and you move them around at high rates of speed.

And so when that system gets unstable, and I saw this once. There's a long hill in Austin at 2222 and 360 for those of you who know Austin. The long downhill coming out of the hill country into the flat, the valley of the river, there was a big semi-truck, a huge one, and it had a bunch of telephone poles on the back. And up at the top, somebody did something in a car that made the truck swerve a little bit. You've got a mile of visibility here.

So up at the top, the truck is coming down. It's a little wobbly and you can tell the truck driver's trying to manage the truck and the trailer because he's had to make this sudden movement. You got about halfway down the hill and you could see the point in the overall system of physics shift where the trailer started to drive the truck. And it's coming at me and I'm thinking, I don't know what is going to happen here. So I'm speeding up because I'm thinking I would like to be past this physics problem well before it goes pear-shaped.

And so the truck continues to wobble. I'm over on the shoulder on my side. I get past the truck and I look in my rearview mirror. It just comes completely apart and the logs are everywhere. And I mean, these are telephone pole-sized logs. And people behind me coming this way are pulling off the road and they're veering and the whole thing. It's an integrated system and it's very stable under a certain set of conditions, but the system is so tightly coupled, and it's impossible not to, that when one part of the system gets out of its normal behavior, there's nothing you can do from the other part of the system.

And performance challenges, which is probably one of the number one things you run into in this kind of tightly coupled thing with digital banking. Performance challenges, they have that rolling down the hill. Here's the thing that's fascinating to me about it is, and this is counterintuitive, the best thing you could probably do in that situation would be if you could safely unhitch the trailer full of logs and the cab of the truck because then it breaks the loop of that system. The same way, it's like you got to steer into the skid and you don't put your foot on the brakes when you hit the ice.

And we did the same thing in our product as we figured out how to break that tight coupling between our middle tier business logic layer and the integration layer of the core. Because it's one thing to say, "Hey, when the course slows down, you're not going to get great digital banking performance." It's another thing to say, "When the core slows down, people are just going to get a spinner in digital banking." What they expect is, no, I want a well-formed error to tell me I can't log in right now and then I'll try again in 10 or 15 minutes.

But those systems are tightly coupled in a way that when one misbehaves, it's very difficult to keep that from cascading through the remainder of the components. And I've worked on a lot of technology in my life. I can say without reservation, digital banking has the most labyrinthine web of integrations, and just by their nature, they tend to be fairly deeply coupled. I have a tremendous amount of empathy for all the folks that work at banks and have to deal with that problem, and then they have to deal with us as a part of that problem. They have to deal with their core as a part of that problem. And so it's just so challenging to try and get the integration value of things because you want them to be tightly integrated, but you want them to be loosely coupled, especially from performance, stability, uptime error handling perspective. And it's a difficult thing to teach, but I think it's a really fundamental principle. I think it goes beyond the technology. I think it goes into the way you think about organizations, the way you think about teams, all of those pieces.

Dallas Wells

I can't help but see that analogy of this truck coming down the hill tightly coupled everything. It's a little bit of what you talked about at the last CONNECT of core systems and where banks are with those because they sit at the center of that hub system and they've got all these now growing in complexity and sophistication pieces glued to it in this haphazard way. Give us the snapshot version of where you're thinking is with cores and how banks and credit unions should be thinking about what that evolution should look like because it's a terrifying thing. And what they look at it as is like, well, sure, I could swap out one of the big three for another big three, but what's the difference?

Adam Blue

Yeah, what's the point?

Dallas Wells

How should they be thinking about that outside of just I swap like vendors, right? But what's that evolution look like for them?

Adam Blue

That's right. That notion, I could swap, but I'll just get the same thing with a different logo on the bill. That's business nihilism at work.

Dallas Wells

Yeah, there you go. Yeah.

Adam Blue

So here's what I think's happened over the past 20 years, and I say this ... Let's just grant that I'm biased because I helped build a digital banking company, but the center of the IT universe for a bank was the core. And part of the reason that the center was the core was that the functions of the bank from a technology perspective rotated around it and they provided service to people in which the core determined the semantics, and the rhythm, and the nature of that server. You went to the drive-through when it was open. You went to the ATM where it was. You communicated with a call center when they would pick up the phone. And then in 1995, Wells Fargo launches online banking in the U.S. and the center of mass of that behavior changes. It just changes radically. It doesn't happen overnight. It takes a while, but the center of mass is now that the customer is essentially performing those tasks in some combination of self-service and digitalization, digital transformation.

I want to say this very carefully, the center of it is not the digital banking system. That's not the point I'm making, although you might think so because of my inherent biases. The center of it is the digital experience. That is now the center of the technology point of the bank. The digital banking system, whatever it happens to be, enables much of that experience, but it doesn't happen without the core itself, mobile remote deposit capture, check image, statement image, lockbox, positive pay, you name it, right? All of those ancillary pieces. The core no longer mediates the choice of who can move money in and out of which account. It participates in that decision, but a lot of that is now embedded in a combination of data on the core, data in digital, and to some extent, data choices that are made by the individual consumer.

So for instance, if you are on a traditional core and you create users within a small business or a commercial, the core has no idea that those users exist because the core's focus in the bank space in particular is account based, right?

Dallas Wells

Right.

Adam Blue

And so those users, they're not particularly relevant. They might be signers on the account, they might be not. They're probably not, but they have privileges to do things via digital that happen on the core. And that abstraction layer has moved the center of mass of how that technology works.

Similarly, at a credit union where you have a lot of member-centric data models generally, commercial is I think particularly awkward in many cases, not all cases, some cores handle it more elegantly than others. But commercial can be awkward because you're not a member of the credit union. You could be making payments and reviewing reports and doing things and entitling people, but you don't really have a member record. You borrow a member number from whatever the business is that belongs to the credit union, opens the account.

And so these little bits of conceptual friction that come up, they show up as things like a bank saying, "I really need to be able to manage the addresses on these 46 commercial accounts independently because 32 of them are this address and 12 of them are that address." And it's like it feels very vestigial in a sense. And then what happens is because a financial institution and their existing, and I'll call it process debt, is the sum of every decision they've made over the last 20 to 25 years.

Again, we have this topic we started with. Nobody knows why we put a linking ID into a field that's meant to contain an address. Nobody knows why we put that there, but that's where we put it and it's always been there. And for God's sake, don't move it because there's a whole bunch of processes and resorts. Everything will stop working. And so this notion of this says address two. And it's like, well, it's usually null, but when it's not null, it's actually this thing that indicates the relationship type. And it's like you learn that, but all those little bits of friction, all of those untruths in the data model, they accrete and accumulate over time.

Checks is another example. I mean, we got so many systems for dealing with checks. Target says they're not going to accept checks anymore, which is great, but there's still going to be checks out there. You got to write them. You got to reorder checks. You got to process checks. You got to do MRDC on checks. You got to run checks. You got check sorting. You got to do check 21 truncation. You got to have check imaging. You got to have deposit item detail, all these things. And so you look at online banking implantation, it's like I would be surprised if 10 or 15% of the work effort is around integrating digital to the fact that people make ink marks on a rectangular piece of paper, which is absurd, but we're not going to give them up overnight.

And so all of that process and technical debt follows you around. And so it may or may not be true that, hey, I can go from the blue one to the orange one, or the orange one to the green one, and my life's the same. I don't think that's really true though because there's so much value in the way in which you choose to employ the technology. And there's so much value in thinking about really asking this question: What is the thing that I actually deliver? Is it the account? It kind of is, but it kind of isn't. If you go back to that jobs to do theory of product management, I think a lot of financial institutions think about their "products" in terms of I'm going to deliver this account and it has these characteristics or terms. And probably if you think about an account as an abstracted bundle of privileges that are afforded to an end user in the digital channel, I think it radically changes what you think about in terms of core and digital and ancillary systems.

And so what if you asked the question and just said, "If what I really need is I need to issue a debit card, I'm not going to do checks. I'm going to do 100% digital enrollment, digital identity management, digital self-service with a chatbot and then maybe at the very bottom, a bailout to the call center,” then your technology need for doing the accounting, running the abacus underneath that, is very different than it is, "Hey, man, we're going to give them a checking account," which then means, well, checking account, that is a thing that is and not the job that you need to do.

And so we give people checking accounts. We call them checking accounts, even though sometimes they don't even have checks. Remember that was hot to say for eight minutes?

Dallas Wells

Yeah.

Adam Blue

A lovely little oxymoron. So thinking about it from the perspective of what's the job to do for the end user gives you some alternatives, particularly around more simple relationships or entry-level relationships where you can employ a sidecar strategy and use a modern deposit accounting system. You could think about some of the cloud-oriented stuff, but the work, right? The work is not making the choice and turning up the technology. That's fixed. The work is changing the way in which you think about how you want to deal with your process debt, your technology debt, and your cultural debt. Those are the three things I think that are really important.

So in the same way that in “Empire Strikes Back,” Yoda tells Luke under the tree that that's where the evil is. And then when he comes out he tells them the only thing that was in there was what he brought with him. If you say that I'm going to change cores to a modern core, the same core, whatever, and it's going to be exactly the same, you're bringing that with you. That's you. It's not actually the technology provider. So you have to be very thoughtful about if you ask the same questions, if you think about the products the same way, if you don't really think about the jobs to do and then you repeat the exercise that you've gone through in the past, you're going to get the same outcome.

And so I think that changing the mindset in the industry around what's necessary and not necessary, what's valuable and not valuable might give them some freedom to do some things that are more interesting or more innovative. If someone said, "We can let go of this long tail of features we've been asked for 20 or 25 years," that part of the industry tends to innovate via acquisition and I think that is a very challenging way to do it because it's like mixing colors to make icing. You never get rid of the colors that are already there. And so if you've got red and then you're going to put more blue in, you got to put a lot of blue in before it turns to purple. And so given the mass of the acquiring entity and then the relative mass of the acquired entity, it's like things get redder and not bluer when you put the blue one into the red one, I think is the way to think of it a little bit.

Dallas Wells

So a lot of things that we could talk about there that we don't have time for, but a thought coming as you went through that. A lot of times we get this brought to us, and I know the core providers do probably in spades as well, which is like, "Hey, we're looking at switching systems. Here's all the things that my old one did. It has to do all that, plus these things." And the way you described it there, it's almost like switching from one provider to another is not the thing. It's almost like the conversion ends up being the value if you approach that the right way.

It's like an extreme juice cleanse, right? All kinds of toxins get to exit the system and you can start fresh and all those things that you hid in the specialized fields and the fact that you used code numbers instead of real information because storage was expensive back in 1994 when you made that decision, all those things you can start fresh with in a way. We rarely see that from financial institutions of willing to erase and start over and say, "What are we actually trying to do for this account holder? What are the things they actually need to do?" Instead of saying, "Well, obviously they got to be able to do all the things they did before."

Adam Blue

Yeah. I think first off, if you work at a bank, it's not your fault. It's just the nature of the business. You got to carry around every payment method you've ever issued. You've got to hold on every account you've ever given anybody. You've got to remember everything you ever did for anyone. Part of it's compliance regulatory burden. Part of it's the nature of the industry. Carl Ryden is fond of saying, “Banks project trust into the world.” That's an extraordinary and humbling responsibility.

If you look at Christensen’s, “The Innovator's Dilemma,” the book they make us all read when we're going to do our own MBA and all that kind of stuff, the digital cameras work because they're not film. And then cell phones eclipse digital cameras because they're not a digital camera. People still shoot on film. And then I saw a beautiful two-thirds sensor that goes into old camera bodies to give these old camera bodies and lenses life. If you take a digital picture with a 1950s Hasselblad camera, that's super cool. So all these technologies are constantly getting remixed.

The question I think that you can ask yourself is, how small can I make this project such that I can do something truly radical where I can learn what I'm going to need to do the rest of the project? So don't say, "Man, we're going to replace the whole core system. We're going to replace the entirety of mobile remote model. We're going to replace old digital banking," because then you have to have every feature you've ever had. Ask this question, “What part of my customer base could be served by a more modern, thinner digital solution? What part of the jobs to do?” Just a Venn diagram that's interesting, right?

We do this all the time at Q2 is like Kafka landed. It came out of LinkedIn. We got very interested in it in 2012, 2013, 2014. And so we said, "What is a small problem that we could use Kafka for so we can learn how to use Kafka?" And then we picked the problem of streaming off audit events to a third-party security partner. So we learned about it. We didn't say, how do we go in and take the core of our architecture and replace it with event driven streaming system? We're now progressing down that road where we may get there or we ask questions like, where is the part of our architecture where we struggle the most with resilience? And then new tools become available to make us more resilient. Where do we really struggle with implementation complexity? And then we use that as the entry point for the HashiCorp stack, which now runs our entire infrastructure.

But you have to earn the ability to make use of these new capabilities and technologies. But the question you should be asking, I think, is what's the smallest project with the highest payoff where I can learn the most? And then those tend to be things where the learning is the value and not actually the direct business outcome. And then you can make a second bet that's much, much larger and you say, "We learned this and we learned that. It's good for this, it's bad for that. OK, well, can I fix that problem and broaden the circle I can draw? Can I think through a different way? He uses technology. Can I just repeat this project again with another piece?" And so as opposed to this like, "I'm going to go from green to orange or whatever," it's like, "What part can I take and do something really interesting, really novel? How small can I make it?" That, I think, is really interesting.

Dallas Wells

Yeah, I like it. I think that's a good takeaway and we'll wrap it there so you can be onto the next thing. But Adam, always a pleasure and really enjoy you. Really appreciate you making the time for this.

Adam Blue

You bet. Thanks very much, Dallas. It was fun.

Dallas Wells

Thanks everyone else for listening this week's episode of The Purposeful Banker. If you want to catch more episodes, please subscribe to the show wherever you like to listen to podcasts, including Apple Podcasts, Spotify, Stitcher, and iHeart Radio. As always, we'd love to hear what you think in the comments and you can learn more about the company behind the content by visiting Q2.com. Until next time, this is Dallas Wells and you've been listening to The Purposeful Banker.