What Thinking in Bets taught me about IT post-mortems
In 2018, Maersk and IBM made the best possible decision with the information available. In 2022, they shut it all down. Since then, everyone has been explaining why it was a mistake. That’s where it gets interesting. Confusing a bad outcome with a bad decision is the most widespread bias in our IT post-mortems, and nobody is really on guard against it.
The scene you know
The project is dead. The meeting opens. Someone pulls out the original timeline, someone else pulls out the initial KPIs, a third person starts listing what “should have” been done differently.
An hour later, everyone agrees: the warning signs were there from the start. The team should have seen them. The initial decision was risky. We won’t make that mistake again.
The post-mortem wraps up. The conclusions are archived. And the next project kicks off with exactly the same decision biases, just better camouflaged under a new governance.
It has nothing to do with how smart the people in the room are. It’s a question of method, and Annie Duke, in Thinking in Bets, put it better than anyone.
What TradeLens was trying to solve
Before going further, a bit of context for those who don’t follow the shipping industry.
Shipping a container of fresh produce from East Africa to Europe means passing through the hands of about 30 organizations (carriers, ports, freight forwarders, customs, insurers, banks) and generating nearly 200 communications, most of them on paper. A single error in a customs document can hold up the goods for days. Late information about a ship’s arrival means a terminal that couldn’t get its cranes ready.
In 2018, international shipping was one of the most important sectors of the global economy and one of the least digitized. The shipping documents that matter most, bills of lading, still mostly existed on paper, just as in the 19th century.
Blockchain seemed like the perfect tool for this problem: a distributed ledger, shared among all the players, with no central trusted third party, letting everyone see the same data in real time without having to share it through bilateral APIs or paper.
The 2018 decision was reasonable
In August 2018, IBM and Maersk officially launched TradeLens. Supply Chain Dive, the industry’s reference publication, named the project “Business Decision of the Year.” Not some minor award: the market’s most informed observers were endorsing the bet.
The reasons to believe in it were solid. The problem was real and documented, experienced daily by thousands of companies, with measurable direct costs. Nothing like a consulting firm’s hypothesis. Then there were the partners: Maersk, the world’s largest shipping line, and IBM, at the time firmly established in enterprise blockchain with Hyperledger Fabric. Their partnership signaled an industrial ambition, not just another pilot. Regulatory validation followed. The US Federal Maritime Commission had given its antitrust green light, and the World Customs Organization was taking part in the standardization work.
And the first adoption signals were pointing the right way. By early 2019, 94 organizations had joined the pilot phase. In May, CMA CGM and MSC, two of Maersk’s biggest competitors, announced they were joining, followed by Hapag-Lloyd and Ocean Network Express. By the end of 2019, four of the world’s six largest shipping lines were on the platform: 175 organizations, two million events tracked per day.
An IBM executive had publicly laid down the success criterion right from the launch: “It rests on a single factor: bringing the entire ecosystem together around a common approach that benefits all participants equally.”
The risk had been named. Clearly. From day one.
What killed TradeLens
On November 29, 2022, Rotem Hershko, head of platforms at Maersk, announced the shutdown. The official line: “The need for global industry collaboration has not been achieved.”
By the time it shut down, TradeLens had tracked 70 million containers and published 36 million electronic documents. The technology worked.
What didn’t work was the dynamic between the players. For three structural reasons.
The first: the neutrality was never believed. Maersk held the majority of the joint venture and remained a direct competitor of the other carriers. The governance adjustments made in 2019, meant to give the other shipping companies more transparency, changed nothing. Sharing your operational data on a platform controlled, even partially, by a competitor is a red line in such a cutthroat industry.
Next, the freight forwarders refused en masse. Their reading was crystal clear: TradeLens wanted to digitize document flows and cut out the middlemen. Why would a freight forwarder help build the platform that makes it useless? No incentive was offered to offset that risk.
Finally, the Asian carriers never came. COSCO and the Chinese shipping lines joined GSBN, the Global Shipping Business Network, launched at the urging of the Chinese government. Two parallel networks emerged, making the ambition of universality impossible.
IBM, for its part, had started cutting its blockchain staff massively well before the official shutdown: more than 100 jobs eliminated, according to estimates. The financial dynamic was no longer sustainable.
No bug killed the platform. It was the business model that gave way, against a backdrop of competitive dynamics that no one could measure precisely in 2018.
Thinking in Bets: the distinction that changes everything
Annie Duke was a professional poker player for twenty years before becoming a decision-making consultant. In Thinking in Bets, she introduces a concept she calls resulting: the bias of judging the quality of a decision solely through the quality of its outcome.
Her argument is simple. A good decision can produce a bad outcome if uncontrollable factors work against it. A bad decision can produce a good outcome if luck is on its side. Confusing the two means learning the wrong lessons.
Resulting is particularly toxic in post-mortems, because it works backward: we know the outcome, and we retrospectively rebuild a chain of warning signs that “should have” been seen. That’s hindsight bias, and Duke shows that it is almost systematic.
The right question isn’t: “Was it a good decision?”
The right question is: “Given what we knew at the time of the decision, was it a reasonable bet?”
For TradeLens in 2018, the answer is yes. The problem was real. The partners were credible. The adoption signals were positive. The main risk, collaboration between competitors, was known, named, and seemed to be on its way to being solved as the major carriers joined the platform.
Just because it ended badly doesn’t mean it was a bad decision.
What this says about our IT post-mortems
I wasn’t involved in the TradeLens project. But I’ve sat through enough IT post-mortems to recognize the pattern.
The IT modernization project that ran 18 months late on a 24-month schedule. The CRM rollout that reached 40% adoption six months after go-live. The cloud migration that cost three times the initial budget. In each case, the review meeting reconstructs something that was obvious in hindsight: we should have seen that.
What we almost never do is honestly reconstruct what we knew, and what we couldn’t have known, at the time of the decision.
Duke proposes a simple discipline: before analyzing what happened, write down what the team knew at the time of the go/no-go. What signals were available? What risks had been identified, and what was their estimated probability? What was the logic of the bet?
This document rarely exists in IT organizations. The business case, yes. The formal risk analysis, sometimes. But the equivalent of a “bet sheet” (here’s what we know, here’s what we don’t know, here’s why we’re going ahead anyway), almost never.
Without this document, the post-mortem can only reconstruct a story consistent with the outcome. That’s storytelling, not analysis.
The irony of the TradeLens case
What is remarkable about TradeLens is that the fatal risk was named publicly, right from the launch, by IBM itself: “success rests on a single factor: bringing the entire ecosystem together.”
They knew. They said so. And four years later, everyone quotes that sentence as proof that they should have known it would fail.
That’s hindsight bias at work, exactly. In 2018, the sentence was a commitment to the ambition, not an admission of anticipated failure. And the 2019 signals, four of the six largest carriers on board, seemed to show that this commitment could be kept.
Resulting makes us read the same sentence differently depending on whether we read it before or after the outcome. That’s the real problem.
What we should do instead
Duke doesn’t say we should stop analyzing failures. She says we need to change the central question.
Instead of “What didn’t work?”, which calls for a retrospective reconstruction, ask: “Was the decision process sound, given what we knew?” That question calls for an assessment of the method.
In practice, two things change in an IT post-mortem.
First, document the decision before knowing its outcome. Not the business case: the logic of the bet. What we know, what we don’t know, the conditions under which we’ll agree to revisit it. The best investment teams do this systematically. IT teams, rarely.
Second, separate lessons about the process from lessons about the substance. “We underestimated the freight forwarders’ resistance” is a lesson of substance: it applies to this specific case. “We hadn’t planned a 12-month review point on our adoption assumptions” is a process lesson: it applies to every project that follows.
IT post-mortems excel at lessons of substance. They almost systematically ignore process lessons.
To wrap up
Good decision, bad outcome. The two can coexist without contradicting each other. Maersk and IBM didn’t do a bad job, or at least nothing in the available sources supports that claim. And yes, useful lessons can be drawn from it. Just not the ones most post-mortems take away.
The real lesson isn’t “beware of blockchain consortiums” or “don’t launch a platform with a competitor as majority partner.” Those are lessons of substance, valid for this case, hard to generalize.
The real lesson is more uncomfortable: we don’t know how to evaluate our decisions. We know how to evaluate our outcomes. It’s not the same thing, and we keep confusing the two.
Annie Duke formalized it for poker. It applies word for word to running IT.
Annie Duke, Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts, Portfolio/Penguin, 2018.
Sources on TradeLens: Maersk (official press release, Nov. 2022), Supply Chain Dive, Computerworld, MIT CISR, PierNext / Port of Barcelona.