The Spreadsheet Breaks at 200 People. Here's What Happens Next.

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 outgrows the coordinator. At 80 employees, tracking who has done what is an hour a week. At 250, with new joiners arriving monthly, three compliance cycles, a certification with an expiry date, and a sales onboarding programme, it becomes the whole job. Priya is now a full-time human API, and nobody has noticed because her job title didn't change.

Then the exceptions start living in her head. The two people who did the training at their previous company and got an exemption. The contractor who isn't on payroll but needs the safety module. The employee who transferred in April and belongs to two compliance regimes. None of this is in the spreadsheet, because the spreadsheet has no column for judgment. It's in Priya, which means the company's compliance position is now stored in one person's memory and is unavailable when she takes leave.

Then the records develop quiet holes. Not through negligence — through volume. A completion recorded in the wrong tab. A batch from the Chennai workshop that a trainer emailed and nobody transcribed. A version of the module that changed mid-cycle, so half the cohort saw different content and nothing records which half. Each hole is small. None is visible. All of them are fine until the exact moment they aren't.

Then something asks for evidence. A client audit. A regulator. An incident investigation. And the question is not "did you train people?" but "produce, for this named employee, on this date, the record of what they completed and what version they saw." The spreadsheet cannot do this. It was never asked to. It contains ticks, not evidence.

That's the moment the company discovers it has been running a compliance function on a document that has no integrity guarantees, no audit trail, and no author except a person who is now, understandably, updating her CV.

The signals, in case you're in the middle of it

You don't have to wait for the audit. The tells are reliable:

• Someone has to be asked to produce a training report. It isn't a button.
• Nobody can say, without checking, how many people are overdue on a certification.
• A new joiner's onboarding depends on someone remembering to send them things.
• The phrase "let me check with Priya" appears in conversations about compliance.
• There is a tab called "MASTER (use this one)", which exists because there is another one that isn't.

If three of those are true, the spreadsheet has already broken. You just haven't been billed for it yet.

What people buy, and what they should buy

The instinctive next step is to buy software, and here's where a distinction matters that catches out a lot of first-time buyers.

There are two adjacent categories. A training management system is operations software — it manages the logistics of training: sessions, trainers, venues, batches, waitlists, calendars. It's what a company running heavy instructor-led programmes needs, and it's what commercial training providers run their business on. A learning management system is delivery software — it hosts content, enrols learners, runs assessments, tracks completion, and holds the record of truth.

Most growing companies genuinely need the second, with enough of the first bolted in to handle their occasional workshops. Some — dealer networks, manufacturers running heavy classroom programmes, anyone whose training is mostly scheduled and in-person — genuinely need the operations depth first.

The mistake is buying by label rather than by workflow. Write down the ten things Priya actually does in a month, in order of frequency. That list is your requirements document, and it will tell you which category you're in far more reliably than any comparison grid. (The modern platforms increasingly do both, which is why the debate is less interesting than it used to be — but "increasingly" is doing real work in that sentence, and you should test the scheduling features rather than assume them.)

Why "we'll build it in Google Sheets" fails specifically

Every technically-minded company has someone who proposes the middle path: skip the software, build a proper internal system. A Sheets backend, a form for completions, an automation script, maybe a dashboard. It's cheap, it's flexible, and it's ours.

I have watched this go wrong enough times to be confident about how.

It works, at first, and often quite well. Then the person who built it moves teams, and the automation script becomes an unowned artifact that nobody dares touch. Then the requirements grow — an assessment with a pass mark, a certificate with an expiry, a manager who wants a view of just her team — and each addition is another script, another sheet, another dependency. Then someone asks for evidence: not a tick in a cell, but a record showing what version of the module this named employee saw on this date. The homemade system has ticks. It has never had versions.

And then, eventually, the compliance officer asks the question that ends the experiment: if we're challenged, can we prove nobody edited this cell?

The answer is no. It was always no.

The homemade stack isn't a bad idea because it's amateur — some of them are built beautifully. It's a bad idea because the requirement it's quietly failing isn't tracking. It's evidence with integrity, and that requirement arrives without warning, years after the tool was built, in a letter from someone who is not interested in how clever the automation was.

The part nobody budgets for

Here's what I'd want a founder or a CHRO to understand before they sign anything: the software doesn't replace Priya. It replaces the parts of Priya's job that were never a good use of her.

The enrolments become rules — new joiner in Sales, path assigned on day one, automatically, forever. The chasing becomes a reminder cascade — employee, then manager, then dashboard — that runs without anyone remembering to start it. The reporting becomes a scheduled email that arrives in twelve stakeholders' inboxes on the first of the month, produced by nobody.

And Priya, who spent three years as a human API, becomes the person who actually thinks about what the company's people need to learn — which is what you should have been paying her for all along, and what the spreadsheet was quietly preventing.

That's the real argument for making the move, and it's more compelling than the audit risk, which is what usually forces it. A well-implemented learning management system doesn't just reduce risk. It returns a competent person to competent work.

The window

One last thing, on timing.

The best moment to do this is before the audit, before the resignation, and before the spreadsheet has accumulated so much history that migrating it becomes archaeology. In other words: while everything still looks fine.

Which is precisely why almost nobody does it then. The spreadsheet's greatest talent is looking fine right up until the week it doesn't — and the company that moves at 250 people, calmly, on a normal Tuesday, will spend a fraction of what the company that moves at 600 spends, in a panic, three days after the regulator's letter arrives.

Priya knows. She's known for a while. Ask her.