Skills Caravan LXP

The kickoff meeting for a platform migration is always run by the wrong people, asking the wrong question. There's an IT lead, an L&D manager, a project plan, and a vendor implementation consultant. And the question on the table — the one that shapes everything that follows — is: how do we move what we have into the new system? It's a completely reasonable question. It is also the question that guarantees you will spend six months, a substantial budget, and an enormous amount of organizational goodwill in order to arrive at exactly where you started, with better uptime. Because the honest truth about most learning platform migrations is that the thing being migrated doesn't deserve to survive . What you're actually carrying Before the project plan, run the census. Export the full inventory from the old system: every course, with its last-updated date and its twelve-month usage count. The results are remarkably consistent across companies, and remarkably ...

Run this on your learning platform and report back. Sort every course by last updated . Now look at how many were last touched more than two years ago. Then look at how many of those are about your products, your processes, your policies, or your systems — the things that have definitely changed since. That number is not a content inventory. It's a list of things your platform is currently telling employees that are, to some degree, no longer true. We talk about content libraries as if they were warehouses: things you fill, things that sit there, things that retain their value while stored. They're not. They're gardens. Everything in them is alive, most of it is dying, and if nobody is weeding, you are not running a library — you are running a compost heap with a search box. What rot actually costs The instinct is to treat stale content as harmless clutter. It isn't, and the damage runs in three directions. It destroys trust, retail. An employee searches f...

There's a habit in good engineering teams that I've come to think is the most transferable idea in modern management, and almost nobody outside software has picked it up. When something breaks and a human fixes it by hand, the engineer doesn't feel relieved. They feel annoyed — and they write a ticket. Not about the incident. About the fact that a human was needed at all. The manual fix is treated as evidence of a missing system, and the missing system is the actual bug. Now hold that idea next to how learning operations work in almost every company I've seen. An admin manually enrols a new joiner. Manually chases the seven people who haven't finished the compliance module. Manually exports a report because a business head asked for it. Manually adds the transferred employee to the right group. And at the end of the week, having done all this, she feels productive — because in her function, the manual fix isn't a bug report. It's the job. That fram...

Every growing company has a Priya. She's an HR generalist, or an ops coordinator, or an executive assistant who inherited "training" three years ago because someone had to. She maintains a spreadsheet. The spreadsheet has tabs — one per programme, one per year, one that's just called "MASTER (use this one)". It works remarkably well, and it works because Priya is good, and it has never once occurred to anyone that this is a system with a load limit. It has a load limit. It's somewhere around 200 people, and the strange thing about crossing it is that nothing visibly breaks on the day. There's no alarm. The spreadsheet still opens. What happens instead is a slow, invisible transfer of risk from the system to the human — and by the time anyone notices, the risk has already materialized somewhere expensive. What actually breaks, in order The failure isn't dramatic. It's a sequence, and it runs like this. First, the coordination cost ...

The most repeated line in HR is that people don't leave companies, they leave managers. It's a good line. It's also, in my experience, only half true — and the missing half explains most of the resignations that leave managers genuinely baffled. Plenty of people leave managers they like. They leave because they looked up, one ordinary Tuesday, and saw the ceiling. Not a bad boss, not a toxic culture, not even bad pay. Just a clear, quiet view of exactly how far this goes, and a growing suspicion that they'd already covered most of the distance. The moment nobody records Ask someone why they left and you'll get the socially acceptable answer: a better opportunity, a bigger role, more money. All true, and all downstream of something that happened months earlier and never got named. The actual moment is usually smaller and stranger. Someone realizes they haven't learned anything new in fourteen months. Or they watch a peer at another company move into a r...

 A safety module for a plant in Tamil Nadu. Written in English. Delivered to supervisors and operators, some of whom read English comfortably, many of whom read it slowly and think in Tamil, and a few of whom nod politely at the completion screen having understood perhaps sixty percent of it. The completion rate on that module was 94%. The comprehension rate was unmeasured, unmeasurable, and — I would bet a good deal of money — considerably lower. This is one of the quietest failures in Indian corporate learning, and it persists for the least defensible reason imaginable: not because anyone decided it, but because nobody ever decided otherwise. The default that nobody chose Ask why the content is in English and you'll get a chain of perfectly reasonable answers. The L&D team works in English. The licensed content library came in English. The subject-matter experts wrote their material in English. Translation was expensive, so it was deferred. And the completion number...