The first part of this pair ended on a single observation. The recurring failure across data work is a question that was never framed properly. The fix is a habit, and it can be run from either side of the table.

State the decision

For business users: “pull the FTS numbers” is a request for output. “I am deciding whether to renew FTS for another season, and I think completion rate on the new season is how we will judge it” is a request for help with a decision. The second version silently answers most of the hidden questions. Metric, period, comparison, and purpose all fall out of the decision once it is named.

The fix is a one-sentence habit: name the decision before asking for the number.

The same rule applies the moment a chat window opens with an LLM. A vague prompt to a model is the same mistake as a vague request to an analyst, with one difference. The model will not push back.

Ask one question first

For analysts and data teams: when the next vague ask arrives, do not pull a number. Ask one question first. “What decision is this feeding?”

Watch how much rework that one question prevents. Watch how much false confidence it prevents downstream.

And when a metric has no shared definition, do not quietly pick one. Write the definition down. Get it agreed. Put it where the next person will find it. One blessed definition per metric is what stops three teams computing “views” three different ways.

What leadership owes the people doing both

Individual goodwill does not scale. Two people can negotiate the FTS question over coffee. A large enterprise needs structure. This is where leadership’s pillar sits, and it is the one most often skipped.

A named bridging role. Someone who turns a business problem into a solvable data problem, then turns the answer back into a decision. The role can be filled from either side: a data analyst with deep business acumen, or a business-side practitioner whose data literacy is strong enough to frame the question.

Ownership of metrics. One team accountable for a given metric’s definition and quality, so that when “views” is wrong there is a name attached to fixing it. What fails is the shape in which nobody owns the metric on either side.

Hiring for data literacy beyond the data team. Marketing, product, operations, finance, HR. Hiring criteria signal what an organisation values. If the criteria for those roles never mention data, the organisation has decided data literacy is somebody else’s problem.

Democratisation, done two ways

“Data democratisation” gets sold as an unalloyed good. It is not.

Done badly, it means handing people raw access and calling it empowerment. Done well, it means access plus the things that make access safe: shared definitions, a small set of trusted standard reports, and the literacy to read them.

The difference between the two is governance, not ambition.

AI: amplifier, not solution

AI changes none of this. It amplifies whatever the foundation supports. With shared definitions and a literate workforce, AI helps. Without them, AI scales the noise.

The foundation is what an organisation actually controls. The model just amplifies what the foundation supports.

Where to start

Do one thing.

For those making the requests: never send “pull the FTS numbers” again. Send the decision instead.

For those fielding them: ask one question before pulling anything. “What decision is this feeding?”

For those leading the people doing both: fund a named bridging role instead of hoping for volunteers. Decide what the organisation is shipping: governed self-serve or raw access. AI will amplify whichever was chosen.

The next FTS request will arrive tomorrow. Whether it remains a thirty-second favour or opens a substantive conversation depends on which habits got built.

The full argument with sources lives in the long-form article.