Totara Thursdays: Your LMS Isn’t the Problem. It’s Revealing One.

Why does your LMS feel like the bottleneck?

Most organisations reach a point where their LMS feels like friction rather than support. Engagement is low, reporting is unreliable, and administration keeps expanding. These are not isolated issues; they affect how decisions are made, how quickly people become capable, and how confidently the business can rely on learning data.

It is natural to assume the system is the problem because this is where the friction shows up most clearly. But that assumption shapes the response, and not always in a way that improves outcomes.

If the LMS is the problem… why do the same issues keep showing up?

Most teams can point to the same set of frustrations: low engagement, unreliable reporting, and an administrative load that keeps growing. The issues are visible in the LMS, so it feels reasonable to conclude that the system is the cause. That conclusion is understandable, but it is incomplete.

The LMS is where learning activity is recorded, tracked, and reported. It is the surface where problems become visible, which makes it the most obvious place to look for answers. Visibility is not the same as causality. When completion data is inconsistent, or reports need manual workarounds, the system becomes the place where those breakdowns show up. It does not mean the system created them.

In practice, this leads to a familiar pattern. A team exports data into spreadsheets because the report “isn’t right.” Admins rebuild views manually to make sense of progress. Managers stop trusting dashboards and rely on informal updates instead. The volume of activity increases, but the outcome does not improve. Reporting still lacks credibility, and decision-making remains slow.

This is the tension. The LMS is treated as the problem because it holds the evidence. But the underlying issues often sit elsewhere: inconsistent data structures, unclear ownership of learning processes, and fragmented ways of assigning and tracking work. The system reflects these realities with precision.

This creates a cycle. The more visible the friction becomes, the more pressure builds to replace the platform. Yet the same patterns persist after a switch because the conditions that produced them have not changed. The tool changes. The behaviour does not.

So before deciding that the LMS is failing, it is worth asking a different question. Are the problems you see being caused by the system, or are they being revealed by it?

The answer to that question determines whether you fix a tool or address the way learning actually operates.

What is the LMS actually revealing about how learning works?

If the LMS is not the root cause, what is it actually showing? In most organisations, it is revealing a structural gap: learning is not built into how work happens. It sits adjacent to it. This separation is easy to miss because activity still takes place. Courses are assigned, completions are tracked, and reports are generated. But the connection to performance is weak.

Learning often operates as a parallel system rather than an embedded one. Employees leave their workflow to complete training, then return to work without a clear link between the two. Managers are expected to support development, but are not always accountable for it, which weakens follow-through. L&D designs programmes, compliance tracks completion, and HR looks at capability. Each function plays a role, but the overall model lacks cohesion, which limits impact.

This becomes more visible as complexity increases. Onboarding is managed in one system, compliance in another, and performance conversations in a third. Data does not move cleanly between them, and definitions are inconsistent. A “completed” activity in one context does not translate into demonstrated capability in another, which limits the usefulness of reporting. The LMS captures these gaps because it sits at the intersection of these processes.

The issue is not fragmentation alone. It is the absence of a clear operating model for learning. Who owns development at the point of work? How is learning triggered by business events? What does good look like beyond completion rates? When these questions are unresolved, the system is left to compensate. It cannot.

In practice, this creates friction that looks like a system problem. Learners experience training as an interruption. Managers see reporting as administrative rather than useful. L&D spends time coordinating activity instead of influencing outcomes. The volume of learning increases, but capability does not move at the same pace.

So the LMS is doing something important. It is making the disconnect visible. It shows where learning is happening, but not where it is needed. It tracks activity, but cannot ensure impact.

This shifts the conversation. The question is no longer “how do we improve the system?” but “how should learning fit into the way the business actually operates?”

So why doesn’t switching systems fix it?

When frustration builds, replacing the LMS feels like progress. There are cases where switching is necessary. If the current system cannot support your structure, cannot integrate with core systems, or cannot produce usable reporting, it becomes a constraint on how learning can operate. In those situations, change is not optional.

A replacement often feels like progress. A new system promises better usability, cleaner reporting, and less administrative effort. The expectation is simple: change the platform and remove the friction. In some cases, things do improve at the surface level, which reinforces the decision. But the underlying issues tend to persist.

The reason is straightforward. Changing technology does not change the operating model. If learning is still disconnected from workflows, if ownership is still unclear, and if processes remain fragmented, a new system will inherit those conditions. It may present them differently, but it cannot resolve them on its own.

This shows up quickly after implementation. The launch goes well, the interface feels cleaner, and early feedback is positive. But within a few months, familiar patterns return. Managers still do not actively engage with learning. Reporting is still questioned. Admin teams begin building workarounds to fill gaps between systems. The activity resumes. The outcomes remain inconsistent.

There is often an assumption that better design will drive better behaviour. That if the system is easier to use, people will naturally engage more and make better decisions. But behaviour is shaped by expectations, incentives, and accountability, not just interfaces. If those do not change, the system can only do so much.

This creates a cycle of replacement rather than improvement. Each new platform is expected to solve structural issues it was never designed to address. Over time, confidence in the system declines, even when the real limitation sits outside of it.

So the question is not whether a new LMS is better than the old one. It is whether anything has changed in how learning is owned, triggered, and applied.

If the answer is no, then the result will be familiar. A different system, delivering the same outcomes.

What does this look like when it actually changes?

When organisations address how learning actually operates, the system starts to produce different outcomes. The change is not driven by new features. It comes from clarifying ownership, connecting learning to workflow, and standardising how activity is tracked and used. As a result, the LMS reflects a more coherent model and the friction reduces.

In practice, this shows up consistently across different contexts where organisations have implemented Totara:

• Blind Veterans UK (Compliance clarity) Fragmented records and weak tracking created audit risk. By centralising records and introducing automated reminders, visibility improved and audit preparation became predictable. Confidence in completion increased because the process was clear.

• Oxford Health NHS Foundation Trust (Usability and trust in data) Complex navigation and heavy reporting effort limited use. Simplifying navigation and aligning dashboards to management needs increased usability and, more importantly, trust in reporting. Managers used the data because it supported decisions.

• SPAR (Performance at scale) Performance, feedback, and qualifications were disconnected. Bringing these into a single model created real-time visibility for managers and reduced administrative effort across a large user base. Activity became easier to act on.

• Odido (Speed and integration under pressure) An outdated platform and a three-month timeline required focus. A phased approach with clear integration priorities created a unified learning environment across employees and partners without disruption. Speed came from alignment, not shortcuts.

These are different problems on the surface, but the underlying shift is the same. Ownership is clear, processes are connected, and learning is aligned to how work actually happens.

So the pattern is consistent. When the operating model is clarified, the system starts to work as intended. Not because it changed, but because what it is supporting has.

What actually drives performance: the system or the way it’s used?

Two organisations can run the same LMS and produce very different results. One sees consistent adoption, credible reporting, and clear links to performance. The other struggles with low engagement, disputed data, and heavy administration. The difference is not the platform. It is how learning is structured and used, which directly affects outcomes.

Systems enable activity; they do not define outcomes. An LMS can assign training, track completion, and surface data. But it cannot decide when learning should happen, who is accountable for it, or how it connects to performance decisions. Those choices sit in the operating model. When they are unclear, the system becomes a recorder of activity rather than a driver of capability.

This is where the gap between activity and outcome becomes visible. Large volumes of training are completed, yet capability does not improve at the same rate. Reports show progress, but managers do not act on them. Compliance targets are met, but risk does not meaningfully reduce. The system is doing its job. The model around it is not.

When the structure is clear, the same system produces different results. Learning is triggered by real business events such as onboarding, role changes, or performance gaps. Managers are accountable for development within their teams. Data is defined consistently and used to support decisions, not just to report activity. The system supports this flow rather than trying to compensate for its absence.

In practice, this means less time spent managing courses and more time influencing performance. Reporting becomes a tool for action, not reconciliation. Learners engage because the content is relevant to their work, not because it is assigned.

So the question is not which system will drive better outcomes. It is how learning is designed to support performance in the first place. The platform will reflect that design, for better or worse.

What needs to change before you touch the platform?

At this point, the question shifts from selecting a better system to designing a better way of working. If learning is not integrated into how the business operates, no platform will fix it. The work starts by defining how learning should connect to performance, decisions, and accountability, because this determines whether activity translates into results.

The first step is to make ownership explicit. Who is responsible for capability at the point of work? In many organisations, this is assumed rather than defined. L&D creates programmes, but managers influence performance. When ownership is unclear, learning becomes optional in practice, even if it is mandatory in policy.

The second step is to align learning to real workflows. Training should be triggered by business events, not by schedules alone. Onboarding, role changes, compliance deadlines, and performance gaps should initiate learning activity. This reduces disruption and increases relevance, because learning is tied to something that matters in the moment.

The third step is to standardise how activity is defined and used. What counts as completion? What indicates capability? How is data used in decisions? Without consistent definitions, reporting becomes an administrative exercise rather than a performance tool. Clarity here improves both trust and action.

In practice, this often means designing manager-led workflows before configuring the LMS. For example, defining how a manager identifies a gap, assigns targeted learning, reviews progress, and follows up in performance conversations. The system then supports that flow, rather than trying to impose one.

This creates a different kind of implementation. Instead of starting with features, the organisation starts with behaviour and process. The platform is configured to reflect those choices, not to compensate for their absence.

The shift is simple but significant: move from asking what the system can do to defining how learning should work. The quality of that definition determines the value the system will deliver. Once that model is clear, the platform choice becomes critical, not for its feature list, but for its ability to support how learning needs to operate across teams, systems, and workflows.

When the model changes, the system starts working

At the start, the LMS appears to be the constraint. It is where engagement drops, where reporting breaks down, and where administrative effort accumulates. As the picture becomes clearer, it becomes evident that the system is reflecting something deeper. It is showing how learning currently operates in the business, and where that model falls short.

When that model is fragmented, the LMS amplifies the friction. When that model is clear, the same system starts to deliver value. This is why some organisations extract meaningful insight, drive capability, and support performance with the same tools that others struggle to use effectively.

The implication is practical. Improving outcomes is not primarily a system decision. It is a design decision. How learning is owned, how it is triggered, and how it is applied in the flow of work determines whether the platform becomes useful or ignored.

The shift is not from one LMS to another. It is from treating learning as an activity to embedding it in how work gets done.

When that shift happens, the system no longer feels like a barrier. It becomes a reflection of a model that is working.

And that is the real decision: not which LMS to choose, but how learning should operate to support performance.

For organisations that have done that work, the platform choice becomes clearer. You need a system that can adapt to your structure, connect into your core systems, and support how learning actually happens across teams and roles. This is where platforms like Totara tend to fit, because they can be shaped around the model you define, rather than forcing the model to fit the software.

If you are at that point, where your current system is limiting how learning needs to operate, it may be worth having a more practical conversation. If Totara looks like a potential fit for your organisation, you can book a short call with our team to explore how it could support your model.