Stop Hedging Your Designs: Honest Replacements for "I Think" and "Maybe"
Learn how to sound authoritative about your technical choices while maintaining intellectual honesty about the risks.
The fear of being wrong
If you are an engineer, you know that every technical decision involves tradeoffs. There is rarely a perfect architecture; there is only the architecture that fits the current constraints.
Because you know the edge cases, you probably caveat your recommendations. You use words like "I think," "maybe," and "it depends."
You do this to be accurate. But to your team and your stakeholders, you sound unsure. If you don't sound confident in the design, they won't trust the recommendation.
You can sound authoritative while remaining intellectually honest about the risks by using Explicit Uncertainty.
Explicit Uncertainty (3 Layers)
This framework allows you to make a strong recommendation while openly acknowledging the flaws in your design. It replaces vague hedging with precise, calculated risk.
1) The Definitive Choice
State exactly what you are choosing, without qualifiers.
2) The Known Tradeoff
State exactly what you are sacrificing by making this choice.
3) The Unknown Risk (If X, then Y)
State what you don't know, and what the fallback plan is if the risk materializes.
Scripts for engineers (say this, not that)
Here is how you replace nervous hedging with explicit, calculated engineering choices.
When recommending an architecture
- Not that: "I think maybe we should use Redis, but I guess Postgres could work too."
- Say: "My recommendation is Redis because of the read speed. We sacrifice relational queries, but that's an acceptable tradeoff for this service."
When discussing scale
- Not that: "I'm not 100% sure this will scale to 10k RPS."
- Say: "Based on our load tests, this handles 5k RPS comfortably. If we hit 10k RPS before Q4, our fallback is to add a caching layer."
When diagnosing an incident
- Not that: "It kind of looks like the API is failing."
- Say: "The logs show the API is failing 15% of the time on this endpoint."
When choosing between two bad options
- Not that: "We could just sort of rewrite the whole module, or maybe try to fix the bug."
- Say: "We have two options: patch the bug now or rewrite the module. I recommend patching now to unblock the release, and tackling the rewrite next sprint."
Examples in the wild
The Nervous Architect
An architect is presenting a new system design to the Staff Engineers. If they hedge ("This might be the best way to do it, but there are some issues..."), the Staff Engineers will tear the design apart. If they use Explicit Uncertainty ("I chose X. The tradeoff is Y. If Z happens, we will pivot to A"), the architect looks thoughtful, prepared, and authoritative. The debate shifts from whether the design is good, to whether the team accepts the stated tradeoffs.
The Code Review Debate
A junior engineer suggests a different pattern on your PR. Instead of hedging ("Maybe your way is better, I don't know"), state the tradeoff clearly: "Your way is more readable, but mine is more performant. Since this is in the hot path, I prefer performance." You validate their idea while confidently defending your own.
"I don't know" is a complete sentence
Being confident doesn't mean hiding the flaws in your design. It means owning the flaws as deliberate tradeoffs.
It is perfectly acceptable to not know the answer to a technical question. But "I don't know" should never be the end of the sentence.
Follow it up with the action you will take to find out: "I don't know the exact memory overhead of that library. I will profile it this afternoon and post the results in Slack."
Real-time feedback catches the hedges you miss
You can write a perfectly structured technical spec, but when you are defending it live on a Zoom call, it is easy to slip back into "I think" and "maybe."
Yakety catches you hedging your architecture decisions live. It runs in your browser and flags anxiety words in real-time, reminding you to trigger the Explicit Uncertainty framework and own your tradeoffs with confidence.
If you want the adjacent playbooks: