Rollen för en stabsplusingenjör beror mycket på vad teamet behöver och vilka styrkor den enskilda ingenjören har. Enligt min erfarenhet kan en Staff-plus-ingenjörs ansvarsområden förändras med tiden, men vanligtvis är deras huvudfokus att arbeta med projekt/insatser som har ett strategiskt värde för företaget, samtidigt som de driver den tekniska utformningen och höjer nivån på sitt team. – Diana Pojar

Alla som har blivit uppringd av släktingar på en fest och ombedd att förklara vad programvaruingenjörer faktiskt gör vet att det kan vara en utmaning att förklara arbetet. Med tiden har du kanske skapat ett övertygande svar för dina släktingar, men många människor är helt tomma när deras kollega lutar sig fram och frågar: ”Vad gör en personalingenjör?”

Det enklaste svaret är att personalingenjörer fortsätter att göra mycket av det som gjorde dem framgångsrika som seniora ingenjörer: bygga relationer, skriva mjukvara, samordna projekt. Det är dock ett missvisande svar. De utför samma uppgifter, men medan de tidigare utgjorde kärnan i arbetet har de blivit hjälparbete, och de har nya prioriteringar. Deras dagliga schema varierar lite beroende på arketyp, men det finns en gemensam grund för alla arketyper: att fastställa och redigera den tekniska riktningen, tillhandahålla sponsring och mentorskap, ge teknisk kontext till organisatoriska beslut, utforska och det som Tanya Reilly kallar att vara lim.

För att fastställa den tekniska riktningen

Jag känner mig mest inflytelserik när jag kan underlätta fastställandet av en teknisk vision för ett område och få folk att röra sig i riktning mot den visionen. Jag tror att vi alla håller med om att vi vill att vår kod ska vara bättre arkitektoniskt utformad än den är eller förbättras på något sätt. Jag har dock upptäckt att människor ofta har en vag känsla av att de vill ha bättre utan att ha en tydlig idé om vad det de vill ha är. Jag gillar att hjälpa gruppen att besluta om en gemensam förståelse för exakt vad de försöker uppnå (det är faktiskt okej om vi aldrig når dit) och att komma fram till en allmän spelplan för hur vi ska nå dit. – Joy Ebertz

Som Lorax talar för träden i sin populära barnbok, talar personalingenjörer för sina företags teknik. Tekniken kan inte tala för sig själv och kräver effektiva förespråkare. Människor som framgångsrikt främjar tekniken är pragmatiska, medvetna och fokuserar mer på den långsiktiga utvecklingstrenden än att betrakta varje enskilt beslut som en avgörande kris. Det kan vara bra att tänka på detta som att vara en produktchef på deltid för teknik.

Vissa Staff-plus-ingenjörer anställs uttryckligen för att leda ett specifikt område, t.ex. API-design, och i andra fall får de redigera och anpassa tillvägagångssätt inom ett brett område. En konstant faktor i alla roller är att verkligheten när det gäller att fastställa teknisk inriktning handlar mycket mer om att förstå och lösa de verkliga behoven hos organisationen runt omkring dig, och mycket mindre om att prioritera teknik och tillvägagångssätt som du personligen är glad över att lära dig om. I tidigare roller kan du ha försökt påverka besluten i riktning mot teknikval som du motiveras av, men i ledande roller är du ansvarig inför verksamheten och organisationen i första hand och dig själv i andra hand.

Mentorskap och sponsring

I min nuvarande roll känner jag mig energisk när någon som jag har sponsrat skickar ett meddelande om att han eller hon har levererat sitt arbete, eller när jag ser att jag har hjälpt till att forma eller förändra ett ingenjörsteams modell av ett viktigt ämne. Det är dessa team, inte jag, som gör det hårda dagliga arbetet med att bygga och stödja deras teknik. Jag mäter min påverkan utifrån deras framsteg och, ännu viktigare, hur dessa framsteg går i rätt riktning och hur deras arbete anpassas till företagets mål. – Michelle Bu

Det finns en populär syn på hjältemodigt ledarskap som fokuserar på extraordinärt produktiva individer vars beslut förändrar företagets framtid. De flesta av dessa berättelser är avsiktligt utformade av PR-team för att skapa en bra historia. Det är mycket troligare att du ändrar ditt företags långsiktiga utveckling genom att få ingenjörerna runt omkring dig att växa än genom personliga hjältedåd. Det bästa sättet att utveckla din omgivning är att skapa en aktiv praxis för mentorskap och sponsring.

Många karriärstegar har en obligatorisk kryssruta kring mentorskap för att kvalificera sig för en befordran till en stabsroll, och mentorskap är en viktig del av rollen. Att dela med sig av sin erfarenhet och sina råd, tillsammans med en fortlöpande relation för att förstå mottagarens sammanhang, är ett arbete med stor effekt. I högre befattningar är mentorskap bara en gräns för tillträde, och de mest effektiva personalingenjörerna kombinerar en måttlig mängd mentorskap med betydligt mer sponsring: du sätter din tumme direkt på skalan för att hjälpa till att främja och stödja dem som finns runt omkring dig. Om du inte redan har läst den har Lara Hogan skrivit den kanoniska artikeln om skillnaden mellan sponsring och mentorskap, What does sponsring look like?

Providing engineering perspective

Jag har en plats vid bordet vid tekniska diskussioner på högre nivå som äger rum på en nivå ovanför enskilda projekt och team. Vi har återkommande tekniska personalmöten där vi diskuterar problem som sträcker sig över flera team och som är både tekniska och icke-tekniska till sin natur. – Dan Na

Effektiva organisationer effektiviserar rutinmässigt beslutsfattande. Ett bra exempel på detta är processen för granskning av kontrakt för potentiella företagskunder. I ett tidigt skede kommer det att undertecknas en del kontrakt som produkt- och teknikgrupperna inte känner sig bekväma med att stödja. När det har hänt några gånger kommer processen att inkludera fler intressenter i granskningsstegen, och med tiden kommer rätt personer att befinna sig på rätt plats vid rätt tidpunkt.

Det finns en andra kategori av beslut, de som är både tidskänsliga och viktiga, och det är mer utmanande att få in rätt personer i rummet innan dessa beslut slutförs. Det är vanligt att en organisatorisk omstrukturering sker utan värdefull input som skulle ha förändrat resultatet. På samma sätt är det vanligt att intervjuslingor för sällan förekommande roller – sådana där du kanske anställer en person per år, t.ex. chefer eller ingenjörer i ett företag som befinner sig i ett tidigt skede – inte utvärderar kandidaten på en viktig dimension. För vissa företag faller till och med saker som planering av färdplaner in i denna kategori.

Staff-plus-ingenjörer är de personer som ofta oväntat dras in i det rum där den här typen av beslut fattas. Detta ger dem möjlighet att ge ett tekniskt sammanhang och perspektiv till ett beslut medan det fortfarande är möjligt att ändra resultatet. Dessa korta stunder av input till kritiska beslut är onödigt betydelsefulla och gör det möjligt för dig att hålla ingenjörernas perspektiv hörda. De är också ett ögonblick då det är lätt att glömma att din roll i dessa ögonblick ofta är att företräda hela ingenjörsgruppens intressen, inte bara din egen.

Exploration

I min nuvarande roll inom inkubatorn spenderar jag hela dagarna med att ta fram prototyper, men i min tidigare roll som teknisk ledare gjorde jag en massa olika saker. – Ritu Vincent

Hillclimbing kan inte lösa alla problem, men det är så effektivt att många företag kämpar för att välja andra tillvägagångssätt. Det kan handla om ett konsumentorienterat företag som kämpar för att stödja företagsaffärer, eller ett moget företag som kämpar för att konkurrera med en mindre konkurrents lanseringsfrekvens. Det kan till och med vara så att din nuvarande verksamhet är så värdefull att det är svårt att prioritera nya affärer, även om den värdefulla verksamhetens tillväxttakt släpar nedåt.

På lång sikt lär sig företagen antingen att utforska eller så försvinner de; detta är inte en utmaning som kan ignoreras. Att bara tilldela ett team som behärskar bergsklättring för att göra utforskande arbete är långt ifrån säkert, så många företag väljer ett annat tillvägagångssätt. De hittar ett par betrodda personer med bred kompetens, tilldelar några resurser och tittar tillbaka några månader senare för att se vad de har upptäckt. En av dessa ingenjörer är ofta en Staff engineer.

Detta är inte heller alltid ett affärsproblem, det kan vara vilken typ av tvetydigt, viktigt problem som helst som företagets system är dåligt utformade för att hantera. Det kan vara att minska dina infrastrukturkostnader med en storleksordning. Det kan vara att identifiera en strategi för flera regioner som tar sex månader i stället för tre år. Det kan handla om att plötsligt inse att din primära databas bara har tre månaders diskutrymme kvar och att du inte kan uppgradera till en större storlek (enligt min erfarenhet är detta ett förvånansvärt vanligt problem i snabbväxande nystartade företag).

Detta är något av det mest givande, och det mest riskfyllda, arbetet som företag utför, och det krävs en hel del organisatoriskt förtroende för att man ska kunna anförtros det här arbetet, bland annat att verksamheten respekterar att om du misslyckas beror det på problemet och inte på dig.

Being Glue

Tanya Reilly skrev ett underbart inlägg, Being Glue, som fångar en annan central del av framgångsrika personalingenjörer: att göra det som behövs för att identifiera det rätta arbetet och få det skickat. Det är inte glamoröst, men organisationer med stor inverkan har ofta en eller flera personalingenjörer som arbetar bakom kulisserna för att påskynda det viktigaste arbetet och se till att det blir färdigt.

Men kommer du fortfarande att skriva mjukvara?

Det är ohövligt att avsluta en diskussion om rollen som personalingenjör utan att kommentera den första frågan som personalingenjörer ställer när de samlas i ett rum tillsammans: ”Hinner du fortfarande skriva mjukvara?” Svaret är naturligtvis att det beror på!

Ras Kasa Williams sade: ”Jag bidrog fortfarande regelbundet med kod – förvisso mindre än resten av ingenjörerna i mitt team – men det var viktigt att jag fortsatte att arbeta med tangentbordet för att se till att min tekniska strategi (och andra beslut på makronivå) var informerad av erfarenheterna från resten av teamet på plats.”

Katie Sylor-Miller sa: ”Jag är frontend-arkitekt, men det som jag har skrivit mest på sistone är SQL, eftersom jag gör en hel del dataanalyser. Jag har tittat på våra prestandamätningar för att ta reda på var det finns förbättringsområden och vad som skulle vara de mest betydelsefulla problemen att åtgärda för att förbättra prestandan och affärsmätningarna. Jag skriver små bitar av JS eller PHP här och där, men det är mest för att hjälpa till att frigöra team eller för att köra små prestandarelaterade experiment.”

Silvia Botros sa: ”Jag kodar inte längre för verksamheten. Jag tror att sista gången jag var tvungen att ta fram min terminal var för att refaktorisera mina dot-filer. Detta är ett avsiktligt beslut av min chef, chefsarkitekten. Han kontrollerar oss varje kvartal för att se till att vi inte har bidragit till någon kod som går i produktion.”

Joy Ebertz sa: ”Ju högre man blir, desto mindre handlar ens jobb om kod. Visst, till skillnad från en personaldirektör har du fortfarande en mycket teknisk inriktning, och även om du är chef kommer du troligen att göra åtminstone en del kodning. Men ju högre upp du kommer, desto mer handlar ditt jobb om att handleda och utveckla personerna runt omkring dig (och mer allmänt), att bygga upp ditt team genom att bygga upp företagets offentliga teknikvarumärke, att lägga märke till större tekniska trender som kan förbättras eller korrigeras, att hjälpa till att fastställa den tekniska visionen för ditt team eller företaget och att förespråka resurser för projekt med teknisk skuld.”

De flesta skriver en del, en del inte alls, men ingen skriver lika mycket som de brukade göra tidigare i sin karriär. Det kommer att finnas en och annan vecka som enbart består av kodning, men de är inte normen, och om de inträffar för ofta är det vanligtvis ett tecken på att man arbetar med något bekvämt snarare än viktigt.

Långsamt men belönande

Ett gemensamt tema i arbetet med Staff-plus är att tidsramarna helt enkelt är längre. Tidigt i karriären är det lätt att fästa sig vid mjukvaruutvecklingens snabba feedbackcykel – skriv, testa, skicka, upprepa – och det mesta av det arbete du kommer att göra på den här nivån ersätter denna feedbackcykel med en som tar veckor, månader och år.

Inverkan och den personliga tillväxten lever i dessa längre tidsramar, och även om alla som jag pratade med önskade att de ibland skulle få mer tid för att koda, så var det ingen av dem som ångrade att de övergick till sina nuvarande roller.