A Staff-plus mérnök szerepe nagyban függ attól, hogy mire van szüksége a csapatnak, és hogy az adott mérnöknek milyen erősségei vannak. Tapasztalataim szerint a Staff-plus mérnökök feladatai idővel változhatnak, de általában a fő hangsúly a vállalat számára stratégiai értékkel bíró projekteken/erőfeszítéseken való munkára helyeződik, miközben a műszaki tervezést és a csapatuk szintjének emelését irányítják. – Diana Pojar

Mindenki, akit a rokonok már sarokba szorítottak egy partin, és megkérték, hogy magyarázza el, mit is csinálnak valójában a szoftvermérnökök, tudja, hogy a munka elmagyarázása kihívást jelenthet. Idővel talán sikerült egy meggyőző választ alkotni a rokonok számára, de sokaknak elakad a szeme, amikor a munkatársuk odahajol, és megkérdezi: “Mit csinál egy Staff mérnök?”

A legegyszerűbb válasz az, hogy a Staff mérnökök továbbra is sok mindent csinálnak abból, ami Senior mérnökként sikeressé tette őket: kapcsolatépítés, szoftverírás, projektek koordinálása. Ez azonban félrevezető válasz. Ugyanazokat a feladatokat végzik, de míg korábban ezek képezték a munka lényegét, most mellékmunkává váltak, és új prioritásaik vannak. A napi beosztásuk archetípusonként némileg változik, de minden archetípusban van egy közös alap: a technikai irányvonal meghatározása és szerkesztése, szponzorálás és mentorálás, mérnöki kontextus beillesztése a szervezeti döntésekbe, felfedezés, és amit Tanya Reilly úgy nevez, hogy ragasztónak lenni.

Technikai irányvonal meghatározása

A legnagyobb hatást akkor érzem, amikor megkönnyíthetem egy terület technikai jövőképének meghatározását, és rávehetem az embereket arra, hogy e jövőkép felé haladjanak. Azt hiszem, mindannyian egyetértünk abban, hogy azt szeretnénk, ha a kódunk a jelenleginél jobban lenne architektúrázva, vagy valamilyen módon továbbfejlesztve. Azonban azt tapasztaltam, hogy gyakran az emberek homályosan érzik, hogy jobbat akarnak, anélkül, hogy világos elképzelésük lenne arról, hogy mit is akarnak. Szeretek segíteni a csoportnak eldönteni, hogy pontosan hova is akarnak eljutni (az sem baj, ha sosem érünk oda), és kidolgozni egy általános játéktervet arra vonatkozóan, hogyan juthatunk el oda. – Joy Ebertz

Mint ahogyan a Lorax beszél a fák nevében a népszerű gyermekkönyvben, a személyzeti mérnökök beszélnek a vállalatuk technológiája nevében. A technológia nem tud önmagáért beszélni, és hatékony szószólókra van szüksége. Azok az emberek, akik sikeresen fejlesztik a technológiát, pragmatikusak, megfontoltak, és inkább a fejlődés hosszú távú tendenciájára összpontosítanak, mint arra, hogy minden egyes döntést válsághelyzetnek tekintsenek. Hasznos lehet, ha úgy gondolunk erre, mintha a technológia részmunkaidős termékmenedzsere lennénk.

Egyes Staff-plus mérnököket kifejezetten egy adott terület, például az API-tervezés vezetésére vesznek fel, más esetekben pedig egy széles terület megközelítéseit szerkesztik és hangolják össze. Az egyik állandó minden szerepkörben az, hogy a technikai irány meghatározásának valósága sokkal inkább a körülötted lévő szervezet valós igényeinek megértéséről és megoldásáról szól, és sokkal kevésbé arról, hogy olyan technológiákat és megközelítéseket helyezzünk előtérbe, amelyekkel kapcsolatban személyesen izgatottan tanulunk. Korábbi szerepkörökben megpróbálhattad befolyásolni a döntéseket a téged motiváló technológiai döntések irányába, de a vezetői szerepkörökben elsősorban az üzletnek és a szervezetnek tartozol elszámolással, és csak utána magadnak.

Mentorálás és szponzorálás

A jelenlegi szerepkörömben akkor érzem magam energikusnak, amikor valaki, akit szponzoráltam, bejelentést küld, hogy elküldte a munkáját, vagy amikor látom, hogy segítettem egy fontos témával kapcsolatos mérnöki csapat modelljének kialakításában vagy megváltoztatásában. Nem én, hanem ezek a csapatok végzik nap mint nap a kemény munkát a technológiájuk építésében és támogatásában. A hatásomat a fejlődésük alapján mérem, és ami még fontosabb, a fejlődés irányultsága és a munkájuknak a vállalat céljaihoz való igazítása alapján. – Michelle Bu

Létezik egy népszerű elképzelés a hősies vezetésről, amelynek középpontjában a rendkívül produktív egyének állnak, akiknek döntései megváltoztatják a vállalat jövőjét. A legtöbb ilyen narratívát a PR-csapatok szándékosan úgy alakítják ki, hogy jó sztorit hozzanak létre. Sokkal nagyobb valószínűséggel változtathatod meg a vállalatod hosszú távú pályáját a körülötted dolgozó mérnökök fejlesztésével, mint személyes hőstettekkel. A körülötted lévők fejlesztésének legjobb módja a mentorálás és a szponzorálás aktív gyakorlatának kialakítása.

Néhány karrierlétrának van egy kötelező jelölőnégyzete a mentorálással kapcsolatban, amely a személyzeti pozícióba való előléptetéshez szükséges, és a mentorálás kulcsfontosságú része a szerepnek. A tapasztalatok és tanácsok megosztása, valamint a folyamatos kapcsolat a kedvezményezett környezetének megértése érdekében, nagy hatású munka. A vezetői pozíciókban a mentorálás csak a felvételi lécet jelenti, és a leghatékonyabb személyzeti mérnökök mérsékelt mennyiségű mentorálást párosítanak lényegesen több szponzorálással: közvetlenül a mérlegre helyezik a hüvelykujjukat, hogy segítsék a körülöttük lévők előmenetelét és támogatását. Ha még nem olvastad, Lara Hogan megírta a szponzorálás és a mentorálás közötti különbségtételről szóló kanonikus írást: What does sponsorship look like?

Providing engineering perspective

A magasabb szintű mérnöki megbeszéléseken, amelyek az egyes projektek és csapatok feletti szinten zajlanak, az asztalnál foglalok helyet. Rendszeresen tartunk személyzeti mérnöki értekezleteket, ahol a csapatokon átívelő, technikai és nem technikai jellegű problémákat vitatunk meg. – Dan Na

A hatékony szervezetek racionalizálják a rutinszerű döntéshozatalt. Jó példa erre a potenciális vállalati ügyfelek szerződéseinek felülvizsgálati folyamata. A korai szakaszban lesz néhány olyan szerződés, amelyet a termék- és mérnöki csapatok nem szívesen támogatnak. Miután ez néhányszor megtörténik, a folyamat több érdekelt felet von be a felülvizsgálati lépésekbe, és idővel a megfelelő emberek a megfelelő helyen lesznek a megfelelő időben.

A döntéseknek van egy másik kategóriája is, amelyek egyszerre időérzékenyek és fontosak, és nagyobb kihívást jelent a megfelelő embereket bevonni a szobába, mielőtt ezek a döntések véglegesítésre kerülnek. Gyakori, hogy egy szervezeti átszervezés értékes input nélkül történik, amely megváltoztathatta volna a végeredményt. Hasonlóképpen gyakori, hogy a ritkán betöltött pozíciók esetében – ahol évente talán egy embert veszünk fel, például vezetőket vagy Staff-plus mérnököket egy korai fázisban lévő vállalatnál – az interjúkörök nem értékelik a jelöltet egy fontos dimenzióban. Egyes vállalatoknál még az olyan dolgok is ebbe a kategóriába tartoznak, mint az útiterv-tervezés.

A Staff-plus mérnökök azok, akiket gyakran váratlanul behívnak abba a szobába, ahol ilyen jellegű döntések születnek. Ez lehetőséget ad nekik arra, hogy mérnöki kontextust és perspektívát adjanak a döntéshez, amíg még lehet változtatni az eredményen. A kritikus döntésekhez való hozzájárulásnak ezek a rövid pillanatok indokolatlanul nagy hatásúak, és lehetővé teszik, hogy a mérnöki nézőpont meghallgatásra kerüljön. Ezek olyan pillanatok is, amikor könnyű elfelejteni, hogy ezekben a pillanatokban gyakran az a feladatod, hogy az egész mérnökség érdekeit képviseld, ne csak a sajátodat.

Felfedezés

A jelenlegi szerepemben az inkubátorban egész nap prototípusok készítésével töltöm a napomat, de az előző tech lead szerepemben sok mindent csináltam. – Ritu Vincent

A hegymászás nem tud minden problémát megoldani, de annyira hatékony, hogy sok vállalatnak nehezére esik más megközelítéseket alkalmazni. Ez lehet egy fogyasztó-orientált vállalat, amelyik a vállalati ügyletek támogatásával küzd, vagy egy érett vállalat, amelyik egy kisebb versenytárs kiadási ütemével küzd. Még az is előfordulhat, hogy a jelenlegi üzletág annyira értékes, hogy nehéz új üzleteket priorizálni, még akkor is, ha az értékes üzletág növekedési üteme lefelé húzódik.

Hosszú távon a vállalatok vagy megtanulják a felfedezést, vagy elhalványulnak; ez nem egy figyelmen kívül hagyható kihívás. Egyszerűen egy hegymászásban jártas csapatot megbízni a feltáró munka elvégzésével messze nem biztos, ezért sok vállalat más megközelítést alkalmaz. Találnak néhány megbízható, széles körű készségekkel rendelkező személyt, elkülönítenek néhány erőforrást, és néhány hónap múlva visszanéznek, hogy mit fedeztek fel. Az egyik ilyen mérnök gyakran személyzeti mérnök.

Ez sem mindig üzleti probléma, lehet bármilyen kétértelmű, fontos probléma, amelynek kezelésére a vállalat rendszerei rosszul vannak kialakítva. Lehet, hogy az infrastrukturális költségek nagyságrenddel való csökkentése. Lehet egy olyan több régióra kiterjedő stratégia meghatározása, amely három év helyett hat hónapot vesz igénybe. Lehet, hogy azt a hirtelen felismerést kell kezelni, hogy az elsődleges adatbázisnak már csak három hónapnyi lemezterület van hátra, és nem lehet nagyobb méretűre frissíteni (tapasztalatom szerint ez meglepően gyakori probléma a gyorsan növekvő kezdő vállalkozásoknál).

Ez az egyik leghálásabb és egyben legkockázatosabb munka, amit a vállalatok végeznek, és nagy szervezeti bizalomra van szükség ahhoz, hogy rábízzák ezt a munkát, beleértve azt is, hogy az üzletág tisztelje, hogy ha kudarcot vallasz, az a problémára és nem rád vetül vissza.

Being Glue

Tanya Reilly írt egy csodálatos posztot, Being Glue címmel, amely a sikeres személyzeti mérnökök egy másik alapvető elemét ragadja meg: a megfelelő munka azonosításához és szállításához szükséges tennivalókat. Nem elbűvölő, de a nagy hatású szervezeteknél gyakran egy vagy több személyzeti mérnök dolgozik a színfalak mögött, aki a legfontosabb munkákat gyorsítja és biztosítja, hogy azok elkészüljenek.

De akkor is írsz majd szoftvert?

A személyzeti mérnök szerepéről szóló beszélgetést udvariatlanság lenne anélkül befejezni, hogy a személyzeti mérnökök első kérdésére ne válaszolnánk, amikor összegyűlnek egy szobában: “Még mindig van időd szoftvert írni?” A válasz természetesen az, hogy attól függ!

Ras Kasa Williams elmondta: “Még mindig rendszeresen hozzájárultam a kódhoz – természetesen kevesebbet, mint a csapatom többi mérnöke; de fontos volt, hogy folyamatosan “kézzel a billentyűzethez” dolgozzak, hogy a technikai stratégiámat (és egyéb makroszintű döntéseimet) a csapatom többi tagjának gyakorlati tapasztalatai alapján alakítsam ki.”

Katie Sylor-Miller elmondta: “Frontend-architekt vagyok, de messze a legfontosabb dolog, amit mostanában írok, az SQL, mert sok adatelemzést végzek. Megnéztem a teljesítménymutatóinkat, hogy kitaláljam, hol vannak a javításra szoruló területek, és melyek lennének a legnagyobb hatású problémák, amelyeket a teljesítmény és az üzleti mutatók javítása érdekében meg kellene oldani. Itt-ott írok kis JS- vagy PHP-darabkákat, de többnyire azért, hogy segítsek a csapatoknak feloldani az akadályokat, vagy hogy kisebb teljesítményhez kapcsolódó kísérleteket futtassak.”

Silvia Botros azt mondta: “Már nem az üzlet miatt kódolok. Azt hiszem, utoljára akkor kellett elővennem a terminálomat, amikor a dot fájljaimat kellett refaktorálnom. Ez egy szándékos döntés a főnököm, a Chief Architect részéről. Minden negyedévben ellenőrizni fog minket, hogy megbizonyosodjon arról, hogy nem járultunk-e hozzá olyan kódhoz, amely a termelésbe kerül.”

Joy Ebertz azt mondta: “Minél magasabb beosztásba kerülsz, annál kevésbé szól a munkád a kódról. Persze, az emberekkel foglalkozó menedzserekkel ellentétben neked még mindig van egy nagyon műszaki beállítottságod, és még az igazgatón keresztül is valószínűleg legalább némi kódolást fogsz végezni. Azonban minél magasabb pozícióba kerülsz, annál inkább arról szól a munkád, hogy mentoráld és fejleszd a körülötted lévő embereket (és szélesebb körben), építsd a csapatodat a vállalat nyilvános technológiai márkájának építésén keresztül, vedd észre a nagyobb technikai trendeket, amelyeken javítani vagy korrigálni lehet, segíts meghatározni a csapatod vagy a vállalat technológiai jövőképét, és támogasd a technikai adósságprojektek forrásait.”

A legtöbbjük ír valamennyit, néhányan egyet sem, de egyikük sem ír annyit, mint korábban a karrierjük elején. Alkalmanként lesz olyan hét, amely tisztán kódolásból áll, de ezek nem lesznek a normák, és ha túl gyakran fordulnak elő, az általában annak a jele, hogy inkább valami kényelmes, mint fontos dolgon dolgoznak.”

Lassú, de kifizetődő

A Staff-plus munkák egyik egységes témája, hogy az időkeretek egyszerűen hosszabbak. A pályafutásod elején könnyű hozzászokni a szoftverfejlesztés gyors visszacsatolási ciklusához – írj, tesztelj, szállíts, ismételj -, és a legtöbb munka, amit ezen a szinten fogsz végezni, ezt a visszacsatolási kört egy olyanra cseréli, amely heteket, hónapokat és éveket vesz igénybe.

A hatás és a személyes fejlődés ezekben a hosszabb időkeretekben él, és bár mindenki, akivel beszéltem, azt kívánta, bárcsak időnként több ideje lenne a kódolásra, egyikük sem bánta meg, hogy a jelenlegi szerepkörébe került.