Il ruolo di un ingegnere dello staff-plus dipende molto da ciò di cui ha bisogno il team e anche da quali sono i punti di forza dell’ingegnere in questione. Dalla mia esperienza, le responsabilità di un ingegnere Staff-plus possono cambiare nel tempo, ma di solito il loro obiettivo principale è lavorare su progetti/sforzi che hanno un valore strategico per l’azienda, mentre guidano la progettazione tecnica e fanno salire di livello il loro team. – Diana Pojar

Chiunque sia stato messo all’angolo da parenti ad una festa e gli sia stato chiesto di spiegare cosa fanno effettivamente gli ingegneri del software sa che spiegare il lavoro può essere una sfida. Nel corso del tempo potreste aver creato una risposta convincente per i vostri parenti, ma la mente di molte persone si svuota quando il loro collega si china e chiede, “Cosa fa un ingegnere dello Staff?”

La risposta più semplice è che gli ingegneri dello Staff continuano a fare molto di ciò che li ha resi di successo come ingegneri Senior: costruire relazioni, scrivere software, coordinare progetti. Tuttavia, questa è una risposta fuorviante. Stanno facendo gli stessi compiti, ma mentre prima erano il cuore del lavoro, sono diventati lavoro ausiliario, e hanno nuove priorità. Il loro programma giornaliero varia un po’ a seconda dell’archetipo, ma c’è una base condivisa da tutti gli archetipi: impostare e modificare la direzione tecnica, fornire sponsorizzazione e mentoring, iniettare il contesto ingegneristico nelle decisioni organizzative, esplorazione e ciò che Tanya Reilly chiama essere il collante.

Impostare la direzione tecnica

Mi sento più incisivo quando posso facilitare la definizione di una visione tecnica per un’area e far muovere le persone verso quella visione. Penso che siamo tutti d’accordo sul fatto che vogliamo che il nostro codice sia architettato meglio di com’è o migliorato in qualche modo. Tuttavia, ho scoperto che spesso le persone hanno un vago senso di volere il meglio senza avere una chiara idea di ciò che vogliono. Mi piace aiutare il gruppo a decidere su una comprensione condivisa di dove esattamente stanno cercando di arrivare (in realtà va bene se non ci arriviamo mai) e venire con un piano di gioco generale su come arrivarci. – Joy Ebertz

Come il Lorax parla per gli alberi nel suo popolare libro per bambini, gli ingegneri del personale parlano per la tecnologia della loro azienda. La tecnologia non può parlare da sola e ha bisogno di difensori efficaci a suo favore. Le persone che fanno progredire con successo la tecnologia sono pragmatiche, deliberate, e si concentrano di più sulla tendenza a lungo termine del progresso piuttosto che vedere ogni singola decisione come una crisi da risolvere. Può essere utile pensare a questo come a un Product Manager part-time per la tecnologia.

Alcuni ingegneri dello Staff-plus sono esplicitamente assunti per guidare un’area specifica come la progettazione delle API, e in altri casi si trovano a modificare e allineare gli approcci in una vasta area. Una costante in tutti i ruoli è che la realtà dell’impostazione della direzione tecnica è molto più incentrata sulla comprensione e la risoluzione dei reali bisogni dell’organizzazione intorno a te, e molto meno sulla priorità della tecnologia e degli approcci che tu personalmente sei entusiasta di imparare. Nei ruoli precedenti potresti aver cercato di influenzare le decisioni verso scelte tecnologiche che ti motivano, ma nei ruoli senior devi rendere conto prima al business e all’organizzazione, e poi a te stesso.

Mentorship e sponsorship

Nel mio ruolo attuale, mi sento eccitato quando qualcuno che ho sponsorizzato manda un annuncio che ha spedito il suo lavoro, o quando vedo che ho aiutato a modellare o spostare il modello di un team di ingegneri su un argomento importante. Sono questi team, non io, che stanno facendo il duro lavoro quotidiano di costruire e supportare la loro tecnologia. Misuro il mio impatto in base ai loro progressi e, cosa più importante, la direzione di questi progressi e l’allineamento del loro lavoro agli obiettivi dell’azienda. – Michelle Bu

C’è una visione popolare della leadership eroica che si concentra su individui straordinariamente produttivi le cui decisioni cambiano il futuro della loro azienda. La maggior parte di queste narrazioni sono intenzionalmente progettate da team di pubbliche relazioni per creare una buona storia. È molto più probabile che tu cambi la traiettoria a lungo termine della tua azienda facendo crescere gli ingegneri intorno a te piuttosto che attraverso eroismi personali. Il modo migliore per far crescere chi ti circonda è creare una pratica attiva di mentorship e sponsorship.

Molte scale di carriera hanno una casella di controllo obbligatoria sulla mentorship per qualificarsi per una promozione in un ruolo di Staff, e la mentorship è una parte fondamentale del ruolo. Condividere la propria esperienza e i propri consigli, insieme a una relazione continua per capire il contesto del destinatario, è un lavoro ad alto impatto. Nei ruoli senior, la mentorship è solo l’asticella per le ammissioni, e gli ingegneri dello Staff più efficaci accoppiano una moderata quantità di mentorship con una considerevole quantità di sponsorizzazione: mettendo il pollice direttamente sulla bilancia per aiutare l’avanzamento e sostenere chi ti circonda. Se non l’avete ancora letto, Lara Hogan ha scritto il pezzo canonico sulla distinzione tra sponsorizzazione e mentorship, What does sponsorship look like?

Providing engineering perspective

Ho un posto al tavolo nelle discussioni di ingegneria di livello superiore che si verificano ad un livello superiore ai singoli progetti e team. Abbiamo riunioni ricorrenti di ingegneria del personale in cui discutiamo problemi che abbracciano i team e che sono sia di natura tecnica che non tecnica. – Dan Na

Le organizzazioni efficaci semplificano il processo decisionale di routine. Un buon esempio di questo è il processo di revisione dei contratti per i potenziali clienti aziendali. All’inizio, ci saranno alcuni contratti firmati che i team di prodotto e di ingegneria sono a disagio a sostenere. Dopo che questo accade un paio di volte, il processo includerà più stakeholder nelle fasi di revisione, e col tempo le persone giuste saranno nei posti giusti al momento giusto.

C’è una seconda categoria di decisioni, quelle che sono sia sensibili al tempo che importanti, ed è più impegnativo avere le persone giuste nella stanza prima che queste decisioni vengano finalizzate. È frequente che una ristrutturazione organizzativa si verifichi senza un prezioso input che avrebbe cambiato il risultato. Allo stesso modo, è comune per i cicli di intervista per ruoli poco frequenti – quelli in cui si potrebbe assumere una persona all’anno come i dirigenti o gli ingegneri Staff-plus in una società early stage – non valutare il candidato su una dimensione importante. Per alcune aziende anche cose come la pianificazione della roadmap rientrano in questa categoria.

Gli ingegneri Staff-plus sono le persone che spesso vengono inaspettatamente tirate nella stanza dove avviene questo tipo di decisione. Questo dà loro l’opportunità di iniettare il contesto ingegneristico e la prospettiva in una decisione mentre è ancora possibile cambiare il risultato. Questi brevi momenti di input su decisioni critiche sono indebitamente impattanti, e vi permetteranno di far sentire la prospettiva dell’ingegnere. Sono anche un momento in cui è facile dimenticare che il tuo ruolo in questi momenti è spesso quello di rappresentare gli interessi di tutta l’ingegneria, non solo i tuoi.

Esplorazione

Nel mio attuale ruolo all’interno dell’incubatore passo tutto il giorno a fare prototipi, ma nel mio precedente ruolo di tech lead ho fatto un sacco di cose diverse. – Ritu Vincent

L’Hill-climbing non può risolvere tutti i problemi, ma è così efficace che molte aziende fanno fatica ad adottare altri approcci. Può trattarsi di un’azienda orientata al consumatore che lotta per supportare gli affari aziendali, o di un’azienda matura che lotta per competere con la cadenza di rilascio di un concorrente più piccolo. Può anche essere il caso che il vostro business attuale sia così prezioso che è difficile dare priorità a nuovi business, anche se il tasso di crescita del business di valore è in calo.

A lungo termine, le aziende o imparano a esplorare o svaniscono; questa non è una sfida ignorabile. Assegnare semplicemente una squadra che ha imparato a scalare le colline per fare un lavoro esplorativo è tutt’altro che una cosa sicura, quindi molte aziende adottano un approccio diverso. Trovano un paio di persone fidate con ampie competenze, assegnano alcune risorse e tornano dopo qualche mese per vedere cosa hanno scoperto. Uno di questi ingegneri è spesso un ingegnere dello staff.

Non si tratta sempre di un problema di business, può essere qualsiasi tipo di problema ambiguo e importante che i sistemi dell’azienda non sono in grado di affrontare. Potrebbe essere la riduzione dei costi dell’infrastruttura di un ordine di grandezza. Potrebbe essere identificare una strategia multiregionale che richiede sei mesi invece di tre anni. Potrebbe essere affrontare l’improvvisa realizzazione che il vostro database primario ha solo tre mesi di spazio su disco rimanente e non potete aggiornarlo a una dimensione maggiore (nella mia esperienza, un problema sorprendentemente frequente nelle startup in rapida crescita).

Questo è uno dei lavori più gratificanti, e più rischiosi, che le aziende fanno, e ci vuole una grande quantità di fiducia organizzativa per essere affidati a questo lavoro, compreso il rispetto da parte del business che se fallisci è una riflessione sul problema e non su di te.

Essere Colla

Tanya Reilly ha scritto un post meraviglioso, Essere Colla, che cattura un altro elemento centrale degli Staff engineer di successo: fare il necessario per identificare il lavoro giusto e farlo spedire. Non è affascinante, ma le organizzazioni ad alto impatto spesso hanno uno o più ingegneri dello staff che lavorano dietro le quinte per accelerare il lavoro più importante e assicurarsi che venga finito.

Ma scriverai ancora software?

È scortese concludere qualsiasi discussione sul ruolo dell’ingegnere dello staff senza commentare la prima domanda che gli ingegneri dello staff fanno quando si riuniscono in una stanza: “Trovi ancora tempo per scrivere software?” La risposta è, naturalmente, dipende!

Ras Kasa Williams ha detto, “Ho ancora contribuito regolarmente al codice – certamente meno del resto degli ingegneri del mio team; ma era importante che sostenessi il lavoro “mano alla tastiera” per assicurare che la mia strategia tecnica (e altre decisioni a livello macro) fosse informata dalle esperienze sul campo del resto del mio team.”

Katie Sylor-Miller ha detto: “Sono un architetto frontend, ma la cosa principale che ho scritto ultimamente è SQL, perché sto facendo un sacco di analisi dei dati. Sto guardando le nostre metriche di performance per capire dove sono le aree di miglioramento e quali sarebbero i problemi più importanti da risolvere per migliorare le performance e le metriche di business. Scrivo piccoli pezzi di JS o PHP qua e là, ma per lo più per aiutare a sbloccare i team o per eseguire piccoli esperimenti relativi alle prestazioni.”

Silvia Botros ha detto: “Non scrivo più codice per il business. Penso che l’ultima volta che ho dovuto tirare fuori il mio terminale è stato per rifattorizzare i miei file dot. Questa è una decisione intenzionale del mio capo, il capo architetto. Ci controlla ogni trimestre per assicurarsi che non abbiamo contribuito a nessun codice che va in produzione”.”

Joy Ebertz ha detto, “Più alto è il livello, meno il tuo lavoro riguarda il codice. Certo, a differenza di un people manager, hai ancora un taglio molto tecnico e anche attraverso il direttore, probabilmente farai almeno un po’ di codifica. Tuttavia, più in alto si arriva, più il vostro lavoro diventa di mentoring e di crescita delle persone intorno a voi (e più in generale), costruendo la vostra squadra attraverso la costruzione del marchio tecnico pubblico della vostra azienda, notando le tendenze tecniche più grandi che possono essere migliorate o corrette, aiutando a impostare la visione tecnologica per il vostro team o l’azienda e sostenendo il resourcing per i progetti di debito tecnologico.”

La maggior parte scrive un po’, alcuni non scrivono, ma nessuno scrive tanto quanto faceva prima nella loro carriera. Ci sarà l’occasionale settimana di puro coding, ma non sarà la norma, e se accade troppo spesso è di solito un segno di lavorare su qualcosa di comodo piuttosto che importante.

Lento ma gratificante

Un tema unificante in tutto il lavoro Staff-plus è che i tempi sono semplicemente più lunghi. All’inizio della carriera è facile affezionarsi al rapido ciclo di feedback dello sviluppo del software – scrivere, testare, spedire, ripetere – e la maggior parte del lavoro che farete a questo livello sostituisce quel ciclo di feedback con uno che richiede settimane, mesi e anni.

L’impatto e la crescita personale vivono in questi tempi più lunghi, e mentre tutti quelli con cui ho parlato desideravano avere occasionalmente più tempo per scrivere codice, nessuno di loro ha rimpianto la transizione ai loro ruoli attuali.