How to Measure Informal Learning at Work: A Framework

Key Takeaways

Completion rates measure obedience, not learning. They tell you who clicked through a mandatory module, not who learned something they actually needed. Treating the two as the same metric is where most L&D reporting goes wrong.
Most learning at work is invisible by construction. The widely cited 70-20-10 heuristic (McCall, Lombardo, and Eichinger, Center for Creative Leadership) puts the bulk of learning in on-the-job experience and social exchange, with only a small slice in formal courses. An LMS was built to report on that small slice.
Five metrics carry real signal, in order: unprompted adoption, repeat usage, time-to-learning, topic-level demand, and coverage of the long tail. None of them require watching an individual learner.
Individual surveillance backfires. Tracking what one person searched or asked destroys the trust that makes people ask in the first place, and in EU organizations it runs straight into works councils and GDPR. Measure demand and patterns, not people.

Completion rates measure obedience, not learning

Ask most L&D dashboards a simple question, "did the team learn what it needed this month," and they cannot answer it. They can tell you who finished the compliance module, who is overdue on onboarding, and who has not opened the quarterly course yet. That is a real and useful thing to know. It is not learning.

The gap exists because of where the data comes from. An LMS records what it assigns: scheduled, mandatory, auditable training, roughly 5% of what people actually learn at work, by the same estimate we use on our shadow learning page. Why employees route around the assigned layer is its own story, and we tell it in Why Employees Don't Use the LMS. The other 95% happens off the record: an engineer looking up a new API on YouTube, a manager asking ChatGPT how to structure a hard conversation, someone messaging a colleague in Slack the moment a task gets stuck. None of it shows up in a completion report, because none of it was assigned.

A completion rate is not wrong. It is just answering a much narrower question than the one L&D needs answered, and reporting it as if it were the whole picture.

What not to measure: demand, not people

The instinct to close this gap is often "instrument everything," including what individuals search for, ask, and click on outside the LMS. Resist it.

Tracking an individual's questions turns a moment of curiosity into a monitored event. The employee who would have asked "what does this acronym mean" in a Slack thread stops asking, because it is now logged against their name. You lose the exact behavior you were trying to see, and you lose it first in the people engaged enough to keep asking.

In EU organizations this is also a legal problem, not just a trust one. Works councils generally hold co-determination rights over systems that monitor employee behavior, and individual-level learning surveillance is exactly what GDPR's purpose-limitation and data-minimization principles exist to catch.

The alternative is to measure demand and pattern rather than the person: what topics are being asked about, by which teams, how often, not who specifically asked. That is enough to run L&D, and it is the only version people will not learn to route around.

The metrics that actually carry signal

Rank these by how much they tell you about real learning, not by how easy they are to pull from an existing dashboard.

Unprompted adoption. Of the people who could use a learning resource, how many did, with no mandate, reminder, or manager nudge? This is the strongest signal there is, because it is the only one that cannot be manufactured by policy. A completion rate enforced by a due date tells you about compliance. An adoption rate with no due date tells you about need.
Repeat usage. Did the same person come back a second time, unprompted, for a different question? One-time use can be curiosity or a fluke. Return use means the first experience solved a real problem well enough that the person trusted it with the next one.
Time-to-learning. Start a stopwatch the moment a question appears, and stop it the moment the person is looking at something relevant. Today that gap is usually filled by a search engine or an AI chat window, because it is faster than anything L&D built. Shrinking this number is the point of meeting learning in the flow of work.
Topic-level demand, this week. What are teams actually trying to learn right now, not what a needs analysis said six months ago? A weekly view of demand by topic and team catches an emerging gap, a new tool rollout, a process change, while it is still forming, instead of a quarter later in an engagement survey.
Coverage of the long tail. Take ten real, recent questions your teams have asked, the niche internal tool, the one-off client requirement, and check whether your learning stack can answer any of them. Catalogs are built for the common case. Most of what employees need to know is not the common case.

None of this requires a name attached to a query. Adoption, repeat usage, time-to-learning, and topic demand are all countable in aggregate, without anyone reading an individual's search history.

How to instrument this without building a surveillance system

The practical version of this framework has three moves, and none of them require a new monitoring layer.

Put learning where the question already fires. If getting an answer means remembering to open a separate portal, most people will not, and you will have no data at all. Learning needs to live in Slack and Microsoft Teams, where the question was already being typed.

Make asking effortless. Informal learning is invisible mostly because recording the moment used to cost more effort than the learning itself. Once "explain this" or "walk me through that" generates a structured path automatically, the request becomes the data. Nobody has to log anything.

Aggregate by topic and team, not by person. Roll activity up to "the data team asked about SQL window functions eleven times this month," not "Jana asked about SQL window functions." That is the level at which the numbers are useful to L&D, and safe to bring to a works council.

A worked example: one pilot, measured honestly

This is the shape of measurement Plynn was built to produce, so it is worth showing with real numbers, from one enterprise pilot with the engineering, data, and support teams of a fintech company. These are results from a single, small-cohort deployment, not an industry benchmark, and the full methodology is published on our pilot results page.

In that pilot, 60% of employees adopted Plynn with no prompting or mandate from L&D, the unprompted-adoption signal above, showing up in a real organization. 90% of employees who created one course came back to create another, the repeat-usage signal. Median time from a person's question to a ready, structured learning path was under two minutes, the time-to-learning signal, measured, not modeled.

None of those three numbers required watching what any individual asked. They came from counting activity in aggregate, which is the whole point: a framework built on demand and pattern produces numbers L&D can stand behind, in a board deck or in front of a works council, because it was never built on watching people.

Frequently Asked Questions

Why are completion rates a bad measure of learning?

Because they measure whether an assigned module was finished, not whether the person learned something they needed. Completion is driven by a due date and a manager's reminder, so it is really a measure of compliance. Real learning demand shows up in unprompted adoption and repeat usage instead, numbers that cannot be manufactured by a mandate.

Is it legal to track individual employee learning behavior?

It depends on what you track. Tracking what topics teams ask about, in aggregate, is straightforward. Tracking what a named individual searched or asked is a different category of processing, and in EU organizations it typically triggers works council co-determination rights and GDPR's data-minimization requirements. The safer design point is demand by topic and team, not activity by person.

What is the 70-20-10 model, and does it still apply?

It is a widely used heuristic from McCall, Lombardo, and Eichinger at the Center for Creative Leadership, holding that most workplace learning happens through experience and social exchange rather than formal courses. It is a rule of thumb, not a precise measurement, but the direction it points in, formal training covering a minority of how people actually learn, matches what LMS completion data alone cannot show you.

What's the fastest metric to start tracking if we're doing none of this today?

Time-to-learning. Pick one real question that came up on a team this week and measure, honestly, how long it took that person to get to something relevant, whether that was a Google search, a Slack message to a colleague, or a formal course. That single number will tell you more about where your learning stack is failing than a year of completion reports.