Leestijd8 minuten
Geschreven doorFloris Schoenmakers
Modernisering

De wet van Metcalfe te slim af zijn: hoe succesvolle bedrijven ontwikkeling opschalen zonder chaos

Illustratie van kleine figuren die door een doolhof van torens navigeren onder een gloeiende roze vortex, verbonden door een verward neonnetwerk

In mijn professionele leven, werkend aan innovatie- en softwareprojecten, draaide alles altijd om tijd (geld), deadlines en kwaliteit. Omdat softwareontwikkeling een creatief vakgebied is, zijn veel zaken onvoorspelbaar. En wie houdt er van onvoorspelbaarheid? Mijn zoektocht naar een manier om om te gaan met die onvoorspelbaarheid, die vervolgens leidt tot rampzalige projectopleveringen, bracht mij bij de gerenommeerde engineer en softwarearchitect Fred Brooks. Hij zei ooit: "het toevoegen van mankracht aan een vertraagd softwareproject maakt het nog later". De redenen achter dat "feit" zijn deels blootgelegd door Robert Metcalfe, die het de wet van Metcalfe noemde. Ik combineer zijn analyse van communicatiecomplexiteit met onze eigen ervaring bij Eli5, om inzicht te geven in manieren om softwareprojecten beter uit te voeren.

Na het lezen van dit artikel begrijpen lezers dat de exponentiële groei van communicatiecomplexiteit de belangrijkste kracht vormt die softwareprojecten over budget en voorbij deadlines duwt.

Stel het volgende voor: een softwareproject start met vijf toegewijde teamleden, elk briljant binnen het eigen vakgebied. De communicatie verloopt soepel, beslissingen worden snel genomen en de voortgang voelt tastbaar. Dan worden er, gedreven door deadlinedruk of een groeiende scope, drie mensen toegevoegd. Plotseling wordt chaotisch wat eerst beheersbaar voelde. Vergaderingen vermenigvuldigen zich, de voortgang vertraagt en het project dat op schema leek te liggen, begint aan zijn afdaling naar de bekende hel van gemiste deadlines en budgetoverschrijdingen.

Dit scenario speelt zich dagelijks af binnen duizenden organisaties, en toch beschouwen de meeste projectmanagers het als pech in plaats van de onderliggende mechaniek te doorgronden. Mislukkingen van softwareprojecten volgen patronen die besloten liggen in de wiskunde van menselijke communicatie zelf, volgens een principe dat succes steeds onwaarschijnlijker maakt naarmate projecten groeien.

Diagram met netwerken van 2, 5 en 8 knooppunten met respectievelijk 1, 10 en 28 verbindingen, dat de toenemende communicatiecomplexiteit illustreert

In dit artikel behandel ik de drie belangrijkste componenten van communicatiecomplexiteit en menselijke bias die naar mijn mening de voornaamste oorzaken zijn van het mislukken van softwareprojecten.

Deel I: de wet van Metcalfe: het wiskundige fundament van projectcomplexiteit

De wet van Metcalfe, oorspronkelijk geformuleerd door telecompionier Robert Metcalfe in 1980, stelt dat de waarde van een netwerk evenredig is met het kwadraat van het aantal verbonden gebruikers (n²). Toegepast op projectteams legt dit een uitdagende realiteit bloot: terwijl de teamomvang lineair toeneemt, groeit de communicatiecomplexiteit exponentieel.

Een team van twee personen heeft slechts één communicatiekanaal. Met twee extra mensen erbij zijn er al zes kanalen. Bij een nieuwe verdubbeling naar acht personen beheert het team 28 communicatiepaden. Bij tien teamleden betekent dat 45 mogelijke communicatieroutes.

Twee keer zoveel mensen aansturen die allemaal met elkaar communiceren, is niet twee keer zoveel werk. Het is vier keer zoveel. Een project drie keer zo groot maken vermenigvuldigt de communicatie-uitdaging met negen.

De wet van Metcalfe legt de wiskundige groei van complexiteit in communicatiekanalen bloot, en het menselijke element zet die potentiële complexiteit om in operationele uitdagingen.

Stakeholders hebben uiteenlopende communicatievoorkeuren, manieren om informatie te verwerken en verwachtingskaders. Sommigen geven de voorkeur aan gedetailleerde technische documentatie, anderen willen samenvattingen op hoofdlijnen. Sommigen hebben frequente updates nodig, anderen ervaren voortdurende communicatie als storend.

Naarmate het aantal communicatiekanalen exponentieel toeneemt, daalt de kans aanzienlijk dat alle stakeholders dezelfde verwachtingen blijven delen.

Part 2: The inverted U-curve: more communication destroys performance

Recent academic research has discovered an inverted U-shaped relationship between communication network density and project performance. This finding reveals a counterintuitive truth: there's an optimal level of communication, beyond which additional communication actually reduces performance. Increasing the frequency of interactions among members may bring excessive information processing pressure to core members, leading to negative effects of information overload.

Te weinig communicatie leidt tot:

Coördinatiefouten

Ontbrekende requirements

Dubbel werk

Technische incompatibiliteiten

Te veel communicatie veroorzaakt:

Informatie-overbelasting

Besluiteloosheid

Overhead die de productiviteit vernietigt

Communicatieknelpunten

Er bestaat in studies consensus over de correlatie tussen projectsucces en teamgrootte, waarbij kleinere teams consequent beter presteren dan grotere: teams van 5 tot 9 leden hadden de hoogste productiviteit, terwijl grotere teams productiviteitsverlies zagen door communicatie-overhead.

De meeste projectmanagers merken niet dat ze de kritische grens overschrijden totdat het te laat is. Tegen de tijd dat de communicatielast zichtbaar destructief wordt, is het project doorgaans het punt van herstel al voorbij.

Deel 3: De bias van de senior engineer: het overschatten van de opleversnelheid

De gevolgen van communicatie-uitdagingen worden versterkt door een menselijke bias in een activiteit die inherent subjectief is: inschatten wat iemand binnen een bepaald tijdsbestek kan realiseren.

Senior engineers overschatten hun opleveringscapaciteit consequent, ondanks hun uitgebreide ervaring en technische expertise. Deze bias komt voort uit verschillende cognitieve factoren die in complexe teamomgevingen sterker naar voren komen. In de eerste plaats treft de planningsfout zelfs ervaren professionals. Bij het inschatten van de afronding van taken richten senior engineers zich op het best mogelijke scenario en houden ze te weinig rekening met de onvermijdelijke onderbrekingen, afhankelijkheden en randgevallen die tijdens de implementatie opduiken.

De vloek van de expertise versterkt dit probleem. Senior engineers beschikken over diepgaande technische kennis, wat vertrouwen wekt in hun vermogen om problemen snel op te lossen. Dat vertrouwen houdt echter geen rekening met de communicatielast die exponentieel toeneemt met de teamgrootte. Een senior engineer kan de tijd die nodig is om een stuk code te schrijven accuraat inschatten, maar onderschat de tijd die nodig is om af te stemmen met andere teamleden, deel te nemen aan vergaderingen, pull requests te beoordelen en om te gaan met het constante context switchen dat grotere teams vergen.

Door de onderling verbonden aard van moderne softwaresystemen worden individuele schattingen steeds onbetrouwbaarder. Een senior engineer kan de toegewezen module perfect en op tijd afronden, maar vertragingen in afhankelijke componenten, integratie-uitdagingen of veranderende eisen van stakeholders kunnen die schattingen betekenisloos maken. Hoe meer mensen bij een project betrokken zijn, hoe sterker deze onderlinge afhankelijkheden zich vermenigvuldigen, wat leidt tot een cascade van schattingsfouten die zich in de loop van de tijd opstapelen. Wanneer te optimistische tijdschattingen samenkomen met exponentiële communicatiecomplexiteit, worden projectplanningen vanaf het begin fundamenteel onrealistisch.

De weg vooruit: omgaan met beperkingen

De wiskunde van de wet van Metcalfe suggereert dat traditionele benaderingen van softwareprojectmanagement (resources toevoegen, teams opschalen, stakeholders coördineren) fundamentele onverenigbaarheden opleveren met betrouwbare oplevering. Door de exponentiële groei van de communicatiecomplexiteit worden projectproblemen aanzienlijk waarschijnlijker wanneer teams boven de optimale grootte uitgroeien. Het is nodig om te ontwerpen rondom communicatiecomplexiteit in plaats van ertegen te vechten:

Aanvaard exponentiële communicatiekosten als een fundamentele beperking, niet als een oplosbaar probleem.

Ontwerp voor communicatiegrenzen door kernteams die beslissingen nemen onder de kritische drempels te houden.

Deel complexe projecten op in werkelijk onafhankelijke modules met minimale communicatiebehoeften tussen teams.

Breng communicatiehiërarchieën tot stand die volledige netwerkconnectiviteit tussen alle teamleden en stakeholders verhinderen.

Meet de communicatieoverhead expliciet en behandel het als een vroege indicator van projectrisico.

De belangrijkste conclusie is dat communicatiecomplexiteit behandeld moet worden als een structurele beperking in plaats van als een coördinatie-uitdaging, anders zullen softwareprojecten deze patronen met voorspelbare regelmaat blijven tegenkomen.

Tot slot wil ik één eenvoudig voorbeeld laten zien van ons dochterbedrijf Noco.agency, waar ze ingrepen in de exponentiële groei van communicatiekanalen door (bijna) alle groepsvergaderingen te schrappen en over te stappen op asynchrone communicatie als primaire manier van communiceren. Berichten via Slack, maar vooral: updates en voortgang delen via opgenomen video's (vertellen en tonen), zodat het hele team op de hoogte kan blijven zonder de exponentiële vergaderoverhead die traditioneel de productiviteit om zeep helpt.

"Traditionele bedrijven voegen mensen toe en zien de productiviteit instorten. Wij voegden mensen toe en elimineerden de communicatiepatronen die die instorting veroorzaken. Asynchrone video-updates, heldere documentatie en nul onnodige vergaderingen. Het is geen rocket science, maar het werkt”
Ian, CEO van Noco

De eerste stap naar uw modernisering

Softwaremodernisering en architectuurherbouw vormen de kern van Eli5. We halen de complexiteit weg en leveren directe businesswaarde met pragmatische, cloud-native trajecten.

Voordat u besluit of u uw legacysysteem inpakt, een SaaS-product koopt of met AI eigen tools bouwt, hebt u volledig zicht nodig op uw huidige techlandschap.

Wilt u een vrije brainstorm over uw legacystack? Dat is de eerste stap om technische schuld om te zetten in een schaalbare, modulaire toekomst.

Plan een gesprek
Floris Schoenmakers

Meer artikelen

Alle artikelen