You know the meeting. Six engineers in a room (or a Zoom). Someone shares their screen and walks through a design doc they wrote three days ago. Two people ask good questions. One person hasn't read it. Two are multitasking. The last person has a relevant concern but doesn't raise it because the meeting is already running over.
That's not a review. It's a table read — one engineer performing a document out loud for an audience that was supposed to have read it. The performance exists because nobody read it. And as long as the walkthrough meeting exists, nobody ever will: why do the homework when the author is going to recite it to you?
The meeting isn't compensating for the reading problem. It's causing it.
Design reviews work better async. The thinking is sharper when it's written. The feedback is better when people have time to process. And you get answers from the people who would have sat quietly in the meeting.
Here's the process.
Step 1: Write the proposal (and keep it short)
A design review doc is not a spec. It's not the implementation plan. It's the pitch for an approach, written well enough that someone can evaluate it without you in the room explaining it.
Rules of thumb:
- One page for most things. If you need more, your proposal might be too big. Split it.
- Lead with the problem. Two paragraphs on what you're solving and why it matters now.
- Be concrete about the approach. "We'll use a queue" is not a design. "We'll use SQS with a dead-letter queue, processing messages in batches of 10 with a 30-second visibility timeout" is a design.
- Include what you rejected. This saves reviewers from suggesting things you've already considered.
Don't bury the important parts. If there's a risky bet in your design, put it near the top.
Step 2: Identify the decisions
This is where most async reviews fall apart. The author shares a doc and says "let me know what you think." That's not an ask. That's a hope.
Before you share the doc, write down the 3-5 specific decisions you need input on. The difference is stark:
The hope: "Sharing the notification service design — would love your thoughts by end of week!"
The ask: "I need three calls made by Thursday: (1) separate service or extend the API — I'm proposing separate, it costs us a deploy pipeline; (2) does the fan-out model survive the multi-tenant case — Dana, this one's yours; (3) is 200ms added latency on send acceptable to product?"
The first gets two thumbs-up emoji. The second gets three answers, because it's obvious what answering looks like. (There's a whole method for writing these questions.)
If you can't come up with any real decisions, you might not need a review. You might just need to tell people what you're doing.
Step 3: Pick your reviewers
Not "the team." Specific people, chosen for specific reasons:
- The domain expert — someone who knows this part of the system
- The skeptic — someone who'll poke holes
- The downstream consumer — someone who'll have to live with this decision
- The outsider — someone from another team who can catch assumptions
3-5 reviewers is the sweet spot. More than that and everyone assumes someone else will respond.
Tell each person why you're asking them specifically. "I'd like your input because you dealt with something similar in the billing migration" is more motivating than a cc.
Step 4: Collect structured input
Here's where most teams reach for a Google Doc and hope for the best. Comments trickle in over a week. Some are about the design, some are about formatting, some are inline suggestions that don't address your actual questions.
What you want instead:
- Answers to your specific questions, from each reviewer
- Clear signal on where people agree and where they disagree
- A way to see all responses in one view, not scattered across a thread
Documents and issue threads don't enforce any of this — you ask three questions at the bottom of a doc and get a comment on paragraph two. Inkling is built for this step: questions embedded inline in the doc, answered in the flow of reading, responses returned organized by question.
Step 5: Summarize and decide
After the review deadline (you did set one, right?), write a short summary:
- What you heard: The key themes from the feedback. Where reviewers agreed, where they disagreed.
- What you decided: The approach you're going with and why.
- What changed: If the feedback shifted your design, say so. People are more likely to give good feedback next time if they see it actually matters.
Post this summary where the original proposal lives. If it was a GitHub issue, comment on the issue.
Close the loop. This is what makes the process feel worthwhile instead of performative.
What survives of the meeting
Run the review async and one thing occasionally remains: a genuine disagreement between two informed reviewers that the written round couldn't resolve. That deserves 30 minutes — scoped to the one contested question, attended by the people who actually disagree, decided on the spot. (The same rule applies to decision meetings generally.)
Everything else the meeting used to do — the recap, the walkthrough, the status theater — the document now does better:
Better input. People give more thoughtful feedback when they can read at their own pace, think, and respond. Meetings reward whoever talks first.
More voices. The person who's quiet in meetings might be the one with the best insight. Async lets them participate on equal footing.
A record. Six months from now, when someone asks "why did we go with approach B?", you point to the review — the questions, the answers, and the decision. Not "I think we talked about it in a meeting."
Cancel the table read. Keep the argument.