L&D Is Drowning in Data It Can’t Really Use
Ask a learning leader whether they have enough data, and you’ll get a wry laugh. Data is not the problem. Every platform in the modern L&D stack — the LMS, the LXP, the survey tools, the HR system, the collaboration suites — produces a steady exhaust of numbers. The problem is that having data and being able to use it are two very different things, and most learning functions have vastly more of the first than the second.
The symptom is a peculiar kind of frustration: the sense that the answer to an important question is almost certainly sitting in the data somewhere, and no practical way to get to it. Which system holds it? Is that field trustworthy? Has anyone defined what it actually measures? By the time those questions are resolved, the moment for the decision has usually passed, and the choice gets made on instinct instead. Data-rich and insight-poor is not a contradiction. For most L&D teams, it’s the default state.
Two problems hiding inside “we have the data”
When a learning team can’t turn its data into answers, the obstacle is usually one of two things, and they’re worth separating because they have different fixes.
The first is discovery: not knowing what data you even have. In a sprawl of systems accumulated over years, no one holds a complete map of what’s collected where, what each field means, or which source is authoritative when two disagree. Analysis stalls before it begins, because the first step — finding the right data — is itself a research project.
The second is interrogation: even once you’ve found the data, not being able to ask it questions without a specialist. The information sits in a system that speaks a technical language, and getting an answer means filing a request and waiting in a queue behind every other team.
Most conversations about “data-driven L&D” jump straight to dashboards and analytics, which address neither of these. A dashboard assumes you already know what data exists and what to ask of it. If you don’t—and most teams don’t—the dashboard is built on sand.
The map you don’t have
The unglamorous first fix is knowing what you’ve got. This is the job of a data catalog — essentially an organized inventory of an organization’s data: what exists, where it lives, what each element means, how trustworthy it is, and who owns it.
It sounds mundane, and it is exactly the mundane thing that determines whether everything downstream works. Without it, every analysis begins with the same archaeological dig, and different people answer the same question differently because they pulled from different sources without realizing it. The rise of AI-powered data catalogs matters here because the old approach — asking humans to manually document every data source and keep it current — reliably failed. The documentation was always out of date, because maintaining it was nobody’s real job.
Systems that can inventory and describe data with far less manual effort change that equation. For a learning function, the payoff is concrete: instead of wondering whether the completion data in one system means the same thing as in another, you have an actual map — which is the precondition for trusting any answer you eventually produce. You cannot analyze your way to insight on top of data you can’t confidently identify.
The interpreter you’ve been waiting on
The second fix addresses the queue. Even with a clear map of the data, most L&D professionals still can’t interrogate it directly, because doing so has traditionally required technical skill they don’t have and shouldn’t need. So the questions route through a data specialist, and the specialist’s queue is the bottleneck that kills most L&D analytics ambitions.
This is the gap a new generation of tools aims to close — and choosing among them has become its own skill. A practical guide to how to choose an enterprise AI assistant for data and reporting is worth more to a learning leader than another dashboard, because the selection criteria are where these initiatives succeed or fail. The right tool lets a non-technical program owner ask a question in plain language and get a trustworthy answer, without the queue and without learning to write queries.
But the selection matters enormously, and this is where L&D leaders should slow down. The questions that separate a genuinely useful assistant from an impressive demo are unglamorous: Does it connect to the systems your data actually lives in? Can it explain where an answer came from, so you can trust it? Does it respect who’s allowed to see what? A tool that gives fast, confident, unverifiable answers on data you don’t fully trust is worse than no tool at all — it just lets you be wrong faster.
The trust question you can’t skip
There’s a caveat that has to travel with any move toward easier data access, and skipping it is how organizations get burned. The easier it becomes to get an answer, the more the trustworthiness of the underlying data matters — because a system that answers confidently in plain language carries an authority that a raw spreadsheet never did.
That authority is a liability if the data beneath is messy, undefined, or contradictory. A confident answer built on unreliable data is simply a confident mistake, delivered faster and believed more readily. This is precisely why the discovery step — the catalog, the definitions, the ownership — is not optional groundwork to rush past on the way to the exciting part. It’s the thing that makes the exciting part safe. Democratized access to well-mapped, trustworthy data is a genuine advantage. Democratized access to a data swamp is a way to make bad decisions at scale.
Why this gets worse every year
The data problem in L&D is not static, and that’s the part most teams underestimate. It compounds. Every year brings new tools, each generating its own data in its own format, stored in its own place, with its own definitions. The learning stack that had four systems five years ago has ten now, and each addition doesn’t just add data — it adds another island of data disconnected from the rest, another source that might contradict the others, another thing no one has catalogued.
This means the discovery problem widens automatically over time unless someone actively works against it. Left alone, an organization’s data landscape becomes less navigable each year, not more, even as the raw quantity of data grows. The paradox sharpens: more data, less findable; more systems, less coherent; more measurement, less insight. Teams that assume the problem will improve as tools get better have it backwards — the tools getting more numerous is precisely what makes it worse.
Consider the concrete situation that exposes this. A learning leader is asked, in a board meeting, a reasonable question: did the leadership development investment actually change anything? The answer, if it exists at all, is spread across a leadership program’s completion data in one system, performance ratings in another, retention figures in the HR system, and engagement scores in a survey tool — none of which share a common definition of who counts as a “participant” or over what period. Assembling a defensible answer becomes a multi-week reconciliation project, and the meeting was yesterday. So the leader answers with an anecdote and a hope, and the investment’s real impact stays permanently unknown.
That scenario repeats, in varied forms, across every learning function that has grown its tooling faster than its data discipline. And it will keep repeating, getting a little worse each year, until the organization treats knowing-what-data-it-has as an ongoing discipline rather than a one-time cleanup. The catalog isn’t a project you complete; it’s a practice you maintain, precisely because the sprawl it fights against never stops growing.
The encouraging part is that the same forces making the problem worse — more capable systems — are also what make the discipline newly achievable. The manual approach to cataloguing data could never keep pace with the sprawl; approaches that require far less manual upkeep finally can. But the discipline has to be adopted deliberately, because it will not emerge on its own, and every year it’s deferred is a year the gap widens.
What L&D should do with this
The sequence matters, and most teams get it backwards. The instinct is to buy the analytics tool first and worry about the data later; the durable approach is the reverse. Start by mapping what you have and defining what it means, so you know which data you can stand behind. Then equip the people closest to the learning problems to interrogate that data directly, choosing the tool on the boring criteria — connectivity, transparency, access control — rather than the flashy demo.
Done in that order, L&D stops being data-rich and insight-poor and starts being able to answer its own questions in the moment they arise. The learning teams that operate on evidence are not the ones with the most data or the fanciest dashboards. They’re the ones that did the unglamorous work of knowing what they have and making it genuinely askable — and then trusted the answers because they’d earned the right to.
