Shadow IT and the Illusion of Innovation

Olivia Carter

Good afternoon, Mark. Today we're digging into Shadow IT—why it’s so seductive, why it gets confused with innovation, and what that confusion actually costs us. Mark, you ever come across those so-called “star quarterbacks” running shadow IT projects that seem to have the executive’s full blessing?

Mark Putnam

All too often, Olivia. And what’s remarkable isn’t the technical skill—most central IT teams could build exactly what these shadow groups are building, and usually with more rigor. What’s different is that the rules just… vanish. A colleague of mine inherited a nightmare. Ten years earlier, a side-door project had been spun up to speed things along—built fast, never documented, and never integrated with enterprise security. The developers were long gone. No one remembered it was even running. Then it failed. The entire student information system database—tens of thousands of records—was downloaded through a vulnerability no one knew to look for. Because it wasn’t on the map. That’s what shadow IT leaves behind: not just risk, but blind spots. And when it goes wrong, the CIO is the one left holding the bag.

Olivia Carter

That’s wild, but it’s a pattern, right? Someone’s chasing a quick win, they throw resources at a side project, and suddenly it’s painted as agility and innovation. But it’s really just a workaround. Why do you think this keeps getting mistaken for digital transformation?

Mark Putnam

There’s this mirage: fast equals innovative. But speed, unmoored from discipline, just creates drift. You’re not building resilience or lasting value. You’re making more work for tomorrow—without any strategic anchor.

Olivia Carter

You know, this reminds me of a story I covered on a university’s AI chatbot rollout. It was spun up fast—outside of IT governance, totally driven by executive enthusiasm. They wanted something flashy, something they could showcase at board meetings. And at first, it looked great. Clean UI, slick responses, lots of buzz.

Olivia Carter

But then it started crashing. It couldn’t connect to the student information system, gave wrong answers about registration, and completely broke during the first round of advising appointments. And the minute it failed, the blame shifted. Suddenly, central IT was expected to jump in and fix a system they had never touched, weren’t consulted on, and didn’t even know existed.

Mark Putnam

Classic pattern. Executive impatience dressed up as digital transformation. The obsession with the “visible win”—something you can show off in a cabinet meeting—takes priority over doing the actual hard work of integration, testing, and long-term planning. And what gets sacrificed is trust. Skipping alignment, ignoring governance—it doesn’t just create technical fragility. It erodes credibility. When every division or leader is allowed to build in isolation, you lose the connective tissue of the institution. Systems don’t talk to each other. Data doesn’t flow. And suddenly, what looked like innovation starts to feel more like entropy.

Olivia Carter

And meanwhile, central IT is left balancing mission-critical systems—finance, HR, research compliance—not to mention cybersecurity and regulatory pressures. So when they say, “we need time to do this right,” it gets framed as bureaucracy or resistance. Sure, sometimes IT does move slow. But more often, they’re slow because they’re doing the hard work: sequencing change, protecting data, designing for scale. The real issue is that instead of resourcing that work, executives bypass it. No one wants to sit down and wrestle with real prioritization. They want shortcuts. Quick wins. Something that makes the slide deck pop.

Mark Putnam

Exactly. Shadow IT isn’t a technical shortfall. It’s a reflection of cultural dysfunction. It’s what happens when leadership values momentum over maturity. When processes get framed as obstacles instead of safeguards. And when nobody has the patience—or the discipline—to sweat the details together. Without that discipline, you don’t get innovation. You get chaos in a nice wrapper. And eventually, someone in central IT is left holding the bag. Again.

Olivia Carter

I keep thinking about that phrase from an earlier podcast—“dopamine-fueled IT.” It just nails it. Especially with GenAI tools, there’s this instant gratification loop. You get a great response from ChatGPT, plug it into a script, and suddenly it feels like you’re solving real problems at light speed. It scratches the creative itch, it looks like momentum, and everybody walks away thinking, “Wow, we’re really moving.”

Mark Putnam

Right—and it’s addictive. You’re not just building; you’re getting rewarded while building. There’s novelty, there’s speed, and it triggers that little chemical rush. It’s software as adrenaline. But the danger is, that rush short-circuits good judgment. You skip documentation. You bypass integration. You don’t think about governance, because the reward loop ends once the prototype works. And then, six months later, the platform updates, or the API call breaks, or the person who built it moves on. And now it’s this fragile construct no one understands—held together with vibe and duct tape. That’s where the term vibe coding comes from. It’s improvisational development, not enterprise architecture.

Olivia Carter

And the scary part is that it doesn’t look dangerous in the moment. It looks like momentum. Like responsiveness. But it’s all surface. So how do you actually draw the line? Where does healthy experimentation cross over into just laying down future headaches?

Mark Putnam

That’s the heart of it. The difference is intent and structure. Healthy experimentation has constraints—it happens in sandboxes, with version control, review cycles, and clearly defined outcomes. There’s an exit plan if the prototype fails. There’s documentation if it succeeds. But when people start deploying code to production systems without process, just because it “works” today, they’re quietly sewing new threads into Andy Kyte’s Gordian Knot. Every ungoverned script, every workaround that never gets handed off or supported—that’s future technical debt. And eventually, the knot tightens so much that the entire system becomes brittle. You can’t call it innovation if it breaks the moment someone lets go. That’s not transformation. That’s just entropy in disguise

Olivia Carter

Which brings us to Andy Kyte and that legendary Gartner talk. Man walks on stage with a scimitar, ready to hack through decades of technical debt. I’ll never forget reading about that metaphor—the Gordian Knot. His whole point was: you can’t just pile new tech onto tangled, dysfunctional systems. If you don’t first simplify, you’ll just modernize the mess.

Mark Putnam

Exactly. You look at ERP—there’s this evolution: first we built everything ourselves, then we bought off-the-shelf and rewrote them anyway, then we glued it all together with middleware. Every “generation” inherited more mess, more complexity, unless you made a conscious effort to simplify first. It’s not just historical—it’s a warning.

Olivia Carter

So really, every new tool or platform we add without cleaning up first, we’re just keeping the old problems and giving them a shinier home. That’s not transformation, that’s just repackaging the same mess.

Mark Putnam

That’s what institutions have to face: unless you cut through the knot—the old assumptions, the unnecessary steps—no modern platform can save you. Simplify before you automate, always.

Olivia Carter

The illusion of momentum is so risky because, eventually, the costs come due. People don’t see it at first—it all feels fast and empowering. But let’s talk about what really happens on the back end. What are the support, security, and integration nightmares no one thinks about when they launch these side-door systems?

Mark Putnam

Let’s start with support—because it’s always the first crisis that lands on IT’s doorstep. I’ve lost count of how many times, as CIO, I’d get a call at 2 a.m. from a campus unit in total panic. Something broke. Students were locked out of a portal, payroll didn’t run, or an advising system crashed mid-registration. And when we investigate, we find a rogue tool—one no one ever told us existed. No documentation, no monitoring, no assigned ownership. And the original developer? Long gone.

Olivia Carter

So IT ends up responsible for a system they never built, don’t control, and can’t fix without burning hours just trying to reverse-engineer what’s there.

Mark Putnam

Exactly. It’s like inheriting a black box—one that’s actively failing. But because it’s now a business-critical issue, IT is expected to jump in and clean it up. That erodes trust. Not just operationally, but institutionally. It shifts the narrative from “innovation” to “who’s cleaning up the mess,” and IT gets cast as the problem solver and the villain—both too slow and somehow responsible for a system they never approved.

Olivia Carter

And then there’s security—which people underestimate constantly. I mean, how often do these shadow systems even go through risk review?

Mark Putnam

Almost never. They’re typically spun up with good intentions—“let’s move fast, let’s deliver”—but no one stops to ask, “Is this storing sensitive data? Does it authenticate users properly? Who’s patching it?” I’ve seen systems with root access exposed to the internet, no audit trail, logging turned off. Shadow IT is often invisible to the security team until the breach happens—or until an audit turns it up, and then suddenly everyone’s scrambling.

Olivia Carter

Or the integration issues. That’s a whole other layer. Either the shadow tool doesn’t talk to institutional systems at all, or worse—it does, but badly. I’ve seen student records overwritten, financial data duplicated, and nightly jobs fail because a rogue API call knocked something out of sync. By the time anyone notices, the damage is already done.

Mark Putnam

And let’s be honest: integration is rarely designed from the start in these builds. It’s bolted on, reverse-engineered, patched together with duct tape and hope. And the person who built it usually wasn’t thinking in terms of long-term architecture. They were solving for a local need, not for institutional stability.

Olivia Carter

So then central IT inherits a spaghetti mess—half-working code, undocumented logic, broken dependencies—and has to untangle it all in production, with no margin for error. And that becomes the new normal. Over time, the real cost is that the enterprise becomes harder and harder to manage.

Mark Putnam

Which brings us to the biggest cost of all: strategic risk. And that one doesn’t scream—it whispers. It’s the slow erosion of coherence. Every time a team builds in isolation, it fragments the institution a little more. Systems don’t align, data gets siloed, and priorities drift. What looks like a local win—getting something out the door quickly—actually undermines the ability to build an integrated, scalable ecosystem. You lose shared language, shared governance, and shared trajectory. Eventually, you’re no longer building a university IT environment. You’re babysitting 47 competing toolsets duct-taped together.

Olivia Carter

And that fragmentation makes it almost impossible to lead strategically. You’re not guiding innovation—you’re firefighting its unintended consequences.

Mark Putnam

Exactly. Shadow IT isn’t just risky. It’s regressive. It pulls institutions backward, into complexity, fragility, and chaos. The real cost isn’t just technical—it’s the loss of strategic alignment. And once that’s gone, it takes years to recover.

Olivia Carter

But this isn’t an anti-innovation podcast! The answer isn’t just to shut everything down. It’s about what real, institution-wide innovation actually requires. It’s not ten different teams running in ten directions; it’s getting everyone aligned around clear priorities and shared stewardship.

Mark Putnam

That means an empowered IT organization, with the CIO actually at the strategy table. Not just fighting fires in the basement, but shaping the roadmap, influencing priorities, ensuring that every digital investment fits the bigger picture.

Olivia Carter

So—real innovation sticks when we’re choosing to integrate, not just accumulate. That takes executive restraint, patience, and good old discipline. If we’ve learned anything from the last few episodes—like our discussions on ERP and negotiation—it’s that leadership and clarity come before shiny tech toys.

Mark Putnam

Institutions that support their IT leaders, define real priorities, and sweat the details together—they’re the ones ready for longevity, not just the next news cycle.

Olivia Carter

So, if we had to boil it down—what does it mean to actually cut through the knot, instead of playing around its edges? Is the bold move really about more workarounds, or is it about making hard choices to simplify before you adopt anything new?

Mark Putnam

It’s about discipline. Low-code platforms, AI, fancy dashboards—they’re powerless against bloated, outdated processes. The institutions that’ll thrive are ruthless about simplification: cutting unnecessary steps, saying no to customizations unless there’s a business-critical reason, and training IT to act like process engineers, not just tech supports. If you refuse to cut complexity, you lose the point of digital transformation entirely.

Olivia Carter

It’s not about being the fastest to deploy this year’s gadget. It’s about building systems—and a culture—that can adapt, integrate, and endure. Every thread you cut from the knot, every process you simplify, it’s a win for the future, not just the present.

Mark Putnam

And that’s where we’ll leave it today. True transformation depends on discipline, not dopamine. As always, more to talk about—but for now, thanks for joining us, Olivia.

Olivia Carter

Thank you, Mark. And thanks to everyone for listening. Next time, we’ll dig deeper into how executive leadership actually creates space for this discipline—so, make sure you subscribe and stick with us. Take care, Mark!

Mark Putnam

Take care, Olivia. Until next time.