Proč technická excelence samotná již není dostatečná pro povýšení inženýrů v éře AI

AI způsobil významný posun v tom, jak pracujeme a co se automatizuje uvnitř technických týmů. V mé práci ve Sombra jsem viděl, jak tento posun změnil nejen to, jak týmy dodávají, ale také to, co se odměňuje v kariérním růstu. Po dlouhou dobu byla kariérní dráha v technice bastante lineární: jste se učili nové dovednosti, stále se zlepšovali technicky, stali se někým, kdo řeší těžké problémy, vybudovali si pověst a důvěru a poté si vydělali cestu nahoru po kariérním žebříčku.

Ale tento cyklus se nyní začíná lámat. AI přebírá mnoho úkolů, urychluje práci a snižuje náklady. To neznamená, že technické dovednosti již nejsou důležité, ale dělá úkoly, které vyžadují úsudek, myšlení o výsledcích a rozhodování, ještě důležitějšími.

Tento posun jsem zažil osobně na své cestě od inženýra k spoluzakladateli a CTO ve Sombra. Pět let do své inženýrské kariéry jsem se stal tím typem specialisty, na kterého se týmy spoléhají. Byl jsem tím typem zaměstnavatele, který mohl řešit těžké technické problémy, převzít vlastnictví složitých prací a být důvěryhodný, když projekty byly v ohni. Ale něco chybělo a cítil jsem se uvězněný.

Zdálo se, že jsem narazil na svou kariérní střechu a že nemohu jít further. Mé technické dovednosti byly na svém vrcholu, ale tato další fáze růstu vyžadovala něco jiného – obchodní myšlení.
Nemohl jsem pokračovat pouze tím, že vím, jak postavit něco, musel jsem se naučit, co stojí za to postavit jako první.

Taková střecha se stává stále častější napříč průmyslem.

Trh se mění rychleji, než si mnoho inženýrů uvědomuje

Světové ekonomické fórum hlásí, že 40 % zaměstnavatelů očekává, že sníží pracovní sílu, kde AI může automatizovat úkoly, zatímco výzkum Anthropic na software development naznačuje, že když AI přebírá více opakovaných vývojových prací, více inženýrů může být tlačeno směrem k vyššímu designu a rozhodování.

Samozřejmě, že stále existuje enormní poptávka po technickém talentu. Nemyslete si, že technické tvrdé dovednosti zůstávají jádrem profese, ale širší trend je, že existuje méně rolí, kde samotná realizace stačí k povýšení. Existuje vysoká poptávka po lidech, kteří mohou formulovat problémy, priorizovat pod omezeními a spojovat technickou práci s obchodním hodnotou.

To byla transformace, kterou jsem musel udělat. Můj největší upgrade nebyl pouze technický, ale kontextuální.

Nevzdal jsem se inženýrství, ale rozšířil jsem ho a přeformuloval otázky kolem něj.

Přestal jsem měřit svůj kariérní růst podle “více kódu”, “více složitosti” nebo “těžšího technického vlastnictví” a přešel na architekturu, obchodní dopad a kvalitu rozhodnutí.

Pět posunů, které změnily způsob, jakým pracuji

To může znít abstraktně, takže to rozložím na 5 praktických posunů, které mi pomohly vyvinout obchodní myšlení.

První posun byl naučit se obchodní přímo, místo aby přijímal druhé ruce prostřednictvím lístků.

Mnozí inženýři pracují z downstream signálů. Získáváme požadavky, ale ne konverzaci, která je formovala. Nemůžeme vidět kompromisy za našimi úkoly, ani strategické důvody, proč tyto úkoly existují.

Takže jsem začal se učit obchodní přímo. Začal jsem navštěvovat více prodejních a podpůrných hovorů, poslouchal jejich konverzace pozorně a věnoval více pozornosti diskusím mezi stakeholdery. Postupem času jsem přestal vidět svou práci jako řadu izolovaných dodávek.

Došel jsem k závěru: technicky elegantní řešení, které přijde příliš pozdě, stojí příliš mnoho nebo řeší špatný problém, není strategickou prací. Je to jen drahá korektnost.

Druhý posun byl naučit se obchodní jazyk bez toho, aby se choval jako něco vyhrazeného pro výkonné ředitele.

Začil jsem se učit všechny ty termíny, které mnozí inženýři nejsou explicitně vyučeni: ROI, náklad na zpoždění, příležitostný náklad, riziko expozice, marže a sekvence. To je prostě nevyhnutelné, pokud máte v úmyslu dosáhnout seniorních nebo C-úrovní pozic.

To ovlivňuje technické úsudek, protože mnozí specialisté jsou skvělí v řešení problémů, ale nemohou priorizovat a vyhodnotit je podle obchodních cílů.

Pro mě se změnil způsob, jakým komunikuji a, ještě důležitěji, jak hodnotím řešení. Práce sama o sobě zůstala technickou, ale logika za ní se stala širší.

To je důležitý rozdíl v éře AI. AI může stále více pomáhat týmům realizovat, ale nemůže vlastnit rozhodování. Ta vrstva patří lidem.

Jiný velký posun mysli byl definovat úspěch před psaním kódu.

Postupem času, předtím než jsem začal implementaci, zeptal jsem se sám sebe série otázek:

• Co přesně to změní pro uživatele nebo podnik?
• Který metrický údaj by se měl pohybovat?
• Jak bude někdo vědět, že to mělo význam?

Tyto otázky mi opravdu pomohly vyřešit věci předtím, než jsem začal kódovat. Také mě zachránily před běžným selháním: investovat silně do dodávky předtím, než se shodneme na dopadu.

To je jeden z důvodů, proč měření tolik záleží. DORA’s software delivery research ukázala hodnotu měření, jak týmy dodávají software bezpečně, rychle a efektivně. Ale v praxi obvykle vedoucí techničtí lídři jdou o jednu vrstvu dále: spojují dodávky s produkčními a obchodními výsledky.

To znamená, že odeslání není cílem. Určitě, odhadujeme výsledky na základě dodávky, ale často je schopnost definovat úspěch dopředu tím, co někoho posouvá do širšího vedení.

Čtvrtý posun byl testovat předpoklady předtím, než přebudujete.

Silní inženýři často přebudovávají, vedeni běžným mýtem, že AI činí budování levnějším a že více inženýrství automaticky znamená lepší kvalitu.

Vysokovýkonní techničtí lidé jsou často trénováni k myšlení v termínech robustních řešení, protože všichni chceme budovat věci správným způsobem. To je skvělá vlastnost, kterou je třeba vyvinout, ale často se stává nákladnou, když se zavážete k plnému řešení předtím, než ověříte předpoklady.
To je proč jeden z mých nejpraktičtějších posunů byl vynutit pauzu před budováním a definováním mých předpokladů. Jakmile je předpoklad explicitní a jasný, práce se změní.
Cílem již není prokázat, jak sofistikované může být řešení. Cílem je naučit se rychle, levně a jasně enough, aby se rozhodlo, co si zaslouží hlubší investici.

Jeden poslední posun, který mi opravdu pomohl, byl psát krátké rozhodnutí před kódováním.

To může být nejpraktičtějším zvykem ze všech. A nemyslete si, že se snažím vynutit další dokument — jen krátkou a strukturovanou poznámku, aby se visualizoval váš myšlení: co existují možnosti, co rizika záleží, co dopad se očekává, co doporučení má smysl a kde je stále potřeba sladění.

To nejen zlepšilo komunikaci, ale také odhalilo slabé myšlení brzy a pomohlo vyjasnit předpoklady (viz předchozí posun). Kromě toho vytvořilo záznam o tom, proč bylo rozhodnutí učiněno, což se stává zvláště cenným, když se přehlíží výsledky. Tato malá akce může změnit, jak jsou rozhodnutí formulována, komunikována a vlastněna.

V praxi se mnohé povýšení dějí, protože osoba může snížit ambiguitu pro ostatní, ne proto, že jsou nejtechničtěji brilantní osobou v místnosti.

Proč další úroveň je o lepších rozhodnutích

To je větší chyba, kterou mnozí lidé dělají, když mluví o AI a technických kariérách. Rámují příběh tak, jako by volba byla mezi technickou hloubkou a vedením, nebo mezi inženýrstvím a řízením.

Technické dovednosti stále záleží. Ve mnoha případech záleží dokonce více, protože lidé potřebují dostatečnou hloubku, aby mohli posoudit, co AI systémy dělají, kde selhávají a co by se mělo nebo nemělo důvěřovat. Ale technická excelence sama o sobě je méně diferencovaná, když více realizace může být urychlena nástroji. To je přesně to, co svědkujeme každý den ve Sombra: nejrychlejší kariérní růst nastává, když inženýři spojují technickou hloubku s obchodním myšlením.

To neznamená, že by každý silný inženýr měl stát se manažerem. Ale znamená to, že cesta nahoru se mění. Další úroveň je méně o tom, aby prokázal, že někdo může udělat nejtěžší úkol sám, a více o tom, aby prokázal, že může pomoci týmu a podniku učinit lepší rozhodnutí.

Nenarazil jsem na zeď, protože mi chyběla inteligence nebo disciplína. Narazil jsem na zeď, protože další úroveň vyžadovala širší pohled. Jakmile se to změnilo, můj rozsah se také změnil.