# Project management for large software teams

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

Past a few dozen people, the work is not harder to do but harder to see. What matters is clear ownership, one shared view of launches that cross teams and decisions that are written down.

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

Updated: 5 October 2026

## What changes as a team gets large

With five people, everyone knows what everyone is doing. With fifty, nobody does, and every missing piece of knowledge is paid for in meetings. Three things tend to break first: **ownership** becomes unclear, **dependencies** between teams surprise people, and **information** scatters across too many tools.

## Principles that hold up

1. **Small teams with clear ownership.** Split a large group into teams that each own an area end to end. Every task and every decision has one named owner.
2. **One way to describe work.** The same words for status, the same priorities and the same definition of done in every team, so a card means the same thing everywhere.
3. **One view of each cross-team launch.** A single page for the release, with a section per team, so nobody has to ask product, engineering and support separately where things stand.
4. **Decisions in writing.** Short [decision records](https://kansohq.app/guides/what-is-an-adr.md) mean new people and other teams can read why, instead of asking.
5. **Asynchronous by default.** Channels per area and written updates, with meetings kept for decisions. See [remote and async teams](https://kansohq.app/guides/remote-software-teams.md).
6. **Roles that fit.** Some people manage the workspace, some edit, and some only read: clients, auditors and other teams.

## Planning across teams

The release is where teams meet. Set one date, give each team a section and require every line to have an owner, a due date and a status. Review blockers daily near the end. Dependencies between teams should be written on the cards: “blocked by” a card on another board is a fact everyone can see.

**One release, four teams**

> **Platform:** migrate the notification queue (blocks Product’s alerts).
> **Product:** finish alert settings (blocked by Platform).
> **QA:** run the full test plan on the release build.
> **Support and go-to-market:** release notes, help pages and a briefing for support.

## Visibility without more meetings

- Use saved views and filters (by team, by owner, blocked, overdue) instead of status reports.
- Let the board be the status. If a card’s state is wrong, that is the problem to fix.
- Write a short update for each release on the release page, not a separate document.

## What to ask of a tool at scale

- Roles and permissions, including guests who can look but not edit.
- Unlimited members in one workspace, so you are not counting seats per team.
- Search that finds the thing across projects.
- A backup you can take and restore, and a way to get your data out.
- A vendor that will answer security and procurement questions, and quote for an organization.

## A planning rhythm across teams

| How often | What happens | Who is there |
| --- | --- | --- |
| Each quarter | Teams share what they intend to build and flag dependencies on other teams | Leads from every team |
| Each release | One page for the date, a section per team, owners and blockers reviewed | The release owner and a lead from each team |
| Each week | Each team plans its own week and posts blockers that need another team | Each team on its own |
| Each month | A short look at what shipped and what slipped, and why | Leads, with a written summary for everyone |

The rhythm exists to surface dependencies early. A team that learns in the last week that it needs something from another team has learned too late.

## Governance without bureaucracy

- Decide a few things centrally: the words for status and priority, the definition of done and who may change a release date. Leave the rest to the teams.
- Write the rules down in one place, and make each rule say what problem it solves.
- Review the rules once a quarter. A rule that nobody can explain should go.
- Give teams a way to ask for an exception, and say yes often. Teams that cannot ask will work around.

## Bringing a new team onto the shared tool

1. Pick a team with a real release coming up, so the tool is used for a real reason.
2. Set up their projects, boards and roles together, in one session.
3. Move the current work across in one go, so the first day is accurate.
4. Ask them after two weeks what is missing, and fix the top item.
5. Only then ask the next team.

## Large teams in Kanso

[Kanso Team](https://kansohq.app/pricing.md) gives a workspace unlimited members, with roles (owner, admin, member and guest), chat, an inbox and the ability to assign work across every board. A [release page](https://kansohq.app/product/releases.md) gathers one date’s work into sections for each team, and channels in [chat](https://kansohq.app/product/chat.md) link to the tasks they talk about. Enterprise is quoted for the organization on annual terms. Kanso is a young product: for a large group, the sensible way to start is with one team and one real release. See [Kanso for teams](https://kansohq.app/for.md).

## Questions

### How do you manage a large software team?

Split it into teams that each own an area end to end, give every task and decision one owner, use one shared way to describe work, and keep one view of each launch that crosses teams.

### What project management tool works for large software teams?

One with roles and permissions, unlimited members, good search, a way to see cross-team launches and an export. Try it with one team on one real release before rolling it out.

### How do you coordinate several teams on one release?

Set one date, give each team a section on a shared release page, give every line an owner, a due date and a status, and write dependencies on the cards so blockers are visible.

### How do large teams avoid too many meetings?

Make written updates and the board the default source of status, use channels per area, and keep meetings for decisions and for problems that need talking through.

## Keep reading

- [Project management for growing software teams](https://kansohq.app/guides/project-management-for-growing-teams.md): 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.
- [How remote software teams stay in sync](https://kansohq.app/guides/remote-software-teams.md): How remote and distributed software teams stay in sync: write things down, make status visible, use chat well and keep meetings for decisions.
- [How to plan a software release, step by step](https://kansohq.app/guides/how-to-plan-a-software-release.md): Plan a software release in seven steps: fix the date, freeze the scope, split the work by team, track blockers and decide go or no-go. With a checklist.
- [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.
- [Software launch checklist template to copy | Kanso](https://kansohq.app/templates/launch-checklist.md): A software launch checklist template covering product, quality and go-to-market, launch day and after launch. Copy it, or start it in Kanso.
- [Technical design doc template for engineers | Kanso](https://kansohq.app/templates/technical-design.md): A technical design doc template with context, approach, data model, alternatives, trade-offs, rollout and open questions. Copy it, or start it in Kanso.

## Parts of Kanso used

- [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 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 Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release.

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