Team Productivity Calculator

It helps with the first step, a high-level analysis, when you’re thinking about changing who works on something: will bringing in more people raise the team’s output, or will getting newcomers up to speed and keeping everyone in sync cost more than they add? It also shows what happens if someone leaves, or if you swap one person for another. If you enter how long a project would take, it also shows when that project would finish.

• Personal projects: moving house, a renovation, cooking for a party, setting up an event, a garden clean-up with friends.
• Work: deciding whether to add someone to a team or project (including one that’s running late), comparing a trainee with an experienced hire, seeing what a team loses when someone leaves, and seeing how large a group can grow before each extra person stops paying off.

Use it as a first filter. It shows whether a change is clearly worth pursuing, clearly not, or too close to call. The final decision still needs further steps, such as a more detailed look at cost and budget, deadlines, the onboarding plan, which tasks can actually run at the same time (the critical path), people’s availability, and quality and risk.

• Don’t feed it hopeful numbers. Estimates made by people who don’t do the work, or who want a particular answer, tend to be too optimistic. In experiments where teams built LEGO models, four-person teams needed 54% more person-minutes than two-person teams, and people consistently underestimated that difference. In data from 594 software projects, estimates were more optimistic the larger the team (Staats, Milkman & Fox, 2012).
• Agree the numbers with experienced people who do the work: how productive a given newcomer really is at the start, how long they take to reach full speed, how much friction there is in the team today, and how much a newcomer adds. The result is only as good as the numbers: garbage in, garbage out.
• Don’t treat the result as a budget, a schedule or a final verdict. The model leaves out money, deadlines and which tasks depend on others (see “What doesn’t this calculator take into account?”).
• Don’t take a poor result as a reason to give up on getting help. It describes the situation as you entered it, and that can often be changed (see the next question).

Not necessarily. Ask what would have to change for the numbers to improve, then try those changes in the calculator to see which ones matter most.

• Make newcomers productive sooner. Write down the answers to the questions every newcomer asks (an FAQ), make short guides or videos they can go back to, prepare practice tasks or small challenges that teach the project step by step, document unintuitive processes, give them a mentor, and have tools and access ready on day one. In a study of new software engineers at Microsoft, mentors, prior knowledge, training and well-chosen first tasks helped them ramp up, while missing documentation and waiting for access slowed them down (Rastogi et al., 2015).
• Reduce friction. Split the work so that small groups or pairs each own a piece, with few hand-offs; make roles clear so nobody waits on anyone else; choose people who are easy to work with; and keep office politics to a minimum. A review of 78 studies found that people put in less effort in groups, but much less so when each person’s contribution can be seen, the task matters to them, or they work with people they value (Karau & Williams, 1993). Google’s study of 180 of its teams found that psychological safety (feeling safe to ask questions and admit mistakes) mattered most to how well a team worked (Google re:Work).
• Bring people in earlier. The start-up cost comes first and is paid back over time, so the earlier someone joins, the more time they have to pay it back. Simulations of late software projects found that, for each project, there is a point in time before which adding enough people can help (Hsia, Hsu & Kung, 1999).

Friction is the output lost because someone else is there: explaining things, clearing up misunderstandings, negotiating, answering questions, checking and fixing each other’s work, extra messages and meetings, waiting for each other and, in physical work, getting in each other’s way.

In the calculator, each person has their own friction: the share of each colleague’s time they cost. Everyone else on the team loses that share. So in a team of 3 where everyone causes 5%, each person loses 2 × 5% = 10% of their time, and the team works like 2.7 people at full productivity. That’s why output is shown in people at full productivity rather than headcount. Newcomers and less experienced people usually cause more friction at first, and less as they settle in.

Some level of friction will never go away. If one mind could control two bodies, they would work in perfect sync and friction would be 0%. Two separate people, however well they get on, will always have some friction, however little: they still need to tell each other what they’re doing, agree on things and sometimes wait for each other. That’s why long-term friction is never zero.

This has been measured for over a century. In 1913 the French engineer Maximilien Ringelmann found that people pulling on a rope in a group each pulled less hard than when alone, and less the larger the group. A 1974 repeat of the experiment, in which the other “team members” only pretended to pull, suggested that much of the drop comes from people easing off in a group, not only from poor coordination (Ringelmann effect). Ringelmann’s summary table shows each worker’s output falling by about the same amount, 7–8 percentage points, with every extra person, which is the straight-line pattern the calculator uses. He didn’t say which task that table came from, and his rope-pulling measurements fell off more gently (Kravitz & Martin, 1986).

To estimate it, ask the experienced people doing the work what share of their working time goes on coordinating with the rest of the team, then divide it by the number of colleagues they coordinate with. That is the long-term friction per person, reached once everyone is experienced. For example, if each person in a team of 4 spends about 15% of their time coordinating with the 3 others, long-term friction is about 15 ÷ 3 = 5% per person. The start value for a newcomer is the share of each colleague’s time that goes on helping them at first. It’s best to agree these numbers with people who have trained newcomers for this kind of work before.

The ranges in the “?” help are our own rules of thumb, not research results: long-term friction of 1–3% for independent work and 5–10% for tightly connected work; at the start, 5–15% for an experienced newcomer and 20–40% for a trainee.

Productivity is how much useful work the person does compared with someone fully productive in this work. The start value applies when they join: a trainee may contribute almost nothing at first (0–10%); someone who has done this kind of work elsewhere may start at 60–90%. The long-term value is where they end up: usually 100%, but it can be lower, for example for someone who will only ever help part of the time.

Time to long-term is how long, from when they join, until each value reaches its long-term level, set separately for productivity and friction. Friction usually fades within weeks, once a newcomer knows the people, the tools and where things are. Productivity can keep growing for much longer: for a simple physical task it may be minutes or hours; for skilled work, months; and a junior growing into a senior role can take years. People already in the team who have fully settled in have 0 for both.

As with friction, these numbers are best agreed with people who have trained newcomers for this kind of work before.

Entering a project length is optional. It’s how long you estimate the project would take with the people already in the team (marked “In the team”), whether or not they are ticked. That sets the size of the project: the work those people would do in that time, including their own friction and anyone still settling in.

The calculator then works out when the ticked people would get the same amount of work done. The chart shows both finish dates (switch between the project and the long-term view above it), and a section about the project shows how much sooner or later it finishes and the project length from which the change pays off.

Without a project length, the result is about the team’s output over time: how far it dips, when it recovers and where it settles.

The costs come first: the newcomer isn’t fully productive yet, and the people already there lose time helping them. The benefits come later, once they’re up to speed. On a short project there isn’t enough time left for the extra output to pay back the start-up cost. The section about the project shows the project length from which the change starts to pay off.

When people join, the team’s output usually dips at first and then rises above where it was. Two moments matter:

• Output catches up: the moment the team’s output is back at its old level. On the chart, it’s where the two lines cross (the dot).
• The dip is covered: later, the moment the extra output has made up for everything lost during the dip, so the team has done as much work in total as it would have done without the change. From then on, it’s ahead.

That second moment is also the shortest project for which the change pays off: a project that would take the current team longer than that finishes sooner with the change; a shorter one finishes later. Sometimes there are two crossings, for example when one useful person joins straight away and a trainee joins a few weeks later; the result then gives both.

The result also says when each newcomer pays off: when the team with them has done as much work in total as it would have without them. Two people who end up equally productive add the same in the long run, but an experienced hire may pay off within weeks and a trainee only after a year.

• Someone leaving now: untick them. The result shows the team without them, compared with the team as it is.
• Someone leaving later (they’ve resigned, or are going back to their own team): enter when in “until”. It applies to both lines on the chart, since it’s going to happen either way, so you can see whether hiring someone covers the gap.
• Someone borrowed for a while: set when they join and when they leave. They help while they’re there, but the team pays the cost of getting them up to speed, and that cost may not be paid back before they go.

The calculator leaves out handover and the knowledge that leaves with a person, so the real cost of someone leaving is usually higher than shown.

In this kind of model, yes. Each person added brings their own output, but everyone loses that person’s friction, so each extra person adds a little less than the one before. At some point, adding one more person lowers the team’s output. For example, if everyone is fully productive and causes 5% friction, a team of 10 works like 10 × (1 − 9 × 5%) = 5.5 people at full productivity; 11 people work like 11 × 0.5 = 5.5; and 12 people work like 12 × 0.45 = 5.4, a little less.

A quick rule when everyone has the same friction: the best size is about (1 + 1 ÷ friction) ÷ 2. At 5% that’s (1 + 20) ÷ 2 ≈ 10 to 11 people. You can try it by adding people to the table and watching how little each extra person adds to the long-term result.

This fits research suggesting that large teams are inefficient. A QSM analysis of 564 software projects of similar size found that teams of more than 20 people finished only about a week sooner than teams of fewer than 5 (8.92 against 9.12 months) (QSM, 2012). The team researcher J. Richard Hackman’s rule of thumb was “no double digits” (Harvard Business Review, 2009).

It’s the time saved divided by the time the project would take with the current team. For example, finishing in 7.46 weeks instead of 8 saves 0.54 weeks, and 0.54 ÷ 8 ≈ 6.7% faster.

Two reasons. Costs need figures that many people don’t have to hand, or would rather not type into a website: salaries, overheads, and what finishing early is worth. And money would make the result look more precise than a simple model can be.

It doesn’t show total effort in person-hours either. That would treat every hour as equal, when an hour of a trainee’s time and an hour of an expert’s are very different: the point of The Mythical Man-Month is that people and months aren’t interchangeable.

To weigh the cost yourself, compare what the people added cost you for the time they’re involved with what finishing sooner, or the extra long-term output, is worth to you. For example, if adding 2 people finishes the project 30 days sooner, they’re on it for 60 days and each costs you $400 a day, finishing a month sooner costs $48,000. Whether that’s worth it depends on the deadline, the revenue or the penalties involved.

• Steps that must happen in order. If part of a project can only be done one step at a time, extra people can’t speed that part up: if 10% of a project is like that, even unlimited help can’t make it more than 10 times faster. Computer scientists know this as Amdahl’s law (1967); project planners call the longest chain of steps that depend on each other the critical path.
• Physical limits. Only so many people fit in a small kitchen or up one ladder.
• How friction grows with the size of the group. Each person added costs everyone a fixed share of their time, so the total cost grows roughly with the number of pairs, as Brooks described: 3 people make 3 pairs, 10 people make 45. Large groups often split into smaller teams to keep that down, which the calculator doesn’t model, so for large additions the result may be too pessimistic.
• Curved learning. Productivity and friction change in straight lines here; in reality people often learn quickly at first and then more slowly.
• Everything else: overtime and tiredness, morale, quality and rework, and money.

You don’t need to, and roles usually work better: “senior developer”, “trainee”, “new designer”. The calculator only needs each person’s numbers.

Names are saved only in your browser, but they are included in share links, and anyone who gets the link can see them. Writing down how productive a named colleague is, or how much friction they cause, can also feel personal if it’s shared. If you do use names, keep the project to yourself or agree it with the people involved.

AI chatbots are good for talking a decision through and for the detailed planning that comes after this first filter. This calculator has some advantages over AI:

• Same numbers, same answer. It follows one fixed, tested model every time. An AI may answer differently each time you ask, especially when its model is updated, or work the numbers out a different way.
• Neutral. It doesn’t pick up on the answer you’re hoping for. AIs can lean towards answers that please you.
• Easy to share and discuss. Everyone sees the same inputs and the same result, so discussions about improving working conditions and the project can focus on the data.
• You can see and play with it instantly. The charts and numbers show the impact of changes in assumptions in real time.
• Private. What you type stays in your browser and isn’t used for anything else.

Several lines of research, going back more than a century, point the same way, with important exceptions:

• Groups lose some of their potential. Ringelmann’s rope-pulling experiments (1913) showed individual effort falling as groups grew. The psychologist Ivan Steiner (1972) described a group’s actual productivity as its potential minus the “process losses” caused by how its members work together. A review of 78 studies found that people reducing their effort in groups (“social loafing”) is a robust effect across tasks and populations (Karau & Williams, 1993).
• Brooks’s law. The best-known version of the idea is “Adding manpower to a late software project makes it later,” from Fred Brooks’s book The Mythical Man-Month (1975). Brooks himself later called it an “outrageous oversimplification” (Wikipedia).
• Larger teams are less efficient, and people underestimate it. In LEGO-building experiments and data from 594 software projects, people underestimated how much extra effort larger teams need (Staats, Milkman & Fox, 2012). A 2005 QSM study reported that a team of 29 people used 191 person-months of effort, against 40 for a team of about 2.5, produced more than six times as many defects, and finished only about 12 days sooner (Computerworld, 2005).
• But adding people can work. Simulations found that adding people to a late software project always raised its cost but didn’t always make it later: delays happened only when enough of the tasks had to be done in sequence, and adding enough people early enough could help (Hsia, Hsu & Kung, 1999). Steve McConnell argued that Brooks’s law mainly applies near the end of a project, and that well-run projects are less affected than chaotic ones (McConnell, 1999).
• Onboarding and team culture make a difference. Mentors, documentation and well-chosen first tasks helped new engineers at Microsoft ramp up (Rastogi et al., 2015). Google found that psychological safety mattered most to its teams’ effectiveness, while team size wasn’t significantly linked to it in that study (Google re:Work).

The calculator’s model is our own simplification of these ideas, with straight-line learning and friction curves. It’s meant to make the trade-off visible, not to predict an exact date.

Your scenarios are saved only in this browser, on this device. Nothing you type is sent to us or to any server, and there’s no account. Clearing your browser’s data deletes your saved scenarios, and other browsers or devices won’t see them.

Share links carry the scenario in the part of the address after “#”, which browsers don’t send to the website’s server. But anyone who has the link can see everything in it, including the names or roles in the table, and the app you send it through (such as email or chat) may keep a copy. If you prefer, use roles such as “trainee” instead of names (see “Should I put real names in?”).

The page loads its layout, chart and font files from a public content delivery network (jsDelivr). Like any website, it can see that the files were loaded, but not your scenarios.

We use Google Analytics to see how the site is used: how many people visit, from which countries and sites, and which features they use (for example, adding a person or opening an example). It never receives anything you type: no names, numbers or results. It only stores a cookie if you accept in the banner; if you decline, Google still receives basic anonymous visit counts without cookies. There are no ads.