You write a design doc. You put real thought into it — the problem statement, the proposed approach, the alternatives you ruled out. You share it in Slack with "Hey team, would love your eyes on this."
Two people react with 👍. One person comments "looks good, minor nit on line 14." Nobody addresses the hard question on page three.
The doc sits there. You wait a few days. Nothing. Eventually you just go build the thing and hope you made the right call.
Here's the diagnosis, and it's not the one you've been telling yourself. Your team isn't too busy. Your doc isn't bad. You made the easy response and the useful response two different things — and everyone chose easy. They always will. The only fix is to make them the same thing.
How you split easy from useful
"Let me know what you think" is unpaid scoping work
When you ask someone to "review" a document, you're handing them a job you haven't defined:
- Figure out what kind of feedback you want
- Decide how deep to go
- Determine what's in scope for comment and what's already decided
- Find the right level of detail
Most people look at that implied workload, skim the doc, and write "looks good" because it's the path of least resistance. That's not laziness. That's a rational response to an unscoped request.
No deadline means no priority
"When you get a chance" means never. Your design doc is competing with everything else on their plate, and it's the only item with no due date. It will always lose to things that have one.
The hard questions are invisible
The question you actually need answered — "approach A or B?" — is on page four, after three pages of context. Most people never get there. They read the first section, feel like they've engaged, and move on. Your most important ask has the least visibility of anything in the document.
The feedback that does arrive is confetti
A Google Doc comment here, a Slack reply there, a verbal aside in standup. You're left manually reconstructing what people actually think, hoping you didn't miss anything. The synthesis work you were trying to distribute lands back on you.
The fix: collapse easy and useful into one action
Ask three specific questions
The single highest-leverage change. Instead of "please review," write:
I need your input on three things:
- Is the proposed data model going to work for the multi-tenant case?
- Should we build the migration tooling ourselves or use an off-the-shelf solution?
- Are you comfortable with the 2-week timeline for phase 1?
Now the easy response is the useful response: answer the three questions. There's no cheaper move available that still counts as replying. (Writing questions that resist a lazy "LGTM" is its own skill — worth twenty minutes to learn.)
Put the questions where they matter
Don't dump all your questions at the bottom of a 5-page doc. Put each question next to the section it relates to. After you describe the data model, ask about the data model. After the timeline, ask about the timeline.
Context and question should be inches apart, not pages apart.
Set a deadline
"I need responses by Thursday EOD so I can finalize the approach on Friday."
That's it. You're not being pushy. You're being clear. People respond when they know the window is closing — and a decision with a deadline is the difference between a review and a suggestion box.
Make responding frictionless
The harder it is to leave feedback, the less feedback you get. If someone has to request access to your Google Doc, figure out how commenting works, and then type a freeform response — you've lost half your reviewers before they start.
The ideal: click a link, read the section, answer the question. No login, no account, no friction.
This is why we built Inkling
I hit this wall over and over before starting Inkling. The pattern was humiliatingly consistent: the proposals I shared as documents got silence or "LGTM." The proposals that got real scrutiny were the ones where I gave up on the doc, walked over to specific people, and asked them specific questions to their face. The useful feedback was never in the document workflow — it was in the interrogation I ran around it. Which meant the document, the thing I'd spent hours writing, was functioning as a prop.
That's the gap Inkling closes: it puts the interrogation inside the document. You write your proposal (or paste a GitHub issue URL), add questions inline next to the relevant sections, and share a link. Reviewers read the doc and answer the questions in one flow — no account, no access requests. The questions aren't at the bottom hoping to be found; they're in the reading path, where skipping them is more awkward than answering them.
Your design doc doesn't need more polish. It needs better questions.