Who owns your LMS?.

Ask an L&D team what's wrong with their learning platform and you'll get a list: the reporting is hopeless, the interface is dated, nobody can find anything, it doesn't talk to the HR system. All of it will be true.

Ask a second question — who runs this, and how much of their week does it get? — and the answers become vaguer. It's part of someone's role. It sits with HR. The person who set it up has moved on. We've all got logins.

That second answer usually explains the first one.

Responsibility isn't ownership

Plenty of people are responsible for a learning platform. Far fewer own one. The difference is time and mandate.

A responsible person answers when something breaks. An owner knows what the system is capable of, decides what it should be doing next, and has hours in the week protected to make that happen. One is a duty; the other is a job.

The structural reason this happens is visible in the data. TalentLMS's 2026 L&D report found that half of the HR managers surveyed say learning and development is managed by HR or People teams, with 23% reporting a dedicated L&D team and 13% a single individual. When learning technology sits inside a function whose main work is something else, the platform gets the attention left over — and there usually isn't any.

How systems end up unowned

It's rarely a decision. It happens in one of four ways, and they're all mundane.

• The project ended. Implementation had a budget, a project manager and a launch date. None of those things covered the following Monday.
• The person left. One capable individual understood the configuration, and nothing was written down. Their replacement inherited the logins but not the knowledge.
• It was never assigned. Everyone assumed it belonged to someone else — L&D thought IT, IT thought L&D, HR thought the vendor.
• It was absorbed. It became 5% of someone's job on paper and 0% in practice, because the other 95% has deadlines attached and the LMS doesn't.

What an unowned platform looks like after two years

The symptoms are consistent enough to be diagnostic. If several of these are familiar, the problem probably isn't the software.

• Nothing has been configured since go-live. The settings are still whatever the implementation partner left behind.
• Modules are licensed but switched off — sometimes nobody remembers they were bought.
• Compliance reporting takes days, because the same report is rebuilt by hand every quarter instead of being built once and scheduled.
• User records have drifted. Leavers still have accounts; joiners are added late; the LMS and the HR system disagree and nobody knows which is right.
• Course structures have grown organically, so nobody can find anything and duplicates have appeared.
• There's a spreadsheet. There's always a spreadsheet, and one person owns it personally.
• Integrations that once worked have quietly stopped, and were noticed weeks later.
• Nobody has upgraded, or nobody has tested the upgrades that happened automatically.
• Support tickets get raised for things that are configuration options.
• The platform's reputation internally is poor, and no one can point to when that started.

The cost is real, and invisible

None of this appears in a budget line, which is exactly why it persists.

You're paying full licence cost for partial use. Someone senior is spending days on reporting that should take minutes. Compliance evidence is weaker than anyone would like to admit before an audit. And eventually the organisation concludes the platform has failed and starts shopping for a replacement — which is the most expensive possible outcome, because the new one will be unowned too, and in two years it will look exactly like the old one.

Replacing an unowned system gets you a newer unowned system.

The 90/10 rule

A well-run LMS runs itself about 90% of the time. Enrolments trigger automatically. Reminders go out without anyone pressing send. Starters and leavers flow from the HR system. Compliance reports are built once and scheduled, not rebuilt every quarter. Certificates issue themselves. The system does the repetitive work, because repetitive work is what software is for.

The remaining 10% is human, and always will be:

• Maintenance checks — confirming the automation is still doing what you think it is
• Integration work — as the systems either side of the LMS change
• Reporting — new questions need new reports
• Courses and content — adding, updating, retiring
• Promotion — new content nobody knows about achieves nothing
• Issues and tickets — the genuine exceptions

If your split is worse than that, the problem is configuration, not capacity. Adding another pair of hands to keep doing things manually treats the symptom. The test isn't “do we have someone” — it's “is most of what they're doing automatable?” There's a longer piece on the rule here, including how to measure your own split.

It's also the more useful question to take to your board, because it changes the ask. “We need another administrator” is a headcount conversation and it will lose. “Our platform is doing 40% of what it should automatically, and here's what fixing that is worth” is a different conversation entirely.

The 10%, in practice

It helps to be concrete, because “someone should own it” is easy to agree with and hard to act on. Once the automation is doing its job, the human work looks roughly like this:

• Weekly — user and enrolment management, joiners and leavers, first-line queries, checking integrations are still running
• Monthly — compliance and completion reporting, course maintenance, reviewing what's failing and why
• Quarterly — upgrade testing, permissions and role review, licence reconciliation, a look at what's licensed but unused
• Annually — renewal preparation, data quality audit, and an honest assessment of whether the platform still fits
• Continuously — documentation, so this doesn't all leave when a person does

For most organisations that's somewhere between one and five days a month depending on size, number of systems and how much compliance sits on top. It is not a full-time job for most, which is precisely why it never gets a full-time person — and why it falls through the gap.

If it's taking substantially more than that, go back to the 90/10 rule. You almost certainly have an automation problem wearing the costume of a resourcing problem.

Three honest options

Assign it internally, properly. Give it to a named person, protect the hours in their diary, and write it into their objectives so it survives a busy quarter. This is the cheapest answer and for many organisations it's the right one. It fails only when the time isn't genuinely protected — which is how the situation arose in the first place.

Hire for it. Sensible above a certain scale, particularly with multiple systems or heavy compliance. Expensive below that, and it carries the key-person risk that created the problem originally.

Outsource it. Someone external holds the role, with documentation as part of the arrangement so you're not dependent on them either. Suits organisations where the work is real but doesn't justify a post.

The wrong answer is the fourth one, which is what most organisations actually do: leave it unassigned, absorb the cost invisibly, and blame the platform.

Where to start

Before deciding anything, find out where you stand. Two questions will tell you most of it.

What's on your licence that isn't switched on? Ask your vendor for the list of modules on your contract and compare it against what's actually live. It costs nothing and it's frequently startling.

How long does your compliance report take? If the honest answer is measured in days, that's the size of the gap, repeating every quarter.

Then apply the rule. Of everything your team does on that platform in a month, how much of it could the system be doing on its own?