How to Make Decisions Without a Meeting

A team I worked with spent three weeks deciding whether to move off a database. Not because the decision was hard. Because it kept waiting for a meeting.

The question needed a few people who sat in San Francisco, London, and Bangalore, and the only hour all three were awake was a Thursday slot that was already crowded. Week one, something urgent ate the agenda and the database question got four minutes at the end, when everyone was tired and half-listening. Week two, the London person was out. Week three they finally talked it through, agreed in the room, and the engineer who'd been blocked the whole time started building. Twenty-one days to make a call that one person could have written up in an afternoon.

That's the tax nobody puts on the invoice. When your default way of deciding something is "let's discuss it live," every decision inherits the scheduling problem of a distributed team. It waits for the overlap window, and on a team spread across continents that window is tiny and always contested.

The meeting is where decisions go to wait

Most teams don't decide in meetings because meetings are the best place to decide. They decide in meetings out of habit, and because getting everyone in a room feels like the responsible thing to do. On a colocated team the cost of that habit is low. You grab people, you hash it out, you move on. The overlap is all day.

Spread the same team across timezones and the habit quietly breaks. The meeting that used to be free now costs you the scarcest thing you have, which is shared waking hours, and it costs the blocked person days of waiting for that meeting to arrive. This is the same instinct that pushes good remote teams toward async-first communication in general: writing things down where people can read them on their own schedule beats gathering everyone at once. Decisions are the highest-value place to apply it, because a decision that waits blocks real work, and a meeting to make it burns the hours you'd rather spend on the conversations that genuinely need a face.

So stop syncing decisions to meetings by default. Most of them don't need one.

Write the decision down as a short proposal

The move that replaces the meeting is a written proposal, and it's less work than it sounds. One person, usually whoever owns the problem, writes a page. Not a spec, not an essay. A page.

A good decision doc says four things. Here's the situation and why we have to choose. Here are the options I considered, honestly, including the one I'm not picking. Here's the one I'd go with and why. And here's what I need from you: a sign-off, a strong objection, or silence if you're fine with it. That last part is where most async decisions live or die, so I'll come back to it.

The reason this works is the same reason a good async message works at all. It has to be self-contained enough that the reader can act without a reply-and-wait loop. A vague "thoughts on the database thing?" dropped in Slack isn't async, it's a meeting you scheduled by accident, because nobody can respond usefully without three rounds of clarifying questions across an eight-hour gap. Do the thinking up front, write it down once, and the eight-hour gap stops mattering. Your teammate in Bangalore reads the whole argument at 9am her time and responds to the actual proposal, not to a fragment of it.

Writing the proposal also does something a meeting never does. It forces the owner to make the case before anyone weighs in, which surfaces the weak options while they're still cheap to fix. Half the time the person writing the doc talks themselves out of their own bad idea by paragraph three, which is the doc doing its job.

Put a real deadline on input, and let silence mean yes

Here's the part teams get wrong. They write the proposal, post it, and then wait. And wait. Because "let me know what you think" has no end, and everyone's busy, and reviewing someone else's decision is nobody's top priority. The doc sits there gathering two comments and no resolution, and after a week the owner gives up and schedules, you guessed it, a meeting.

The fix is a deadline attached to a default. Something like: "I'm going with option B unless someone raises a blocking objection by end of day Thursday your time." Now the doc has a clock, the clock has a timezone so nobody's guessing, and silence becomes a decision instead of a stall. If you've read the thing and you're fine with it, you do nothing, which is exactly the load you want on the ninety percent of people who don't have a strong view.

This only works if you mean it. The first time you let the deadline pass and then relitigate the decision anyway because someone woke up with second thoughts, you've taught the team that the deadline is theater and the real decision still happens in a meeting. Hold the line. If nobody objected by Thursday, it's Friday and you're building option B.

Give people enough runway to actually read it, though. A deadline that lands before your Bangalore teammate has had a working day to respond isn't a deadline, it's a way to make a unilateral call while pretending you asked. Two full working days is a reasonable floor for anything that matters, more if the decision is expensive to reverse.

Name who decides, because consensus doesn't scale across timezones

A written proposal with a deadline still needs one thing a meeting quietly provides: someone whose call it actually is.

Async decision-making falls apart when "we'll decide together" means "we'll decide when everyone happens to agree," because across six timezones and four opinions, everyone agreeing is a rare event you could wait weeks for. Input from many, decision by one. The owner of the doc gathers the objections, weighs them, and decides. Not by vote, not by whoever argued longest, but by one accountable person who read everything and made the call.

This matters more remotely than it does in an office, because the office has a pressure-release valve that a distributed team lacks. In a room, a stalled decision gets uncomfortable and someone eventually just says "okay, we're doing B, moving on." Async, a stalled decision can drift for a fortnight with nobody feeling the discomfort, each person assuming someone else will close it out. Naming the decider up front is how you make sure the discomfort lands on exactly one desk. It's the same reason coverage on a distributed team has to be assigned to a specific human rather than left to "the team." Work that belongs to everyone belongs to nobody.

Disagree and commit, then actually commit

The last piece is what happens after the call is made, and it's the piece a bad async culture breaks.

Someone will have preferred option A. They said so, thoughtfully, in the doc. The decider read it, weighed it, and went with B anyway. That's allowed. What's not allowed is the loser of that argument quietly reopening it three days later in a different channel, or slow-walking the work because they still think A was right. Across timezones this is a real hazard, because the dissenter is often working alone during hours when nobody who made the decision is awake to say "we settled this." A grumble that would die in a hallway can fester into a week of half-hearted work.

Disagree and commit is the norm that closes this. You get to fight hard for your view while the decision is open. Once it's closed, you commit to it as if it were your own, even the ones you argued against. The alternative, where every decision stays permanently reopenable by anyone who wakes up unhappy about it, is how a distributed team ends up making the same decision four times and shipping none of them.

When it does need a call

Not everything should be a doc. Some decisions are genuinely two-way arguments where the thinking happens in the back-and-forth, and a forty-comment thread crawling across three days is worse than twenty live minutes. When a written decision has clearly stuck, when the same two people have circled the same point through several rounds, stop typing and get on a call. That's not a failure of async. It's async-first knowing its own exceptions.

But keep those calls rare and cheap. Record the decision the moment it's made, write the outcome and the reasoning back into the doc, and treat the meeting as the tool you reached for on purpose rather than the runway every decision has to queue for. The goal isn't zero meetings. It's that a decision never has to wait three weeks for one.

Give Your Decisions One Less Reason to Wait

Half the reason a decision gets pushed to a meeting is that coordinating the async version feels like a hassle, starting with figuring out whose Thursday is whose. Timely converts every time mention in Slack to each reader's own timezone automatically, so "objections by end of day Thursday" reads correctly for everyone and your deadline means the same thing in San Francisco as it does in Bangalore.

Add Timely to Slack — Free · See how it works