Od seniora ke staffovi

Tahle kapitola je nad rámec zbytku učebnice. Všechno předtím tě učilo postavit a rozebrat systém — tedy práci, kterou se z juniora stává senior. Posun senior → staff je ale o jiné ose: přestává jít o to, kolik kódu napíšeš, a začíná jít o páku (leverage) — jak velký dopad má tvoje rozhodnutí na ostatní. Staff inženýr často napíše kódu míň, ale to, co rozhodne, ovlivní desítky lidí na měsíce dopředu. Tohle je úvod do té osy, ne kompletní příručka.

Pár pojmů na úvod

• IC (Individual Contributor) = inženýr, co neřídí lidi (nemá podřízené). Staff je „senior na druhou" na IC dráze — roste vliv, ne počet podřízených.
• Leverage (páka) = poměr „dopad / odvedená práce". Napsat funkci = malá páka. Rozhodnout, že celý tým nebude stavět vlastní frontu a použije hotovou = obrovská páka.
• Scope (záběr) = jak velký kus problému držíš. Junior: úkol. Senior: služba/feature. Staff: oblast napříč týmy, kde problém ještě ani není jasně zadaný.
• Conwayův zákon = systém kopíruje komunikační strukturu organizace, která ho staví (rozvedeno níže).
• Expand-contract (parallel change) = vzor, jak měnit věci za běhu bez výpadku (rozvedeno níže).
• Disagree and commit = řeknu nahlas nesouhlas, ale když padne rozhodnutí, jdu za ním naplno.

Co se vlastně mění mezi seniorem a staffem

Senior odpoví perfektně na otázku „jak to postavím?“. Staff se ptá o úroveň výš: „má se to vůbec stavět? Co se má stavět? A proč zrovna teď?“ Tři posuny:

• Od řešení k zadání. Seniorovi dáš problém a on ho vyřeší. Staff problém najde, orámuje a rozhodne, který stojí za řešení — protože většina práce je v tom vybrat tu správnou věc, ne ji udělat.
• Od „mám pravdu“ k „posunul jsem skupinu“. Být technicky správně nestačí. Když to nikdo nepřijme, dopad je nula. Staff měří úspěch tím, jestli se organizace pohnula správným směrem.
• Od jednoho systému k systémům + lidem. Návrh už není jen o boxech a šipkách, ale i o tom, kdo to bude provozovat ve 2 ráno, který tým co vlastní a jak se rozhodnutí udrží i za rok.

💡 Dobrá zkratka: senior optimalizuje svůj výstup, staff optimalizuje výstup okolí. Když na půl roku zmizíš a tvůj tým je díky věcem, co jsi nastavil, rychlejší — to je staff práce.

Technická strategie — myslet v letech, ne v sprintech

Strategie je jak rozumně alokovat omezené úsilí směrem k cíli, který přežije víc než jeden kvartál. Není to roadmapa featur. Je to odpověď na: kam to jde za 1–3 roky, jaké sázky děláme a co vědomě neděláme.

• Pojmenuj „nudný střed“. Většina dobrých strategií je nuda: konsolidovat tři skoro stejné služby, zaplatit technický dluh, co brzdí všechny, vybrat jeden způsob, jak dělat X. Nuda ≠ špatné — viz pravidlo „nudná technologie vyhrává“.
• Build vs. buy ve velkém. Na úrovni jedné featury je to drobnost; na úrovni oblasti je to nejdražší rozhodnutí (stavět vlastní platformu = roky závazku). Rozhoduj podle toho, jestli je daná věc tvoje konkurenční výhoda (stav) nebo režie (kup/použij hotové). Detaily v Tech Choices.
• Reverzibilní vs. nevratné. Rychlá, snadno vratná rozhodnutí dělej hned a sám. Nevratná (datový model, veřejné API, volba úložiště) zpomal, naber víc hlav a zapiš proč (ADR, viz Inženýrská praxe).
• Sázej s rozpočtem na omyl. Nikdy nevíš jistě. Dobrá sázka je ta, u které levně poznáš, že byla špatná, a dá se otočit (error budget myšlení z Reliability).

Conwayův zákon — organizace si tě formuje

„Systémy kopírují komunikační strukturu organizace, která je navrhuje.“ — Melvin Conway

Když tři týmy stavějí překladač, vznikne tříprůchodový překladač. Když má objednávka projít čtyřmi odděleními, vznikne čtyřkrokový pipeline s frontami mezi nimi. Hranice modulů a služeb dopadnou tam, kde jsou hranice mezi týmy — ať chceš, nebo ne.

Pro staffa to znamená dvě věci:

• Architektura je z půlky org design. Když dvě služby musejí pořád ladit rozhraní a navzájem se blokují, často to není technický problém, ale že je vlastní špatné týmy. Lék bývá přesun vlastnictví, ne další vrstva kódu.
• Inverse Conway maneuver. Chceš-li určitou architekturu (např. nezávisle nasaditelné služby), napřed uspořádej týmy tak, aby jim ta architektura přirozeně vyšla. Struktura týmů je páka na strukturu systému.

Vedení velké migrace — jako program, ne jako commit

Vyměnit databázi, rozseknout monolit nebo změnit formát dat pod živým provozem se nedělá jedním nasazením. Bezpečný vzor je expand-contract (parallel change): nikdy neměň staré a nové najednou, vždy je na chvíli provozuj vedle sebe.

Klíčové principy, které z toho dělají staff práci (ne jen technický postup):

• Každý krok je samostatně vratný. V jakékoli fázi umíš couvnout bez ztráty dat. To je celý smysl „vedle sebe“.
• Feature flag / postupný rollout. Přepínání řídí přepínač, ne nasazení. 1 % provozu, změř, přidej. (Viz deploy strategie v Infra & DevOps.)
• Backfill je idempotentní a dávkový. Milardu řádků nedopočítáš jedním dotazem — jedeš po dávkách, znovuspustitelně (viz idempotence a background jobs).
• Deprecation a sunset jsou součást plánu, ne „někdy potom“. Migrace není hotová, dokud staré nezmizí. Nedotažené migrace (obojí běží navěky) jsou nejdražší forma technického dluhu. Naplánuj datum vypnutí, oznam ho, měř, kdo ještě používá staré, a dotáhni to.

🚩 Nejčastější selhání migrace není technické — je to „doběhli jsme do 90 % a přešli na jiný projekt“. Zůstanou dva systémy, dvojí zápis a nikdo neví, který je pravda.

Vliv bez autority — jak prosadit směr, když nikomu nešéfuješ

Staff (IC dráha) nemá formální moc nikoho nutit. Páka je v přesvědčení a důvěře:

• Piš. Krátký design dok / RFC, který srozumitelně orámuje problém a možnosti, přesvědčí víc lidí než nejlepší řeč na schůzce — a škáluje (přečtou ho i lidi, co tam nebyli). Viz Inženýrská praxe.
• Dělej práci viditelnou. Prototyp, čísla z měření, malé demo. „Ukázal jsem, že to jde a stojí X“ poráží „myslím, že bychom měli“.
• Sbírej spojence předem. Velké rozhodnutí se nevyhrává na schůzce, ale v rozhovorech před ní. Zjisti námitky lidí dřív, zapracuj je — na schůzku přijď s konsenzem, ne s hádkou.
• Disagree and commit. Řekni nesouhlas jasně a jednou. Když padne jiné rozhodnutí, jdi za ním naplno — věčné podrývání zabíjí důvěru rychleji než omyl.
• Rozdávej kredit, ber vinu. Multiplikátor zvedá ostatní. Když tvoje páka roste tím, že je tým lepší, dlouhodobě vyhráváš.

Zvedat ostatní — od výkonu k multiplikaci

Nejde jen o tebe. Staff je „multiplier“: tvoje hodnota je čím dál víc v tom, o kolik jsi zrychlil ostatní.

• Mentoring a recenze jako investice, ne daň — dobrá code review učí celý tým (viz Inženýrská praxe).
• Standardy a paved road. Jeden dobrý vzor (šablona služby, sdílená knihovna, jasné „takhle to děláme“) ušetří desítkám lidí rozhodování. Pozor na druhý extrém — vnucený standard, co nikomu nesedí, je brzda.
• Píš věci dolů. Rozhodnutí, kontext, „proč“ (ADR, postmortemy). Znalost v hlavě jednoho člověka je single point of failure i organizačně.

Failure modes — jak se posun na staffa nepovede

• Hrdina, co píše všechen důležitý kód sám → krátkodobě skvělý, dlouhodobě brzda a bus-factor 1. Páka je nulová, protože nic nezvedá okolí.
• Architekt z věže ze slonoviny → diagramy bez kontaktu s realitou provozu; nikdo to nechce stavět.
• Strategie jako seznam featur → „uděláme A, B, C“ není strategie; chybí proč, co neděláme a jaké sázky.
• Migrace doběhnutá na 90 % → staré i nové běží navěky vedle sebe, dvojí pravda, nikdo nedotáhne sunset.
• Vliv silou, ne důvěrou → prosazuješ přes hlavu lidí; jednou vyhraješ, podruhé tě obejdou.
• Boj o technicky správné řešení za každou cenu → máš pravdu a prohraješ, protože jsi nikoho nepřesvědčil.

🛠️ Cvičení

1. Senior, nebo staff? U každé věty rozhodni, jestli popisuje seniorní, nebo staff práci, a proč: (a) „naimplementoval jsem platby přesně podle zadání“, (b) „zjistil jsem, že platby vůbec nemáme řešit my, a domluvil to s druhým týmem“, (c) „napsal jsem RFC, proč nestavět vlastní frontu“.
2. Rozhodni podle vratnosti. Roztřiď na „rozhodni hned sám“ vs. „zpomal a naber víc lidí“: změna názvu interní proměnné, volba hlavní databáze, formát veřejného API, barva tlačítka, schéma událostí v Kafce.
3. Naplánuj migraci. Měníš primární klíč z auto-increment ID na UUID v živé tabulce s miliony řádků. Popiš kroky expand-contract a u každého řekni, jak v něm umíš couvnout.
4. Conway v praxi. Dvě služby se pořád navzájem blokují kvůli jednomu sdílenému rozhraní, které musí měnit obě. Navrhni organizační (ne čistě technické) řešení.
5. Prosaď to. Chceš, aby tým přestal stavět tři skoro stejné notifikační systémy a sjednotil je. Nemáš žádnou formální autoritu. Napiš tři konkrétní kroky, jak to prosadíš.

🧠 Otázky & odpovědi