Scaling Teams to the Problem Type

We have all watched a simple project, something one person could knock out in an afternoon, get handed to a ten-person committee, only to watch it instantly dissolve into weeks of alignment meetings. This kind of complexity isn’t a glitch. It’s the system.

Many leaders try adding more gears to the machine to make it more powerful. In reality, adding more gears is usually exactly what makes the whole machine seize. Talent leaders often fall victim to the “Linear Resource Fallacy,” instinctively assuming that adding more bodies to a project scales output proportionally. Psychological studies show that this behavior is often driven by an illusion of group productivity, in which we mistake the positive social buzz of a large committee for actual operational efficiency. By scaling team size past human cognitive limits, architects don’t increase capacity, they merely manufacture corporate comfort and distribute political risk.

If we want to build teams that actually perform, we have to stop designing them based on corporate comfort or legacy org charts. We need to look at first principles: What does the data actually say about how human brains collaborate under stress?

Network scientist Duncan Watts spent years unpacking collective behavior, and his research highlights a massive problem in talent architecture today: collaboration is a tool, not a law. Architect it under the right conditions, and you build speed. Implement it carelessly, and you stall.

Here is what the data tells us about how humans actually work, and how to apply it to your talent architecture.

1. Match Your Organizational Structure to the Problem Type

In one of his studies on group synergy, Duncan Watts demonstrated that teams only outperform individuals when tasks are truly complex and require multi-step problem-solving. For simple tasks, over-assembling a team just adds coordination drag that cancels out any collaborative advantage. To fix this, talent architects can look to the Cynefin Framework to design workflows based on four distinct domains:

Cynefin Framework

2. Design the right team size

When architecting teams, talent leaders often scale size to match the budget rather than human biology. Cognitive science proves that humans have a strict limit on social bandwidth. Data from evolutionary psychologist Robin Dunbar shows that our brains can only maintain active, high-trust collaboration with about 5 to 6 people at a time.

When you scale past that, Metcalfe’s Law kicks in, which states that a network’s potential connections grow exponentially with every person you add. A team of 5 has 10 potential relationships to manage; a team of 10 has 45. Small teams aren’t just convenient, they are neurologically optimal. If you are building teams larger than 6 people for complex work, you are creating a bottleneck!

3. Architect the management layer to incentivize coordination

Corporate hierarchies didn’t arise by accident. They emerged as well-intentioned organizational responses to network complexity. Managers weren’t invented to oppress innovation, they were structural solutions to the high cost of coordination.

Rather than viewing managers through the lens of traditional “people management”, talent architects should view them as system conduits. Research suggests we need to design for a network facilitator model.

By strategically placing managers as communication traffic controllers, you resolve ambiguity quickly. This architecture allows your small delivery teams to stay small, focused, and shielded from collaborative overload even as the overall company scales.

4. Build Structural Interfaces, Not Just Communication Channels

Data from team dynamics expert Eduardo Salas shows that small teams don’t automatically self-synchronize. The communication advantage only happens when talent leaders architect explicit operating norms on clarity on decision rights, concise sharing channels, and defined interface points between teams.

In complex organizational environments, intentional high-trust communication beats frequent but loose interactions every time. Don’t just give teams more chat channels… architect the rules of how they interact.

The Bottom Line

If we want to build resilient organizations, we have to move past inherited org charts and shallow mantras about “more collaboration.” Look at the data, diagnose the type of problem your business is facing, and architect your teams to leverage how employees operate best.

Shad Rogers, Talent Thought Leader

Sources & Further Reading:

  • Duncan J. Watts, Everything Is Obvious (Once You Know the Answer)

  • David J. Snowden & Mary E. Boone, A Leader’s Framework for Decision Making (Harvard Business Review)

  • Robin Dunbar, Neocortex size as a constraint on group size Rob Cross, Robert Rebele, & Adam Grant, Collaborative Overload (Harvard Business Review)

  • Niall Ferguson, The Square and the Tower: Networks and Power

Previous
Previous

Solving the Right Problem