#059

Span of control: kolik podřízených je moc? S AI zvládneš 16+

· autor Marian Kamenistak

Anglická verze: /blog/how-many-direct-reports-too-many/

Před AI (Before AI) sedí Engineering Manager v klubku šipek mezi týmem a kolegy (Team & peers); po AI (After AI) je mezi manažerem a týmem vrstva AI, skriptů a dat (AI, Scripts, Data)

Takhle vypadá den AI-native Engineering Managera s 26 přímými podřízenými na EM Dashboardu, který jsme postavili spolu. Je to příklad složený z našich pravidel a obrazovek, ne zápis z deníku.

  • 9:00. Jeden seřazený seznam místo sedmi inboxů. Americké týmy přes noc pracovaly a odstavec od Clauda plus top pětka řeknou EM, co má řešit jako první.
  • 9:15. Dva status updaty se zpožďují. Dashboard ke každému připravil přátelské popostrčení a obě odejdou na jedno kliknutí.
  • 9:30 až 12:00. Čas na soustředěnou práci. Naše kalendářová pravidla drží dopoledne bez 1:1.
  • 13:00 až 17:00. Jedno 1:1 za druhým, pořád ve stejné zasedačce. Před každým si EM přečte podklad z poznámek, zpráv a kanálu funkce toho člověka, takže hodina patří jemu.
  • Jednou denně. Kontrola kalendáře projde dva týdny dopředu, hledá kolize v 1:1 a navrhne opravy. Nic se nepohne, dokud EM neřekne OK.
  • Pátky. Žádná 1:1. Dashboard napíše koncepty status updatů z Jiry a Slacku, EM je upraví a klikne na „Yes, post“.

Span of control, česky rozpětí řízení, je počet lidí, které jeden manažer vede přímo. Obvyklá odpověď pro Engineering Managera zní pět až osm. V datech Gallupu měl v roce 2025 mediánový manažer pět až šest přímých podřízených. Průměr byl 12,1, vytažený nahoru menšinou velmi širokých rozpětí.

Podle mě šlo u pěti až osmi od začátku o limit dispečinku. Manažer s osmi lidmi tráví týden přehazováním informací: kdo dluží update, který projekt nabírá skluz, co se stalo ve vlákně, kde nebyl, na co se zeptat na příštím 1:1. Vezmi manažerovi dispečink a lidskou část práce zvládne i pro víc než 16 lidí.

S jedním z mých mentees, budu mu říkat Adam, jsme postavili EM Dashboard, který mu dispečink z týdne odebral. V roce 2025 měla organizace 8 lidí v jednom týmu. Dnes je to 26 lidí ve třech týmech a všichni spadají přímo pod Adama. Díky dashboardu si Adam udržel stejnou pracovní dobu: „Mám rodinu a chci mít šťastnou ženu.“

S vedením týmů pomáhají dva team leadi. Každý z 26 má s Adamem pravidelné 1:1, jednou za dva týdny, nováčci první dva měsíce každý týden. To je zhruba 13 schůzek 1:1 týdně, o pár víc, dokud je někdo nový, a právě v kalendáři tě span of control stojí nejvíc.

Jak vypadá 26 lidí v 8 ráno

Než se dostaneme k tomu proč, tady je, jak EM Dashboard vypadá. Tři obrazovky níž, seřazený seznam, koncept statusu a podklad na 1:1, jsou překreslené z Adamovy aplikace. Ostatní jsou mock-upy, které jsme si načrtli pro inspiraci. Všechna jména a tikety jsou vymyšlené.

Jeden seřazený seznam místo sedmi inboxů

Americké týmy pracují, zatímco Adam spí, takže rána dřív začínala překvapeními. Teď první obrazovka stáhne Jiru, Slack, e-mail, kalendář, úkoly, CI a status updaty do jednoho seznamu: odstavec od Clauda, top pětka a pak všechno ostatní podle klesající priority.

Překreslená obrazovka aplikace: Today's Priorities (dnešní priority) se shrnutím od Clauda a seřazenou top pětkou ze sedmi zdrojů; ukázková data
Top pětka se řídí sepsanými pravidly o tom, co dokáže odblokovat jen Adam. Překresleno z Adamovy aplikace, ukázková data.
Obrazovka týmových cílů: cíle na Q4 pro tři týmy s progress bary, stavovými štítky a pravidly, která dva z nich označila; ilustrační mock-up, ukázková data
Devět cílů ve třech týmech, každý se stavovým štítkem a pravidlem, které ho nastavilo. Ilustrační mock-up, ukázková data.

Z každé položky se dá udělat Google Task se slotem v Adamově kalendáři. Seznam si pamatuje, co už je vyřízené, takže se položka vrátí, jen když se změní. „Teoreticky se to každý den zlepšuje,“ říká Adam.

Status updaty, které Adam jen schvaluje

Adam to říká na rovinu: „Nebaví mě psát status updaty.“ Každý pátek je dashboard napíše jako koncepty ze změn v Jiře a z diskuse na Slacku. Vedle konceptu vypíše, z čeho vycházel a jaká pravidla použil, formát, závislosti a tón, takže Adam práci zkontroluje a nemusí jí věřit naslepo.

Překreslená obrazovka aplikace: koncept status updatu se značkami Scope, Quality a Schedule (rozsah, kvalita, termín), jeho zdroji a pravidly a tlačítkem Yes, post; ukázková data
Páteční koncept se značkami Scope, Quality a Schedule a se zdroji, které Claude použil. Překresleno z Adamovy aplikace, ukázková data.

Adam upraví text v poli, klikne na „Yes, post“ a dashboard ho pošle do Jiry a na další místa, která proces vyžaduje, „protože naše procesy jsou bohužel hodně složité“. Dashboard proces neopraví. Jen mu nedovolí sníst Adamovi pátek.

Obrazovka reportů: jednostránkový týdenní report pro Adamova šéfa, u každého tvrzení jeho zdroj, a tlačítko k odeslání; ilustrační mock-up, ukázková data
Jednostránkový týdenní report pro Adamova šéfa, každé tvrzení označené zdrojem. Ilustrační mock-up, ukázková data.

Podklad před každým 1:1

Adam o téhle funkci říká, že je „nejkontroverznější“, a přitom z ní má největší radost. Před každým 1:1 dashboard přečte poznámky z minulého 1:1, e-maily toho člověka, jeho zprávy a DM na Slacku a kanál funkce, na které pracuje. Napíše podklad: co spolu probírali minule, otevřené body a kdo je vlastní, co stojí za to otevřít, vše s odkazem na zdroj, a navrženou agendu.

Překreslená obrazovka aplikace: podklad na 1:1 se sekcemi Last time, Open items a Worth raising (minule, otevřené body, stojí za zmínku) s odkazy na zdroje ve Slacku a se Suggested agenda (navržená agenda); ukázková data
Co si Adam čte pět minut před 1:1. Překresleno z Adamovy aplikace, ukázková data.

Jsou to osobní data, takže platí tři věci. Tým ví, co dashboard čte, Anthropic API běží na účtu schváleném firmou a nic, co se dotkne člověka, neodejde bez Adamova ano.

Adam je zhruba ve 150 kanálech na Slacku a nesleduje je. „Ale věděl bych, že ten člověk má problém,“ protože ho podklad vytáhne a dá se eskalovat ještě dřív, než 1:1 vůbec začne.

Obrazovka What's happening (co se děje): shrnutí noci od Clauda, feed podle týmů se štítky zdrojů a rámeček s tím, co nečte; ilustrační mock-up, ukázková data
Jeden feed místo 150 kanálů a seznam toho, co vynechává. Ilustrační mock-up, ukázková data.

Dispečink na obrazovce

Další tři dispečerské úlohy, celé rozdělení je v tabulce níž. Obrazovka kalendáře přijde později, s příběhem o tom, jak se rozbila.

Obrazovka statusů: sedm projektů s vlastníkem, pravidlem, podle kterého je update na řadě, a stavem zpoždění, vedle popostrčení na Slacku, které napsal Claude; ilustrační mock-up, ukázková data
Sedm projektů, pravidlo, podle kterého je každý update na řadě, a připravené popostrčení pro ten opožděný. Ilustrační mock-up, ukázková data.
Obrazovka zdrojů: pět karet zdrojů se staženými položkami a 0 AI tokeny, pod nimi vlákno na Slacku o 64 zprávách shrnuté Claudem; ilustrační mock-up, ukázková data
64 přečtených zpráv, na Adama zbylo jedno rozhodnutí. Ilustrační mock-up, ukázková data.
Obrazovka Risk radar (radar rizik): sedm projektů označených pravidly RK a SU, graf ohrožených položek za osm týdnů a top pětka seřazená Claudem; ilustrační mock-up, ukázková data
Pravidla riziko označí, Claude ho seřadí, Adam rozhodne, co je první. Ilustrační mock-up, ukázková data.

Pět až osm měří dispečink

Zeptej se čtyř zdrojů, kolik přímých podřízených je moc, a dostaneš čtyři čísla.

ZdrojČísloCo to číslo měří
Gallup, data za rok 2025průměr 12,1, medián 5 až 6angažovanost; jedno správné rozpětí neexistuje, rozhoduje talent manažera a jeho vlastní individuální práce
Jellyfishzhruba 1:6 až 1:9 ve výkonných organizacích jako Google, Microsoft a Amazonpoměr manažerů a vývojářů
Jade Rubick4 až 8 na začátku, 8 až 10, jak organizace dozrává, 12 „docela těžké“, 20 málokdy dobřezralost organizace
Archetypy manažerů podle McKinseyhrající trenér 3 až 5, koordinátor 15+jak velkou část práce tvoří koordinace

Čísla se rozcházejí, protože měří různé týdny. V řádku McKinsey nese nejvíc lidí role, která nejméně koučuje. Rozpětí se hýbe podle toho, co manažer celý den dělá, takže užitečná otázka zní, čím je vyplněný týden, ne kolik jmen visí na organigramu.

Gallup má ještě jedno číslo, které tady hraje roli. 97 % manažerů dělá i individuální práci, v mediánu asi 40 % svého času. Typický manažer tedy vede lidi zhruba třemi dny v týdnu. Něco musí povolit.

Nejsilnější argument proti širším rozpětím

John Farrier tvrdí opak: AI zvyšuje objem změn v týmu, ale nikomu nezvedá kapacitu je zreviewovat nebo koučovat lidi. Jeho slovy: „Když AI zvýší objem kódu, nepředpokládej, že můžeš rozšířit manažerské rozpětí.“ V review má pravdu. Adamovy týmy tráví reviewem kódu víc času než dřív, protože každý merge pořád schvaluje člověk.

Review práce, rozhovory o výkonu, nábor a odměňování vyžadují úsudek a žádný soubor s pravidly je neodstraní. Pravidlo ale může zmenšit, kolik z toho dopadne na manažera. Review potřebuje politiku: co dostane důkladné čtení, co se zkontroluje namátkou, kdo se dívá první. Nastavit tu politiku je práce manažera, a jakmile je sepsaná, manažer přestane sedět v každém review vlákně.

Kapacita na review je tedy reálná. Jen si nemyslím, že omezuje rozpětí na osm, protože statusy, kontext, rizika a příprava na 1:1 jsou ta část, kterou zvládne skript.

Týmy zrychlily. Adamův týden se zhoršil.

Tohle Adam naměřil u tří týmů, z Jiry a ze svého kalendáře.

Slide: vývojářské týmy až zhruba o 30 % rychlejší, doba od zahájení do dokončení kratší asi o 35 %, víc kódu čekajícího na review; IT manažer má víc závislostí, víc meetingů a 2,5× víc dvojitě obsazených hodin
Tři týmy, duben až září, 2025 vs. 2026. Jira a Adamův kalendář, průměry, zaokrouhleno.

Týmy zrychlily až zhruba o 30 % a doba od zahájení do dokončení klesla asi o 35 %. Na Adamově straně to šlo opačně: víc závislostí k hlídání, víc meetingů a 2,5krát víc hodin s dvojitě obsazeným kalendářem.

Adamovými slovy: „Musel jsem začít chodit na víc meetingů, synchronizace závislostí, nějaké eskalace, trackovací meetingy, a kalendář se mi začal úplně plnit. Občas jsem měl dvě, tři věci najednou a nikdo nevěděl, na kterou z nich přijdu.“

Adam poctivě přiznává výhrady: Adamova data zpracoval Claude, je to těžko kvantifikovatelné a AI nebyla jediná příčina. Urychlila problém, který tam už byl.

Těch 2,5krát měří samotný růst: duben až září 2026 proti stejným měsícům roku 2025, zatímco organizace narostla z 8 na 26 lidí. Čistší srovnání před a po dává plnění roadmapy. Adam začal dashboard používat v dubnu 2026, takže Q2 byl zčásti kvartál stavění a Q3 první celý kvartál s ním. V tom kvartálu týmy dodaly 81 % kvartální roadmapy, v Q2 2026 to bylo 55 %.

Adam taky počítá o 60 % méně přepínání kontextu a hlásí lepší spánek, víc času na soustředěnou práci a méně času ztraceného provozními problémy a hledáním, kde leží pravda. Jsou to Adamova vlastní čísla z jedné organizace, ne kontrolovaná studie. Organizace i AI nástroje se ve stejných měsících měnily, takže zásluhu nepřipisuju jen dashboardu. Lidská stránka, třeba angažovanost nebo jak těch 26 hodnotí svá 1:1, zatím měřená není.

Je to jeden případ naměřeného vzorce. V datech Faros AI týmy s vysokou adopcí AI mergovaly o 98 % víc PR a strávily o 91 % víc času jejich review. Faros prodává nástroje na měření a ta čísla jsou korelace, ber je tedy jako směr. V průzkumu developer experience od Atlassianu za rok 2025 ušetřilo 68 % vývojářů s AI víc než 10 hodin týdně, zatímco 50 % ztratilo 10+ hodin týdně, hlavně kvůli neefektivitě v organizaci.

Report DORA za rok 2025 to říká jednou větou: AI „zesiluje silné stránky výkonných organizací i dysfunkce těch, které se trápí“.

Adam vidí totéž o patro výš. „Podpůrné role, ať už manažeři, nebo PM, možná neškálují tak rychle.“ Někteří PM, které Adam zná, nestíhají psát PRD tak rychle, jak je jejich týmy dnes spotřebují.

Rychlejší týmy automaticky nedodávají víc. Přesunou frontu k lidem, kteří dělají dispečink, a ve většině týmů je tím člověkem Engineering Manager.

Vývojáři teď řídí agenty

V 1:1 slyší Adam pořád stejný příběh. Vývojář předá úkol agentovi, agent běží hodiny a jeden inženýr si teď do kanceláře nosí vlastní gripy na stolní fotbal, „protože jeho agent pracuje za něj“. Komentující na Hacker News, kterého cituje Addy Osmani, to řekl nejstručněji: „Už neprogramuješ, dohlížíš.“

„Z vývojářů se stávají manažeři agentů… To je v podstatě to, co jsem dělal jako manažer, a doufal jsem v to nejlepší,“ říká Adam. Někteří inženýři usoudili, že „tenhle nástroj není pro mě“, jiným je potřeba vysvětlit paralelní agenty „jako mechanismus větvení“ a podle Adama „je to hlavně o tom, jak to lidi mají v hlavě“. Ty rozhovory berou manažerovi čas a u 26 lidí ho musí vzít z dispečinku.

Než cokoli zautomatizuješ, sepiš si dispečink

Začali jsme seznamem toho, co Adam každý týden opakuje.

Slide: What do I repeat every week? (Co každý týden opakuju?) Nahánění status updatů, sbírání kontextu, hledání rizik, příprava na 1:1
U každé rutiny jsme si položili jednu otázku: kterou část zvládne AI a která potřebuje Adama?

Hledání rizik například znamená zachytit projekt, který má skončit příští kvartál, zatímco práce je „pořád na 10 %“. Ani jedna z těch čtyř věcí není leadership. Všechno je to dispečink a padá to na manažera, protože to „jak“ existuje jen v jeho hlavě.

Tak jsme to sepsali. Adam to nejdřív prošel s Claudem: „Začal jsem mluvit s Claudem, vysvětlil jsem mu, co dělám, a začali jsme psát pravidla.“ Každé pravidlo dostalo ID jako SU-5. Tady je pravidlo pro týdenní status:

# weekly-status.md
# Expect a weekly update when the project
- is in progress, has a dev-complete date,
  or has 2+ issues in the current sprint
# Flag it as at risk when
- the latest update is Yellow or Red
- dev-complete date passed, work still open
# When an update is overdue
- draft a short, friendly nudge
- send it only after I confirm

ID jsou tam kvůli těžkým rozhovorům. Když se projekt označí a někdo nesouhlasí, ukáže na SU-5. Jak říká Adam: „hádáme se o pravidlo, ne o pocity“.

Napsat pravidlo je ta těžká část a Adam to přiznává: „Na začátku je to ta těžká část.“ Manažer během pár sekund ví, že je projekt v ohrožení. Pojmenovat podmínky, které ho k tomu vedly, trvá déle, a právě to pojmenování je delegování.

Čím líp dokážeš vysvětlit svůj úsudek, tím spolehlivěji ho můžeš delegovat.

Pravidla běží ve skriptu. AI dostane jen to, co chce úsudek.

Tohle je část, kterou jsme stavěli spolu. Roky stavím dashboardy o efektivitě vývojářských týmů a díky nim jsem mohl vést 80+ týmů. S Adamem jsme ten nápad rozšířili o AI do EM Dashboardu, aby tech manažer trávil míň času provozními problémy a nevyhořel.

Adamova první verze před dvěma lety byla statická stránka, která jen ukazovala data. Spolu jsme 4 měsíce stavěli EM Dashboard na tom, co Adam skutečně potřebuje, s Augment Code a pak s Claude Code. Má 9 obrazovek a stojí zhruba 170 USD měsíčně za automatické datové pumpy a LLM volání, která pomáhají psát koncepty odpovědí.

Diagram na slidu: pět zdrojů krmí zhruba 100 pravidel, která běží jako kód každé 4 hodiny bez AI tokenů, a Anthropic API řeší jen shrnutí, koncepty a top pětku
„Můj agent neběží celý den. Běží skript a AI volá, jen když potřebuje úsudek.“

Pod obrazovkami je obyčejné potrubí. Datové pumpy stahují Jiru, Slack, e-mail, kalendář a CI každé 4 hodiny s přístupem jen pro čtení a ukládají surová data a vyčištěnou databázi lidí, projektů a updatů. Obyčejný skript pak nad touhle databází kontroluje zhruba 100 pravidel uložených v 5 souborech v prosté angličtině. Neutratí ani jeden AI token a dvakrát po sobě dá stejnou odpověď.

Adam vysvětluje, proč na tom záleží: „jakmile máš algoritmy, nespotřebováváš tokeny a databázi můžu obnovovat docela často, aniž bych utratil jediný token“.

Teprve když práce vyžaduje porozumění, zavolá skript Clauda přes Anthropic API, a to jen se záznamy, které pravidlo vybralo: shrnout dlouhé vlákno na Slacku, napsat koncept updatu, vybrat top pětku. Výsledek se vrátí do aplikace jako koncept, se zdroji a pravidly, které použil. Díky tomu je to levné, předvídatelné a snadno kontrolovatelné, protože pravidla jsou kód, který umíme přečíst.

Diagram ukazuje návrh, který jsme postavili.

Diagram architektury: pět zdrojů, datové pumpy každé 4 hodiny, úložiště na AWS, engine pravidel, Claude pro úsudek, aplikace a schvalovací brána před každým zápisem; ilustrační architektura
Pět zdrojů, datové pumpy, úložiště na AWS jako jedna z možností, engine pravidel, Claude pro úsudek a schvalovací brána před nástroji. Ilustrační architektura.

Druhé rozhodnutí v návrhu je hranice mezi čtením a jednáním. Všechno, co jen čte, běží samo; všechno, co se dotkne člověka, čeká na Adamovo ano. V praxi je to komentář v Jiře, popostrčení na Slacku, přesunutý meeting nebo report pro Adamova šéfa, a každá z těch věcí do té doby čeká v aplikaci.

Dispečerská úlohaSkript, podle pravidel, bez tokenůClaudeČeká na Adamovo anoZůstává Adamovi
Nahánění statusůkdo dluží update, co je pozděnapíše přátelské popostrčeníodeslání popostrčenírozhovor, když to dál sklouzává
Sbírání kontextukaždé 4 hodiny stáhne Jiru, Slack, e-mail, kalendář a CIshrne dlouhá vláknanic, jen čterozhodnutí
Hledání rizikoznačí updaty ve stavu Yellow a Red a prošlá data dev-completeseřadí top pětkunic, jen čteco odblokovat první
Reporting statusuvypíše změny v Jiře a vlákna na Slackunapíše update, ukáže použitá pravidlazveřejnění kdekoliúpravy
Příprava na 1:1posbírá sdílený dokument s poznámkami, Slack a kanál funkcenapíše podklad a navrženou agendunic, jen čterozhovor
Kalendář (přidaný po té jizvě)každý den zkontroluje 1:1 na další dva týdnynavrhne opravykaždou změnus kým se Adam potkává a jak často

Poslední sloupec je to, co Adamovi zůstává: rozhodnutí a rozhovory. Objem se přesunul do skriptu.

Obrazovka běhů: běhy každé 4 hodiny se staženými záznamy, spuštěnými pravidly, voláními Clauda, tokeny a cenou a měsíční náklady zhruba 170 USD; ilustrační mock-up, ukázková data
Všechny běhy v jedné tabulce, v každém pár volání Clauda. Ilustrační mock-up, ukázková data.

Dál chceme dostat měsíční náklady na modely a automatizace na zhruba 120 USD a začátkem Q1 2027 nasadit dashboard dalším týmům a jejich EM.

Přípravu jsme zautomatizovali, hodinu jsme si nechali

Proto má pro Adama podklad na 1:1 největší váhu: „Chci, aby ta schůzka plně patřila tomu člověku. Nechci strávit půlku 1:1 tím, na čem pracuješ a kde to je.“

Snadný způsob, jak přežít 16+ lidí, je natáhnout 1:1 na jednou měsíčně a statusovou debatu nechat v těch, která zbydou. Adam je nechal jednou za dva týdny a statusovou část přesunul do podkladu, takže hodina se vrátila tomu člověku.

Gallup dává důvod, proč tu hodinu neškrtat. Ze zaměstnanců, kteří rozhodně souhlasí, že za poslední týden dostali smysluplný feedback, je zhruba 7 z 10 angažovaných. Z těch, kteří ho nedostali, zhruba 1 ze 4.

Feedback je ta část, kterou může dát jen manažer. Psal jsem o tom, k čemu je dobré 1:1, a o tom, jak se ptát místo sbírání statusů. Podklad je to, co tohle umožní i u 26 lidí.

Adam si tu hranici hlídá. „Pomáhá mi to s přípravou, ale rozhovor pořád vedu já. Je to podpůrný nástroj, ne nástroj, který mi řekne, co mám tomu člověku říct nebo co s ním mám dělat.“

„Jeho agent si stěžoval mému agentovi“

Téhle části celého případu věřím nejvíc, protože jsem viděl, jak se rozbila.

V srpnu přišla do Adamova týmu nová přímá podřízená a Adam s ní chtěl mít týdenní 1:1 na 45 minut. Volný slot nebyl. Adam se zeptal Clauda a ani Claude žádný nenašel. Prošel srpen, září a říjen a vrátil se s odpovědí: když dodržím všechna pravidla, která jsi mi dal, místo není.

Slide: Rebuild 26 recurring 1:1s with Claude (přestavět 26 pravidelných 1:1 s Claudem) podle tabulky pravidel: jen odpoledne, v pátek žádná 1:1, respektovat posilovnu, dojíždění a pevné meetingy, místnost pro každé 1:1
Tabulka, kterou Adam koncem srpna dal Claudovi.

Kalendář byl mapou toho, jak rychle organizace rostla. Každý nový člověk dostal 1:1 tam, kde se to zrovna vešlo. „Musel jsem udělat defragmentaci kalendáře.“

Adam tedy napsal tabulku výš, jeden řádek na člověka a nahoře kalendářová pravidla. Napasovat 26 lidí kolem těch pravidel ručně by byla „noční můra“, takže Claude měl všech 26 pravidelných 1:1 zrušit a založit znovu.

Než Claude sáhl na jedinou pozvánku, Adam dal týmu vědět na Slacku: „Upozornění, Claude za mě dělá tyhle změny.“

Co se mohlo pokazit? Časová pásma jsou ten zřejmý tip. Horší by byly soukromé poznámky z 1:1 nasdílené špatným lidem a Adam přiznává, že na to vůbec nemyslel.

O tři dny později odpověděl ve vlákně jeden z inženýrů. Nový slot se střetl s jeho existujícím 1:1 s kolegou. Pod zprávou malým šedým písmem: „Sent using @Claude.“

Adam to shrnul: „Jeho agent si stěžoval mému agentovi.“

Adam se vrátil za Claudem: Říkal jsem ti, ať před přesunem 1:1 zkontroluješ kalendáře všech.

„Máš naprostou pravdu,“ řekl Claude. Adamova odpověď byla méně zdvořilá: oprav ten slot, jdi se omluvit a postarej se, aby lidi pochopili, čí to byla chyba.

Claude tedy napsal do vlákna vlastním jménem: „Tohle je trochu trapné. Je to čistě moje chyba. Dobrá zpráva je, že už je to opravené.“ Celý tým se smál, protože si teď kalendář mezi sebou řešili dva agenti.

Stálo to druhý, opravený běh a byla to jediná chyba z 26 přesunutých schůzek. Od té doby sedí Adam v den 1:1 celé odpoledne ve stejné zasedačce a lidi se u něj jen střídají.

Pak jsme přidali mantinel, který prvnímu běhu chyběl. Každý den teď agent kontroluje 1:1 na další dva týdny: Adamův kalendář, kalendář druhého člověka a místnost. Navrhuje opravy.

Obrazovka kalendáře: přestavba 26 pravidelných 1:1 zkontrolovaná proti šesti pravidlům, s jednou označenou kolizí a opravou od Clauda; ilustrační mock-up, ukázková data
26 schůzek 1:1 zkontrolovaných proti šesti kalendářovým pravidlům, s označenou kolizí jednoho nováčka. Ilustrační mock-up, ukázková data.

Vzali jsme si z toho jedno ponaučení. Delegování na AI neodstraňuje odpovědnost. Mění to, co musíš ověřit.

Člověk by při čtení tabulky pravidel zkontroloval i kalendář druhé strany, aniž by mu to někdo říkal. Claude udělal, co v tabulce stálo, a nic víc.

Deleguj práci. Odpovědnost si nech.

Tahle jizva formuje pravidla, podle kterých Adam vede tým. Vycházejí z Adamových tří principů pro rok 2027.

Slide: tři principy pro rok 2027: 1 people first (lidi na prvním místě), 2 scale yourself with AI (škáluj sám sebe s AI), 3 delegate the work, keep the responsibility (deleguj práci, odpovědnost si nech)
Adamovy tři principy pro rok 2027.

Jdi příkladem

Adam otevřeně sdílí, jak AI používá, včetně toho, co nefunguje. Když se experiment rozbije, Adam se tomu s týmem společně zasměje. Od inženýrů čeká, že budou AI používat, ale nástroje jim nepředepisuje.

Mluv se mnou přes svého agenta, pokud to dává smysl

„Je úplně v pořádku, když se se mnou někdo rozhodne komunikovat přes svoje agenty, pokud to dává smysl. Je v pořádku, když přes agenta napíše celý dokument, pokud to není AI vata na 60, 70 stran a pořád se pod to dokáže podepsat.“

Víc výstupu neznamená vyšší produktivitu

PRD na 20 stran vygeneruješ za pár minut. Když pak všechny stojí hodiny ho zreviewovat, tým nezrychlil. Inženýři vlastní to, co jejich agenti vyprodukují, a manažeři a lídři vlastní i výsledky.

„To udělal můj agent“ není výmluva

„Bude hrozně snadné říct: není to moje chyba, to udělal můj agent. Odpovědný je vždycky ten, kdo agenta spustil. Jinak to bude opravdová noční můra.“

To platí i pro Adama. Chyba v kalendáři byla Adamova a omluva odešla, protože o ni Adam požádal. Zprávy týmu na Slacku píše Adam taky osobně, protože mají znít jako Adam.

Claude se ozve jednou. Nejlepší lidi se hádají dál.

Ze tří principů je první ten o lidech.

„AI se se mnou málokdy hádá dál. Jednou se se mnou pohádat může, ale jakmile jí řeknu ‚ne, pokračuj‘, udělá to. Tvoji nejlepší lidi se s tebou hádat budou. Když něco smrdí, půjdou a budou se ti snažit dokázat, že mají pravdu.“

AI se málokdy hádá dál. Tvoji nejlepší lidi ano.

Tohle je ta část práce, kterou systém chrání. Manažer, který celý týden dělá dispečink, nemá čas vyslechnout inženýra, který nesouhlasí. Manažer, jehož dispečink běží na pravidlech, ho má.

Proto na to Adam taky nebyl sám. Na otázku, jak si u 26 lidí udržet stejnou mentální kapacitu, jmenoval Adam lidi dřív než nástroje: „Mít správné lidi a správný tým je podle mě klíčové.“

Na otázku, co hledá u třetího team leada, Adam vyjmenoval lidi na prvním místě, komunikaci, schopnost pracovat s AI a nastavovat priority. A ještě jeden test: když jejich tým roste, „počtem lidí nebo počtem agentů“, udrží tempo, takže „bych nemusel řešit, jak škálovat tohohle člověka“.

Tvůj první AI workflow pro řízení, ještě tento týden

Na začátek nepotřebuješ devět obrazovek ani vlastní aplikaci. My jsme začali jedním pravidlem.

Slide: Your first AI management workflow (tvůj první AI workflow pro řízení) ve čtyřech krocích: vyber jeden úkol, napiš 3 až 5 pravidel, nech AI je aplikovat a oprav pravidla, pusť je znovu s každým novým modelem
Čtyři kroky. První se vejde do jednoho odpoledne.

1. Vyber jeden opakující se manažerský úkol

Dobrý kandidát je ten, kterého se v pátek děsíš. U nás to byla týdenní kontrola statusů.

2. Sepiš, jak o něm rozhoduješ, jako 3 až 5 pravidel

Jestli ti psaní nejde, nech agenta, ať tě vyzpovídá. Otevři Clauda nebo ChatGPT a napiš: chci tohle zautomatizovat, ptej se mě a na konci mi napiš MD soubor s pravidly.

Adamův příklad pro páteční kontrolu statusů: „Každý pátek kontroluju, jestli jsou moje projekty na dobré cestě. Tady je pět věcí, na které se dívám. Pomoz mi vyhodnotit updaty z tohoto týdne.“

3. Nech AI pravidla aplikovat a oprav je tam, kde se mýlí

Na začátku „tokeny neřeš“. Pusť všechno přes AI a dívej se na výstup. Když je špatně, neopravuj výsledek ručně.

„Jdi a oprav pravidla, ať to příště můžeš zopakovat.“ Do skriptu pravidla převeď později, až se přestanou měnit.

4. S každým novým modelem pusť stejná pravidla znovu

Některé Adamovy pokusy selhaly, protože se AI nedostala do firemního portálu nebo byl proces moc složitý. Adam to zkouší znovu s každým novým modelem, protože schopnosti se pořád posouvají. Stejný přístup pokrývá dohánění po dovolené, kvartální slide o zdraví tech oddělení i roční R&D dokumentaci z celého roku historie v Jiře.

Jestli chceš, aby si první soubor pravidel napsala celá skupina tvých manažerů v jedné místnosti, dělám tenhle případ i jako keynote a praktický workshop pro Engineering Managery.

Než vezmeš 16

Velká rozpětí se manažerům obvykle stanou, nevyberou si je. Zamrzne náhrada za člověka, který odešel, „protože tým teď má Copilot“, reorganizace sloučí dva týmy a o rok později má manažer 14 lidí a pořád stejný týden. O tomhle plíživém posunu jsem psal v textu co AI agenti mění pro manažera první linie. Šestnáct lidí, kteří se ti stali, a šestnáct lidí, pro které sis postavil systém, jsou dvě různé práce.

Než tedy řekneš ano šestnácti lidem, zkontroluj tři věci.

Dokážeš svůj dispečink sepsat?

Když neumíš vyjmenovat pět věcí, které každý týden děláš, aby tým věděl, co potřebuje, nepředáš je skriptu. Začni tam, ještě před reorganizací.

Komu patří tvůj kalendář?

Zlom přišel pro Adama s jednou větou: „Stěžovat si šéfovi, že mám moc práce nebo moc meetingů, není řešení. Nikdo to za mě nevyřeší. Musím být advokátem svého kalendáře, svého času a svých priorit.“

Kdo ti pomůže těch 16 lidí utáhnout?

Adam má po boku dva silné team leady. V textu o kariérním rozcestí roku 2027 jsem psal, že tým zůstane kolem osmi lidí. To platí pro manažera, který pořád dělá celý dispečink ručně. Tenhle případ ukazuje, jak vypadá druhá strana toho rozcestí, když dispečink běží na pravidlech.

Kterou ze svých týdenních rutin bys do pátku dokázal sepsat jako pět pravidel? Jestli s tím chceš pomoct pro skupinu svých manažerů, na to je Firemní mentor. Jestli jde jen o tebe a tvůj kalendář, začni s mentoringem pro AI Engineering Managery.

[Čas psaní: 6 h]

Časté dotazy

Kolik přímých podřízených je pro Engineering Managera moc?

+

Většina rad dává limit pět až osm a Gallup v roce 2025 naměřil u amerického manažera medián pět až šest přímých podřízených. Ten limit platí, dokud manažer přehazuje statusy, kontext, rizika a přípravu na 1:1 ručně. Jakmile tyhle rutiny běží jako sepsaná pravidla, skript a koncepty od AI, dá se zvládnout 16 lidí i víc: Engineering Manager, kterého mentoruju, vede 26 přímých podřízených, s každým má 1:1 jednou za dva týdny a pomáhají mu dva team leadi. Samotné 1:1 zůstává lidské.

Pomůže AI manažerovi zvládnout víc přímých podřízených?

+

Ano, pokud AI převezme přehazování informací, a ne lidi. V EM Dashboardu, který jsme postavili s Engineering Managerem, kterého mentoruju, běží zhruba 100 sepsaných pravidel jako skript každé čtyři hodiny bez jediného AI tokenu a Claude dostává jen shrnutí, koncepty a pět hlavních priorit. Organizace narostla z 8 na 26 přímých podřízených a díky dashboardu si EM udržel stejnou pracovní dobu. V Q3 2026, prvním celém kvartálu s dashboardem, týmy dodaly 81 % kvartální roadmapy, v Q2 2026 to bylo 55 %. Jsou to vlastní čísla toho EM z jedné organizace, ne kontrolovaná studie.

Jak se s AI připravit na 1:1, aniž by AI vedla rozhovor?

+

Nech AI sestavit podklad jen z práce: sdílené poznámky z minula, otevřené body a kdo je vlastní, a co ten člověk otevřel na Slacku nebo v kanálu funkce, na které pracuje, vždy s odkazem na zdroj. Přečti si ho pět minut předem a rozhovor pak veď sám. Když status z 1:1 zmizí, hodina může patřit tomu člověku.

Jak automatizovat status updaty v tech týmu?

+

Nejdřív napiš pravidlo: kdy projekt dluží update, kdy se počítá jako ohrožený a co se stane, když update přijde pozdě. Skript ho pak aplikuje na Jiru, Slack a status komentáře, AI napíše koncept updatu a ukáže, z jakých zdrojů a pravidel vycházela, a ty koncept upravíš dřív, než se odešle.

Co by manažer nikdy neměl delegovat na AI agenta?

+

Odpovědnost za výsledek a rozhovor s člověkem. Agent umí napsat koncept, seřadit a naplánovat, ale když přesune meeting nebo popožene kolegu, za výsledek odpovídá manažer, který ho spustil. Pravidlo, které jsme si s Engineering Managerem, kterého mentoruju, nastavili poté, co agent naplánoval 1:1 do obsazeného termínu: všechno, co jen čte, běží samo; všechno, co se dotkne člověka, čeká, až EM řekne ano.

Nové články rovnou do mailu.