What breaks as a team grows
A small team runs on shared memory. Everyone heard the decision, everyone knows who is doing what. Each new person dilutes that. The first signs are small: someone asks a question that was answered last month; two people build the same thing; a launch surprises support.
The stages, and what to add
| Team size | What starts to hurt | What to add |
|---|---|---|
| 1 to 5 | Little. Work lives in people’s heads | A written plan and a board |
| 5 to 15 | Unclear owners, scattered decisions | An owner on every card; written decisions; a weekly plan |
| 15 to 30 | Two teams, one product; hand-offs | Clear areas of ownership; a shared release page; roles |
| 30 to 50 | Dependencies and surprises between teams | A planning rhythm across teams; written dependencies; guests and permissions |
1 to 5
What starts to hurt
Little. Work lives in people’s heads
What to add
A written plan and a board
5 to 15
What starts to hurt
Unclear owners, scattered decisions
What to add
An owner on every card; written decisions; a weekly plan
15 to 30
What starts to hurt
Two teams, one product; hand-offs
What to add
Clear areas of ownership; a shared release page; roles
30 to 50
What starts to hurt
Dependencies and surprises between teams
What to add
A planning rhythm across teams; written dependencies; guests and permissions
Add structure only when something hurts
Process has a cost: every rule is something people must remember. Add a rule when a specific problem has happened twice, and remove it when it stops helping. A rule that nobody can explain the reason for should go.
Five changes that pay off early
- Name an owner for everything. Every card, every decision, every launch. Shared ownership is no ownership.
- Write decisions down. Where, and in one place. A decision in a chat thread is gone in a week.
- Make dates visible. A calendar for each person and a release page for each ship date.
- Hold a short weekly planning. Ten minutes: rank, unblock, remove.
- Run a retrospective every few weeks. Change one thing each time.
Keep it light
- Prefer one tool to several, so the truth is in one place.
- Keep your definition of done to a handful of lines.
- Review your process every quarter and delete what is not used.
- Be wary of copying a large company’s process. It solved a problem you may not have.
Roles that appear as a team grows
| Around | A role that becomes necessary | What it does |
|---|---|---|
| 5 to 8 people | A tech lead | Keeps the technical direction and unblocks others |
| 8 to 12 people | A product owner | Decides priorities, so engineers are not guessing |
| 12 to 20 people | An engineering manager | Looks after people, hiring and how the team works |
| 20 to 50 people | Several teams, each with a lead | Each team owns an area, with someone accountable |
5 to 8 people
A role that becomes necessary
A tech lead
What it does
Keeps the technical direction and unblocks others
8 to 12 people
A role that becomes necessary
A product owner
What it does
Decides priorities, so engineers are not guessing
12 to 20 people
A role that becomes necessary
An engineering manager
What it does
Looks after people, hiring and how the team works
20 to 50 people
A role that becomes necessary
Several teams, each with a lead
What it does
Each team owns an area, with someone accountable
These are rules of thumb, not rules. The mistake to avoid is adding the role after the pain has gone on for months.
The first engineering manager
Promoting the best engineer to manager is common and risky: the skills are different and the person loses the work they loved. Make the move explicit, give the person training and a way back, and be honest about what the new job is. A good manager’s output is the team’s output.
Growing pains, and what usually fixes them
| The pain | A common cause | A first fix |
|---|---|---|
| Things are built twice | Nobody can see what others are doing | A shared board and a weekly look at it |
| Decisions get relitigated | They were made in a thread nobody can find | Written decisions in one place |
| Launches surprise support | Support is not in the plan | A release page with a section for support |
| New people take months to be useful | Knowledge lives in heads | An onboarding doc the newest person fixes |
Things are built twice
A common cause
Nobody can see what others are doing
A first fix
A shared board and a weekly look at it
Decisions get relitigated
A common cause
They were made in a thread nobody can find
A first fix
Written decisions in one place
Launches surprise support
A common cause
Support is not in the plan
A first fix
A release page with a section for support
New people take months to be useful
A common cause
Knowledge lives in heads
A first fix
An onboarding doc the newest person fixes
Growing teams in Kanso
Kanso is built for this stage. Start free with docs and a board; add chat, an inbox and roles when more people join, with Team giving unlimited members in one workspace. Give each ship date a release page. See Kanso for teams.
