Project Management for 10-Person Teams

Ten is where the free plan stops fitting

Somewhere around person number six, ShipSprint's free plan (5 users, 2 projects) stops covering your actual team, and by ten you're well past it. That's not specific to ShipSprint; it's roughly where most "small team" pricing tiers end, because ten is close to the point at which a team stops fitting in one person's head.

That's the real shift at this headcount, more than the pricing one. At five or six people, whoever's paying the most attention can hold the whole picture: who's blocked, what's late, what's actually done versus "basically done." At ten, that stops being reliable. There are enough parallel threads that no single person's mental model matches reality anymore, and the gap between what someone thinks is happening and what's actually happening is exactly where deadlines quietly slip.

It's worth being specific about why ten rather than eight or twelve. Ten is roughly the size where a team stops being one conversation and becomes two or three overlapping ones: enough people that a single daily standup starts running long, and enough parallel work that "what's everyone doing" is no longer answerable by looking around an open-plan office for thirty seconds. Nine and eleven aren't meaningfully different from ten, but the zone around ten is where most small teams report the shift happening.

That's also, not coincidentally, when a board's WIP limits start doing real work. Below ten people, a column showing six items "in progress" is minor untidiness. At ten, split across two or three workstreams, six items in progress usually means three of them are stalled and nobody's noticed, because there's no longer one person glancing at the whole board every hour.

Why WIP limits start mattering right about here

A WIP limit caps how many items a column can hold before the board forces a decision instead of quietly accepting one more card. At five people it's a nice-to-have. At ten, it's closer to load-bearing: this is roughly the headcount where two or three sub-teams are each moving at their own pace, and without a limit, "in progress" turns into a parking lot for anything someone started and didn't finish. The limit forces the choice: finish it, flag it as blocked and say why, or take it off the board, before it can sit hidden for three weeks.

The same logic applies to the triage inbox for new requests. Below ten people, a new ask usually goes straight to whoever's free. At ten, "whoever's free" stops being obvious, so requests need a landing spot that isn't a specific person's inbox. That's what the triage queue is for.

None of this requires anyone to become a project manager. The board enforces the limit and routes the request; the people on the team just work off what's in front of them. That's the specific design bet behind WIP limits and a triage inbox: rules that live in the system rather than in a person's judgment scale better, because they apply the same way on a team's busiest day as on its quietest one. Teams around this size who turn WIP limits on tend to say the real change isn't fewer stalled items, it's noticing them three weeks sooner, while there's still time to do something about it.

Ten people is also usually the first time roles overlap

Below ten, most teams are still one-of-each: one designer, one salesperson, one ops person. At ten, it's common to have two people who could plausibly pick up the same piece of work: two engineers, say, or a founder and a first hire both capable of handling a client call. That overlap is good for resilience but bad for clarity, because "someone will handle it" stops meaning anything specific once there are two someones.

A triage inbox fixes the specific failure mode that creates: instead of a new request landing in one person's messages and depending on them to either handle it or explicitly hand it off, it lands somewhere both people can see and claim. Nothing falls through the gap between two people who each assumed the other had it, which at nine people simply couldn't happen because there was no gap to fall through. Teams that make this switch right around this headcount tend to notice it fast: "I thought you had this" mostly stops coming up in retros within the first couple of sprints.

What else changes at ten people

• A "my day" screen matters more once nobody can eyeball the whole team's status by glancing around the room, or the one shared channel.
• Delivery forecasts, on Business, become worth considering once you're running more than one sprint in parallel and can't sanity-check both from memory.
• Time logging stays five seconds per entry regardless of headcount, one of the few things that doesn't get harder as a team grows.
• GitHub integration turns "did that ship" into a board fact instead of a standup question, once there's more than one engineer's work to track at a glance.

Monthly versus annual, worked out for exactly ten people

Monthly billing on Team costs ₹299 per seat; annual costs ₹2,899 per seat, which is ₹241.58 a month once spread across the year: a savings of about 19% for committing upfront. For ten people, that's ₹2,990 a month versus roughly ₹2,416 a month, or ₹35,880 a year versus ₹28,990. The gap, ₹6,890 a year, is real money for a ten-person team, but it's only worth taking if you're confident you'll still be at roughly this size in twelve months, which isn't always a safe bet for a team that just crossed from five to ten.

A reasonable approach: start monthly while headcount is still moving, and switch to annual once it's settled enough that a year-long commitment isn't a guess. Both options run the same product with the same features; the only difference is the billing cycle.