Waarom softwareprojecten falen na team-augmentatie

Mensen toevoegen aan een vertraagd softwareproject maakt het later. Fred Brooks observeerde dit in 1975, en decennia ervaring hebben het niet ontkracht. De redenen zijn structureel, niet motivationeel.

Nieuwe mensen hebben onboarding nodig, en die onboarding wordt betaald door je meest ervaren engineers — juist de mensen wiens tijd het meest waardevol is. Communicatie-overhead groeit niet-lineair: een team van vier heeft zes communicatiepaden; een team van acht heeft er achtentwintig. Elke nieuwe persoon voegt coördinatiekosten toe voordat die output toevoegt. Op korte termijn vertraagt augmentatie een team bijna altijd. De vraag is of het zich later terugbetaalt, en met het contractor-injectiemodel gebeurt dat vaak niet.

Staff-augmentatie levert individuen. Software wordt gebouwd door teams. De kloof tussen die twee is waar de meeste augmentatieprojecten stilletjes falen.

Een functionerend team deelt context, conventies, vertrouwen en een mentaal model van het systeem. Het heeft uitgevonden hoe je productief van mening verschilt en hoe je werk overdraagt. Drop drie vreemden in dat team en je krijgt geen groter team — je krijgt het oorspronkelijke team plus een coördinatieprobleem. Drop drie vreemden zonder team, en je krijgt drie mensen die lokaal optimaliseren, inconsistente beslissingen nemen en code produceren waar niemand zich verantwoordelijk voor voelt.

Eigenaarschap is het diepere probleem. Een contractor die wordt ingehuurd om capaciteit toe te voegen, wordt geprikkeld om tickets af te ronden, niet om om het product te geven. Bij iets dubbelzinnigs doen ze het letterlijke ding in plaats van het juiste ding, omdat het juiste ding een oordeel vereist dat ze niet gemachtigd zijn te vellen.

Augmentatie voegt niet alleen coördinatiekosten toe — het belast specifiek je sterkste engineers. Zij schrijven de onboardingdocumentatie, beantwoorden de vragen, reviewen de onbekende code en ruimen de inconsistente beslissingen op. De capaciteit die je dacht te kopen, wordt deels tenietgedaan door de capaciteit die je besteedt om het te absorberen.

In het ergste geval ontstaat een vicieuze cirkel: het project is laat, dus voeg je mensen toe, wat je beste mensen vertraagt, wat het project later maakt, wat je ertoe brengt nog meer mensen toe te voegen. Het aantal mensen stijgt terwijl de snelheid daalt, en het moreel volgt.

Het alternatief is een team binnenhalen dat al als team functioneert en het echt eigenaarschap geven over een resultaat in plaats van een backlog met tickets. Een toegewijd team arriveert met eigen conventies, intern vertrouwen en senior leiderschap, zodat de onboardinglast bij hen ligt, niet bij jou. Ze integreren op het niveau van een op te lossen probleem, niet uit te voeren taken.

Eigenaarschap verandert gedrag. Wanneer een team verantwoordelijk is voor een resultaat — een platform dat schaalt, een compliancefeature die live gaat, een product dat groeit — maakt het de afwegingen die contractors vermijden. Het brengt risico's vroeg aan het licht omdat het risico ook van hen is. Het optimaliseert voor het systeem, niet voor ticketdoorvoer.

Stabiliteit versterkt dit. Een team dat jarenlang blijft, bouwt domeinkennis op die geen enkele hoeveelheid documentatie vervangt. Die kennis is het verschil tussen een wijziging die een dag kost en een die een week kost, en tussen een release die veilig is en een die een incident veroorzaakt.

Team-augmentatie faalt wanneer het software behandelt als een hoeveelheid werk die bemenst moet worden in plaats van een resultaat waar je eigenaar van bent. Meer handen op een worstelend project betekent meestal meer coördinatie, meer inconsistentie en meer belasting voor je beste mensen.

Als je sneller moet, is de betere zet zelden meer individuen. Het is een stabiel, senior team dat eigenaarschap neemt, eerlijk communiceert en lang genoeg blijft om je business te begrijpen. Dat is het model waar wij in geloven — en het model dat consequent betere resultaten oplevert.