De rol van een Staff-plus ingenieur hangt sterk af van wat het team nodig heeft en ook wat de sterke punten van de ingenieur in kwestie zijn. Mijn ervaring is dat de verantwoordelijkheden van een Staff-plus engineer in de loop der tijd kunnen veranderen, maar meestal ligt de nadruk op het werken aan projecten die van strategisch belang zijn voor het bedrijf, het aansturen van technisch ontwerp en het opwaarderen van hun team. – Diana Pojar

Iedereen die op een feestje door familieleden in het nauw is gedreven en gevraagd is uit te leggen wat software-ingenieurs eigenlijk doen, weet dat het een hele uitdaging kan zijn om het werk uit te leggen. Na verloop van tijd heb je misschien een overtuigend antwoord voor je familieleden, maar veel mensen denken niet meer na als hun collega hen vraagt: “Wat doet een Stafingenieur?”

Het gemakkelijkste antwoord is dat Stafingenieurs veel blijven doen van wat hen succesvol maakte als Senior ingenieurs: relaties opbouwen, software schrijven, projecten coördineren. Dat is echter een misleidend antwoord. Ze doen diezelfde taken, maar waar ze vroeger de kern van het werk vormden, zijn ze nu hulpwerk geworden, en hebben ze nieuwe prioriteiten. Hun dagelijkse schema varieert een beetje per archetype, maar er is een gedeelde basis over alle archtypes: het bepalen en bewerken van de technische richting, het bieden van sponsoring en mentorschap, het injecteren van de technische context in organisatorische beslissingen, verkenning, en wat Tanya Reilly lijm noemt.

Het bepalen van de technische richting

Ik voel me het meest invloedrijk wanneer ik het bepalen van een technische visie voor een gebied kan faciliteren en mensen in beweging kan krijgen in de richting van die visie. Ik denk dat we het er allemaal over eens zijn dat we willen dat onze code beter ontworpen is dan hij nu is of op een bepaalde manier verbeterd is. Ik heb echter gemerkt dat mensen vaak een vaag gevoel hebben dat ze beter willen zonder een duidelijk idee te hebben van wat datgene is wat ze willen. Ik help de groep graag om tot een gezamenlijk begrip te komen van wat ze precies willen bereiken (het is eigenlijk niet erg als we er nooit komen) en een algemeen plan op te stellen van hoe we daar kunnen komen. – Joy Ebertz

Zoals de Lorax spreekt voor de bomen in zijn populaire kinderboek, spreken stafingenieurs voor de technologie van hun bedrijf. Technologie kan niet voor zichzelf spreken en heeft effectieve pleitbezorgers nodig. Mensen die technologie met succes vooruit helpen zijn pragmatisch, weloverwogen, en richten zich meer op de langetermijntrend van vooruitgang dan op het zien van elke individuele beslissing als een make-or-break crisis. Het kan nuttig zijn om dit te zien als een part-time Product Manager voor technologie.

Sommige Staff-plus ingenieurs worden expliciet ingehuurd om een specifiek gebied te leiden, zoals API-ontwerp, en in andere gevallen bevinden ze zich in het bewerken en afstemmen van benaderingen over een breed gebied. Een constante in alle rollen is dat de realiteit van het bepalen van technische richting veel meer gaat over het begrijpen en oplossen van de echte behoeften van de organisatie om je heen, en veel minder over het prioriteren van technologie en benaderingen waar je persoonlijk enthousiast over bent om over te leren. In eerdere rollen heb je misschien geprobeerd om beslissingen te beïnvloeden in de richting van technologiekeuzes waar je zelf door gemotiveerd bent, maar in senior rollen ben je in de eerste plaats verantwoording verschuldigd aan de business en de organisatie, en pas in de tweede plaats aan jezelf.

Mentorschap en sponsoring

In mijn huidige rol voel ik me energiek wanneer iemand die ik heb gesponsord een aankondiging stuurt dat hij zijn werk heeft verzonden, of wanneer ik zie dat ik heb geholpen om het model van een engineeringteam voor een belangrijk onderwerp vorm te geven of te veranderen. Het zijn deze teams, niet ik, die dagelijks het harde werk doen om hun technologie te bouwen en te ondersteunen. Ik meet mijn impact op basis van hun vooruitgang en, nog belangrijker, de richting van die vooruitgang en de afstemming van hun werk op de doelstellingen van het bedrijf. – Michelle Bu

Er bestaat een populaire visie op heroïsch leiderschap waarin buitengewoon productieve personen centraal staan wier beslissingen de toekomst van hun bedrijf veranderen. De meeste van deze verhalen zijn opzettelijk ontworpen door public-relations teams om een goed verhaal te creëren. Je hebt veel meer kans om het lange termijn traject van je bedrijf te veranderen door de ingenieurs om je heen te laten groeien dan door persoonlijke heldendaden. De beste manier om de mensen om je heen te laten groeien, is het creëren van een actieve praktijk van mentorschap en sponsoring.

Veel carrièreladders hebben een verplicht selectievakje rond mentorschap om in aanmerking te komen voor een promotie naar een Staff-rol, en mentorschap is een belangrijk onderdeel van de rol. Het delen van je ervaring en advies, samen met een voortdurende relatie om de context van de ontvanger te begrijpen, is werk met een grote impact. In senior functies is mentorschap slechts de lat voor toelating, en de meest effectieve Staff ingenieurs koppelen een matige hoeveelheid mentorschap aan aanzienlijk meer sponsoring: je duim direct op de schaal leggen om degenen om je heen vooruit te helpen en te ondersteunen. Als je het nog niet hebt gelezen, Lara Hogan heeft het canonieke stuk geschreven over het onderscheid tussen sponsoring en mentorschap, What does sponsorship look like?

Providing engineering perspective

Ik zit aan tafel bij engineeringdiscussies op hoger niveau die plaatsvinden op een niveau boven individuele projecten en teams. We hebben regelmatig terugkerende technische stafvergaderingen waar we problemen bespreken die teams overspannen en die zowel technisch als niet-technisch van aard zijn. – Dan Na

Effectieve organisaties stroomlijnen routinematige besluitvorming. Een goed voorbeeld hiervan is het proces voor het beoordelen van contracten voor potentiële zakelijke klanten. In het begin zullen er contracten worden getekend die de product- en engineeringteams niet graag ondersteunen. Nadat dat een paar keer is gebeurd, zal het proces meer belanghebbenden betrekken bij de beoordelingsstappen, en uiteindelijk zullen de juiste mensen op de juiste plaatsen zijn op het juiste moment.

Er is een tweede categorie van beslissingen, die zowel tijdgevoelig als belangrijk zijn, en het is een grotere uitdaging om de juiste mensen in de kamer te krijgen voordat die beslissingen definitief worden gemaakt. Het komt vaak voor dat een organisatorische herstructurering plaatsvindt zonder waardevolle input die het resultaat zou hebben veranderd. Evenzo komt het vaak voor dat sollicitatiegesprekken voor weinig voorkomende functies – functies waarbij je elk jaar maar één persoon aanneemt, zoals leidinggevenden of staf-plus ingenieurs in een startend bedrijf – de kandidaat niet evalueren op een belangrijke dimensie. Voor sommige bedrijven vallen zelfs zaken als roadmap planning in deze categorie.

Staf-plus ingenieurs zijn de mensen die vaak onverwacht in de kamer worden getrokken waar dit soort beslissingen worden genomen. Dit geeft hen de kans om engineering context en perspectief in een beslissing te injecteren terwijl het nog mogelijk is om de uitkomst te veranderen. Deze korte momenten van inbreng bij kritieke beslissingen zijn van onschatbare waarde, en stellen u in staat om het perspectief van de ingenieur te laten horen. Het is ook een moment waarop je gemakkelijk vergeet dat je op deze momenten vaak de belangen van de hele technische afdeling moet behartigen, en niet alleen die van jezelf.

Verkenning

In mijn huidige rol binnen de incubator ben ik de hele dag bezig met prototypen, maar in mijn vorige tech lead-rol deed ik een heleboel verschillende dingen. – Ritu Vincent

Hill-climbing kan niet elk probleem oplossen, maar het is zo effectief dat veel bedrijven moeite hebben met andere benaderingen. Dit kan een consumentgericht bedrijf zijn dat worstelt om enterprise-deals te ondersteunen, of een volwassen bedrijf dat worstelt om te concurreren met de releasecadans van een kleinere concurrent. Het kan zelfs het geval zijn dat uw huidige bedrijf zo waardevol is dat het moeilijk is om prioriteit te geven aan nieuwe bedrijven, zelfs als het groeipercentage van het waardevolle bedrijf naar beneden gaat.

Op de lange termijn leren bedrijven ofwel te verkennen of ze verdwijnen; dit is geen ignorable uitdaging. Simpelweg een team aanstellen dat heuvelklimmen beheerst om verkennend werk te doen is verre van een zekere zaak, dus veel bedrijven kiezen voor een andere aanpak. Ze zoeken een paar betrouwbare mensen met brede vaardigheden, zetten wat middelen in, en komen een paar maanden later terug om te zien wat ze hebben ontdekt. Een van die ingenieurs is vaak een Staff engineer.

Dit is ook niet altijd een bedrijfsprobleem, het kan elk soort ambigu, belangrijk probleem zijn dat de systemen van het bedrijf slecht geschikt zijn om aan te pakken. Het kan het verminderen van uw infrastructuurkosten met een orde van grootte zijn. Het kan een multiregionale strategie zijn die zes maanden duurt in plaats van drie jaar. Het zou de plotselinge realisatie kunnen zijn dat je primaire database nog maar drie maanden schijfruimte heeft en je niet kunt upgraden naar een grotere grootte (in mijn ervaring een verrassend vaak voorkomend probleem bij snelgroeiende startups).

Dit is een van de meest lonende, en het meest risicovolle, werk dat bedrijven doen, en het vergt een groot vertrouwen van de organisatie om met dit werk te worden vertrouwd, inclusief het respect van de business dat als je faalt het een weerspiegeling is van het probleem en niet van jou.

Being Glue

Tanya Reilly schreef een prachtige post, Being Glue, waarin een ander kernelement van succesvolle Staff engineers wordt vastgelegd: het nodige doen om het juiste werk te identificeren en het te laten verschepen. Het is niet glamoureus, maar organisaties met een grote impact hebben vaak een of meer Staff engineers achter de schermen die het belangrijkste werk versnellen en ervoor zorgen dat het af komt.

Maar ga je nog steeds software schrijven?

Het is onbeleefd om elke discussie over de rol van Staff engineers te beëindigen zonder een mening te geven over de eerste vraag die Staff engineers stellen als ze samenkomen in een kamer: “Heb je nog tijd om software te schrijven?” Het antwoord is, natuurlijk, het hangt ervan af!

Ras Kasa Williams zei: “Ik droeg nog steeds regelmatig code bij – zeker minder dan de rest van de ingenieurs in mijn team; maar het was belangrijk dat ik “hand aan toetsenbord” werk volhield om ervoor te zorgen dat mijn technische strategie (en andere besluitvorming op macroniveau) werd geïnformeerd door de ervaringen op de grond van de rest van mijn team.”

Katie Sylor-Miller zei: “Ik ben een frontend architect, maar verreweg het belangrijkste wat ik de laatste tijd heb geschreven is SQL, omdat ik veel data-analyse doe. Ik kijk naar onze prestatiecijfers om uit te zoeken waar de verbeterpunten liggen, en wat de meest impactvolle problemen zijn om op te lossen om de prestaties en bedrijfsgegevens te verbeteren. Ik schrijf hier en daar kleine stukjes JS of PHP, maar dat is meestal om teams te helpen deblokkeren of om kleine prestatiegerelateerde experimenten uit te voeren.”

Silvia Botros zei: “Ik codeer niet meer voor de business. Ik denk dat de laatste keer dat ik mijn terminal moest gebruiken het was om mijn dot-bestanden te refactoren. Dit is een bewuste beslissing van mijn baas, de hoofdarchitect. Hij controleert ons elk kwartaal om er zeker van te zijn dat we geen code hebben bijgedragen die in productie gaat.”

Joy Ebertz zei: “Hoe hoger je komt, hoe minder je werk over code gaat. Natuurlijk, in tegenstelling tot een people manager, heb je nog steeds een zeer technische inslag en zelfs als je directeur bent, zul je waarschijnlijk op zijn minst wat coderen. Echter, hoe hoger je komt, hoe meer je baan wordt over mentoring en het laten groeien van de mensen om je heen (en breder), het opbouwen van je team door het opbouwen van het publieke tech-merk van je bedrijf, het opmerken van grotere technische trends die kunnen worden verbeterd of gecorrigeerd, het helpen bij het vaststellen van de tech-visie voor je team of het bedrijf en het pleiten voor resourcing voor tech debt projecten.”

De meesten schrijven wat, sommigen schrijven niets, maar geen van hen schrijft zoveel als ze vroeger in hun carrière deden. Er zal af en toe een week zijn waarin alleen maar wordt gecodeerd, maar dat is niet de norm, en als dat te vaak gebeurt, is dat meestal een teken dat je aan iets comfortabels werkt in plaats van aan iets belangrijks.

Traag maar lonend

Een rode draad door het hele personeels-plus-werk is dat de tijdschema’s gewoon langer zijn. In het begin van je carrière is het makkelijk om gehecht te raken aan de snelle feedbackcyclus van softwareontwikkeling – schrijven, testen, verzenden, herhalen – en het meeste werk dat je op dit niveau doet, vervangt die feedbackcyclus door een die weken, maanden en jaren duurt.

De impact en de persoonlijke groei leven in die langere tijdsbestekken, en hoewel iedereen met wie ik sprak wenste dat ze af en toe meer tijd zouden krijgen om te coderen, had geen van hen spijt van hun overgang naar hun huidige functie.