449- How CIOs Govern Change Without Blocking It w/Gabriel Chappell

Mike Kelley: Well, it's great to have you with us again on You've Been Heard,
the show dedicated to technology enthusiasts 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've carved out
some time to dive into the trenches with us today and share your experiences
with our community over at youvebeenheard.com. Our guest today is Gabriel
Chappell, 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 and 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?

Gabriel Chappell: Thank you Mike. Yes. I've got, very diverse experience. that's
kind of led me up through my path in 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 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 Buzz Balls. If anybody knows the,
pre-mixed 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 Fabrica,
wholesale distribution company, in the interior design space, hospitality
chains, etc., and like luxury fabrics. And, we're going through a, A S four
hundred conversion of the old ERP if anybody 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 Buzz Balls. I did this multiple times through acquisitions and
mergers in the past with these, ERP transformations, it fundamentally changed
the entire workflow and processes in a company in addition to the software
changes.

Mike Kelley: So oh man. 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 four hundred migration is a perfect example of the
challenges. I've worked on four hundred multiple times throughout my career and,
those people who have learned all of those keystrokes and have the, 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?

Gabriel Chappell: 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, during other acquisitions, when I was at, Buzz Balls, they
were just growing so rapidly that we needed like, they're falling behind on
where they needed to be. Because when your 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 of sophistication, in different areas of the company in
order to keep from hitting a 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 the stat A is four hundred
conversions to a new ERP is about fifty six, fifty eight percent failure rate,
when they happen. And a lot of that is because fundamentally, any of these
companies on these as four hundred 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 the different modern system. And
sometimes, they were done out of efficiencies 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've added more
over time. So it requires not just changing the system and 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.

Mike Kelley: 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 a four hundred, the people who are doing the
programming then, 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?

Gabriel Chappell: 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, well, that'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 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 one eighty from
one another? Yeah. So one of the first things I did when I started was, put a
bay 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 is automatically doing, and what's just a
workflow that's going over to somebody else in the organization to finish off.
And until 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.

Mike Kelley: 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 billing?

Gabriel Chappell: Oh, no. Absolutely. And that kind of goes back to if we go
twenty 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 say where it's going to make
a better fit for the company.

Mike Kelley: Yeah. 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 to, 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 one group had 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?

Gabriel Chappell: 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 may 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 to 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, though still
give them what they need. That's the not saying no, but to 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 in 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.

Mike Kelley: 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 rowing the same direction, or whatever metaphor you want to use,
right? 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.

Gabriel Chappell: Absolutely. And what do you do even when you present all that,
somebody's just being stubborn and doesn't want to do it anyway. Yeah.

Mike Kelley: Yeah. You're adding time to my people. My people are too overworked
as it is.

Gabriel Chappell: 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 is always
going to buy into it, not until they have trust in you and they've seen some
success and they tend to listen a little more. But sometimes you always have a
percentage out there that are 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've 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.

Mike Kelley: Okay. out of all of the questions that I've been throwing at you,
is 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.
And it's a large project. That's all I'm trying to get across, but I'm wondering
what thoughts have hit your mind with this discussion so far? and has it brought
forth anything you want to share in your experience?

Gabriel Chappell: 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 that. 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 fifteen 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 BA's 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 viral. You have to be willing to work in an agile environment and pivot
when you found a gap.

Mike Kelley: Yeah.

Gabriel Chappell: And you've got to do some very, very thorough UAT. So you've
got to do the user acceptance testing incredibly thoroughly so that you can vet
like ninety nine percent 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. So you've got to identify, the cheerleaders, the semi's, 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 over haul 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 and 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, what everyone there and what you end up happen is,
their 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's 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 say the
transparency is always important. I use that on multiple levels with change
management. The transparency is very, very key. Honesty and transparency.

Mike Kelley: Yeah. I'm interested in something because I've been having this
discussion with one of my, team managers, the VAs. The VAs 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 in to anywhere in the organization and
have them evaluate?

Gabriel Chappell: I would probably answer that differently for different
organizations, but most midsize, 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. And 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 that 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 management so rapidly. And with technology evolving at such a rapid rate
in unprecedented ways, like we can't sit back and wait for it to settle and then
get on board ten years later, I have to pay attention every couple of months to
what's changing. Yeah. Especially with the AI world, like whack a mole right
now.

Mike Kelley: 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 an 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 twenty four months.

Gabriel Chappell: Oh, yeah. Even less 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 have 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 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 juniors 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 an 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, or be in 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 me do it faster than ever.

Mike Kelley: 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 that, third seat, not even a secondary seat,
they're not even on the back burner. They're off on the counter somewhere else
being waiting or waiting for their chance 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.

Gabriel Chappell: 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 demand. So, to your point, it kind of has been on the back
burner in some areas, and some softwares would 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 or 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 two compliant, right? We need to make sure that some of our
standards are being adhered to if we're Sox 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
lax in the past few decades about it, but now it's more important than ever to
get on to it. And with the AI piece, they add these tools. And if we give them
access to do it, I actually had some executives asking me for admin access at
Azure so they could hook up cloud. And I'm like, hold on, no, we gotta to
validate what 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 yeah, 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. but you.

Mike Kelley: 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 the 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 admin, 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 CEO's inbox? And
their connector or that admin connector has been set up with global admin
permissions.

Gabriel Chappell: I would argue that even worse is we train the LLM with our
data, and now competitors and other people that are outside of our 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 can 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. I'll 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 weeds.

Mike Kelley: You're selling it?

Gabriel Chappell: Yeah, 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 said, here, another server, another company,
take it all. I don't have 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. Like we would
have never done that twenty years ago. so it's a tough one to deal with. It's
also why a lot of CISOs are quitting companies left and 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. We're having proper processes.
I've got internal developers 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 to ChatGPT on your own. I'd rather build a program where 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. When you're trying to
deal with HIPAA, you have different encryption modules that your software can
match when the LLM comes back, but 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 leaders 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.

Mike Kelley: 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 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 CI CD and making sure that it's not
just releasing straight into production reviews and all of 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 vibe coding. how are you working with that? Because
there's some ideas that are being generated in that have some business value.
But what do you do with that? What are your approaches towards that?

Gabriel Chappell: I mean, it also doesn't help. Like I know somebody who
developed their own WMS and Configurators in four months with no programming
background, doing 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 A I
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 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 because not necessarily anybody would
do it on purpose, but they could, just be lazy and start vibe 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, the I think the real
danger is other people in the organization that are not I.T. vibe coding things,
then you end up with this sprawl. I was talking to somebody about one company.
They went live with a 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 thirty
eight different apps, and a lot of them are redundant. And so now you're ending
up back in the same problem we had before we started consolidating these ERPs,
last fifteen 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. And 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, yeah, 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.

Mike Kelley: 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 from the old, AC power into some new version of power. that the ERP
system changed. 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. When's the breaking point, man?

Gabriel Chappell: No, I mean, be honest. I would have preferred if the AI stuff
was going a little slower and I could have waited to 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 eye 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. 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 talk 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 in 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.

Mike Kelley: So, okay, a little back story 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 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 out of the, 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 to continue CI, CD, 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
vibe coded over the weekend. Are you running into that fund too?

Gabriel Chappell: 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 x, y, z. What's the business case for it? And then present
that. And then that goes through 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
path. I mean, 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 into 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 gotta 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
risks 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 council or you've got a path. I
mean, I 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 factory and do everything
everybody asks. Part of my vetting process is the VAs, and I think it's
important. So the VAs 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 a 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.

Mike Kelley: 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
BA's, so the BA's, I found in the past that trying to apply or to instantiate
multiple BA's 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've been talking about.
Have you had any experiences at organizations that didn't have BA's as you tried
to bring those in? and how did you help upsell that.

Gabriel Chappell: Every organization that I brought BA's 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 and 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 BAs positions, even if
they're new and you can just train them, if they got a strong business acumen
and a good technical like 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 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 ten or fifteen
BA's we don't have any. I've been in like more midsize companies. So we start
off with one or two and go from there.

Mike Kelley: 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. Well, yeah.

Gabriel Chappell: And if you remember, you still want to bring people in the
departments over through the projects. So you want to be able to identify the
species. Who's your subject matter expert in the area. That's very technology
forward. There's always somebody enthusiastic to be a part of it. So your bay
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 BA's that are working with it. That's gluing the others, the
developers and the other people on the backend 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 at go live.

Mike Kelley: This discussion and this view of the BA's 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 their 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 CNA 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. Mhm. I bet you the, BA's is
a great path to start trying to follow behind us.

Gabriel Chappell: 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 developers, 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 learning 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, keeping them in a box, which, a midsize
companies, I can't compete with the large ones that have, twenty 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 get. And so
they can grow in that way.

Mike Kelley: 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 your eye at an organization and to grow
into these positions, you got anything you want to share?

Gabriel Chappell: Well, yeah, it's one of the pieces that 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, twenty, thirty 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, or, and streamline maybe some
personnel reduction in certain area. Maybe they won'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, you 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 in, too. So I could say, yeah, sure, give me thirty 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 then 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 want it 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 on 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 are tend to be a little more introverted, got to
get a little out of their 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.

Mike Kelley: 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 eighteen months that we're not talking about today?

Gabriel Chappell: 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,
because I think that's really what's going to happen. We're going to have so
much, our tech stack is 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? And 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.

Mike Kelley: 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 cost.

Gabriel Chappell: I will challenge everybody listening on this one. Your
organization probably has sprawl already and you don't know it. There's
individuals in 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 need to work
on it.

Mike Kelley: 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.

Gabriel Chappell: Appreciate it. Mike. Thank you.