ENGINEERING LEADERSHIP / TECHNICAL LEADERSHIP
Writing Better Technical Proposals
How to make complex decisions easier to review and act on.
Key Insight: A technical proposal that requires a live meeting to be understood has usually failed as a document, regardless of how good the underlying idea is. The goal of a written proposal is for a reviewer, reading it cold, to understand the problem, the options, and the recommendation without you in the room to explain it.
I've reviewed and written enough technical proposals to notice a consistent pattern: the ones that get approved quickly and the ones that stall in endless discussion threads differ less in the quality of the underlying idea than in how the proposal is structured. A strong idea, badly presented, generates confusion and delay. A well-structured proposal, even for a debatable idea, generates focused, productive disagreement that actually reaches a decision.
Start with the problem, not the solution
The most common structural mistake is leading with the proposed solution before establishing, concretely, what problem it solves and why it matters now. A reviewer who doesn't yet understand the problem can't meaningfully evaluate whether the proposed solution is a good fit for it — they're evaluating the solution in a vacuum, which produces shallow, surface-level feedback ("have you considered X") instead of the deep engagement the proposal actually needs.
Open with the concrete problem: what's happening today, why it's a real cost (to users, to the team, to the business), and what happens if nothing changes. This framing does more to get a proposal taken seriously than any amount of polish on the solution section.
Present real alternatives, not straw men
A proposal with only one option, framed as the obvious answer, reads as already decided — and reviewers can tell, which either produces rubber-stamp approval that hasn't actually stress-tested the idea, or defensive pushback because the format itself feels like it's skipping the deliberation. Present at least two or three genuinely considered alternatives, including the honest trade-offs of each, even the ones you're not recommending. This does real work: it shows the space was actually explored, it gives reviewers a way to disagree productively about a specific trade-off rather than the whole proposal, and it often surfaces a hybrid approach or a consideration you hadn't fully weighed.
State the recommendation and the reasoning, separately from the options
After laying out the alternatives fairly, be direct about the recommendation and, more importantly, exactly why — which specific trade-offs matter most for this situation, and which ones you're consciously accepting as acceptable costs. Vague proposals that present options without a clear recommendation push the actual decision-making work onto the reviewers, which is slower and produces a worse decision than the person who did the research making a clear, reasoned call.
Make the cost and risk explicit, not implied
Reviewers, especially more senior ones, are often evaluating cost and risk more than technical elegance: what does this take to build, what could go wrong, what's the rollback plan if it doesn't work, what's the ongoing maintenance burden. A proposal that addresses these directly, rather than leaving them to be inferred or asked about later, moves through review faster because it's answering the questions reviewers are actually going to have before they have to ask.
Keep it scannable
Even a thorough proposal should be structured so a reviewer can get the gist in two minutes and the full reasoning in ten: a short summary at the top stating the problem and the recommendation in a few sentences, clear section headers, and the heavier technical detail organized so it can be skipped by a reviewer who trusts the summary and read in full by one who wants to verify it. A proposal that requires reading start to finish to find the actual recommendation loses reviewers before they reach it.
Key takeaways
Lead with the concrete problem and its real cost, before presenting any solution. Include genuine alternatives with honest trade-offs, not a single option dressed up as obviously correct. State a clear recommendation and the specific reasoning behind it — don't leave the decision for reviewers to make from raw options. Address cost, risk, and rollback explicitly rather than waiting to be asked. Structure the document to be scannable, with the core recommendation understandable in the first few sentences.