---
id: KB-AD-010
url: https://app.codecontract.io/help/administration/when-the-team-grows-from-five-to-fifty
idioma: en
categoria: administracion
audiencia: administrador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-AD-002, KB-ET-011, KB-AD-008]
citadoPor: [KB-AD-017]
---

# When the team grows from five to fifty

_What worked with five people stops working, and gives no warning._

**Responde a:** organising the platform as the team grows · everyone is an administrator and we are now many · reorganising permissions in a growing company · scaling document management

With five people everything works with nothing configured: everyone sees everything, everyone can do anything, and if something goes wrong you talk it out. That model holds up to a point and then stops working without warning — usually between fifteen and twenty-five people.

## The signs you are no longer five

| Sign | What is happening |
| --- | --- |
| Someone deletes something by accident | Too many people with delete permission |
| Nobody knows who owns a case | No owner, and with five it was not needed |
| People ask on chat who did what | The log exists, but nobody uses it yet |
| A colleague sees something they should not | Teams need separating |
| There are seven administrators | Nobody feels responsible for anything |

> [!IMPORTANT]
> None of these signs is a tool failure: they are the five-person model applied to twenty-five. And none resolves itself, because individually each looks like an isolated case.

## The order to fix it in

1. **Reduce to two administrators** — Fastest, and removes the most risk. Half an hour.
2. **Remove delete permission from whoever does not need it** — Almost nobody needs it daily, and it does the most damage.
3. **Give cases an owner** — One per case, by name. It is what prevents dead cases.
4. **Separate into teams if something should not be seen by all** — And only then: splitting before it is needed gets in the way.

> [!WARNING]
> Do not do it all in one day or without warning. Removing permissions without explaining why reads as distrust, and people remember that longer than the improvement lasts.

> [!NOTE]
> The natural moment is when someone new joins and you do not know what permissions to give them. That doubt is the signal: it means there is no longer one profile that fits everyone.

**When exactly is the right time?**

There is no magic number. The signal is doubt about a new joiner's permissions.

**Can it be reversed?**

Yes, everything adjusts. But explain changes rather than making them silently.

**What if we grow very fast?**

Then start with two administrators and delete permission; the rest can wait.

## Ejemplos

**A company grows from 8 to 30 people in a year and everyone is still an administrator.**

- Reduces to two administrators
- Removes delete permission from 26 people
- Explains why at the team meeting

→ Accidental deletions disappear without anyone experiencing it as distrust.

**What worked with five people breaks with fifty.**

- Reviews permissions and structure as it grows

→ The organisation keeps up with the team.

**Everyone is still an administrator.**

- Adjusts roles to the job

→ Access stops being general.

**Nobody knows who handles what.**

- Assigns owners per process

→ Requests reach somebody.

**Each department builds its own templates.**

- Unifies what repeats

→ Improvements reach everyone.

**Onboarding new people is done by hand every time.**

- Defines an onboarding process

→ Growth does not consume a person.