1. What Is a Team?

A reporting line does not automatically create a team. A manager may have eight direct reports, but those employees may work on unrelated projects, support different customers, use different systems, and rarely depend on one another. That arrangement is better described as a work group or managerial portfolio. A genuine team usually has five characteristics.

1.1 Shared outcomes

The members are collectively responsible for a meaningful result.

Examples include:

Operating a payment platform Improving customer onboarding Delivering a mobile application Managing enterprise accounts Maintaining cloud infrastructure Producing a monthly financial close Operating a regional fulfillment network The result should be more specific than “support the company” and broader than a single temporary task.

1.2 Interdependent work

Members need one another to complete the work. A product engineer may rely on a designer, a product manager, a data specialist, and a platform engineer. An operations team may require coordination among planning, quality, logistics, and customer support. Google’s team-effectiveness research distinguished teams from ordinary work groups partly through this interdependence. Teams plan, solve problems, make decisions, and review progress together in pursuit of a shared objective.

1.3 Defined boundaries

A team must understand:

What it owns What it does not own Which decisions it can make Which systems or customers it supports Which outcomes it is accountable for Where another team’s responsibility begins Without boundaries, every urgent request becomes the team’s problem.

1.4 Persistent membership

Temporary project groups can be useful, but durable teams develop knowledge, trust, working habits, and shared context over time. A well-established team can often outperform a newly assembled group of individually stronger employees because coordination is a learned capability.

1.5 A coherent operating rhythm

A team needs repeatable ways to:

Prioritize work Make decisions Escalate risks Review performance Learn from failures Coordinate dependencies Communicate with stakeholders Without an operating rhythm, the team is forced to reinvent collaboration every week.

2. Why Team Size Matters

There is no universally perfect team size. Nevertheless, size changes how a team behaves. As membership grows, the number of possible communication relationships rises rapidly. A team of four people has six possible one-to-one relationships. A team of eight has 28. A team of twelve has 66. Not every relationship requires constant communication, but the principle remains important: larger groups create more coordination paths, more meetings, more opportunities for information loss, and greater difficulty maintaining shared context. At the opposite extreme, very small teams are fragile.

A team of two may appear efficient until:

One person takes vacation One employee resigns A production incident occurs A major customer escalates A critical system requires maintenance Two priorities become urgent simultaneously The team then becomes a collection of individual bottlenecks rather than a resilient organizational unit.

Team size should balance five forces:

Communication cost Managerial capacity Operational resilience Skill coverage Workload demand The objective is not to make every team identical. The objective is to create teams large enough to be resilient and complete, but small enough to remain understandable and manageable.

3. Why Six to Eight People Is Often a Useful Starting Point

For many engineering organizations, six to eight individual contributors under one manager is a practical steady-state range.

This size can provide:

Sufficient skill diversity Coverage during vacation or illness Multiple perspectives without excessive coordination A viable division of responsibilities Enough people to distribute operational duties Reasonable capacity for mentoring and succession A manageable number of direct reports Larson’s framework recommends six to eight engineers per engineering manager. With fewer than four, managers often become player-coaches who spend significant time performing individual technical work. With more than eight or nine, managers may be reduced to handling escalations and administrative problems, leaving insufficient time for development, strategy, and proactive team improvement. This does not mean every team must contain exactly eight people. A highly specialized research team may function well with four or five experienced members. A standardized customer-operations team may support a wider managerial span. An early-stage startup may temporarily place ten employees under one leader because there is not yet enough organizational scale to create additional management roles.

The value of the six-to-eight range is not mathematical perfection. It creates a reference point against which exceptions can be evaluated. When a team has three people, leaders should ask whether it is too fragile. When a manager has thirteen reports, leaders should ask whether meaningful management is still possible. When an organization has a manager for every two employees, leaders should ask whether management titles are being used as promotions rather than as genuine operating roles.

4. Managerial Span Should Reflect the Nature of the Work

The number of people a manager can effectively support depends on what the manager and employees actually do. McKinsey’s span-of-control research argues against applying one universal ratio across an entire organization. It classifies managers into several archetypes based on how much individual work they perform, how standardized the team’s processes are, how varied the work is, and how independently team members can operate.

4.1 Player-coach managers

A player-coach performs substantial individual work while also managing people.

Examples include:

An early-stage startup CTO who still writes production code A design director who personally leads major client work A legal department head who handles critical negotiations A principal consultant managing a small engagement team A sales leader who personally owns strategic accounts A player-coach may only be able to support three to five reports effectively because the manager’s own execution obligations consume significant capacity. The danger is role ambiguity. Employees may expect coaching and rapid decisions, while the manager is trying to complete individual work. The manager may believe the team has autonomy, while team members believe the manager is unavailable. The organization must explicitly decide how much time the role should devote to management versus execution.

4.2 Coaching managers

A coaching manager owns team outcomes but spends less time performing the team’s daily work.

The manager focuses on:

Developing people Removing obstacles Improving processes Coordinating stakeholders Clarifying priorities Reviewing important decisions Managing performance Planning capacity This manager may effectively support approximately six to eight people, depending on the maturity and complexity of the team.

4.3 Supervisory managers

A supervisor oversees more standardized and repeatable work.

Examples may include:

Transaction-processing teams Customer-service operations Warehousing teams Routine quality-control functions Standardized administrative services When work is clearly defined, employees are well trained, exceptions are limited, and performance is visible, a manager may support a larger number of people.

4.4 Managers of managers

The work changes again when a leader manages other managers.

The leader must:

Coach managers rather than bypass them Align several teams Allocate resources across competing priorities Resolve cross-team problems Develop organizational strategy Improve management quality Build succession plans Represent the organization to senior leadership Larson suggests approximately four to six managers per manager-of-managers. Fewer than four may leave the leader underutilized or tempted to interfere in team-level work. Too many may turn the role into an escalation service with little capacity for organizational improvement.

5. The Managerial Capacity Test

A simple headcount ratio is not enough. Leaders should examine how the manager’s time is actually used.

For every manager, estimate the weekly capacity required for:

One-to-one meetings Performance coaching Career development Team meetings Project reviews Hiring interviews Stakeholder meetings Incident response Planning Written communication Strategy development Cross-functional coordination

Administrative work Personal learning Independent thinking Consider a manager with eight reports. Eight weekly one-to-one meetings may require eight hours. Peer and cross-functional coordination may require another two to four hours. Team rituals may require several additional hours. Interviews, planning meetings, incident reviews, company meetings, and executive updates can quickly consume half the working week. Larson uses a similar calculation to show why a manager of eight engineers can already spend roughly 20 hours per week in meetings and management-related coordination. Beyond that level, employee development and strategic thinking are often the first activities sacrificed. A manager is overloaded when the role regularly forces trade-offs among responsibilities that are all essential.

Common symptoms include:

One-to-one meetings are frequently canceled. Performance problems are addressed late. Employees receive little useful feedback. Career discussions happen only during formal review cycles. The manager acts primarily as an escalation point. Strategic documents remain unfinished. Hiring becomes reactive. High performers receive little attention because struggling employees consume most available time. Cross-team dependencies remain unresolved. The manager works excessive hours to compensate. The correct response may be to reduce the span, appoint a team lead, separate responsibilities, simplify processes, or remove unnecessary coordination demands. It should not automatically be to tell the manager to improve time management.

6. Why Teams Smaller Than Four Are Often Fragile

A group of one, two, or three people may be called a team, but operationally it often behaves like a set of individuals. The distinction matters because organizations assume that teams provide continuity.

A durable team should be able to absorb:

Vacation Illness Parental leave Turnover Training Incidents Shifting priorities Unexpected customer needs Tiny teams have limited redundancy. They may also suffer from concentrated knowledge. One person understands the deployment system. Another owns the customer relationship. A third understands the historical architecture. When one person becomes unavailable, the entire function slows down. Larson argues that groups with fewer than four people are often too fragile to function as genuine teams. Their output is heavily affected by individual schedules and interruptions, and one departure can move the group from productive work back into pure maintenance.

Small groups are not always wrong.

They may be appropriate for:

Early exploration Temporary incubation Research spikes Initial product validation Highly specialized advisory work Short-lived transition periods The mistake is treating a temporary two-person group as a permanently reliable organizational unit. When the function becomes critical, it should either grow, merge with a related team, become supported by a broader platform, or receive explicit protection against operational risk.

7. Why Oversized Teams Become Slow

Large teams can possess enormous talent and still struggle to deliver. The problems usually come from coordination rather than intelligence. Common symptoms of an oversized team Meetings require too many participants. Decisions need repeated explanation. Ownership becomes ambiguous. Smaller internal factions emerge. Employees lose visibility into one another’s work. The manager cannot meaningfully coach everyone. Projects are divided artificially to keep people occupied. Stakeholders do not know whom to contact. More time is spent synchronizing than building.

Individuals feel less accountable for the final result. Large teams also create social loafing risk. When responsibility is widely distributed, each person may feel less personally accountable. At some point, the team should divide into smaller units with clearer ownership. A practical method is to grow an existing team until it contains enough people and leadership capacity to divide safely. Larson recommends growing a team to approximately eight to ten people and then “budding” it into two teams of four or five, rather than creating an empty team and hoping future hiring will eventually make it viable.

The split should follow meaningful boundaries such as:

Customer segment Product journey Technical domain Geographic region Platform responsibility Workflow stage Operational responsibility Business outcome Do not divide a team merely to achieve symmetrical headcount. A poorly designed split can create more dependencies than it removes.

8. The Dependency Cost of Team Design

A team may appear appropriately sized while still being unable to deliver because it depends on too many other teams.

Suppose a product team requires approval or implementation support from:

Security Legal Data engineering Infrastructure Brand Compliance Finance Customer support Architecture Procurement The team may have eight people, but it does not possess eight people’s worth of independent execution capacity. Its real speed is constrained by external queues.

Leaders should therefore measure not only team size, but also dependency load. Useful dependency questions How many other teams must approve a normal change? How many external teams contribute to an average project? How long does the team wait for decisions or services? Which dependencies are recurring? Which dependencies could be eliminated through tooling or training? Which capabilities should be embedded within the team? Which services should become self-service? Which boundaries repeatedly cause incidents or rework? A team with many dependencies may need better interfaces, clearer service expectations, platform capabilities, embedded specialists, or redesigned ownership boundaries. Adding people to the team will not necessarily improve throughput if external waiting time remains the dominant constraint.

9. Assessing Team Health: The Four-State Model

Headcount tells leaders how many people exist. It does not tell them whether the team is succeeding.

A useful assessment model places teams into one of four operating states:

Falling behind Treading water Repaying debt Innovating Larson’s framework applies this continuum to engineering teams, but the underlying logic can be adapted to many functions.

10. State One: Falling Behind

A team is falling behind when new obligations accumulate faster than the team can complete them. The backlog grows every week. Customer complaints increase. Incidents repeat. Deadlines are regularly missed. Employees work hard, but the system continues deteriorating. Typical indicators Incoming demand exceeds completed work. Unplanned work dominates the schedule. Employees are frequently interrupted. Operational incidents recur. Important tasks remain untouched.

Stakeholders escalate constantly. People work overtime without creating lasting improvement. Morale is low. Employee turnover risk rises. Quality declines because everyone is rushing. Managers spend most of their time managing crises. This is not necessarily evidence of poor effort. The team may simply have less capacity than the responsibility requires. Appropriate leadership response The first task is to diagnose the cause of the capacity gap.

Possible causes include:

Insufficient staffing Excessive scope Poor tools Unreliable systems Too many dependencies Underdeveloped skills Constant priority changes Unclear ownership Preventable operational demand Low-quality intake processes Larson’s proposed system response for a genuinely undercapacity team is to add people until the team can at least meet critical demand. However, hiring should not become the default solution to every backlog.

Before hiring, leaders should determine whether the organization is feeding the team unnecessary work or allowing avoidable demand to continue.

Questions include:

Which work can stop? Which requests should be rejected? Which services should be retired? Which manual steps can be automated? Which incidents share the same root cause? Which stakeholders are creating low-value interruptions? Which commitments were made without capacity analysis? A team cannot hire its way out of unlimited demand. Managerial priorities in this state

The manager should:

Reset stakeholder expectations Protect the team from additional commitments Define the minimum critical service level Publicize capacity constraints with evidence Escalate structural problems Celebrate meaningful progress Prevent blame from replacing diagnosis Create a credible recovery plan The manager should not pretend the team can continue accepting every request.

11. State Two: Treading Water

A team that is treading water can complete critical work, but it has little or no capacity for improvement. The system is no longer deteriorating rapidly, yet it is not getting healthier. The team delivers mandatory releases, resolves urgent issues, and keeps essential services running. Technical debt, documentation, automation, training, and architectural improvements continue to wait. Typical indicators Critical work is completed. Most deadlines are met, but only through intense prioritization. Improvement work is repeatedly postponed. The backlog remains stable rather than shrinking. Employees are busy almost all the time. Stakeholders have stopped expecting ambitious improvements. Technical or process debt remains high. The team has no meaningful slack.

Managers frequently move people between priorities. The greatest danger is that this state can look acceptable from outside. The team appears productive. Customers are no longer shouting. Executives may therefore add new work, unaware that the team has no resilience and cannot invest in future productivity. Appropriate leadership response The main intervention is focus. Larson recommends reducing concurrent work so the team can finish more of what it starts and eventually create capacity to repay debt.

This means:

Limiting work in progress Reducing active projects Ranking priorities explicitly Finishing before starting Creating stronger intake controls Assigning clear ownership Removing low-value work Consolidating fragmented initiatives Organizations often confuse high utilization with high productivity. When every employee is assigned to several projects, everyone appears fully occupied. Yet each project suffers from delays, context switching, handoffs, and incomplete decisions. A team with fewer active priorities may deliver more total value because work moves through the system faster.

12. State Three: Repaying Debt

A team enters the debt-repayment state when it can finally address the accumulated friction that previously consumed its capacity.

In engineering, this may include:

Unreliable systems Brittle architecture Slow test suites Poor deployment processes Repeated incidents Outdated dependencies Missing observability Weak documentation Security deficiencies

In other functions, debt may include:

Manual reporting Duplicated workflows Poorly documented processes Outdated contracts Inconsistent customer data Unresolved compliance gaps Weak training Fragmented tools Unclear decision rights Debt is work created by previous shortcuts, accumulated complexity, or prolonged underinvestment. Why debt repayment is difficult Stakeholders often become impatient.

They may ask:

Why are we not launching more features? Why are customers not seeing immediate changes? Why are engineers working on internal systems? Why are we investing in automation when people can do the work manually? Why does this improvement require several months? The manager must connect debt repayment to business outcomes.

Instead of saying, “We are cleaning the architecture,” explain:

Deployment time will fall. Incident frequency should decline. Customer onboarding will become faster. Audit preparation will require less manual work. The team will recover productive capacity. Future products will launch with less risk. Employees will spend less time on repetitive tasks. Appropriate leadership response The system needs protected time. Larson argues that once debt repayment is working, the primary requirement is patience. The compounding effect emerges gradually as each improvement releases capacity for the next improvement.

Leaders should monitor leading indicators such as:

Incident frequency Mean time to recovery Deployment frequency Change failure rate Manual processing hours Repeated customer complaints Cycle time Time spent on unplanned work Number of known high-risk components Employee interruption rates Backlog age A dramatic turnaround may appear sudden, but the visible improvement is often the accumulated result of many ordinary improvements implemented consistently over time.

13. State Four: Innovating

An innovative team is not merely a team producing new ideas. It is a team with enough operational stability, clarity, trust, and discretionary capacity to convert ideas into useful outcomes. Typical indicators Debt remains at a manageable level. Operational incidents are controlled. Most work addresses customer or business opportunities. Employees have time for discovery and experimentation. The team can improve quality while delivering. Stakeholders trust the team. Morale is healthy. The team can respond to change without abandoning all planned work. Learning is continuous.

People understand the purpose and impact of their work. This state is valuable but not permanent. Entropy pulls teams backward. A successful product attracts more users. More users create more support requests. More features create more complexity. New regulations create new obligations. Strong performance attracts additional executive priorities. Unless the team protects its operating capacity, innovation gradually becomes maintenance. Appropriate leadership response The key requirement is slack. Larson recommends preserving enough schedule capacity for quality, learning, and continuous improvement. He also warns that innovative teams must ensure their work is visibly valuable, or they risk being perceived as experimental groups producing interesting but commercially irrelevant projects.

Useful practices include:

Reserving capacity for improvement Running small experiments Validating work with customers Connecting technical investments to business value Retiring failed experiments quickly Maintaining operational discipline Preventing every available hour from being allocated Continuing debt repayment before problems become emergencies Slack is not laziness. It is the reserve capacity that allows the team to absorb uncertainty, think clearly, improve systems, and respond intelligently to opportunity.

14. Do Not Separate Innovators From Maintainers Without Careful Thought

A common organizational response to a struggling team is to create a new “innovation team.” The original team continues maintaining the existing system, while the new group receives the exciting work.

This may produce short-term progress, but it can also create two classes of employees:

One group receives visibility, experimentation, and career-building assignments. The other group handles outages, legacy systems, support obligations, and technical debt. The maintenance team becomes demoralized. The innovation team lacks operational context. New products may be designed without understanding historical constraints. When the innovation work eventually enters production, responsibility may be handed back to the maintenance team, creating further resentment. Larson recommends keeping innovation and maintenance together where practical, so teams experience the consequences of their decisions and retain opportunities for learning and meaningful new work. There are valid reasons to create a separate exploration group, particularly when testing an unfamiliar market or technology. But the organization should define: How knowledge will transfer Who will own production operations How the existing team participates How employees rotate between responsibilities

How maintenance work will be valued When the temporary group will dissolve or become permanent

15. Psychological Safety and Team Effectiveness

Correct team size does not guarantee an effective team. A well-sized group can still fail if employees are afraid to speak, unclear about goals, unable to rely on one another, or disconnected from the purpose of their work.

Google’s Project Aristotle identified five important dynamics associated with effective teams:

Psychological safety Dependability Structure and clarity Meaning Impact The research emphasized that interpersonal dynamics and team norms can matter more than assembling employees with the most individually impressive backgrounds. Psychological safety

Employees should be able to:

Admit mistakes Ask basic questions Challenge assumptions Raise risks Request help Offer incomplete ideas Disagree respectfully Psychological safety does not mean avoiding accountability. It means employees can surface information before hidden problems become expensive failures. Research involving agile software teams has also found positive relationships among autonomy, psychological safety, team reflection, and performance. Dependability Team members must reliably complete quality work.

Trust deteriorates when employees repeatedly miss commitments without communication or leave others to absorb unfinished responsibilities. Structure and clarity

People need to understand:

Their role Team goals Decision processes Priority order Success criteria Ownership boundaries Ambiguity creates duplicated work and political conflict. Meaning Employees should see personal value in the work. Meaning may come from learning, craftsmanship, service, mission, relationships, customer impact, or professional growth. Impact The team should understand how its work affects customers, the organization, or society.

Teams lose energy when they cannot connect daily effort to meaningful outcomes.

16. A Practical Team Assessment Scorecard

Organizations need more than subjective impressions. A useful scorecard should combine quantitative measures with qualitative judgment. A. Demand and capacity

Measure:

Incoming work per week or month Completed work Backlog growth Work age Planned versus unplanned work Overtime Utilization Capacity allocated to maintenance Capacity allocated to improvement Capacity allocated to innovation

Key question:

Is demand growing faster than sustainable delivery capacity? B. Delivery flow

Measure:

Cycle time Lead time Work in progress Project completion rate Frequency of priority changes Percentage of blocked work Handoff delays Decision turnaround time

Key question:

Does work move smoothly, or spend most of its life waiting? C. Quality and reliability

Measure:

Defect rates Incident frequency Rework Customer complaints Service-level performance Audit findings Change failure rates Mean time to recovery Recurring root causes

Key question:

Is the team creating durable results or repeatedly repairing its own output? D. Team sustainability

Measure:

Employee turnover Absence trends On-call burden Work outside normal hours Burnout indicators Meeting load Canceled one-to-one meetings Distribution of workload Concentration of critical knowledge

Key question:

Can the team operate this way for another year without harming people or performance? E. Management quality

Assess:

Frequency and quality of feedback Clarity of priorities Career development Performance management Stakeholder alignment Hiring quality Succession planning Delegation Decision quality Time spent strategically versus reactively

Key question:

Does the manager have enough capacity and authority to improve the system? F. Organizational interfaces

Measure:

Number of recurring dependencies External approval time Cross-team escalation frequency Duplicate ownership Service-provider responsiveness Clarity of interfaces Percentage of work blocked externally

Key question:

Is the team constrained mainly by its own capacity or by the surrounding organization? G. Team dynamics

Assess:

Psychological safety Dependability Constructive disagreement Clarity Shared purpose Inclusion Trust Willingness to ask for help Ability to discuss failure openly

Key question:

Can the team tell the truth about its problems?

17. A Monthly Team Health Review

A monthly team review should not become another status meeting. It should help the manager and leadership determine whether the team’s operating state is improving or deteriorating. A useful agenda contains seven questions.

1. What state is the team in?

Choose:

Falling behind Treading water Repaying debt Innovating Support the classification with evidence.

2. What changed since last month?

Review:

Demand Backlog Staffing Incidents Priorities Dependencies Morale Customer sentiment Management capacity

3. What is the team’s primary constraint?

Possible constraints include:

Headcount Skills Focus Technology Process Management Decision rights Dependencies Stakeholder behavior Unclear strategy Select the most important constraint rather than creating a long list.

4. What system-level intervention is required?

Examples:

Hire Reduce scope Eliminate work Merge teams Split a team Add management support Improve tooling Clarify ownership Limit work in progress Protect debt-repayment capacity Redesign an interface

5. What should the team stop doing?

Improvement often requires subtraction. A team cannot prioritize everything.

6. Which indicators will show progress?

Select a small set of leading and lagging indicators.

7. What leadership decision is needed?

Do not finish the review with vague observations. Identify the specific decision, owner, and date.

18. When to Split a Team

A team may be ready to divide when several of the following conditions are present:

Membership has grown beyond manageable coordination. The manager cannot invest meaningfully in each employee. Two distinct missions have emerged. Stakeholders consistently engage with separate subgroups. Work can be divided along durable boundaries. Each proposed team can possess sufficient skills and leadership. Dependencies between the proposed teams can be clearly managed. Both teams will be large enough to remain resilient. A qualified manager or lead exists for each group. Do not split merely because the organization wants to promote someone. Management roles should follow genuine organizational need. Creating tiny teams to manufacture titles leads to excessive layers, confused ownership, and managers without meaningful managerial scope.

19. When to Merge Teams

Teams should be considered for consolidation when:

Each group is too small to be resilient. The teams own highly related systems. Work passes constantly between them. Separate backlogs create priority conflict. Managers duplicate coordination work. Employees have overlapping skills. Neither team has a sustainable mission. The split was based on an outdated product architecture. A shared team would reduce handoffs and improve accountability. Merging should not mean simply placing more people under one manager.

The combined team may need:

A redesigned mission New ownership boundaries Subteam structures A technical or operational lead A unified backlog Clear decision rights Reduced scope elsewhere

20. Common Team-Sizing Mistakes

Mistake 1: Treating headcount as strategy Hiring ten people without redesigning responsibilities may simply create a larger confused team. Mistake 2: Creating teams before people exist An empty box on an organizational chart is not a team. Assigning one person to “lead” a future function may create isolation and unclear expectations. Mistake 3: Promoting people by creating unnecessary management layers Strong individual contributors need career paths that do not require direct reports. Otherwise, the organization creates managers for recognition rather than need. Mistake 4: Assuming everyone is interchangeable Employees possess different knowledge, relationships, skills, and context. Moving three people from another team does not necessarily add three units of usable capacity. Mistake 5: Ignoring onboarding cost

New employees initially consume capacity before they add capacity. Managers and experienced team members must train them. Mistake 6: Measuring activity instead of flow A fully utilized team may still deliver slowly because everyone is juggling several unfinished tasks. Mistake 7: Using reorganization as a substitute for execution Structural change can help, but repeated reorganization destroys context, trust, and momentum. Mistake 8: Expecting immediate results from system changes Team recovery often takes months. Leadership must monitor gradual evidence rather than abandoning the plan prematurely. Mistake 9: Blaming people for permanent overload When workload continually exceeds capacity, individual heroics delay rather than solve the problem. Mistake 10: Removing all slack

A team scheduled to 100 percent of theoretical capacity has no room for incidents, learning, improvement, mentoring, or unexpected opportunity.

21. Team Sizing in Startups

Startups cannot always follow mature-company ratios. One founder may lead engineering, product, recruiting, sales support, and fundraising simultaneously. The goal is not immediate structural perfection. The goal is awareness of temporary compromises. Early stage

At the earliest stage:

Roles overlap. Managers are usually player-coaches. Teams may contain only two or three people. Priorities change frequently. Formal processes are minimal. This can work because communication is direct and the total organization is small. The risk begins when the company grows but operating assumptions remain unchanged. Growth stage

As headcount increases:

Founder access becomes limited. Managers need explicit authority. Teams require durable ownership. Hiring creates onboarding burden. Cross-team dependencies increase. Career expectations emerge. Informal coordination stops scaling. This is when the company should begin applying team-size guardrails. Scale stage

At larger scale, leadership must manage:

Spans and layers Manager quality Platform teams Functional specialization Global coordination Succession Resource allocation Organizational health Team interfaces

The organization should avoid both extremes:

Excessive hierarchy Founder-centered chaos disguised as agility

22. Team Sizing in the Age of AI

Artificial intelligence may change how much work individuals can perform, but it does not eliminate the need for team design.

AI can increase capacity by helping with:

Coding Documentation Research Analysis Customer support Testing Workflow automation Monitoring Reporting Knowledge retrieval However, AI may also increase demand. When production becomes cheaper, organizations may attempt more projects, serve more customers, generate more experiments, and create more software.

The management question therefore remains:

Does AI reduce the team’s constraint, or merely increase the amount of work entering the system? AI may allow a team of six to accomplish what previously required ten people. It may also create new responsibilities involving: Model governance Data quality Security Human review Prompt and workflow design Vendor management Legal compliance Evaluation Reliability Cost control

Organizations should not assume that AI productivity gains automatically justify larger managerial spans.

Managers may still need to:

Coach people Resolve conflict make trade-offs communicate context protect quality develop careers manage ethical risk AI can reduce task effort. It does not remove human complexity.

23. An Implementation Framework for Leaders

Step 1: Map every real team

For each team, record:

Mission Manager Members Size Responsibilities Customers Critical systems On-call obligations Dependencies Current operating state Do not rely only on the official organizational chart. Step 2: Identify structural exceptions

Flag:

Teams with fewer than four people Managers with more than eight knowledge workers Managers with only one or two reports Teams without a clear mission Teams with several unrelated missions Functions dependent on a single employee Teams with unsustainable on-call rotations Managers performing extensive individual work Step 3: Assess work type

Determine whether each manager is primarily:

Player-coach Coach Supervisor Facilitator Coordinator Manager of managers Use the work itself to determine appropriate span. Step 4: Classify team health Place each team into one of the four states. Use data, not reputation. Step 5: Identify the constraint

Determine whether the main problem is:

Capacity Focus Debt Skills Dependencies Management Strategy Tools Ownership Demand control Step 6: Choose the system intervention Avoid applying the same remedy to every team.

A falling-behind team may need capacity or reduced scope. A treading-water team may need fewer concurrent priorities. A debt-repayment team may need protected time. An innovative team may need slack and stronger connection to business value. Step 7: Define transition indicators Establish how leadership will recognize movement to a healthier state. Step 8: Review monthly Structural health should be monitored continuously, not only during annual planning or a crisis.

Key Takeaways

Team design is a leadership responsibility. Poorly designed teams cannot be repaired indefinitely through individual effort. Six to eight people is a useful starting range for many engineering and knowledge-work teams, not a universal law. Managerial span must reflect work complexity, standardization, employee independence, and the manager’s own execution responsibilities. Teams with fewer than four people are often operationally fragile and overly dependent on individuals. Oversized teams create communication, accountability, and management-capacity problems. A team’s true capacity is reduced by dependencies, interruptions, incidents, and operational obligations. Assess teams by operating state: falling behind, treading water, repaying debt, or innovating. Different team states require different interventions. Hiring is not the solution to every problem. Reducing work in progress can improve delivery more effectively than maximizing individual utilization. Debt repayment requires protected time and organizational patience. Innovation depends on stability, slack, clarity, and visible business value. Psychological safety, dependability, clarity, meaning, and impact remain essential regardless of team size.

Reorganizations should address genuine structural problems, not replace patient execution. AI changes task productivity but does not eliminate management, coordination, responsibility, or human complexity. The ethical leader does not ask employees to compensate forever for an operating system designed to fail.

Frequently Asked Questions

What is the ideal team size?

There is no universal ideal. For many engineering and knowledge-work teams, six to eight members is a useful steady-state range. The right number depends on work complexity, operational responsibility, skill requirements, dependencies, managerial capacity, and employee autonomy.

Is a two-person team always a bad idea?

No. A two-person group can be appropriate for exploration, incubation, or a temporary project. It becomes risky when the organization treats it as a permanent, mission-critical capability.

How many direct reports should a manager have?

A player-coach may only be able to support three to five. A coaching manager may support approximately six to eight. A supervisor overseeing standardized work may support more. The work should determine the number.

Why not give a strong manager twelve or fifteen reports?

Some managers can temporarily support large teams, but their role may become reactive. Coaching, development, succession planning, strategy, and proactive improvement often decline as the span grows.

How do I know whether a team needs more people?

Look for sustained evidence that essential demand exceeds sustainable capacity even after unnecessary work, poor prioritization, and preventable interruptions have been addressed.

What is the difference between falling behind and treading water?

A falling-behind team experiences continued deterioration. Its backlog, risk, and customer dissatisfaction grow. A treading-water team can meet critical obligations but cannot improve the system or address accumulated debt.

Can a team innovate while maintaining existing systems?

Yes. In fact, keeping innovation and maintenance together can improve learning and accountability. The team needs explicit capacity allocation and protection from excessive operational demand.

Should technical debt be handled by a separate team?

Usually not as a permanent arrangement. The team creating and operating the system should normally remain accountable for its health. Temporary specialist support may help, but permanent separation can weaken ownership.

How often should team health be reviewed?

Operational indicators may be monitored weekly, while a structured team-health review can occur monthly. Major organizational design decisions may be reviewed quarterly.

Are employee surveys enough to assess a team?

No. Surveys provide useful information about clarity, trust, workload, and psychological safety, but they should be combined with delivery, reliability, backlog, capacity, dependency, and customer data.

Does remote work require smaller teams?

Not necessarily. Google’s team-effectiveness research did not find colocation to be a significant differentiator within its studied teams. However, distributed teams require stronger written communication, documentation, decision records, and intentional coordination.

Will AI reduce the number of people needed on a team?

In some cases, yes. AI may automate or accelerate parts of the work. But organizations should reassess the mission, demand, risks, and managerial burden rather than applying a simple headcount-reduction formula.

Conclusion

The health of an organization can often be understood by examining its teams. Are they large enough to be resilient? Are they small enough to remain coherent? Do managers have enough time to lead? Can employees raise problems honestly? Is work flowing, or merely accumulating? Are teams improving their systems, or surviving through constant heroics? Does every team have a clear mission, or has the organizational chart become a collection of historical compromises? Team sizing is not simply an efficiency calculation. It determines whether employees receive support, whether customers receive reliable service, whether managers can act ethically, whether technical and operational debt is addressed, and whether the organization possesses enough stability to innovate. The strongest leaders do not evaluate teams only by asking whether people are busy. They ask whether the team has been designed to succeed.

They recognize that a group falling behind needs a different intervention from one treading water. They protect teams that are repaying debt. They preserve slack for teams capable of innovation. They resist the temptation to blame individuals for structural failures. They understand that durable improvement may take time. Most importantly, they treat team design as a living management system. Teams grow, split, merge, mature, accumulate debt, recover, and sometimes outlive the missions for which they were created. Effective organizations observe these changes early and adjust deliberately. A well-designed team is more than an efficient production unit. It is a stable environment in which people can develop, tell the truth, solve difficult problems, absorb uncertainty, and create results that no individual could produce alone.

Relevant Articles and Resources

1. How to Size and Assess Teams From an Eng Lead at Stripe, Uber and Digg

First Round Review’s interview with Will Larson presents the original team-sizing guardrails and the four-state framework of falling behind, treading water, repaying debt, and innovating.

2. Understand Team Effectiveness

Google re:Work explains Project Aristotle and its five team-effectiveness dynamics: psychological safety, dependability, structure and clarity, meaning, and impact.

3. How to Identify the Right Spans of Control for Your Organization

McKinsey presents managerial archetypes and explains why managerial span should reflect work complexity and operating context rather than one universal ratio.

4. Psychological Safety in Agile Software Development Teams

This research examines how autonomy, task interdependence, role clarity, psychological safety, reflection, and performance interact within software-development teams.

5. Right Thoughts and Right Action: How to Make Agile Teamwork Effective

This academic work integrates research on general team performance, agile development, and practitioner guidance into a model for effective agile teamwork.

6. Large Teams Have Developed Science and Technology; Small Teams Have Disrupted It

Research analyzing millions of papers, patents, and software products found different patterns of contribution from smaller and larger teams, suggesting that organizations may need both focused small teams and larger development groups for different types of progress.

7. An Elegant Puzzle: Systems of Engineering Management

Will Larson’s book expands on organizational design, engineering management systems, team sizing, technical debt, career development, and scaling technology organizations.

8. High Output Management

Andy Grove’s management classic examines managerial leverage, one-to-one meetings, team performance, organizational structure, and the responsibility of managers to improve the output of the systems they lead.