When Do We Know a Decision Was Right?

At this month’s executive board meeting, a question from our adviser had me going back over my past decisions one by one for several days after the meeting ended. Then I started wondering: if I had a time machine, which decisions in my working life would I go back to? The day I hired someone I now think was the wrong person? A project where I said, “I wish I hadn’t signed”? Or the day of a decision for which everyone congratulated me and I was showered with praise, but which I would not make the same way today? Think about it for a moment yourself: if you had a time machine, which decision would you go back to change? I found a few answers, and I realised that when I travel back, I take with me a very important piece of information I did not have on that day: the outcome of those decisions.

Looking back from today, we know what happened. When we make the decision, we don’t. What is more, when we decide, we live only the future we chose; we never get to see where the option we gave up would have taken us. Where would we be today if we had entered the market we stayed out of, or taken one of the investments we turned down? We don’t know. To say with certainty that a decision was truly “right”, we would have to get into the time machine, return to the same moment again and again, and live each option separately. In real life we have a single future and its outcome. Even so, we take that outcome and stick it onto our past decision like a note: right or wrong.

Some time ago, we sat down for a first meeting with a large manufacturing company. The decision-maker was at the table; we needed a customer and they needed a solution. But after the first few questions, we reached an impasse. The customer’s top priority was to start running its processes with automation and AI as soon as possible. I, on the other hand, could see that the boundaries of the problem had not yet been drawn. Where the processes began and ended, how they connected to one another and where the real problem lay were not clear enough. However powerful an ERP you have behind the scenes, I know that technology projects become more likely to fail where processes are tangled up and the problem is not clearly defined. And when processes are this intertwined and ownership is unclear, communication within the organisation often becomes one of the project’s hidden variables too. In the end, the customer signed with another technology company. We marked the opportunity LOST in our CRM and closed it.

But I couldn’t stop asking myself: if we had won that deal, would we really have made a good decision? MRR would have gone up, and we would have seen a big new customer on the dashboard. On the other hand, the project would have required serious analysis and process-design work, tied up a significant share of the team’s capacity, probably pulled our margin down and contributed little to the new capabilities we wanted to build. It is easy to say all this today. That is why I can’t say “Thank goodness we lost” either. Perhaps, had we taken the project, it would have turned into a very profitable, long-lasting relationship. Perhaps the other technology company is extremely successful today. I don’t know. I have lived only the future in which we lost. The one thing I know is that the word LOST in the CRM is not enough to tell all of this.

In business we do this more often than we think. If the sale closed, it was the right customer; if the employee succeeded, it was the right hire; if the partnership worked, it was the right partner; if the project finished on time, it was good project management; if the investment paid off, it was the right investment. Yet a salesperson can close a big contract on bad terms: today the sales team takes the applause, and six months later operations pays the price. A project manager can hit the date while the team has worked nights for months. Procurement cuts costs by 15 per cent, the KPI turns green, and months later a quality problem lights up red on the production screen. Sometimes a decision’s result arrives immediately, while its cost appears six months later on another department’s dashboard. We have a saying in Turkish: “While the wise man is still thinking, the fool has crossed the bridge.” Every time it comes to mind, I smile a little. Because the fool really can cross the bridge. But in business, the moment he crosses it, don’t we forget how he crossed and call him successful, and, if the bridge was big enough, perhaps even visionary?

Psychology has a name for this tendency: outcome bias. In Jonathan Baron and John Hershey’s classic experiments, when the same decision process was described with different outcomes, the decision that turned out well was rated as higher quality, and the same decision that turned out badly was rated as worse. That is why we need to draw a clearer line between a “right decision” and “decision quality”. The outcome tells us what happened; decision quality asks us to question how we decided with what we knew at the time.

Interestingly, we are all quite good at remembering outcomes in our companies. We can find last year’s revenue, margin, churn rate, the customers we won, the opportunities we lost and the projects that finished on time within a few minutes. Now think of the five most important decisions we made in that same company last year. What did we know when each decision was made? What did we believe? Before deciding, had we defined which outcome would make us say “this decision worked”? In most organisations, finding the answers to these questions is much harder than finding last year’s revenue. Remember how often we say in meetings, “Why did we do it this way?” As time passes, only the record of the decision remains, while its reasoning fades.

While working on an optimisation adaptation at Arya, I saw how easily this can happen. Our customer counted the start of the daily cost calculation not from the moment a record entered the system, but from the moment the operation actually began. It differed from the classic definition of cycle time, and for anyone looking only at the data, the first reflex was to see it as a technical mismatch that needed fixing. Yet there were quite reasonable grounds behind this choice, rooted in the customer’s operation. Today we know that. But if, two years from now, another team sees only two different timestamps and doesn’t know why, it might mistake a deliberate past decision for an error and “fix” it. Recording what a system does is not the same as remembering why we made it do so.

Working on Decision Intelligence, I increasingly see the value of AI here: in carrying not only the decision but also its context. What did we know that day, what did we believe, what assumptions did we make? If we can put these side by side when the outcome arrives, we can go further than saying “we succeeded” or “we failed”. We can begin to tell a bad decision apart from a bad outcome. Perhaps this is where one of AI’s most interesting roles for organisations begins: not only helping to make decisions, but testing the story an organisation tells itself after the decision.

We cannot go back to the past with today’s knowledge and change our decisions. But we can carry into the future what information and what reasoning today’s decisions rest on. The point is not to remember every decision, but to build a system in which good decisions are not left to chance.