We work with clients who want to improve their systems, their processes, the way they operate. Not every project goes exactly as planned. And most of them know that.

What separates good projects from mediocre ones isn't the absence of errors. It's how they're handled.

There's a type of error that's particularly hard to admit: the wrong diagnosis. When the problem you thought you were solving wasn't the real problem. When the automation you designed addressed a symptom but left the cause untouched.

It's happened to us. We've entered a project convinced of one thing and come out understanding something entirely different. And every time it has happened, the project ended up better than it would have been had we gone straight to execution without questioning first.

Because a diagnostic error, caught in time, is what opens the door to the right solution.

The question we ask ourselves internally every time we detect a deviation is: "Were we wrong about the diagnosis, or the execution?" It's not the same thing. The first means the context was different from what it appeared. The second means the plan was right but the implementation broke down.

Sharing the error with the client is uncomfortable. And necessary. Because trust isn't built in the moments when everything goes well. It's built in the moments when something fails and the other person sees you handle it with honesty.

The mistake that makes you better isn't the one you hide. It's the one that, in a moment of maturity, you choose to turn into shared learning.

→ When clients don't know what they want until they see it · Why we don't work with everyone · When it's too soon to automate