Every Manual Enrollment Is a Bug Report

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 framing is the single most expensive assumption in learning operations, and flipping it is close to free.

The rule

Here it is, and it's the whole article: every time a human does something by hand in your learning operation, ask what rule should have existed.

Not "how do we do this faster." Not "should we hire another coordinator." Just: what rule was missing?

A new joiner in Sales was enrolled manually. What rule was missing? An attribute-based enrolment that reads the HRMS sync and assigns the sales onboarding path on day one to anyone whose department field says Sales. Written once. Runs forever. Never forgets, never takes leave, never misses the person who joined during Diwali week.

Seven people were chased by email. What rule was missing? A reminder cascade — learner at day 7, manager at day 14, compliance dashboard at day 21 — triggered by the deadline, not by anyone's memory.

A report was exported for a business head. What rule was missing? A scheduled report that emails itself to that business head on the first of every month, so she stops asking and you stop exporting.

The transferred employee was added to a new group. What rule was missing? Nothing, actually — that one should have happened automatically the moment HR updated her department, and the fact that it didn't means your HRMS integration is decorative.

Why this doesn't happen naturally

Two reasons, and they're both structural rather than personal.

The manual fix is invisible and the automation is a project. Enrolling twelve people takes ten minutes. Writing the rule takes an afternoon, requires understanding a feature nobody has explored, and might need someone from IT. Faced with that trade on a busy Tuesday, every rational person enrols the twelve people. And on the next Tuesday. Forever. The ten minutes never appear on a report; the afternoon does.

This is technical debt, exactly as engineers understand it — a small rational choice that compounds into an operation where nobody has time to fix anything because they're too busy doing the things that need fixing.

The manual work looks like the job. This is the deeper one. An admin who spends her week processing enrolments and chasing completions has visibly worked. She has responded to requests, cleared a queue, and been helpful. An admin who spends the same week writing rules has produced nothing visible at all, and will be asked what she's been doing.

Organizations that reward visible responsiveness get an operation made of heroism. Heroism does not scale, and — this is the part that stings — it hides the need for the system, because things somehow keep working right up until the hero leaves.

The metric that fixes the incentive

If you want one number to run a course management operation on, it's this:

Admin hours per 100 learners per month.

Track it. Chart it. Take it to the same review where you'd discuss any other operational efficiency. Because the moment that number exists, the incentive flips: the admin who wrote rules all week and processed nothing now has evidence that she made the operation cheaper, and the admin drowning in manual work has evidence that she needs help — not another pair of hands, but an afternoon to build the thing that removes the need for hands.

In a healthy operation, that number falls as headcount grows. That's the whole test. If your admin load scales linearly with your workforce, you don't have a system. You have a person, and a growing dependency on them.

The corollary metric, for the same review: escalation volume, categorized. Every recurring category of support request is a defect wearing a costume. Six people a month asking how to find their certificate isn't a training issue; it's a UX issue with a monthly bill.

The exception list

The obvious objection: some things genuinely can't be automated. True — and the honest response is to name them rather than let them multiply.

Keep an exception list. The contractor who isn't in the HRMS. The regional programme with a bespoke approval. The senior leader whose enrolment always goes through their EA. Write each one down, with its reason.

Two things then happen. First, the list stops living in someone's head, which means the operation survives their departure. Second — and this is the useful part — the list gets reviewed, and about half of it turns out to be automatable after all, once someone looks at it deliberately rather than encountering it at speed on a Tuesday.

Undocumented exceptions are how well-run operations rot. They're indistinguishable from the missing rules they're hiding.

The rule you write is a decision you'll have to defend

A caveat, because I don't want to hand anyone a licence to automate carelessly.

A manual process is forgiving. When an admin enrols people by hand, she applies judgment silently — she notices that the new joiner is actually a rehire, that the contractor shouldn't get the internal-only module, that the person on leave shouldn't be chased. That judgment is invisible, unrecorded, and completely dependent on her being there. It's exactly why the manual system doesn't scale.

But when you convert it into a rule, that judgment has to be made explicit, in advance, by someone. And the rule will then apply it to five thousand people without hesitating.

This is a feature and a hazard at once. A well-written rule encodes good judgment permanently. A carelessly written one encodes a bad assumption permanently — and, unlike a human, it never hesitates, never notices something odd, never asks.

Which means automation carries an obligation the manual system didn't: the rules have to be documented and reviewed. A registry of what exists, what it reads, and what it assumes. Reviewed when the org changes, when a policy changes, when someone joins the team.

Undocumented rule sprawl is just the coordinator's memory problem again, transferred into a system where nobody can see it and nobody remembers writing it. You haven't fixed the fragility. You've automated it.

Write the rules. Then write down the rules.

What you're actually buying back

The point of all this isn't tidiness. It's that a learning function drowning in manual course management has no capacity left for the work that actually matters — deciding what the business needs people to become, curating content that's worth someone's eleven minutes, working with managers to make development count.

An L&D team that spends its week on enrolments and exports isn't a strategic function. It's a queue with a budget. And the tragedy is that everyone involved knows it, and everyone is too busy clearing the queue to fix the queue.

So: next time you enrol someone by hand, feel the small flare of annoyance an engineer would feel. Then write the rule.

You'll do it about forty times. And then, one Tuesday, you'll notice you have an afternoon free — and that's when the actual job starts.