Grote teams, kleineteamenergie
Op deze pagina
Om de paar jaar publiceert IEEE Spectrum weer een autopsie van rampzalige IT-mislukkingen1. De nieuwste telt alleen al in de VS meer dan $2 biljoen aan jaarlijkse kosten van softwarefalen. De casussen zijn pijnlijk bekend.
Het Canadese salarissysteem Phoenix zwol op van CA$310M naar $5,1B en liet 70% van de federale werknemers achter met fouten in hun salaris. Het Horizon-systeem van de Britse Post Office stuurde onschuldige mensen naar de gevangenis, terwijl de top bugs toedekte waarvan ze wist dat ze bestonden.
Ik heb gewerkt bij organisaties die op de lijst hadden gestaan als iemand de moeite had genomen ze te beschrijven.
Retrospectives die nergens heen leiden
Projecten lopen uit de hand. Er komt een crunch. Daarna volgt een retrospective met de vraag “wat kunnen devs anders doen?”, nooit het management.
Ik heb in die retrospectives gezeten. Die waarin iedereen weet wat er misging, de scope veranderde drie keer, de deadline stond vast voordat er requirements waren, iemand voegde een manager toe om “te helpen coördineren” en opeens zit je meer in standups dan dat je code schrijft, maar niemand het zegt, want het zeggen betekent toegeven dat de structuur het probleem is.
Voor hoeveel macht middenmanagement heeft over teamindeling en processen, draagt het bijna geen verantwoordelijkheid voor uitkomsten. Je zou miljarden aan uitgaven besparen en de productiviteit enorm verhogen als management kaal was en net als iedereen werd afgerekend.
De belasting van de managementlaag
Grote projecten mislukken niet omdat engineers niet kunnen coderen. Ze mislukken omdat elke managementlaag vertraging toevoegt, verantwoordelijkheid versnippert en prikkels creëert die haaks staan op werkende software opleveren.
Het patroon is voorspelbaar:
Een project krijgt budget. Budget rechtvaardigt headcount. Headcount vraagt om managers. Managers vragen om proces. Proces vraagt om meetings. Meetings vragen om documentatie. Documentatie vraagt om reviewrondes.
Ergens in die keten moest iemand software schrijven.
Elke laag bestaat om de laag eronder te coördineren. Maar coördinatie kost iets: context gaat verloren in de vertaling, beslissingen lopen vertraging op omdat ze op goedkeuring wachten en eigenaarschap lost op in een commissie. Als er iets kapotgaat, zijn er zoveel mensen betrokken dat niemand duidelijk verantwoordelijk is.
Het Phoenix-salarissysteem moest 80.000 salarisregels implementeren. Maar die regels waren het probleem niet. Het probleem was een organisatie waar informatie door zoveel lagen stroomde dat niemand aan de top begreep wat er onderaan echt gebeurde, tot het te laat was.
Waarom kleine teams werken
Kleine teams presteren beter dan grote. Niet omdat ze betere engineers hebben, maar omdat ze dit hebben:
- Korte feedbackloops. Je levert iets op en je ziet de resultaten.
- Duidelijk eigenaarschap. Als er iets kapotgaat, weet iedereen wie het fixt.
- Directe communicatie. Geen stille post via drie lagen management.
Linear haalde een waardering van $1,25B met 100 medewerkers en 2 PM’s. Geen A/B-tests. Geen groeidashboards. Geen sprintplanning. Geen OKR’s voor ICs. Gewoon kleine teams van ontwerpers en engineers die denken als productmensen.
Het product verkoopt zichzelf omdat het werkt. En het werkt omdat er bijna niets zit tussen de mensen die beslissingen nemen en de mensen die code schrijven. Vaak zijn het dezelfde mensen.
Dat is geen toeval. Dat is het punt.
De fout is niet groeien, maar hoe je groeit
De les is niet dat organisaties voor altijd klein moeten blijven. Sommige problemen vragen om schaal.
De fout is naar managementlagen grijpen voordat je ze nodig hebt. Een “director of engineering” aannemen als je 8 engineers hebt. Een “project management office” optuigen omdat twee projecten één keer overlapten. Managers aannemen om managers aan te sturen voordat je hebt bewezen dat je de eerste laag eigenlijk nodig hebt.
Elke laag die je toevoegt is een gok dat de coördinatiekosten opwegen tegen de coördinatiewinst. De meeste organisaties verliezen die gok en weten het niet eens.
Ik schreef hierover vanuit een andere hoek in mijn post over Workforce Engineering bij flowstate2. Het probleem van de meeste technologieleiders is niet dat ze niet weten wat er gebeurt. Het is dat ze systemen hebben gebouwd waarin informatie door zoveel lagen moet reizen dat weten onmogelijk wordt.
Het antwoord is niet meer managers. Het is beter zicht.
Als je moet opschalen voorbij wat één team kan, moet het doel zijn de dynamiek van een klein team te behouden met tooling, in plaats van complexiteit te beheersen met hiërarchie. Maak informatie standaard zichtbaar. Laat teams uitkomsten van begin tot eind bezitten. Geef engineeringleiders de ruimte om rechtstreeks te coördineren.
Bij flowstate bouwen we dat: een Workforce Engineering-platform dat organisaties zicht geeft zonder rapportagehiërarchieën te scheppen. Om blokkades zichtbaar te maken zonder statusmeetings. Om leiderschap op de hoogte te houden zonder het tot flessenhals te maken.
De kans van $2 biljoen
Iedereen weet wat er mis is. Het oplossen vraagt dat wie macht heeft zichzelf beperkt.
Middenmanagement bestaat omdat het de standaard is. Omdat het altijd zo is gedaan. Omdat grote budgetten voelen alsof ze grote teams nodig hebben en grote teams voelen alsof ze lagen nodig hebben.
Maar het bewijs is overweldigend. De organisaties die miljarden verbranden aan mislukte projecten hebben duizenden medewerkers. Degenen die producten opleveren die werken, hebben er vaak tientallen.
Het verschil is geen talent. Het is structuur.
Op een gegeven moment moeten we ophouden andere resultaten te verwachten.