Start with the constraint the current system cannot meet
“We should move to events” is a solution looking for agreement. Begin with the observed problem: a user request waits for three downstream systems, retry behavior is inconsistent, or ownership boundaries prevent teams from deploying independently. Specify which constraint is failing and what a satisfactory outcome would look like.
State assumptions before using them to justify the design. Expected traffic, allowed inconsistency, recovery targets, operational staffing and delivery dates all shape the recommendation. An architecture that makes sense for a large platform team may be a poor fit for a team of eight.
Explain alternatives fairly
Give at least one plausible alternative, including improving the current design if that is realistic. Compare options against the same constraints. Do not give your preferred design a detailed benefits section while describing the alternative only by its worst failure mode.
An explicit trade-off makes the recommendation stronger. Event-driven processing can reduce coupling in a request path while introducing delivery, ordering and observability concerns. The proposal should say why those new responsibilities are acceptable in this situation and who will own them.
Describe the path from here to there
A target-state diagram is not a migration plan. Explain the first small change, how old and new behavior coexist, what you will verify, and what would cause you to pause. If rollback is difficult, say so before the team commits.
Choose verification criteria tied to the original problem. If the objective is to isolate downstream failures, demonstrate that behavior during a controlled failure. A successful deploy alone does not prove the design solved the problem. Name the team responsible for observing the result and making the next rollout decision.
Ask for the right decision
End by separating what is being approved now from what remains open. You may be asking for a two-week experiment, a shared API boundary, or agreement on a migration direction—not approval of every implementation detail.
Invite disagreement at the level that matters. Ask which constraint you have missed, which assumption is weakest, or which alternative deserves a test. “Any questions?” often produces a less useful discussion than a specific request for review.
Keep the decision in the explanation.
- Problem: the observed failure or unmet need.
- Constraints: what the solution must respect.
- Proposal: the smallest useful description of the change.
- Alternatives and why: compare against the same requirements.
- Trade-offs: the costs and failure modes you accept.
- Rollout: sequence, verification, rollback and ownership.
- Decision: what you need from this review.
Same situation. Clearer explanation.
We should use a message broker and split the service into microservices. It will scale better and make the architecture cleaner.
Checkout currently waits for inventory and email before returning. I propose moving email delivery out of the request path first, while keeping the inventory decision synchronous. This adds queue monitoring and duplicate-delivery handling, but lets us test whether we can isolate email failures without changing order semantics. I am asking for agreement on that first slice and its rollback criteria.
Illustrative examples. Adapt the facts and commitments to your situation.
Common mistakes to catch
- Leading with technology before establishing a problem.
- Ignoring the operational work the design creates.
- Comparing alternatives using different assumptions.
- Presenting migration risk as an implementation detail for later.
Now try saying it out loud.
Use the framework for one attempt. Listen back, choose one improvement, and try again.
Practice this conversationA couple of useful questions
How much detail belongs in the opening?
Enough to understand the decision and the central trade-off. Keep detailed schemas, failure sequences and capacity calculations available for the review, rather than making everyone traverse them before they know the purpose.
What if there is no clearly best option?
Describe what each option optimizes for, make the uncertainty explicit, and propose the cheapest useful experiment. A conditional recommendation is more honest than artificial certainty.