The Tool Isn’t Impressive, Trust Is
With Brian Tracy at Notre Dame Stadium on Feb 2, 2026.
Often when you sit down to interview someone, you set yourself up with questions you think you already know the answer to. Here’s a guy who literally co-authored the textbook on managing construction technology and now teaches it to master's students at Notre Dame. He has spent his entire career turning complicated tech into something crews will actually use. So naturally, I lobbed Brian Tracy what I thought would be a softball.
Which matters more, how impressive the tool is, or how trustworthy it is?
Then the surprise, he responded very matter-of-factly:
"A tool is impressive to me by how trustworthy it is."
While it might sound like cheating, he’s not wrong. And the more you think about it, the more you begin to realize this single sentence points out almost everything construction gets wrong about tech.
We Have the Whole Thing Backwards
In tech, we love to talk about the fancy new features we’ve built. We love to show off the ease of use, the simplified workflow and the intelligent dashboards. But here's the thing, we’ve got that all backwards.
Because the tool isn't impressive. The trust is.
Think about it, the entire contech marketplace is built to dazzle people. Vendors lead with a demo that makes your jaw drop, because the dazzle is what closes the deal in the room (just look at the way everyone is adding a little AI sprinkled on top). But the dazzle is not what survives when stuff hits the fan on a job site.
Brian put it perfectly: engineers aren't the showiest group. We're function over form. Our industry is expected to never fail. So when Brian scores a tool, trustworthiness isn't number one on a list of ten. Really, it's "one, two, three, all the way up to 100." Everything else is a rounding error.
And there’s truth to that. The tool your team actually reaches for on a Friday afternoon when the pressure is on isn't the one with the best feature set. It's the one that has never let them down. That's why people cling to the spreadsheet built in the late 90s. Not because they're Luddites. Not because they fear change. Because that ugly, clunky, decades-old file has earned something the shiny new platform hasn't: their trust.
What we keep calling resistance is really just a rational response to being burned one too many times.
The String and the Cursor
Back in the day, I began estimating with a digitizer (yes, I’m getting older). But on day two of the job, they handed me my first OnScreen takeoff license. Day one was a digitizer board and a takeoff pen, and the need to literally cut a piece of string, lay it along a curve and then measure the string. I'm not making that up. That was the state of the art.
So they gave me this new tool and said, "Test it. Tell us if it’s better."
Yes. Much better.
But here's what matters. It wasn't better because it was impressive. The tracing-with-your-cursor thing was cool for about an hour. It was better because it did the exact job I was already doing, more accurately, every single time. The math worked, so it earned my trust on the first project. By the second, I wasn't thinking about the tool at all anymore. I was just doing my work, faster.
Brian had the same experience with the same tools, years apart, at the same company. But the way he framed it is what was so impressive to me. He realized that he never actually loved the tech. He loved the process of getting better. The tool was just how he got there.
That's the key. Nobody on your team wants new software. They want their job to suck less. The tool is a means, and the only currency that matters in that exchange is trust.
Does this thing do what it promised, reliably, so I can stop thinking about it and get back to building?
Why Implementations Actually Die
Compare that to how most tech rollouts usually go. Somebody up the chain buys a platform because the demo was impressive. They roll it out with no training, no support and no explanation of why the change is even happening.
Brian's sharpest observation was that half the time, the people making the decision haven't answered those questions for themselves either. So the tool shows up, fails to earn anyone's trust and slowly dies on the vine while everyone drifts back to the spreadsheet.
Then we blame the field for being resistant to change. We blamed the wrong thing. We always do.
The Only Question That Survives the Job Site
The good news is, there is an easy solve to this. Stop evaluating tools by how impressive they are. Start evaluating them by how fast they can earn trust. Two completely different questions that lead to completely different decisions.
In fact, Brian gave the cleanest way to test for this. Before you install anything, ask one question: if your team got all the training and all the support, and then you gave them a free choice between the new tool and what they're using right now, which would they pick?
If the honest answer is "they'd keep doing what they're doing," you don't have an adoption plan at all. You have an expensive shelfware.
The best signal of a tool's success isn't the feature list. It's whether your people are already begging for it (or even using it on their own without asking permission). That's trust showing up before you've spent a dime forcing it. One of the riskiest things in tech is having no plan and saying nothing, because your team will go find and experiment with the tools anyway (just look at AI right now). But the flip side is just as true, because when they've already found something and they trust it, the adoption fight is mostly over.
So next time a vendor walks you through a demo that makes your jaw drop, sit on your hands. Don't ask how impressive it is. Ask the only question that survives the job site:
Can my team trust this thing on the worst day of the project, not the best?
Because the tool that earns that answer is the only impressive one in the room.
Construction is cool, tell your friends!