Team capacity planning

Four people do not give you 160 hours

You have measured your individual capacity. You know the number — not the aspirational number, the real one. If you followed Measure your actual capacity, you tracked your focused output time for a week and arrived at something between 2.5 and 4.5 hours per day. You have learned to plan against that number. Your commitments are calibrated. Your deadlines are realistic.

Then you join a team.

Four people, each capable of 30 hours per week of focused output. Simple addition says the team can produce 120 hours of focused work per week. So you plan a project against 120 hours. You divide the work into streams, assign owners, set milestones. The plan looks clean. The timeline looks achievable. And the project ships late. Not a little late. Thirty to fifty percent late. Every time.

This is not a mystery, and it is not a failure of execution. It is arithmetic. The sum of individual capacities is the theoretical maximum — the number you would get if every person worked in perfect isolation with zero coordination, zero communication, zero dependency on anyone else's output, and zero time spent in meetings. That scenario does not exist. It has never existed. In every team that has ever operated, a significant fraction of each person's capacity is consumed not by the work itself but by the overhead of working together. That overhead is not a bug in the system. It is the cost of coordination. And if you do not subtract it from your plan, the plan is a fantasy.

The mathematics of coordination cost

Fred Brooks understood this before almost anyone else. In 1975, Brooks published The Mythical Man-Month, drawing on his experience managing the development of IBM's OS/360 — one of the largest software projects of its era. The book's central argument is captured in Brooks's Law: adding manpower to a late software project makes it later.

The reason is mathematical. In a team of n people, the number of unique communication channels is n(n-1)/2. Two people have one channel. Three people have three channels. Four people have six. Five have ten. Ten have forty-five. Twenty have one hundred and ninety. The communication overhead grows quadratically while the capacity grows only linearly. At some team size, the overhead of coordinating the additional person exceeds the capacity that person adds. Beyond that point, adding people makes the team slower, not faster.

Brooks was writing about software engineers in the 1970s, but the principle is domain-independent. It applies to a household trying to coordinate meal preparation, a volunteer organization planning an event, a founding team building a startup, and a committee attempting to draft a document. Every person added to a collaborative effort adds both capacity and cost. The net contribution is capacity minus cost, and for large teams or poorly structured teams, that net can be negative.

The practical implication is blunt: if you have a four-person team where each member has 30 hours of weekly focused capacity, your team does not have 120 hours of capacity. It has 120 hours minus the coordination tax. And that tax, across decades of research and real-world measurement, consistently falls between 25% and 50% of theoretical capacity.

The Ringelmann effect: effort decreases as teams grow

The coordination cost is not the only tax. There is a second one, subtler and more uncomfortable. In the 1880s, a French agricultural engineer named Maximilien Ringelmann conducted a series of experiments in which he asked groups of varying sizes to pull on a rope. He measured the force each person exerted. What he found is now called the Ringelmann effect: as the group size increased, the average force exerted per person decreased. Two people pulling together did not produce twice the force of one person. They produced about 93% each. Three people produced about 85% each. Eight people produced about 49% each.

Some of this loss is coordination — it is physically difficult to synchronize eight people pulling at the same instant. But subsequent research by Bibb Latane, Kipling Williams, and Stephen Harkins in the late 1970s demonstrated that a substantial portion of the loss is motivational, not mechanical. They called it social loafing: when people work in a group, they unconsciously reduce their individual effort because individual contributions are harder to identify. The diffusion of responsibility — the sense that "someone else will cover it" — decreases each person's output even when the coordination is perfect.

This is not laziness. It is a documented psychological phenomenon that operates below conscious awareness. The same person who produces four hours of focused output alone will produce three or fewer hours in a team context, even if the team is perfectly organized, because the motivational dynamics of group work reduce individual intensity. The Ringelmann effect and social loafing together mean that team capacity is degraded by two independent mechanisms: coordination overhead (structural) and effort reduction (psychological). Both must be accounted for in planning.

What actually consumes team capacity

If you audit a typical four-person knowledge-work team over a week, the losses fall into five categories. Meetings — stand-ups, planning, retrospectives, one-on-ones, cross-team syncs. A 2022 analysis by Otter.ai and the University of North Carolina found the average worker spends roughly 18 hours per week in meetings. Even at 10 hours per person, that is 40 hours — a full person's capacity — consumed before any output is produced. Communication overhead — emails, Slack threads, reviews, clarifications. Microsoft's 2023 Work Trend Index reported that workers spend 57% of their time communicating and only 43% creating, with volume scaling quadratically as team size grows. Dependency wait times — Person A blocked until Person B finishes, Person C waiting for a decision from Person D. Cycle-time studies consistently show that work items spend more time waiting than being worked on; a 4-hour task routinely has a 3-day lead time. Context switching — Gloria Mark's research at UC Irvine found that it takes an average of 23 minutes to fully regain focus after an interruption; in a four-person team, interruptions are continuous. Alignment and rework — when multiple people work on interconnected pieces, assumptions drift, and the cost of diagnosing and correcting misalignment compounds silently.

Add these together: a four-person team with 120 hours of theoretical focused capacity typically has 70-85 hours of effective capacity. That is a 30-40% coordination tax under good conditions. Under poor conditions — unclear ownership, absent documentation, excessive meetings — the tax climbs to 50% or higher.

Smaller teams pay less tax

J. Richard Hackman spent decades studying teams at Harvard and arrived at a consistent recommendation: keep teams as small as possible for the task. His research showed that most teams are too large, and that even within the four-to-six person range he recommended, larger teams consistently underperformed smaller ones relative to their theoretical capacity advantage. The reason connects directly to Brooks's Law: every additional member increases coordination cost faster than capacity.

Jeff Bezos formalized a similar intuition with Amazon's "two-pizza rule" — no team so large it cannot be fed by two pizzas. A team of six has fifteen communication channels. A team of twelve has sixty-six — more than four times the overhead for only double the theoretical capacity.

The implication for planning: the coordination tax rate is not constant. A two-person team might lose 15-20% to overhead. A ten-person team might lose 40-55%. When you estimate team capacity, the team's size determines the tax bracket.

How to estimate team capacity honestly

Here is a practical protocol for estimating the effective capacity of any team you work with.

Step one: Measure individual capacities. Each team member measures their own focused-output capacity using the protocol from Measure your actual capacity. If full measurement is not possible, use conservative estimates — 3 to 4 hours of focused output per day for knowledge workers, 25 to 30 hours per week. Sum these numbers. This is your theoretical maximum.

Step two: Subtract meeting time. Count the total hours per week that team members spend in team meetings — any meeting that exists because the team exists. Stand-ups, planning, retrospectives, one-on-ones between team members, cross-team syncs. Subtract this from the theoretical maximum.

Step three: Subtract communication overhead. Estimate the time each team member spends per day on team-related communication — Slack threads, emails, pull request reviews, informal questions. A conservative estimate for a well-functioning four-person team is 30-60 minutes per person per day, or 10-20 hours per week for the whole team.

Step four: Subtract dependency wait time. Review recent work and estimate how many hours per week each team member spends blocked — unable to progress because they are waiting for someone else's output, a decision, a review, or an external input. This is often the largest and least visible cost. In teams with long code review cycles, approval chains, or sequential handoffs, dependency wait time can exceed meeting time.

Step five: Subtract context-switching overhead. If team members work on multiple streams or serve multiple teams, estimate the transition cost. A team member who switches contexts three times per day loses roughly an hour to reloading. Over a week, that is five hours per person.

Step six: Apply a Ringelmann discount. Reduce the remaining number by 5-10% to account for the motivational loss inherent in group work. This is uncomfortable to acknowledge, but the research is consistent.

The number you arrive at after these subtractions is your effective team capacity. Use that number — not the theoretical sum — for all planning, commitment, and deadline decisions. If the resulting number feels depressingly low, that is not a signal that the number is wrong. It is a signal that your previous plans were built on a number that did not exist.

Team WIP limits: the constraint that changes everything

Individual WIP limits — constraining the number of tasks you work on simultaneously — were covered earlier in this curriculum. Team WIP limits are even more powerful, because the cost of excess work-in-progress in a team context is amplified by dependencies.

When a team has too much work in progress, every item competes for every person's attention. Dependencies multiply because more active streams mean more handoff points. Context switching increases because people are juggling contributions to multiple streams. And most critically, cycle time — the time from starting a piece of work to finishing it — stretches dramatically. Little's Law (L = lambda times W) tells you that as the number of items in the system increases, the average time each item spends in the system increases proportionally. A team with ten items in progress will complete each one slower than a team with five items in progress, even if both teams have the same capacity.

David Anderson's work on Kanban for knowledge work demonstrated that limiting WIP at the team level reduces cycle time, increases throughput, and — counterintuitively — makes teams faster by making them do less at once. The mechanism is that WIP limits force the team to finish work before starting new work, which reduces dependency chains, reduces context switching, and reduces the alignment burden.

A practical starting point: set your team WIP limit to the number of team members. A four-person team should have no more than four items in active progress at any time. If someone finishes and nothing is ready to pull, they help a teammate with an existing item rather than starting a new one. This feels slow. It is not. It produces faster delivery of completed work because it eliminates the drag of excessive parallelism.

Velocity: let history replace optimism

Scrum teams discovered empirically what Brooks and Ringelmann proved theoretically. Early agile teams estimated sprint capacity by summing individual hours. They consistently overcommitted. The solution was velocity tracking: measure how much the team actually completed in the last several sprints and use that historical average as the basis for the next commitment. Velocity inherently accounts for coordination overhead, because it measures what the team delivered — not what individuals could theoretically produce in isolation. All the taxes are already subtracted.

If your team does not use formal agile methodology, apply the same principle informally. Look at the last three comparable time periods. Count what was actually delivered. Average those numbers. Use the average as your baseline. When the actual number is consistently 40% below what you planned, the plan was wrong, not the team.

The Third Brain

AI tools can transform team capacity planning from guesswork to data-driven estimation. Coordination overhead calculation: feed your team's calendar data and task management timestamps to an AI system and ask it to compute total meeting hours, average communication response times, and the ratio of coordination time to output time per person — producing an empirical tax rate that updates weekly. Dependency bottleneck identification: AI can analyze task management data and surface which handoffs create the longest wait times, making patterns visible that no individual team member can see from their own queue. Team restructuring modeling: given capacity data and dependency patterns, AI can simulate alternative structures — what happens if you split the six-person team into two three-person teams, or replace two meetings with async updates. WIP limit optimization: by correlating team WIP count with cycle time over months, AI can identify the empirical sweet spot where your team delivers fastest.

The critical principle: use AI to make the invisible costs of coordination visible. The coordination tax hides in small increments distributed across every team member's day. No single cost triggers alarm. In aggregate, they consume a third to half of the team's capacity. AI aggregation makes the aggregate visible.

From individual to collective — and back again

The previous sixteen lessons in this phase have focused on your individual capacity — measuring it, understanding its rhythms, allocating it wisely, protecting it from depletion. This lesson extends that framework to the collective case, and the core insight is that collective capacity obeys different and harsher mathematics than individual capacity. You cannot simply scale up your personal capacity planning by multiplying. You must account for the coordination tax, the dependency cost, the communication overhead, and the psychological dynamics of group work.

But here is the bridge to the next lesson: team capacity planning also reveals something about individual capacity that pure self-measurement misses. When you participate in a team, some of your capacity goes to maintaining existing team commitments — status updates, reviews, meetings, alignment conversations. And some of your capacity goes to producing new output. The ratio between maintenance and growth is not fixed, and it is not obvious. Capacity for growth and maintenance examines that ratio directly: how much of your capacity, whether individual or collective, goes to maintaining what already exists versus building something new. Because the most insidious capacity trap is not overcommitment to new work. It is the slow accumulation of maintenance obligations that consume your capacity so gradually you never notice the growth budget shrinking to zero.