How to Communicate Uncertainty in Technical English: Hedging and Qualification
Learn hedging phrases, qualification language, and approximation vocabulary to communicate uncertainty clearly and professionally in technical English.
In technical communication, accuracy is essential — and accuracy includes being honest about what you don’t know. Communicating uncertainty clearly is a professional skill, not a weakness. In English, we use a set of vocabulary called hedging language to signal degrees of certainty, probability, and approximation. This guide will help you use it naturally in engineering contexts.
Why Hedging Matters in Technical English
Making overconfident statements can damage your credibility when reality doesn’t match your claim. Making underconfident statements can make you seem indecisive. The goal is calibrated language — language that accurately reflects how certain you actually are.
Compare:
- Overconfident: “This change will fix the performance issue.”
- Underconfident: “I have no idea, it might work maybe.”
- Calibrated: “This change should reduce latency significantly — we’ll confirm with load testing before the release.”
Hedging Phrases by Degree of Certainty
High Certainty (but not absolute)
Use these when you are confident but want to leave room for exceptions or additional data:
- “This is almost certainly caused by…”
- “The evidence strongly suggests that…”
- “In all likelihood, the root cause is…”
- “There is a high probability that…”
Moderate Certainty
Use these for your best current judgement when data is incomplete:
- “It appears that…”
- “This may indicate…”
- “It seems likely that…”
- “The data suggests, though does not conclusively show, that…”
- “Our current hypothesis is…”
Low Certainty or Possibility
Use these when you are speculating or flagging a risk:
- “There is a risk that…”
- “It is possible that…”
- “We cannot rule out the possibility that…”
- “One potential explanation is…”
Qualification Language
Qualification means adding conditions that limit the scope of your statement. It prevents your claim from being misunderstood as universal.
| Without qualification | With qualification |
|---|---|
| ”The system handles 10,000 requests per second." | "Under current load conditions, the system handles approximately 10,000 requests per second." |
| "The migration takes two hours." | "Based on our staging environment tests, the migration takes approximately two hours — though this may vary depending on database size." |
| "This approach doesn’t scale." | "This approach may not scale beyond our current traffic levels without modification.” |
Useful qualification phrases:
- “under typical conditions”
- “in most cases”
- “assuming X”
- “subject to further testing”
- “based on the data available”
- “at our current scale”
Approximation Vocabulary
When you can’t give precise numbers, use approximation vocabulary rather than vague language.
| Avoid | Use instead |
|---|---|
| ”A lot of users" | "Approximately 15,000 users” / “Roughly 12% of active users" |
| "It’s slow" | "Response time degrades to around 800 ms under peak load" |
| "It happens sometimes" | "It affects roughly 3–5% of requests" |
| "It’ll take a while" | "We estimate two to three weeks, pending the infrastructure changes” |
Approximation words and phrases:
- approximately, roughly, around, in the region of, on the order of
- between X and Y, in the range of X to Y
- as many as, up to, at least
- on average, typically, in most cases
Hedging in Written Engineering Communication
Hedging is especially important in written reports, proposals, and post-mortems where statements can be quoted out of context.
In an incident report:
- “The root cause appears to be a race condition in the session management code, though further investigation is required to confirm this.”
In a design proposal:
- “This approach is expected to reduce database query time by approximately 40%, based on benchmarks run against a representative data sample.”
In a performance review:
- “This engineer has shown strong progress in system design, and appears to be approaching readiness for the senior engineer role, subject to a few remaining growth areas.”
Example Sentences
- “It appears that the memory leak is related to the websocket connection pool — we’re investigating, but this is not yet confirmed.”
- “There is a risk that removing this cache layer will increase database load significantly during peak traffic; we should run a load test before proceeding.”
- “Our estimate for the migration is in the region of three to four weeks, assuming the data team can deliver the schema changes by the end of the month.”
- “The performance improvement is likely due to the new indexing strategy, though we cannot rule out the influence of the traffic drop over the weekend.”
- “Based on current data, this approach should scale to approximately five times our current load — beyond that, we would need to revisit the architecture.”
Navigating Nuance: Supporting Uncertainty in Team Discussions
The core concept – understanding that uncertainty is rarely absolute – is crucial for effective technical communication. It’s not about admitting defeat or lacking confidence; it’s about acknowledging the limits of our current knowledge and presenting information with appropriate caution, especially when making recommendations or interpreting data. For non-native English speakers, this can be particularly challenging as direct translation often doesn’t capture the subtle nuances of expressing doubt constructively. It’s also important to recognize that perceived uncertainty – even if based on incomplete data – can significantly impact how your ideas are received.
Let’s consider a scenario: You’ve been reviewing a colleague’s pull request for a new feature in a web application. The PR description states, “This will improve user engagement by 20%.” As you review the code, you notice several areas that haven’t been thoroughly tested and some ambiguous interactions with existing components. Instead of saying something blunt like, “This is wrong,” or “That’s not going to work,” a more nuanced approach would be to offer qualified support for the concept while highlighting potential issues. You might respond in Slack: “That’s a really interesting idea for boosting engagement – I can see the potential! However, given that we haven’t yet tested the integration with the user authentication service, and there are some areas of the UI that seem untested, it’s difficult to predict exactly how much engagement will improve. Perhaps we could prioritize testing those integrations before finalizing the rollout?” This combines a positive affirmation (“interesting idea”) with carefully worded qualification – using phrases like “difficult to predict exactly how much” and suggesting a priority action (“prioritize testing”).
Another common challenge arises when drafting PR descriptions for new components. Imagine you’re documenting an API endpoint: “This endpoint will handle all user data requests.” While technically accurate at the moment, it’s inherently uncertain. The system could evolve, other services might integrate with it in unexpected ways, or future requirements might necessitate changes. A more cautious phrasing would be: “This initial version of the endpoint is designed to handle a range of user data requests and will serve as a foundation for future expansion. We anticipate potential integration with [mention specific potential integrations] and will continue to monitor performance and adapt accordingly.” Notice the use of terms like “initial version,” “foundation,” and the acknowledgment of ongoing monitoring – all strategies to manage expectations and signal that this is an evolving piece of code.
Finally, remember that demonstrating a willingness to revisit decisions is often more valuable than asserting absolute certainty. Framing discussions around potential outcomes rather than definitive statements fosters collaboration and reduces defensiveness. Focusing on clarifying assumptions (“Let’s clarify the expected traffic volume”) or exploring alternative scenarios (“What happens if we see a surge in requests?”) demonstrates intellectual honesty and strengthens your position as a thoughtful contributor to the team. Building this habit of qualified communication will serve you well, particularly when navigating complex technical discussions and working with diverse teams.