Gids voor de Staff Engineer: Het 'uitvinden' van werk

De constante uitdaging is om manieren te vinden om de waarde die ons platform biedt aan de gebruikers van het systeem te vergroten. Een groot deel van de baan van een staff engineer in een platformteam is bepalen wat het team vervolgens moet bouwen — ik noem dat het "uitvinden van werk". Gelukkig zijn de signalen die ons helpen dit werk te inventariseren al aanwezig. Deze komen uit vier richtingen: van de systemen, van de gebruikers, van de organisatie en van de industrie. Wat volgt is een gids voor het interpreteren van elk van deze signalen.

Signalen vanuit het systeem

Crash-gestuurde ontdekking

Crashes en de bijbehorende postmortems zijn, mits correct uitgevoerd, duidelijke signalen die aangeven wat er gerepareerd of vervangen moet worden. Het is zeldzaam dat postmortems direct wijzen naar iets nieuws dat gebouwd moet worden, maar dat gebeurt wel als je goed let op hoe gebruikers door crashes werden geraakt, of hoe zij hun processen draaiende hielden terwijl het team een langdurige crash oploste. Teams analyseren zelden patronen over meerdere postmortems heen omdat het een sporadische bron is; zorg dat je het grote geheel niet uit het oog verliest.

Een groot nadeel van crash-gestuurde ontdekking is dat het het team bevoordeelt richting de luidste en meest recente fouten, in plaats van naar de grootste kansen. Bovendien is het een maximale 'lagging indicator' (een indicator die achterloopt op de feiten).

Kosten

Kosten, uitgedrukt in geld, zijn een overduidelijk signaal. De cloudrekening fungeert als vervanging voor een ontbrekende omzetdoelstelling. Maar stop niet bij de oppervlakte; ga verder dan het optimaliseren van een databasequery of het onderzoeken van kosten voor inter-VPC-verkeer. Bekijk de winst- en verliesrekening van je business unit als die beschikbaar is, of bekijk de leverancierscontracten en specifieke posten op de cloudrekening.

Onderzoek voor elk kostencentrum hoe het het team ten goede komt om die functie te "outsourcen", en wat het zou betekenen om dit juist binnen het eigen teamscope te trekken. Deze analyse werkt ook de andere kant op: zaken die nu in scope zijn, maar beter uitbesteed kunnen worden aan een leverancier, een cloud-dienst of een ander team. De kernles hier is: de keuze tussen kopen of bouwen (buy-versus-build) is GEEN eenmalige beslissing; je mag deze herzien naarmate de scope, de teamsamenstelling, de technologie en de markten verschuiven.

Eigen 'toil'

Dit is de andere vorm van kosten — onzichtbaar voor velen, soms zelfs voor degenen die het werk uitvoeren. Elk team heeft te maken met toil (handmatig, repetitief werk), en dit wordt bijna nooit geprioriteerd. Toil is een belangrijk signaal dat er werk is dat ontdekt moet worden. De valkuil is echter: jouw toil is niet per se de toil van je gebruikers. Het oplossen van de eerste verbetert de interne economie, terwijl het oplossen van de tweede de gebruikerservaring verbetert.

Signalen vanuit de gebruikers

Continue ontdekking

Ik heb in het verleden betoogd dat 'gevangen' gebruikers niet de beste visie hebben op de ideale staat van tooling, en dat een overmatige afhankelijkheid van gebruikersinterviews een plaag is voor platform-productmanagement. In essentie zeg ik hiermee: als je mensen vraagt wat ze willen, zullen ze vragen om "snellere paarden". Ik geloof nog steeds dat dit waar is, maar dat is geen excuus om niet met je gebruikers te praten. Continue ontdekking betekent het voeren van een voortdurend gesprek:

Spreek met $N$ gebruikers per week/maand/kwartaal. Stel hen vragen in de trant van:

• Kun je me meenemen door de meest recente taak die je hebt uitgevoerd waarbij je het platform hebt gebruikt?
• Wat waren je drie grootste pijnpunten bij het gebruik van het platform?
• Wat zou het voor je betekenen als we die pijnpunten zouden oplossen?
• Wie heeft nog meer hetzelfde probleem?

Ondervraag hun pijnpunten. Besef dat bijna elk echt probleem al een 'hack' heeft; als er geen hack is, is de pijn waarschijnlijk niet acuut genoeg. Weerleg hun voorgestelde oplossingen. Probeer te begrijpen waarom ze die oplossingen willen en of die oplossingen beperkt worden door het huidige ontwerp. Documenteer de pijnpunten en indexeer ze op basis van hoe vaak ze worden genoemd.

Kortom: gebruikersinterviews moeten gericht blijven op het gezamenlijk begrijpen van de probleemruimte. Het ontwerpen van de oplossingsruimte is een kwestie voor een ander forum.

Overbelaste use-cases

Dit is mijn favoriete heuristiek. Sommige platforms bezitten een serendipiteit: gebruikers dwingen ze in een rol voor use-cases waarvoor ze nooit zijn ontworpen. Besteed tijd aan het begrijpen waarom gebruikers liever jouw platform gebruiken om hun probleem op te lossen in plaats van alternatieven, ook al was het platform daar niet voor bedoeld. Beschouw overbelaste use-cases als prototypes die je gebruikers voor je hebben gebouwd, en bepaal welke daarvan de moeite waard zijn om officieel te integreren. De lakmoesproef voor integratie is simpel: wie van je andere gebruikers heeft hetzelfde probleem?

Partner-to-Prototype

Overbelaste use-cases worden achteraf ontdekt. Partner-to-prototype is hetzelfde, maar dan bewust ingericht: jouw team en de gebruikers werken samen om een prototype op het platform te bouwen dat hun probleem kan oplossen. Een prototype is geen belofte dat de feature onderdeel wordt van het platform; het is simpelweg een gezamenlijke exploratie. De lakmoesproef voor integratie blijft hetzelfde: wie van je andere gebruikers heeft hetzelfde probleem?

Signalen vanuit de organisatie

OKR's

Dit is een overduidelijk signaal. Als je team een OKR (Objective and Key Result) heeft gesteld of gekregen, heb je dit stuk werk al 'uitgevonden'. Gefeliciteerd! Op naar de volgende.

De heuristiek van de herhalende manager

Deze is simpel en soms effectief: als je je manager (of diens manager, of hogerop) twee keer in één week over hetzelfde onderwerp hoort praten, is er waarschijnlijk een onbehandelde zorg achter. Dit is een goede reden om aantekeningen te maken tijdens 1-op-1 gesprekken. Naar mijn mening is dit de zwakste manier om werk uit te vinden. De reden: hoe hoger in de hiërarchie, hoe verder men van de gebruikers af staat, en hoe groter de kans dat je bouwt op basis van de HiPPO (Highest Paid Person’s Opinion).

Migratie-residu

Elke grote wijziging aan het platform vereist een migratie. Iedereen die een kritieke migratie heeft geleid, weet dat de adoptie een 'fat tail' heeft (vergelijkbaar met de curve uit Crossing the Chasm). Je hebt je innovators, early adopters, de vroege en late meerderheid, en tot slot de achterblijvers (laggards).

De teams die traag zijn of nooit overstappen naar het nieuwste aanbod, zijn een belangrijk signaal: zij vertellen je waarom je aanbod onvolledig is en waarom er meer werk gedaan moet worden. Interne platforms moeten inspelen op een breder publiek dan alleen de 'gemiddelde' gebruiker. Het residu van een migratie wijst ons op gebruikers voor wie jouw gemiddelde oplossing niet werkt.

Signalen vanuit de industrie

Beschrijvend schrijven leidt tot voorschrijvend schrijven

Ideatie is moeilijk, maar het is jouw taak om frisse ideeën te bedenken om een bestaand systeem te verbeteren en deze voor te stellen in een voorschrijvende vorm (bijvoorbeeld een RFC). Mijn favoriete manier om ideeën te genereren is door bestaande systemen te beschrijven (voor collega's, gebruikers of nieuwe medewerkers). Schrijf een ontwerpdocument voor het systeem zoals dat nu bestaat en vergelijk dit met state-of-the-art systemen die een soortgelijke taak uitvoeren. Deze handeling van het beschrijven brengt beslissingen aan het licht die niet langer logisch zijn. Dit is "schrijven-als-denken" in zijn puurste vorm.

Vertraging als arbitrage

Er is echte waarde in het op de hoogte blijven van trends in de industrie — open-source releases, blogs van andere bedrijven, research papers en conferenties. Maar er is een scherpere manier om deze te gebruiken. Ik geloof dat elk computerdomein schommelt tussen fasen van bundling (samenvoegen) en unbundling (opsplitsen). We voegden compute en storage samen in data warehouses, splitsten ze daarna in data lakes, en nu voegen we ze weer samen in lakehouse engines. De beweging van monolith naar microservices maakt nu plaats voor de modulaire monolith.

Interne platforms vertonen dezelfde schommelingen, maar met een vertraging omdat ideeën tijd nodig hebben om door te sijpelen. Die vertraging is geen bug; het stelt je in staat om zowel de redenering achter de convergentie in de industrie als het bewijs daarvoor te importeren (publieke postmortems, succesvolle migraties, benchmarks, etc.). Je krijgt het bewijs zonder dat je zelf de kosten van het genereren ervan hoeft te betalen, en je kunt posities overslaan die de industrie al heeft verlaten. Het risico is hier te veel vertraging: je wilt niet bij de laatste groep teams horen die een trend adopteert.

Welk signaal, wanneer?

Elf signalen zijn te veel om tegelijkertijd te monitoren. Ik rangschik ze op twee assen: hoeveel van het argument krijg ik gratis aangeleverd, en is het een leidende (leading) of achterlopende (lagging) indicator.

Aan de ene kant staan de signalen die "voor-beargumenteerd" binnenkomen. Een postmortem heeft al een doelgroep en een conclusie. Een kostencentrum is al uitgedrukt in dollars. Een OKR volgt werk dat al is uitgevonden. Deze zijn goedkoop om op te acteren, maar ze lopen in verschillende mate achter.

Aan de andere kant staan signalen waarvoor je zelf een argument moet construeren. Lag arbitrage geeft je de sterkste redenering maar de zwakste positie, omdat het bewijs van buiten je bedrijf komt. De heuristiek van de herhalende manager geeft nul bewijs, maar heeft wel interne steun. Continue ontdekking geeft je gebruikerspijnen, maar het omzetten daarvan in specificaties is aan jou.

Overbelaste use-cases zitten in het midden, en daarom zijn ze mijn favoriet. Het signaal is leidend en het argument is al gebouwd en draait in productie. Partner-to-prototype koopt hetzelfde bewijs, maar dan tegen de kosten van het zelf bouwen. Migratie-residu is dezelfde ruil, maar één migratie later: de achterblijvers zijn een achterlopend signaal voor de migratie die je net hebt gedaan, en een leidend signaal voor de volgende. Beschrijvend schrijven levert geen direct argument of urgentie op, maar heeft de grootste kans om beslissingen op te merken die stilletjes zijn verlopen.

Slotopmerking

Dit is geen probleem van tekort. De signalen zijn altijd aanwezig en de bovenstaande lijst is niet uitputtend. De fout die engineering-led platformteams vaak maken is niet een lege backlog, maar een backlog die is samengesteld uit de luidste signalen — meestal de crash, soms de manager van twee niveaus hoger. Het uitvinden van werk gaat minder over het vinden van een signaal, en meer over het kunnen uitleggen waarom juist dit signaal prioriteit krijgt boven de andere tien.