Meetings Are a Decision Latency Tax

Meetings are not automatically waste. Some decisions need live negotiation, shared context, or fast incident coordination. The problem is that meetings are often used as the default container for unclear decisions, and defaults become expensive.

The thesis

Meetings are a decision latency tax. Pay it only when the meeting reduces more delay than it creates.

The visible cost of a meeting is calendar time. The larger cost is usually interruption, preparation drag, waiting for availability, context switching, and ambiguous follow-up. A one-hour meeting with six people can consume more than six hours because it splits attention before and after the event.

The principal-engineer question is not "should we have fewer meetings?" It is what decision needs to move, and what is the cheapest coordination mechanism that will move it?

The production pattern

The calendar entry usually appears after a decision has already stalled. A technical tradeoff is unclear, a launch needs alignment, a dependency owner has concerns, or an incident exposed disagreement. Someone schedules a meeting because live discussion feels responsible.

Sometimes it works. The right people join, the decision is named, options are clear, and the group leaves with ownership. More often, the meeting tries to do five jobs at once. It broadcasts status, discovers context, debates alternatives, negotiates priority, and assigns work. People leave with different memories. Another meeting appears because the first one created conversation but not closure.

The organization experiences this as slowness, but the root cause is poorly typed coordination.

The model

I classify meetings into five types: decision, alignment, broadcast, social, and incident.

Decision meetings: exist to choose between options. They need a decision owner, options, tradeoffs, required evidence, and a closure rule. If options are not written down before the meeting, the group will spend live time discovering the problem.

Alignment meetings: exist to surface assumptions across groups. They need a shared artifact and explicit open questions. They should end by naming disagreements, not pretending all concerns were resolved.

Broadcast meetings: exist to distribute information. Most should be replaced by a written update unless the information is sensitive, emotionally loaded, or likely to produce immediate questions that change action.

Social meetings: exist to build trust, belonging, or informal context. They are valid, but they should not be disguised as decision forums.

Incident meetings: exist to coordinate under time pressure. They need clear roles, a live state artifact, and a bias toward action. Incident meetings are expensive because delay is also expensive.

The type decides the artifact. A decision needs a decision record. Alignment needs an assumptions list. Broadcast needs a note. Social time needs consent. Incidents need a live timeline and owner map.

Where this goes wrong

The first mistake is scheduling discussion before preparing the decision. Live time is poor for reading large context, discovering options, and editing wording. It is better for resolving disputed assumptions, making tradeoffs, and committing owners.

The second mistake is inviting everyone who might care. That feels inclusive but often increases latency. People wait for a calendar slot, attend without clear authority, and then defer to someone absent. Inclusion should come through artifacts and review windows unless live negotiation is necessary.

The third mistake is letting meetings end without a durable output. If there is no decision, owner, rejected alternative, or next evidence request, the meeting created memory that will immediately fragment.

The counterpoint is that some meetings save enormous time. A hard disagreement can resolve faster live than through a long comment thread. Sensitive topics deserve human bandwidth. Incidents need synchronous coordination. The argument is not anti-meeting. It is anti-untagged meeting.

What I do now

I ask what artifact would replace the meeting. If nobody can answer, the meeting is probably hiding an unclear purpose. A proposal, decision table, risk list, written update, incident timeline, or owner map should exist before or after the live conversation.

I require decision meetings to have a decision owner. Consensus can inform the decision, but someone must be accountable for closure. Without ownership, the group may optimize for everyone feeling heard rather than for the system moving responsibly.

I push broadcast work into writing. Written updates let people read at the right time, ask better questions, and preserve memory. They also make hidden disagreement visible because people can comment on the same text.

I protect flow by batching coordination. A calendar full of scattered half-hour meetings can damage engineering output more than a smaller number of deliberate blocks. Decision latency includes the time it takes people to reload the problem after interruption.

Finally, I treat recurring meetings as inventory. Each one should have a current job. If the job has disappeared, the meeting should disappear or change type.

Closing takeaway

Before scheduling, name the meeting type, the decision or artifact it must produce, and why live time is cheaper than written coordination.