Sync or Async: a Two-Question Test

Most guidance on choosing between a meeting and a message runs to a page of criteria, which guarantees nobody applies it at the moment of deciding. Two questions is short enough to actually use.

"Is this a call or a message?"

Question one: does it need back and forth?

Does the outcome depend on real-time exchange? Not "would it be nicer live", not "is it complicated", but does the result genuinely differ if the exchange takes a day rather than a minute.

Yes for a contested trade-off where each position changes in response to the other. Yes for a disagreement with feeling in it. Yes for the first conversation with someone whose judgement you cannot yet read. Yes for a live incident.

No for most things: a status question, a clarification, a review, a proposal, an update, an approval. Those have one exchange or a small number of independent ones, and they survive being spread over a day perfectly well.

One useful refinement. If you are booking a meeting because the last three messages went unanswered, the honest answer to question one is no. You are not booking a conversation, you are booking a guaranteed response, and that is a response-time problem rather than a format problem.

Question two: does the answer already exist in someone's work?

This is the question almost nobody asks, and it eliminates more traffic than the first one.

A large share of what gets sent as a question is not a question at all. It is a request to retrieve something that already exists: what was decided, where a piece of work stands, whether an approach was already tried, who owns a thing, what the number was. The asker frames it as a question to a person because a person is the only interface they have.

If the answer exists in someone's work, the correct action is neither a meeting nor a message. It is retrieval. This is what StandIn is for: each person confirms a ninety-second brief at the end of their day, and while they are off, their StandIn answers questions from it in their words, with a source under every answer. Ask it and you get the answer during your own working hours, with no interruption to anyone and no waiting for a shared slot. When the answer is not in the record, it says so and names who to ask, which is the point at which question one becomes relevant again.

Adding this as the second question changes the default. Before: ask a person, or book a meeting if they are slow. After: retrieve it, and involve a person only when the record cannot settle it. See how StandIn works.

The test applied to real requests

The request	Needs back and forth?	Already exists?	Do this
"Where is the migration up to?"	No	Yes	Retrieve it
"Should we cut the export from v1?"	Yes	No	Short live slot with the decider
"Can you review this proposal?"	No	No	Written, with a deadline
"I think the plan is wrong."	Yes	No	Live, today, not in a channel
"Why did we drop the cache?"	No	Yes	Retrieve it

Notice the pattern in the rows that say retrieve. Both are questions a colleague would answer in fifteen seconds, which is exactly why they get sent to a person and exactly why they are worth removing. Fifteen seconds of answering costs the person twenty minutes of lost context, a cost covered in context switching.

Where the test needs judgement

Three honest edge cases.

New relationships. With someone you have never worked with, meet once even when the test says no. You are calibrating, not exchanging information, and calibration is cheap now and expensive later.

Bad news. Written bad news reads harsher than intended and offers no chance to respond to a reaction. Deliver it live even when the content is one sentence.

Repeated failure to get an answer. If the test says async and async is not producing a response, escalate the channel rather than the format. Booking a meeting to force a reply works, and it teaches everyone that meetings are how you get answered, which fills the calendar back up.

Common Questions

Should this be a meeting or an email?

Meet only if the outcome depends on real-time exchange, which usually means a contested decision or a disagreement. If not, ask whether the answer already exists somewhere, in which case retrieve it rather than sending anything at all.

What if I am not sure whether it needs back and forth?

Start async and escalate. One written attempt costs a few minutes; if the thread turns into three rounds of clarification, that is your evidence and you book fifteen minutes. Going the other way, from a meeting back to writing, almost never happens.

Does this work for one-to-ones?

One-to-ones are relationship time, which is the category that justifies live contact regardless of information content. Do not apply the test to them, and do keep them short and regular rather than long and occasional.

How do we get a team to actually use the test?

Put the two questions in the channel topic and use them out loud when declining. "Second question: I think Maya already wrote this down, checking there first" teaches the test in one line and takes less effort than explaining a policy.