Why Small Squads Outperform Large Armies in Software Projects

A Question

Recently I talked with a friend who runs a startup building a complex education‑industry management system. Their six‑person team (including a designer and a project manager) completed the project in just over two months, without dedicated testers or front‑end developers. When I asked how long it would take our company, I estimated at least six months.

Analyzing the Gap

Their team gathered functional requirements in a single sketch and non‑functional requirements in an Excel sheet, while we would produce a requirements‑analysis report and a detailed specification. Design was minimal; each developer created their own database model and the project manager reviewed them. In contrast, we would deliver low‑fidelity prototypes, high‑fidelity UI designs, architectural and network designs, each undergoing formal reviews that require coordination and scheduling.

During development and testing, the same few developers handled both front‑end and back‑end coding as well as testing. Our approach separates back‑end developers from front‑end work, assigns dedicated QA engineers, tracks bugs in a bug‑management tool, and performs regression testing before release. Although seemingly tedious, these steps consume significant resources.

In the acceptance phase, their whole team is on‑site fixing issues instantly, whereas we collect issues, let QA verify, have developers fix them, then QA re‑validates before the implementation engineer updates the production environment.

Large‑Army Mode

This mode relies on hundreds or thousands of people working under strict processes, regulations, KPIs, and documentation to ensure stable, controllable outcomes. It is common in large software firms (Huawei, IBM) and in heavy‑industry projects (bridges, aerospace, automotive). While it guarantees predictability, it often leads to low efficiency, stifled innovation, and resource waste due to excessive procedures, reviews, and data‑keeping.

Small‑Squad Mode

Since the third industrial revolution, small, loosely‑coupled squads have proven highly effective. Examples include the open‑source voice‑communication platform FreeSwitch (six core developers), Git, Linux, JavaScript, Hadoop, and many other large‑scale systems built by tiny teams. Small squads execute quickly, avoid unnecessary reviews, treat tasks as personal responsibilities, and foster strong innovation.

Advantages of Small Squads

Suitable for large projects: Complex systems can be decomposed into many independent squads, each delivering a modular component.

High execution speed: No formal review gates or resource‑allocation bottlenecks; developers act as owners of their tasks.

Strong innovation: Freedom from rigid processes encourages creative solutions, which is rare in large‑army settings.

A Case Study

Zhang Xiaolong once said a good tool should be unobtrusive and enable users to complete tasks efficiently. He warned against KPI‑driven cultures that force teams to chase metrics rather than focus on product quality. Over‑emphasis on measurable targets can corrupt motivation and hinder genuine product excellence.

Conclusion

When an organization grows beyond 500 people, it should be treated as 50‑100 small squads rather than a single monolithic team. This hybrid approach preserves the benefits of scale while retaining the agility of small squads.

Conway's Law

Mel Conway observed that a system’s architecture mirrors the communication structure of the organization that builds it. Loosely‑coupled organizations tend to produce modular, low‑coupling systems, and vice versa. Inverting Conway’s Law, critical systems that demand modularity push organizations to adopt looser structures.

Although large‑army teams excel in safety‑critical domains (satellite software, nuclear launch control, missile guidance), most everyday software development benefits from small‑squad dynamics.

Amazon’s “two‑pizza team” principle reinforces that even massive companies should limit team size to what two pizzas can feed, emphasizing small‑team collaboration.