A message lands in the analyst’s chat: “Can you pull the new FTS numbers?”
It feels like a thirty-second favour. It isn’t. Hidden inside that one sentence are half a dozen unasked questions: which metric, which season, which period, compared to what, and, least asked of all, for what decision.
That tiny exchange is the smallest possible version of the entire relationship between a business team and a data team. Answered well, it produces something someone can act on; answered badly, a number that is technically correct and quietly wrong for the decision. False confidence, with a deadline attached.
Multiply that by every such message, in every company, every week. That is where becoming data-driven gets built or broken.
And the cost is rarely just money. The wrong number becomes a slide, then a decision (renew or cancel, hire or hold), and by the time anyone might notice the figure was off, it is baked into something expensive and hard to walk back. Nobody goes back to check, because nothing looked broken.
Worse, it spreads. Each confidently wrong answer that slips through chips away at trust in the numbers, and at the nerve to act on them. Past a certain point people stop relying on the figures at all and quietly route around them, which is the exact opposite of what the whole effort was for.
The paradox
Ask senior data leaders what is blocking them, and they point at people, culture, and process, not technology. They name the human side as the wall they keep hitting. Then, in the same breath, fewer than one in fifty rank data literacy as an investment priority.
Four in five name the problem. Fewer than one in fifty fund the fix.
And the split runs both ways. Business leaders describe their organisations as “very data-driven”. Technical leaders in those same companies report struggling to drive business priorities with data. Same firms, opposite verdicts. The disagreement itself is the problem.
Why this happens
The easy reading is corporate hypocrisy. The honest one is less flattering: knowing what to do and actually doing it are different problems, and the doing is far harder than the knowing.
Literacy programmes are slow; a workshop on Tuesday does not produce sharper decisions on Wednesday. They are expensive, with the cost visible while the benefit stays diffuse. And they are hard to measure, which in a budget meeting is close to fatal.
Underneath that, “data literacy” has no agreed definition. A discipline struggles to fund, scope, or measure what it has not defined.
There is a quieter possibility underneath. The people making the budget calls may not have enough data literacy themselves to see which intervention actually matters. Low literacy at the top compounds the problem twice: once in failing to invest, and again in misjudging what to invest in.
Where AI makes it worse
Add AI, and the dynamic changes less than people hope. AI raises the stakes without changing the structure.
A vague question to an analyst produces correct-but-useless work. A vague prompt to a language model produces fluent-but-wrong work. In the chat, someone competent and slightly annoyed asks which metric, which season, compared to what. With the model, nobody asks.
The same cognitive slip that produces “pull the FTS numbers” in a message now produces “summarise FTS performance” as a prompt. A vague question goes in; a beautifully written, plausibly framed, wrong answer comes back out.
So every existing data problem becomes an AI problem too. An organisation that already distrusts a meaningful slice of its own data does not see that distrust dissolved by a model. It sees the same flawed inputs returned, now dressed up as fact.
The thread
Pull on any of it and the same knot shows up. The failure is not bad maths. It is a question that was never framed properly before the work began. Framing a question well is itself a literacy, and it is the one nobody is funding.
Frame it, and the rest becomes tractable. Leave it, and AI simply scales the noise.
The companion post takes up what fixing it actually involves. The full argument, with sources, lives in the long-form article.