Hoe ik problemen vind om op te lossen als Staff Engineer

Opmerking: dit bericht is na publicatie herzien voor meer helderheid, gebaseerd op feedback van lezers.

"Hoe vind je problemen die het waard zijn om aan te werken?" vroeg een senior engineer die ik mentor, me onlangs. Hij probeert de stap naar staff engineer te maken en realiseerde zich dat de rol niet alleen gaat over het uitvoeren van het werk dat hem wordt toegewezen. Hij moet zich ook gaan verdiepen in het bepalen van wat zijn team en organisatie zouden moeten bouwen.

Iemand anders had hem gesuggereerd om tijd in zijn agenda te blokkeren om na te denken over het grotere geheel. Hij had dat geprobeerd, maar vond het niet productief, dus vroeg hij of ik alternatieven had.

Ik vertelde hem dat ik zelden goede problemen vind door naar een leeg blad te staren en te proberen "strategisch na te denken". In plaats daarvan handel ik als een spons. Ik luister naar de stroom van dagelijkse ruis, absorbeer de problemen waar mensen tegenaan lopen en laat deze in mijn achterhoofd zitten. Na verloop van tijd vervagen sommige, terwijl er verbindingen ontstaan tussen andere die aanvankelijk ongerelateerd leken. Uiteindelijk begin ik te zien wat mensen echt vertraagt en wat mijn team of ik daaraan kunnen doen.

Ik heb met veel engineers gewerkt die dit nooit echt hebben geprobeerd. Ze wachten tot managers of leads kansen identificeren en bewijzen vervolgens hun waarde door de moeilijkste toegewezen problemen op te lossen. Dat kan absoluut leiden tot promotie. Maar de projecten die de grootste indruk hebben gemaakt in mijn carrière, waren de projecten waarbij ik een belangrijk probleem vond en oploste waarvan mijn leidinggevenden nog niet eens beseften dat het bestond.

Een kanttekening: mijn ervaring komt voornamelijk voort uit het werken aan infrastructuur en ontwikkelaarstools bij grote bedrijven, in teams waar engineers veel bottom-up autonomie hebben om hun roadmaps te beïnvloeden. In een meer top-down omgeving is er wellicht simpelweg minder ruimte om op deze manier te werken.

Absorbeer problemen, geen verzoeken

Mensen praten graag over de problemen waar ze voor staan: in vergaderingen, chatthreads, presentaties en e-mails. Ze leggen uit waarom hun werk moeilijk is, klagen over wat hen vertraagt en beschrijven wat ze zouden willen kunnen doen.

Wanneer iets overlapt met mijn vakgebied, begin ik aan die draad te trekken. Ik vraag bijvoorbeeld: "Als X zou bestaan, zou dat jouw probleem oplossen?" of ik wijs ze op een bestaande functie in een product dat ik beheer en vraag in hoeverre dit hun use case dekt.

Gebruikers vragen vaak om een specifieke oplossing in plaats van hun kernprobleem uit te leggen. In plaats van het verzoek voor waarheid aan te nemen, blijf ik graven tot ik begrijp wat ze proberen te bereiken en waarom bestaande producten niet voor hen werken.

Als natuurlijk introvert werkt dit soort 'omgevingsluisteren' bijzonder goed voor mij. Ik hoef mijn agenda niet te vullen met speculatieve vergaderingen om ideeën te vinden; er stroomt tijdens een normale week al een enorme hoeveelheid nuttige informatie om me heen.

Wanneer een probleem het waard lijkt om te onderzoeken, word ik actiever. Ik wil zien hoe het de dagelijkse werkzaamheden van het team beïnvloedt. Ik ga bij hen zitten terwijl ze me meenemen door hun workflows en de bugs die ze onderzoeken. Wanneer ik kan, probeer ik die bugs zelf op te lossen. Het probleem uit de eerste hand ervaren maakt het gemakkelijker om te scheiden wat het team daadwerkelijk nodig heeft van de oplossing waar ze om vroegen.

Ook zoek ik mensen op die meer van de organisatie zien dan ik: zij die verantwoordelijk zijn voor kritieke systemen, over verschillende teams heen werken of bijzonder diep inzicht hebben in het werk dat downstream van mijn team plaatsvindt. Ik plan een 1-op-1 gesprek of een koffieafspraak en vraag naar interessante problemen die zij zijn tegengekomen. Zij hebben hetzelfde probleem wellicht al op verschillende plekken gezien en zijn al begonnen de punten te verbinden, wat mij een voorsprong geeft op patronen die ik anders veel langer had kunnen over het hoofd zien.

Laat problemen zich opstapelen

Meerdere keren ben ik onvoorzichtig geweest door te snel te handelen. Ik raakte enthousiast door een verzoek van een luidruchtig team, bouwde de functie en zag dat ze er nauwelijks gebruik van maakten. Hun prioriteiten waren veranderd, of het verzoek kwam voort uit een eenmalig onderzoek dat niet langer relevant was. Hoe enthousiast een team op dat moment was, was niet hetzelfde als hoe belangrijk de functie was ten opzichte van alles wat mijn product anders nog moest ondersteunen. Door me hyper-te focussen op hun verzoek, verloor ik het grotere geheel uit het oog.

Dat heeft me geleerd om potentiële problemen op te stapelen. Door te luisteren op de manier die ik beschrijf, houd ik veel meer problemen over dan ik mogelijk zou kunnen oplossen, en niet alle problemen verdienen actie. De meeste hoeven niet direct in een project te worden omgezet zodra ik er voor het eerst over hoor; wachten kan een superkracht zijn.

Wachten betekent dat hetzelfde probleem onafhankelijk van elkaar in verschillende teams kan opduiken, waardoor het een hogere prioriteit krijgt om op te lossen. Of problemen die aan de oppervlakte verschillend lijken, blijken dezelfde vorm te hebben, zodat ik verschillende use cases in één keer kan aanpakken. Of, zoals ik op pijnlijke wijze heb geleerd, het team dat het verzoek deed, vond het eigenlijk niet zo belangrijk.

In plaats daarvan maak ik een mentale notitie en kom ik op het probleem terug als het opnieuw opduikt. Andere engineers die ik ken, schrijven dit soort zaken systematischer op. Het mechanisme is een persoonlijke keuze: iedereen moet uitzoeken wat voor hem of haar werkt. Wat belangrijk is, is om onopgeloste problemen lang genoeg vast te houden zodat er meer bewijs kan worden verzameld.

Zoek naar de gemeenschappelijke vorm

Wachten helpt me om bewijs te verzamelen, maar dat alleen vertelt me niet wat ik moet bouwen. Ik moet nog steeds uitzoeken of de problemen die ik heb onthouden daadwerkelijk gerelateerd zijn en wat, indien aanwezig, ze samen zou kunnen oplossen.

Perfetto, de performance-debuggingtool waaraan ik werk, is hier een goed voorbeeld van. Het toont opnames van systeemactiviteit op een tijdlijn die bestaat uit rijen, genaamd "tracks". Over een periode van een paar jaar bleven teams vragen om kleine, specifieke toevoegingen aan de UI. De één wilde een commando om hun voorkeurstracks bovenaan het scherm vast te pinnen; het volgende team wilde hetzelfde, maar voor een geheel andere set tracks. Anderen wilden dat Perfetto direct ingezoomd opende op een specifiek deel van een opname, of een aangepaste aggregatie toonde die was afgestemd op waar zij om gaven. Een enkelen waren gestopt met wachten en hadden uitgebreide workarounds gebouwd met bookmarklets. [^1]

Tegen de tijd dat er genoeg van dit soort verzoeken waren opgestapeld, was mijn hoofd een chaos: de verzoeken zelf, de beperkingen van elk verzoek en een handvol halfgevormde oplossingen. Ik heb geleerd om geen oplossing te forceren door simpelweg achter een bureau te gaan zitten en na te denken. Mijn beste ontwarring gebeurt tijdens lange, doelloze wandelingen door Londen, waar verbindingen gemakkelijker ontstaan wanneer ik ze niet probeer te forceren.

Wat ik uiteindelijk besefte, was dat geen van deze teams echt de specifieke functie wilde waar ze om hadden gevraagd. Ieder wilde Perfetto personaliseren voor hun eigen workflow zonder hun keuzes aan iedereen op te leggen. De onderliggende behoefte was niet één specifieke functie, maar eerder de mogelijkheid om de UI uit te breiden. Wanneer een verbinding als die uiteindelijk klikt, is dat een van de beste gevoelens in dit vak: verschillende onhandige verzoeken vallen samen in één enkel idee, en er openen zich mogelijkheden waar geen van hen individueel naar wees.

Dat gevoel is echter precies het moment waarop ik voorzichtig moet zijn, want een gemeenschappelijke vorm is slechts een hypothese en elegantie is geen bewijs. Toen het gebeurde met het uitbreiden van de UI bleek het echt te zijn, maar ik ben me eerder laten misleiden.

In een ander recent geval was ik ervan overtuigd dat het bouwen van een transparant caching-systeem voor het opvragen van Perfetto-traces problemen zou oplossen met het delen van grote traces en herhaalde queries. Pas toen ik de RFC schreef en een prototype bouwde, realiseerde ik me dat de elegantie een leugen was: de twee problemen vereisten wezenlijk verschillende oplossingen. Ik splitste het ontwerp tegen mijn zin in in tweeën, waarvan beide delen inmiddels zijn opgeleverd. [^2]

Test het idee voordat je begint met bouwen

Je zou denken dat dit het moment is waarop ik begin met bouwen, maar dat is meestal niet het geval. Hoe ver ik ga, hangt af van hoe zeker ik ben dat het idee werkt en dat mensen het daadwerkelijk willen.

Als iets nuttig en risicovrij genoeg is, handel ik direct: ik stuur de wijziging door en laat mijn manager het weten. Wanneer ik onzeker ben of een idee zal werken of hoeveel moeite het zal kosten, bouw ik in plaats daarvan een wegwerpprototype; dit legt de zwakke punten bloot en geeft me iets concreets waar anderen op kunnen reageren. En wanneer een idee groot is maar ik ervan overtuigd ben, zet ik me volledig in: weken of maanden werk en de zware taak om steun te krijgen van andere engineers en teams.

Tijdens dit hele proces probeer ik niet alleen anderen te overtuigen; ik probeer ook mezelf te overtuigen. Soms is het eerlijke antwoord om te stoppen: als mensen de waarde niet zien die ik zie, of als we tegen een grote technische muur aanlopen, drop ik het idee liever nu dan dat ik iets bouw waar niemand gebruik van maakt of dat een onderhoudsnachtmerrie wordt. En soms houdt het idee stand, maar is de timing verkeerd, dus parkeer ik het, klaar om in actie te komen op de dag dat het een prioriteit voor de organisatie wordt.

Wanneer een idee standhoudt, hoef ik niet noodzakelijkerwijs degene te zijn die het bouwt. Ik kan het implementeren, iemand anders in mijn team kan dat doen, of het kan veranderen waar de organisatie zich op focust. Het vinden en vormgeven van het juiste probleem kan impact hebben, zelfs als ik de implementatie niet zelf bezit.

Het idee voor de Perfetto-extensies was die volledige inspanning waard. We waren al bezig met het bouwen van plugins om de UI te modulariseren, maar die waren niet genoeg: teams moesten al hun plugin-code open source maken, wat voor veel interne use cases geen optie was. Dus voordat ik iets nieuws bouwde, nam ik het probleem en mijn voorstel mee naar mijn manager, teamgenoten en de klantteams. Ik schreef uiteindelijk twee RFC's, had diverse 1-op-1 gesprekken en gaf een paar presentaties, waarbij ik het voorstel verfijnde naarmate de feedback binnenkwam.

Uiteindelijk heb ik macros ontworpen en geïmplementeerd als "lichtgewicht extensies": een manier om acties in de UI te automatiseren zonder een plugin te schrijven. Extension servers brachten het idee verder door teams in staat te stellen hun macro's te delen. In plaats van elke gevraagde functie zelf te implementeren, gaven we teams manieren om Perfetto aan hun eigen behoeften aan te passen. Tientallen teams binnen Google maken nu gebruik van macro's en extension servers, en verschillende andere bedrijven gebruiken extension servers intern.

Het oplossen van nuttige problemen helpt bij het vinden van de volgende

Hoe vaker ik dit proces doorloop, hoe gemakkelijker het wordt. Wanneer ik oprechte interesse toon in het probleem van iemand, nuttige vragen stel of help het op te lossen, onthouden ze dat. Ze komen eerder naar me toe en betrekken me bij gesprekken met andere mensen die met gerelateerde problemen kampen.

Dat geeft me een breder overzicht van wat er in de organisatie gebeurt, waardoor het gemakkelijker wordt om patronen te herkennen en dingen te bouwen die mensen daadwerkelijk nodig hebben. Het oplossen van een van die problemen brengt me in meer gesprekken, en de cirkel is rond. Deze successen bouwen het soort vertrouwen op dat voortkomt uit langdurig beheer.

In het begin moest ik veel van deze ideeën zelf omzetten in iets tastbaars om te bewijzen dat mijn oordeel correct was. Na verloop van tijd gaven mijn manager en de organisatie meer gewicht aan mijn inschatting van wat belangrijk was. Dat stelde me in staat om de roadmap te beïnvloeden zonder elk project zelf te hoeven bezitten.

Dit verschilt van het idee dat een staff engineer worden betekent dat je technisch werk vervangt door vergaderingen en coördinatie. Voor mij zijn gesprekken input voor wat ik bouw, niet het eindresultaat.

Conclusie

Dat is wat ik mijn mentee wilde laten begrijpen: het vinden van problemen die het oplossen waard zijn, staat niet los van de rest van het werk. Het komt voort uit het betrokken blijven bij het werk van anderen, lang genoeg om te zien wat geen enkel individueel verzoek je kan laten zien.

***

[^1]: Deze workarounds gebruikten bookmarklets om JavaScript uit te voeren tegen de interne UI-API's van Perfetto. [^2]: Het oorspronkelijke voorstel was om een transparante cache te gebruiken voor herhaalde queries en het sneller heropenen van grote traces. Tijdens het uitwerken realiseerde ik me dat herhaalde queries beter bediend werden door sessies 'warm' in het geheugen te houden, terwijl heropenen beter werd bediend door een trace expliciet te exporteren naar een formaat dat ontworpen is om snel te laden. Een transparante diskcache zou ook bestanden van meerdere gigabytes kunnen bewaren zonder dat de gebruiker dit merkt en zou een nieuw systeem vereisen om hun levensduur te beheren. Het voorstel werd uiteindelijk vervangen door warm sessions en streaming table export.