Data in the boardroom

Situation

A difficult transition in a data career is learning to contribute to a decision rather than only producing the analysis behind it. For years the job is to answer the question as asked, as accurately as possible, and accuracy is the thing you are rewarded for. Then one day you are in a room where a decision is being made, and that skill is suddenly insufficient in a way that is initially hard to diagnose.

The first meetings go badly in a particular way. You are asked for a number. You produce it, correctly, with appropriate caveats about methodology and confidence. The room receives it politely. The decision is then made on grounds that have very little to do with what you presented, and you leave unsure what happened.

What happened is a category error, and it is worth stating precisely because it took me embarrassingly long to see it: you answered the question and they needed the decision. Those are different products. A number is an input. A decision requires the number, the alternatives, the risk of being wrong, and a recommendation. Supplying only the first and expecting the room to assemble the rest is a failure of the job, not a display of rigour.

The second thing that goes wrong is subtler. Technical people, correctly trained, present uncertainty as a disclaimer: a list of caveats appended to protect the analysis. Executives hear caveats as hedging, and hedging reads as this person does not know. The instinct is then to present with more confidence than the data supports, which is the beginning of a much worse problem.

My work has included executive dashboards, operational reporting, and reports that had to withstand external scrutiny. Working with business leaders meant translating a request into a definition, a delivery expectation, and an answer someone could defend. A faster report was valuable when it arrived in time for the decision and retained that accountability.

Most of it is not the boardroom

The word oversells the setting, and the correction matters because it is where the work actually happens.

A small fraction of this is formal: a board pack, a quarterly review, fifteen minutes on an agenda. The overwhelming majority is department heads and functional executives, one at a time, in conversations nobody schedules as strategy. Marketing wants to know whether a channel is working. Finance needs a figure defended before it reaches the board. Operations has a hypothesis and no way to test it.

Those conversations are where positions form. By the time something reaches a formal meeting it has usually been decided in three of them, and a data leader who only appears in the formal setting is arriving after the thinking has happened.

This is also where the hardest organizational work gets done. When I was building a data function from zero, the argument that persuaded department heads to bring their analysts into a central team was not made in a boardroom. It was made repeatedly, individually, to people who were being asked to give up something that was working for them. And the argument that landed was never about metric definitions in the abstract. It was about where the company was going, what would have to be true to know whether it was getting there, and why four private versions of a number made that unanswerable.

That is the real shape of the work: alignment on strategy first, with metric definitions as the mechanism rather than the point. Leading with definitions sounds like bureaucracy. Leading with “here is the decision we cannot currently make, and here is why” is a conversation people want to have.

The deeper claim underneath all of it is that data can be a partner that answers with evidence rather than instinct, not to replace judgment, which is what executives are actually for, but to tell them when their instinct is expensive. That argument has to be won person by person, and it is won by being useful before being right.

Constraint

• Time is measured in minutes, sometimes in a single slide. A decision with material consequences may get fifteen minutes. A full methodology walkthrough rarely belongs in the opening; keep the supporting analysis available for the questions that follow.
• Analytical fluency varies. Some executives will interrogate the method; others need the consequences first. Prepare both and make the detail accessible.
• Your mandate may be incomplete. Being invited to present is different from being expected to contribute to a decision. Establish which role is needed.
• Being right is not sufficient. A correct analysis can be ignored, poorly communicated, or outweighed by another constraint. Find out which before assuming the audience failed to understand it.

That last constraint is the one technical people resist hardest, and it is not unfair. Understanding the analysis does not oblige someone to accept the recommendation. It does make the disagreement clearer. Communication is not a soft skill bolted onto the analysis. It is part of whether the analysis worked.

Decision

Treat the boardroom as a distinct discipline with its own method, rather than as a presentation layer over the analysis.

Lead with the decision, not the analysis.

The structure that works, in order: here is what I think you should do, here is what it rests on, here is what would have to be true for me to be wrong, here is what I would want to know before committing further. Recommendation first, reasoning second, caveats as conditions rather than disclaimers.

This inverts how analysis is naturally written and it is not dumbing down. It is front-loading the part the audience needs in order to know how closely to listen to the rest. If the recommendation is obviously right, the room can accept it in a minute. If it is surprising, they will interrogate the reasoning, which is exactly when you want to be explaining it.

Present uncertainty as a range with consequences attached.

Not “the data suggests, though with limitations.” Instead: “somewhere between these two figures, and the difference matters because below this point the case does not hold.” That gives the room something actionable, a threshold to watch, a condition to test, rather than a reason to discount you.

Executives make decisions under uncertainty regularly. Make the uncertainty relevant to the choice: what remains unknown, which threshold matters, and how the decision changes across the plausible range. Hiding a material limitation damages the relationship; listing every caveat without a recommendation makes the analysis difficult to use.

Answer the question behind the question.

The requested analysis is frequently not the useful one, and the gap is usually visible if you ask what decision it feeds. A few generic examples of the pattern, which recur across very different organizations:

• “What is our customer acquisition cost by channel?” The decision underneath is usually where to move budget next quarter. The requested number is a historical average; the useful analysis is marginal: what the next unit of spend returns in each channel, which frequently points somewhere else entirely.
• “How many customers did we lose last quarter?” The decision is usually whether to invest in retention, and if so where. A churn count answers nothing about that. Which cohorts, at what point in their lifecycle, and whether the pattern is new does.
• “Can we model the revenue impact of this pricing change?” Often the honest answer is not with useful precision, and the productive response is to reframe: here is what we would learn from a limited test, here is what it costs, here is how long before we know. Converting an unanswerable question into a cheap experiment is more valuable than a confident model built on assumptions nobody stated.
• “Which market should we enter?” Frequently the data cannot rank the options credibly, but it can eliminate one, and it can identify which single unknown would most change the ranking. Narrowing the question is a legitimate and often superior deliverable.

Delivering the requested number and then the reframe, in that order, matters. Skipping straight to “you asked the wrong question” is correct and is received as arrogance. Answering first demonstrates you can, and buys the standing to say the more useful thing.

Make disagreement specific, and agree when to revisit it.

There will be moments where the room is converging on something the data does not support. How that is handled determines whether the seat is real.

What works: disagree before the decision consolidates, not after. Be specific about what you think is wrong and what would change your mind. State it once, clearly, record the concern, and support the decision when it is within the agreed remit. New evidence or a material risk warrants reopening it; staying welcome in the room is not a reason to suppress either. Repeatedly relitigating a decision that has been made is the fastest way to be excluded from the next conversation, and it does not change the outcome.

What also matters, and is harder: being visibly willing to be wrong. Volunteering “my previous read on this was wrong, and here is what I missed” costs far less than it feels like it will and buys more credibility than any correct call. A person who never revises is either lucky or not looking.

Build the relationship outside the room.

Preparation outside the meeting helps you understand objections early. Keep it transparent: relevant evidence and material disagreements still belong in the formal decision, including views that did not prevail in the earlier conversations.

The work that matters is unglamorous and continuous: understanding what each executive is actually accountable for, learning the decisions coming down the road, and being the person they think to call before the analysis is commissioned. That is the difference between being consulted and being ticketed, and it is built in the fifteen-minute conversations nobody schedules.

A recommendation someone can challenge

Consider an illustrative pricing decision, not a client result. The commercial team wants a forecast for a price increase. Historical data describes who bought at the old price; it cannot, on its own, establish who will buy at the new one.

Part of the decision	What I would bring
Recommendation	A limited test before a wider rollout
Alternative	Roll out now, accepting greater uncertainty
Evidence	Customer mix, historical purchase behavior, and the limits of comparison
Guardrail	A pre-agreed retention or conversion threshold that pauses expansion
Decision owner	The commercial leader, with finance and product involved
Follow-through	A review date and the evidence needed to expand, adjust, or stop

The useful output is a decision whose assumptions can be tested. A narrower question can be more valuable than a precise-looking forecast.

The tradeoff I accepted

I chose influence at the point of decision over depth in the analysis, and the analysis genuinely suffered.

Time spent building executive relationships, sitting in planning conversations, and learning the commercial context is time not spent in the data. My personal technical edge dulled. I stopped being the person on the team who could most quickly find the bug in a model, and I did not get that back.

I accepted it because the alternative was a function that produced excellent analysis nobody acted on, and I had seen that outcome up close enough to know it is a worse failure than slightly shallower analysis that changes decisions. But it is a real trade, and it has costs I would not minimize:

• Distance from the detail. Making calls on work you can no longer personally verify requires trusting the team, which is correct, and it also means being further from the thing that told you something was wrong. That instinct was built on proximity and it degrades without it.
• Credibility with your own team. Engineers can tell when a leader has stopped understanding the work. Maintaining enough depth to be useful in a technical conversation is ongoing effort that competes directly with the executive work.
• The pull toward being a translator. There is a version of this role that becomes purely communicative, carrying messages between the business and the team, adding latency rather than judgment. The distinction is whether you are forming a view or relaying one, and it is easier to drift than to notice drifting.
• You cannot fully evidence this work. Avoided losses are difficult to estimate, but decisions to stop or change an investment can be recorded with their reasoning. The most valuable work in this category is structurally invisible, which is uncomfortable at review time and worth knowing in advance.

Outcome

Across reporting and analytics work, I shortened reporting cycles and reduced the delay between activity and the information available to leadership and operations. Governed reporting also supported decisions where the answer needed to be auditable beyond the team producing it.

Those are outcomes of delivery and business partnership. They do not, by themselves, prove that a particular executive decision improved. For that, I would record the recommendation, what was decided, and what happened afterwards.

The further shift worth aiming for is that data participates while decisions are forming. These are the signs I would use to assess it:

• You hear about decisions while they are forming rather than when the analysis is commissioned, which is the only point at which analysis can affect the outcome.
• The question arriving is “what do you think” rather than “can you pull.” That change in phrasing is the clearest single indicator of where the function stands.
• Executives start pre-emptively raising data questions in their own conversations, in your absence, because the framing has been internalized. That is useful evidence that the approach is spreading, although it can be hard to observe directly.
• Disagreement becomes ordinary. In a functioning relationship a data leader says “I do not think that is right” regularly and it does not damage anything. If disagreement never appears, ask whether the context is unusually aligned or whether people lack a safe way to raise a different view.

What I’d do differently

Learn the commercial vocabulary earlier and deliberately. I spent my first year in those rooms translating business questions into analytical ones in my head and translating back, which is slow and shows. Understanding how the business actually makes money (the unit economics, the levers, what each executive is measured on) would have made me useful considerably faster than improving any analytical skill.

Bring the team in sooner. I acted as the single interface for too long, partly because it was efficient and partly because it was gratifying. That concentrated context in one person, capped the team’s development, and meant their work reached executives filtered through me. Bringing an analyst into a strategy conversation is uncomfortable for everyone the first time and pays for itself quickly.

Keep a record of the calls I made and revisit them. I did not systematically track my own recommendations and how they turned out, which means my sense of my own judgment is less evidence-based than it should be. A simple log of what I recommended, what was decided, and what happened would be humbling, useful, and is the obvious application of the discipline I ask of everyone else.

Say “I do not know” earlier and more comfortably. Early on I treated not knowing as a failure to be minimized. Senior people say it constantly and it costs them nothing, because it is paired with what they would do to find out. The phrase that works is not “I do not know” but “I do not know, and here is how we would find out and what it would cost.”

Develop the next person who can hold the conversation

My mistake of becoming the single interface gives me a practical starting point for developing someone else. I would begin with one bounded decision, prepare with the analyst, and agree which part they will own in the meeting. Afterwards, review what the audience understood, which question changed the recommendation, and where I stepped in too soon.

The next meeting should require less of me. That is the progression I would look for: the analyst increasingly frames the options and handles the questions, with support still available. Attending the meeting is exposure; owning a part of the decision is a development opportunity.