Latest / You've Been Heard / 449- How CIOs Govern Change Without Blocking It w/Gabriel Chappell

Transcript

449- How CIOs Govern Change Without Blocking It w/Gabriel Chappell · You've Been Heard

• 0:00
  Speaker A: I will challenge everybody listening on this one. Your organization probably has sprawl already and you don't know it. There's individuals and small teams that are doing their own thing outside of our tech stack, maybe even on their own devices and they're using their own environments. And so if you're not already looking at that, you need to and you're not going to solve it by just shutting everybody off, they'll figure out another way to get it. So we have to look at what's the business case they're trying to solve and, and how can we solve this in a way that the company can one afford and is willing to take the risk on. So that's why I think the AI governance board is very important because you end up getting more of a cross collaborative partnership and if you don't have one of those, you need to work on it.
• 0:50
  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.
• 1:44
  Speaker C: Well, it's great to have you with us again on youn've Been Heard, the show dedicated to technology enthusiasts, code currently steering their organization and the aspiring leaders working towards their own seat at the table. Gabriel, a huge welcome to the show. We're so grateful you carved out some time to dive into the trenches with us today and share your experiences with our community. Over@viewbenherd.com our guest today is Gabriel Chaffell, Chief Information Officer at Fabrica Inc. One of the things that stands out in Gabriel's executive playbook is his ability to drive digital modernization and operational agility inside a complex global wholesale and distribution environment. Leading technology in an enterprise dependent on intricate supply chains, logistics and high velocity business systems requires balancing rock solid infrastructure with continuous modernization. So I'd Love to start by handing over the floor to you. Could you introduce yourself to our listeners and share a bit about your path to cio?
• 2:53
  Speaker A: Thank you Mike. Yes. I've got a very diverse experience that's kind of led me up through my path and my resume. I had one of my former employees getting a little confused by it because his path was very straightforward. He was like I'm going to be a network admin. I'm doing everything along that way. I've got experience in sales before I was in it. I ran my own little like ventures in the past too that were like IT related businesses with others. And I've got experience back in the health industry doing pharmacy software software in the venture capitalist environment. So a lot of acquisitions and mergers, a lot of rapid change management. I was at consulting for a while. After that I moved over to Buzzfalls. If anybody knows the Premix cocktails, they were very rapidly growing, very fast growing company. I left after they sold the company and moved over to where I am now at a fabric wholesale distribution company in the interior design space, hospitality chains et cetera in like luxury fabrics. And we're going through a AS 400 conversion of the old ERP if everybody remembers those green screens system. Yeah. So there's a lot to change there. But it's not my first rodeo. I did this at Buzzballs. I did this multiple times through acquisitions of mergers in the past with these ERP transformations fundamentally changed the entire workflow and processes in a company in addition to the software changes. So oh man.
• 4:18
  Speaker C: So that touches on so many different topics that I find interesting like the fundamental shift of technology from one way of doing things to another way of doing things. And you mentioned you've done this multiple times. That as 400 migration is a perfect example of the challenges I've worked on four hundreds multiple times throughout my career. And those people who have learned all of those keystrokes and have that path through a process memorized so that they can just punch in the numbers and the data and just zip through it. Compared to grabbing their mouse clicking and then typing in a modern form, trying to get them to change is a challenge. But let alone the whole organization. So talk to me a little bit about the challenges that you've had doing that and how do you sell that? Or was it something that the organization brought you in for specifically.
• 5:25
  Speaker B: Your CFO doesn't want 47 Internet bills. We help IT teams consolidate multi location Internet into parent child billing with co terminous contracts while still buying wholesale from the best providers. It gets control, finance gets clarity. No disruption, no sales pitch pitch. Just go to you've been heard.com and answer the seven questions to simplify, streamline and save.
• 5:48
  Speaker A: Well, I've been in a few different scenarios I've been in where I've picked up the pieces from other consulting companies that kind of left it in shambles for another acquisitions. When I was at Buzzballs they were just growing so rapidly that we needed like they're falling behind on where they needed to be. Because when you're growth in an organization, it's not just a gradual linear path, it's like steps, right at every step you need to be at a different layer sophistication in different areas of the company in order to keep from hitting the ceiling. And I had to think about where they would hit the ceiling before we prioritized what we were going to do. So a little bit different the one I'm at now, they were trying to go over to it already before I came in. And so I'm coming in to help them finish the path through. So we started the design and gap analysis when I started back in December. So we're right in the weeds of IT right now. So we're going through very agile method of build and still continual design. Because if stat as 400 conversions to a new ERP is about 56, 58% failure rate when they happen. And a lot of that is because fundamentally any of these companies on these as 400 systems have been on them for decades. They had internal development, so they've customized these systems to their own processes. And those processes don't always translate. So those workflows and processes don't necessarily work with a different modern system. And sometimes they were done out of efficiency for the way that they do things. Sometimes it was because an area thought it would be better for them if it worked this way rather than architecting it properly for the entire company and taking like a lean approach to it or like a six sigma approach or continuous improvement, go back and change the way we're doing things as we added more over time. So it requires not just changing the system in the keystrokes which they do have memorized. They could probably do it blindfolded because they've been doing it for so long. It requires changing some of the processes too and adding some different levels of standardization that need to be rethought.
• 7:44
  Speaker C: Oh man, so many challenges in all of that. I mean just the technology alone, trying to map those old processes, document them, because more than likely, especially on 400 the people who were doing the programming there wasn't the best at documenting stuff. And so you're probably walking in trying to have to discover half of these processes and figure out what the code does or the people that are there, how many of the people that are there, remember when the code was instantiated and why it's changed that way.
• 8:19
  Speaker A: That's true. And then the developers you have may not be the ones that programmed it initially, so they may be long gone. And then if you're asking the users, yeah, it's typical. A lot of non IT department users take things for granted that the system does and assume all systems work this way because they may not know any or know that we needed to program that logic for it to happen. So how do you figure out what the system's technically doing versus what the user is telling you it's doing, which sometimes are total 180 from one another. So one of the first things I did when I started was put a BA in place and then go shadow everybody, figure out what the current processes are at a technical level so we know what they're actually doing in the system and figure out what the system's automatically doing and what's just a workflow that's going over to somebody else in the organization to finish off. And if till you capture all of that, you're going to have a lot of gaps and you'll find it when you go to do the testing.
• 9:12
  Speaker C: And so many organizations, I don't know if the current organizations like this, but so many organizations, they have that department that does this piece of the workflow and then it just flows into the next department and they've got their walls up and their blinders on and they're only paying attention to how they touch the data as it flows through the whole system. And you already alluded to it that somebody that's doing something on the front end may be doing something that is going to radically affect somebody on the back end where they're invoicing or collecting and or doing the accounting and they can't see how well this change here up front, this is just for us. How could this affect somebody back in Billy?
• 9:54
  Speaker A: Oh, no, absolutely. And that kind of goes back to if we go 20 years back and how most companies ran their software stack, they were very siloed in most cases. So like sales had their piece of software, marketing had theirs, finance had theirs. Everyone had different softwares that were not connected, which we run into. The problem with how do you get good clean data quickly and Accurately. And it was always a struggle because you get exports and you validate it. And by the time you clean it up and put it together on some spreadsheets and pivot tables, you're already behind. So now your data is obsolete. So then the rise of the modern ERP systems where everybody's interconnected. But when you take that approach, what they had, their system and how they set it up, when it was a silo, it could do whatever they wanted to. It doesn't affect anyone else. But now we have to look at, okay, what they do actually affects other things downstream. So we need somebody that's architecting the entire sphere here, where all the pieces connect. Sometimes it makes sense to add more work on one area where they have to add a person versus having to add five other people in different areas because the downstream effect. And so it takes an effort of doing some analysis on that and understanding the business processes to be able to see where it's going to make a better fit for the company.
• 11:05
  Speaker C: And so right now this is all front and center in your world. But you mentioned something else in your history. Working with VCs and a couple of mergers and acquisitions and, and things like that makes me wonder about some of. And I'm sure this comes into play with this change of ERPs too. The ability to value what the team is doing and provide metrics and, or numbers, financial numbers, around the changes and, or like that statement you just made of. Sometimes it makes sense to make a one group add work so that things are streamlined further down the process. How do you evaluate that and how do you communicate that to your fellow C suite?
• 11:58
  Speaker A: Yeah, that really depends on what you're dealing with. But it does require a level of business acumen to understand the processes in every department that you're interacting with. Because if you don't understand their internal processes and workflows, how can you evaluate if the technology should be doing X or Y to make things flow more smoothly? And they not know, because a lot of times you'll have the people who are experts in their area, they're really good about their process. I've got my operational people and our frontline people and they know about their stuff. They don't know what technology exists out there and what could benefit them, what's within reach. They could ask for the moon, but that may not be realistic. They have to build that and program it depending on what kind of company you are. You're not necessarily a software company. You're not going to go and build the most elaborate piece or add some level of AI that can do everything for everybody, right? So you have to understand the technology, but you also have to understand the business part. A lot of companies fail on that breaking piece. So even when they're transitioning from one system to another, when they rely on the external consultants, the consultants know their software, but they don't know the business processes. People on the business side know their processes, but they don't understand what the software can or can't do. So you need somebody that can bridge that, that understands both sides, that can vet both sides. That's why you tend to have a lot of business analysts under CIOs, so that they can actually get into the weeds of the business processes. And then when they're asked to do something, instead of being a feature factory and just saying, yes, I'll do it, evaluate, is there a real business case here? Is there a business need? Could we do it with something that we already have, or is there maybe a small change we could do in a different way that they're asking, they'll still give them what they need. That's the not saying no, but the saying maybe this will satisfy your need instead. So there, there's a lot to how do you sell it onto the C suite level? Well, when you can quantify what needs to happen and what's going to actually give the best workflow, then you can actually write it down and go talk to the partner level people and explain what's going on and saying how this is going to add one person's labor over here because they have to do these steps they didn't do before. But by doing that now over here, I don't have to do X, Y and Z. And over this other area, they don't have to do this part because they have data points that are going to benefit them. And you can quantify it at that, but you can't quantify it if you don't understand it.
• 14:12
  Speaker C: So yeah, that's for sure. Now I'm trying to figure out the best way to articulate this. I've had experience in multiple organizations and the teamwork of the senior management and the C level and the concerns for their domains and their area of influence and like trying to get that one group to add more work. If a team with the organization at heart and headed the same direction or rolling the same direction, bullying, whatever metaphor you want to use, having that discussion is a lot easier than when you have to talk to each of the leads or the leaders of portions of this individually and Then convince them to join that process and to help teach them how what they do is affecting others downstream or upstream, depending on what's going on.
• 15:14
  Speaker A: Absolutely. And what do you do even when you present all that? Somebody's just being stubborn, doesn't want to do it anyway.
• 15:20
  Speaker C: Yeah, you're adding time to my people. My people are too overworked as it is.
• 15:25
  Speaker A: Of course, you make the argument, well, we could give you more resources to satisfy that and then you can have a larger team is usually the right answer. Because it makes more sense to give you some more resources in your department than it does to spend three or five times as much in other areas. And sometimes it makes sense to streamline it that way. It's difficult sometimes when you're doing the one on one because not everybody's always going to buy into it. Not until they have trust in you and they've seen some success. Then they tend to listen a little more. But sometimes you always have a percentage out there. They're going to be just stubborn and they don't want to do it. They don't want to change. People don't change by nature. They're resistant to it. It's just human nature. So my strategy is usually transparency. I call them the circling the transparency wagons. If you add enough visibility to everything that's going on, what I found is most people want to feel like others think they're doing good at their job. So rather than say most people want to do good at their job, I say what's a bigger motivational factor is they want other people to think that they're doing good at their job. And I say that motivation is higher than most. And so if you add enough transparency to things where it's very obvious that one way is going to be good or bad, you tend to get everyone to fall in line, even the ones that are being stubborn against you. And it works really well. But sometimes I have to streamline some other areas first because we don't have the transparency. I mean, I've been in scenarios where we didn't know what the cost of goods manufactured or sold were until I had to do some better upgrades to our systems and then add some new processes to be able to get the data in there. And then once we did, then I could go around to a different area that was being a little stubborn about using it correctly.
• 17:04
  Speaker C: Out of all of the questions that I've been throwing at you, has that brought up any thoughts or anything that you want to share about this or especially that? Because we are Talking about a fundamental shift for an organization and those can be dangerous projects for the organization. And it's not just on you and your team, but it's on the organization to make this shift. It's a large project. That's all I'm trying to get across. But I, I'm wondering what thoughts have hit your mind with this discussion so far and it has brought forth anything you want to share in your experience?
• 17:41
  Speaker A: No, I mean it is a large project. There's so many things that have to go, right? I mean if you end up breaking it along the way, you break the revenue stream and then the organization can't survive. So you've got to keep the revenue stream intact first and foremost, right? Everything you do has got to prioritize. You also don't want to over customize when you're doing one of these changes because the odds for success go down with the more customization you have before go live. Because now there's more things that could break, more things that you're trying to troubleshoot. So how do you standardize your processes enough to be in line with the software? But when does that make sense and when does it make sense to step back and say, no, we need this, because if we don't, we're going to have to add 15 hands if we have to do it this way. And so some of that is understanding the real business flows in every area. I think that's important. It's vital. You have to have a good business acumen, you have to be a good partner and you have to have your bas on the ground to kind of go and get in the weeds. And that's one thing that's important. And then having a good project management on top of that is also pretty vital. You have to be willing to work in an agile environment and pivot when you found a gap. And you've got to do some very, very thorough uat. And so you've got to do the user acceptance testing incredibly thoroughly so that you can bet like 99% of it's going to be broken or not. But not only that, you can't have it being the one that's pushing the change. So it can't be the only one saying you're going to do it this way. You've got to get buy in from others. You've got to identify the cheerleaders, the SMEs, if you will, the subject matter experts in the different areas. You've got to bring them into the conversation that you're troubleshooting. Present the problems with what they're doing right now, present the other solutions that are possible, let them be a part of it. Because if they feel like they're a part of the solution we're designing now, you've got someone that's cheerleading you when you're not there and helping the organization move forward. So they're going to be behind the methods that are going forward, not feeling like they're being forced upon them and feel like they're a part of it. And by doing that, adding that collaborative approach to it, you tend to get more success when you're doing any kind of big changes, whether it's a major ERP overhaul or just operational improvement in one area or something added to the software stack or even some integrations. But whenever you're doing it, if it's not, it says this is best, we know better. So you're going to do it this way. It's usually a recipe for disaster. You're going to get people to fight you on it. You've got to have them as part of the solution. So I like to do these collaborative pieces whenever we're changing something in the organization and bring everybody who's affected, we talk about all the downstream effects when everyone there and what you end up happen is there are silos of the departments breakdown and you get better transparency between what everybody's doing. Then the resentment between different departments, leads or experts tend to break down too when they realize this person's not just an obstacle for me, I now understand better what they're dealing with and they're more open to collaborating and making compromise when that's happened. And so most people in your organization, they want to work together. We're all going to the same goal. But there sometimes gets a bit of resentment when you feel like you're working your butt off over here in one area and these other guys are just putting up a wall for you and making it harder for you to do your job. And so you get a little resentment. But then when you realize why they're putting up the wall and what's happening, there tends to be a little more respect for one another. And when you can break down those walls. That's why I said the transparency is always important. I use that on multiple levels with change management. Transparency is very, very key. Honesty and transparency.
• 21:05
  Speaker C: Yeah. I'm interested in something because I've been having this discussion with one of my team managers. The bas. The bas that you work with and that you foster and grow. Do you have them specialize in areas of the organization or do you try to keep their knowledge base as wide as possible so that you can pick them up and put them into anywhere in the organization and have them evaluate?
• 21:34
  Speaker A: I would probably answer that differently for different organizations, but most mid size, I would say it makes sense to make them jack of all trade a little bit. So understanding how all the pieces are interconnected helps them advise their area better anyway because they understand the downstream effects better than anyone else. And what you end up finding is sometimes the technology wing of the organization. This is different than it was a couple decades ago, but ends up becoming more of an expert of everyone else's processes and what they do in the organization. If you look at C suites that are more likely to become CEO, the one of the leading growth factors is from the CIO going into that role. And it's because they have to get so involved with the rest of the organization. They understand all of it better than anyone else does on any of the other pillars. Because we have to. We're doing so much change so rapidly and with technology evolving at such a rapid rate and unprecedented ways like we can't sit back and wait for it to settle and then get on board 10 years later, I have to pay attention every couple months to what's changing. Yeah. Especially with the AI world, like whack a mole right now.
• 22:41
  Speaker C: Yeah. And I was wondering when to blend that into our conversation and wondering how it's affecting what you're doing, because it has to have some radical effects on an ERP change. Are you guys going to a custom ERP or are you going to a modern ERP and then configuring it for the organization? And if you're going to that modern one that you're configuring, well, then they're bringing in AI and probably the organization already has their toe in the water in one way or another around AI. And so what's that blend look like? How has that changed your world compared to the past projects? Because all of this is in the last 24 months.
• 23:22
  Speaker A: Oh yeah.
• 23:23
  Speaker C: Even less.
• 23:24
  Speaker A: Even last year I was talking to some other CIO colleagues and they were talking about how last year everyone was saying, AI is not ready, we're not ready for it yet. And then this year everyone's saying, well, you should have been on this ship three years ago, where you been? So it's changed so rapidly. And you also have the problem with the shadow it with AI more than we ever have, and governance problems and holes being discovered faster than we ever have because we used to you could have a hole in your governance and it never be exploited because the person that has the access would never in their wildest dreams know about it or understand how to go exploit it. But with AI now, it just makes it so easy. And it's also a tool for us though. So like we're using it for programming. I actually put that in place since I've been here. And it's using it the right way. Not doing the code for us, not vibe coding, but using it to help validate and treat it like a junior. You never let a junior's code go live in a production without review. So we do all of that, but I'm able to do twice as much that I could with the team size that we have otherwise. And I still have to worry about the rest of the organization just grabbing data, throwing it out to like ChatGPT or something on their own that we have no control over. That's a problem. So we're putting together AI governance board. I think that's important now because that kind of also takes some of it off of me being the only one to sit there and say, hold on, no, we're being the bottleneck now. We have a board that's going to evaluate the risks and the monetary investment and then make a call whether we should use it or not in the organization. So that's going to help also, but it is helping do it faster than ever.
• 25:00
  Speaker C: Yeah, I was wondering what you meant by the governance holes and that utilization. Because in all honesty, in my experiences in the past, governance has always kind of taken a third seat, not even secondary seat. They're not even on the back burner. They're off on the counter somewhere else being waiting or waiting for their attempts to come up to the back burner. But now with all of this happening, we find ourselves today working on the governance, trying to get that governance in place before we release more and more of this throughout the organization. And so I have an idea, but I'd love to understand what you mean by when you say governance gaps and apply it towards one of the business units outside of it.
• 25:46
  Speaker A: Yeah, so let's talk about like role permissions and restrictions right in the organization software. And if you have proper governance, you only give them access to minimally what they need to do their job. You don't want to give them more than they should. You don't want to give administrative access to every sales rep or operational line person out there because they don't need it and they don't need access to all of that data and it just creates more to manage. So to your point, it kind of has been on the back burner in some areas and some softwares we tend to be better about IT and other ones not so much. And it's usually where we've had help with like finance and IT working together, usually in a lot of these areas to apply it. Or you have a governance entity compliance department in your company maybe, but if not, then it has always been the one with the security side saying, well, we need to restrict this because we need to make sure the data is secure, we need to make sure we're SOC 2 compliant, right? We need to make sure that some of our standards being adhered to. If we're SOCKS compliant, there's a whole nother level on there that we have to worry about. But even in the Azure environment, how much access do they have to all the shared drives out there? And from any user level being able to. What about copying all their email? What about their smartphone, having the apps on there and having all the data accessible and then the person departs from the company or the phone gets lost. Do you have access to eliminate that data or is it possible that it's been copied over? So there's things that we should have always been paying attention to, we should have always been good about. But I think everybody can agree there's been some lacks in the past few decades about it, but now it's more important than ever to get onto it. And with I choose they add these tools and if we give them access to do it. I actually had some executives asking me for admin access to Azure so they could hook up quad and I'm like, hold on, no, we got to wait, validate when you're doing and figure out how we want to do it. But they want to use their own license to just go in there because somebody ran a seminar that told them how it can help them with their email and their calendars and everything without them really understanding the ramifications of it. So I had to talk with it, I educated them and then they agreed with me after I was done. I didn't just go and say no, like I actually educated them. But there's things that we have to worry about that we didn't really have to at the same level. And it's coming so fast, it's like whack a mole. If you try to block all the AI, well you're going to have problems there too because you need to have an outlet, you need to come up with a way that the organization can use it and a path where they can come and say here's my business case.
• 28:12
  Speaker C: But you just become more Doc Douglas Adams and the preventer of technology. And because the CEOs and a lot of the C suite and all of senior management are going to those seminars are finding out ways that it can help and how it saves them time. To your point, I think one of the critical things that isn't getting communicated well is like the difference between that administration Azure access and a connector in that allows them to have let Claude go in through their mailbox if it's been approved by us. And we know that that license isn't sharing with the public model. But you can set up that connector so that they can have that tool set and leverage this stuff. But it's not wide open. So now some junior who gets curious starts asking hey, what's in the CEOs inbox and their connector or that admin connector has been set up with global admin permissions.
• 29:12
  Speaker A: I would argue even worse is we train the LLM with our data and now competitors and other people that are outside of organization have access to data that they shouldn't that we should have locked down. Or what if you even get like PII out there by mistake because we're not filtering it out and somebody could just freely throw it in the LLM. So those are some of the risks, which is why it's important to come up with a strategy to use internally. Here's the portals you can use, here's the AI. And if you have a good business case because you heard a seminar or something, the problem with most of these softwares out there too, let's be honest, a lot of them are snake oil. I get these, I'll get on a call for a couple hours with them. I'll be drilling down into how it's actually working. Finally get some of them to admit, well, it doesn't yet. We're still working on getting there to make it do X, Y, Z. But you don't get that until you get into the week they're selling it. They are sure, because they want you to pay them now so they can figure it out. They're confident they'll get there quickly. But pay me now. The real way to do it successfully is to actually have some internal developers with building up some of the agents and the workflows to work with your own LLM instances on the background that you can still control to a degree. But let's be honest as it across the board, we've put phenomenal governance standards in place for data security over the last few decades and now we just threw it all out the window and in here, another server, another company, take it all. I don't no idea what you're doing with it. You don't even know what you're doing with it. But I'm going to trust that it's okay. We would have never done that 20 years ago, so it's a tough one to deal with. It's also why a lot of CISOs are quitting companies, left or right. Because the CEO is saying, you're going to do this no matter what. And they're saying, I don't want my blood on this. So I'm out waiting for somebody to get hit with a big problem. There's a way to do it responsibly though. So we're very AI forward and I'm putting the governance board in place for having proper processes. I've got internal developers so that we can work with our own company instances of these AI models and build our own parameters. So a good example would be sales came to me about asking about how to prioritize which customers to visit. Well, they need some financials for that. Which ones do we want to prioritize? And then let's map it out. Well, I need some PII on all of that too. So I don't want you to go chatgpt on your own. I'd rather build a program where the those can be added and then we can go out and encrypt the identifiers so that they're not being connected. Kind of like we do with medical data. We're trying to deal with hipaa. You have different encryption modules that your software can match when the LLM comes back, the LLM doesn't need to know who. And then you also want it only hitting your own instances so it says it's not learning from it. We try to trust them as much as we can. Like there's only there's a certain amount of risk that you have to take. And I think that's why it's important to do the governance council because then the leaders that on the company can all collectively make a decision and say here's the potential risk, here's what we're willing to take for the benefit.
• 32:06
  Speaker C: Okay, interesting. You are spot on with a lot of your approach and the way that you're doing it, at least from everything that I've seen and what I've run across so far and trying to understand this world myself, because the. I think you said it earlier, things are changing so fast. It's a whole new world in the last three years compared to what it was. And the question that I wanted to ask was, you're setting it up. You've got some governance, you've got some control in place for your team doing the cicd and making sure that it's not just releasing straight into production, you reviews and all that piece. But you mentioned the thing that's bypassing a lot of it and is showing up as shadow AI everywhere and that's that Vibe. Cody, how are you working with that? Because there's some ideas that are being generated in that have some business value.
• 33:03
  Speaker A: But what do you do with that?
• 33:04
  Speaker C: What are your approaches towards that?
• 33:06
  Speaker A: I mean, also doesn't help. Like I know somebody who developed their own WMS and configurators in four months with no programming background. I'm doing five coding with Claude. So the amount that you can do is almost dangerous. You still want an expert who understands the code because they can review and see where there's still some holes or some security problems that AI may have done. Or maybe just from a consistent coding practice, as everybody probably is aware who works with developers, they all have their own way of doing things. And you want to standardize that in a company because it makes it easier to troubleshoot different pieces and also to upgrade. Because if everything's done the same way, it's easier to tackle problems and train new people on it too. Which is hard to do if you're just Vibe coding it because it'll be however it's doing it and sometimes it'll be a little inefficient. There's been instances where companies have Vibe coded a software, but in order to update it, it was just so convoluted, like so much spaghetti code, that they just made a new version and released a whole new app because it was easier to do it that way. So I think it's important to have not only like your senior devs that really understand it, have good practices, but also a leader that's monitoring it and paying attention to what's happening on there. And if you don't do that, you can get out of control pretty quickly. Not necessarily anybody would do it on purpose, but they could just be lazy and start by coding and releasing it. So you don't want that. What we tend to do is we work on the code. If we hit walls, we use it to help research the AI that is. And then we also Use it to help, like, check and validate the coding before we're sending it out. And we run into our test environments first and we have multiple levels of people looking at this before it gets released. Now, I think the real danger is other people in the organization that are not it vibe coding things. Then you end up with this sprawl. I was talking to somebody about one company, they went live with the Jira, and there's like some AI in there where you can build your own little apps and flows. They ended up in three weeks with 38 different apps and a lot of them were redundant. So now you're ended up back into the same problem we had before we started consolidating these ERPs last 15 years. And now you're having a whole bunch of small little programs being spun up on their own because there's no review or validation, there's no continuous improvement model that's going to be applied to them because they're outliers and they're unseen, and so they're not part of the controlled tech stack. So it's important to rein that in. And that's where governance is difficult, because you want to be able to control that. And it's getting harder and harder to do it than ever has. But you have to have an outlet. You can't just say, no, nobody can do this. We're not going to pursue AI. You have to have a process where they can come up with their ideas and funnel them through and be heard in order to kind of mitigate most of it. But it is whack a mole. It really is. Like, if you try to ban them or block them, every time you do, another one's going to pop up and it's hard to keep up with because there's new ones every day.
• 36:00
  Speaker C: Okay, so I find myself with this challenge, and you must have this challenge also. So you're trying to keep the lights on. You're trying to change those lights, the old AC power, into some new version of power, the ERP system change. You're trying to set in this governance. You're trying to leverage these tools to help increase the speed with which you're doing all of these fundamental shifts. And then you've got all of these different people trying to use these tools and you're playing that whack a mole at the same time.
• 36:39
  Speaker A: When's the breaking point, man? No, I mean, be honest. I would have preferred if the AI stuff was going a little slower, and I could have waited after phase one of the erp. Trans migration because I could put more energy onto it. But we're just going to have to. Sometimes things come up in it and you got to deal with it, right? Sometimes there's big global pieces that affect you and you've got to get in there and you just got to roll your sleeves up and deal with it. So I'm going faster on the AI piece right now to add some governance, put some stuff in place. One of the things we're going to talk about as a company is how much do we want to spend to give people an AI out that's controlled in our own environment rather than everybody using their own accounts. And so we're going to have something to mitigate it and there's a cost to it and we're going to have to get the company to buy in on it because then what I want is leaders in the other areas of the company to also be bought in on. Here's why we need to do it, here's why it's dangerous. We just had a big national sales conference so I was educating a lot of people on how it could be dangerous when you're feeding this data out there because it doesn't forget. It's not like me. You talked to me one day and I forgot what we were talking about last week and you got to refresh me. It knows and it makes the connections faster than anybody. And so how do you use that a responsible way? We're not having problems with data security and in the past it was just finance it, maybe a compliance department that really cared about all of this because they controlled the new tech stack that was coming in. The cost to add a new tech stack was so high and then the cost for data migration required IT involvement. So there's always these gates that would stop it from coming into the organization. And then everybody else just knows, here's the software, here's how I'm supposed to use it. They didn't think of I shouldn't use this identifier information or I shouldn't put this financial data out in a non zero trust environment. And they didn't have to think about that stuff. But now that I think the education is warranted now and so I'm going to start educating more of the company about this stuff when they didn't have to think about it before, but they need to, they need to understand why it's important and then we need to be partners and work with them.
• 38:36
  Speaker C: So okay, a little backstory on my side. So one of the things that we did we put together the AI council, we started putting in the guardrails and the governance and talking about those pieces and then we started trying to educate the upper echelons C suite and the leaders of the different departments. So we brought them in and started teaching them some of the uses, use cases, things to be aware of and watch out for. And back to the governance of. Yeah, no PII and only the approved tools. And this is why. And those pieces of it. And so we're working through that, but it's that now that velocity of all of those requests just went exponential and we're still trying to do all of those day to day things for us keeping trucks moving for you guys getting that fabric created now to that warehouse. How much are you guys experiencing a frustration with? Well, I did this over the weekend using the approved tools and came up with these things and now it goes over to it and now we've got to start adding in all of the governance the continue CICD the layers that make it so that as you put the authority for people to only access the things that they should. We're trying to put all those in and it's going to take us a week or three to accomplish that with that thing that they five coded over the weekend. Are you running into that fund too?
• 40:13
  Speaker A: Not yet. Because we're like, I'm gonna step back on that piece. But I would say one of the things you want to do, you don't want to give people the ability to vibe code. So there shouldn't be a sanctioned vibe coding tool for people in the organization. Instead I have a business case. I think we could have AI do xyz, what's the business case for it and then present that and then that goes to the proper vetting and we have people who have the skill set and control around them that could do it. But we can evaluate if we want to do it as a company before we even start going down that pat path. That's the way you want to approach it. If they're doing solutions in your environment, you've got another problem, which is one that a lot of people are dealing with, a lot of IT leaders are dealing with right now because there's these little shadow things are getting created and sometimes it's not even what you've instituted, it's one of your tools that added an AI to their own environment and then before you even caught it, started allowing all of its users to go and do stuff crazily with it. I also have the problem. What about our partners who Start using AI in a way that I didn't necessarily approve of and it might be a problem. There's like some Zoom recorders out there that have a very bad track record with the data getting out there and I've had to shut it down. But it gets embedded in all their tools and it's hard to keep out. And if they can embed it into the browser, I mean, there's things that just make it really hard from a governance standpoint to control all of this and to educate everyone. So we got to educate people on proper software implementation and the channels to go and check things before they use it. We have to educate people on why the data is important to protect and why compliance is important and the risk to the company. I think when we do that, they tend to buy in a little better and then they're willing to sit back and say, okay, well here's an idea I have, I think it could be a good use. And then when you talk about the floodgates being open for like you've got a counselor, you've got a path. I mean, first thing I dealt with when I started was let's have a council that approves what we do rather than just being a feature factoring. Do everything everybody asks. Part of my vetting process is the bas and I think it's important so if the bas understand what they're doing in the different positions, they can also approach them and say, hey, did you know you could do it this way instead? Or hey, we have this tool, we can actually get what you want from this kind of report instead of the customization you're asking for. And that's a lot of them that tend to be lower hanging fruit stuff because not everything's going to come at you going to be a drastic change.
• 42:35
  Speaker C: Okay, my mind went after like eight different threads there. But the biggest thing that I actually want to talk about at the moment is, okay, the bas. So the bas. I found in the past that trying to apply or to instantiate multiple BAs within an organization that typically hasn't used them, that is a struggle itself. And bringing them in, having them to learn that business and those pieces of it, I, I know all of the value that you, you've been talking about. Have you had any experiences at organizations that didn't have bas as you tried to bring those in and how did you help upsell that?
• 43:20
  Speaker A: Every organization that I brought bas and didn't have them. But okay, it's usually not hard to get it started. I need a person or two Right. To get started in. Explain the reasons why as you're doing some of these projects, why they're helpful. And then getting them in the weeds usually isn't difficult either because a lot of people in the organization want to be seen and so them going, hey, can I just see what you do? I want to understand what you're doing. Oh yeah, here's how I do my stuff. I haven't had a lot of resistance on that, so that's usually been easy. And then they end up becoming an educator, they're a trainer, they help with some of the go lives and the project management. So people have seen them implement things as we do it and the trust is there. And if you've got good people in the BA positions, even if they're new and you can just train them, if they got a strong business acumen and a good technical mind that can grab and understand things quickly. I've even had some people out of college that have been all stars and within months became the experts that other people in the organization were going to and getting feedback. They trusted them. But you have to have that trust. So you've got to be willing to work with people and understand what they're doing. When I say you, I mean everybody in this area. And when you can do that and then they see successful projects going through and they know you've been a partner along the way, they, they tend to have more trust in it. And then as the need to expand happens, it's usually easy enough. But don't think I've been in a scenario just personally where I've had to jump in and say, hey, we need to add 10 or 15 BAS. We don't have any. I've been to like more mid sized companies. So start off with one or two and go from there.
• 44:50
  Speaker C: Yeah. And then as they prove their value then it's like, hey, I need to be able to get to these two departments at the same time. Help me put somebody here. And especially with the Swiss army knife version that you were talking about, then you know that you're going to be able to move them to other areas of need so you can quickly kind of map out, hey, they're going to be here right now for the next three to six months. Then we'll have them over there then that'll help with this whole workflow. We'll. Yeah.
• 45:19
  Speaker A: And whomever you still want to bring people in the departments over through the projects. So you want to be able to identify the SMEs, who's your subject Matter expert in the area that's very technology forward. There's always somebody enthusiastic be a part of it. So your BA doesn't have to be the expert in the area. They just have to know enough of how all the pieces interconnect on the technology side and then understand who to go to and bring in as part of the process. So if they don't have to be an expert in every area, it's a lot quicker to move them around and they can be that Swiss army knife because they know the interactions that are happening. They may not be able to do the job, but they know the interactions that are happening to the software and how it connects with all the other pieces for the workflows. And now you've got an alliance. So now you've got SMEs in some departments, you've got your BAS that are working with it, that's gluing the others, the developers and the other people on the back end together and our partners. And so now you've closed the gap from understanding the business process and understanding the technology and you've got a nice little flow or a stream for all of that stuff to get vetted out and understand the gaps before you encounter them.
• 46:22
  Speaker C: At Go Life, this discussion and this view of the bas and what they're doing and their ability to understand the business, their ability to understand the technology, their work with the project management and all of this, I see this as the. I've been trying to come up with a way of saying it, but I'm just going to be blunt with they're the CIO wannabes or they're probably a great pool for the people who will grow into management within the technology groups and then start continuing to advance that way. So back to that other guy that wanted to become the network admin. He saw his path. Well, I'll date myself here a CCNA and needed to work through the education and the experience and everything to get to where he wanted to be. And then, then he was done. I bet you the BA is a great path to start trying to follow behind us.
• 47:24
  Speaker A: Yeah, you end up with people like a higher business acumen and a desire for IT in those positions, but they have to be technical enough to understand the lingo and the tech. So when talking to developer, they need to understand it. They don't have to necessarily know how to go code it, but they understand what's happening and fill those gaps in. And yeah, to your point, they can be future leaders. They tend to be because they're touching so many different areas. They're lear to work collaboratively with other people in different departments. They're understanding the different workflows. They get great exposure and experience. So I can usually get some enthusiastic young people to really be all stars in those areas for that reason. And then they usually love it because they get so much exposure to different pieces. As long as I'm not putting cuffs on them and bob keeping them in a box, which midsize companies, I can't compete with the large ones that have 20 different promotional levels that you can just slowly go every couple of years. So instead I give exposure to more cross training to more than they'd ever give it. And so they can grow in that way.
• 48:21
  Speaker C: Awesome. Got any thoughts that you want to leave the audience with? You got anything that again, that bubbled up through this conversation that anybody that's looking to follow behind you or I at an organization and to grow into these positions? You got anything you want to share?
• 48:38
  Speaker A: Well, yeah, I'd say one of the pieces I've been talking about this a lot lately with others in our fields is the fundamental shift. And it's happened kind of slowly over time, but it's even more dramatic now than ever in leadership. And IT being more than just the IT guy knowing all the technology, it's also understanding the business and being a partner. And when you can fulfill that role, it's kind of shifted from 20, 30 years ago. The CEO would be the one that kind of like really knew everything that was going on. So they could orchestrate the leaders in different areas to make the changes that they wanted. But when it comes to this tech, they don't have the bandwidth to keep up with that. They need to focus on growing the company and funding the company. Whether the CIO can jump in and say, okay, here's where I notice some gaps in the organization where we could fix it by adding this tech. And if we did this, we could have cost savings of X, Y, Z year and streamline. Maybe it's some personnel reduction in a certain area. Maybe they don't need them over there where we're just like throwing more hands at it. But the CIO being a partner in that sense, being collaborative with the C suite and then owning the technology side of it, we still have to understand the security, the governance. We still have to manage the development and proper levels there and all of our controls in place and keep ourselves secure and connected. Right. But we also have this ownership of really being a partner with. How can technology move our company forward and within bounds that's reasonable for the company at its size and the industry that it's into. So I could say, yeah, sure, give me 30 more developers, we'll go program the best AI solutions that we could have. But that's not what our company is. We're in the fabric industry. We are going to have some great solutions, but we can wait for some breakthroughs from the big guys and piggyback off of them. But then being able to educate the other C suite because they went to some seminars, saw this latest greatest stuff coming down the pipeline and they wanted to be a person and I need to educate them. That's not what it is. Here's what it does, here's how we could use it. And then by doing so now we're all in the same mindset for what's possible. But being a partner is definitely a shift. And it can be an uncomfortable shift sometimes for some people who tend to be a little more introverted. Got to get a little out of your shell and learn to work more collaboratively with people. But they all want to work together. And people will work with you if you're being a partner. If you show that you're listening and understanding them and their problems. They'll also be willing to work with you on the limits and the solutions that we can come up with.
• 51:06
  Speaker C: Yeah, I've had some examples of that within our organization and people just jumping in. My fellow, the management at the same level, they've just jumped in and supported a lot of those things and it's been amazing. We like to ask another question, and that is make a prediction. What do you think we will be talking about in 18 months that we're not talking about today?
• 51:33
  Speaker A: All right. In the next couple of years? I think what we're going to be talking about is how to reduce the software and AI sprawl in the company. That is really what's going to happen. We're going to have so much our tech stacks just going to sprawl out. It'll be siloed again with all these different solutions. And we're like, how do we bring this back in and manage it? How do we make it secure? But how do we do it without saying no to the business? And it's going to be tough to keep up with. And the other part is on how do we do this and understand the cost? How do we make the business understand the cost of doing this and justify it? So there's going to be a point where I think where we'll get to where you have so much. A lot of it's good and it's given us value and a lot of it. We're just spending money, but we're not getting a good ROI on it. And how do we quantify and evaluate it? And it's going to be difficult.
• 52:20
  Speaker C: Yeah, well, we're already starting to talk about it, but we're going to have to control those costs before we get to that pure sprawl. But I think some organizations are going to be big enough that they're going to have the sprawl before they recognize the college.
• 52:33
  Speaker A: I will challenge everybody listening on this one. Your organization probably has sprawl already and you don't know it. There's individuals and small teams that are doing their own thing outside of our tech stack, maybe even on their own devices and they're using their own environments. And so if you're not already looking at that, you need to. And you're not going to solve it by just shutting everybody off. They'll figure out another way to get it. So we have to look at what's the business case they're trying to solve and how can we solve this in a way that the company can want to afford and is willing to take the risk on. So that's why I think the AI Governance board is very important, because you end up getting more of a cross collaborative partnership and if you don't have one of those, you work on it.
• 53:14
  Speaker C: Well, Gabriel, you've been heard. Thank you so much for joining us today and all of your time and your experience. If you don't know it, it is well worth the listen today to get ahead of a couple of these things and learn from our experience versus going through it on your own. So truly appreciate the time, Gabriel. Thank you.
• 53:37
  Speaker A: Appreciate it, Mike. Thank.