Stakeholders Want High-Level Summaries but Then Drill Into Details? A Data Scientist's Communication Playbook

The Universal Data Scientist Dilemma: Simplify Your Report, Get More Questions

Almost every data analyst or data scientist has encountered this maddening scenario: stakeholders explicitly tell you that your presentations are "too dense, too technical, too in the weeds," and ask you to focus on "high-level business impact and conclusions." So you comply—strip out the methodology, simplify the metrics, lead with business value. The result? Their very first question is: "What was your sample size?" "Why did you choose this model?" "How did you handle edge cases in the data?"

This is exactly the frustration a Reddit user shared with the community. They described the experience as "both confusing and frustrating," feeling a massive disconnect between what stakeholders "say they want" and what "actually satisfies them." The post struck a nerve, drawing widespread agreement—proof that this isn't an isolated incident but a systemic challenge in how data professionals communicate with business teams.

The Real Psychology Behind the Apparent Contradiction: What Do Stakeholders Actually Want?

On the surface, this looks like a case of "saying one thing, doing another." But if we dig deeper into stakeholder psychology, their two demands don't actually conflict—they just occur at different cognitive stages.

"Give Me the Conclusion" Is the Entry Point, Not the Destination

When stakeholders say "keep it high-level," what they really mean is: "Don't drown me in technical details from the start—give me a main thread I can understand and remember." The high-level conclusion is their entry point into the topic, the first step in building trust and assessing value.

But the moment that conclusion touches a decision they genuinely care about—whether to adjust pricing based on this model, whether to commit budget—their brain instantly switches into "risk assessment" mode. At that point, sample size, model selection, and edge cases are no longer "technical details" but evidence of decision credibility. When they ask these questions, they're fundamentally asking: "How much should I trust this conclusion?"

This cognitive shift has solid theoretical grounding in psychology. Nobel laureate Daniel Kahneman's Dual Process Theory divides human thinking into System 1 (fast, intuitive judgment) and System 2 (slow, analytical reasoning). When stakeholders initially request "high-level conclusions," they're in System 1 mode—they need to quickly scan information, form preliminary judgments, and decide whether this topic deserves their attention. But when conclusions involve major resource allocation or strategic decisions, System 2 activates, actively seeking evidence, evaluating uncertainty, and assessing downside risk. Understanding this is crucial: the shift from "wanting conclusions" to "drilling into details" isn't fickleness—it's the natural cognitive flow of human decision-making.

Detail Questions Are Fundamentally Trust Checks

In other words, stakeholders don't want a methodology lecture—they want to "spot-check" your rigor through a few key questions. If you handle these follow-ups with confidence, their trust in your conclusions soars; if you stumble, even the most polished conclusions lose credibility. This is a classic trust verification mechanism, not a genuine desire to understand how k-fold cross-validation (a standard method of repeatedly splitting data into groups to verify model stability) works.

Trust verification is a widely studied phenomenon in organizational behavior. When decision-makers face recommendations from technical teams, they can't evaluate work quality at the methodological level like peer experts would. Instead, they employ a "Heuristic Probes" strategy—asking a few specific questions they can understand to indirectly assess overall reliability. This is similar to how venture capitalists conduct due diligence: they don't review code line by line, but use a few key questions to gauge a team's professional depth and thoroughness of thinking. If these "probe questions" receive satisfactory answers, decision-makers infer the overall work is reliable and feel comfortable acting on the conclusions.

The Root Cause of Communication Failure: Treating "Simplify" as "Delete"

Many data professionals, after being told to "keep it simple," respond by "deleting all the details." This is precisely the root of the problem.

Simplifying is not the same as deleting. The truly effective approach is layered communication: keep the main narrative extremely concise, but have "callable details" ready behind every key assertion. When stakeholders probe, you can immediately pull up supporting material rather than being caught off guard.

The concept of layered communication originates from Information Architecture and Progressive Disclosure design principles. This concept was first proposed by IBM researcher John M. Carroll in the field of human-computer interaction. The core idea: information complexity should unfold progressively as the user's needs deepen, rather than being dumped all at once. In consulting, McKinsey's "Pyramid Principle" and SCR (Situation-Complication-Resolution) framework are classic applications of this philosophy—lead with the answer, then expand the argument layers as needed. In data reporting, this means building a clear information hierarchy: the top layer is 1-2 core business conclusions, the middle layer is supporting logic and key data points, and the bottom layer is complete methodology, assumptions, and raw data.

Think of it like an iceberg—above the waterline is a clear, concise conclusion; below is the complete, rigorous analysis. Stakeholders see the tip, but they need to be confident there's massive support beneath the surface.

Practical Strategies: Making Reports Both Concise and Probe-Proof

Drawing from community discussions and practical experience, here are several actionable methods.

Strategy 1: Minimal Main Narrative, Appendix on Standby

Keep your formal presentation slides to only the most essential business conclusions and impact, but prepare a "technical appendix." When someone asks about sample size or model selection, flip directly to the relevant page. This satisfies the "high-level" requirement while allowing you to go deep at any moment.

Strategy 2: Proactively Plant "Hooks" for Key Details

When presenting conclusions, proactively drop in a line like: "This conclusion is based on X hundred thousand samples, and we validated against several mainstream models—happy to expand on this if needed." This single sentence communicates rigor while handing the choice of whether to go deeper back to the audience, often preempting abrupt follow-ups. The elegance of this technique lies in how it pre-satisfies the trust verification need—when stakeholders hear you proactively mention sample size and model validation, they've already received the signal that "this person is rigorous," and often won't feel the need to probe further.

Strategy 3: Distinguish "Decision-Relevant" from "Process Curiosity"

When facing follow-up questions, quickly assess: is this question about decision risk, or purely technical curiosity? For the former, give a thorough answer; for the latter, address it briefly and follow up after the meeting to avoid derailing the entire session. For example, "What's the maximum loss if this model prediction is wrong" is a decision-relevant question that needs a clear answer on the spot; while "Did you use XGBoost or Random Forest" is more process curiosity that can be briefly addressed with a detailed comparison saved for later.

Strategy 4: Treat Follow-Up Questions as a Positive Signal

Shift your mindset—stakeholders willing to drill into details often means they're taking your conclusions seriously and preparing to act. The truly bad scenario is when they nod politely and then do nothing. Probing is a sign of engagement.

The Deeper Insight: Data Communication Is Bidirectional Translation

This seemingly trivial complaint actually reveals a chronically undervalued capability in data science work—cross-role translation ability. Technical teams and business teams operate with two different "languages" and "mental models," and a data scientist's value lies not just in building models but in serving as a translator between these two worlds.

Industry data reinforces this point. According to multiple industry surveys (including annual reports from Burtch Works and Kaggle), communication skills are consistently ranked as one of the most important yet scarcest soft skills for data scientists. Harvard Business Review research indicates that data scientists who can effectively communicate analytical insights to non-technical audiences see their projects adopted and generating business impact at rates several times higher. This explains why the definition of a "full-stack data scientist" is expanding beyond pure technical competencies (Python/R programming, statistical modeling, machine learning) to include Business Storytelling and Stakeholder Management. In many tech companies' promotion evaluations, the "impact" dimension doesn't assess how complex a model you built, but how many business decisions your analysis ultimately drove.

Behind stakeholders' apparent inconsistency lies their natural wariness of uncertainty and the due diligence required for their decisions. Understanding this, you'll no longer view probing as "nitpicking" but as something to proactively address as part of your communication design.

Truly mature data communicators design their presentations as interactive information systems: displaying high-level conclusions by default, with the ability to drill down to any level of detail on demand. When you can do this, the confusion of "they say keep it simple but then ask for details" simply dissolves.

Key Takeaways