“Software development is a team sport,” write Brian Fitzpatrick and Ben Collins-Sussman in their book Team Geek. ¹ The two Googlers, who together started the company’s Chicago engineering offices, capture a valuable but often overlooked insight in their tagline: working effectively as part of a team instead of working alone can significantly improve output quality and morale.

Many engineers and managers are familiar with the risks of large teams, a problem that’s well described in Frederick Brooks’s The Mythical Man-Month. A “man-month” or a “person-month” refers to the amount of work that a person can complete in a month. It’s a myth because a software project that takes one person a year to complete (twelve person-months) can’t have its timeline shortened to a single month simply by staffing the project with a dozen engineers. Each additional engineer on a project incurs both communication and coordination overhead with everyone else on the team. As a result, the time to complete a project doesn’t actually decrease linearly with increased staffing. ² It may even increase, and the notion that “adding manpower to a late software project makes it later” has become known as Brooks’s Law. ³

Unfortunately, managers and technical leads sometimes overcorrect for this problem. They attempt to maximize efficiency by staffing single-person projects, since this would presumably reduce the communication overhead among team members down to zero. Some companies even emphasize in their promotion processes that an engineer has to be the primary owner of a project, which can incentivize engineers to work on solo projects to increase their chances for promotion.

The reality is that just as there are costs to working on large teams, there are a number of risks and downsides to working alone as well:

• Working alone makes it harder to get early and continual design feedback. The earlier that you can get feedback, the less likely that you’ll waste time going down the wrong path and the earlier you’ll know to correct your course. One place where this shows up in software development is that it’s significantly easier for someone to review your code and to give good feedback if they actually work on the same team as you and share the same project context as you. It’s much harder for someone on a different project to give you thoughtful code reviews.

• Working alone reduces learning. Related to the first point, there are fewer people with a shared context to challenge your ideas. Moreover, because a project takes longer to complete, an individual working alone has fewer opportunities to work on a diversity of projects compared with someone working on a team over the same amount of time.

• Working on a team increases motivation. Peer pressure is a powerful force. Particularly if you’re working with people whom you respect and don’t want to let down, the motivation to help your team succeed can override the dips in motivation that you encounter on days when you’re not at your best.

• Working on a team increases the bus factor for a project. The bus factor of a project refers to the number of team members that can be hit by a bus (or gets sick, leaves the company, goes on maternity leave, etc.) before a project comes to a complete halt. ⁴ A higher bus factor reduces risk on a project. It also helps prevent obscure and undocumented shortcuts taken by a single individual and forces team members to spread knowledge and do things in more easily understandable ways.

• Solo projects increase a project’s perceived time requirements, which can be discouraging. People tend to think about time spent on a project in terms of time elapsed and not time invested. Even if you’ve only been working part-time on a project for two months spread out over half a year, it’s hard for you and others within an organization not to think the entire project proceeded slowly.

• Slower project momentum from working alone reduces morale. Project estimation is hard, and projects tend to slip behind schedule. In single-person projects, a single stall can put the project to a halt, just like how in a grocery store with only one checkout line, one problematic customer or one item that needs a price check can put all sales to a temporary halt. With at least one additional person on the project, there can still be some forward momentum.

• The lows of a project are more demoralizing when working alone. Sand traps that you struggle to get out of, monotonous work that you need to grind through, and bugs that seem to defy all understanding become less draining and more bearable when there’s someone else to share the pain with.

• The highs of a project are more motivating when working as a team. Celebrating an achievement with teammates is a great way to boost morale. If you work alone, who are you going to high five when you get something working?

If you’re not careful, one-person projects can lead to reduced engineering quality and lower morale. The lower morale also tends to mean lower employee happiness and consequently can affect retention. Ensuring a minimum team size of two can therefore be extremely beneficial. In any project, there might be one-person tasks, but grouping those tasks thematically so teammates share the same context and are still working together toward shared goals can mitigate many of the above risks.

There will always be more things to do than time to do them, and it can be tempting to just staff a number of one-person teams on orthogonal projects to make some progress on everything. But given the risks of one-person teams, having the discipline to serialize your priorities so that engineers can work together on projects can make everyone better off.

This blog post is adapted from an article I published on Forbes.