Picture an engineering post-mortem for a production incident that took down a payments system for forty-one minutes on a Tuesday. The document is sober and specific. There is a timeline, accurate to the minute. There is a sequence of decisions made under uncertainty by an on-call engineer who is named, but not blamed — the writeup goes out of its way to note that any reasonable engineer would have made the same call given what was visible on the dashboard. There is a list of contributing factors, ranked. There are action items, each with an owner and a date, mostly aimed at the system rather than the people. The document is circulated widely. Two engineers from a different team read it and propose a fix to a related component.
Now picture the board version of the same exercise, after a $200M acquisition that has, eighteen months in, gone visibly wrong.
The room is smaller. The document is shorter, or there is no document, just a discussion. The timeline is fuzzy. Names are present but the question being asked is not what the system did — it is who is going to be associated with the result. There are no action items aimed at the decision process. There are personnel changes that everyone understands are connected to the acquisition but that are framed, formally, as unrelated. The conversation is not circulated. Twelve months later the same board makes a structurally identical decision about a different acquisition, and nobody notices the structural similarity, because the document that would have surfaced it does not exist.
These two exercises share a name and almost nothing else.
The structural difference, named
Engineering post-mortems work because the culture around them is blameless and the artifact is a system fix. Both pieces are load-bearing. The blamelessness is not a moral posture; it is a tool. It exists because engineers learned, the hard way, that punishing the on-call for an incident produces engineers who hide incidents, not engineers who prevent them. The system-fix orientation exists because engineers also learned that human error is a downstream symptom of system design, and that the leverage is in the design.
Board post-mortems, when they happen at all, assume the opposite of both. They assume a person to credit or blame, because that is what board governance is structurally for — the board's job is to evaluate management. They assume a narrative to produce, because boards are accountable to shareholders and that accountability has to be performed in some legible form. These are not bad assumptions for what a board normally does. They are catastrophic assumptions for what a post-mortem normally does.
A board that runs its post-mortems the way it runs its evaluations will produce, reliably, executives who present their failures rather than examine them. The document the board needed will not be written, because the people who would have written it have correctly concluded that writing it is career-limiting.
This is, in our experience, the central reason board-level decision reviews do not produce learning. The mechanism that makes engineering post-mortems valuable is the same mechanism the board's structure cannot support. Importing the word without the mechanism is worse than not running the exercise at all, because it produces the appearance of learning while teaching the organization not to learn.
What a board-level review should look like
The fix is not to import the engineering version unchanged. Boards cannot be fully blameless, because boards do, ultimately, have to evaluate management. The fix is to separate, in calendar and document, the decision review from the performance review. The two exist on different time horizons and ask different questions, and conflating them is what produces the dysfunction.
The decision review answers four questions, none of which depend on who is in the room.
What information did we have at the time of the call, and what would have been knowable with reasonable effort that we did not collect. What was the frame we used to organize the decision, and what alternative frames did we consider and reject. What were the assumptions the case rested on, and which of them have since proven wrong, right, or untestable. What, in the current outcome, is signal about the quality of our reasoning and what is noise about how the world happened to move.
These questions sound abstract. They are not. They produce, when answered honestly, a document a future board can read. The decision review for the $200M acquisition above would say: we used a synergy frame; the alternative frame of "buy the team and shut the business" was raised in pre-read and dropped without analysis; the central assumption was cross-sell to our existing accounts at a rate of 18%; that assumption has proven to be closer to 4%; the gap is mostly signal — our channel team is not built for this kind of motion, and we should have known that — and partly noise, in that the regulatory window narrowed faster than anyone in the market predicted. A board that reads that document twelve months later, before approving the next acquisition, is a board that has institutional memory. A board that did not write the document does not.
The blameless part is the hard part
We do not pretend the blameless framing is easy at board level. A bad acquisition was, in some real sense, somebody's recommendation. That somebody is in the room, or recently was. Holding the decision review separate from the personnel question requires actual discipline from the chair, and the chair has to be willing to say, on the record, that this meeting is about the call, not the caller, and that the personnel implications will be handled in a separate forum at a separate time.
The reward for that discipline is a document that gets written truthfully, by people who are not playing defense. The cost of not paying it is the pattern we keep seeing: boards that respond to failed bets by replacing the executive and keeping the process, when in three quarters of the cases we have studied the process was the larger problem and the executive was, on balance, doing competent work inside a system that made the bad call more likely than the good one.
The other piece of the discipline is to write down the decision before the outcome is known. This is the connection to the premortem we have argued for elsewhere. A premortem written at the time of the call is, two years later, the cleanest possible input to a decision review. It contains the frame, the assumptions, the risks the team identified, and the kill criteria they set — all uncontaminated by hindsight. Boards that run premortems and then run decision reviews against them are running a closed loop. Boards that run neither are running on memory and ego, which is the system most boards default to and which produces the patterns we have been describing.
Revisiting, as a habit
The last piece is repetition. Engineering post-mortems are revisited; the document is read again when a related incident occurs, and the action items are tracked against a real calendar. Most board decision reviews — when they happen at all — are one-off events tied to a specific failure. They are not revisited. They become, at best, a footnote in a director's private notes.
The boards we have seen do this well treat decision reviews as a standing item, not an exception. Once a year, the board picks three to five of the most consequential decisions of the prior eighteen months — including the ones that worked — and reviews them against the questions above. The exercise takes a morning. It produces, in our experience, more durable governance value than any of the formal compliance work the board is required to do, because it is the one mechanism that systematically converts the board's experience into something the next board can use.
We help boards build this discipline into their calendar before the failure that forces it on them. The work is unglamorous and the artifacts are short. Both of those things are features. The board that does this for three years in a row is a measurably different board than the one that does not, and the company underneath it is a measurably different company. The room is just quieter about it than the failure modes it has stopped producing.
Writes about decision quality at Bayeseon. Reach the team at hello@bayeseon.com.