Setting expectations and delivering bad news
Trust is built when what you say will happen, happens. Most broken customer relationships aren't caused by failures; they are caused by surprises. Setting expectations early and delivering bad news well are core FDE skills.
Set expectations about AI early
Many stakeholders expect AI to be either magic or useless. Reset both views in the first meetings:
- It is probabilistic. It will be right most of the time and wrong some of the time; the design must make errors safe.
- Quality depends on their data. Results on a demo dataset don't transfer automatically.
- We will measure it. Quality claims come from an evaluation set agreed together.
- It improves iteratively. The first version is a baseline, not the final answer.
Give a range, not a promise: "On similar documents, extraction accuracy is typically high, but we'll know your number after the first week on your data." Then report the real number.
Handle scope creep calmly
New requests are a sign of engagement — and a risk to delivery. Use the same pattern every time:
- Acknowledge — "That makes sense; I can see why it would help."
- Locate — "It isn't in the current scope."
- Quantify — "Adding it would take about a week and push the pilot start."
- Offer options — "We can swap it for X, add it after the pilot, or extend the timeline."
- Let them decide — and record the decision in the change log.
Say no without saying "no"
Customers rarely respect an engineer who agrees to everything. Useful phrases:
- "Yes, and here's what it would cost us in time."
- "We could do that — but it would put the go-live date at risk. Which matters more?"
- "I'd recommend against it, for this reason. If you still want it, here's how we'd mitigate the risk."
Deliver bad news early, with options
When something goes wrong — a missed date, a quality shortfall, a blocker you can't remove — tell the sponsor as soon as you know. Bring:
- What happened, in plain language, without blame.
- The impact on dates, scope or results.
- Two or three options, with your recommendation.
- What you're doing now to recover.
Bad news ages badly. The same problem raised on day two is a hiccup; raised on the deadline, it is a breach of trust.
Escalate well
Escalation is not tattling; it is using the organisation to remove a blocker. Escalate when you have tried the normal path, the blocker threatens an agreed milestone, and you can name a specific ask. Keep it factual: the blocker, what you've tried, the impact, and the decision you need.
When the customer is unhappy
Listen fully before responding, restate their concern to show you understood it, and separate the facts you can fix from the frustration you should acknowledge. Agree a concrete next step and a time you'll come back. Then come back on time.
"The pilot results are worse than you promised. How do you tell the sponsor?" Use the bad-news structure: plain facts, impact, options with a recommendation, and what you are already doing to recover.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.