You followed the plan, the tech worked, the budget was there…yet adoption stalled, and resistance crept in to where it all felt like a slow motion disaster. That’s because not every problem is an execution problem. Some are complicated (predictable), others are complex (messy, people-driven). IT leaders get stuck treating one like the other, and no amount of meetings or KPIs will fix it. Call out complexity early, align incentives, and design for iteration.

You ever work on a IT or Digital project where everything looked right on paper, but somehow, it still felt like undertones of the struggle bus?

🟢 You had the right team.

🟢 The budget was locked in.

🟢 The roadmap was solid.

🟢 The tech worked in testing.

But the whole time there was this constant undercurrent of resistance. It’s palpable and everyone can feel it but never outright says it.

Deadlines slipped. The adoption wasn’t there and conversations got harder. You kept running into unexpected roadblocks, and no matter how well you explained the plan, people weren’t fully on board.

If you’ve been there, I want to say something upfront: You’re not crazy.

You’re not imagining things. You’re not missing some secret ingredient that other leaders seem to magically have. You’re running into something deeper than execution. As an IT leader, this drove me insane until it finally clicked (thankfully at a young age).

Let’s solve this riddle.

Subscribe now

Not Everything Can Be Solved With a Better Plan

In IT, digital, and business in general, we love structure. We love plans, roadmaps, frameworks, and best practices…and for good reason. They make big problems manageable and bring clarity. In particular for B2B organizations in manufacturing & distribution, structured execution is the default mindset.

That mindset is invaluable in operational areas like supply chain management, procurement, and logistics where process consistency and predictability drive efficiency.

But sometimes, even the best plan doesn’t fix the problem.

Why? Because not every challenge is a matter of execution.

Some things can be solved by breaking them down, assigning tasks, and following a structured approach. And boy do I (and most technical folks) thrive on those types of opportunities. Very analog. These are complicated problems - they might be difficult, but they’re predictable once you understand them. Examples…

• Moving data from an old ERP to a new one.

• Replacing a firewall with a new one.

• Upgrading your fleet of PCs from Windows 10 to Windows 11

If you follow the steps, you get the expected result with minimal variability.

But some challenges are not predictable and they don’t only require technical expertise. They require buy-in, adaptation, and emotional intelligence. These are complex problems, where success isn’t really about execution but about navigating change, resistance, and the unknown. Examples:

• Getting customers to actually use self-service instead of calling their rep.

• Convincing sales teams that digital tools help them instead of replacing them.

• Driving AI adoption in an organization where people don’t trust the data.

See the difference?

One is about doing the work correctly.
The other is about aligning people toward an often uncertain future.

That distinction alone (complicated vs. complex) explains so much about why some projects feel perpetually cursed while others succeed.

Most IT leaders understand this distinction in theory, but it’s not thought of in practice proactively. We treat everything like it’s solely complicated. Thinking about this more hit me like a sack of bricks.

• We create rigid project plans. We scope out deliverables. We assume execution = success.

• We launch an ecommerce site and customer adoption is meh, we’re confused.

• We roll out AI-driven pricing and sales ignores it, we’re frustrated.

• We implement a new ERP and business units refuse to change their workflows, we think: What the f*** happened?

When you’ve been a technical problem solver so long, you’re almost preconditioned to only think a certain way.

But…the problem was never only the technology.

This Isn’t Merely a Change Management Rant

Let’s pause for a second. If you’re dealing with a project that feels harder than it should be, ask yourself:

Is this truly a technical problem, or is it a human problem?

Now, before you roll your eyes and say, “No shit, Jacobi. This is basic change management.” - hear me out.

I know change management is a thing. I know that proper communication, training, and leadership buy-in matter. That’s not lost on me and I work my change management muscles daily by nature of the work I do.

What I’m saying is this: what if we’ve been looking at the problem through the wrong lens?

B2B organizations, especially manufacturing and distribution, aren’t new to big, difficult projects. We handle ERP overhauls, warehouse automation, and supply chain optimizations all the time. And when we do, we follow a structured playbook:

✅ Define the problem.
✅ Map the solution.
✅ Assign ownership.
✅ Execute the plan.
✅ Track progress.

And most of the time, this approach works. So when a digital initiative, like an ecommerce rollout or an AI-driven pricing tool struggles, the instinct is to treat it like an execution failure.

❌ “Maybe we need more training.”
❌ “Maybe IT didn’t configure it correctly.”
❌ “Maybe the sales team isn’t trying hard enough.”

What if the real issue is a misalignment of incentives? A loss of perceived control? An unspoken fear that the change is a threat? You can train people all day long, but if they don’t believe the change benefits them, they’ll find a way around it.

And that’s the real problem.

Not execution.
Not process flaws.
Not lack of documentation.

Behavioral resistance masquerading as a technical problem. And you don’t fix that with a fake Gantt chart to fit a certain narrative.

You’re Not Alone in This. We All Get Stuck Here.

I’ve seen brilliant IT leaders, ecommerce directors, and CIOs get completely blindsided by this. People who have led massive, high-stakes projects. People who know how to execute, how to manage complexity, how to keep things moving when everything seems stuck. And yet, when digital transformation, ecommerce adoption, or AI-driven decision-making struggles to take hold, they find themselves in a frustrating loop of resistance and confusion.

Not because they weren’t good at their jobs. Not because they didn’t plan well. Not because they weren’t smart enough.

It’s mostly because no one explicitly tells us that complexity needs to be led differently than complication. It’s a hindsight realization.

You don’t learn this in a project management course. There’s no section in your PMP certification that covers “what to do when the sales team quietly sabotages ecommerce adoption.” A software vendor doesn’t include a chapter on “how to rebuild trust when AI pricing tools make sales reps feel obsolete.” The ERP migration guide doesn’t explain “how to handle process changes that threaten department fiefdoms.”

So when things start going sideways, what do we do? By default we double down on structure. Psssst, that’s code for more meetings and KPI dashboards.

We tell ourselves, "We need more alignment. We need better tracking. We need stricter accountability."

lol none of that fixes the core issue so let’s see how we can contribute as an IT leader.

What Can You Actually Do? (Without Carrying the Whole Organization on Your Back)

If you’ve ever felt like driving digital adoption or leading IT strategy means taking on the emotional baggage of the entire company, your intuition and feeling is right.

I’m not going to sugarcoat it. B2B IT leaders are put in a strange position. You’re not only expected to execute the technology, you’re expected to change how the business operates without actually being given authority over the people and processes that need to change.

That’s why it’s easy to fall into the trap of owning too much, believing that if you work harder, communicate better, and build a perfect roadmap, things will click into place. For seasoned folks, you already know this, but I’m going to reiterate: You can’t force people to change. (I mean you can but uhh we’re talking beyond short term modification of behaviors)

What you can do is set the conditions for adoption, minimize resistance, and put leadership in a position where they have to engage.

Let’s break this down into three strategies that allow you to lead change without becoming the organization’s punching bag:

#1 - Call Out the Complexity (Early and Often)

The first mistake leaders make is not naming the complexity up front.

IT and digital leaders assume that because they see the challenge clearly, others do too. They expect leadership to recognize that adoption isn’t about training, that digital transformation success isn’t just about platform selection, that digital transformation isn’t just an IT initiative.

Don’t assume this. Feel it out.

So before a project even kicks off, put it on the table. Say it with me:

“This initiative isn’t merely a technical rollout, it’s a behavior change effort. We need to plan for that.”

“Success here depends on incentives and internal alignment, not only execution. We need business leaders involved from the start.”

“If we treat this like a traditional IT project, we will get traditional IT results; functional, but underutilized. That’s not success.”

It’s VERY important that we’re not washing our hands and giving ‘not my business, not my problem’ vibes but this does two things:

1️⃣ It prevents you from being blamed for adoption issues later should they arise. If you flag potential resistance upfront, no one can say, “We didn’t see this coming.”

2️⃣ It forces executives and stakeholders to engage. If they want the project to succeed, they need to take ownership beyond IT.

And if you get pushback? That’s good. It means you’re hitting a nerve that would’ve caused problems later. Trust me.

#2 - Shift from Convincing to Aligning

A lot of leaders spend way too much time trying to “sell” change internally convincing stakeholders why the new system, tool, or process is the right move. That’s exhausting. And it rarely works.

Resistance to change isn’t typically about logic and instead about emotion. As humans, we’re strange like that but that’s how it is.

When sales refuses to use CRM, when customers ignore self-service portals, when employees complain about process automation, it’s usually not because they don’t understand the benefits. It’s because they don’t see how it benefits them.

So instead of trying to convince people why change is good, align the change with their self-interest. Such as:

✅ Sales sees ecommerce as a threat? Make it clear that digital tools will help increase their commissions, not replace them. Show them. The ‘whats in it for me’ is very important.

People don’t resist change. They resist loss. If you can reframe change as a gain, resistance drops significantly.

Do you know what my most successful projects have ever looked like? It’s when employees or consumers of the technology say things like:

“I can’t believe we never had this before” or “Please don’t take this thing away from us, it’s amazing!”

#3- Design for Iteration, Not Perfection

One of the biggest lies in enterprise IT is the idea that you can fully define success before you start.

That’s a comforting thought, but in complex environments it’s nonsense.

The best way to drive adoption isn’t to chase a ‘perfect launch’, it’s to build in flexibility while keeping a clear direction. I’m not saying go full Agile manifesto, but you need a plan that bends without breaking. There’s a fine line between looking adaptable and looking like you have no clue wtf you’re doing. On the flip side, if you come in with a rigid, 'my way or the highway' approach, you’ll bulldoze past real concerns and kill buy-in before you even start.

Instead of launching the a full digital platform on day one…Soft launch it with a controlled group of customers, actively monitor behavior, and refine the experience before scaling. Visibility without chaos.

Instead of assuming employees will magically embrace new workflows…Introduce the change in parallel mode first and let them run the old and new process side by side before shutting the old one down. Gives them a lifeline without stalling adoption.

Instead of rolling out a massive IT-led initiative…Find the natural champions within each department, equip them with the tools and context, and let them influence adoption from within. Top-down mandates breed skepticism whereas peer influence breeds trust.

Rigid, all-or-nothing launches almost always fail when they they are both complex and complicated. Whether you like it or not, these things have to marinate and take time.

Lead Smarter, Not Harder

If you’ve ever felt like IT leaders carry too much of the burden for digital success, it’s because you/they do.

Not because you’re doing anything wrong, but because business leadership defaults to letting IT “own” transformation efforts without fully engaging in the hard parts of change.

You don’t have to carry that weight alone. You don’t have to be the sole champion for adoption.

What you can do is:

✅ Call out complexity before it blindsides everyone.
✅ Align change with self-interest instead of trying to sell it.
✅ Design for real-world iteration, not theoretical perfection.

If you do these things, you shift from being the person responsible for making everything work to being the leader who creates the conditions for success without carrying the entire organization on your back. You’ve got enough to carry already.

You’ve Got This.

If you’ve been frustrated with adoption, culture shifts, or slow-moving change then you’re not alone. Recognizing complexity for what it is doesn’t make the work easier, but it gives you the perspective to navigate it without losing your mind.

That’s what separates tactical execution from real leadership.

Leave a comment

I’ve been on both sides of this.

As a consultant, I delivered advice and implementation *gasp*. As an IT leader, I made the call on whether to bring in external help or keep it in-house with intention.

What worked in the past for consulting organizations, particularly focused on the “management consulting” function is not going to keep working.

For decades, many big service firms won work through sheer manpower, attrition, and brand recognition. The old playbook by internal leaders? Bring in the safe option because, hey - “Nobody ever got fired for hiring [Big 4 Firm].” You’d get an army of consultants, a polished strategy deck, and a sense of security that your stakeholders wouldn’t question the decision.

That’s changing.

Subscribe now

AI and LLMs aren’t replacing expertise, but they are shrinking the time it takes to get from problem to action. The moat that consulting firms built; access to knowledge, research capabilities, high-end analysis is shrinking.

It’s not just the consulting firms that need to adjust. Internal IT teams need to step up, too. Because now executives are starting to ask:

If we have instant access to information, why do we still need to bring in outside help?

The Crumbling Foundation of 'Safe Bet' Consulting

For decades, bringing in a well-known consulting firm was the default move for IT leaders. Need a strategy roadmap? Hire a firm. Struggling with an ERP rollout? Bring in external experts. Even when internal teams had a good grasp of the problem, an outside firm was often called in to make stakeholders listen.

It worked.

Not necessarily because consulting firms always had “game-changing” insights, but because they were a risk that was mitigated. If leadership pushed back on a decision, you could point to the high-priced consultants and say, “See? They said the same thing.” Nobody ever got fired for hiring [insert big firm here]. An expensive insurance policy, as it were.

But I’m seeing that playbook breaking down fast and it’s starting to erode service organization’s practice areas. Blame the economy, politics, or uncertainty all you want, but those are constants. There’s a bigger shift happening.

AI and LLMs are shrinking the time it takes to move from problem to action.

The once-exclusive knowledge that consulting firms built their business on is now accessible in seconds. It always was, but a browser search bar and thousands of results had to be meandered through, consolidated, and absorbed. That was just enough friction to outsource the work by clients. Now it’s served on a silver platter via Perplexity/ChatGPT/Claude/etc. - maybe not perfect but it has undoubtedly saved a shit ton of time and much less expensive than a $225/hr. rate associate.

Meanwhile, IT leaders are being asked:

If information is abundant, why are we still paying six/seven figures for research we could do ourselves?

It’s a wake-up call. Not only for consulting firms, but for IT teams as well. External expertise still has value, but the reasons for bringing it in are under scrutiny. The days of outsourcing endless analysis are fading. IT leaders don’t need more fluff, they need sharper, more actionable advice in order to get things done.

The new game isn’t about paying for quantity of thinking, but for the kind of expertise that actually puts them closer to rubber meeting the road.

Execution and capability expansion matter more than ever.

You’ve already started to notice the big firms pivot to teaching how to best use AI and LLM’s. The equivalent of teaching you how to use a shovel to dig for gold. That will work…for a while. The dynamics in the industry are moving and value is eroding as more internal functions within organizations are better equipping themselves.

But one looming question remains: If firms are able to leverage AI to work faster and more efficiently, will their rates and total project costs reflect that efficiency?

Will consulting firms pass those savings onto their clients, or will they pocket the gains while still charging legacy rates? The answer to this will determine which firms remain relevant and which become outdated relics of a bloated industry.

I see this as a great thing overall and will expose those hiding behind 0 substance.

The New Consulting Landscape: A Summary

• Big firms are losing their “safe bet” status. Brand power alone isn’t enough anymore.

• AI and LLMs are shrinking the research & strategy moat. Knowledge is no longer exclusive.

• Executives are questioning the value of external help. If insights are instant, why pay six figures?

• Consulting firms are pivoting to teaching AI use. But selling shovels instead of gold only works for so long.

• IT leaders must be more selective.

We’ve got a pressure cooker of ingredients here, so if you’re an IT leader then you best take notice and adapt.

When Should IT Leaders Actually Bring in External Help?

Here’s how I think about it in simple terms when identifying whether I may need external expertise or not:

1️⃣ Do we already have access to the knowledge or data?
➡️ Yes → Don’t outsource thinking. Move on.
➡️ No → Keep going.

2️⃣ Is this knowledge truly proprietary or difficult to acquire?
➡️ Yes → Maybe worth bringing in.
➡️ No → Keep moving.

3️⃣ Is my team too stretched to execute effectively?
➡️ Yes → Execution support makes sense.
➡️ No → Why outsource?

4️⃣ Is this a one-time need or a recurring competency?
➡️ One-time → External help might be fine.
➡️ Ongoing skill? → Build it internally.

5️⃣ Is this critical to our competitive advantage?
➡️ Yes → Keep it in-house or work with highly specialized partners.
➡️ No → Maybe outsourcing makes sense.

Stop outsourcing so much thinking. Start outsourcing execution if you really need to.

It’s clearly not always as simple as that and there’s much more nuance to each situation, but you get the gist. There’s a lot of money to be made in analysis paralysis and busy work but you can avoid that.

Where External Help Still Makes Sense

I’m not saying external services are dead. But the why and when are shifting.

When You Should Bring in External Expertise:

• You need compliance expertise that your team will never develop in-house.

• You’re rolling out a massive ERP and don’t have the resources to lead the implementation.

• A third party has proprietary benchmarking data that can reshape your strategy.

• You need a very targeted SME based on their individual skillset and experience.

When You Should Keep It Internal:

• You’re outsourcing research that your team could do in an afternoon.

• You’re hiring an IT strategy consultant to tell you things you already know.

• You’re relying on a consulting firm for core business capabilities that should belong to your company.

You might be saying “no shit, Sherlock”, but common sense isn’t as common as you’d think.

The Dual Wake-Up Call For Both Consulting Firms and IT Leaders

Look, I’m not anti-consulting. Not even close. I’ve spent half my career working in IT professional services. I’m saying the quiet parts out loud.

I do think the consulting and IT services industry is overdue for a reality check. It was already in an overleveraged position with bloated projects, extremely high rates, low value-roles pumping billable hours. Do you know how many endless hours are spent on slide decks?

If you want to humor yourself, visit reddit.com/r/consulting. I contribute to that subreddit more than I’m willing to admit.

Now the tables are turning. The question of value is being critiqued hard. The days of bringing in a firm just because it’s the “safe bet” are shrinking.

Executives are getting smarter about this. Internal teams are expected to do more. AI is reducing the need for bloated analyst work. And the firms that only provide recycled knowledge via classic Management Consulting engagements? They’re in trouble. It will not disappear, but the herd will be thinning.

The winners will be those that do at least one of the following:

✔️ Have proprietary data that can’t be sourced from public LLMs.
✔️ Offer efficient execution and capability expansion, not just advice.
✔️ Help internal teams scale instead of replacing them.
✔️ Dominate niche industry verticals.
✔️ Bring skills that are too expensive or rare to build in-house.

On the flip side, IT leaders need to wake up to the new reality, too. You can’t always lean on consultants because “that’s how we’ve always done it.”

You need to own your expertise and be selective about where external help actually moves the needle. You have more tools in your toolbox now.

IT leaders who keep defaulting to the “safe bet” will wake up to find that safe no longer means smart.

/end rant

Leave a comment

IT pros used to learn by breaking things, fixing them, and actually understanding how stuff worked. Now? AI, Google, and instant answers. Fast, but shallow. If you don’t know why something works, you’re pasting fixes, not solving problems. Modern tools are great, but real expertise still matters.

The Shifting Landscape of IT Knowledge

Learning IT used to be a grind.

You had to break things, fix them, and break them again just to understand how they worked. No instant answers, no AI-generated solutions, just you, a manual, and hours of frustration.

But now everything is different.

AI, Google, and endless online resources have changed the way we learn and absorb (or not) information.

The journey of IT professionals has transformed from hands-on tinkering to leveraging AI-driven tools as a wedge. This evolution raises a question:

Has this shift made IT pros wiser, or merely quicker at finding answers?

Breaking Things: The Original IT Bootcamp

Let me paint you a picture of old-school IT learning: It's 2AM, you're surrounded by Cisco manuals that could double as doorstops, squinting at a PuTTY terminal while questioning your life choices. Why? Because you fat-fingered ONE configuration setting and lost remote access to the device in a datacenter 6 hours away. Totally didn’t happen to me…nope.

And you know what? Those were the good ol’ days.

I'm not some greybeard reminiscing about punch cards because I’m not THAT old - I cut my teeth building PCs at eight years old, when "tech support" meant praying your computer would POST.

But even in my professional journey through infrastructure and cybersecurity, learning meant one thing: breaking stuff and fixing it yourself. The amount of things I broke after-hours that nobody really knew about in the business is astounding. I work best under pressure anyway.

The old-school IT curriculum looked something like this:

• RTFM: Picture yourself decoding technical documents that made tax codes look like light reading. No ChatGPT summarization here - just you, caffeine, and endless pages of protocols.

• Forums & Usenet Groups: Where simple questions like "How do I configure BIND?" sparked 47-page flame wars about DNS architecture. But buried in those threads? Pure gold.

• Trial & Error: You haven't truly lived until you've accidentally dropped a production database. Ask me how I know.

• Mentorship: Learning from battle-scarred veterans who had already made every mistake you were about to make (and invented a few new ones).

This method built a deep, almost instinctive understanding of systems. You didn’t just know the answer, you understood why it worked. That kind of knowledge sticks and is referred to as “wisdom”.

I’m no greybeard in terms of age, but a strong 60% of my learnings and cutting my teeth in infrastructure, security, and operations were through this method. At about eight years old I ventured beyond video games and started to build and repair PCs. These early experiences laid the foundation for a career defined by hands-on problem solving.

Anecdotally, as a kid, my old man used to say “The wisest man is the one who made the most mistakes” a lot. Ironically, I never really saw him make mistakes. Only later in life would I realize that I was doing the EXACT same thing. We both make mistakes, but they are calculated and quickly recovered (mitigated) as a part of the learning process.

This is a stark contrast to today’s learning environment.

The Manufacturing Floor Parallel

This reminds me of something I see constantly in manufacturing environments. Walk into any production facility built before 2010, and you'll find machines running on Windows XP, controlled by proprietary software that hasn't been updated since the Bush administration. These systems keep running because of one 58-year-old maintenance tech who's been there since the equipment was installed. He doesn't have documentation, it's all in his head. The company relies entirely on his tribal knowledge.

And it works! Until it doesn't. Until he retires, or the one replacement part they need is no longer manufactured, or a security vulnerability finally gets exploited (because you totally didn’t air gap the thing).

Then it's all hands on deck, production stops, and suddenly everyone wishes they'd invested in understanding how things actually work rather than just keeping them running. Meanwhile the poor IT person is trying to connect to this machine via 6 adapter dongles daisy-chained together.

We’ve all been there. Those situations build character.

IT knowledge follows the same pattern. You can paste solutions from ChatGPT all day long, but when something truly breaks, you need that deep understanding that only comes from having broken and fixed things yourself.

The Modern IT Classroom: Stack Overflow and Pray

Today's landscape is... different. Why spend hours understanding BGP when you can copy-paste from ChatGPT? Need to configure a firewall? There's probably a TikTok for that. Need a code snippet to customize your ERP? There’s a reddit thread with your exact problem and solution.

Don't get me wrong - I'm not here to yell at clouds. These tools are incredible, but they're creating a generation of IT pros who can follow recipes without understanding the ingredients. It's like being a chef who can only cook by watching YouTube tutorials.

When something hands you the answer without requiring you to understand the underlying mechanics, you risk becoming just an operator instead of an engineer.

The convenience is great until you hit an edge case AI can’t solve.

Learning now looks like:

• Google, Stack Overflow, and AI Tools: The answer to almost any problem, just a few keystrokes away.

• Interactive Labs & Virtual Sandboxes: Experimenting without the risk of bricking a system.

• Low-Code & No-Code Solutions: Making things work without needing to understand how they work.

• Video Tutorials & Online Courses: Bite-sized lessons for quick consumption.

It’s convenient. It’s efficient. My issue with it is that many newer IT pros are great at following steps, but not at understanding what’s happening under the hood. If the AI-generated solution doesn’t quite fit? They’re stuck. I predict we’ll see this reverb of issues when solutions don’t follow the happy path and don’t have resiliency built into them.

The Right Balance is AI as a Tool, Not a Crutch

AI isn’t the enemy. It’s a powerful tool if used correctly. It’s just that though…a tool.

The best IT pros I work with know that blending old-school depth with new-school speed is what sets them apart. Relying solely on AI to spit out answers? That’s a recipe for shallow knowledge. Ignoring AI altogether? That’s being stubborn and probably unemployed soon.

The real magic happens when you combine both approaches. Building, breaking, and fixing systems instills a deep-rooted understanding, while AI can handle repetitive tasks, freeing you to tackle more complex challenges.

It's the difference between knowing how to use a tool and understanding how that tool was built. Both have value, but only one will save you when everything's on fire and the standard solutions aren't working.

IT pros who thrive in this era won’t be the ones blindly following AI-generated solutions, nor will they be the ones clinging to outdated ways. They’ll be the ones who embrace efficiency while staying grounded in the fundamentals.

With the changes I’ve mentioned, I STRONGLY encourage you to work on the below skills, as they are abilities that will keep you resilient in the job market and set you apart:

Self-Assessment for IT Leaders

If you’re leading an IT team, ask yourself these questions:

1. Am I using AI as a tool to learn, or as a shortcut to get things done?

2. If AI and Google disappeared tomorrow, could I and my team still troubleshoot effectively?

3. Does my team understand the tech we rely on, or just follow scripts and apply patches?

4. Am I hiring and training problem-solvers, or just people who know how to Google?

5. Is IT in my company a strategic function, or just an over-glorified helpdesk?

Fast is good. Smart is better. Build both. If you let one lapse for too long, you’re going to run into situation where your team as no depth of wisdom to them, or the opposite…relying on a single rockstar to carry the weight.

The Future of IT Learning: Blending AI with Human Expertise

The IT field has always been shaped by adaptation and problem-solving. AI is simply the next evolution, but it should not fully replace human expertise. The best IT professionals will be those who:

✅ Use AI to enhance their expertise, not replace it.
✅ Question and validate AI-generated solutions instead of blindly accepting them.
✅ Develop human skills like problem-solving, leadership, situational awareness, and adaptability to stay irreplaceable.

If you're relying purely on AI to solve your problems, you're not an IT professional - you're just a very efficient Googler with admin privileges.

When the robots finally take over, they'll keep around the humans who know how to fix them. Be that human.

AI isn’t coming for your IT job, but it is changing rules. Just like cloud, automation, and every other tech shift before it, AI is taking the repetitive grunt work off your plate. The real risk isn’t AI itself, it’s the rise of “synthetic experts,” people who lean on AI without actually knowing what they’re doing. If you ignore this, you’re setting yourself up to be replaced, not by a machine, but by someone who knows how to use one better than you. IT leaders who sit on the sidelines will watch their teams become obsolete while the competition builds a smarter, faster, AI-assisted operation.

So you're an IT pro, minding your business, configuring servers and whatnot. Then suddenly AI shows up like that annoying coworker who always has to one-up you. "Oh, you spent three hours debugging that script? That's cute. I did it in 3 seconds."

The rise of AI has triggered existential anxiety across industries, particularly in IT. Every few years, a new technology emerges that’s supposedly going to replace jobs wholesale. We’ve seen this before with automation, cloud computing, and now AI.

AI isn’t going to take your IT job outright. Instead, it’s going to reshape the landscape of IT, making some professionals more valuable than ever and others, well... redundant.

As Gartner recently noted in their "Top Strategic Technology Trends for 2025" report:

15% isn’t a ton, but it’s a whole lot of busy work that probably comprises certain individuals vast majority of their workload.

What else?

“Jobs are being eliminated within the IT function which are routine and mundane, such as reporting, clerical administration. As they start looking at AI, they’re also looking at reducing the number of programmers, systems designers, hoping that AI is going to be able to provide them some value and have a good rate of return.”

— Victor Janulaitis, Janco Associates

Hmm ok, great take and I tend to agree.

Before you start polishing your resume for a career pivot to artisanal cheese-making, take a deep breath.

For the greybeards it does bring about a foreshadowing uncertainty that isn't just understandable, it's necessary for adaptation.

Let's break down why AI's presence in IT isn't a death knell, but a call to evolution. If you’ve been in the IT space long enough, this isn’t your first rodeo.

Subscribe now

Technology Doesn’t Replace Professionals. It Exposes Them.

Being in IT my whole career has taught me that technological advancements don’t eliminate skilled professionals in of itself, it elevates them. But they also mercilessly expose those who refuse to adapt.

Consider these shifts that reshaped IT over the last two decades (that I personally experienced):

• Mass migrations from physical to virtual servers – Those who resisted virtualization got left behind.

• The rise of cloud computing – IT pros who ignored AWS, Azure, GCP, and SaaS adoption found themselves outdated.

• The automation of IT operations (DevOps, IaC) – Manual sysadmins lost relevance while engineers who embraced Terraform, Kubernetes, and CI/CD pipelines thrived.

• The explosion of cybersecurity threats & zero-trust models – IT teams that failed to adapt to modern security postures became liabilities.

• The blend of OT and IT - Operational and Information Technology lines blurred with sensors and IoT powering production and analytics.

AI is no different. The question isn’t whether it will replace IT professionals. It’s whether you’ll be one of the professionals who learns to harness it.

Agentic AI and LLMs will eliminate certain types of IT work, without a doubt. Some roles will disappear and others will consolidate. But if history is any guide, new roles will emerge favoring those who evolve. If your role has been built on executing predictable tasks without critical thinking, AI might just pull back the curtain on your limitations.

Don’t want to evolve? Well, like a blue shell hitting you in Mario Kart, everyone else is now catching up. AI is that artificial rubber-band catch up mechanic now in place.

Those that are catching up quickly have a downside, too. This is just another phase of learning and adaptation in IT.

The Rise of the "Synthetic Experts"

The ease of accessibility and utilizing AI in both purpose built platforms, and even embedded into business apps now, has resulted in an interesting scenario.

I call it the "synthetic experts" phenomenon.

Imagine a world where anyone with a chatbot and a prompt can troubleshoot a network issue, deploy a virtual machine, or fine-tune a security policy. That world isn’t years away - it’s now.

It’s not so simple though: knowing how to execute doesn’t mean understanding why it’s the right (or wrong) choice. AI gives instant solutions, but without critical thinking, it also creates instant liabilities.

And this is both thrilling and terrifying. It’s like Stack Overflow and Quora served on a silver platter.

In hindsight, this was me with access to the internet as a young teenager. I was not necessarily smart in the traditional sense, but I was fantastically resourceful, relentless with understanding topics, and had a great memory. Turned out to be enough of a cocktail to do well in starting my career. Thanks, internet.

In the manufacturing and distribution companies I work with, I’m seeing very regular use newish tech:

• Distribution center managers are using AI tools to optimize warehouse layouts and dynamically adjust slotting.

• AP teams are deploying AI-powered OCR and document processing tools to extract and reconcile purchase order information without IT involvement.

• Marketing teams in industrial mfg are using AI to generate product descriptions and promotional materials.

Tasks that once required IT intervention are becoming democratized. Again, this is amazingly cool to see and yet scary at the same time. Maybe this is what HR means by “employee empowerment.”

But here’s what everyone misses: being able to generate a solution isn’t the same as understanding its implications. I’m going to handwave all the shadow IT, data governance issues, etc. for now…that’s for another article.

The real risk isn’t AI, it’s organizations mistaking surface-level execution for real expertise. You’ve probably noticed this when an AI generated piece of code, or something copy-pasted from Stack Overflow breaks and the person who put it in struggles to remediate the issue. Why something works the way it does, how it operates, what it’s implications are, and where the pros/cons lay is all a part of expertise.

When somebody who had relied on other systems without inherent knowledge, it will become apparent with the imposter syndrome that then takes effect immediately after. High and mighty confidence turns to dust.

Just as professionals who don’t adapt become exposed, those that have been naturalized through AI LLM’s without an understanding of how things work will as well.

Gap 1 above represents the synthetic experts artificially catching up. This is followed immediately by Gap 2, which represents the “expertise” skill gap that presents itself. As an exception, a few synthetic experts will be able to recover quickly though - they would have done this without the hamstring of AI or LLM’s eventually anyway.

This lowers the floor of entry into IT, allowing less-experienced individuals to perform tasks that once required a seasoned professional. Often basic tasks.

The Three Types of IT Professionals

In traditional B2B environments, I sort of see AI reshaping IT roles into three distinct categories:

The Automators (AI is Replacing Them)

Routine, repeatable tasks? AI handles them faster, cheaper, and at scale. This is definitely that 15% of effort that Gartner mentions.

❌ Who’s at risk? Script writers, basic troubleshooters, configuration managers.

❌ Survival strategy? Move up the pyramid or get automated out of a job.

The Integrators (AI is Supercharging Them)

They don’t fear AI. They wield it.

✅ Who thrives here? Cloud architects, DevOps engineers, security analysts.

✅ Key to success? Master AI-driven automation, infrastructure-as-code, and system optimization.

The Strategists (AI is Making Them Indispensable)

They bridge technical possibilities with business realities.

🔝 Who’s winning? CIOs, IT Directors, Enterprise Architects.

🔝 Why? Because AI struggles replacing strategic thinking, business alignment, leadership, and general human nature.

In general, the skillset floor has risen but the ceiling has stayed relatively stagnant (so far). The bottom of the skillset pyramid isn’t the only one affected though. Rest assured that everything and everyone is impacted. Middle management? Need less IMO. Leaders with big titles and yet still individually contributing? Likely even more of that. Doing more with less? 100%. This very much applies to your typical IT department in a B2B organization.

Here’s how this might look if we were to apply AI to skillsets in layers:

AI is finding it’s way into every part of the pyramid, and also making those things at the bottom like a rising tide. So what can one do?

How to Stay Ahead in an AI-Augmented World

For IT Veterans:

✅ Your experience is an asset, not a liability. AI doesn’t replace decades of contextual knowledge. You actually know how shit works on a fundamental level. While AI can generate solutions, it lacks the critical intuition that comes with experience.

✅ Stop resisting AI, start orchestrating it. Instead of seeing AI as competition, think of it as an augmentation tool. Use AI to enhance decision-making, automate tedious tasks, and allow yourself to focus on high-value, strategic work.

✅ AI can automate tasks, but it still needs oversight. Your role evolves into being a curator, validator, and strategist, ensuring AI-generated solutions are both technically sound and business-aligned. Learn how to guide AI instead of fearing it.

✅ Mentor the next generation of IT professionals. They might have AI fluency, but they lack real-world context. Your ability to teach nuance, edge cases, and long-term thinking will make you indispensable.

For IT Newcomers:

✅Your comfort with AI tools is an advantage, but it’s not enough. Mastering AI tools will help you get ahead, but real value comes from knowing when and why to apply technology, not just how to use it.

✅ Develop a strong business mindset. Understanding how technology impacts revenue, operations, and customer experience will differentiate you from those who only focus on execution. Learn how your organization makes money and how IT contributes to that.

✅ Build relationships across departments. AI won’t replace the human side of IT. Being able to collaborate with stakeholders, communicate effectively, and align technology with business goals will be important in an AI-enhanced workplace.

The Future Isn’t Binary

The AI revolution in IT isn't about replacement, it's about transformation. If your value comes from deep knowledge, problem-solving, and business alignment, you have little to worry about. In fact, you’ll probably become even more valuable.

Just as calculators didn't eliminate mathematicians, AI won't eradicate IT professionals. Instead, it will reshape the landscape, creating a divide between those who adapt and those who don't.

The real threat isn't AI taking your job; it's your peers who master AI outpacing you.

🚀 Are you and the IT team evolving fast enough? Or is that blue shell a knock out punch and you’d rather be a goat herder?

Leave a comment

If you’re an IT leader in manufacturing or distribution, you’ve probably realized that the playbooks written for Silicon Valley don’t quite apply to your world. Mid-market and enterprise manufacturers and distributors have unique challenges. Legacy systems, complex supply chains, fragmented data, and a business culture that’s skeptical of technology investments.

This Substack is for CIOs, VPs of IT, IT Directors, Digital Leaders, or those who are aspiring to be one. If you’re a functional leader outside of IT, maybe it will help you understand the disposition of your peer better too.

Here you’ll find practical insights on how to modernize, align IT with business strategy, and ultimately drive value beyond keeping the lights on.

I’ve been in your shoes and seen some stuff, so to speak. If you’ve ever had to explain to your CEO why a 25-year-old ERP won’t support AI, or if you've spent a year trying to integrate a new eCommerce platform only to have sales complain about ‘too much change’ then you’re in the right place.

My goal is to help IT leaders cut through the noise, make smart decisions, and lead with confidence.

Throughout the posts you’ll find a fair amount of satire, humor, and slightly-better-than MS Paint drawings. It’s "on brand” as the kids would say.

Subscribe now

What Makes IT Management in Manufacturing & Distribution Unique?

Manufacturers and distributors are operationally intense, asset-heavy, and process-driven. While SaaS startups and retailers chase innovation at breakneck speeds, you’re dealing with:

✅ ERP Ecosystem Complexity

You don’t have a single “system of truth”; you have an ERP, a PIM, a WMS, a CRM, and spreadsheets floating in email threads.

✅ Legacy Tech Debt

Many companies still rely on 20-year-old AS/400 systems, Excel-based processes, and on-prem applications that don’t integrate well with modern solutions.

✅ Channel Conflict & B2B Selling Complexity

You’re managing customer expectations across direct sales, ecommerce, distributors, and marketplaces, all while trying not to upset existing relationships.

✅ CapEx vs. OpEx Funding Battles

IT investment requires board-level buy-in, and there’s constant tension between long-term strategic bets and quarterly P&L pressures.

✅ Culture & Change Resistance

Many executives still view IT as a cost center rather than a strategic enabler, which means you have to sell every technology investment like a business case.

Why IT Leaders in This Space Struggle

Great IT leaders in manufacturing and distribution do more than maintain infrastructure. They play a role much more diverse than keeping the lights on.

However, many struggle to escape patterns that limit their ability to lead strategically.

Instead of shaping long-term technology strategy, they get pulled into constant problem-solving. ERP issues, security threats, integration failures, and compliance audits demand immediate attention, making it difficult to focus on initiatives that drive real business value.

At the same time, IT is frequently left out of key business decisions.

Without a seat at the table early in the process, organizations experience shadow IT, failed digital initiatives, and misalignment between business goals and technology investments. When IT is treated as a support function rather than a strategic partner, digital transformation efforts fall short.

We end up in this stalemate of finger pointing of either trying to budge into everything, hampering progress, or not working fast enough.

Breaking free from these patterns necessitates a shift. IT must move from reactive problem-solving to proactive leadership, from being seen as a cost center to a driver of business strategy, and from doing everything alone to building the right mix of internal capability and external support.

Huge Opportunities for IT Leaders in Manufacturing & Distribution

Even with the constraints of the industry and the general positioning of technology, there are significant opportunities for IT leaders to become trusted business partners in their organization:

💡 IT Can Be the Bridge Between Silos

• Most manufacturers and distributors suffer from data silos. ERP, CRM, eCommerce, WMS, PIM… they don’t talk to each other.

• Opportunity: IT leaders who integrate systems and unlock real-time data can give functional business units what they need.

💡 AI & Automation Are Actually Useful Here

• Unlike some industries where AI is a shiny toy, AI and automation can drive massive efficiency in demand forecasting, inventory management, and pricing optimization. That data thing? You’ve got quite a bit of it.

• Opportunity: IT leaders who build a strong data foundation can make AI investments actually deliver ROI.

💡 IT Can Directly Influence Revenue

• IT is mostly seen as a cost center, but digital commerce, self-service portals, and better customer experiences are driving real revenue.

• Opportunity: IT leaders who frame initiatives in business terms (e.g., “This will enable the increase of sales velocity by 15%”) will get executive buy-in faster.

💡 Cybersecurity is a Differentiator, Not Just a Cost

• Supply chain attacks, ransomware, and compliance risks are only increasing. Companies that proactively secure their data and operations will have a competitive edge. It’s survival of the fittest in more than one way.

• Opportunity: IT leaders who lead cybersecurity initiatives can protect the business and build trust, especially with customers who demand secure integrations and organizational resiliency.

💡 IT Can Fix the Talent & Workforce Problem

• Many manufacturing companies struggle with labor shortages and tribal knowledge locked in retiring employees.

• Opportunity: IT leaders can digitize and automate processes, capture critical knowledge, and enable remote collaboration to bridge the skills gap. Maybe not eliminate it, but minimize it.

💡 Modernizing B2B Commerce

• Manufacturers and distributors who embrace eCommerce and self-service portals are winning market share from those who rely only on sales reps.

• Opportunity: IT leaders who enable frictionless B2B transactions can help their company outmaneuver competitors.

How IT Leaders Can Stay Ahead

To stay ahead, IT leaders must bridge technology and business strategy, ensuring IT is a competitive advantage rather than a back-office function. This means engaging in product strategy, supply chain decisions, and sales enablement while framing technology investments around profitability, efficiency, and customer experience.

IT should not be seen as a cost center but as a driver of growth, translating technical initiatives into business impact; faster order fulfillment, increased revenue, and improved customer interactions.

That being said, it is on you to help be a catalyst for this, it won’t be served up for you on a silver platter.

What to Expect from This Substack

Every 7-10 days, I’ll publish a concept, trend, insight, or advice to help IT leaders navigate digital transformation in manufacturing & distribution. You can expect:

📝 Practical IT Strategy – How to align IT with business growth
⚙️ Technology Deep Dives – ERP, eCommerce, AI, cloud, and cybersecurity insights
📈 Leadership & Career Growth – How to level up as an IT leader
🔥 B2B Digital Trends – What’s happening in the industry & what you should care about

If you’re looking for real-world advice from someone who’s been in the trenches, I’d appreciate you subscribing. I’m not in it for the “money” or “fame”, I’m in it to advance an industry I’m passionate about.

Technology should be a competitive advantage, not just an IT budget line item. Let’s try to make that happen.

Leave a comment

Relying on IT "rockstars" isn't heroism; it's playing Russian roulette with your business. These go-to experts become single points of failure, turning your team's strength into a ticking time bomb. When your rockstar burns out or bails, your operations are left hanging by a thread. IT leaders have got to dismantle this fragile setup by promoting knowledge sharing, thorough documentation, and team-wide problem-solving skills. Your goal? Build a resilient crew where no single person holds all the keys, ensuring your business doesn't crumble when your "hero" takes a hike.

Picture this: It’s 2 AM. Your lead system administrator is knee-deep in a silent server room that smells like anxiety, stale coffee, and existential dread. Servers are down, the warehouse crew is hours from mutiny (where’s your business continuity plan anyhow?) and for the sixth time this quarter you’re relying on one person’s ability to MacGyver a fix. Again.

“But they always figure it out!” you tell yourself.

This isn’t heroism, it’s organizational Russian roulette. And if you’re honest, you’ve known this for years. Time to dig into why we keep pulling the trigger.

Subscribe now

The Corporate Hunger Games: Enterprise vs. Mid-Market

Walk into a Fortune 100 IT department and you’ll find:

• Dedicated teams for every tech niche

• Meetings about meetings about cloud strategy

• Enough middle managers to start a golf league

Now enter a typical B2B company:

• Your network admin moonlights as the ERP therapist

• The IT Manager also support’s the CEO’s home network

• Everyone’s calendar looks like a Tetris game from hell

It’s like comparing a symphony orchestra to a one-man band. Both make music, but one has the luxury of dedicated performers while the other is juggling instruments more than playing harmonics.

This duality creates a dangerous Convergence Zone where urgent fixes and long term strategy collide.

Survival here requires an adaptable team that can sway between the pendulums of averting crisis and strategically architecting technology. A common occurrence for most IT teams in traditional B2B organizations staffed between 10-50 FTEs.

On one end, being single threaded at crisis resolution becomes apparent immediately. Whereas on the other end of the spectrum at the strategic level, you won’t feel the impact of a rockstar missing between a Monday and a Tuesday.

This happens at both the team level, but even more so the individuals that make up the unit. This is where things get hairy.

Meet Brent: Your Company’s Biggest Liability

Anyone who's read "The Phoenix Project" knows Brent. Brent is the brilliant engineer who becomes both the hero and the single point of failure. He's the person everyone calls, the one who knows every system intricacy, the technical superhero who saves the day but inadvertently creates organizational fragility.

It's a trap that catches even the most well-intentioned teams. As Bill, Brent's manager in the book, laments, "Can't we do anything without Brent?" This isn't only a management frustration, it's a critical risk that derails entire technological ecosystems.

Brent is seemingly fantastic at his job, but he’s also:

• The Keeper of Tribal Knowledge (documentation? never heard of her)

• The Human API between departments that refuse to talk

• The Walking Risk Register (PTO? ha.)

There are versions of Brent in just about every midsized B2B organization. In fact, it’s not limited to IT. You’ll find this person in Accounting, Sourcing, Logistics, Assembly, Welding, etc. Do you have this person?

Is there visible team anxiety when this person is out of office?

Is there one person who needs to be in EVERY important meeting?

Does your bus factor hover dangerously close to 1?

Can a new team member understand your systems/processes within a reasonable onboarding period?

This is traditionally a very tenured person or somebody who has got themselves involved in every big project or initiative and has a relentless drive to figure things out. I can attest to being that latter person and having to de-Brentify myself proactively due to the risk it bears as you fast forward in time. I’ve also inherited Brents.

It might be a bad sign if your organization is having a succession planning exercise and the topic of “Who is the biggest risk to this company?” comes up and that person is in your department. Source: Guilty.

The paradox is the more indispensable they become, they closer your company inches towards disaster. Brent is one missed alert away from rage-quitting to start an alpaca farm.

This hero culture works until it doesn’t. You find out VERY quickly how reliant your organization is not only on technology, but individuals, in order to operate. There’s more single points of failure than most people realize.

The High Cost of Hero Culture

Here’s the uncomfortable look in the mirror: Your “rockstars” are liabilities in disguise.

Every time Brent saves the day, you’re trading short term relief for long-term fragility and incentivizing knowledge hoarding.

Worse? You’re stunting your team’s growth. Juniors don’t become architects by watching Brent work. They learn by breaking things and then fixing them. Last but not least, you’re creating an invisible ceiling for your organization’s growth because no company can scale faster than its bottlenecks.

The Antidote: From Hero Worship to Collective Resilience

Fixing Rockstar Syndrome isn’t about cloning Brent, it’s about making the idea of Brent obsolete. I know that sounds harsh but we’re doing it in the healthiest way possible. Here’s how:

Start with process documentation, but make it meaningful. Don't create documentation for documentation's sake. Focus on capturing the critical decision points: Why did you choose this solution? What didn't work? What dependencies weren't obvious at first?

Create breathing room for knowledge transfer. This means carving out time when systems aren't on fire. Schedule regular technical deep-dives where your subject matter experts can share their expertise. Make it part of their job, not an afterthought.

Most importantly, redefine what success looks like. A team's strength isn't measured by how quickly your rockstar can fix a problem, it's measured by how many people can solve it independently. Track metrics that matter:

• Number of incidents resolved without escalation

• Percentage of critical systems with documented recovery procedures

• Time spent on proactive improvements versus reactive firefighting

The goal isn't to make your technical experts obsolete—it's to free them to focus on more strategic work while building a more resilient organization. Because the best technical leaders don't create dependency; they create capability.

The New Rockstars: Teams That Thrive When Heroes Retire

Given most B2B IT budgets and how risk appetites are managed, you can only build and architect so much technical resilience like fail over, backups, or redundancies to mitigate as many issues as possible. There will always be issues that arise. You’ll also have a finite amount of human resources available.

Most IT organizations stop at the technical resilience portion. There are a significant amount of levers to be pulled in order to build people resilience within your team and for the betterment of the whole organization.

You’ll never have 100% people resilience, but getting it to the point of diminishing returns is something I would say is the exception to the rule, which is shocking considering the potential benefits all around.

The least you can do is try. As an IT leader, you need to be building resilient systems AND resilient teams. The business relies on it.

Your Turn: Break the Cycle Today

• Leaders: Pick one system only your version of Brent understands. Schedule a knowledge transfer by EOD Friday.

• Brents: Document one tribal secret this week. Share it.

Over the course of time, your rockstar firefighter will be able to spend more brain calories on the strategic end of the spectrum. This won’t happen overnight and it may be unnatural at first, but it will begin to develop a wide adaptable skillset that benefits the individual, team, you, and the business.

Final Perspective

Your organization's technological strength isn't measured by how quickly you solve problems, but by how well you transform individual smartness into collective capability.

The true rockstar isn't the person who knows everything—it's the team that can learn, adapt, and grow, with or without any single individual.

The only thing worse than a 2 AM crisis is knowing there’s only one person who can solve it.

Leave a comment

Big projects are expensive. But the real problem isn’t the price tag, it’s the shock when people don’t understand why costs skyrocket. Every extra department, legacy system, and approval loop turns a simple initiative into a slow-moving, budget-burning monster. IT leaders who don’t get this will end up stuck in never-ending steering committees while the business loses patience. Stop pretending complexity is free, set realistic expectations, and run projects with clear priorities…or get ready to watch them spiral out of control. Everyone knows when they are on a death march.

I've noticed something interesting in my conversations with companies about digital transformation projects and initiatives. There's always this moment, right after I or someone walks through a detailed proposal, where a stakeholder shifts uncomfortably in their chair and says:

"This seems...expensive."

They're right. It is expensive. And you know what? It should be.

Let me explain why this isn't just okay, it's expected.

Subscribe now

The Reality of Scale and Complexity

I've been the proud sponsor of more enterprise technology projects than I care to count: ERP conversions that made Finance lose sleep, ecommerce tech stack implementations that Marketing swore would revolutionize everything, HRIS migrations that HR both loved and feared, and infrastructure overhauls that only IT understood.

Through all of these, I've noticed a pattern that's almost mathematical in its consistency: the cost of a project directly correlates with how many business processes and employee groups get pulled into the mix.

Think about it this way:

When you're working on a small IT initiative that affects one department and maybe touches a couple of processes? The costs stay relatively manageable. It's like cooking dinner for your family. You know the recipe, you know the portions, you can handle the variables.

Note: My “Eh, we’ll figure it out, we don’t need to measure anything” cooking strategy at home does not apply here. Ask my wife and kids.

But what happens when you start involving multiple departments, interconnected processes, and layers of complexity? The costs don't just increase linearly, they explode almost logarithmically. Suddenly, you're not cooking dinner for your family; you're running a restaurant during rush hour.

Why The Math Makes Sense

Here's what most people miss when they look at project costs: complexity compounds.

When you add another department or process to the mix, you're not just adding their individual costs. You're adding:

• The time it takes to get everyone aligned (and re-aligned when things change)

• The effort required to document and standardize processes that "everyone just knows"

• The complexity of integrating with existing systems that nobody wants to touch

• The political navigation required when Department A's "must-have" feature conflicts with Department B's workflow

Plus there's always that one critical process that "Bob from Accounting set up 15 years ago" that nobody fully understands but everyone depends on. But we’re afraid of Bob as if he is an untouchable deity and work around him. More organizations have a “Bob” than not, particularly in the B2B industry. Turns out, Bob is a super chill guy and is surprised nobody has asked him how things work in 8 years.

The Hidden Multipliers

Want to know why that logarithmic curve kicks in? Here are the real cost multipliers that most project estimates don't explicitly call out:

1. Cross-functional Dependencies: Every time two departments need to agree on something, add time and money.

2. Legacy System Integration: Those old systems you can't get rid of? They need special care.

3. Change Management: The more people involved, the more time you spend on training, communication, and handling resistance.

4. Risk Mitigation: Bigger projects mean bigger potential failures. Insurance isn't cheap.

Here’s an illustrative rule of thumb that certainly does not apply to all circumstances, but you get the gist:

The Invoice Is Just The Beginning

Here's something that also gets missed in budget discussions: that big number on the vendor invoice? It's only part of the story.

When you pull your best people into a major project, the ripple effects spread across your entire organization. Your star developer shifts from maintaining critical systems to implementation work. Your brilliant business analyst stops optimizing current processes to document new ones. Department heads find themselves trapped in endless planning meetings instead of driving their teams forward. And your subject matter experts? They're so busy documenting processes that customer problems start piling up.

Remember, you don’t have an endless about of internal resources that you’re already trying to maximize.

This isn't just about tracking hours and salaries, it's about the opportunities your team isn't pursuing while they're heads-down on the project.

Internal [opportunity] costs rarely show up in project budgets. They're buried in departmental headcounts and quarterly objectives. But they're just as real as that vendor invoices…sometimes more so. It’s a silent killer and by the time you know it, it’s EOY.

So What's The Alternative?

Here's a question I ask when I sense the sticker shock setting in:

If we could magically solve this problem for half the price, but it only works 80% of the time—would we take that deal?

The answer is almost always no. Because in B2B, "mostly working" is the same as "not working at all”. Hard pill to swallow but we’ve all experienced it. We’re talking about BHAG projects here, not small pet projects.

Making Peace with Reality

Yes, we absolutely work to optimize costs. We look for efficiencies, we reuse components, we stretch our resource constraints, and we phase implementations thoughtfully. But at some point, you have to accept that making enterprise-grade sausage takes enterprise-grade effort.

The next time you're looking at a big project proposal or conjuring up your business case to present to the board and feeling that budget anxiety creep in, remember: the cost isn't just about the technology. It's about the complexity of changing how people work while keeping the business running.

Sometimes expensive is exactly what it should be.

What's your experience with large-scale projects? Have you found ways to manage the complexity curve? Let me know in the comments below.

Leave a comment

Your org chart is not a strategy, and if you are filling seats instead of defining functions, you are already behind. In lean IT teams, broad functions let a few people cover a lot of ground, which is fine until complexity creeps in. A Unified Collaboration Administrator juggling multiple platforms? That works. A single person owning your entire ERP? That is a disaster waiting to happen. IT leaders need to stop treating roles like checkboxes and start building teams that scale. Get it wrong, and you are either burning people out or setting yourself up for a high-stakes failure.

I was recently catching up with an old colleague who now leads IT at a manufacturer. Since we just flipped the page on 2024, the conversation of yearly budgeting was bound to come up. A statement was made that went, almost verbatim, like this:

“I've got [redacted] down my neck about a lot of buzzwordy things. But I can barely keep the lights on with the current team and budget is looking flat."

Sound familiar? Take a look at r/sysadmin and posts like this are non-stop:

This is the story of our lives for most IT leaders. A constant juggling of ambitious business demands with skeleton crews and tight budgets. But here's the thing - after spending 15+ years in the trenches, I've learned that working smarter isn't just about grinding harder.

It's about being intentional with how you structure your team.

One of the most powerful levers you can pull? Deciding whether to organize around functions or roles. It sounds simple, maybe even obvious, but I've seen this single decision make or break IT organizations.

Let me explain.

Functions vs. Roles

Think about your typical IT department that’s somewhere between 1-75 FTEs.

You might have that superhuman solo IT “Director” who somehow keeps 200 applications running while also being the de facto help desk, security team, and digital transformation guru. They're wearing so many hats they could open a haberdashery.

That's a function-based approach - broad responsibilities rather than narrow specializations.

On the flip side, I recently worked with a company that hired a dedicated PIM (Product Information Management) specialist. Despite being a relatively small organization of 350 employees, they knew their product data was their lifeblood. They needed someone who could eat, sleep, and breathe PIM.

That's a role-based approach - narrow responsibilities with hyperfocus.

Neither approach is inherently better and it's all about context. But let’s take a look at when each are better applied.

Functions Shine When...

You're running lean and mean.

Most mid-market IT departments are working with that magical "less than 5% of total headcount" budget. Functions let you cover more ground with fewer people.

At one point in my career, we created a "Unified Collaboration Administrator" function instead of separate roles for being the custodian of SharePoint, Zoom, and Box. One person owned the entire collaboration stack. Not only did it save money, but it also meant better integration between tools and a single point of contact for the business.

Organizations have a LOT of applications, platforms, and technology to support.

It simply does not make sense to have a 1:1 ratio of owner:technology in most environments even with infinite resources. That being said, this isn’t a matter of making individuals a jack-of-all-trades or a specialist. They CAN be both and have a T skillset within reason. In fact, I would encourage it.

Roles Make Sense When...

The cost of failure is too high to ignore.

Sometimes, you need someone who lives and breathes a particular system. Think about your core business systems. For example, your ERP system that handles thousands or millions in employee transactions daily? That needs someone who understands every quirk and configuration. I've seen companies try to save money by having a generalist manage their ERP, only to spend triple on consultants when things go sideways.

In non-digitally born B2B organizations, it’s typical to only have 2-8% of total revenue going through an ecommerce platform, but you’ll find out very quickly how important that platform is when it’s down for a day. You can't afford to have that managed by someone who's also juggling infrastructure maintenance, handling graphic design, or trying to fix that broken printer in the warehouse.

The Practical Reality

If you’re staring at a fork in the road, you should almost always start with functions, but be ready to pivot to roles when the pain points become clear.

Watch for these signals:

• When your generalists are spending more time googling solutions than implementing them

• When system downtime starts impacting revenue and significant operational stability

• When your business users are crying out for expertise you can't readily provide

Think Like a GM (General Manager):

Just like NFL teams have to balance their roster under a salary cap, you're working with finite resources. You can't field specialists everywhere, but you also can't win with just utility players. The key is identifying your "impact positions" - the systems and platforms where specialized expertise directly translates to business success.

The Platform Factor

Now, let's talk about platforms - because they complicate everything in the best possible way. You've got your horizontal tools (think Microsoft 365, the digital equivalent of oxygen) and your vertical applications (like that ERP system that runs your entire business).

In my experience, horizontal platforms usually play nice with a functional approach. Your collaboration tools, basic infrastructure - one capable generalist can usually handle it. But vertical applications? That's where it gets interesting. Platforms with a higher impact to order to cash or procure to pay processes, or that impact a significant amount of business users most often need dedicated roles as they grow in complexity.

Here’s how that gets mapped out visually if we were to put them into quadrants mapped by Application Type and Complexity:

The Million Dollar Question

So how do you decide?

Let me share a quick exercise I’ve used to help. Grab a whiteboard (or your digital equivalent) and let's map this out:

1. List your critical systems in two columns:

   • Revenue impact (what directly affects the money)

   • Business operations (what keeps things running)

2. For each system, jot down:

   • Current support model (who handles it today)

   • Number of weekly incidents/requests

   • Last major outage impact ($$$)

   • Compliance requirements

   • Integration points with other systems

3. Put a star next to anything where your gut clenches when you think about it failing. Trust me, your instincts here matter.

Here’s a basic example to get the wheels turning:

In a roundabout way, I end up doing this as a part of my role when solutioning the implementation of digital commerce platforms. Typically, ERP systems jump out immediately as a high risk area, so we discuss who supports the platform today, how resilient it is, etc. Having your ERP go down is pretty shitty for operations inside your business, but it’s even worse when directly integrated to your public facing website - your dirty laundry is showing for a lot of people to see.

The beauty of this exercise is its simplicity. You'll likely find 2-3 areas that scream "I need a dedicated role!" while others are perfectly fine under your current functional approach. You’ll then be able to tie the gaps to strategic initiatives in the company for justification (or at least a chance at it).

Remember, this isn't about transforming your entire organization overnight. Start with your biggest pain point, make the change, and learn from it.

Evolution beats revolution every time in IT leadership.

Wrapping Up

That former colleague I mentioned left our exploratory conversation with a different outlook on how he may be able to repurpose current individuals who have slowly slid into a niche role that isn’t having an impact on the business. A necessary duty for any leader.

Remember, this isn't a one-time decision. The best IT leaders I know constantly reassess based on changing business needs, available talent, and yes, those ever-present budget constraints.

What's your take? I'd love to hear how you're handling this balance in your organization. Drop a comment below - are you team Function, team Role, or somewhere in between?

Leave a comment

Subscribe now