There’s a specific kind of meeting that fills calendars in engineering organizations. It has a reasonable-sounding title. It has three to eight attendees who all have better things to do. It has an agenda that, on closer inspection, describes a decision that one person could have made yesterday. Nobody calls it a decision-avoidance meeting. But that’s what it is.
This isn’t about meetings being bad in general. Some meetings are irreplaceable: genuine collaborative work, relationship-building, real-time coordination during an incident. This is about a particular species of meeting that exists primarily to give its organizer the feeling of forward motion while deferring the discomfort of being the person who decided.
The Cognitive Mechanics of Deferral
Decisions carry a specific kind of weight that tasks don’t. When you close a task, you’ve done something. When you make a decision, you’ve foreclosed alternatives, and you’ve done so with incomplete information, which is always the case. The psychological term for the distress of holding multiple conflicting options is cognitive dissonance, and scheduling a meeting is a remarkably effective short-term treatment for it.
The moment you put a calendar invite out, the decision is no longer yours to make alone. You’ve distributed the cognitive load. You’ve also created a plausible explanation for delay: “We’re aligning on this Thursday.” The problem is that Thursday’s meeting rarely produces the alignment you claimed to need. It produces a follow-up meeting, or a decision that gets made by whoever spoke most confidently in the last five minutes.
This deferral mechanism is especially common in technical roles, and I think that’s because developers are trained to gather requirements before building. That instinct is correct in the right context. It becomes a liability when applied to decisions that don’t require more information, only more willingness to own the outcome.
What a Decision-Avoidance Meeting Looks Like
The tell is in the pre-meeting behavior. If you’re scheduling a meeting and you already know what you think the right answer is, ask yourself what you actually need from the other attendees. If the honest answer is “I need them to agree with me so I feel covered,” that’s not a meeting. That’s approval-seeking with a calendar invite.
Some patterns that show up reliably:
The Alignment Meeting. The decision is made but hasn’t been announced. The meeting exists to manufacture consensus after the fact, which is different from building consensus before the fact. Attendees often sense this and resent it.
The Options Meeting. You present three options you’ve already ranked. The meeting is framed as collaborative evaluation but is actually a request for the group to validate your first choice. When they don’t, you schedule another meeting.
The Stakeholder Review. You’ve brought in people who have no real stake in the outcome but whose presence makes the decision feel more sanctioned. The RACI matrix (Responsible, Accountable, Consulted, Informed) exists partly to prevent this, but in practice, “Consulted” becomes “mandatory attendee” for political reasons.
The Scope Creep Meeting. This one starts as a legitimate sync but expands until it’s making decisions that weren’t on the original agenda, with people who weren’t invited to decide them.
Why Organizations Reward This Behavior
The frustrating part is that decision-avoidance meetings are often individually rational even when they’re collectively wasteful. If your organization punishes wrong decisions more than it rewards right ones, the calculus tilts toward deferral. A meeting creates a paper trail of “we discussed this together,” which distributes blame in a way that a solo decision doesn’t.
This is an organizational incentive problem. Companies that have a stated value of “bias for action” and then conduct post-mortems that assign individual blame for bad decisions are training their people to schedule more meetings. The culture and the process are in direct conflict, and the process usually wins because it’s what actually happens to people’s careers.
There’s also a status dimension. Calling a meeting is a form of organizational power. It says: my work is important enough to interrupt your work. Running a meeting where senior people attend, even if the meeting produces nothing, is a form of visibility that many people have learned to value. This is harder to fix because it’s baked into how influence works in flat-ish organizations.
The Asymmetry Nobody Mentions
Here’s something that took me too long to notice: the cost of a decision-avoidance meeting is paid by the attendees, not the organizer. The organizer gets relief from cognitive dissonance. The attendees get an hour of their time consumed for a decision that could have been made without them, and then they have to go back to their actual work.
If you’re a senior engineer or a tech lead, your peak focus hours are genuinely scarce, and a decision-avoidance meeting burns them with negative return. Not zero return. Negative, because now you’ve lost the flow state and you’re slightly more cynical about the next calendar invite.
The organizer, meanwhile, has offloaded their discomfort and may not even recognize what they’ve done. I’ve been this person. The meeting I scheduled to “align stakeholders” on an architectural choice I’d already made was a decision-avoidance meeting. I knew what I thought we should do. I was scared to be wrong about it alone. So I gathered five colleagues and called it collaborative design.
The Decision-Ready Test
Before scheduling any meeting where a decision is involved, it’s worth running through a short checklist. Not as bureaucracy, but as a forcing function to make you articulate what you actually need.
First: can you write down your recommendation right now? If yes, you may only need buy-in, not input. Send the document with a deadline for objections. If no one objects by Thursday, the decision is made. This is the RFC (Request for Comments) process that many engineering organizations use for technical decisions, and it works because it forces the proposer to commit to a position and allows async feedback from people who weren’t interrupted.
Second: who actually needs to be in the room? If you’re being honest, “this person will be upset if they’re not included” is a political reason, not a decision-quality reason. These are not the same thing.
Third: what would make this meeting unnecessary? If the answer is “someone just deciding,” and you’re the someone, the meeting is unnecessary.
The RFC approach deserves more credit than it gets. It externalizes the decision-making process in a way that is searchable, auditable, and asynchronous. The Rust programming language’s RFC process and the IETF’s long-standing use of written proposals for internet standards both demonstrate that consequential technical decisions can be made without synchronous meetings if the written artifacts are taken seriously.
What Changes When You Name the Pattern
Once you start recognizing decision-avoidance meetings in your own calendar, you can’t un-see them in others’. The more useful thing is to develop a reflex for offering to short-circuit them.
When someone books a meeting that looks like avoidance, the most helpful thing you can do is respond with: “Can you share your current thinking before we meet? If you’ve already got a direction, I can review async and flag any concerns.” This either accelerates a legitimate decision or surfaces the fact that the organizer didn’t actually have a clear position, which is worth knowing before you give them an hour.
The other pattern worth building is separating decision meetings from execution meetings cleanly. A decision meeting should end with one artifact: a written record of what was decided and who owns it. Not action items. Not next steps. One sentence: we decided X, and Y owns it. If a meeting can’t produce that sentence, it wasn’t a decision meeting, and you should ask what it was.
The cost of meetings that should have been emails is real and documented. Decision-avoidance meetings are a subset of that problem but they’re more pernicious because they look more legitimate. At least the meeting-that-should-have-been-an-email usually has useful information in it. The decision-avoidance meeting is burning time in the service of someone else’s anxiety management.
What This Means
Decision-avoidance meetings feel like progress because they involve other people and produce calendar events. They’re not progress. They’re a mechanism for distributing the discomfort of ownership while paying for that relief with other people’s time and attention.
The fix is not a new process or a better meeting template. It’s honesty about what you’re actually asking for when you send a calendar invite. If you need input, get input. If you need a decision, make one and communicate it. If you need someone to tell you you’re right, that’s a different problem, and no amount of alignment meetings will solve it.
The decisions that are hardest to make alone are usually the ones that matter most. That’s an argument for making them, not for scheduling them.
