This is Why They Don't Trust Us

It's not overselling anymore, it's using their trust against them

I was part of a digital team that built an analysis tool for a project.

It managed data between a main model and many sub models for structural analysis. The idea was for each engineer on the team to work on their own model, then use our tool to combine everything into a single main model. It made modelling collaborative which if you know how analysis programs worked, was a big deal. Most, if not all analysis programs only allow one person at a time.

That meant the project team could put almost every engineer (junior to senior) on the modelling without having to copy and paste between models. This was actually where most of the errors and problems come from. People model the paste the wrong thing or they accidentally delete something important in the main model.

But with our tool, a click of button would solve all of that. You’d get a team-built and expertly led analysis model as many times as you needed.

It was so good and we wanted to present it to other project teams. The hope was that they, too, could experience the future of modelling through the same system. Even though our tool only worked for this project, it wouldn’t have been hard to tweak it for others. In fact, with enough motivation, we could build the same system for everyone. We were creating collaborative editing for models

So, present we did. Hoping to get more interests and ideally, more funding. For 30 minutes, everyone watched us explain this magical process. Parallelize the modelling, click this button, and have all your complex analysis woes solved.

At the end of it, all I could think was: “This is why no one trusts us.”

Because the truth hurts

The tool actually made the project worse.

The one-click reality was people still had to manually copy and paste between models. The very thing the tool was designed to prevent. But now, they also had a tool that would get it wrong, so sometimes, they had to spend even more time cleaning up after the tool.

To make things worse, after we made the tool, there was also a period where the original developer who built the tool was on leave. He didn’t give any handover notes or access to the original code. So, when the tool broke and there was no one around to fix it. I helped out the project team by also manually copying and pasting between models. Not fixing the tool, actually placing lines and copying numbers. Again, the very thing the tool was designed to prevent.

Before we showed up to this project, the team had a workflow. It was manual, error prone and slow, but it was theirs. They understood it and knew exactly what to do. Now, they had a tool they didn’t fully understand, that occasionally saved them time and occasionally broke at the worst possible moment. So, they ended up with a workflow that was slower, more error prone than just doing it manually.

Now, imagine you’re a manager. You’ve been promised that you get a tool that would almost half your turnaround time. What do you tell the clients?

Well, you tell them you can do it faster.

Which is exactly what made the deadlines of this project so tight. The team was depending on the tool working. They’d planned a tighter turnaround because the tool was meant to handle it. But because the tool broke so often and the team weren’t available, they dug their own graves. They had to work long hours to make up the tight deadline that the tool was supposed to prevent.

And after everything, we still presented it to everyone like it was the next best thing since sliced bread.

I bet the project team were laughing at us during the presentation. They would never work with the digital team again. I mean would you ?

That feeling must have bled to the other teams too. Because as “game-changing” as our tool was, no one reached out to us. I swear we looked like clowns up there. The tool also never saw the light of day again.

Subscribe to CodedShapes and I’ll send you my free guide on how to actually apply it to your projects.

We sold the dream, not the reality

The thing that bothers me most about that presentation isn’t the overselling. It’s the eroded trust with the team.

The project team trusted us. They built their entire schedule around it. They told their clients they could turn things around faster. They took on tighter deadlines. They made commitments based on our promises.

They basically believed that we would together to deliver a product that was better than the sum of it’s parts. And we let them down an threw them under the bus.

And while they (and I) stayed late delivering the project while the tool broke, we still stood up there and called it the best tool.

That’s no longer overselling, that’s taking someone’s trust and using it against them.

I don’t blame people for not trusting the team again.

Then we disappeared

But the biggest crime isn’t the broken tool. It’s disappearing after you’ve sold the magic. Especially when people have build their deadlines and budgets around it actually working.

The guilt from this project still stays with me.

There were days where the project team needed help. The tool broke, which was common, but our team had moved on to other things.

I remember our replies all fell along the lines of: “Yes, that’s a bug, but I’m busy. I’ll get to it in 2-3 days.”

But they had a deadline tomorrow. So they stayed up that night doing things manually. And eventually, they stopped asking.

The kicker? When we finally had time to look at it, we’d say something like:

“Oh, you shifted the geometry. Our tool doesn’t support that. So, you broke it.”

The tool broke and we didn’t fix it. They still had a deadline, so they fell back to the manual way to get it over the line. And then, when we did have time, we blamed them for breaking the tool that we made.

If that happened to you, how hard would you kick us?

Two sides of the same coin

Of course, it’s not always this one-sided. There have been times where there are bad inputs or assumptions. Or people try to use the tool outside it’s design and expect it to perform magic.

But the common piece on both sides is trust and reliability.

Trust goes both ways. You need to trust that the tool will consistently deliver. And I need to trust that you’ll use it within the agreed conditions.

Reliability also goes both ways. Before I completely handover the tool to you, we have to ensure that it’s tested well and that you’re confident it works the way you need it to. Of course, there is another piece that when something breaks after, I’m there to fix it, not leave you hanging.

If you can’t trust or rely on the digital solution, then nothing will go well.

We have to align on the direction

I still think computational design is worth it. I wouldn’t be writing this newsletter if I didn’t. The time savings are real, and the problems we can solve now are genuinely amazing. And the whole idea is to build something better than the sum of it’s parts.

But we need that trust and reliability on both sides first.

We can’t sell magic and then disappear when it breaks. And we can’t expect our tools to solve every problem when the only instruction was “fix it for me”

The way to close that gap isn’t to be more impressive. It isn’t to use more AI. It’s to be more reliable and honest about everything we make, like what it can do, what it can’t, and what happens when it breaks.

If you’re working through an automation problem and want to think it through before you build, reply to this email or reach out. I’m always happy to talk through what’s worth automating and what isn’t before anyone commits to a tool that might not hold up.

Thanks for reading.