By Mark Buck
A good result gets applause and closes the file. A bad one gets a post-mortem, and only one of those actually teaches you anything.
In 2011, Francesca Gino and Gary Pisano identified a recurring problem in Harvard Business Review: businesses investigate failure but applaud success, and therefore learn more readily from the first than the second.¹ The remedy already existed. US Army after-action reviews examine what was supposed to happen, what actually happened, what was right or wrong, and how performance should change next time. The review is concerned with performance, rather than whether the result is labelled a success or failure, and current Army doctrine retains that structure.² A 2022 meta-analysis of 83 studies, covering 955 teams and 4,684 individuals, found that after-action reviews improved performance overall.³
A different vantage point
What follows takes a different vantage point: one business’s own account, from inside, of a result that had not yet had time to earn itself a comfortable story.
A useful rule is simple: if a result is far enough from expectation that the equivalent shortfall would have triggered an investigation, the business should investigate the positive variance too. After-action reviews are triggered by an event regardless of its outcome. In ordinary business life, failure commands attention while success usually does not. The useful shift is to treat unexpectedly strong performance as the trigger for investigation, and to test whether it is real before calling it reproducible.
Praise is not an explanation
We recently implemented Moneyinfo as a new client portal at GSI. It was delivered despite holiday disruption, integration difficulties and delays outside our control. Different colleagues held different, specific responsibilities. One person owned the integration. After go-live, responsibility deliberately passed to someone else, so adoption stayed somebody’s job rather than an assumption. When the implementation phase ended, the supplier’s project manager praised the team warmly, in front of everyone: good people, working well together.
She was right. It was also not an explanation. Had the project failed, no one would have accepted “poor people, working badly together” as a diagnosis. We’d have wanted to know exactly which part had failed. Because it succeeded, a compliment was allowed to close the file.
What actually explains it
Looking back, the project succeeded for more specific reasons. The implementation had sustained sponsorship from the top: I kept it visible, protected its priority and followed individual tasks closely. The people involved were personally invested, having lived the problems the project was meant to fix. Responsibility was distributed but not vague.
Communication was frequent and deliberately lightweight. Internally, we used short, stand-up-style meetings to surface tasks, dependencies and obstacles. We never called them agile ceremonies, and the staff didn’t care what they were called. The formal weekly call with the supplier’s project manager was largely a half-hour progress update; most of the real coordination happened between those calls. Everyone could see who was depending on whom. That built its own accountability. Nobody wanted to be the one holding up the rest of the team. When holidays and third-party delays threatened the plan, the problem surfaced early enough to fix. That rhythm did not end at go-live. We still hold a five-minute weekly review of system use and outstanding issues. Those reviews identify clients who have yet to log in, allowing us to contact them again and offer support. Adoption is therefore managed as continuing work rather than assumed from a successful implementation. None of that diminishes the compliment. It makes it useful.
Five questions for an unexpectedly good result
A positive-variance review doesn’t need to smother every success. It’s justified when the result is material enough that its opposite would have demanded one.
Is the variance real? Check the benchmark before the story. Was the expectation valid, the comparison fair? A weak budget can manufacture an exceptional result as easily as a genuine one.
What actually produced it? Reconstruct the contribution rather than repeating the outcome. Who did what, and what did the client, the market, the technology or an existing relationship contribute that wouldn’t be there next time?
What difficulty was overcome? Success makes the underlying difficulty disappear from view. Record the workarounds and coordination required, or the organisation remembers the clean result and forgets what it cost to produce.
What shouldn’t be repeated? A win can contain exhausted people or unsustainable intensity. Work out which parts were a sensible one-off and which the organisation could safely make routine.
What can be reproduced, and where will we test it? Separate what’s personal to the individual from what’s a transferable method, then choose the next piece of work and see whether the explanation actually travels.
Reproducing without noticing
We saw similar behaviour during a later, time-sensitive internal exercise. A considerable volume of work was divided between colleagues, with named responsibility and deadlines throughout. Partway through, priorities shifted and part of the work had to be redone under pressure. The team still finished on time.
I cannot claim that we consciously extracted a method from the first project and applied it to the second; we did not conduct that exercise formally. The honest account is that we had begun reproducing the behaviour before properly describing it.
We would not replace a failure investigation with criticism. We should not replace a success investigation with praise.
Conclusion
The penalty for skipping the investigation does not arrive immediately. Nothing is visibly broken and no deadline forces the question. It arrives later, when the business wants the result again and discovers that it kept the applause but not the capability. Gino and Pisano were right that failure teaches more readily than success. That’s not a law of nature. It’s just what happens to any result nobody bothered to open the file on.
AI acknowledgement
AI tools were used for research support and sentence-level refinement. The article’s thesis, examples and final editorial decisions are the author’s own.
Mark Buck
