
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.


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.

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.

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.

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.

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.



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 | Číslo | Co to číslo měří |
|---|---|---|
| Gallup, data za rok 2025 | průměr 12,1, medián 5 až 6 | angažovanost; jedno správné rozpětí neexistuje, rozhoduje talent manažera a jeho vlastní individuální práce |
| Jellyfish | zhruba 1:6 až 1:9 ve výkonných organizacích jako Google, Microsoft a Amazon | poměr manažerů a vývojářů |
| Jade Rubick | 4 až 8 na začátku, 8 až 10, jak organizace dozrává, 12 „docela těžké“, 20 málokdy dobře | zralost organizace |
| Archetypy manažerů podle McKinsey | hrají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.

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.

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í.

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.

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á úloha | Skript, podle pravidel, bez tokenů | Claude | Čeká na Adamovo ano | Zů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í kontextu | každé 4 hodiny stáhne Jiru, Slack, e-mail, kalendář a CI | shrne dlouhá vlákna | nic, jen čte | rozhodnutí |
| Hledání rizik | označí updaty ve stavu Yellow a Red a prošlá data dev-complete | seřadí top pětku | nic, jen čte | co odblokovat první |
| Reporting statusu | vypíše změny v Jiře a vlákna na Slacku | napíše update, ukáže použitá pravidla | zveřejnění kdekoli | úpravy |
| Příprava na 1:1 | posbírá sdílený dokument s poznámkami, Slack a kanál funkce | napíše podklad a navrženou agendu | nic, jen čte | rozhovor |
| Kalendář (přidaný po té jizvě) | každý den zkontroluje 1:1 na další dva týdny | navrhne opravy | každou změnu | s 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.

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í.

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.

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.

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.

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]


