De auteur betoogt dat het doen van het werk van anderen een krachtige strategie is om systemen te begrijpen, bureaucratie te omzeilen en kritieke doelen te bereiken. Door initiatief te nemen waar anderen falen of weigeren, verkrijgt men niet alleen diepgaande kennis van de organisatie, maar wordt men ook onmisbaar.
Er wordt echter een waarschuwing geplaatst tegen twee vormen van inefficiëntie die hierop lijken:
- Zelf bouwen vs. kopen: Het intern ontwikkelen van software puur omdat het makkelijker is om personeel uit te breiden dan budget te verkrijgen voor externe software.
- Decentralisatie: Het per afdeling implementeren van eigen oplossingen in plaats van een gecentraliseerde service, vaak gedreven door een gebrek aan vertrouwen tussen managers.
Het artikel sluit af met een reflectie over hoe het vermogen om het werk van anderen te kunnen doen essentieel is voor oprichters bij het aannemen en managen van personeel.
Het werk van anderen doen
Ik vind het zeer nuttig om in staat te zijn het werk van anderen te doen. Het helpt je te leren hoe zij werken en waar ze behoefte aan hebben, en het is nog nuttiger wanneer het werk gedaan moet worden, maar zij het zelf niet doen.
Als je iets nieuws hebt gemaakt en degenen voor wie je het hebt gemaakt geen zin hebben om ermee te beginnen, integreer het dan gewoon in hun systeem. Dit werkte voor Intel toen ze hun eerste 32-bit CPU maakten en hun mensen ondersteuning voor die CPU lieten toevoegen in de compiler van Microsoft — ik heb iemand van dat Intel-team ontmoet. Om redenen die mij onbekend zijn, zijn velen geërgerd door het idee om aan het systeem van iemand anders te werken; ze beschouwen het als onnodige liefdadigheid op de werkvloer. Maar deed Intel het werk van Microsoft om het arme, worstelende Microsoft te helpen, of deden ze het om te profiteren van het succes van Microsoft?
Als een manager eigenlijk niets managet, is dit prima, zolang je maar naar zijn mensen kunt gaan en hen effectief kunt aansturen — zonder het zo te noemen en zonder de eer hiervoor op te strijken, natuurlijk. Meestal kun je mensen in zijn organisatie vinden die met je zullen samenwerken, vanuit de theorie dat ze dat zouden moeten doen. Het is waar dat velen van hen allang hebben begrepen dat ze eigenlijk alleen maar orders moeten opvolgen die via de hiërarchie naar beneden komen en verder niets moeten doen, zelfs niet als alles om hen heen in brand staat. Maar sommigen begrijpen dit nooit, en de meeste managers verzuimen om tenminste enkele van deze 'trage leerlingen' te straffen, dus kun jij met hen samenwerken.
Als je een functie nodig hebt in iets dat je gebruikt, is het vaak veel gemakkelijker om iemand te overtuigen jouw patches te accepteren die deze functie toevoegen, dan om het werk gepland te krijgen binnen hun high-velocity Scaled Agile planningsproces. (Natuurlijk is het plan voor dit kwartaal én het volgende al definitief — het is ons goed ingerichte planningsproces waar we onze snelheid aan danken — maar over een paar weken kunnen we de prioriteit hiervan bespreken ten opzichte van de andere functies die relevant zijn voor het kwartaal ná het volgende.) Helaas is het samenvoegen van wijzigingen recentelijk misschien moeilijker geworden, omdat jouw goed doordachte patch op het eerste gezicht niet verschilt van willekeurige LLM-output, maar dat zou geen probleem moeten zijn zodra ze je leren kennen.
Zoals ik al zei, vinden veel mensen dit vreemd en vragen ze zich af waarom je dat zou doen. Ik geloof niet alleen dat 20% van de mensen 80% van het werk doet, maar dat al dit werk zijn uiteindelijke doelen alleen bereikt dankzij de minder dan 5% van de mensen die dingen doen die iemand anders zou moeten doen, maar niet doet. Dit gebeurt om redenen die vanuit het perspectief van de organisatie volkomen legitiem zijn, ook al is het cumulatieve effect van dergelijke legitieme redenen de zekere dood van de hele organisatie.
Ik geloof ook dat je goed beloond zult worden voor het doen van andermans werk in de vele gevallen waarin de organisatie in een toestand verkeert die zo slecht is dat dit nodig is (wat bij de meeste organisaties het geval is), maar nog gezond genoeg is om het uiteindelijk te waarderen (en als dat niet zo is, is de organisatie op haar laatste benen). Je zult ook indirecte beloningen zien door een van de weinige mensen te zijn die daadwerkelijk begrijpen hoe de zaak werkt en wat er nodig is om daar iets gedaan te krijgen.
(Sterker nog, het is het weigeren om in diverse gebieden te duiken waar ik persoonlijk spijt van heb — gebieden waar ik totaal in had kunnen stappen, maar niet deed, vanuit de theorie dat het te ver afliep van wat ik doe, om niet te spreken van saai. Achteraf gezien was dat erg dom. Wanneer je verdrinkt in voorkombare problemen omdat je dacht dat het werk van iemand anders "gewoon gedaan zou worden" terwijl dat overduidelijk niet ging gebeuren, is het niet langer saai, maar dan is het misschien wel te laat.)
Maar niet op deze manier
Er zijn twee schijnbaar gerelateerde zaken die aantrekkelijk lijken voor senior management, maar die eigenlijk slecht kunnen uitpakken. Mensen wijzen deze zaken niet af als een vreemde vorm van liefdadigheid, maar houden er juist van, omdat ze meer personeel (headcount) krijgen. In deze gevallen doe je niet het werk van iemand anders zodat het dankzij jou gedaan wordt, maar doe je iets soortgelijks parallel aan hen, of in plaats van hen.
Het eerste geval is het intern ontwikkelen van iets in plaats van het te kopen, of het gebruiken van een standaard gratis versie. Sommige organisaties kopen te veel in en geven de voorkeur aan externe producten, zelfs als die slecht zijn, omdat "standaarden goed zijn" of omdat het makkelijker is om geld uit te geven dan om mensen aan te nemen. Andere organisaties bouwen echter te veel intern, omdat het daar onmogelijk is om enige uitgave goed te keuren, maar redelijk eenvoudig is om je personeelsbestand uit te breiden. Als we kijken vanuit het perspectief van het verbeteren van de verwachte resultaten, in plaats van het doen van wat in een bepaalde omgeving het gemakkelijkst is, dan is de keuze tussen kopen of bouwen een zeer moeilijke beslissing die per geval verschilt. Je moet veel details leren om eerlijk je eigen tekortkomingen af te wegen tegen die van potentiële leveranciers en de structurele problemen van de markt.
De tweede veelvoorkomende variant is dat, in plaats van een service te centraliseren zodat iedereen in het bedrijf deze gebruikt, elke afdeling het op eigen houtje doet. Afdelingsmanagers houden hiervan omdat ze dan minder afhankelijk zijn van een partij die niet aan hen rapporteert (en niets beangstigt managers meer dan het nodig hebben van mensen die niet aan hen rapporteren). En de mensen die de afdelingsmanagers aansturen, houden ervan omdat ze dan niet hoeven om te gaan met een gecentraliseerde servicedienst die naar verluidt faalt — en hoeven niet uit te zoeken of dat echt waar is en hoe het opgelost moet worden, of dat het een excuus is dat door andere afdelingen is bedacht om hun eigen falen te maskeren. Ook hier geldt: als resultaten je meer aangaan dan wat het gemakkelijkst is voor het senior management, dan is de keuze tussen standaardisatie in het hele bedrijf versus het laten ontwikkelen van eigen varianten door iedereen een moeilijke beslissing.
***
Noot over feedback van Dan Luu
Dank aan Dan Luu voor het nakijken van een concept van dit bericht. Hij merkte op: "Vanaf het begin dacht ik dat het zou gaan over het idee dat oprichters een beter werk leveren als ze weten hoe ze het werk moeten doen van de persoon die ze aannemen, wat verklaart waarom het nuttig is om een bedrijf vanuit het niets op te schalen. Dat zeggen sommige oprichters in ieder geval. Een vriend van mij, een succesvolle tweevoudige oprichter (van wie ik denk dat hij een goed oordeel heeft), zei dat het veel gemakkelijker is om goed aan te nemen als je het werk zelf hebt gedaan, wat redelijk/plausibel klinkt. Ik vermoed dat je dezelfde waarde kunt halen uit het hebben van de juiste vertrouwde mensen die het werk hebben gedaan, maar empirisch gezien lijken mensen vaker fout dan goed te zitten in wie ze vertrouwen."
Dit is logisch voor mij, hoewel ik nog geen eigen bedrijf heb geschaald om dit te kunnen bevestigen. Ik heb het gevoel dat dit werkt bij het laten groeien van een team, zolang je maar weet hoe je mensen moet managen die hun werk beter doen dan jij zou doen. Maar tegen de tijd dat het team groeit naar honderden mensen, zullen er vaak mensen in zitten wiens werk je niet kunt doen. Als het geen team binnen een grotere organisatie is, maar een onafhankelijk bedrijf, zal dit veel sneller gebeuren. Daarom denk ik dat het ontbreken van de complementaire vaardigheid — het managen van mensen wiens werk je onmogelijk zou kunnen doen, wat niet makkelijk is — de beperkende factor zal worden.
Het werk van anderen doen
Ik vind het zeer nuttig om in staat te zijn het werk van anderen te doen. Het helpt je te leren hoe zij werken en waar ze behoefte aan hebben, en het is nog nuttiger wanneer het werk gedaan moet worden, maar zij het zelf niet doen.
Als je iets nieuws hebt gemaakt en degenen voor wie je het hebt gemaakt geen zin hebben om ermee te beginnen, integreer het dan gewoon in hun systeem. Dit werkte voor Intel toen ze hun eerste 32-bit CPU maakten en hun mensen ondersteuning voor die CPU lieten toevoegen in de compiler van Microsoft — ik heb iemand van dat Intel-team ontmoet. Om redenen die mij onbekend zijn, zijn velen geërgerd door het idee om aan het systeem van iemand anders te werken; ze beschouwen het als onnodige liefdadigheid op de werkvloer. Maar deed Intel het werk van Microsoft om het arme, worstelende Microsoft te helpen, of deden ze het om te profiteren van het succes van Microsoft?
Als een manager eigenlijk niets managet, is dit prima, zolang je maar naar zijn mensen kunt gaan en hen effectief kunt aansturen — zonder het zo te noemen en zonder de eer hiervoor op te strijken, natuurlijk. Meestal kun je mensen in zijn organisatie vinden die met je zullen samenwerken, vanuit de theorie dat ze dat zouden moeten doen. Het is waar dat velen van hen allang hebben begrepen dat ze eigenlijk alleen maar orders moeten opvolgen die via de hiërarchie naar beneden komen en verder niets moeten doen, zelfs niet als alles om hen heen in brand staat. Maar sommigen begrijpen dit nooit, en de meeste managers verzuimen om tenminste enkele van deze 'trage leerlingen' te straffen, dus kun jij met hen samenwerken.
Als je een functie nodig hebt in iets dat je gebruikt, is het vaak veel gemakkelijker om iemand te overtuigen jouw patches te accepteren die deze functie toevoegen, dan om het werk gepland te krijgen binnen hun high-velocity Scaled Agile planningsproces. (Natuurlijk is het plan voor dit kwartaal én het volgende al definitief — het is ons goed ingerichte planningsproces waar we onze snelheid aan danken — maar over een paar weken kunnen we de prioriteit hiervan bespreken ten opzichte van de andere functies die relevant zijn voor het kwartaal ná het volgende.) Helaas is het samenvoegen van wijzigingen recentelijk misschien moeilijker geworden, omdat jouw goed doordachte patch op het eerste gezicht niet verschilt van willekeurige LLM-output, maar dat zou geen probleem moeten zijn zodra ze je leren kennen.
Zoals ik al zei, vinden veel mensen dit vreemd en vragen ze zich af waarom je dat zou doen. Ik geloof niet alleen dat 20% van de mensen 80% van het werk doet, maar dat al dit werk zijn uiteindelijke doelen alleen bereikt dankzij de minder dan 5% van de mensen die dingen doen die iemand anders zou moeten doen, maar niet doet. Dit gebeurt om redenen die vanuit het perspectief van de organisatie volkomen legitiem zijn, ook al is het cumulatieve effect van dergelijke legitieme redenen de zekere dood van de hele organisatie.
Ik geloof ook dat je goed beloond zult worden voor het doen van andermans werk in de vele gevallen waarin de organisatie in een toestand verkeert die zo slecht is dat dit nodig is (wat bij de meeste organisaties het geval is), maar nog gezond genoeg is om het uiteindelijk te waarderen (en als dat niet zo is, is de organisatie op haar laatste benen). Je zult ook indirecte beloningen zien door een van de weinige mensen te zijn die daadwerkelijk begrijpen hoe de zaak werkt en wat er nodig is om daar iets gedaan te krijgen.
(Sterker nog, het is het weigeren om in diverse gebieden te duiken waar ik persoonlijk spijt van heb — gebieden waar ik totaal in had kunnen stappen, maar niet deed, vanuit de theorie dat het te ver afliep van wat ik doe, om niet te spreken van saai. Achteraf gezien was dat erg dom. Wanneer je verdrinkt in voorkombare problemen omdat je dacht dat het werk van iemand anders "gewoon gedaan zou worden" terwijl dat overduidelijk niet ging gebeuren, is het niet langer saai, maar dan is het misschien wel te laat.)
Maar niet op deze manier
Er zijn twee schijnbaar gerelateerde zaken die aantrekkelijk lijken voor senior management, maar die eigenlijk slecht kunnen uitpakken. Mensen wijzen deze zaken niet af als een vreemde vorm van liefdadigheid, maar houden er juist van, omdat ze meer personeel (headcount) krijgen. In deze gevallen doe je niet het werk van iemand anders zodat het dankzij jou gedaan wordt, maar doe je iets soortgelijks parallel aan hen, of in plaats van hen.
Het eerste geval is het intern ontwikkelen van iets in plaats van het te kopen, of het gebruiken van een standaard gratis versie. Sommige organisaties kopen te veel in en geven de voorkeur aan externe producten, zelfs als die slecht zijn, omdat "standaarden goed zijn" of omdat het makkelijker is om geld uit te geven dan om mensen aan te nemen. Andere organisaties bouwen echter te veel intern, omdat het daar onmogelijk is om enige uitgave goed te keuren, maar redelijk eenvoudig is om je personeelsbestand uit te breiden. Als we kijken vanuit het perspectief van het verbeteren van de verwachte resultaten, in plaats van het doen van wat in een bepaalde omgeving het gemakkelijkst is, dan is de keuze tussen kopen of bouwen een zeer moeilijke beslissing die per geval verschilt. Je moet veel details leren om eerlijk je eigen tekortkomingen af te wegen tegen die van potentiële leveranciers en de structurele problemen van de markt.
De tweede veelvoorkomende variant is dat, in plaats van een service te centraliseren zodat iedereen in het bedrijf deze gebruikt, elke afdeling het op eigen houtje doet. Afdelingsmanagers houden hiervan omdat ze dan minder afhankelijk zijn van een partij die niet aan hen rapporteert (en niets beangstigt managers meer dan het nodig hebben van mensen die niet aan hen rapporteren). En de mensen die de afdelingsmanagers aansturen, houden ervan omdat ze dan niet hoeven om te gaan met een gecentraliseerde servicedienst die naar verluidt faalt — en hoeven niet uit te zoeken of dat echt waar is en hoe het opgelost moet worden, of dat het een excuus is dat door andere afdelingen is bedacht om hun eigen falen te maskeren. Ook hier geldt: als resultaten je meer aangaan dan wat het gemakkelijkst is voor het senior management, dan is de keuze tussen standaardisatie in het hele bedrijf versus het laten ontwikkelen van eigen varianten door iedereen een moeilijke beslissing.
***
Noot over feedback van Dan Luu
Dank aan Dan Luu voor het nakijken van een concept van dit bericht. Hij merkte op: "Vanaf het begin dacht ik dat het zou gaan over het idee dat oprichters een beter werk leveren als ze weten hoe ze het werk moeten doen van de persoon die ze aannemen, wat verklaart waarom het nuttig is om een bedrijf vanuit het niets op te schalen. Dat zeggen sommige oprichters in ieder geval. Een vriend van mij, een succesvolle tweevoudige oprichter (van wie ik denk dat hij een goed oordeel heeft), zei dat het veel gemakkelijker is om goed aan te nemen als je het werk zelf hebt gedaan, wat redelijk/plausibel klinkt. Ik vermoed dat je dezelfde waarde kunt halen uit het hebben van de juiste vertrouwde mensen die het werk hebben gedaan, maar empirisch gezien lijken mensen vaker fout dan goed te zitten in wie ze vertrouwen."
Dit is logisch voor mij, hoewel ik nog geen eigen bedrijf heb geschaald om dit te kunnen bevestigen. Ik heb het gevoel dat dit werkt bij het laten groeien van een team, zolang je maar weet hoe je mensen moet managen die hun werk beter doen dan jij zou doen. Maar tegen de tijd dat het team groeit naar honderden mensen, zullen er vaak mensen in zitten wiens werk je niet kunt doen. Als het geen team binnen een grotere organisatie is, maar een onafhankelijk bedrijf, zal dit veel sneller gebeuren. Daarom denk ik dat het ontbreken van de complementaire vaardigheid — het managen van mensen wiens werk je onmogelijk zou kunnen doen, wat niet makkelijk is — de beperkende factor zal worden.
Groetjes,