In partnership with
Last week, I had to do the one thing that data analysts dread:
Telling my stakeholders there was a long-standing issue in the data that would impact their current reports.
The table in question had been built more than a year earlier, long before I joined the company. Still, I was the one responsible for explaining what happened, what it affected, and what would happen next.
I knew what this conversation could mean: Lack of trust in the data going forward.
Luckily, the issue itself was fairly small.
That was the good news.
The harder part was communicating it without scaring them away from all their current dashboards.
Before I continue, just sharing a small ad. A simple click helps support my newsletter, so thank you! 😊
Keep up with tech in 5 minutes
TLDR is the free daily email with summaries of the most interesting stories in startups, tech, and programming. The stuff worth knowing, minus the doomscrolling.
Issues are curated by ex-Google and Anthropic engineers and land in your inbox before your morning coffee. A 5-minute read, and you walk into the day already knowing what your team is still catching up on.
Tech is just the start. We also cover AI, marketing, dev, and more. Pick the briefs that match your work.
Free, daily, and read by 7M+ subscribers. Subscribe and let the experts do the digging for the tech news that matters.
Now, back to what I was saying…
These things happen, and when they do, these difficult conversations become necessary. How you navigate them really becomes its own skill.
If you ever have to explain to someone that the data is wrong, here is my simple framework:
1. Investigate before you announce
When possible, do not raise the alarm the second you notice something off.
Take enough time to understand what you are looking at.
I wanted to prepare my answers to the questions I knew my stakeholders would ask:
What caused the issue?
Which reports or metrics were affected?
How long had it been happening?
How large was the difference?
Did it change any previous conclusions?
What would the corrected numbers look like?
When would the fix be ready?
You may not have every answer immediately, but you should have enough information to clearly explain what is known, what is still being investigated, and when the next update is coming.
“Something looks wrong, and we are looking into it” rarely inspires confidence on its own.
2. Do not lead with blame
Who cares who built the table? They don’t. And you shouldn’t either.
The point is that it is an issue and it needs to be fixed.
You can provide context without pointing fingers.
Here is what sounds better:
During a recent review, we identified an issue in an existing pipeline table that was causing sessions to be slightly undercounted.
That explains the situation without throwing another analyst, engineer, or former employee under the bus.
Your stakeholders do not need the office drama. They need the impact and the plan. Stay professional; otherwise, your stakeholders will lose trust in the whole data team, and that’s very hard to get back.
3. Explain the impact in simple terms
Technical details matter, but most stakeholders do not need a full explanation of the pipeline logic, join conditions, or transformation code.
They need to know what changed for them. The “why do I care?”
In my case, I explained that:
The issue affected session counts.
The current numbers were slightly lower than they should have been.
The correction would increase the totals.
The difference was not large enough to materially change past reporting or decisions.
No other key metrics were affected.
4. Use calm, direct language
There is a fine line between minimizing an issue and making it sound like the entire warehouse is on fire.
You do not want to say:
It’s probably fine. I have no clue.
Also, do not scare them with:
We have discovered a major data integrity failure.
Try something like:
We identified an issue affecting session counts in one of the source tables. We have started an investigation and confirmed that sessions were slightly undercounted. The correction will result in a small increase, but it will not materially change previous reporting or business decisions.
5. Give them a plan
People are much more comfortable hearing about a problem when they can also see that someone is in control of the next steps.
Your update should include:
What is being fixed
Who is working on it
When the fix is expected
Whether historical data will be corrected
Which reports will update
When stakeholders will hear from you again
For example:
The logic is being fixed, and we will refresh the affected data once the change is tested. I will confirm when the updated numbers are available and share a comparison of the before-and-after.
That final sentence is key. You are not asking them to simply trust that everything is fixed. You are showing them how you will verify it.
That is much more useful than giving someone a five-minute explanation of how the table was built.
6. Follow up after the fix
Do not disappear once the technical work is done.
Tell stakeholders the fix was completed, summarize the change, confirm the final impact, and explain any checks that were added to prevent the same issue from happening again.
A follow-up could sound like this:
The session count issue has now been corrected, and the affected data has been refreshed. As expected, the updated totals increased slightly, and there was no material impact on previous reporting. We have also added a validation check to help identify similar discrepancies earlier.
That last part helps rebuild confidence because it shows the process improved.
Trust is not lost because an issue exists
Data systems are complicated.
Pipelines change. Logic gets reused. Source systems behave unexpectedly. Old assumptions stop being true.
Even strong teams will occasionally find something that needs to be corrected.
Stakeholders usually understand that.
What damages trust is finding out late, receiving vague answers, hearing conflicting explanations, or feeling like someone is hiding behind technical language.
The analysts who become trusted senior partners are not the ones who never encounter problems.
They are the ones who can investigate carefully, communicate clearly, take ownership of the next steps, and make people feel confident that the issue is being handled properly.
These conversations will come up in your career.
They may be uncomfortable, but they are also a chance to show that you can handle more than dashboards and SQL.
Sometimes seniority looks like knowing the answer.
Sometimes it looks like delivering news nobody wanted to hear, and doing it well.
Have you ever had to tell stakeholders the numbers were wrong? How did you handle it?
Talk soon,
Sarah
P.S. You can browse the full blog here:
https://datawithsarah.com/
And if you missed the free checklist, grab it here:
