Count the meetings on your calendar this week. Now count how many of them exist because someone needs a decision and didn't know how else to get one.
Half your meetings are decisions wearing a discussion costume. A 30-minute sync with six people to decide Kafka or SQS — three hours of engineering time, spent to produce one sentence of outcome. An hour-long "alignment session" that's really about picking a launch date. A "quick chat" that blocks three afternoons so one person can get a yes.
Here's the uncomfortable part: booking that meeting is usually not a scheduling choice. It's an avoidance choice. Writing the decision down — "here are the options, here's my recommendation, tell me by Thursday if I'm wrong" — puts your reasoning on the record where it can be judged. A meeting lets the decision stay fuzzy, shared, and deniable. We call meetings "collaborative." Mostly they're just unaccountable.
The written version is faster, cheaper, and produces a record. Here's how to do it.
The framework
1. Write the context
One page. Not a spec, not a slide deck — a short document that gives someone everything they need to weigh in.
Structure it like this:
- The situation: What's happening? What prompted this decision?
- The constraint: Why does this need to be decided now?
- The options: What are the realistic choices? (Not ten options. Two or three.)
- Your recommendation: What do you think we should do and why?
The recommendation matters most. Don't pretend to be neutral if you have a view — that's the same accountability-dodge as the meeting, in written form. People can push back on a recommendation far more easily than they can fill a blank page. "I think we should go with option B because of X and Y — am I wrong?" is a better prompt than "what does everyone think?"
2. Frame the question
"What do you think?" is not a question. It's an invitation to ramble. Frame the decision as something answerable:
- "Should we go with A or B?"
- "Are you comfortable with this timeline?"
- "What's the biggest risk you see in this approach?"
- "Do you approve this spend?"
If you can't frame the question crisply, you're not ready to ask — and you weren't ready to book the meeting either; you just would have discovered that in front of six people. (Writing questions that can't be brushed off is a skill worth learning on its own.)
One decision per ask. If you have three decisions to make, ask three questions. Don't bundle them.
3. Pick the right people
You don't need consensus. You need input from people whose judgment matters for this specific decision:
- The person who'll own the implementation. They'll flag feasibility issues.
- The person who'll feel the consequences. They'll flag risks.
- The person with the authority to approve. They'll unblock you.
That's usually 3-5 people. If you need more than that, your decision is probably multiple decisions bundled together. Split them.
Tell each person what you need from them specifically. "I'd like your take on the ops complexity" is better than a cc.
4. Set a deadline and collect input
"I'll make the call on Friday. I need your input by Thursday EOD."
This isn't aggressive — it's respectful. You're telling people exactly how much time they have and when their input matters. Without a deadline, your decision request joins the infinite queue of things people will get to eventually.
Two days is usually enough for a focused question. A week for something bigger. If it needs more than a week of review, it's probably too complex for one decision — break it down.
The format for collecting input matters too. Email threads and Slack discussions become unreadable fast. Google Doc comments are marginally better. What you really want is each person's answer to each specific question, collected in one place.
5. Summarize and decide
After the deadline, write a short summary:
- Here's what I asked.
- Here's what I heard.
- Here's what I'm going with, and why.
Post it wherever the original question lives. If people disagree with the outcome, they can say so — but the decision is made, the reasoning is documented, and everyone can move forward.
This last step is where most async processes fall down. People collect input and then go quiet. The summary is what makes it a decision instead of a poll.
The one meeting that's earned
There is a case where a meeting wins: a genuine, unresolved conflict between two informed positions, where the disagreement survived the written round. High bandwidth helps there. Real-time back-and-forth resolves in ten minutes what would take a week of written volleys.
Notice the order, though. The meeting comes after the writing, scoped to the one question the writing couldn't settle, attended by the two or three people who actually disagree. That meeting is earned. The default calendar-blast is not. (The same logic applies to design reviews: async first, meet only on what's left.)
Why this is hard in practice
The framework is simple. The hard part is tooling.
Writing the context? You can do that anywhere — a doc, a GitHub issue, a Notion page. Framing the question? That's a writing skill. Picking people? You know who they are.
But collecting structured input from specific people and seeing all their answers in one place? That's where the tools fail you. Slack becomes a scroll. Google Docs become a comment mess. GitHub issues become a wall of text where the decision is invisible by comment #34.
Inkling is built for exactly this loop: write the context, embed the questions inline, send scoped links to your 3-5 people, and get every answer back organized by question — with the summary posted back where the doc lives. The framework works without it. The tool just removes the excuse.