Back to Blog

Why We Tell You Bad News Immediately

Mohammad Orabi·Founder & CEO·3 min read
process
Why We Tell You Bad News Immediately illustration

When a project goes wrong, the tempting move is to stay quiet until the team has repaired it. Nobody enjoys sending the message that an approach failed or a deadline is at risk.

But waiting for a perfect answer takes away the client’s chance to make a useful decision.

Bad News Changes Shape When It Is Hidden

Suppose an integration will take two days longer than expected. Reported early, the client may move a launch date, cut a secondary requirement, or provide context that removes the blocker.

Reported on launch day, the same technical delay is now also a planning failure. Marketing may already be scheduled, customers may have been promised access, and the safe options are smaller.

Projects can survive problems. Trust struggles to survive surprises that somebody chose not to share.

Report the Observation Before the Story

Early does not mean careless. Do not blame a provider, a developer, or a requirement before the evidence supports it. Start with what was actually observed and what that observation affects.

“The production import failed for this file shape, and we have paused further imports” is responsible. “The provider is broken again” is a conclusion pretending to be a fact.

Give the Client Something They Can Use

  • What happened. Name the affected flow, environment, and current state.
  • What it affects. Separate confirmed impact from possible risk.
  • What is being done now. Explain containment or investigation without calling it a completed fix.
  • What decision is needed. Ask only when the client’s choice genuinely changes the route.

Honesty Is Not a Substitute for Ownership

Sending an alarming message and handing the problem to the client is not good communication. The team should contain safe damage, investigate the cause, propose the next action, and return with evidence.

The same applies after a mistake. “We caused this” matters, but the useful explanation is what changed, why the protection failed, what has been restored, and what now prevents the same failure.

Tell the truth early enough for it to remain useful. Then keep working until the original outcome is restored or the exact blocker is clear.

More from the blog

Have a project in mind?

We keep a couple of slots open for the right fit. Tell us about your idea and we will figure out the rest.

Upwork