Latest / You've Been Heard / 454- Earn Your Seat Beyond Technology w/Scott Holleran

Transcript

454- Earn Your Seat Beyond Technology w/Scott Holleran · You've Been Heard

• 0:00
  Speaker A: The way I always tell my teams when I talk about nobody wants to say no in it. And I get it, I'm on the same page. But I used to tell my commander and the army like, hey, I can get you anything. You want to talk to Mars, we could talk to Mars. But like this is a 10 billion right 10 year plan. And I think it's giving them that cost and really walking them through. Hey, I understand you want to bolt on a new erp. Let me talk you through what that really looks like and whether or not that's a good idea and help them do the ROI analysis of if it takes this long and cost this much money, is that really additive to the business or are we just dragging to gain some marginal improvement on the operations side? And so allowing them to help make that trade off for you, I think gets a lot better result than saying no or too hard or too long. Right. If you frame it back into that business decision and what you're trying to achieve as an organization.
• 1:01
  Speaker B: After talking with IT leaders, I've come to discover one thing. And it's the same thing. You know, it's the same thing everyone else knows, whether they want to admit it out loud or not. Nothing gets done in any company without it touching it. Nothing. But here's the thing. When everything's on fire, when nothing's working, when the ransomware hits, when the whole business grinds to a halt, it is completely indispensable. You're the most valuable asset in the company. But when everything's running like a well oiled Tesla, you're a line item, a cost center on a spreadsheet. You've done the work, you've built the career, you've earned your seat at the executive roundtable. But having a seat at the table is one thing. How much nicer would it be to actually be heard? This is you've been heard. Welcome everyone back to you've been heard. We've got Scott hollerin on today. And I mean, I guess we were just talking about fire protection and which is near and dear to me. So you know, fire protection is important. But even more is in alignment with the metaphor of putting out fires. It people put out a lot of fires and I'm sure you've had years and years of putting out fires. Hopefully not too many ransomware attacks. Maybe we'll sprinkle in an AS400 in there ERP system or two. How did you get into this mess? Which is of course not a mess, it's a digital transformation. It's everything is a well oiled machine right now. There's absolutely no projects on your plate and you everything's running like a well oiled machine.
• 2:38
  Speaker A: Yeah, I fell backwards into these PE backed rolls and so took a pay cut to do the first one and found that I really loved getting my hands dirty and being really close to the metal, essentially having small, small teams. And so this is my third PE backed group now and so love doing the integrations, taking it kind of from real bare bones mom and pop shops and turning into an enterprise that is hopefully ready for this street or to be sold on.
• 3:04
  Speaker B: Yeah, I hope so too because I don't the statistics of like private equity and where they invest money and hopefully we've got a big home run here. You have some military experience which is not uncommon in the IT world and I think that for some reason it's not uncommon because I don't know, maybe you've dealt with a little bit of stress before and people yelling at you which goes hand in hand in IT and makes it that much easier. Any parallels there?
• 3:30
  Speaker A: Yeah, no, I mean it's definitely true. Whether it's just the stress of IT or I think organizations that tend to speak a common language and so you get this capability of moving fast, having a common set of definitions and then really driving towards the same answer as a team. I think IT departments tend to operate more as a team than others. They know they're interdependent on each other as the data moves or as people work through systems. And so I think. Yeah, definitely a few parallels there.
• 3:58
  Speaker B: Awesome. Okay. As you grew up in it, at some point you became, how do we say, ability enabled to speak with human beings that sit in executive management seats or around the roundtable and various different levels throughout the company or you wouldn't be in the position you're in. So how'd that happen? Any advice for other people that might not be in a leadership position, that are potentially listening to this show or are in a leadership position, but when you move from company to company, every. It's almost like every situation is different. How do you talk with the end users and make them love technology and use it and train it well and all that stuff?
• 4:41
  Speaker A: Yeah, yeah. I mean I think people will say, hey, get out where the business is. And that's what I would say too. But I would like specifically for me, I started as an infantry guy in the army, so ground powder, no experience, switch the signal because I was like, this gotta be easier than what they're making it look like, and it really is. And I think that's what it comes down. Like, you have to go understand what the person you're serving is trying to do. And it becomes so much easier to do it if you know the point of what it is really driving. It's not data movement, it's technicians testing and inspecting fire alarm equipment for us. Right?
• 5:16
  Speaker B: Yeah.
• 5:17
  Speaker A: If you've never gone on a ride along with your frontline team, there's no way you can really understand what you're trying to do to serve them.
• 5:24
  Speaker B: It's almost like this is advice for even non IT leaders, because I think there's probably a lot of leaders out there that are actually frustrated with their own IT leadership. What would your advice be to them to advise their own IT leaders? Is it, hey, man, you got to get out there, you got to see how we do our job every day. Like, what is it? Because they may just sit in a room and be building something on Claude and think they're automating something really, really awesome. That's obviously in the current century that we're in, trying to make AI do something. And they might be just spinning their wheels.
• 5:57
  Speaker A: Yeah, I mean, it definitely is. It's get out and see where the work is done. If you work in manufacturing, walk the floor, right. If you're familiar with the Toyota way or Lean or right. They all tell you, go to the Gemba, get out, see what the work is. And if you want to earn the right to sit in that business leader staff meeting and have some real context for the problem they're dealing with, you have to actually go see the problems that are happening out there that they're having to support and work through as they run the business.
• 6:25
  Speaker B: All right, so let's bang on a few examples, or give me a couple examples, or give me an example of where, like, you knew what the problem was, or you knew what the challenge was, but it was just difficult to solve with it, or how did you come about it? Or is it a lot of kind of sometimes fail forward? Other people have said, we'll come with good, better best options, and for whatever reason things don't go as planned or you've walked the floor, you found the problems. How do we actually now use technology in a way that actually is beneficial? Do you have to have a certain knack for it?
• 6:54
  Speaker A: I mean, a knack never hurts, right? But I don't think that you can live life not building systems around these types of problems. And I think it actually has spent a lot of time doing that. If you think about why we moved from waterfall to scrum and sprints, right. This is the same problem in that like work with your user frequently, actually understand the problem, don't build so much that you have a huge investment in something that doesn't solve what they need. But I think we forget the purpose of why we moved to two weeks. Yeah, we don't actually go spend that time. We think we understand the problem. We do 2, 3, 4 sprints and they're busy so we don't worry about the fact they didn't make it to our scrum meeting. And then you really are too far down the road. No.
• 7:32
  Speaker B: So let's break that down then because you just made me think and based on my own problems that we have going on in our business and kind of like, let's solve one challenge at a time, which could be how do you produce a podcast? And our number one constraint might just be delivering more value to the people that have been on the podcast. And that's just the number one thing. So that makes me think, oh, waterfall might actually be a good solution here. Don't go to the next thing until that's done. Is there a time where waterfall is best right now? Or should we have multiple people working in parallel streams doing things? Or does that actually confuse our world? Should we have everyone all hands on deck working on one thing at a time? Your CFO doesn't want 47 Internet bills. We help IT teams consolidate multi location Internet into parent child billing with coterminous contracts while still buying wholesale from the best providers. It gets control, finance gets clarity. No disruption, no sales pitch. Just go to you've been heard.com and answer the seven questions to simplify, streamline and save.
• 8:41
  Speaker A: Yeah, I think it, it comes back to do you have the map? And then you talk about the options. Once you have an understanding of where you're trying to go and a little bit of the path to get there. I, I see it all the time where you've built the whole thing and then you realize like this real core component way earlier that you needed to solve for didn't actually get solved. And I think creating all that rework is a waste of time. And if you're taking the time to really lay out the process, we do a lot of lean mapping in my world. And I think what you always learn when you do that for three days is somebody in the back of the room you say, oh, this is how that works. And then somebody on the other corner says, well actually, and it's like 17 more steps than you thought it was. Okay. And so I think you just really have to connect every once in a while those consumers with the people that think that they understand how they're getting the product.
• 9:30
  Speaker B: No. So I think this is really good because this should be the show about coaching executive leadership. So do you think most executive leaders know what lean mapping is?
• 9:42
  Speaker A: Too few for sure.
• 9:43
  Speaker B: I mean, but how would that benefit them when it comes to any other project that they're doing? Or do they just call it something else? Do they just call it the whatever, the four quadrant, whatever, seven step whatever method? You know what I mean? Is it just the same thing, just morphed into something different?
• 9:59
  Speaker A: Sometimes it is. I mean you'll hear it called value stream mapping and some of those other elements, but I think maybe back to where we started a little bit. If you don't have a common vocabulary for an understanding of what it means, when you're talking amongst yourselves within a team, you're not doing the same thing no matter how similar it is. Right. And one person thinks that this is a quick, let's lay out a swim lane and the other person's like, no, this is a multi day effort to really understand our process and our business and what we're trying to drive out of the. And. And you got to size those right. For the scope of the problem you have too. Right. Not everything needs several days of effort from a 10 person team.
• 10:34
  Speaker B: And then this now is quite clearly to me the gap between technology leadership and probably the rest of the C suite leadership. And this is not about like us versus them or them versus us or anything like that. Well, the shows you've been heard, so why do people not hear it? Leadership sometimes. And I think that entire lean mapping, all of that gets kind of maybe falls into the ether or the unknown of executive management because they think, why aren't we going all in on AI? Like vastly oversimplifying the thinking. We're going SAP. Yeah.
• 11:12
  Speaker A: Just a new tool. Right.
• 11:13
  Speaker B: We're going SAP. Okay. That's it. The guy convinced me. It's awesome. That's what we're doing. And there's just way more to it.
• 11:21
  Speaker A: Yeah.
• 11:22
  Speaker B: And so then now I can understand why actual mid market companies and larger companies move so slow because it's difficult for me to get anything done in a year. How do they get anything done in 10 years? It blows my mind sometimes. So anything else that you want to go in depth on there as to why? I guess what would be your tips for enlightening Executive management about the processes and complications of technology and how do we get heard more.
• 11:52
  Speaker A: Yeah, I think there's two components. One is speak their language. Right. That's part of the going is seeing how it works. If you can talk to them about how it would be hard for them to change their process, it's a lot easier to convince them why your process is difficult to change as well.
• 12:08
  Speaker B: Love it. Yeah, love it. It's like just think about changing all of the sales pipeline process and how you go from first appointment, second appointment to whatever. I got it, get it. That's beautiful. I don't think anyone's ever said that mention changing their process.
• 12:25
  Speaker A: Yeah, I, I think that's biggest one to get empathy because it gets them in their own mindset. Right. They're thinking about the problems they've dealt with before and then they can suddenly relate to the fact that another executive is bringing forth like, hey, this is going to be a challenge, it's a big effort. And once they understand that, it's way easier to get buy in or resources or some safes to make the decisions that you need to make.
• 12:46
  Speaker B: Okay. Has there ever been a request from executive management that seemed simple to them and it was kind of like, hey, we're doing this, I need this done. And you knew that it was an absurd request and you convinced them otherwise.
• 13:01
  Speaker A: Yeah. The way I always tell my teams when I talk about nobody wants to say no in it and I get it, I'm on the same page. But I used to tell my commander and the army like, hey, I can get you anything. You want to talk to Mars. We could talk to Mars. But like this is a 10 billion right. 10 year plan and I think it's giving them that cost and really walking them through. Hey, I understand you want to bolt on new erp. Let me talk you through what that really looks like and whether or not that's a good idea and help them do the ROI analysis of if it takes this long, it costs as much money. Is that really additive to the business or are we just dragging to gain some marginal improvement on the operations side? And so allowing them to help make that trade off for you, I think gets a lot better result than saying no or too hard or too long. Right. If you frame it back into that business decision and what you're trying to achieve as an organization, how many projects
• 13:56
  Speaker B: do you feel is too much? It depends on the size of the project. But there's a balance between again, saying no and not being the department of no and being Able to balance actual projects that are worth taking on and accomplishing the goal.
• 14:12
  Speaker A: Yeah. I mean if you don't have a PMO and most companies my size do not, frankly. Right. It's. Let me show you, here's what the work is today. Here's the capacity to go do other things. Let's stack, rank and see what fits and then add an extra one. Because you always need more work than you can actually do anyway. It's. It's a good policy. People will surprise you with what they figure out, move faster on and where you get stuck and you end up having to delay. And so I think it's fill the capacity maybe then plus one and then see what you can do with it.
• 14:43
  Speaker B: How do you measure how much your team can do and handle?
• 14:46
  Speaker A: I think it depends on the organization and the dev org. You're looking at your Sprint velocity and some of that in an operations org. Right. You can look at your tickets and your troops task and some of that. But I think a lot of times as a leader, you've done this for a long time, you get a little bit of a gut feel for we're actually at capacity and I have to say no to protect the team versus, hey, we're running hard, but we've got a little more in the tank.
• 15:12
  Speaker B: Gotcha. It just makes me want to ask the question, like, what does hard work look like to you? Because some people's version of hard work is different than other people's version of hard work. And I think a lot of people, depending on the organization and where you're at in life and what you're doing and how happy you are and what you want to accomplish, your level of hard work status, or what you would say is hard work is different than what someone else would say is hard work.
• 15:40
  Speaker A: Yeah, it's a good call out because I like to push myself harder than my teams. I do think that we owe them some real work life balance. They didn't sign up to be on all the time the way you do as a leader sometimes. But I do think there's. I always say, like I'm a big fan of laziness. Like people that don't want to work so hard, they want to figure out a better way of doing it. So there's so something about constraints and having enough work that it pushes you hard enough to really think differently about the problems and not just think about how hard can I keep running into this wall because I've got the time to do that.
• 16:15
  Speaker B: Yeah. And I also think it Depends on a person and how. I guess well organized they are. Also, I. I mean. Cause like, I think probably based on what you said, you might be a bit like me. Meaning it's never enough. Like, things are like never really good enough. It's like there's really no end.
• 16:34
  Speaker A: Yep.
• 16:35
  Speaker B: On the flip side, the people that might not know what hard work is, I say we do the opposite to them and make them work 30 days straight. There's like an Alex Hormozi thing where he's like, he's like, if you really want to know what work hard work is, he's like, I want you to work 12 hours every day for 30 days straight. Force yourself to work 12 hours every day, 30 Day street, and you will be shocked. You will then know what hard work is and you will be amazed at what you could get done. Now, can we really ask all of our people to do that when we're probably not paying them enough or anything like that? No. No, we cannot. They just tell you to go pound sand, get lost. I have a feeling that his strategy is just pay everyone like four times. Kind of like the Netflix thing. We go recruit like the top 10 best software dev guys and just pay them like 5 million a year versus having like a hundred guys and paying them 300 or whatever.
• 17:21
  Speaker A: Yeah. What I find for that scenario though is if you haven't given them a way to determine success at the end of a day, at the end of a week, at the end of a month, you're really missing out on an opportunity to figure out how close could they get. Even if they're not driven to crush everything, they can still be a great worker. That if they have great priorities and understand what success looks like, I think they will often surprise you with how far they'll get. Especially if you're not paying them forex, you're paying them what you can actually afford. Right. That you're pretty happy at the end of a day or a month or a quarter with a team that's willing to hit a scorecard.
• 17:59
  Speaker B: I like it. Everyone's heard the term like set expectations or set clear expectations before, but we should modernize that into this, what success looks like. It sounds like a simple concept that I know no one does or very few people do. So how does someone on your team know that they've been successful?
• 18:20
  Speaker A: Yeah. So one of the things we're going through right now, and I've done in previous lives, is you take every role, sit down with that team. I mean, I'll often show up with a draft, but sit down with that team is like, what behaviors make you awesome at this thing? And like you pick six, like six behaviors that you really want to say. Like, this is what expectation is. This is below expectation. This is crushing it. Right. On a service desk. Customer service. Great customer services people are just generically happy. They click the thumbs up. Great customer services get asked for by name. Right? Like that's a behavior you can talk about. Because everybody knows this help desk person that everybody wants to have when they pick up the phone. And so I think it's thinking through across the behavior. You know, on a technical skill set, hey, do you escalate to the manager every time or do you have a peer that you go to and you two work it out together? Okay, that's meets expectations. Blowing it out of the water is you actively go help other people with their tickets.
• 19:17
  Speaker B: That's it. I love it. What behaviors make you awesome? It's a great question. Although what motivates some people might not motivate another. Like, they may not care that Jim's the guy that everyone asked for for first name then, but just like, good, let him ask for him.
• 19:30
  Speaker A: No, that's true. And not everybody needs to be great at every behavior. Right? And we talked about that too. It's like, hey, if Jim is the face of the organization, that might be all right. But like, what is?
• 19:41
  Speaker B: He's a naturally outgoing, bubbly, wants to talk with every annoying person, then great.
• 19:46
  Speaker A: Yeah. But you want to be great at something. Like, what do you contribute to the overall performance of the team? What's the thing you're going to be great at that helps us be great? You're probably not going to be the best soccer player. Like, odds are somebody on your team you're not going to play in the pros. Like, what could be awesome at that your team would like, hey, you can run the whole game without slowing down. Like, that is a skill you don't have to be the best dribbler. What is the thing you can bring that is within your capability? Be great at that.
• 20:09
  Speaker B: Sure. I've been talking about for years putting together the urban dictionary of IT terms. What term have you ever used to describe a vendor that may have not hit the mark? Oh, in other words, there's a lot of times we ask people like, hey, when it comes to CSPs, vendors, MSPs of the world, like, what's your single biggest frustration, problem or concern? And usually people have some very, very colorful metaphors and terms to describe a certain type of vendor. So you either have that option or it can be. What's an IT term that you use to describe any type of. I don't know, some just interesting IT term. Like for example, herding cats. People have used the term herding cats before referring to.
• 20:53
  Speaker A: Yeah. I don't know if any of them come from it, but I use one that people sometimes tell me they've never heard before and I didn't realize. But the juice worth the squeeze.
• 21:01
  Speaker B: Yeah. You would refer to like, we're going to add.
• 21:04
  Speaker A: Should we take this project. Yeah. Should we take this on? Is it. Yeah.
• 21:08
  Speaker B: Is the juice worth the squeeze? That is going to go in the dictionary. It has not made it up yet. Another one in the past was turning the Titanic.
• 21:17
  Speaker A: Okay.
• 21:18
  Speaker B: Yeah, like, we're going to move this. Like, erp, we're going to like start doing it this way. I don't know, I could just see that. That would be turning the Titanic.
• 21:26
  Speaker A: Yeah, okay.
• 21:27
  Speaker B: Okay. Beautiful. When it comes to vendors, just to share a few. Some vendors use the Swiss army knife approach. I got to look up who said that because it was great. Meaning they try to be everything to everybody, but they're not good at any one given thing. Versus when we really just love you vendors to just tell us what do you do really, really, really well.
• 21:44
  Speaker A: Right. Yeah.
• 21:45
  Speaker B: So how do you know when to bring security? Let's just use security as an example. We could say MSP as well. How do you know when to bring security in house entirely and manage it yourself or use an MSS P. Yeah,
• 21:58
  Speaker A: I think especially on that one. It is a hard sell to think that you're going to be great at being an mssp. And it is not. I mean, while it is critical to the business, it is not core to most businesses. Unless you're in healthcare, some other regulated industry. I think same story.
• 22:18
  Speaker B: Are you saying that you think healthcare has good security practices?
• 22:23
  Speaker A: No, no, I'm saying it's core to their business.
• 22:25
  Speaker B: Oh, yeah. Yeah.
• 22:26
  Speaker A: In a way that it is. Yeah. That it is not to many others. When I was in the roofing industry, like, being secure has nothing to do with the service we provide in many ways other than, yeah, we want to be secure. We don't want ransomware, we don't want to lose anybody's pii. But like not core to what people respect about us being like, we're not
• 22:44
  Speaker B: going to get some crazy. Like, we're not going to get some crazy HIPAA violation fine or something like that. There's not people out looking to get Us and make money off us by fining us.
• 22:51
  Speaker A: Yeah, yeah. It's the same way I talk about why data engineers tend to actually be important in house rather than outsource. It's just somebody that understands your business will do a much better job as a data engineer than somebody who doesn't. Whereas security, that is much less true. Unless there's a very need for it in some odd area like we're not doing anything special on security side. We could use all the help we can get and no reason to bring that in house and figure that part out.
• 23:20
  Speaker B: Right. But data, yeah, meaning your own people are going to understand your own issues and problems and how to clean up the data and how to organize it and then apply it to things. You have any deep thoughts on data? Everyone loves to talk data. Data's like this, that. I mean it's kind of like the beginning of every discussion. It's at least the second bullet point. least if you even want to talk about AI. The first AI thing would be, is like I think the first bullet point when we talk about AI, Forgive me if I'm wrong or tell me if I'm wrong is it's not Terminator 2. Like, guys, first of all, let's just get clear on what AI is. Everybody sales, marketing, everyone else. And then usually the second piece is going to be like, okay, what is data? I would say so talk to me.
• 24:08
  Speaker A: Yeah, I mean I take data very seriously. I think it's like the number one thing that other executives ask me about is how quickly can I get this data? How long? How is this? Right, right. That's the number one aspect of what we talk about. And that's why I think it's critical to have data.
• 24:23
  Speaker B: Can you give me a specific example of how that would come across from an executive?
• 24:28
  Speaker A: Yeah, I mean you can make it up.
• 24:30
  Speaker B: It can be make believe in another industry if you can't talk up specifics. But I would love to know.
• 24:33
  Speaker A: I mean, I don't think it's any like mystery on what drives revenue and fire and life safety. Right. If you're in a test and inspect business, your goal is to inspect, find efficiencies, quote deficiencies, sell the repair for the deficiency. Right. Very easily established chain, theoretically. But like how do you actually measure? How do you know when a technician's doing well or poorly? So you have to be able to drive that whole chain of data. And the reason it's important to have someone in house to our original conversation around. Like you have to go see how the work happens is, yeah, you might think you've built that chain, hey, I can see it all. But what you don't know is they actually fire up paper form in the middle of this. So you have this whole digital system in the middle. They write all their deficiencies on paper and hand it to somebody else. You're missing a huge component of the things that are going on in your business and whether or not your data is accurate or how to describe how accurate your data might be because you have a hole in the process. And so letting data both understand that process so they can accurately contextualize it for others. But then hopefully they go back and say, hey, this paper process, here's the problem it's driving for you. And the reason why you can't drive deficiencies from a five day turnaround to a one day turnaround is you got paper in the middle of the process. Let me help you get that back into the digital system where we can see it, measure it, and take action against it from an operations perspective. And any data platform engineer that I'm hiring, that's what I'm looking for. Somebody that's interested in going back to the operator and saying, let me help you solve that problem. Not just somebody that's hoping to get five tran hooked up and sit back and make sure nothing falls apart.
• 26:07
  Speaker B: You had my mind just like going all different directions there, especially with the paper thing. So like there's a clear hole there, which is how do we find holes? It's again like shadowing people kind of looking at an entire process, like really breaking down the entire process and saying, where are their potential holes? And it just made me think, there's gotta be a ton of places that we find holes even in like a, maybe like a sales process. If you're in a sales driven process, like how many sales guys are using some of their own tools or keeping their own spreadsheets or, or doing something like that. And I think an example that just popped into my head was there was a sales organization. I can't remember the actual name it was right now, but it just came up like a roundtable, like a discussion the other day. And there was basically a group of sales reps and they're monitoring all of their like data points. Like this guy ran this many appointments, he made this many phone calls, this many leads came in. He converted this many leads to this. All the sales reps are there, right?
• 27:03
  Speaker A: Yeah.
• 27:03
  Speaker B: But the one anomaly was revenue. One guy stood out as just like every single month, like 30% higher in revenue than every other sales rep. Yeah. And when the sales manager was looking at the numbers and analyzing it, he could not see there was no correlation. Zero correlation.
• 27:24
  Speaker A: Yeah.
• 27:25
  Speaker B: It was like, okay, he's making the same amount of calls, he's doing the same amount of appointments, but he's closing. His closing percentage on the same amount of appointments was, like, just like 30% higher with.
• 27:38
  Speaker A: And.
• 27:38
  Speaker B: And they're listening to game tape. They're listening to, like, watching all the play everything, and they're just like, Couldn't figure it out. Any idea what it could have been? It's a hole. I mean, there was a hole in the date.
• 27:47
  Speaker A: Yeah. Yeah. I mean, there's bound to be. Unless they're so. That much more talented.
• 27:51
  Speaker B: But so what they found out was when they confronted him and asked him, he said, oh, yeah, I just asked for referrals. They weren't tracking referrals.
• 28:01
  Speaker A: That's great.
• 28:01
  Speaker B: Like, duh.
• 28:03
  Speaker A: Yeah.
• 28:03
  Speaker B: Like the guy asks for referrals. I mean, like. And it was. And he wasn't even. And they were like. They couldn't figure it out because he wasn't as good. They, like, on paper. And how everything looked. He did not seem as good and as buttoned up as the other guys.
• 28:19
  Speaker A: But every lead started further down the pipeline.
• 28:21
  Speaker B: Yeah. So it's like the people that are calling in for the appointments are, like, already ready to go. So I don't know. I guess the data thing fascinates me, and I would just love to figure out how we could even do it more for IT leadership and really kind of differentiate what helps IT leaders be more effective than others. And tell me why you think this is. The statistic I read the other day was that something like the majority, like, 86% of the C suite actually trusts their IT leaders to keep the company secure and to report on whatever metrics and to basically be really good operational leaders. 86%, but only 7% saw them as effective, like business leaders. And the correlation was most of IT leadership in the C suite vastly overestimates their business leadership. Why do you think that is? Meaning, I've arrived. This is my assumption. I've arrived. I have a seat at the executive roundtable. So thus, that I am here must mean it's like one of those old SAT things. This is to this. This is to this. Because I have a seat at the executive roundtable. Having a seat at the executive roundtable is to business leadership. It's because I'm here. I must have these business skills, and I must deserve the Right. To be listened to and to be brought in early on technology decisions. Because the biggest complaint that most IT directors have is I want to be brought in early on business decisions. I want to be part of the strategic aspect of moving this company forward when it comes to technology. I don't want to be brought in too late. This is a big complaint. And the stats show that most IT directors overestimate their business leadership capabilities. Would you agree or not?
• 30:21
  Speaker A: It's probably true. The questions I would ask somebody would be like, what conversations are you having with other leaders that aren't technology related? Like, are you having coffee and talking about the problems in their part of the business, not just how it relates to technology? If the rest of the C suite started looking for other jobs, like, which one of their jobs could you also cover in the interim? Like, are you actually building enough domain expertise other places that they could use your help in their own skill set? Like, or can you read the P and L? Can you talk about why indirect labor and direct labor matter differently to the coo?
• 30:57
  Speaker B: Yeah. And yeah, maybe technology isn't the answer to every problem.
• 31:04
  Speaker A: Right.
• 31:04
  Speaker B: I've just, we've realized it like not everything is like, oh, we just need to a better CRM.
• 31:10
  Speaker A: Right.
• 31:11
  Speaker B: It has been an absolute pleasure having you on the show. I feel like there's one final deep question here or something because some of the things is people would rather dig in deep and we could have had a show probably just on data and maybe it's the integrator rule. Okay. With the dawn of AI and everything coming forward, what is the role that IT leaders are going to take in the future? And what do you think is going to be different 16 months from now that no one's going to see coming or is not talking about 16 months from now. What is everyone going to be talking about that they're not talking about right now?
• 31:51
  Speaker A: Yeah. The thing I think a lot about though is I think we've over indexed on how much AI lets us do and have not understood things won't change as much as we think they will. It's nice that I can now go code a full app in a day and a half. Despite being more of an operations person and not having done anything since ADA95. The reality is my time is probably better spent elsewhere and it's still probably more efficient to hire somebody that actually knows how to code today to do that. And so I spend a lot of time thinking about like comparative advantage, the old economic concept that countries that specialize in one thing and have a comparative advantage to another should do that and then trade. I think we're going to find that these systems aggregators and the big consulting companies, they'll change, they'll be smaller consulting companies, they'll be more enabled. But I think we're still going to find that people should specialize, they should do certain things really well, and that we're fooling ourselves when we use AI to do the whole thing into thinking we were productive when we could have done it cheaper by just hiring, spending the money somewhere else and being good at what we're good at. Letting somebody be excellent at the thing they're excellent at.
• 33:00
  Speaker B: Yeah, I love that you said over indexed. That's actually the term that. That's the term I was looking for. The Urban Dictionary. We're over indexing. Over indexing on AI. Or it's like, double click on that. We should double click on that. Like, I heard. I've been hearing that one a lot lately. Double click on that. Double click on that. The arbitrage could just be we refuse to use AI to write any of our copy. We have a rule in our company. You are not allowed to use AI to write any emails. You can use it to spell check. You're not allowed to use AI to write any marketing copy.
• 33:37
  Speaker A: Yeah, right.
• 33:39
  Speaker B: But you can use it to like, spell check. It's like my kids too. Like, I showed them how to sit down, open up Claude, desktop, do projects, all that type of stuff. If you're having problems with geometry, I want you to have a Claude project open. And I want the project to be organized a certain way. That's like, help me learn this concept, teach it to me three different ways, then check my understanding, walk me through it, make sure I learn it, but don't do the work for me.
• 34:03
  Speaker A: Yeah.
• 34:05
  Speaker B: So is that kind of getting at what you were talking about? Still specializing or going at least staying deep? Maybe you.
• 34:12
  Speaker A: You tell me more a component of it. Like, you find all those people that are getting themselves in trouble by trusting a hallucination from it. Like, you should just not do things that you don't have expertise in. Like, just because AI makes you think you can do it, probably shouldn't I
• 34:26
  Speaker B: always find it like, hey, what about this? Why do I have this, like, this problem? Okay, so what's your idea then? Is that like 18 months from now we're going to have. Is that really we're going to kind of regress back a little bit? Not regress, but it's going to be back to kind of the. The law of constraint. Kind of like what we talked about.
• 34:45
  Speaker A: I think so. And I think some people are talking about that knowledge was the constraint, and now it's tokens or constraint. I think that's like an element of it, right? Which is, like, you're just allocating it differently. What you use, like, when you pay for tokens, you could have used that to pay for labor, like actual human intelligence. And at some point, like, we're gonna. Right now we're spending all of it on tokens, and we're going to pull back from that. We're going to say, like, could actually use some of that actual intelligence, not just the artificial kind in here. Like, great, it's an accelerator, but it is not the solution.
• 35:14
  Speaker B: In other words, the separation factor is still going to have to be. It's becoming so kind of bland. I just, like, I can spot it like a mile away now, at least. At least writing and stuff. And it's just really, where's the originality and Which I think everyone's going to be very, very thirsty for. So, Scott, it has been a pleasure speaking with you today.
• 35:33
  Speaker A: You've heard, this has been great.
• 35:35
  Speaker B: Thank you, sir.