# Project management for growing software teams

> What breaks as a software team grows from 5 to 50 people, and the small changes that fix it: owners, written decisions, shared dates and a steady rhythm.

Somewhere between five and fifty people, the way a team coordinated by instinct stops working. Add the least structure that fixes each problem, and no more.

Web page: https://kansohq.app/guides/project-management-for-growing-teams

Updated: 5 October 2026

## 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 |

## 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

1. **Name an owner for everything.** Every card, every decision, every launch. Shared ownership is no ownership.
2. **Write decisions down.** Where, and in one place. A decision in a chat thread is gone in a week.
3. **Make dates visible.** A calendar for each person and a release page for each ship date.
4. **Hold a short weekly planning.** Ten minutes: rank, unblock, remove.
5. **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 |

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 |

## Growing teams in Kanso

Kanso is built for this stage. Start free with [docs](https://kansohq.app/product/docs.md) and a [board](https://kansohq.app/product/boards.md); add [chat](https://kansohq.app/product/chat.md), an [inbox](https://kansohq.app/product/inbox.md) and roles when more people join, with [Team](https://kansohq.app/pricing.md) giving unlimited members in one workspace. Give each ship date a [release page](https://kansohq.app/product/releases.md). See [Kanso for teams](https://kansohq.app/for.md).

## Questions

### When does a software team need project management?

As soon as work is hidden in people’s heads. For many teams that is around five to eight people, when questions that were answered last month are asked again.

### How do you scale a software team from 10 to 50 people?

Name an owner for everything, write decisions down, make dates visible, plan weekly and review how you work every few weeks. Add rules only when a specific problem has happened twice.

### How much process does a growing team need?

The least that fixes the problems you have. Every rule has a cost, so add one when something hurts and remove it when it stops helping.

### Should a growing team change tools?

Only if the current tools no longer show the work, the dates or the decisions. Moving costs time, so fix the habits first and change the tool if the habits do not help.

## Keep reading

- [Project management for large software teams](https://kansohq.app/guides/project-management-for-large-software-teams.md): How to manage software work across many people and teams: clear ownership, one view of cross-team launches, roles, written decisions and the right tools.
- [Project management for software teams, explained](https://kansohq.app/guides/project-management-for-software-teams.md): Project management for software teams in plain words: what to manage, a light system that works at any size, the rhythm to keep and the mistakes to avoid.
- [How to run a retrospective that changes something](https://kansohq.app/guides/how-to-run-a-retrospective.md): A retrospective is only worth it if something changes afterwards. Learn a simple format, how to run it in an hour and how to follow through.
- [Decision record template (ADR) to copy | Kanso](https://kansohq.app/templates/decision-record.md): An architecture decision record (ADR) template with the decision, status, context, consequences and revisit condition. Copy it, or start it in Kanso.
- [Retrospective template for software teams | Kanso](https://kansohq.app/templates/retrospective.md): A retrospective template with what went well, what did not, what we learned and what we will change, each change with an owner. Copy it, or start it in Kanso.
- [Sprint planning template: goal, work and risks | Kanso](https://kansohq.app/templates/sprint-plan.md): A sprint planning template with the sprint goal, committed work, stretch, risks and what is out of scope. Copy it, or start it in Kanso.

## Parts of Kanso used

- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.
- [Kanso Releases](https://kansohq.app/product/releases.md): A release page gathers the work behind one date into sections, with an owner, a due date and a status on every line.
- [Kanso Chat](https://kansohq.app/product/chat.md): Channels and direct messages that link straight to the task, page or release being discussed.

[Kanso home, with plans and prices](https://kansohq.app/index.md)