Data in the boardroom

Situation

There is a transition in a data career that nobody prepares you for, and it is not technical. For years the job is to answer the question as asked, as accurately as possible, and accuracy is what you are rewarded for. Then one day you are in a room where a decision is being made, and that skill is suddenly not enough, in a way that is hard to diagnose at first.

My first meetings went badly in a particular way. I was asked for a number. I produced it, correctly, with careful caveats about method and confidence. The room received it politely. The decision was then made on grounds that had very little to do with what I presented, and I left unsure what had happened.

What happened was a category error, and it took me embarrassingly long to see it: I answered the question, and they needed the decision. Those are different products. A number is an input. A decision needs 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 rigor.

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.

Most of it is not the boardroom

The word oversells the setting. A small fraction of this work is formal: a board pack, a quarterly review, fifteen minutes on an agenda. Most of it 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.

They are 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, one person at a time, 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.

The decision all those conversations built toward fit in a sentence. Leadership agreed to trust me to build a central data team, in place of siloed analysts hired by each department and engineers working through whatever tickets each department sent them, and to build the data strategy around the business strategy. It was won person by person, against real skepticism, long before it was said in a formal meeting.

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.

Underneath all of it is a claim: data can be a partner that answers with evidence rather than instinct. Not to replace judgment, which is what executives are for, but to tell them when their instinct is expensive. That argument is 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. There is no version of that conversation where you walk through the methodology.
• Most of the room is not analytically trained and does not need to be. They are exceptionally good at pattern-matching, at spotting evasion, and at knowing which questions have expensive answers. Explaining a confidence interval is not the task. Conveying what it means for the decision is.
• You are the least senior person in the room and the only one whose input is optional. The finance and commercial voices are structurally required. Data is present because someone invited it, and the invitation is renewable.
• Being right is not sufficient. An analysis that is correct and does not land changes nothing, and “but I told them” is not a defense anyone senior accepts.

That last one is the constraint technical people resist hardest, and it is not unfair. Nobody is obliged to act on an insight they did not understand. Communication is not a soft skill bolted onto the analysis. It is part of whether the analysis worked.

Decision

Treat the boardroom as a 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 front-loads 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 a threshold to watch and a condition to test, rather than a reason to discount you.

In my experience, executives are extremely comfortable with uncertainty. They make decisions under it constantly, and they know that certainty is usually being manufactured. What they will not forgive is discovering that uncertainty was hidden from them. The fastest way to lose the seat for good is a confident number that turns out to have been shakier than presented. The second fastest is so many caveats that nobody can extract a position.

Answer the question behind the question.

The requested analysis is often not the useful one, and the gap shows as soon as you ask what decision it feeds. A request for acquisition cost by channel is usually a decision about where to move next quarter’s budget, and the useful answer is what the next unit of spend returns, not the historical average. A request to model the revenue impact of a price change often cannot be answered with useful precision, and a small, cheap test answers it better than a confident model built on assumptions nobody stated.

Deliver the requested number first and the reframe second. Skipping straight to “you asked the wrong question” is correct and is received as arrogance. Answering first shows you can, and buys the standing to say the more useful thing.

Disagree early, specifically, and once.

There will be moments when the room is converging on something the data does not support. How you handle them decides whether the seat is real.

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, and then support what is decided. New evidence is a reason to reopen it. Having been outvoted is not. Relitigating a decision that has been made is the fastest way to be left out of the next conversation, and it does not change the outcome.

Harder, and just as important: be 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.

The meeting is where decisions are ratified, not where they are formed. The work that matters is unglamorous and continuous: understanding what each executive is actually accountable for, learning which decisions are 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.

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 up close enough to know it is a worse failure than slightly shallower analysis that changes decisions. It is still a real trade, with costs I would not minimize:

• Distance from the detail. Making calls on work you can no longer personally verify means trusting the team, which is correct. It also puts you further from the thing that used to tell you something was wrong. That instinct was built on proximity, and it fades without it.
• Credibility with your own team. Engineers can tell when a leader has stopped understanding the work. Keeping enough depth to be useful in a technical conversation is ongoing effort, and it competes directly with the executive work.
• The pull toward being a translator. There is a version of this role that becomes purely a messenger between the business and the team, adding latency rather than judgment. The difference 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. Nobody can point to the decision that was not made, or the bad investment quietly abandoned after a conversation. The most valuable work in this category is invisible, which is uncomfortable at review time and worth knowing in advance.

Outcome

What I can point to is shorter reporting cycles and less delay between what happened and what leadership and operations could see, with reporting that held up when it had to be defended beyond the team that produced it. Whether any particular decision came out better, I cannot prove, because for years I did not keep the record I describe below.

The shift worth aiming for is that data stops being consulted about decisions and starts being present while they are made. These are the signs I watch for:

• You hear about decisions while they are forming, rather than when the analysis is commissioned, which is the only point at which analysis can change the outcome.
• The question arriving is “what do you think” rather than “can you pull.” That change in phrasing is the clearest single sign of where the function stands.
• Executives start raising data questions in their own conversations, without you there, because the framing has stuck. It is the best outcome available, and you will rarely see it happen.
• Disagreement becomes ordinary. In a working relationship, a data leader says “I do not think that is right” regularly and nothing breaks. If that never happens, either you are not saying what you think or you are not really in the room.

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 would have made me useful much faster than improving any analytical skill: the unit economics, the levers, and what each executive is measured on.

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 it pays for itself quickly. When I did, the first was a product analyst, and the product managers got as much out of it as the analyst did.

Keep a record of the calls I made, and revisit them. I did not systematically track my own recommendations and how they turned out, so for years my sense of my own judgment was less evidence-based than it should have been. A simple log of what I recommended, what was decided and what happened would have been humbling and useful, and it 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 comes paired with what they would do to find out. The phrase that works is not “I do not know.” It is “I do not know, and here is how we would find out and what it would cost.”