Proposing a design

"I want to propose a new design" is a fine sentence, and it is also the least important part of a proposal. Proposals live or die on framing: whether the reader can tell what problem you are solving, what you considered, what you recommend, and what you want from them. This chapter gives you the language for each stage, from the first trial balloon in chat to a design review with principals in the room.

Before proposing: socialize the idea

Dropping a finished 12-page design doc on a team that has never heard the idea is a known failure mode; people react to surprise with resistance, and public review becomes the first place objections appear. Senior engineers socialize first: they float the idea informally with the two or three people most affected, before writing anything long.

• "I've been thinking about the retry storm problem. Rough idea: move the queue to per-tenant shards. Can I get twenty minutes to sanity-check it with you before I write anything up?"
• "Early thought, not a proposal yet: what if the cache moved client-side? What would break first?"
• "You know this system best. If I proposed splitting the worker into two pools, what would your first objection be?"

That last phrasing is deliberately excellent: it asks for the objection as a favor, which gets you the strongest counterargument while the design is still cheap to change, and it recruits the objector as a co-author of the fix. Ideas that survive socialization arrive at review pre-supported.

The shape of a written proposal

Whether it is three paragraphs in a ticket or a formal RFC ("request for comments", the standard name for a design doc circulated for feedback), the skeleton is stable:

1. Context      What exists today, in two or three sentences.
2. Problem      What hurts, with numbers if you have them.
3. Goals        What a solution must achieve.
   Non-goals    What this proposal deliberately does not attempt.
4. Options      2-3 candidates, each with honest tradeoffs.
5. Recommendation   Which option and why, stated plainly.
6. Risks & open questions   What could go wrong; what you don't know yet.
7. The ask      What you need: approval, feedback on a section, a decision.

The two sections that mark a mature proposal:

Non-goals. Explicitly listing what you are not solving ("multi-region failover is out of scope; this only addresses single-region resilience") prevents the review from sprawling and shows you scoped deliberately. The phrase "out of scope" is neutral and standard; use it without apology.

Honest options. A proposal with one option is a demand; a proposal whose rejected options are strawmen is a manipulation, and reviewers smell both. Present the strongest version of each alternative, then say why you still prefer yours. "Option B is genuinely attractive if we expect 10x growth; I recommend A because we have no evidence of that growth and A is reversible."

Don't be confused: a strawman has two meanings in this world. In argumentation it is a fallacy: misrepresenting a position to knock it down. But in design discussions, "here's a strawman" means "here's a deliberately rough first draft, please attack it": offering your own idea as the thing to knock down. "Let me put up a strawman so we have something concrete to argue about" is an invitation, and a good one. The counterpart is the steelman: the strongest possible version of a position, usually someone else's ("let me steelman the monolith option before I argue against it").

Phrases for making the proposal

Calibrate the strength of your language to the strength of your conviction:

Say the recommendation in one plain sentence and put it early: "I recommend option A: per-tenant queues with a shared overflow pool." Burying the recommendation on page six, or hedging it into fog ("perhaps something like A could potentially be explored"), forces every reader to reverse-engineer your opinion. Calibrated confidence also means marking the uncertain parts out loud: "I'm confident about the queue split; I'm much less sure about the overflow sizing, and I'd especially like eyes on that."

Inviting criticism on purpose

A proposal that asks "any feedback?" gets either silence or randomness. Direct the fire:

• "Please poke holes in the failure-mode section; that's where I'm least sure."
• "What am I missing?" (short, disarming, effective)
• "Where does this break first?"
• "I'd especially like pushback on the decision to keep writes synchronous."
• Scope the open surface: "The API shape is settled with the client team, so that part is FYI; the storage choice is genuinely open."

Telling reviewers which decisions are open versus closed is a kindness in both directions: nobody wastes effort relitigating settled ground, and the open questions actually get attention.

Presenting a design live

The written doc and the meeting have different jobs: the doc carries detail; the meeting exists to surface disagreement and make a decision. Openings that work:

• "Everyone's seen the doc? Quick show of hands... OK, I'll skip the recap and go straight to the open questions."
• If they have not read it: "Let me give the two-minute version, then let's spend the time on the two open decisions." Then actually take two minutes.

The two-minute version is BLUF: bottom line up front. State problem, recommendation, and the decision you need; detail only on demand. Answering questions during a live review:

• Concede specifics gracefully: "Good catch; the doc is wrong there, I'll fix it."
• Defer rabbit holes: "That's real, and it deserves more than a drive-by answer. Can I take it offline and post the analysis in the thread?" ("Take it offline" means discuss outside this meeting; it is standard, not evasive, provided you actually follow up.)
• Absorb hostility without matching it: "Strong reaction, let me make sure I get the substance. Your concern is the migration cost, right?"

Driving to a decision

Proposals die of silence more often than rejection. The closing moves:

• Name the decision-maker if there is one: "Dana, this is ultimately your call; what do you need from us to make it?"
• Lazy consensus for reversible decisions: "If there are no objections by Friday, I'll take that as agreement and start on Monday." State it in the doc and the channel, give a real deadline, and honor objections that arrive late anyway if they are serious.
• Record the outcome where the next person will look: "Decision: option A, agreed in design review 2026-07-14. Rationale and rejected alternatives in the doc." Many teams formalize this as an ADR ("architecture decision record"). Six months later, the recorded why is worth more than the decision itself.

And when your proposal loses: lose gracefully and visibly. "I still lean A, but B carries the room and it's a reasonable call. I'm on board; let's document why we chose it." That sentence, said sincerely, buys you more long-term influence than winning the argument would have. It has a name, disagree and commit, and it appears again in the next chapter.

👉 Proposing your own design is the easy half; the hard half is what to say about a design you think is wrong. "I want to criticize this design, it's abhorrent" contains a real professional need (the criticism) wrapped in career damage (the adjective). The next chapter is about extracting the one from the other: the mechanics of disagreeing hard while keeping the person on your side. On to Chapter 5.