“No surprises” is easy to promise when the news is good. The real test comes when the facts are incomplete, the outcome is uncertain, and no one wants to be the first person to say that something may be going wrong.
Most organizations understand that customers should be told when there is a problem. The harder question is when.
Do we wait until we know exactly what happened? Until we understand the full impact? Until we have a recovery plan? Until the technical team has exhausted every possible solution?
Each choice has merit. No one wants to create unnecessary concern about something that may resolve itself or repeatedly alarm a customer over routine technical difficulties. But that hesitation creates its own risk: a manageable problem can become a customer surprise simply because we waited too long to talk about it.
The Temptation to Wait
Good teams want to solve problems. When something begins to go wrong, the natural reaction is often, “Give us a little time. We think we can fix this.”
That instinct usually comes from a good place. We do not want to burden the customer with every internal difficulty, and we certainly do not want to escalate problems unnecessarily.
The danger comes when solving the problem quietly becomes more important than communicating the risk honestly.
If the potential impact is significant enough that the customer may need to make a decision, adjust a schedule, accept additional risk, change an expectation, or provide direction, waiting for every fact may already be too late.
The first warning does not have to be a declaration of failure. Sometimes it simply needs to be: We see something developing. We do not yet know exactly where it will lead, but we want you to know what we are watching. That is not weakness. It is good communication.
A Risk Is Not the Same as a Failure
One reason people hesitate to communicate early is that uncertainty is uncomfortable. We may know that something could happen without knowing that it will happen. That distinction matters.
A possible risk is not the same as a developing issue. A developing issue is not the same as a confirmed problem. And a confirmed problem is not the same as a missed commitment. Those conditions should not be communicated as though they are equivalent, but neither should uncertainty become an excuse for silence. The level of certainty should determine how we communicate, not whether we communicate.
There is a tremendous difference between saying, “We are going to miss the delivery date,” and saying, “We have identified a risk that could affect the delivery date. We are evaluating the impact and should know more by Thursday.” Both communicate something important. Only one claims to know the outcome.
I saw this play out on a project involving programmable logic.
We had selected a device that, on paper, appeared to have sufficient capacity for what we needed. In practice, we could make it perform most of the required functions in one implementation and the remaining functions in another. We had demonstrated that the requirements themselves were achievable.
The problem was that we simply could not make all the necessary code fit into the device at the same time.
We kept working the problem. We tried different approaches, optimized what we could, and continued looking for a way to make the existing design work. At the same time, we kept the customer informed.
They knew what we were trying. They knew what was working. They knew what was not working. Most importantly, they knew there was an increasing possibility that we would eventually have to change direction.
Eventually, we had to accept that the existing device was not going to get us there. We backed up, redesigned the board around a substantially larger device, and moved forward. That change required additional time, money, and effort, but it was not a surprise to the customer.
They had been part of the conversation while we were still trying to solve the problem. They had seen the effort and the failures along the way. So when we finally said that the original approach had reached its limit and we needed to redesign the board, they accepted the news graciously.
There was some schedule impact, but relatively little because we had raised the issue early enough for everyone to understand what was happening and prepare for the possibility. The technical solution changed, but the customer relationship did not suffer because the customer never had to ask, “How long have you known about this?”
Early Warning Needs Context
There is another danger in early communication: sounding an alarm without providing enough information to understand it. Simply telling a customer that there may be a problem can create more confusion than clarity.
A useful early warning should explain what is known, what remains uncertain, what may be affected, what is being done, when the next update will come, and which decisions may eventually be required. That context turns uncertainty into something manageable.
It also establishes a communication rhythm. If I tell a customer on Tuesday that we are evaluating an issue and will provide another update Thursday, the customer does not have to wonder whether the issue disappeared or whether everyone simply stopped talking about it.
The next update may even be, “The risk has been resolved and no further action is required.” That is still useful communication.
In the programmable-logic example, we did not go to the customer every time a line of code failed. That would have created noise rather than useful information. But the customer knew the larger issue existed, understood what we were doing about it, and knew that a redesign was becoming one of the possible outcomes.
That distinction matters. “No surprises” does not mean reporting every problem. It means making sure the customer is not blindsided by the problems that may affect them.
Bring Options, Not Just Alarms
Escalation becomes much more valuable when it includes choices.
Sometimes a team discovers a problem with few immediate options. Whenever possible, however, customer communication should move beyond reporting the condition and help support a decision. Perhaps we can continue with the current approach and accept additional risk, change the technical solution, move the schedule, add resources, modify the requirement, or wait another two days for information that will significantly improve the decision.
None of those choices is automatically correct. The key point is that customers should have the opportunity to participate in decisions that affect them. This is one of the places where customer engagement becomes much more than customer agreement.
Our job is not simply to tell the customer what they want to hear or immediately agree with the first requested solution. Sometimes the greatest value we provide is a clear explanation of the situation, the tradeoffs, and the available paths forward.
Internal Surprises Become Customer Surprises
I learned the importance of this partly by seeing what happened when communication went the other way. There were countless projects where I did not hear about a problem until it was already too late to do much about it.
We would reach what was supposed to be a customer demonstration only to discover that we could not demonstrate what we had expected to show. Instead of walking into the room ready to demonstrate progress, we were walking in to explain why something was not ready.
Those incidents had consequences. Sometimes they cost us additional work. Sometimes they contributed to someone losing a job. They always cost us some credibility with the customer.
After enough of those experiences, I became much more deliberate about having serious conversations with engineers and designers early and often. I did not just ask whether things were going well. I asked what was not working, what they were worried about, what had not been demonstrated yet, what assumptions still had to prove true, and what we were calling “almost finished” that had never actually worked from beginning to end.
My technical background helped me understand much of what they were saying and ask another question when an answer did not quite fit.
I did not need to be the engineer designing the solution. I needed enough understanding to distinguish between “we are making progress” and “we have actually demonstrated that this works.”
Those are not the same thing. A project can make progress for weeks and still be sitting on top of a serious unresolved problem.
“We think we know how to solve it” is not the same as “we solved it.” “It works in pieces” is not the same as “the complete system works.” And “we should have it by Friday” is not the same as “we have demonstrated that we can have it by Friday.”
Those conversations were not about catching people doing something wrong. They were about finding the problem while there was still time to do something about it.
Because once an internal surprise reaches the customer, the conversation changes. You are no longer discussing how to manage a developing risk. You are explaining why no one told them sooner.
Silence Lets Small Problems Propagate
Most large customer surprises do not begin as large problems. They begin as signals: something takes longer than expected, a test repeatedly fails, a supplier misses an intermediate milestone, a design assumption becomes less certain, or an engineer says they are “still working through a few things.”
None of those statements necessarily means a project is in trouble, but they may deserve another question. The fault line often begins where we stop asking because we assume we already know.
If a technical concern stays within the technical team long enough, it can become a schedule concern. The schedule concern can become a cost concern, and the cost concern can become a contractual concern. Eventually, someone must explain why a problem that developed internally over several weeks appears to the customer to have happened overnight.
It did not happen overnight. The customer simply did not see it until the end.
“No surprises” therefore has to operate inside the organization before it can operate with the customer.
Contracts, program leadership, engineering, finance, supply chain, quality, and the other functions involved in delivery may each see a different part of the same problem. Those signals have to cross organizational boundaries early enough for someone to recognize what they mean together.
Otherwise, the organization experiences the surprise first and passes it along to the customer.
Bad News Does Not Automatically Destroy Trust
No customer enjoys receiving bad news, but the news itself is often not what damages the relationship most. The more damaging questions usually come later: How long have you known? Why am I just hearing about this? Could we have done something differently if we had known sooner?
Those questions are difficult because they are no longer only about the original problem. They are about trust.
The programmable-logic problem cost us time, money, and effort. The outcome was not what we originally planned.
But the customer had watched the problem develop with us. They knew we were trying to preserve the original design. They knew why we eventually stopped trying. When we changed direction, they understood how we got there.
Compare that with walking into a scheduled demonstration and announcing for the first time that the system cannot do what everyone expected it to do.
Technically, both situations may involve a problem. Relationally, they are completely different.
Early communication does not guarantee that a customer will be happy with the situation. It does something more important: it demonstrates that we are willing to communicate when the conversation is uncomfortable.
That is where credibility is built—not when everything is working, when the schedule is green, or when the answer is easy. Trust is built when the information is incomplete, the options are imperfect, and the answer may not be the answer anyone wanted.
That is when “no surprises” actually means something. Not every problem can be prevented, but many surprises can. The difference is often not whether a risk existed, but whether someone recognized the signal, communicated it clearly, kept asking the necessary questions, and gave the team and the customer enough time to respond.