Jak excelovat v Engineering managementu

· Aktualizováno · autor Marian Kamenistak

Anglická verze: /blog/how-to-excel-in-engineering-management/

Pro Software Developera se může zdát nereálné představovat si, že by v budoucnu byl Engineering Managerem řekněme desítek lidí.

Čas plyne. Budoucnost se mění v současnost.

Jednoho dne si uvědomíte, že být manažerem má potenciál dramaticky zvýšit vliv, který máte. Společně se svými týmy toho můžete dosáhnout mnohem více ve srovnání s prací na vlastní pěst.

Věřím, že níže uvedený soubor principů vám pomůže stát se lídrem, kterého má smysl následovat, v kratším časovém horizontu, zejména ve světě Software Engineeringu.

1. princip: Prosazujte změny

Zůstaňte zaměření a investujte svůj čas do zlepšení většího rozsahu. Nezůstávejte na úrovni řešení drobných každodenních problémů, které končí stovkami položek v seznamu úkolů na Trellu.

Mise

image 7 jpeg

Abyste se vyhnuli této pasti, formulujte Mission Statement a transparentně artikulujte, čeho plánujete dosáhnout ve střednědobém až dlouhodobém horizontu. Nechte na tom lidi spolupracovat. Když máte Mission Statement, zbavíte se většiny položek mimo scope. Dalším trikem je odkazovat na hodnoty vaší společnosti a vyhodnocovat, které iniciativy jsou s nimi nejvíce v souladu.

Tip: Pokud správně řídíte své priority, skončíte s až osmi různými cíli podkládajícími vaši misi, rozloženými do měsíců nebo kvartálů. Ujistěte se, že v průměru každých šest týdnů implementujete jednu větší změnu. Lidé si všimnou a budou následovat váš příklad častého zlepšování a konzistence směru.

image 12Zdroj: Mindful Ambition

Komunikujte, jaká je další iterace mise, kterou je třeba splnit, a poskytujte aktualizace o průběhu, jak jen to je možné. Souběžně se ptejte na zpětnou vazbu (např. NPS skóre) a vyhodnocujte, zda směřování pomáhá lidem a společnosti růst nejrealističtějším způsobem.

Senior manažer neuspokojuje svou potřebu naplnění tím, že si odškrtává drobné, bezvýznamné až „zdánlivě urgentní“ úkoly, aby získal falešný pocit dosažení výsledku.

2. princip: Postavte lidi do středu vesmíru

Bez svých lidí nejste nic. Zasloužte si jejich důvěru.

Zvykněte si trávit 3/5 svého času komunikací s vývojáři, kolegy a top manažery, ať už neformálně nebo přímo k věci.

image 9

Naučte se delegovat. Zmocněte ostatní k řešení většiny přicházejících problémů. Pokud je problém komplexní, zapojte se, použijte strategii rozděl a panuj nebo vytvořte Tiger team odpovědný za odstranění problému.

Skvělí manažeři se přesouvají od vykonavatelů k facilitátorům. Ptejte se, jaké překážky brání lidem v řešení situace. Následně tyto překážky odstraňte a požádejte o implementaci změny. Především se ujistěte, že máte follow-up, zda byla situace vyřešena. Pochvalte, nebo požádejte o zlepšení. Pokud dojde k selhání, nechte se z něj všichni poučit a viňte sebe.

3. princip: Rozumějte produktu

Ujistěte se, že děláte maximum pro to, abyste se naučili produkt end-to-end: Proč naše řešení přináší zákazníkům hodnotu a co je diferenciátor. Společnosti mají obvykle několik zdrojů znalostí. Podívejte se nejprve na videa, release notes a wiki. Sekundárně mluvte se všemi Product manažery a doménovými experty, abyste své znalosti prohloubili a získali odpovědi na otázky.

image 8 jpeg

Se znalostí produktu pochopíte, proč má feature X vyšší prioritu, včetně dopadu na zákazníka. Navíc se můžete zapojit do produktových diskuzí, což v konečném důsledku zvyšuje vzájemnou důvěru.

4. princip: Vystupte ze své bubliny

Vedení oddělení vývoje softwaru není o tom, aby všechny týmy a interní procesy fungovaly jako po másle. Takový přístup vás soustředí pouze na lokální optimum (typicky Jira tickety s nízkým lead time a vysokým throughputem) a dláždí cestu k selhání. Místo toho vystupte ze své bubliny.

Zaměřte se na spolupráci a výstupy.

image 5 jpeg

Kromě toho se ujistěte, že máte hodnotné vztahy se svými manažerskými kolegy, zejména s Product Managery. V pracovním prostředí lidé kopírují vzorce chování shora. Manažeři se skvělými vztahy vedou oddělení se skvělou spoluprací.

Vynikající Engineering Manažeři jsou ti, kteří pouze, když je to nutné, vytvářejí jednoduché smlouvy mezi odděleními, aby pomohli lidem zvládat situace hladce (může to být limit kapacity vstupních/výstupních front, jasná definice priorit, SLA doba odezvy 4 hodin během pracovního dne, nebo features s průměrným lead time). Context-switching je velmi drahý. Takové dohody jsou efektivním způsobem, jak zabránit hasičským situacím a udržet lidi vyvážené a soustředěné dlouhodobě.

Bonus: Zvládněte podstatu managementu

V kontextu Engineering Managementu preferuji definici Managing the Risk. Riziko zvýšeného tech debt, propásnutých termínů, ztráty vývojáře, špatného rozhodnutí.

Riziko je proměnná, kterou my jako vývojáři softwaru nejsme zvyklí brát v úvahu kvůli binární povaze programování. Buď feature funguje na 100 %, nebo ne. Buď kód projde code review, testováním a nasadí se, nebo ne.

Podstupte riziko

image 6 jpeg

Zkušení manažeři vědí, že 80% úspěšnost v rozhodování a plnění cílů je zatraceně dobrý výsledek (např. v náboru, reorganizaci týmu, zlepšení metodiky, změně odpovědností) . S tímto vědomím se nenechte chytit do pasti vytváření ultimátních procesů a metodik pro vaše lidi, které pokrývají 100 % případů. V době, kdy je takové řešení téměř hotové a popsané na wiki stránkách, které nikdo nebude číst, se stává irelevantním a umírá.

Z této perspektivy může být dobrým příkladem vytvoření pipeline pro dodávku features, která hladce zvládá 80 % požadavků. Zbylých 20 % pokrytí je nákladných, vyskytují se zřídka a mohou být řízeny on-demand.

Vizualizujte

Dalším tipem je jednoduše vizualizovat problém formou jednoduchého dashboardu ukazujícího na problém, ve srovnání s tvorbou složitých procesů. Když se report stane viditelným pro všechny, root cause má tendenci zmizet, protože lidé mu začnou přirozeně věnovat pozornost.

image 13

Tento článek pokrývá první tři principy, které vás odliší od davu a nakonec vám přinesou úspěch. Přesto je toho víc, o čem lze mluvit, jako je rozhodování, najímání a propouštění, sladění s top managementem a princip Learn or die.

Více v příštím blogpostu 🙂

Přečtěte si dál