How to Say “We Don’t Know” Without Losing Credibility

A payment service starts declining transactions on a Tuesday afternoon. Ten minutes in, an executive walks into the room with a single question: “Do we know what it was yet?” Not yet. And that answer, said flat and with nothing around it, can make an active investigation sound like a loss of control.

The temptation is to answer with something that sounds firm: “it was this morning’s deploy,” “it must be the database.” Organizations tend to read confident delivery as competence, and the person who hesitates can look like they are not up to it. An earlier essay examined why systems reward that appearance of certainty; this one starts just after that pressure and asks a different question. When there is no complete answer yet, how do you communicate and act on it without misleading anyone or losing direction?

Because the problem, almost always, is not the uncertainty. It is something subtler: opacity. No one in the room can tell where the evidence ends, where interpretation begins, and where a decision was already made in spite of what is still unknown. Credibility does not depend on sounding certain. It depends on whether others can follow the path from the available evidence, through the provisional judgment, to the decision being made. When that path is visible, “we don’t know yet” stops sounding like evasion and starts sounding like control.

“We don’t know” is not a status update

Said with nothing around it, “we don’t know” leaves the listener without boundaries, without context, without an owner, and without a next step. It does not say whether the team is lost or one test away from confirming it. That is why it can sound like abandonment even when it is honest: the answer is not the only thing missing; what is also missing is any account of what remains to be learned and how the team will find out.

There is more. “We don’t know” gathers several very different situations under one phrase. Not knowing is not the same as not having investigated yet. Not having enough evidence is not the same as having it and being unable to tell two equally plausible explanations apart. And none of those is the same as knowing that the answer cannot be obtained yet, because it depends on something that has not happened. Said the same way, all of them flatten into the same blank “we don’t know,” and the listener has no way to tell an investigation that is just beginning from one that has hit a dead end.

The difference has consequences. A security team that detects suspicious activity knows at least one thing – there was an anomalous login from an unusual location – and does not yet know several others: whose credentials were used, how far the access reached, and what was actually done. Saying only “we don’t know if we were breached” erases what was actually confirmed and hides what still needs investigating to clear up the rest.

The useful version names the state of each piece: this is confirmed, this is still open, this is under active investigation, and this we cannot know until we finish collecting the evidence. The uncertainty is identical in both versions. Only one of them shows where the investigation actually stands.

What the data shows, what we infer, and what we decide

Back to the payment service. Under pressure, three different things fuse into one confident statement, and that fusion is the root of almost all the confusion that follows. They are worth holding apart.

The first layer is what the evidence directly shows: since 14:10, the payment gateway has returned errors at the checkout step, and the error rate climbed from roughly one percent to forty. That is an observed fact; it is in the logs. The second layer is what the team believes that fact means: it was probably the 14:05 deploy. That is an interpretation – the most plausible reading of the available evidence, but still a hypothesis. The third layer is what the organization decides to do about it: roll the deploy back now. That is a decision, made before the cause is confirmed.

An honest update sounds like this: “We know where it is failing, we suspect why, and we have decided to roll back while we confirm it.” An opaque update sounds different: “It was the deploy; we’re fixing it.” The second version packs into one sentence where the failure surfaced, what may have triggered it, what the underlying cause was, and what mitigation was applied, as if they were all the same thing. They are not. The location of a failure is not its cause. Containing the symptom is not the same as removing the cause.

The cost of that collapse arrives later, and almost always by the same route. The hypothesis changes – the problem was not the deploy but a service the checkout depends on that had started to exceed its response time – but by then the executive has passed the first explanation up as fact, support has given a customer a root cause that did not hold, and someone has started treating the temporary restart as though it were the permanent fix.

None of that happened in bad faith. It happened because, in the critical moment, no one made clear what was observed, what was interpreted, and what was decided. Once those three are fused into a single statement, every later correction looks like a contradiction instead of a sharper diagnosis.

The language of a provisional assessment

If the layers have to stay separate, language is the tool that keeps them visible. This is not about softening the message or padding it with defensive qualifiers; it is about making each sentence reveal the state of the knowledge instead of hiding it. A small difference in phrasing can be the difference between a well-founded decision and an avoidable surprise.

“We have not confirmed the cause” is not the same as “we don’t know anything”: it says the investigation is still open. “The evidence currently supports X but does not rule out Y” keeps alive an alternative that a flat assertion would have buried. “We know where the failure occurred, but not what initiated it” separates the symptom from the origin and stops anyone from declaring resolved what was only contained.

“We cannot estimate the final cost until these dependencies are resolved” ties the figure to the conditions behind it, so no one quotes it later without them. And “we are acting now because waiting carries the greater risk” names the decision as a decision, not a conclusion. Each of those sentences does the same work: it marks how far what is known actually reaches.

To sustain that in practice, it helps to sort every claim by how well it is supported rather than by how alarming it sounds:

• Confirmed What the evidence directly supports and what would survive an independent review.
• Inferred The most plausible reading of that evidence today, offered as a hypothesis and not a fact.
• Assumed What we are treating as true without having checked it, often without noticing that we did.
• Open The competing explanations the evidence cannot yet tell apart.
• To verify The specific evidence that would confirm or rule out the hypothesis, and who will go get it.

This is not a form to recite in every meeting. It is a check before speaking. Every useful update should also name the next test and the next review date: what evidence will change the assessment, who will obtain it, and when the current view will be revisited. Without those commitments, “open” can become indefinite.

Detail changes with the audience; certainty does not. Engineering may need traces and versions, leadership the impact and decision, and customers what affects them. A hypothesis must remain a hypothesis through every translation. When “likely” becomes “confirmed” on its way upward, the failure is not uncertainty but loss of provenance.

Deciding before the answer arrives

None of this means judgment is a matter of waiting. You can be uncertain about the cause and decisive about the next step at the same time. Intellectual honesty does not postpone every decision; it exposes what the decision assumes.

A rigorous decision made without certainty leaves five things in view: what is being assumed, by when the choice has to be made, the cost of acting against the cost of waiting, what is reversible and what is not, and what signal would force a change of course. Rolling back the payment deploy is a reversible, low-cost move: if the hypothesis was wrong, little is lost and the real cause is still on the table. Rewriting the database schema in the middle of the incident is neither reversible nor cheap.

When in doubt, the reversible move is the safer one, taken with a safeguard where possible, while the irreversible options wait until the evidence is sufficient. It is worth saying out loud which signal would tell you the decision was wrong and should be reversed: the error rate climbing back above a threshold, or the same failure showing up on the previous version.

Consider a second case, less urgent but just as instructive: the estimate to migrate a platform to the cloud. The highest estimate is nearly triple the lowest, and that spread does not reflect a lack of rigor. The range depends on two still-open unknowns: the database licensing model, and how many applications can be migrated unchanged versus how many will have to be redesigned or rebuilt.

The mature answer is not to invent a single number to reassure the steering committee; it is to present the range together with the assumptions behind it, say which of them will be resolved before the budget is committed and by when, and set the point at which the estimate can become a commitment. A figure separated from its assumptions travels through an organization without context and loses its conditions along the way, until someone presents the lowest value to leadership as if it had been promised.

This is where the other half of “not yet” appears: uncertainty with no owner and no next steps quietly turns into avoidance. Saying it well creates obligations. Someone owns the investigation. There is a next review with a set date. The open questions are visible, not scattered across three people’s memories. And whoever depends on the answer knows when the assessment will be updated. That is the line between disciplined uncertainty and abdication: the first assigns responsibility and sets deadlines; the second uses “we don’t know” as a reason for no one to move.

Revising without rewriting history

Important judgments should have versions, the way code does. An initial assessment at 14:20. A working hypothesis at 14:50. A revised assessment at 16:00, when the dependency that caused the failure is finally identified. A confirmed conclusion the next day, after the root cause has been reproduced under controlled conditions. Each version leaves a record of what was believed, on what evidence, what changed, and why it was revised. This is not bureaucracy; it is what lets a decision made at 15:00 still be understood, later, as reasonable in light of what was known at that hour.

Correcting a provisional judgment is not inconsistency; it is exactly what you would expect from someone who was working from a hypothesis and then got stronger evidence. What destroys trust is the opposite: rewriting the past quietly, acting as if the first explanation had never been offered, or letting a temporary mitigation be remembered as though it had always been the permanent fix. The inconsistency is not in changing your mind when the evidence changes; it is in changing it without leaving any record that you did.

When people can trace how an assessment evolved, revision stops reading as weakness. It becomes the evidence that there was a method behind it and not a lucky guess. A visible history of judgments corrected by evidence earns more trust, over time, than a single confident assertion that happened to be right.

That, in the end, is the difference. Mature credibility is not the elimination of uncertainty through a firm tone. It is making incomplete knowledge transparent enough that other people can act without being misled by it: able to see where the evidence ends, where interpretation begins, and what decision was made despite what was still unknown. A confident front can convince quickly, but it does not last. Letting people follow your reasoning, even when the answer is not yet complete, is what makes them believe you the next time you say “this part we have confirmed.”

Source notes

These sources support the incident-response practices used here: explicit roles and communication, evidence and record keeping, and review. The five-state taxonomy is the article’s synthesis.

• Google, Site Reliability Engineering, “Managing Incidents.” Supports assigning clear incident-command and communication roles, maintaining a shared incident record, and reviewing the response after the incident. Source: sre.google.
• National Institute of Standards and Technology, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. Supports defined response roles and communication, preserving incident records and evidence, and using review findings to improve response. Source: csrc.nist.gov.