Monday Myth: Small Teams Move Faster

The Factory Without an Assembly Line

In 1989, Volvo opened a car factory at Uddevalla on Sweden's west coast that looked strangely unlike the factories which had come to define twentieth-century manufacturing. There was no great moving assembly line carrying cars through hundreds of narrowly defined operations. Production happened in parallel, with small groups working on stationary vehicles while components arrived in kits corresponding to the work ahead. Depending on how work was organised, groups of roughly five people could assemble substantial functional portions of a vehicle, from approximately a quarter of a car through to complete vehicles. The physical result looked familiar when it eventually left the factory, but the production system behind it challenged almost a century of increasingly specialised industrial labour.

The difference went considerably deeper than removing the conveyor belt. A conventional assembly line decomposes production into increasingly small and repeatable operations. One worker fits a component, another performs the next operation, the vehicle moves forward and thousands of carefully sequenced actions eventually converge upon a finished machine. Uddevalla deliberately experimented in the opposite direction. Workers received extensive training, work cycles expanded from minutes into hours, and groups developed an understanding of functional systems rather than merely memorising short sequences of repetitive operations. Researchers later described the approach as “reflective production”: an attempt to return cognitive understanding to industrial work rather than locating almost all of that understanding in the architecture of the production line.

This matters because the most visible feature of Uddevalla can easily become the least interesting one. The groups were small, certainly, and small groups enjoy obvious advantages in communication and coordination. Yet Uddevalla did not obtain those advantages simply by cutting a large workforce into smaller pieces and giving each piece less to understand. It attempted something considerably more ambitious: reducing the number of people collaborating directly while increasing the coherent portion of the product those people could understand and assemble.

The workforce surrounding a problem became smaller while the territory available to that workforce remained remarkably large.

Small Groups, Large Territory

A handful of people can coordinate with an efficiency that larger groups struggle to reproduce. Information barely requires transportation because much of it already exists inside the group. When someone discovers a problem, colleagues can understand the implications almost immediately. Decisions remain close to observations. Context accumulates collectively rather than being repeatedly reconstructed. Questions that require tickets, documents, meetings, handovers and status mechanisms across a larger organisation can disappear during a short conversation beside the thing being built. This advantage does not require management theory. It follows from the elementary geometry of communication.

Smallness alone, however, explains remarkably little. Put three people in front of a problem they cannot understand beyond their speciality, cannot modify beyond their ownership and cannot follow beyond their assigned responsibility, and their small size has achieved little more than reducing meeting attendance. The interesting characteristic of the Uddevalla experiment was not simply that Volvo divided workers into groups. Industrial production had divided people into groups for generations. It changed what happened inside those boundaries by giving a relatively small number of people a much larger coherent production surface across which knowledge and work could travel.

That distinction separates two organisational designs that look almost identical when represented as boxes. In one, a small group exists because a broad range of skills, knowledge and authority allows fewer people to navigate a large problem. In the other, a small group exists because the problem itself has been divided until each fragment can fit inside a small group. The first reduces the number of people required to traverse complexity while the second reduces the amount of complexity each person needs to traverse. Both can produce a five-person rectangle on an organisation chart, but their information structures, adaptability and dependence on surrounding coordination could hardly differ more.

The Assembly Line Solved Another Problem

None of this makes Uddevalla evidence that mass production took a historical wrong turn. The assembly line conquered manufacturing because it solved a formidable economic problem. When millions of similar products must emerge with predictable quality, cost and timing, broad individual craftsmanship becomes difficult to reproduce at industrial scale. Expertise varies, training takes time, knowledge concentrates in particular people, and output becomes sensitive to individual skill. Industrialisation attacks these sources of variation by transferring part of the knowledge required to make the product from individuals into the production system itself.

Sequence carries knowledge, as do tooling, fixtures, tolerances, standardised work, inspection procedures and the physical arrangement of the factory. The individual operator does not need to understand the entire automobile because generations of industrial engineering have already encoded much of that understanding into the environment in which the operator works. Specialisation therefore represents an economic trade rather than an organisational failure: it exchanges breadth of individual capability for repeatability, throughput and reproducibility. When the problem repeats hundreds of thousands of times and its important uncertainties have already been resolved, the economics can become overwhelming.

Uddevalla investigated another region of this design space. It asked whether industrial production could preserve more human understanding of the complete product without surrendering industrial efficiency entirely. Its eventual closure prevents any serious observer from converting the experiment into a convenient fairy tale about autonomous teams defeating mass production, and its economic and institutional history deserves considerably more respect than that.

The enduring question concerns neither worker happiness nor ideal team size, but something much more fundamental: where should knowledge of the whole system reside, and what happens to productive capability when that knowledge becomes progressively fragmented?

The Twelve-Person Team

Software organisations encounter a curiously similar problem from the opposite direction. Consider an engineering team containing 12 people, assembled because the product area, platform transformation, migration or strategic initiative appears substantial enough to justify serious capacity. 12 engineers offer considerable theoretical productive power, yet they rapidly encounter an unsurprising limitation: 12 people cannot continuously collaborate on the same problems without spending an increasing portion of their capacity maintaining shared context. Discussions involve people who do not require every detail, decisions accumulate participants, planning becomes heavier and the information required to keep everyone aligned begins competing with the work itself.

The modern answer increasingly involves tracks. 3 engineers pursue one initiative, another 3 take a second, 2 concentrate on migration and 4 address the strategic feature. Each group receives enough independence to progress without constantly synchronising with the other members of the team, and local productivity often improves because the arrangement genuinely reduces immediate communication overhead. 3 people can maintain dense shared context, make decisions quickly and understand exactly what occupies their colleagues without needing a sophisticated coordination system to reconstruct that knowledge every morning.

Something peculiar has nevertheless happened. The organisation solved the coordination problem created by 12 people by arranging matters so that those 12 people no longer operate as a coherent productive unit. Operationally, 4 small groups now perform much of the actual work while the 12-person structure persists above them as the nominal team. Calling those groups “tracks” rather than teams does not alter their information topology. The large team remains administratively intact while production has fragmented into smaller units whose efficiency depends partly upon how little they need to know about one another.

The Peculiar Geometry of a Track

This is precisely where the superficial resemblance with Uddevalla collapses. Uddevalla made groups small while attempting to preserve a large coherent territory across which each group could understand and act. Tracks commonly achieve their efficiency through the opposite mechanism. 3 engineers receive a bounded initiative, component, feature or workstream, reducing coordination not only because fewer people interact directly but because fewer people continuously need to understand the surrounding system. Track A develops extraordinarily dense context around A, Track B does the same around B, and Track C becomes increasingly competent inside C. Local knowledge improves while shared knowledge of the complete product gradually thins.

Unfortunately, the software itself has never agreed to respect these boundaries. Track A changes something consumed by C and B discovers an architectural constraint that invalidates an assumption elsewhere. Then 2 groups modify neighbouring parts of the same service while a customer problem crosses several ownership boundaries because customers remain stubbornly unwilling to organise their experience according to our Jira structure. Architecture, data, security, deployment and product behaviour continue forming one interacting system regardless of how elegantly the work has been divided for planning purposes.

The track has therefore not eliminated coordination so much as displaced it. Communication that once happened continuously among people sharing a broad problem now becomes necessary at the boundaries between groups whose internal efficiency increasingly depends upon avoiding exactly that communication. The product remains integrated while the organisation fragments its understanding of it, creating a structural tension that becomes more pronounced as each track becomes better at operating independently.

The Team That Exists Between Meetings

Eventually that tension becomes visible. Engineers discover that they know surprisingly little about what colleagues supposedly belonging to their own team actually build. Technical knowledge concentrates inside tracks, architectural assumptions develop locally and dependencies appear later because nobody recognised them while they were forming. The organisation then responds quite rationally by adding mechanisms capable of transporting information across the boundaries it has created: cross-track synchronisation, demonstrations, architecture sessions, shared refinements, dependency reviews, documentation, more elaborate tickets and technical leadership devoted increasingly to maintaining coherence between independently moving parts.

None of those mechanisms represents stupidity or bureaucracy for its own sake. They compensate for genuine information loss and therefore often become necessary once the production system has acquired this topology. The interesting contradiction lies further upstream. The organisation divided people partly to reduce communication overhead and subsequently constructed a communication system to compensate for the consequences of that division. Coordination became cheaper inside each group by becoming more expensive between groups, while the original twelve-person team increasingly survived as a governance and synchronisation structure wrapped around several actual productive units.

This produces a particularly strange form of organisational isolation. People can belong formally to a substantial team while experiencing almost all meaningful engineering collaboration through 2 or 3 colleagues. They share management, planning cycles, ceremonies and perhaps a backlog with 9 other engineers, yet their daily technical reality occupies a much narrower social and intellectual space. The organisation simultaneously obtains the isolation of small teams and retains much of the coordination machinery required by the large one, which raises an uncomfortable question about what exactly the larger structure continues to provide.

The Legend of the Binôme

Software engineering has always contained stories about tiny groups accomplishing improbable things. 2 engineers disappear into an ugly migration and finish in 6 weeks what a programme discussed for 6 months. 3 rebuild a subsystem that resisted repeated attempts. A pair of experienced developers solve a performance problem whose organisational footprint had gradually become much larger than its technical one. These stories deserve attention because the phenomenon unquestionably exists, but the explanation deserves more suspicion than it usually receives.

The number of people provides the most visible characteristic and therefore attracts causal significance. We remember that 2 engineers solved the problem, notice that 12 people previously struggled with it, and infer that the binôme itself produced the performance. Looking more closely often reveals something different. Those unusually effective pairs and trios frequently possessed extraordinary context and unusually broad authority. They could modify application code, inspect infrastructure, change schemas, question architecture, alter deployment mechanisms, investigate production behaviour, speak directly with users and remove assumptions that had survived principally because nobody previously owned enough of the system to challenge them.

Their ownership followed the problem rather than forcing the problem to respect their ownership. The number of people remained small while the portion of reality available to them became enormous, making them much closer conceptually to Uddevalla's broad production groups than to the narrow tracks now frequently proposed in their name. Organisations remember the binôme because it is easy to count. They remember less readily how much of the machine those 2 people could understand, touch and change without negotiating their way across a succession of organisational boundaries.

AI Rediscovers Half the Story

Artificial intelligence has given this old mythology fresh momentum because it genuinely changes the amount of technical territory an individual engineer can traverse. Modern tools can accelerate investigation of unfamiliar code, generate routine implementation, create tests, analyse failures, interrogate documentation and reduce the friction involved in moving across technologies that previously demanded more specialised knowledge. None of this eliminates expertise, and inflated claims about tenfold productivity deserve scepticism, but the direction matters: AI can plausibly increase the breadth of problems a capable engineer can investigate and manipulate without immediately requiring another specialist.

That development should make the Uddevalla question fascinating again. If technology reduces the cost of crossing technical boundaries, perhaps fewer people can retain coherent understanding across larger portions of a software system. Instead, much of the emerging organisational conversation asks how small the delivery unit can become. Perhaps two engineers assisted by AI can perform work previously requiring four. Perhaps a trinôme becomes the new autonomous delivery unit. Perhaps every initiative receives a tiny AI-augmented strike team whose extraordinary local throughput demonstrates the future of engineering organisation.

The contradiction deserves attention because the technology and the organisation can easily move in opposite directions. AI expands the potential technical territory of the engineer while the track narrows the organisational territory in which that engineer operates. We construct tools capable of increasing breadth and then use their increased productivity to justify further fragmentation, reproducing the visible shape of the legendary binôme while removing one of the conditions that made those binômes remarkable in the first place.

Faster Inside the Boundary

AI can make this mistake harder to detect because local productivity may genuinely improve. A trinôme capable of investigating faster, generating more implementation, producing more tests and explorinFourg alternatives more cheaply can move through its assigned work at a rate that makes every local indicator look encouraging. Yet the surrounding system must still absorb the decisions and changes produced at that higher rate. Architecture, data, security, infrastructure, deployment, product behaviour and assumptions embedded elsewhere continue interacting regardless of how efficiently one group generates code.

Increasing productive capacity inside one track therefore changes the location of the constraint rather than necessarily increasing the throughput of the whole system. Integration can absorb the gain, as can review, validation, architectural reconciliation or decision-making across boundaries. 4 AI-assisted trinômes may each demonstrate extraordinary local productivity while the product itself accelerates surprisingly little, because the rate at which isolated groups can produce change has increased faster than the rate at which the larger system can safely integrate it. The engines produce more power while the transmission connecting them to productive movement remains largely unchanged.

This matters economically because local output remains considerably easier to observe than systemic throughput. Tickets close, pull requests appear, code volume changes and demonstrations show visible progress inside each track. The less visible work of reconciling assumptions, repairing interactions, transporting context and maintaining architectural coherence appears elsewhere and often later. The organisation can therefore record the productivity gain where it originated while recording its cost as somebody else's coordination problem.

The Economics of Artificial Scale

An uncomfortable financial question sits underneath the entire structure. If 12 engineers work most effectively after being divided into 4 groups of 3, the organisation should understand why it constructed a 12-person team in the first place. Sometimes the answer remains entirely legitimate: the product genuinely contains enough parallel work, architecture provides stable boundaries, interfaces remain explicit and groups can operate independently while integrating their output cheaply. Under those conditions the organisation has not merely created tracks. It has designed a production system capable of genuine parallelism, much as mature industrial systems deliberately design interfaces before distributing production across specialised units.

Another possibility deserves equal attention. Organisations sometimes begin with headcount rather than with the topology of the work. Important initiatives attract people, strategic programmes acquire staffing plans and difficult problems feel insufficiently respected when assigned to three engineers, even when those engineers possess everything required to solve them. Additional people then create additional coordination requirements, which encourage subdivision. And subdivision creates information boundaries, which require processes and roles to reconnect information. And those processes consume capacity, making the original initiative appear even larger and more deserving of organisational machinery.

Every individual response can remain perfectly rational while the resulting system becomes increasingly expensive. The organisation adds people to increase capacity, divides them to recover efficiency and adds coordination to recover coherence. The original technical problem may have changed remarkably little while the production system surrounding it has acquired its own architecture, dependencies and operating costs. What initially looked like scale can gradually become the machinery required to manage the consequences of having scaled.

Building the Whole Car

Uddevalla eventually closed, and its history contains enough economic, political and industrial complexity to prevent any honest interpretation from turning it into a simplistic victory of autonomous teams over mass production. That complexity makes the experiment more useful rather than less. Uddevalla investigated the relationship between productive scale and human understanding, asking whether industrial work could retain larger coherent units of knowledge instead of obtaining efficiency principally by decomposing production into increasingly narrow tasks. Its small groups mattered because the production territory around them expanded rather than contracted.

More than 3 decades later, software engineering often travels in the opposite direction. We construct large teams because problems appear large, discover that large groups cannot coordinate efficiently, divide them into tracks, celebrate the speed of the resulting binômes and trinômes, and eventually build coordination machinery to reconnect the people whose productive worlds we deliberately separated. AI now offers the possibility that individual engineers may once again traverse much broader technical territory, yet one of our first organisational instincts appears to involve using that increased capability to make the subdivisions smaller still.

Perhaps future engineering organisations really will contain remarkably small productive groups, and perhaps AI will make that economically inevitable in some domains. The interesting question has never concerned whether 3 people move faster than 12, because 3 people obviously can when the surrounding conditions permit it. The harder question concerns how much of the actual system those three people can understand, influence and own before their work encounters an organisational boundary that exists primarily because somebody previously decided where their track should end.

A mature automobile factory can divide production across hundreds of specialised operations because enormous amounts of knowledge about the finished car already exist in the design of the product and the production system.

Software organisations perform a stranger experiment when they create similarly narrow stations while the architecture, requirements and even the nature of the product remain under discovery. AI may make every one of those stations astonishingly productive, allowing every track to move faster than its predecessors could have imagined, while the unfinished machine continues accumulating quietly in the space between them, waiting for somebody whose territory still includes the whole car.