The 20-Person Team Problem: Too Big for Chaos, Too Small for an LMS

At 8 people, most teams can get away with memory.

The new hire sits near the person who knows the billing workflow. The ops manager answers the same question four times in Slack and barely notices. A customer success lead records a quick screen share, drops it in a channel, and that’s apparently training.

It isn’t elegant, but it works well enough. Everyone knows roughly who knows what. Gaps get patched in conversation.

Then the team grows.

Somewhere around 20 people, the small frictions stop being small. The same onboarding questions keep resurfacing, but now they land in different inboxes. The unofficial expert is in back-to-back meetings. The sales team explains the product one way, support explains it another, and operations quietly develops its own version of the truth just to keep things moving.

Nothing is on fire. That’s part of the problem. The team has outgrown chaos, but not dramatically enough to justify a full learning stack, a dedicated enablement hire, or a six-month training project. So knowledge sharing becomes everyone’s side job, which usually means it becomes nobody’s job.

When “just ask that person” stops working

There’s usually that person.

Not literally. But every team has a person who carries an unreasonable amount of context in their head. They know why the refund process has three odd exceptions. They know which enterprise customer still needs the old workflow. They know that the SOP in Notion is technically correct, but misses the one step that prevents a mess later.

For a while, that arrangement feels efficient. Why document everything when that person can answer it in thirty seconds?

Because thirty seconds doesn’t stay thirty seconds.

Once a team gets big enough, questions multiply faster than answers. New hires don’t know what they don’t know, so they ask reactively. Managers fill gaps live. Training becomes a chain of interruptions. People are helpful, but the system is fragile.

The problem isn’t only that knowledge is undocumented. It’s that documented knowledge and absorbed knowledge are not the same thing.

Most growing teams do eventually write things down. They create folders, wikis, recorded walkthroughs, process docs. Then they assume the existence of documentation means the problem is solved. It rarely is.

A 14-page SOP can be perfectly clear and still fail as training. A folder full of call recordings can be useful and still teach almost nothing unless someone knows what to look for. Documentation stores information. Training helps a person use it at the right moment, under normal work pressure, without hunting through five tabs.

That’s a different job.

The awkward middle is real

Large companies solve this with structure. They buy an LMS, assign owners, build courses, track completions, set governance rules, and spend a fair amount of time administering the whole thing.

A 35-person company usually doesn’t need that. More to the point, it usually can’t support it.

Enterprise learning systems assume a certain world: compliance requirements across departments, full-time administrators, formal programs, long software evaluations, enough scale to justify complexity. For a lean team, that can feel like installing airport security to manage a shared office kitchen.

So teams delay. They keep training informal because the formal option looks absurdly heavy.

This is where a lot of avoidable pain comes from. Not from ignoring training, exactly. From assuming there are only two choices: keep winging it, or buy software built for a company ten times the size.

There’s a middle path, but it looks less impressive than people expect.

It usually starts with a narrow question: where does inconsistency cost this team the most?

Not “how do we build a complete learning program?”

More like: why do new CSMs take six weeks to handle renewals confidently? Why does every support hire need the same ad hoc explanation of escalation rules? Why do managers still reteach the same process two months after onboarding?

Those questions lead to better training because they’re attached to work. Real work, with failure modes and consequences. That matters. Teams in this stage do not need a university. They need fewer repeated mistakes, faster ramp time, and less dependence on whoever happens to be online.

Small systems, not grand programs

The teams that handle this well usually do a few unglamorous things.

They stop treating training as a one-time event. Reading docs during week one is not the same as learning a job. People need information in sequence, with examples, practice, and some way to tell whether it actually stuck.

They build from existing material instead of starting from a blank page. The best raw material is often already lying around: recorded demos, call reviews, policy docs, process walkthroughs, manager explanations in Slack threads. The work is not inventing content from scratch. It’s turning scattered context into something teachable.

They choose a few moments that matter. A team doesn’t need to operationalize every piece of knowledge at once. It needs to identify the points where confusion creates drag: handoffs, edge cases, compliance steps, customer-facing explanations, recurring mistakes.

And they make ownership boring and explicit. Not “the team owns onboarding.” An actual person owns the support onboarding flow. Someone updates the returns policy training when the policy changes. Someone notices that half the cohort missed the same quiz question or keeps making the same error in live work.

This is less about content volume than feedback loops.

A decent training system for a 20-to-200-person company is not a giant library. It’s a small set of learning paths tied to real responsibilities, kept current by the people closest to the work, and checked often enough that stale information doesn’t quietly become company policy.

That can live in simple tools. Sometimes it’s a lightweight course builder. Sometimes a wiki plus recorded explanations plus manager check-ins. Sometimes a platform like Capya sits in the middle and structures what the team already has. The point isn’t the category. The point is that training becomes a maintained system rather than a pile of references.

Past osmosis, not yet bureaucracy

This awkward stage tends to be misread.

Leaders assume things feel messy because the company is growing, and growth is just messy. That’s partly true. But there’s a specific kind of mess that comes from relying on social proximity long after it stops scaling.

In a 12-person company, people learn by overhearing each other. In a 60-person company, they learn by guessing, interrupting, or not asking.

That shift is easy to miss because the documents exist. The meeting recordings exist. The notion that training is “somewhere in Notion” exists. What’s missing is the bridge between available information and repeatable understanding.

That bridge does not require an L&D department. It requires a team deciding that knowing something is not the same as teaching it, and storing something is not the same as learning it.

For companies in the middle, that’s usually the real transition. Not from startup to enterprise. From proximity to systems.

A lot of teams wait too long to make it.

By the time they do, that person is tired.