The Safety Net is the Saboteur
Trevor Baggett (right) with Nick Osborne and I at CMAA Focus in Las Vegas on March 8, 2026.
Four out of five digital transformations fail. That's an 80% strikeout rate. Even in the world of baseball, that’s not very good at all.
And we just love to blame the software. The interface is clunky. The integration is broken. The vendor overpromised. Ok fair, sometimes that's true. But after twenty years of watching tech roll onto job sites and roll right back off, it’s become clear that failure is rarely about the tool.
It's about the back door we leave open.
But don’t just take my word for it. Trevor Baggett, who literally wrote the book on The Implementation Gap, has found the same to be true.
The Safety Net Saboteur
That's the idea you should walk away with today.
Every time you implement a new system but leave the old one running in the background, you've built an escape hatch. And the moment things get hard (like the moment crap hits the fan on a Friday afternoon with a deadline looming) your team will dive straight back through it. Not because they're lazy. Not because they're “luddites.” But because that old Excel template that's been on the shelf since the late nineties is the thing they trust when the pressure is on.
Trevor and I like to call this "burning the ships."
It's an older concept. When the conquistadors landed, the commander supposedly burned the ships so retreat wasn't an option. You either make the new place work or you don't survive.
Same principle on a job site. If the old system is still sitting there, people will gravitate toward it because that's what they know. The safety net feels like protection. In reality, it’s the thing guaranteeing your transformation never lands.
That’s why this is so important to drive home, we don't have a technology problem in construction. We have a culture problem. And nothing exposes that faster than how we handle the old way of doing things. The tool is just the mirror. What it reflects back is whether your people actually trust the new direction or are quietly hedging their bets.
Why Smart People Keep the Old System Alive
Here's what makes this so deceptive. The people clinging to the old template aren't the problem children. They're often your best people, the ones with decades of experience who've been burned before by some half-baked rollout that wasted three months of their life. When they keep the spreadsheet alive, they're not resisting progress. They're managing risk the only way they know how.
That's the part leaders miss. They see the workaround and read it as defiance. It's not. It's a vote of no confidence in the new system's readiness (and it's usually correct). The field is telling you something true. The question is whether you're prepared to hear it.
“But you need both kinds of people on an implementation team.”
The champion who runs at the new thing, and the skeptic who gives you honest, unfiltered criticism. As Trevor points out, if you only have champions, you get blind spots. If you only have skeptics, you get paralysis. The skeptic keeping a back door open isn't your enemy. They’re your early warning system so long as you're paying attention.
Success in the Office, Failure in the Field
Here’s a quick example that perfectly illustrates the trap, and the fix.
Trevor’s group got a new system live at the operations level. Looked great. People at the top were using it. Then it hit the field and died on contact. The construction schedule the office had built was too high-level to be useful for the day-to-day look-ahead the field actually runs on. So the field did what field teams always do when a tool doesn't fit their reality: they reverted. Back to what they knew. Back through the back door.
This is where many of us make our second mistake. In a tough industry like construction, we like to double down. We mandate harder. We send stronger emails. We blame the field.
But Trevor did the opposite.
He stopped. He took the implementation and paused it. Then they went back to operations to retrain the entire process, breaking the schedule into a high-level construction view and a detailed daily look-ahead the field could actually use.
He didn't just close the back door. He rebuilt the room so nobody wanted to leave it in the first place.
The Pause Only Works If You've Earned It
Here's the most important part. The reason Trevor could hit pause (the reason stopping a live rollout didn't torch his credibility) is that he'd already built a culture with open feedback loops. His people felt safe enough to walk up and say, "Hey, this doesn't work the way we work." That admission isn't a failure in their shop. It's the input that makes the next version better.
Most leaders don’t have that credibility, and they did it to themselves. They built a culture where stopping means admitting failure, and admitting failure means looking weak. So the rollout limps forward, half-adopted, while everyone privately runs the old system. All while the leader keeps insisting it's working.
That's not transformation. That's theater.
I've lived the other side of this. I've been on rollouts where leadership mandated a tool top-down, refused to look at how the field actually did the work and then acted surprised when adoption cratered at two weeks.
Everybody fighting the change. Everybody frustrated.
All the while the old system hummed along in the background the entire time, ready to catch them. We didn't lose because the software was bad. We lost because we left the lights on in the old house.
And because nobody felt safe enough to tell us the new one had no plumbing.
Build the Shore Before You Burn the Ships
But here’s the thing, burning the ships only works if the new shore is actually livable. You can't just delete the old template and walk away. If you close the back door before you've built something the field can stand on, you haven't created commitment, you've simply created a hostage situation.
Hostages don't innovate. They wait for you to look away and then run.
The sequence matters, and most times we get it backwards. We’ll burn the ships first and hope the team figures out the island. But Trevor does it the other way. Go to the field. Watch how they actually work (you can't improve a process you've never seen). Build the new system around their reality. Then close the door.
If your last three rollouts stalled at the two-week mark, stop blaming the tool. Go look for the back door you left open. That spreadsheet, that legacy login, that "just in case" workaround everybody swears they don't use anymore.
Then ask yourself the tough question: have you built the kind of culture where someone feels safe enough to tell you the new shore isn't livable before they quietly swim back to the old one?
Because if they don't feel safe saying it, they won't say it. They'll just leave the door open. And you'll be standing there in six months wondering why you're part of the 80%.
Construction is cool, tell your friends.