Integrity and Ethical Leadership Questions

Direct answer

I would name what the data actually shows, separate from what the narrative wants it to show, and bring both to the stakeholder, rather than either forcing the data to fit or shutting down the conversation entirely.

Structured elaboration

1. Get specific about the gap: is the narrative flatly wrong, or just incomplete, meaning the data supports a smaller or different version of the claim than what is being asked for.
2. Check your own analysis first. Ask whether you might be the one missing something before assuming the request is in bad faith.
3. Bring the real result with the caveat built in, not hidden: here is what the data shows, here is the version of the story it does support, and here is why it does not support the stronger claim.
4. If the pressure is implicit rather than an explicit ask, for example a slide template already written before your numbers came in, name it directly: "it sounds like this deck assumes X, my analysis actually shows Y."
5. If pushed again after that, hold the number, and offer to present the honest finding alongside the reason leadership might still choose to act despite it. A business call made knowingly against inconvenient data is a different thing than the data being misrepresented.

Worked example

A director wants a slide showing a new onboarding flow "significantly improved" week-one retention ahead of a board meeting; your analysis shows a small uptick that is not statistically meaningful given the sample size, meaning the observed change is within the range you would expect from random noise alone. You bring the actual number and say plainly: "the observed lift is small and within noise at this sample size, I cannot call this significant yet, here is what we would need to be confident." You offer a defensible alternative framing that is not the same as the one requested: "early signal is directionally positive, we are continuing to monitor," instead of the overstated claim, and instead of simply refusing to produce a slide at all.

Trade-offs and pitfalls

Assuming bad faith too early is a pitfall: some "make this look better" requests are really an information gap, not an intent to falsify, and your response should differ accordingly, escalating as an integrity issue only if the person pushes you to misrepresent it after you have corrected the record. Being so blunt that you do not offer any usable alternative framing is the opposite pitfall, since it reads as unhelpful rather than rigorous.

Direct answer

When I catch my own error after presenting results, I do not sit on it. The strongest move is to surface it within the same day, with the corrected number already in hand, not a vague "we might need to revisit this."

How I handle it

1. Verify first: rerun the analysis to confirm the error is real and measure exactly how far off the original number was, and which decisions or slides depended on it.
2. Tell your manager before you tell the stakeholder, so they are not blindsided and can help you decide who else needs to know.
3. Go to the stakeholder directly, not just an email footnote, with three things: what was wrong, what the corrected number is, and why it happened in one sentence (a join bug, a stale data pull, a wrong denominator), without turning it into an essay of excuses.
4. Separate "here is the mistake" from "here is what I am changing so it does not happen again." A generic "I will double check next time" does not rebuild trust; a specific, checkable control does.
5. Close the loop with your team once the fix is verified, and be explicit that no one is being blamed, the process is.

Worked example

Say you presented a churn-driver analysis to a VP claiming a support-ticket flag doubled the odds of churn. Two days later you notice a duplicate join had double-counted a subset of customers, and the real effect is roughly 1.3x, not 2x. You rerun the query, confirm the corrected multiplier, and email the VP within the day: "The support-ticket effect I presented Tuesday was overstated because of a duplicate join in the customer table. Corrected, it is about 1.3x, still meaningfully large, here is the fixed chart. I have added a row-count check to the pipeline so a join like this fails loudly instead of silently inflating a number." You tell your team the same afternoon what happened, and that the new check is now part of the pipeline.

Trade-offs and pitfalls

The two failure modes are opposite and equally damaging: delaying disclosure while you build a "perfect" root-cause writeup (stakeholders remember that you sat on it more than they remember the original number being wrong), and over-apologizing in a way that buries the corrected number under caveats and makes the audience doubt everything else you have shown them. Credibility comes back fastest when you pair the correction with a specific, checkable safeguard, not a promise to be more careful.

Direct answer

In the moment, I do not alter the metric or quietly comply. I ask a clarifying question that makes the request explicit, which usually causes the person to either back off or reveal exactly what they are asking for, so I can respond to the real thing instead of an ambiguous one.

What I do in the moment

1. Do not assume malice immediately. Some "make this look better" requests are really about framing or context, not falsification, for example showing a metric next to a fairer baseline. Clarify which one it is.
2. If it is a request to falsify or cherry-pick in a misleading way, changing the underlying number, hiding a denominator, cutting the date range specifically to erase a bad month, decline plainly and immediately: "I cannot change what the number actually is, but I can help present it more clearly if that is the concern."
3. Offer the honest alternative on the spot if you can: a different but true framing, added context, or a caveat.

What I do over the following weeks

4. Document what happened factually, what was asked, what you said, what you presented, in case it resurfaces, without turning it into an accusation.
5. Watch for whether the pressure repeats or escalates. A one-off ambiguous ask and a pattern of pressure are different problems.
6. If it becomes a pattern, escalate to your manager or, depending on severity, to whoever owns data integrity reporting internally, since a stakeholder consistently pressuring people to shade numbers for funding is a risk that outlasts any one slide.

Worked example

A director asks you to show their program's cost-savings metric using a rolling three-month average instead of the standard twelve-month figure used everywhere else in the org, right before a funding review, because the three-month number looks better. In the moment, ask directly: "is the concern that the twelve-month number does not reflect a recent improvement, or do you want the review board to see the higher number specifically?" If it is the latter, decline to swap the standard methodology for this one slide, but offer to show the twelve-month number as required with a footnote noting the recent trend, honest and still surfaces the improvement they care about. If the same director asks a second time on a different metric with a similar pattern, raise it with your manager rather than treating each incident in isolation.

Trade-offs and pitfalls

Assuming every framing request is manipulation makes you needlessly adversarial with people who have a legitimate point about context. Complying "just this once" because it is a small change and the stakeholder is senior is exactly how the pattern starts and becomes easier to repeat.