I once backed a technology decision with more confidence than the evidence deserved.
The platform had promise. The vendor understood the problem. The demonstration showed capabilities we wanted, and I could see the strategic destination clearly. I pushed for it.
What I underestimated was everything between the product and the outcome: integration complexity, data readiness, process redesign, internal ownership, adoption and the operational reality of running old and new environments at the same time.
In other words, I bought the destination and underpriced the journey.
The uncomfortable part
It is easy to describe a failed technology decision as a vendor problem. Sometimes it is. But leaders should be suspicious of any postmortem in which responsibility sits entirely outside the organization.
The vendor did not decide our data architecture. It did not create every legacy process. It did not define our decision rights or determine whether product, engineering, operations and compliance shared one plan. Those were leadership questions.
I had also fallen for a familiar transformation illusion: that a sufficiently capable platform could force the operating model to catch up. Usually the reverse is true. Technology amplifies the clarity—or confusion—already present around it.
A new platform can expose an old operating model. It cannot quietly repair one.
What I should have asked
I should have asked more aggressively whether the data was ready for the decisions we expected the platform to support. I should have required a clearer account of the manual work hiding behind the polished workflow. I should have named the permanent business owner before implementation, not near go-live.
And I should have treated the coexistence period as a control environment in its own right. When old and new systems operate together, risk does not politely wait for the migration plan. Reconciliations, case histories, model versions, operational training and escalation routes all need explicit design.
What changed in my leadership
The experience did not make me less interested in ambitious technology. It made me more demanding about the conditions around it.
Now I want to see the decision architecture alongside the product architecture. Who owns the outcome? What must be true about the data? Which process will disappear rather than merely move screens? How will we know the new capability is improving risk detection instead of only changing volume? What happens when the model or workflow behaves differently in production?
I also try to make it easier for teams to challenge momentum. The more senior the sponsor, the more permission people may need to say that the programme is not ready. Enthusiasm should create energy, not silence.
The point of admitting it
Senior leaders are expected to project confidence. But credibility does not come from pretending every major call was right. It comes from showing that mistakes can be examined without defensiveness and converted into better institutional judgment.
I still believe technology can transform compliance. I no longer believe the technology is the transformation.