Before design reviews, write what you assume is already settled
Before entering any design conversation or architecture review, write one sentence answering 'What am I assuming is already settled here?' to surface expertise-hidden assumptions that should be re-examined.
Why This Is a Rule
Every design conversation operates on a foundation of "settled" assumptions — decisions treated as given rather than as choices. The database technology is settled. The team structure is settled. The deployment model is settled. These assumptions narrow the solution space before the conversation begins, often invisibly.
Expertise makes this worse. Senior engineers carry more "settled" assumptions because they've made more decisions that succeeded — each success reinforcing the assumption that the underlying choice was correct. But context changes. The database that was the right choice two years ago may not be the right choice now. The team structure that worked at 5 engineers may not work at 20.
Writing one sentence about what you assume is settled does two things: it makes the assumption explicit (so it can be examined rather than inherited), and it primes you to notice when the conversation bumps against that assumption. If the constraint turns out to be real, nothing changes. If it turns out to be a cached decision that no longer applies, you've unlocked a larger solution space.
When This Fires
- Before design reviews, architecture discussions, or technical planning meetings
- Before revisiting a system you designed or scoped originally
- When you notice a design conversation is "stuck" — often stuck means constrained by an unexamined assumption
- Any technical discussion where the scope feels surprisingly narrow
Common Failure Mode
Answering the question with truly immovable constraints ("we're assuming we'll use the existing production infrastructure") rather than with assumptions that feel settled but might not be ("we're assuming the API needs to be synchronous"). The valuable assumptions are the ones that feel so obvious you almost didn't write them down — those are the ones most likely to be cached decisions rather than current constraints.
The Protocol
Before entering a design conversation: write one sentence completing "I am assuming _ is already settled." Pick the assumption that feels most "obvious" — that's the one most likely to be hiding an unexplored option. During the conversation, notice when solutions are rejected because they violate this assumption. Ask: "Is that actually a constraint, or a decision we could revisit?"