Wanneer je je engineeringteam op maat brengt (en wanneer niet).

Tegen dat een founder de woorden hardop uitspreekt, "ik denk dat we te veel hebben aangeworven", weet de rest van de kamer het meestal al 2 kwartalen. De late indicatoren zijn zichtbaar. Burn stijgt, levering niet, en de engineering all-hands heeft een specifieke smaak van beleefde moeheid. Dat zijn niet de signalen die ertoe doen. Dat is het kassaticket.

Waar ik vroeger naar kijk:

De meeting-graaf werd drukker zonder dat de roadmap langer werd

Grotere teams hebben coördinatie nodig. Prima. De vraag is of die coördinatie iets oplevert. Houdt een team van 30 drie keer zoveel meetings als het team van 12 daarvoor, maar past de roadmap nog op één pagina, dan betalen de extra 18 mensen hun eigen overhead en niet veel meer.

Ownership ging van namen naar teams

Kleine teams zeggen "Anna is eigenaar van billing." Grotere teams zeggen "het Payments-team is eigenaar van billing." Die overgang is normaal. Wat niet normaal is: als niemand een beslissing kan noemen die het Payments-team dit kwartaal heeft genomen. Als ownership vervaagde in een organigram maar nooit herkristalliseerde in beslissingen, heb je een team dat geld kost en comités produceert.

Senior engineers stopten met tegenspreken

In een gezond team spreken je senior engineers elkaar en jou tegen. Wanneer ze stoppen, wanneer RFC's zonder pushback worden goedgekeurd en design docs lezen alsof de consensus er al is, zijn ze niet aligned geraakt. Ze hebben stilletjes beslist dat het gevecht de moeite niet meer waard is. Kort daarna beginnen ze te interviewen.

De org groeide sneller dan het klantprofiel

Elk schaalverhaal is een gok dat het klantprofiel breder wordt. Soms gebeurt dat. Vaak niet, en je merkt 18 maanden later dat je een platformteam bouwde voor een product dat 2 klanten wilden. Vergelijk de vorm van je engineeringorganisatie met de vorm van je betalende klantenbestand. Is de organisatie meer gediversifieerd dan je omzet, dan heb je je antwoord.

Wanneer je niet op maat brengt

Snijden is een middel. Niet hét middel.

• Je bent pre-revenue en traag. Traag is niet overbemand. Traag is meestal onduidelijke prioriteiten, een onder-geïnvesteerd platform, of een founder die nog altijd op gevoel productmanagement doet. Mensen wegsnijden lost geen daarvan op; het maakt ze erger.
• Je zit tussen twee rondes. Ben je 90 dagen van een raise en snij je, dan vertel je de markt dat je de vorige ronde niet kon managen. Soms is dat de waarheid en moet je die uitspreken. Meestal niet, en dan loop je gewoon bang.
• Het board vraagt het, maar de CEO twijfelt. Een afbouw die gebeurt omdat het board het vroeg, haalt nooit de juiste mensen eruit. De CEO neemt uiteindelijk afscheid van wie het goedkoopst is om te verliezen, niet van wie zou moeten vertrekken. Doe eerst het werk, bepaal wie zou moeten vertrekken, en voer dan het gesprek met het board.

Het ongemakkelijke stuk

Goed op maat brengen is geen spreadsheet-oefening. Het is een herbouw. Je eindigt met minder mensen, maar ook met duidelijker scopes, een kortere roadmap, en 1 of 2 managers zonder rechtstreekse rapporten. Doe je dat slecht, dan bespaar je wat geld en verlies je je beste engineers. Doe je het goed, dan komt de organisatie er lichter en sneller uit, en, dit stuk verwachten founders niet, gelukkiger.

Lees je dit omdat je redelijk zeker bent dat je het moet doen: waarschijnlijk moet je het doen. En je bent waarschijnlijk al 6 maanden te laat. Dat is niet erg. 6 maanden te laat is nog altijd 10 keer beter dan een jaar te laat.

De uitvoering is een ander probleem dan de beslissing, en daar lopen de meeste plannen vast. In België bepaalt de wet Renault de volgorde. In Nederland zetten WMCO en UWV de klok. Lees wat op jou van toepassing is voor je het plan bouwt, niet erna.

Geschreven vanuit patronen uit eerdere opdrachten. Als iets te specifiek klinkt om algemeen te zijn, is dat de reden.

Dit is het werk dat ik aanneem. Zie op maat brengen op de homepage.