The Two-Person Project Rule: Focus, Collaboration, and Sustainable Delivery

A simple and powerful way to keep an engineering team efficient, collaborative, and high-quality is limiting the number of active projects. I’ve been following a straightforward formula:

The Basic Formula

Ideal number of projects = number of people on the team / 2

The idea is that every project should have at least two people involved. That helps avoid risks like individual overload, lack of peer review, context loss, and bottlenecks when someone’s unavailable.

Why two or more people per project works so well

Having at least two engineers on a project brings advantages like

Resilience: one person can go on vacation, have day-offs, get sick, or switch teams - and the project still moves forward.
Knowledge sharing: avoids silos and keeps critical context spread across more than one person. Chances are, you get better and more consistent documentation when isn’t a one-person project.
Code quality: there’s always someone to review, question, or improve a solution.
Better decision-making: collaboration usually leads to more thoughtful and sustainable technical choices.

In short, it helps you avoid the “one-person project” which is fragile, risky, and hard to sustain over time.

Healthy WIP (Work In Progress) Ranges

Healthy WIP ranges bring transparency and help teams stay focused. A good tip is to use the following table:

Range	Description	Project Count
🔹 Ideal	Steady focus and high efficiency	Up to 7 projects
🔸 Risk Zone	Upper limit - be mindful of focus and allocation	8 to 9 projects
🔺 Critical Zone	Spread too thin - lower efficiency and unpredictability	10 or more projects

The project count column is an example based on a 15-person team.

Mapping Risk and Critical Zones

Beyond the ideal scenario, there are moments when a team might need to allocate just one person to a project (unfortunately, it’s not all sunshine and rainbows). While this can be manageable in specific cases, a critical threshold is reached when more than 25% of the team is working solo on separate projects. This often results in constant context switching, decreased quality, slower delivery times, and reduced efficiency.

It’s not just about how many projects are in progress, but how the team’s attention and collaboration are distributed.

Why one-person projects are dangerous

One-person projects have a serious downsides that hurt both delivery and team health

Individual dependency: if that person leaves or takes time off, the project stalls. And even when someone new joins, progress is slow.
Lower quality: no assertive reviews often means more blind spots and suboptimal decisions.
Little context sharing: the knowledge lives in one head, which isn’t sustainable.
Unpredictability: without a teammate, it’s harder to maintain progress and address issues early.
Higher burnout risk: working alone with too much responsibility and no one to lean on increases stress over time.

Final thoughts

Limiting the number of active projects, and making sure no one is working alone isn’t about slowing things down It’s about protecting the long-term rhythm, quality, and health of your team.