What happens past 10 people

Why things change around 10 people

Because one person can no longer talk with everyone every day. With five or six people, you naturally know who's doing what, but past ten, the same information has to be passed along two or three times, and someone gets left out along the way.

Then information gets tied to people. "Ask OO about that" becomes more common, and when that person is away, work stops. If you don't build a system at this point, hiring more people won't speed things up.

What actually happens

• It's unclear who approves what. Whether it's annual leave or expenses, it ends with "I told the CEO," and later there's no way to check who approved it and when.
• The same decision gets made twice. The person who remembers what was decided last month isn't around, so it gets discussed again.
• Newcomers flounder for two months. Too much can only be learned by asking people, not from documents.

Three things to decide first

1. 01Write down rolesNot job titles, but **what each person decides**. One line like "Kim OO — decides project schedules and staffing" is enough. This comes before the org chart.
2. 02Set approval linesFor each thing that needs approval, like annual leave, expenses and contracts, decide **who approves it**, one by one. Splitting by amount brackets keeps everything from landing on the CEO.
3. 03Keep records in one placeDecide **where** decisions and approvals are recorded. Messenger chats can't be found two days later, so don't use them as the record.
4. 04Don't build it all at onceTry to write a rulebook and you'll never start. Decide the one thing that gets stuck most often right now, and once that runs, add the next.

Common sticking points

• Worrying that a system will slow you down. Things slow down when there are too many approval steps; having approvers not decided is slower still. Finding out who to ask takes longer than the approval itself.
• The CEO is in every approval. It feels natural at first, but the CEO soon becomes the bottleneck. It's better to delegate by brackets of amount or type.
• Making rules but not keeping records. If you set rules and then actually handle things over messenger, it's as if the rules don't exist. Doing it through a channel that leaves a record is half the rule.

It only means something in the same account as your projects

You can decide the three things above in documents. A tool becomes necessary when you need to check whether what you decided is being followed — if someone is counting who approved what and when, or how many items are backed up this month, that's the time.

Sprintingo handles the company → team → employee hierarchy, job titles and per-screen permissions in the admin console. Annual leave and purchase requests name an approver at submission, so each request records who approved it and when, and annual leave adjustments aren't deleted when canceled — they remain with the opposite sign, so you can see exactly what happened. Annual leave, project schedules and one-on-ones all go on one unified calendar.

And because this HR data is in the same account as projects and revenue, you don't have to go around asking "who has capacity this week?"

Frequently asked questions

At what headcount do we need a management system?

It's better to watch for signals than headcount. If "ask OO about that" is becoming common, or you're re-discussing what was decided last month, that's the time. It usually shows up around 10 people, but it depends on the type of work.

Do we have to write all the rules first?

No. Try to write a rulebook and you'll never start. It's faster to decide the one thing that gets stuck most often right now (usually the approval line), and add the next once that runs.

HR information shouldn't be visible to just anyone.

Permissions are split per screen. View, create, edit and delete are toggled separately, so the org chart can be open to all employees while salaries and revenue are open to C-level only. The admin console keeps an audit log of who changed what.