This is the Business Tech Playbook, your source for It help for your business. So we're kicking off another podcast. I'm your host, Rob Zolson.

And I'm your other presenter, William Pote. I'm the owner of Etop Technology here in Southern California and also working to build the Business Tech podcast.

And today we have probably a returning guest that's going to be more frequent in Brandon Martinez from Etop as well. Welcome.

Hey, thanks for having me on. I'm Brandon. I work at Etop here as the senior It manager, which is the wearer of many hats, as I like to say, if it touches technology, any sort of advisory on that stuff, that's all on my plate. So I live and breathe tech.

Well, thanks for coming. Now we take turns in the podcast. Now, BJ, I believe this episode is your turn and you're brave enough to take on the topic of technical debt. I am so excited to hear this, I'm not going to lie.

Oh, goodness. When I had the thought of what should we talk about? And I was like, OOH. Technical debt. I didn't really think through how complicated it could be, but at the end of the day, it's something that's pretty darn important and it's covered in almost every It management book that I've read. It's become a pretty big concept. But then how do we teach that concept to nontechnical people? So our goal today is to try to explain what technical debt is. How do you pay it down and keep it from building up.

This is going to be one of the hardest topics. And you're so brave to grab the bull by the horns. You can explain it by Wikipedia the topic, but trying to see it in real world environments and then explain that to was it Brian, the virtual CFO person that doesn't exist, that we talk about every episode and then do it with no alphabet soup? So if you do this, I have a golden spatula here for you.

Golden spatula? Is it to hit me with if I use an alphabet soup or to celebrate as a little trophy?

We were using it. I've used it before using mics and podcasts to stop the co host from rambling too long. So if you get it and you succeed with the topic, you get to be the person that has the metaphorical spatula.

You laugh, but I might have to go get a metaphoric spatula so that way I can smack myself on the side of the head to stop rambling.

God bless. DoorDash.

I'll use some of the leftover bronze filament I have from the trophies I made from the Roost team to print you out a bronze bachelor.

There we go. 3d printing.

I love it. Actually, we could do a 3D printed podcast. Mike, that's an award.

That's too much. This is like a virtual gavel, right?

Exactly.

I'm in the danger zone, though, because I'm right next to Beach's office and I could see some podcast mics flying back and forth. You could the shenanigans out of get out of control here, right?

Oh, goodness. All right, so you'll be priced a podcast mic lately. You don't throw them around.

You'll be our technical financial advisor on how to stop occurring. Technical debt, please. I don't know where you want to begin, but let's hit it.

So just thinking through, we've to some extent adapted it for ourselves. But officially, technical debt is when developers build code. And then it's either not kept up to date, it's not documented, they keep adding on top of it, and then at some point, everything comes unraveled. And that unraveling really is what becomes the downturn of a potential platform, a product. It's the downfall.

So you've been fantastic on metaphors. Can you give an example before we did the was it bouncer in the bar trying to explain how antivirus works. Could you give us an example of some basic version of technical debt? Blame? Like I'm five, I feel like it's.

A bit like a hoarder, where they keep putting more and more stuff in their house without ever taking anything out to the trash. And what happens is eventually the house kind of burns down because there's just so much junk in their house. Like, at the end of the day, don't be that hoarder and do maintenance.

They're making that easy decision that instead of walking outside taking out the trash, it's just easier to throw it in the corner and deal with it another day. And now we're left with, oh man, what am I going to do with this massive pile? Or their house burns down is the inevitable. I'm completely abandoning it.

And sometimes abandoning it from a code perspective or from a development perspective might be the right answer. But at the end of the day, it is exactly like a hoarder, where you have piles and piles and piles of trash everywhere. And unless you go in and you do the maintenance of cleaning it up, it's going to keep the building up. So then as you walk through technical Debt, there's a number of different books that I've read that reference. It pretty substantially. So as a business owner, they're generally fairly high level books, so they're fairly easy to understand. One would be the phoenix project, one would be the unicorn project, and another would be the adventures of an it manager. We can link them in the show notes. They're simple stories that explain development. It why it matters and why documentation matters, and why building standardized processes and procedures for technology really matter. We all have real debt. Well, how do we get rid of real debt financially? Well, we need to do the same thing for technology in your business.

So what are the different types that we need to worry about? We explained how it could work for a hoarder. Keep putting stuff to the side. What are some of the things that we would see in the average day to day for small, medium, and large business.

I think a really common cause of tech debt that I see is trying to throw more products and tools to fix a solution, especially if those tools aren't necessarily designed to fit that mold. People will oftentimes, rather than try to find the root cause of why the problem is occurring, they find something that can fix the symptoms by just throwing stuff at the symptoms of a problem. You end up with 510, 20 different pieces of software that are all trying to accomplish roughly the same goal in different ways. And it just gets out of hand to the point where stuff starts conflicting with each other. It starts fighting over what resources you need. It's just a hoarding of tools, and people really need to just take a step back and say, okay, why is this the case? What is adding this tool going to necessarily solve here compared to just making the short term process of I don't want to deal with this anymore, and not actually adjusting the operational efficiency of the organization to accommodate that change?

I love that I always think of what people do in different automotive industries. You get someone that has a car and the radio goes out. So what do they do? They get their own bluetooth speaker to attach the dash. They come with some other platform or solution to fix their problem and not actually addressing the problem altogether. I've seen that in most commonly email add ons, somebody has a problem where they want to have some sort of automated solution and they decide, hey, there's this great tool, let's add this tool to make your email solution work, when they could have just purchased the licensing in the first place and had that package built in. Now they're having to support two platforms. The platforms do updates, they break, and it's not working correctly, and they don't know how it's fixed because it's multiple platforms. I could go on and on about how many different email associations alone just in that world creates so much more cost. That technical debt you're speaking of, and.

I think a lot of it is also using tools in ways they weren't designed to. So one of the ones that we see probably the most is an Excel spreadsheet. And you know what Excel spreadsheet I'm talking about, it's the one that runs your company that has 27 data sources and is 2 million formulas, and it crushes your computer every time you open it, but nobody knows what it does or how it works, but somebody created it that was an Excel wizard 15 years ago. And everyone's nursing this thing along when in reality they really just need a business intelligence platform that ties into their SQL database. Or they need to be able to integrate three or four different feeds into a grafana dashboard there's a lot of different ways to generate reporting, but if, and or calculate numbers, is the tool that you're using the right one for the job? That to me is one of the other big pieces that I see a lot, where it's literally making a tool that's like Excel into a database when it's really not a database. So it's making sure you're trying to use the right tool for the job that you're trying to accomplish and then realizing that there's a lot of other options out there for developing the right tool. Set.

I once saw a management team set up, think it was SurveyMonkey or some form site, and that's how they would input data to put data onto an Excel sheet for someone else to add to a different system. You're having three steps. You're having three different tools. Do this just to put on an Excel sheet and have someone manually do the job when they could have just had a customer service manager, a CRM, do that for them, having all of their customers in one spot, their billing invoices whatever data they need to keep on the customer, all in one spot. Instead, they hash together a Forums tool.

I've seen that in practice with massive Outlook address books where people will use one person's Outlook account as the CRM for their company and as an example of some of the issues technical debt can cause you when you have hundreds and hundreds of contacts in Outlook and finally realize, oh, wow, we actually do need a proper CRM platform to engage with our customers. How easy do you think it's going to be to move a database of years and years and years of contacts out of Outlook compared to just a couple of dozen out of a few people's Outlook contact folders? It's something, it's really, really sneaky in that sense where it builds up just exponentially without you even realizing it. And unfortunately, people don't often realize it until it gets to the point of, uhoh, now what?

Well, and that's a big one, I think people oftentimes go out and look for other tools. If they just looked at the tools that they had and tried to use them more effectively, they probably wouldn't need anything else. I have been guilty of this more than a few times where, let's go look for a new automation platform because we want to automate the things. And if I just spent more time learning the one that I already had, it would have saved us time, it would have saved us money. And while I do think we have one of the more robust platform solutions out there, there's a lot to learn. Like part of technical debt is teaching a new team member how to access and navigate all of the different tools we have. I figure an onboarding for our team takes a month pretty easily, possibly longer, to get truly comfortable. And I figure generally somebody is not going to be really killing it for probably two or three months in our organization just because we have so much technology to learn. And that's also part of technical debt in my mind, where it's having to bring up that level of knowledge so much. Robin, you're newer to our team. How long did it take for you to feel comfortable using our platform?

I feel comfortable as of last month. I'm not going to lie. I've been here now six months. I think I woke up with confidence last month and sat down. And then that day I worked with a customer I've never done before and I felt like I was back to square one. But because again, you guys paid some of that technical debt beginning of documentation, I was able to complete it without help, look through the notes and again regain that confidence instantly helping the customer, making sure that the ticket got taken care of. The whole process wasn't delayed because someone else paid the debt.

Something else you gain from making a documentation too, is really solidifying the things that you have learned to get there. I was just at a It conference a few days ago in Florida, and one of the things they talked about was not only training tech sufficiently, but also making them retain that knowledge. And there's a figure along the lines of just listening to someone talk leaves you with around 20% retention. Listening and writing down as you go bumps it up to 40% to 50%. Going from there and then training someone else and teaching them that concept takes that retention all the way up to 80% on average by writing this documentation. Personally, when I do it, I find a lot of times I'll think of solutions for other problems as I go because I'm writing this and I'm using my brain to try to figure out how to rearticulate this concept. And by doing so and putting into my own words, I realize, you know what, this might apply somewhere else or we could do it a little bit more efficiently this way. And it's a mix of that and also not necessarily being afraid to try new things. I know we've talked a little bit about debt and code debt being I don't want it to sound like it's caused by trying to try too many things at once. It's more so implementing stuff to make things easier in the short term. If you're writing documentation, for example, and you say, you know what, I might want to try it differently this way. Instead, you try it next time it doesn't work. You say, you know what, that didn't work. We're going to try something else next time. That's not technical debt. If you try it next time and you think that didn't really work, but it's a little bit faster, it might cause some issues later, but later is not now. So we'll just keep doing it. That way, that's what really leads to the technical debt. Because then you start having this mountain of half fixed problems and they're not going to go away on their own. They are going to rear their head all at once most of the time in a little bit of time later.

And even if you're not in the position where you can tackle that technical debt fully with documentation and you try a different method, you guys, when I'm working with you guys and how I enjoy your guys'approach a little, differently than I have with employers and team members in the past is that even when you do that in a different method and you didn't get success, you're putting notes on that. You're putting, hey, tried this, this isn't going to work. And you ruled it out and it's somewhere in the history of that document. So even if it failed, you're still sharing that to pay forward on the technical debt for someone who's doing it next.

I'm a strong believer in failing and falling forward. It's kind of a joke that I said that I fail with great enthusiasm. You learn how to get better by trying things and then documenting that you try things and understanding the impact. A couple of examples of bad technical debt in my mind, it's legacy systems. Some of these legacy systems could be old software. Like you see banks running old as four hundred s and running as 400. These systems are solid and they keep running, but the debt to change is so high. Well, it's like people just don't want to go through the pain of change. But at what point do these stop? At what point do you no longer have developers or people that can maintain and keep these programs running? Well, then you're going to go forward with a pain of change without the people there that know the system. So at some point, these legacy systems are going to be what bites you really, really hard if you don't have some kind of clear process to move forward.

Business people, especially Brian, the virtual CFO we like to pick on brian's a common sense guy. He's not necessarily a technical guy, so he wants to know the numbers. And a lot of these technical debt descriptions that we'll give you are going to be harder to cut for the return. On investment, what is it saving? What is it costing? This on older hardware, it's much easier, especially if you have something simple like, hey, Kathy has an old computer. It takes her 30 extra seconds to open any program and she has to do this X times a day. This is this many hours over a week that she's failing to do her job because we can't get her an $800 computer. That's an easy ROI to do on one system. Billing systems, like you said, as 400. I was in a business where their entire billing software is an as 400. They had the opportunity to sit down and say, hey, $5 million, and we go to a different system. It's going to do all of this for you. Automate all of these processes. And they looked at that number and go, that's not what we want to do right now. Well, because of that, now they're inquiring technical debt. They have to have ten people on staff to continually maintain and build and patch the as 400. They have to pay all this different software licensing for software that the as 400 provider told them that they don't want to run just because of it. I can go on and on and on. And let me tell you, it was a lot more than $5 million that they had to occur to not only maintain it, but to get out of it later when they couldn't use it at all.

Well, you figure the salaries of ten people, ten people that are able to maintain an as 400 are not going to be cheap individuals.

There are rare individuals.

It's a rare individual. And so being rare means that they get to charge kind of whatever they want. So you're probably looking at ten, six figure plus type people to keep one program running. And so, up front, it doesn't seem like it. 5 million seems like a pretty big capital investment compared to what I also.

Think you had some notes on wrong hardware, Brandon.

Wrong hardware? Yes. So something that I have seen a lot, going to site visits and checking out, basically, in the what are we getting into phase of the sales process where we want to see what existing hardware they have and kind of systems in place. One of the biggest things I see is hardware being used in ways it's not supposed to. Good example of that is using custom built computers to run server type functions, which can save you in the short term. It might save you a little bit of money. It might be kind of fun to build your own server. What you don't get with that is support plan from the vendor. So when we roll out our Dell servers, for example, we include a support plan from Dell. What this means is, if anything happens to those servers, hardware wise, dell will send someone on site within a day with a brand new part, have a replace and running. When you have a custom build computer and let's say your processor dies, well, now you have to source a new processor and one that's compatible with this platform that's probably three to five years old at this point, you're not going to find it in the store, so you got to order it online. How long is it going to take to ebay a processor to your office? You're sitting down while your system is not working. It gets here, you have to spend the time to install it and all that. It's these kind of forward thinking things that people don't consider when they're making these purchases because it's just the short term vision of what they want to have. I think it kind of calls back to a conversation I was having this morning with BJ about the danger of it's good enough, it's working. Why change it? One of the reasons that we push really hard to try new things and encourage everyone to try new stuff and fail and fail often is because you don't really realize it can be better until you try something new. Things could be working good enough at that time. It doesn't mean that they can't be better. And if you just assume it's good enough, why bother? You're never going to dig that up on the plane ride back. I was on yesterday from Florida at this convention they had on the Delta planes one of my favorite movies, Spaceballs. And I always think of the quote from it, you guys are always preparing. What are you preparing for? Just do it. And it's so applicable to this industry and just eliminating that in general where it's like at a certain point you just have to do it and try it. And if it fails, that's okay. Either option one, it works and you found a more efficient process. Option two is it fails in the process of failing, you've realized some other opportunities to try new things. Or three, it fails doesn't work out and that's okay too do, because now you know you've tried that and you're not going to think of what if we could have done this instead? Or what if we could have done this? What if? It's a very dangerous phrase to say when it comes to this sort of stuff.

Going back to that hardware. Just one other note. This was exacerbated by COVID as well.

Oh, for sure, yeah.

When I had a customer fly by night guy built a handmade server that wasn't a server only three years in, even when they claimed they had some sort of support plan, because they really didn't, the server went down. A part needed to be replaced, and there was no sourcing. You couldn't find it. It could have been three weeks and they still couldn't have found the part. No matter a blank check was given, it just didn't exist. So they had to completely rebuild their system on something that was dead. They were down for two weeks. I mean, what's two weeks of your systems being down worth at your business? That's insane to me.

Well, 100% to kind of the pandemic thought there. We had a client who basically was going through the we can't get laptops anywhere. So they drove to Office Depot and bought $5300 laptops and sent their people home. Every single one of those laptops was replaced within sight of 18 months. Those slow laptops caused a couple of different problems, right? They were slow, they fell apart, they failed, and they had to be replaced anyway. It's kind of the downside of being inexpensive. How much time is it taking of your employee for it to start? How much time is it taking for them to do the job? How much time is it like when are you going to need to replace it? The lifecycle on an inexpensive piece of hardware is going to be much shorter than something that's going to be a little bit better.

Build the quality typically combining the two knowledges of how technical that work in this situation. You have old hardware, incorrect hardware, take time and figure out what you need for hardware. Do that testing space plan and then give it a try, give it a run, see what actually works. You have a test user beside to build that standard on similar to old.

Hardware in my mind is old software or out of support software from a vendor. So for example, like Quickbook or Intuit only supports the last three years of QuickBooks. So they support 21, 22 and 23. They no longer will support 20 or before. The reason being is because they were fixing a lot of the problems in 21 or in 20 and 21 and 22 and 23. If they keep supporting the older software now they are having to maintain 610 1520 different code bases versus the last three years. So while there's some pushback against software as a service or the reoccurring subscription for software, I also completely get it because by staying current and up to date, you're getting security patches, you're getting features, you have support if something goes wrong. That's one of the areas we also focus on a lot as a company is making sure that the software our clients have is kept up to date and is under vendor support contract. Because if it's not under vendor support contract, how are we going to be able to help them when the vendor can't or won't help them? And we can keep the environment running, but if they're running some esoteric line of business application from the early 2000s, we're not going to be able to put it on new software, we're not going to be able to install it on a new server. There's going to be a lot of pieces that are left behind that are just going to age out and not and are going to at some point just flat out die. And when they die that's going to be it.

Something that is a real life example of that happening that I've actually dealt with fairly recently here is we had someone who was using some old hardware on site and that wasn't able to link up with a cloud service they use for everyone's identity in the corporation. So they needed a way to go from their cloud identity source on Microsoft for their logins down to these devices. People could go and they could log into them and do what they need to do because these devices were so old and they weren't upgraded, they didn't have a way to natively connect into the Microsoft cloud platform. Because of this, they were required to either replace all of them with new ones all at once, which far exceeded the budget of what they had at that point in time, or which what they ended up doing is set up a bunch of connectors and cloud devices to kind of make this work, which is still a good amount of money every month. If you consider this before you run into this problem where you realize we have to do something or our operations are going to stop. I think it would have been a lot easier of a conversation to have if they had this thought three years ago when these devices started to go out of support and stop supporting these new features like Microsoft cloud support of we need to replace these. We have twelve months to do this though. Can we space out the replacement of three high value devices over twelve months? Probably. It's a very different conversation than we need this to work with Microsoft. The only way to do is replace them all at once on zero notice. Will you prove this account finance probably isn't going to.

You know, if good accountants sit there and they depreciate what you have based upon a certain number of time. For instance, good accountants will take a computer and say that they expect that computer is going to last six years, five years, whatever it is, they will depreciate that in the books and prepare finances to show budget of when it needs to be replaced. If accountants can do something simple like that, why can't you take time with your It professional and say, hey, are we prepared for this, this year, next year, fiscal quarter, however, and just do that as a policy. Before we get further in, I just want to make sure we're covering the what is topic. So throwing more platforms and different solutions that weren't intended, that's a great way of occurring. Technical debt, using a wrench as a hammer, using those apps for what they weren't intended for. Documentation. Not just documentation, but retention and validating the documents as you're going through. And old hardware, wrong hardware. What else we got gentlemen?

Yeah, I think without a specific link to an example, the easiest way I found to think about it is short term gains and long term consequences.

There's nothing more permanent than a quick fix.

Oh, for sure.

There's been more than a few times as we've been going back through and cleaning up our client environments where I've realized that I'm the one who put that quick fix in or that workaround and it's been part of what's been causing some of the issues shoes. And so it's like how do you stop short term quick fix thinking and start thinking like how is this going to impact over the next. Two or three years. And sometimes you can't know there's literally nothing more permanent than a quick fix or that workaround to meet that deadline, or because of what's seeming an emergency. It's slowing down, realizing that spending an extra five or ten minutes now is going to give you a lot better long term outcome. By adhering to that best practice, you solve the immediate problem, but that you also prevent future problems.

What's the best way of paying that technical debt and preventing it? Let's go down the list there.

Step one is identify. I think step one with almost everything as far as technology goes is stop, take a breath, look at what you have. Once you have a really, really good list of what you have, you can then start connecting the dots of sorts and think, okay, maybe we can solve this problem with this solution that we already have. You can't fix what you don't know is a problem.

There's a company I worked with, they wanted to say, hey, we want to identify processes to make some improvements, and we want you, Robbie, to do that and go around the company and find just process improvements. I mean, that could show your wage easy. I want you to go around and tell us what we can do as low hanging fruit to fix things. And the things I brought back to the team were literally a person's. Half of their job was taking tape backups, making CD copies of them, and filing them in a cabinet of all of the data sources. That was literally 20 hours a week for one person. That's all they did was make tape backups. That's astounding the astounding part is not that happened, that no one knew what was going on. No one was aware. So identifying is huge. Unless you see the actual product from beginning to end and follow the bouncing ball, you're really inept on how it could have changed even if you were in that process x time ago.

Yeah, for sure. And once you have what you have identified, don't be afraid to try new things. Kind of going back to what I was saying earlier, it's okay to fail. Something that is a relatively new thing that I see a lot of aversion to is cloud services. As far as hosting of servers in the cloud as virtual devices, the biggest pushback I see on that is taking a normally capital expense of a server, say $5,000, that lasts them for five years. That's something that's easy to understand. You take that and you say, actually, it's going to be $80 a month. Now people are like, why am I paying monthly for this thing? I could have just paid upfront for. What they don't realize is, let's say you have a normal five year refresh cycle. That's 60 months. 80 times 60 is $4,800. It's about the same as a new server. With that, you get the benefit of hosting it in someone else's data center so I don't have to worry about the hardware. Microsoft worries about the hardware. They're guaranteeing me 99.99% of the time it's going to be fine. And if it's not, they will take what measures need to be made to make it fine. It's also allowing for ease of upgradability as well. So when I have a virtual machine in Azure, for example, and I want to expand the size of the processor on it, for example, make it a little bit faster, I don't have to rebudget for a new hardware device and go buy it out front. I just say I want to move this to a faster machine that's going to support this. It takes it down for about five minutes, it redeploys it and it's good to go.

Makes sense. And it might be 20 or $30 a month more. So it's a fairly simple process. I know we were looking at that the other day for our lab environment, or your lab environment, and it's incredibly impressive how fast you can update something so far, like Windows 365, which is a virtual, it's basically a computer in Azure Cloud. You can change the license and it basically will reprovision in a few minutes and it'll take them from two CPUs to four or four to eight. And so it's very a fairly quick process to update and upgrade everyone. It's pretty amazing.

Prevents a lot of over scoping of resources as well because of that ease of upgrade. How many times do you think you've tried to scope what kind of specs a device needs? And you want to shoot high because you don't want to get someone a device is not powerful enough?

Absolutely.

Well, what if shooting high is too high and you're paying for hardware that they're never going to utilize? With something like that, you're able to start them off slow and very easily bump them up. So it's not a conversation of, Brian, the CFO needs a faster computer. Well, we just have to put the old one he's using in storage and hope someone else is going to use it eventually because we have to buy a whole new thing. It's okay, Brian. Well, I'll schedule later tonight when you're not working to redeploy your cloud PC on a faster platform. Done.

And by morning you're set.

By morning you're set.

If you're the manager, the owner, the CFO listening to this. The piece I want you to take away from at least this bit is if an It guy comes in front of you, remember that his strong set probably isn't finances. He's trying to bring to you a presentation of what he needs and here's how much it costs. Take a moment and stop and ask him, hey, what would that cost monthly and how long do you expect that to last? And suddenly the light bulbs will go off. If you have someone that really isn't money focused, but a solution focused, it'll be just like you said, five grand for five years or $80 a month, which would be slightly less, and you get more out of it.

And that's a really good point, Robbie. That is one of the hardest things for myself personally to transition, is trying to have business outcome conversations with clients versus, hey, you need this really cool thing. Well, they don't care. Why does this security tool benefit the company? Why do they need the new PC or server or switch your firewall or whatever? Well, have a business outcome that explains why are standards important for the organization? Seriously, as a CFO, if you're talking to your It team, ask them to help develop business cases and then work with them to develop business cases on why this is important, because they probably don't understand how to speak business and finance to you. Help teach them how to talk to you and explain what they need.

You hired a guy with expertise, right? He's expertise at making sure that the systems stay up, everything's working. If you hired a managed service guy or if you have someone internally, you are a business manager, that is your expertise. The It guy might believe that he doesn't need you to do his job, but he needs to be able to milk the information from you to know what's that business outcome, what is the end goal when he's just focused on making sure it works? There's sometimes two in the weeds, and that conversation needs to go back and forth between both of you.

That to the It guy sitting on the other side of the table, to the CFO, shut up and listen. Too many It people in this industry will not shut up and listen. And they're so set in. This is how it's going to work. This is my way or the highway. We're doing it this way or we're not doing it at all. Well, you can't do that because you're not the expert in that field. I always tell people when I was working help desk calls, a very common thing I would hear from people is, I feel stupid. I'm a lawyer or I have a PhD in something and I don't understand computers like this. I wish I knew computers like you. And my response would always be, I don't know the first thing about being a lawyer. That's not my area of expertise. You can't ask me to file a court case because I'm not going to know what to do. My whole thing is computers. Everyone has their strong suits, and people need to realize that. Ask the right questions, and once they ask it, listen to the feedback, start a dialogue.

Even in my job, like the same lawyers that you're talking to, I'm talking to when they put in requests, I want this. You have no idea why, so you just up and do it. It's nice to take a moment, especially with those particular customers and say, hey, what do you want out of this? What is your goal? If you could do this and snap your fingers and make it appear, what are you looking for in your business solution? And then it completely ended up being something entirely different. It's because they were trying to interpret what I needed and I was taking their request. That can go both ways. Take a moment. What do you need? And then I can bring a solution.

Listening first and to loop that back into technical debt. That is one way you can get technical debt, by not asking that question. When someone requests installs on my computer and you buy a software and you install it well, what is that software doing? Is this only one person using it? Are we adding support for like, a single device? Or could we have had a conversation with them and say, you know what, this could fit totally within the wheelhouse of the software everyone else is using. Let's get you on board that. Let's train you here. Let's not try to throw more software at the problem like we were talking about earlier.

Even if something is menial's licensing, I'll get a request saying, I want this email address. Go pay for it, go buy the licensing, take care of it. Whoa, whoa, whoa. What do you need the email for? Well, when they email, I need to see the email. Okay, can we put that as an alias? Cool name at your business, goes to your email. That doesn't cost you any licensing. It does the same thing you were looking for, but I know how to do it while it's included in your.

Plan or three people need to get an accounting email. Well, do they need a distribution list or do they need a shared mailbox.

Which are all included actual money up front, right?

It's saving you 1015 $20 a month per mailbox. Just because we're trying to understand what you want and what you're trying to accomplish rather than just doing what you say. And so a lot of it is just interpreting. A business owner's job is to interpret what their It professional is trying to do. And an It professional's job is to listen and try to interpret the business need to technology. And so both sides need to kind of slow down and listen and then try to think through the business case and the technology use for their business. An example of technical debt. I'm a good example of it because I like buying software. I'm a big fan of having all of the tools. We brought on something called an RPA robotic process automation. I know some alphabet soup. I apologize. One of the key things that I'd missed in that software name was process. I was trying to automate a process we didn't have documented. Well, it's like, well, go make it do automatic things because that's what it does, right? It builds an automation platform? Well, it's true, it does. But if you don't have a process that's clearly lined out that's repeatable, how is an automation platform going to help you? It's really kind of slowed me back down into go, let's document the process that we're trying to automate first and then we can go automate it. And look at that, it's super consistent. Now we're having our user onboardings happen very consistently and very quickly. And we're going to make it even better because we're figuring out what our process is versus the overall process that they built for us. Again, it goes back to the continuous improvement mindset. Do you have a flowchart of what your process is supposed to look like?

And it goes back to identify too. You have to identify the process before you can automate it.

I don't think we've talked enough on standards yet. You want to take that one? BJ.

Oh goodness.

Again, Brian's listening. The CFO or our metaphorical manager, he wants to know he's coming from the approach that you only put enforce a rule if you need it. So why would you go enforce a rule? Like for instance, I never put hot coffee until someone burnt themselves at McDonald's and suddenly there's a rule now that I need to create. I'm not going to go willy nilly putting out rules that I don't understand the consequences. So help me figure out what are some easy standards that I can implement in my small business medium business.

Well, let me explain a little bit about how we've enforced standards in our company and why it's important for us as a managed service provider and then maybe that will help explain it a little bit more for a company that is trying to do this in house or to their It consultant. So for us, one of the things that we've done internally to really help with driving consistency is internal standards that we require of our customers. So for each one of our clients, they look and feel very similar to us. We're approaching 90 plus percent standardized. But the things that we're standardizing are the things that matter a lot to us and will streamline their service and streamline their uptime, make the client more efficient in the long run. But it's something that the client doesn't really realize. And that may sound funny, but it's things like 100% of our firewalls are the same manufacturer and use the same operating system and they have the same security services. 100% of our switches and access points. They're the same provider with the same management platform. Every single customer is on Office 365. If you're not on Office 365, you will be on Office 365 when you become our customer. Every single user is on business standard or business premium licensing. Every single endpoint has the same EDR, the same antivirus, the same IPAM, identity, privilege, access management. Thank you. I know what it means, but I lost what it meant.

The soup.

We have a lot of soup. We apologize.

We love our acronyms in it. Everything's an acronym.

Yeah. The golden spatula is actually for anytime we say an acronym, but not explaining it, but why we do that. Standardization. If somebody has a Sonic wall firewall, we're going to pull it out and replace it. We're going to put our Sofos firewall in because that's what our team is trained on.

Benefit to the end user at that point is there is no, let me get in touch with our SonicWall guy or let me get in touch with our Fortinet guy. All of our team is trained on this consistent platform, so when you submit a ticket, it doesn't matter who calls you. Everyone's going to be an expert in this because they've all taken the same training, they have access to the same documentation, they have the same certificates. We're not having to spread responsibility for platforms across the organization and benefit to us on that is it reduces what in the industry, we commonly called a bus factor. It might be a little bit morbid, but what happens if your expert in the subject matter gets hit by a bus? Who's going to take over that? Is anyone equipped to take over that? I like to think of it as I believe it was Jamie on our team who rewarded it as the lottery factor. What happens if you win the lottery and you disappear to a tropical island? I like that more than getting hit by a bus.

Positive commentary about it, though.

If your CFO or Chief Anything officer wins the lottery and goes away, do you have a plan to transition someone into that role? Do you know what they're doing all the time? Yeah.

Even if in the smallest teams, you have a team of five people, you figure that I don't need to standardize. We're a pretty close knit team. Have someone disappear for a week, see if that one person that was using that one special tool and someone else can pick it up and figure it out and then log that time.

Hey.

It took so and so three and a half hours to do the one thing that was supposed to take ten minutes, because I had to call the support company, because I had to figure it out because no one else is using this. And on her own, Fruition decided that she was going to do it this way.

So, real world example of that I ran into while I was at the conference last week. I always tell myself I'm going to mainly focus on the conference, but I always end up checking work stuff during it because there's periods of downtime. And something that helped identify an area that we were lacking our documentation and training in was when I saw conversations about someone not understanding a tool. And the answer was Brandon normally handles that. He'll be back from his conference pretty soon that told me I didn't do a good enough job documenting this, because I can't expect our team to succeed if we're not giving them the tools to do that. And documentation and training is a huge component of that, and that's not the technician's problem. I can't expect them to not only know how to do this, but know the way we want to do it if I don't provide them guidance. So that's where I have to hop in and be like, you know what? This is on me. I'm going to handle it. And while I'm handling it, I'm going to take some screenshots and document it. So next time this happens, you guys know exactly what to do. I'm going to make sure you know what to do. And if this is unclear, come back to me, let me know, and I can sit down one on one and make sure you understand this. The end goal here is for me to be able to disappear for a week at these conferences and not have any this is a branded thing. This is something only he can handle, so we have to wait till he gets back. It's, oh, Brandon normally does handle this, but we have documentation that'll show me in his absence how to finish this and fix it for the customer. And it takes a two touch problem into a single touch resolution.

1000%. Can anyone on the team pick up? And that's always our goal. Literally. My goal is that anyone on the team should be able to do 80% to 90% of what anyone else on the team could do. And Brandon is our senior It manager, so he has probably the biggest breadth of skill on all of our tools. But can every single person on our team function at 70 to 80, 90% of that skill set? Because we have good processes, good documentation, and tool consistency, we're not having to switch between five different firewalls. We're not having to deal with ten different makes or models of laptops. We use Dell laptops. We use Dell PCs. We use Dell servers. Is Dell the best for our channel? No, it's not. It's fine. Are there potentially more channel friendly providers for us to work with? Well, sure, but at the end of the day, dell is a very well recognized brand. They have very good update platforms that we can deal with inside of our automation. So we can automatically update a firmware on your laptop from our office. That's pretty incredible. And so that's part of how we drive standardization and consistency. We're not having to deal with an MSI laptop and a HP laptop and a Lenovo server. We have Dell or we have Azure. There's no real middle ground here.

Yeah. I was having a really good conversation with some other peers at this conference. It was during a breakout session where the topic of discussion was multitasking, and I won't get too much into it. But the general gist of it was people can't really multitask. Only 2% of the population is what's called a supertasker, where they can genuinely have more than one task being worked on simultaneously. Everyone else who multitasks what you're doing is you're working on task A, shifting your brain to task B, back and forth rapidly in these micro tasks almost. And one of the big drawbacks to having deal with that, or one of the big examples of it is trying to hold a meeting with someone and getting a team's message or a text message or any sort of communication from their person you're trying to focus, and someone's like, hey, can you help me with this? Or, hey, if this isn't working, or pay attention to me instead of what you're doing. And you're so much less efficient at that original task because you have to stop what you're doing. Reorganize your brain to read the message, figure out what it says, figure out what you need to do, and then go back to what you're doing in the first place. The conversation that was happening is how to reduce or how to handle it when people are reaching out like that and tell them to go away basically until you return at the meeting. And I brought the point of why are we focusing on that when the question should be, how do we make sure people aren't having to message in the first place? Where is there a proper chain of escalation when there's a problem? Why is it always going to you? And if you're getting asked the same questions over and over and over, you shouldn't be getting frustrated with your team. You should be recognizing that your team needs help in this specific area and by giving them the tools and documentation to solve the problems on their own, you don't have to worry about handling these messages when they come in because they don't come in anymore.

I think one of the best things that we can do as an organization is training.

Always learning whether it's training yourself, training others, and back to what I was talking about earlier of training others is just it solidifies that information so much more. I want to really empower people to do more training on their own topics as time goes on.

One more thing before we go on to training stop. One more thing.

I'm getting a lot of figures pointed at me.

I got to address Brian, the CFO that's listening into this, this manager, this business owner, the guy that our audience here. For a managed service provider such as us, we are your third party. We're an external source hired as your It department. You pay us, generally speaking, a monthly fee, I don't know, per computer, per person. However that billing structure is done for you. Our way that we succeed make profit margin in our business is if you have uptime and you're calling us less and you need us less. That standardization that we're asking for makes sure that we're the fastest possible to make sure that your business stays online, because that's the only reason we make money is when you call us less.

And this is, in my opinion, one of the areas where we end up being fairly differentiated from a lot of our client, our fellow competitors. We don't do live answer help desk where somebody just they have ten techs on a bench that are just waiting for the phone to ring, and they're just like, picking up phones all day long. That's not how we operate. We operate on a dispatch methodology, but at the end of the day, we also do a lot of triage around understanding what's the actual urgency of the ticket is. It the entire department's down, the entire company is down, versus I can't print to one of my five printers or I have a slightly frustrating issue. Our job is to know your organization inside and out. So that way, when there is an actual real problem, it's fixed in a very short time period.

Right.

That's why we're saying is treated in the same level of urgency.

That's why we're asking for standardization, is we want to be able to make sure you're up, you call less, we can do it at a dispatch level. It seems like we're asking for well, you got to stick with Dell because that's what we sell, and we don't want to deal with it. And it seems like laziness. It's not. It's uptime, it's education, it's training, it's your users training, It's support. It's so many things paying that technical debt up front that even if you're not using a managed service provider, your one, your two It people in a closet, in the basement want to have that same level. Consistency of consistency. That's why they're doing it. They're not going to have an HP, Acer, whatever you feel like house. They're going to make sure that they can run on those two people in the basement and be able to have a weekend and not come in.

If emergencies are the bane of an It provider's existence, but they're also the bane of a client, right, because it means you're down. It means your people aren't effective. It means there's just generalized frustration with It and technology and the company standards solve emergencies because it either prevents them or it makes them extremely easy to recover from.

So back to training. I derailed. Forgive me, Brandon.

Go ahead.

You're fine. No, that was pretty much the end of the point. And I do want to actually I think it's a good pivot into what BJ just said about standardizing disaster kind of recovery type stuff. When I was at this conference, I'm going to be talking a lot about this conference.

What was the Hype conference?

The conference was MSP. Geekcon. There is a community online for managed service providers MSPs called MSP Geek. It's been around for ten years now, actually ten years just as of recently. It was right around the conference start when they actually lined it up like that. Its whole thing is a community of peers in this industry all elevating each other. This is the first thing they put on the conference. It was a lot of learning, a lot of shenanigans. They had open bars. So let your imagination run wild of a bunch of tipsy. It guys in the same room together. There's some stuff going on that it was fun. But something we learned from there was in the vendor hall they had a company who focused on backup and disaster recovery. And one of the big selling points they had was the standardization and automation of restores. Where you have a senior It person write the policy first off of how a restore process should go, what systems need to go up first, in what order, what kind of networking do you need? What's the plan if the building burns down compared to if just the hardware stops working? And you pre build these policies when you have the breathing room to build them when disaster hits and everyone's scrambling to get back up in time, because you've standardized the policy and have written this automation runbook, all you have to do is just click run on the scenario that best fits. You don't have to think about it. You don't have to worry about making mistakes because you're rushing, because it's a real emergency, because you pre planned and standardized this when you had the breathing room to do so properly.

This kind of goes back to the beginning of the conversation where it's always improving. So we are using one of the single best backup platforms in the industry in my mind right now. And we're seriously looking at that new other provider because of that runbook restoration, simply because it allows us to be more proactive and thoughtful around what happens if a client goes down.

It goes back to the bus factor too. Because if the super complicated but doing okay platform is so complicated that only one person is able to stand up a restore reasonably, what happens if disaster hits and they're not there? You want to be able to have that senior person identify and write the policies and then empower anyone less technical at the company to kick that off at any point in time they need to. When you have a disaster occur, would you rather try to figure out what you need to do to restore it as the disaster is happening and everyone is panicking to a certain degree? Or would you rather have a book that you have that says here's step one, two, three, you're going to follow. Don't think about it, just do it. We've already thought about it ahead of time when we can sit down leisurely around a table with a cup of. Coffee and talk about it. That's really where disaster recovery incident response shines. When you have that level of preparation.

One of the consistent ways that you can kind of manage and pay down your technical debt is realizing that you have one and then actually setting aside budget to continue paying it down. As Brian the CFO, go talk to your It team and ask them what technical debt they see in your organization that's causing you the most risk and then start working on that. We looked at a disaster recovery company as a prospect a couple of years ago, and they were running a FileMaker ten database. Mind you, at that point, FileMaker 19 was out. I explained to them how this was one of their single biggest potential, and it was running on a Windows XP machine, no less a desktop. It was impressive that this thing was still running, and unfortunately, their It company was letting them do it. That is their single biggest. Other than losing QuickBooks, that was their single biggest business risk. And then when I presented getting this upgraded and changed and moved over to 19 on a new server, it was like, well, that's too much money. Well, but when this goes down, chances are you're going to be down for a week or two or three while you try to rebuild this FileMaker Nine database. Going forward, one of our clients is using Sage 2020. Sage only supports two years, so we're starting to get end of life emails from Sage advising we need to upgrade. So I'm going to have a conversation with the CFO of this company in the next week or two and say, hey, we really need to set aside some budget to get Sage 2020 upgraded to Sage 22 or 23. Because if it's not under support, if something goes wrong, your time to restoration goes way up. If I can't call support and get help, you're going to be in a lot bigger world of hurt than just setting aside the 20 $30,000 to do the work. So, Brian, go talk to your It team and find out what is your number one and number two business risk and then start working through paying that down.

And to the It teams out there, you need to be having these conversations with your customers, kind of like how you said the old provider for your example was just letting them run. It is. It's hard to have these conversations where you know you're going to be shoving a wrench in their operations and you know it's going to be a difficult conversation where you can't just say, I want to do this, and they're going to go, okay, you're going to need to justify yourself. You're going to get a lot of hard questions, it's going to be uncomfortable. But if you're not doing this, I think you're doing it to service to your customers. These conversations need to happen. It's not going to be fun for us to go to the CFO and say, hey, you need to budget at a decent amount of time and money to upgrade your systems. It would be a lot easier for us just to pretend it doesn't exist and stay the course and keep letting the monthly fee roll in. But that's going to add to their technical debt, which is going to add to our technical debt, which is going it's not if it's going to be, when does that go kaboom down the line? And when it does go kaboom, how hard is it going to be to fix it? A lot harder than if we just had the conversation up front of it's going to suck. You're going to need a lot of time. You probably need to budget a little bit more than you would expect, but that's why we do it in a budget beforehand. We're not going to wait until it falls over and then you suddenly have to pull this money out of your back pocket all at once. We're going to say here's when this is going to need to be moved by you're, the CFO. You're really good at finances and planning. We're going to give you this information so you can properly prepare for this and make sure you're ready. So when we do this move, you're not going to have any sort of shock on price or timeline because you've already prepared to spend this time and money to fix it.

Well, it was something, and this is not really related to anything on our side, but I saw an MSP posting in an online chat group that they had 350 Windows Server 2012 R Two S left across the fleet. And let me explain why that's bad. So Server 2012 R Two goes end of support from Microsoft, and that means no more security patches. That means no more security patches. So that means if there's any vulnerabilities found in that operating system for the next from here until the end of time, microsoft's done supporting it. Because 2022 has been out for over a year now, 2019, we need to start looking at replacing our 2019 servers here pretty soon because we're already four years out of that. So having a 2012 R 352,012 R Two servers is an incredibly huge business risk for both the MSP, because now they have to figure out how to get 350 servers upgraded between now and July. And it's a big risk for their clients are at a big risk because if they have something that's publicly facing or somebody gets into their environment now, they can laterally spread. That's some gigantic technical debt right there.

An example probably more applicable to the average business person out there is Windows Ten. Windows Ten is going end of life October 14, 2025. As of the time of recording. That's over two years away. But consider you have an organization of 100 computers. Are you going to wait until October 2025 and give yourself two weeks to suddenly try to upgrade all these systems or even just not upgrade them at all and open yourself up to the risk of untold cyber attacks in your network? Or are you going to start having the conversation now of we have two years to plan for this. Let's start slowly upgrading systems. Let's start with some low impact users where if they have issues with this rollout, they're going to be easy to fix. We'll start with them and then we'll move up the chain to more and more critical people. So by the time we get to those mission critical systems, we've hammered all these bugs before, and we can just take a leisurely stroll to get to that point.

100%. Speaking of which, we need to put that on our timeline to start having that conversation. Yes, I'm going to be doing account management reviews over the next two months or so, and I'll be bringing that up in our conversation plan because that's probably 500 and 5600 computers we need to replace over the next two years, not counting what we onboard. So that's a substantial amount of work that we need to start prepping for on our side.

We're already supporting I was going to say, I think we already have quite a bit of it mapped out.

Yeah, we're already running Windows Eleven internally on a lot of our systems. I know some clients of ours, especially those who are getting new systems, are just having them delivered with Windows Eleven, which is totally fine, and they're not having issues. And for these companies, they would rather deliver to someone whose job output is not less consequential but less time critical. As someone like a receptionist. A receptionist computer is going down is going to be a lot more painful for a company than someone in accounting's. Computer going down for a little bit. So they'll give the accountants a Windows up on PC and they'll find out this software is acting up. Okay, well, let's spend the time to fix it for accountants, and then by the time we get to reception, then we're going to have that figured out so we can just push it out to them and not have to worry about that.

Aren't you proud of your team? Already working on it. BJ proud last.

My favorite thing to do is for BJ to be like, you need to start looking into this. And I can be like, I already have. Here's our plan.

Right? Already thought about it.

Last note for Brian, the CFO, the manager that's listening in. The metaphor that we have, if you're listening in, one last point that I have is training. Paying technical debt is also keeping your employees up to date. Just like Brandon got sent to a conference that's going to empower the rest of the team, not just Brandon, on making sure we're paying down intellectual technical debt to keep ourselves on top to continually growing the company and paying the technical debt forward as we plan and do things. Your industry doesn't have to be a tech conference do your industry. If you are a lawyer, you have to do things to keep up to date with your state and federal laws and keep up to date with new court cases that are the new defaults and standards in your industry. That's one industry where you can pay down your own business debt. I say technical debt, but your own business debt forward to make sure that you're staying relevant, not just with technical systems as well. And we have to do that. So if you have an It guy and it's not an MSP, if he's asking to go to a conference, I don't understand why you wouldn't want him sent there.

Oh, absolutely. And something that Peach actually told me about this morning is some of the feedback he's got from people that are seeing me. And they were like, wow, Brandon's always sitting in the front row taking notes. I'm surprised that he's paying this much attention. And I'm like, yeah, it's an investment. I know it's an investment to send me to these conferences. It's not free. There is the cost of the price to actually get into the conference. There's the hotel stay, there's the flight there, there's the reimbursement for food and stuff. I need to return on that investment. Best way to do that is to engage and learn and not just keep it to myself, but then think, okay, how are we going to train our team to spread this knowledge? We have our monthly staff meeting coming up, not next week, but the following week. I am going to ask to have probably a decent chunk of that to recap what I learned at this conference, because it's not going to do the company any good if I keep it to myself or if I'm not paying attention there.

While I do absolutely think you need to make sure you keep your It guy trained, or you're making sure that your It team is staying on top of new technology, something else to really think about is actually getting real PC computer training for your staff. Because we're getting to the point in life where I don't know, computers or I'm not good at computers isn't an excuse anymore. Everything we do in life is tied to working on a computer. And you need to have your team trained on being useful. And that sounds maybe mean, but that's not the goal. Your team needs to know how to use Excel and Office, the different browsers. These are pretty basic things. And if they don't know how to use these tools, then they're a really big risk and a really big cost to you. So put them into an Office training class, put them into teach them how to use the tools that you have.

Onboarding like we talked about in a prior episode crucial to pay down that technical debt. You have a literal person that doesn't know what they're doing that onboarding training, even if it's a crash course, is much further in that employee debt. You really wouldn't think of, even in the Minnesota Workforce Center, the place that's supposed to help you if you don't have a job, where you have to file unemployment, you walk in and let's just say that you're a janitor. Something that you wouldn't normally think about ever touching a computer for the first question they're asking everybody that walks in, even a janitor. Do you have computer skills? No. Okay, here's a class to get some and then come talk to us. They won't even work with someone at the workforce center, a government agency to help people get jobs. You don't have any computer experience there. Right there. Start there, come back.

Yeah. And ask your It provider to see if they can give you this training. I would be more than happy for any of our customers to take an hour or two out of my day to go down and teach them about basic computer stuff. It's not going to be a waste of my time. Heck, I'll bring coffee with me because I know that when we train and empower people to solve issues like that, then it's going to be less work on the It staff team, too. That's not unique to it. I mean, if you're in a position where, let's say you're an accountant, and while employee B doesn't necessarily have accounting as their primary duty, they still need to interact with your accounting software. Take this time of your day to sit down with them for an hour and just be like, I want to make sure you understand how to use this software as efficient as you possibly can and just watch them work. You might pick out like, oh, you can save a few minutes doing this or a few minutes doing this. Found a chart that was actually sent to me at this convention about time savings and stuff. So let's say, for example, if you do something 50 times a day and it takes five minutes longer than it could in time savings take that. Five minutes isn't a huge amount of time, but you multiply that over five years, that's nine months of sitting and waiting for something to happen. As this is loading. Can you imagine paying an employee for nine months to sit at their desk and just cross their arms and wait for a loading bar to go across? Like, no, it adds up. Find the ways that people could be improving their process and identify it to them. And you're not going to do that unless you sit down and listen.

Even the note that Brian, if you're listening and you have a new user coming up and you have some onboarding and training, it still helps to talk to that It professional. If it's into house, it managed, service It. However, we have a few customers that when they onboard and send us, hey, we need a new user login. We need this computer set up for this user. They also ask, could you set up a 30 minutes an hour with that new user and explain how to log in, show them how to do their multifactor authentication and show them how to open their applications. Generally, we don't hear from new employees because they're already on their feet running by the time they're done talking to you. Why wouldn't you do that with your It guy?

Utilize the person we like to teach, typically. And if you have somebody that doesn't like teaching, then find a new person.

All right, so the list that I have written down along the way, how to pay and prevent technical debt is number one. Identify and build a list. This is not necessarily in order. Don't be afraid to try new things. Test before the time comes when you're forced to either buy software or old hardware. Identify standards, laptops software, ways of doing your business. If everybody's on the same page, generally things work a lot better. Check the lifecycle of things. If you're expecting five years out of something, document it. So then when you hit the two year mark, you can start preparing to replace it or find a new strategy and stop and ask, what's the outcome? Don't just assume, this is what I need. Pock and say what you want as a result, especially with your It person, they have a lot of different ways to help save you money and pay technical debt up front. And lastly, don't feel afraid to train your team, whether it's onboarding, up front, or keeping the core people up to date by sending them to a conference, It, or otherwise.

I think that's a really good wrap up. I don't know if we need to talk about it much more than that. What I would ask is, if you have any questions about technical debt, please find me on LinkedIn and send me a message or comment on any of my posts. We would love to take questions just to help drive down that technical debt. It's what we do all day, and so we want to know your thoughts around that. And maybe in the next one of these next episodes, we'll figure out a way to create an email address because we are an It company.

Oh, no. Check the show notes and the website biz.

There we go.

Businesstechplaybook.com. You'll find our contact information there as well.

There we go. Awesome. Robbie, really appreciate you kind of spearheading us, as always, and I think we'll be done for the day.

And thanks for joining us again, Brandon. I know you'll be on more. Until next time.

Till next time, guys. Thanks for having me on.