The invisible cost of consensus.

A team that reaches consensus quickly is, almost by definition, a team that has not surfaced the parts of the decision that the consensus is hiding. The artefact most engineering teams should be producing is the disagreement, not the agreement.

I have sat through enough design reviews to recognise the pattern. The room walks through a set of options. There is a presentation, perhaps a deck. The owner of the decision states a preference. The senior engineer in the room — usually the most senior, sometimes the one most committed to the previous version — agrees with mild qualifications. The qualifications get noted. Two or three other people add small amendments. The room reaches what feels like agreement. The owner thanks everyone, says they will write it up, and the meeting ends. The decision is documented in a one-page summary that elides the qualifications, and the project moves forward.

What is missing from this picture is the disagreement. Specifically: the third engineer in the room who thinks the option being chosen is the wrong one, but who could not articulate why in the time available, and decided that pushing back further would not be worth the political cost. Their dissent does not appear in the documentation. It does not appear in the post-mortem six months later when the decision turns out to have been wrong. It does not appear at all, because the artefact the team produced was the agreement, and the agreement contained no record of the dissent.

01 What consensus optimises for

Consensus, treated as the primary output of a decision-making meeting, optimises for two things: the political comfort of the room, and the speed of moving on. Both are valuable. Neither has anything to do with whether the decision is right.

The political comfort matters because teams have to keep working together; engineers who feel routinely overridden in design reviews stop offering opinions, and a team without opinions is functionally a team of one. The speed matters because the decision is rarely the most important thing the team will do that week, and protracted argument burns the team's most expensive resource. I am not arguing against either of these. I am arguing that a meeting whose only artefact is "we agreed on X" has produced no record of what the team actually knows, and the team will pay for that absence later.

02 The artefact that is missing

What I would replace the agreement-only output with is something I have started calling, slightly awkwardly, a disagreement memo. It is a one-page document, written immediately after the meeting by whoever is least invested in the outcome, that captures the following:

• The decision that was made.
• The two or three options that were not chosen.
• The strongest argument anyone in the room made against the chosen option, even if the person who made it has subsequently softened it. Especially if they have softened it.
• The conditions under which the team would expect to revisit the decision.

That last bullet is the most important one. A decision recorded with no revisit conditions is a decision that has implicitly committed the team forever; a decision recorded with explicit revisit conditions is a decision that the team has agreed to monitor. Six months later, when the post-mortem happens, the disagreement memo gives the team something concrete to compare actual outcomes against. The argument that was softened in the meeting is preserved in writing, and either it has been borne out by events or it has not. Either is informative.

The team that records its disagreements is the team that learns from them.

03 Why this is hard

The mechanical part of writing a disagreement memo is trivial. The cultural part is not, and I want to name the parts that make it hard, because pretending it is easy is the same dishonesty I argued against in the previous essay.

The first difficulty is that the person whose dissent was softened often does not want it preserved in writing. Their reasoning runs: the decision is made, the team has moved on, putting my objection into a memo just embarrasses me when the decision turns out to have been right. This is a real concern, and the response to it has to be a cultural one — the team has to internalise that recording dissent is not a status game, that the dissenter who turns out to have been wrong is not punished for having dissented, and that the value of the record comes from completeness regardless of who is right.

The second difficulty is that the senior people in the room are usually the ones with the strongest ability to dampen disagreement, and they often do so unconsciously. A senior engineer who states a preference early in the meeting — even a tentative one — anchors the discussion in a way that makes opposing views harder to articulate. The remedy is not for senior engineers to become silent; it is for the meeting to have a structural step where dissent is collected before any senior preference is voiced. This is mechanically simple — three minutes of silent writing, then everyone reads what they wrote — and culturally hard. Most teams I have observed try this once and abandon it.

The third difficulty is that organisations reward the appearance of consensus. A leadership team looking at a portfolio of fifty engineering decisions has no time to read fifty disagreement memos; what they want is a dashboard of green checkmarks. The team that produces disagreement memos looks, to that leadership view, like a team that argues a lot. The remedy here is partly upstream — leadership has to ask for the memos, not just the decisions — and partly internal: the team has to be willing to look like it argues a lot in exchange for the documentation that lets it learn.

04 What it does not solve

Let me name the limits, because they matter. The disagreement memo does not solve the problem of teams that have nothing to disagree about because nobody has thought hard enough about the decision; in those teams, the memo is empty in a way that does not reveal the underlying issue, which is the lack of investigation. The memo does not solve the problem of toxic teams that produce too much disagreement and cannot move; in those teams, the memo accelerates the toxicity rather than channelling it. And the memo does not solve the problem of decisions that are political at base — about resources or status or scope of authority — where the disagreement-of-record is a thinly disguised proxy for who reports to whom.

For decisions in the territory the memo is built for — technical decisions made by competent teams who broadly trust each other but disagree on specifics — it works as a small, cheap discipline that makes the team's collective memory better. That is the population I am writing for.

05 The connection to Pareto thinking

I made an argument in a previous essay that the right answer to most engineering decisions is a curve, not a number. The disagreement memo is the same argument applied one level up. The decision the team makes is a single point; the curve the team explored to reach that point is the disagreement memo. Without the memo, the curve disappears, and only the point remains. A team that has lost the curve cannot tell, six months later, whether the point was on it.

This is the part of the team's knowledge that is most easily lost and most expensive to recover. The mechanical step of writing it down — three minutes of silent input collection, fifteen minutes of memo drafting, one page of artefact — is small enough that the marginal cost is rounding error. The marginal benefit is the team's ability to learn from its own decisions. Most teams I have worked with have been pleasantly surprised at how much they did not know about their own decision-making until they started capturing it.

06 The smallest version

The version of this practice you can adopt next week, with no political capital and no organisational change, is just this: at the end of every design review you run, write down the strongest argument anyone made against the option you chose. Write it down even if you disagree with it. Save the file in the project folder. Six months later, when you do the post-mortem, read it.

Do this for a year. The compounding effect is, in my experience, larger than any other small change to engineering practice I have seen. It costs nothing. The only person who can stop you from doing it is you.