The Mistake That Cost Us The Most (And It Wasn’t Technical)

Early in my career, I inherited a modernization effort that had already burned through more than two years and a budget that was probably north of what anyone wanted to admit. The engineering was solid. But when I compared the infrastructure to operational needs, the gap was obvious: Nobody had meaningfully addressed operations.

A platform that doesn't fit, regardless of its quality, remains unused in practice. Building meaningful technology is the key to adoption. I see this failure constantly: firms modernizing the TMS and shifting to the cloud without ever fixing the workflows underneath. Running a flawed process on modern infrastructure isn't transformation; it's just an expensive way to keep the same problem alive. If the workflow is broken, automation isn't the solution—it's the fast lane to failure.

Fragmented Ownership Is A Quiet Program Killer

I've seen programs where the CIO owned delivery, the COO operations and the CFO cost. On paper, that's full coverage. When budget pressure hit, each leader pulled toward their own priorities, and the program slowly stopped mattering to anyone with the authority to protect it.

Every program I've watched survive genuine organizational friction had one thing in common: The C-suite was jointly accountable for the same outcome, not just their slice of it. When transformation lives inside IT, it competes with every other IT priority. When it sits in the C-suite as a shared business bet, it gets treated like one. That sounds obvious; it's genuinely rare.

The Sprawl Nobody Budgets For

At one point, I found myself managing a technology estate that had grown organically, each decision sensible in isolation. Multiple TMS environments running in parallel and API layers built by teams long since turned over. Custom middleware was not fully understood, and master data was scattered across systems that didn't talk to each other. On top of it, each technology team was trying to fix their slice of issues in silos, pushing the overall IT budget.

When we tried to introduce AI into that environment, we kept hitting the same wall: Integration complexity was consuming most of our engineering capacity. We weren't building; we were maintaining legacy systems and calling it momentum. People often overlook the cumulative cost of adding platforms without retiring them until you realize you haven't shipped anything meaningful in over a year.

Where Governance Actually Matters

Honestly, I avoided the topic for too long. Governance felt like red tape or the process of slowing down. We thought we were agile. However, we were just avoiding hard questions. Then the cloud bills arrived, and nobody could explain them. The teams that skipped governance to move faster ended up the slowest. It's important to build the checkpoints early and decide when to stop a project—sometimes even before starting it if it's an experimentation project.

The Part Most Programs Get Completely Wrong

Adoption usually gets treated like a formality. Launch the platform, send the announcement, maybe run a training session, check the box. I've watched genuinely well-engineered systems fail because the people meant to use them didn't trust them or weren't involved early enough to feel ownership.

Workforce resistance, not technical failure, is what actually breaks these programs. That doesn't surprise me anymore. What still stands out is how consistently adoption is treated as a small line item. A capability nobody uses delivers no value. You should budget for adoption the way you budget for engineering: dedicated ownership, real resources and a definition of success that isn't just "we launched." It's not done until the expected value is delivered.

Lessons For Other Leaders

When peers ask what separates successful programs from the rest, my answer is simple: Leaders know what they're investing in and stay honest about whether it's working. That honesty shows up in specific ways:

• Measure What Drives Business Outcomes: Track revenue, margin and customer outcomes, not deployment timelines or feature counts. Those are easy to report and easy to manipulate. If your program looks great on a status deck but nobody in operations has changed how they work, something is wrong. Numbers are a thousand words.

• Manage Complexity With Intentional Architecture: The pressure to add another tool, another platform, another quick fix never stops. Every addition without a retirement plan is debt you'll pay later, usually at the worst possible time.

• Invest In Adoption To Realize Value: Any new capability only creates value when used. Without adoption, even excellent design and build efforts go to waste.

• Confront Hard Questions Early: Sunk cost has a way of making uncomfortable truths politically inconvenient. The leaders who succeed ask those questions early, while there's still room to course-correct.

This Is A Leadership Problem, And Only Leadership Can Solve It

These initiatives rarely affect vendors or technology. Leadership problems start before spending. Budgets will misalign, vendors will overpromise, timelines will slip, and key sponsors will move on. The only concern is whether your program's structure can adapt seamlessly with those events. If the structure is wrong, nothing else matters. Everything else can be course-corrected, but this cannot.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?