Rozpiętość kierowania: 16+ podwładnych dzięki AI

Tak wygląda dzień Engineering Managera, który pracuje w trybie AI-native i ma 26 bezpośrednich podwładnych. Wszystko przechodzi przez EM Dashboard, który zbudowaliśmy razem. To przykład złożony z naszych reguł i ekranów, a nie wpis z pamiętnika.

• 9:00. Jedna lista według priorytetów zamiast siedmiu skrzynek. Zespoły w USA pracowały w nocy, a akapit od Claude’a i pierwsza piątka mówią EM, czym zająć się najpierw.
• 9:15. Dwie aktualizacje statusu się spóźniają. Dashboard przygotował do każdej przyjazne ponaglenie i oba wychodzą jednym kliknięciem.
• 9:30 do 12:00. Czas na skupienie. Nasze reguły kalendarza trzymają poranki wolne od 1:1.
• 13:00 do 17:00. Spotkania 1:1, jedno po drugim, w tej samej sali. Przed każdym EM czyta brief zbudowany z notatek, wiadomości i kanału funkcji danej osoby, więc godzina należy do człowieka.
• Raz dziennie. Sprawdzanie kalendarza patrzy dwa tygodnie do przodu, szuka kolizji w 1:1 i proponuje poprawki. Nic się nie przesuwa, dopóki EM nie powie OK.
• Piątki. Bez 1:1. Dashboard przygotowuje szkice aktualizacji statusu z Jira i Slacka, EM je poprawia i klika „Yes, post”.

Rozpiętość kierowania (span of control) to liczba osób, którymi jeden manager kieruje bezpośrednio. Typowa odpowiedź dla Engineering Managera to od pięciu do ośmiu. Według danych Gallupa mediana w 2025 roku wynosiła od pięciu do sześciu bezpośrednich podwładnych. Średnia to 12,1, zawyżona przez mniejszość bardzo szerokich zespołów.

Moim zdaniem pięć do ośmiu od początku było limitem obiegu informacji. Manager z ośmioma osobami spędza tydzień na przesuwaniu informacji: kto jest winien aktualizację, który projekt się obsuwa, co wydarzyło się w wątku, w którym go nie było, o co zapytać na następnym 1:1. Zdejmij z managera obieg informacji, a na samą pracę z ludźmi wystarczy go na ponad 16 osób.

Z jednym z moich mentee, nazwę go Adam, zbudowaliśmy EM Dashboard, który zdejmuje obieg informacji z jego tygodnia. W 2025 roku organizacja liczyła 8 osób w jednym zespole. Dziś to 26 osób w trzech zespołach i wszystkie raportują do Adama. Dzięki dashboardowi Adam utrzymał te same godziny pracy: „Mam rodzinę i chcę mieć szczęśliwą żonę”.

Ma do pomocy dwóch Team Leadów. Każda z 26 osób ma z Adamem cykliczne 1:1, co dwa tygodnie, a nowe osoby co tydzień przez pierwsze dwa miesiące. To około 13 spotkań 1:1 tygodniowo, kilka więcej, kiedy ktoś jest nowy, i to właśnie w kalendarzu rozpiętość kierowania kosztuje najwięcej.

26 osób o ósmej rano

Zanim przejdę do tego, dlaczego, pokażę, jak wygląda EM Dashboard. Trzy ekrany poniżej, lista priorytetów, szkic statusu i brief przed 1:1, są odrysowane z aplikacji Adama. Pozostałe to makiety, które naszkicowaliśmy dla inspiracji. Wszystkie imiona i zadania są zmyślone.

Jedna lista według priorytetów zamiast siedmiu skrzynek

Zespoły w USA pracują, kiedy Adam śpi, więc poranki zaczynały się od niespodzianek. Teraz pierwszy ekran zbiera Jira, Slacka, e-mail, kalendarz, zadania, CI i aktualizacje statusu w jedną listę: akapit od Claude’a, pierwsza piątka, a potem cała reszta według malejącego priorytetu.

Każdą pozycję można zamienić w Google Task z miejscem w kalendarzu Adama. Lista pamięta, co już zostało załatwione, więc pozycja wraca tylko wtedy, gdy się zmieni. „Teoretycznie z każdym dniem jest coraz lepsza”, mówi Adam.

Aktualizacje statusu, które Adam tylko zatwierdza

Adam mówi to wprost: „Nie lubię pisać aktualizacji statusu”. W każdy piątek dashboard przygotowuje ich szkice na podstawie zmian w Jira i dyskusji na Slacku. Obok szkicu pokazuje, z czego skorzystał i jakie reguły zastosował, czyli format, zależności i ton, żeby Adam mógł sprawdzić tę pracę, zamiast jej po prostu ufać.

Adam poprawia tekst w polu, klika „Yes, post”, a dashboard publikuje go w Jira i w innych miejscach, których wymaga proces, „bo niestety nasze procesy są bardzo skomplikowane”. Dashboard nie naprawia procesu. Sprawia, że proces nie zjada Adamowi piątku.

Brief przed każdym 1:1

Adam nazywa tę funkcję „najbardziej kontrowersyjną” i to z niej jest najbardziej zadowolony. Przed każdym 1:1 dashboard czyta notatki z poprzedniego spotkania, e-maile tej osoby, jej wiadomości i DM-y na Slacku oraz kanał funkcji, nad którą pracuje. Potem pisze brief: o czym rozmawiali ostatnio, jakie sprawy są otwarte i kto za nie odpowiada, co warto poruszyć, każdy punkt z linkiem do źródła, a na końcu proponowaną agendę.

To dane osobowe, więc obowiązują trzy zasady. Zespół wie, co czyta dashboard, Anthropic API działa na koncie zatwierdzonym przez firmę, a nic, co dotyczy człowieka, nie wychodzi bez „tak” od Adama.

Adam jest na około 150 kanałach na Slacku i ich nie śledzi. „Ale wiedziałbym, że ta osoba ma problem”, bo brief to wyciąga na wierzch, i można to eskalować, zanim 1:1 w ogóle się zacznie.

Obieg informacji na ekranie

Trzy kolejne zadania z obiegu informacji, a pełny podział jest w tabeli niżej. Ekran kalendarza pojawi się później, razem z historią o tym, jak się zepsuł.

Pięć do ośmiu mierzy obieg informacji

Zapytaj cztery źródła, ilu bezpośrednich podwładnych to za dużo, a dostaniesz cztery liczby.

Liczby się nie zgadzają, bo mierzą różne tygodnie. W wierszu McKinseya rola, która najmniej czasu poświęca na coaching, ma najwięcej ludzi. Rozpiętość zmienia się razem z tym, czym manager zajmuje się przez cały dzień. Przydatne pytanie brzmi więc: co wypełnia jego tydzień, a nie ile nazwisk widnieje w schemacie organizacyjnym.

Gallup ma jeszcze jedną liczbę, która tu się liczy. 97% managerów wykonuje też pracę indywidualną, a mediana to około 40% ich czasu. Typowy manager prowadzi więc swoich ludzi przez mniej więcej trzy dni w tygodniu. Coś trzeba odpuścić.

Najmocniejszy argument przeciw szerszej rozpiętości

John Farrier argumentuje odwrotnie: AI zwiększa liczbę zmian w zespole, ale nie zwiększa niczyjej zdolności do ich przeglądania ani do coachingu ludzi. Jak pisze: „Kiedy AI zwiększa ilość kodu, nie zakładaj, że możesz poszerzyć rozpiętość zarządzania”. Co do code review ma rację. Zespoły Adama spędzają na przeglądaniu kodu więcej czasu niż wcześniej, bo każdy merge nadal zatwierdza człowiek.

Przegląd pracy, rozmowy o wynikach, rekrutacja i wynagrodzenia wymagają osądu i żaden plik z regułami ich nie usunie. Reguła wciąż może jednak zmniejszyć to, ile z tego spada na managera. Code review potrzebuje polityki: co dostaje dokładną lekturę, co jest sprawdzane wyrywkowo, kto patrzy pierwszy. Ustalenie tej polityki to decyzja managerska, a kiedy już jest spisana, manager przestaje siedzieć w każdym wątku przeglądu.

Ograniczenie po stronie przeglądu jest więc prawdziwe. Nie sądzę jednak, żeby zatrzymywało rozpiętość na ośmiu osobach, bo statusy, kontekst, ryzyka i przygotowanie do 1:1 to ta część, którą może przejąć skrypt.

Zespoły przyspieszyły. Tydzień Adama się pogorszył.

Oto co Adam zmierzył w trzech zespołach, na podstawie danych z Jira i własnego kalendarza.

Zespoły przyspieszyły nawet o około 30%, a czas od rozpoczęcia do ukończenia spadł o około 35%. Po stronie Adama było odwrotnie: więcej zależności do śledzenia, więcej spotkań i 2,5 raza więcej godzin, w których miał w kalendarzu dwa spotkania naraz.

Słowami Adama: „Musiałem zacząć chodzić na więcej spotkań, synchronizacje zależności, jakieś eskalacje, spotkania kontrolne, i mój kalendarz zaczął być w pełni zajęty. Czasem miałem dwa, trzy spotkania naraz i nikt nie wiedział, na które przyjdę”.

Adam uczciwie mówi o zastrzeżeniach: Claude przeliczył jego własne dane, trudno to skwantyfikować, a AI nie było jedyną przyczyną. Przyspieszyło problem, który już istniał.

Te 2,5 raza mierzy sam wzrost: kwiecień do września 2026 wobec tych samych miesięcy 2025, w czasie gdy organizacja urosła z 8 do 26 osób. Czystsze porównanie przed i po daje dowożenie roadmapy. Adam zaczął korzystać z dashboardu w kwietniu 2026, więc Q2 był częściowo kwartałem budowy, a Q3 pierwszym pełnym kwartałem z dashboardem. W tym kwartale zespoły dowiozły 81% kwartalnej roadmapy, wobec 55% w Q2 2026.

Adam liczy też 60% mniej przełączania kontekstu i mówi o lepszym śnie, większej ilości czasu na pracę w skupieniu oraz mniejszej stracie czasu na problemy operacyjne i na szukanie, gdzie leży prawda. To liczby samego Adama z jednej organizacji, a nie wynik kontrolowanego badania. Organizacja i narzędzia AI zmieniały się w tych samych miesiącach, więc nie przypisuję zasługi wyłącznie dashboardowi. Strona ludzka, na przykład zaangażowanie albo to, jak 26 osób ocenia swoje 1:1, nie jest jeszcze mierzona.

To jeden przypadek zmierzonego wzorca. W danych Faros AI zespoły z wysoką adopcją AI scalały o 98% więcej PR-ów i spędzały o 91% więcej czasu na ich przeglądzie. Faros sprzedaje narzędzia do pomiaru, a te liczby to korelacje, więc traktuj je jako kierunkowe. W badaniu Atlassiana o developer experience z 2025 roku 68% programistów oszczędzało dzięki AI ponad 10 godzin tygodniowo, a 50% traciło ponad 10 godzin tygodniowo, głównie przez nieefektywność organizacji.

Raport DORA 2025 mówi to jednym zdaniem: AI „wzmacnia mocne strony organizacji o wysokiej wydajności i dysfunkcje tych, które sobie nie radzą”.

Adam widzi to samo poziom wyżej. „Role wspierające, czy to managerowie, czy PM-owie, mogą nie skalować się tak szybko”. Niektórzy PM-owie, których Adam zna, nie nadążają z pisaniem PRD za tempem, w jakim ich zespoły je teraz przerabiają.

Szybsze zespoły nie dowożą automatycznie więcej. Przesuwają kolejkę do ludzi, którzy rozdzielają pracę, a w większości zespołów tą osobą jest Engineering Manager.

Inżynierowie zarządzają teraz agentami

Na 1:1 Adam słyszy tę samą historię. Programista oddaje zadanie agentowi, agent pracuje godzinami, a jeden z inżynierów przynosi teraz do biura własne rączki do piłkarzyków, „bo jego agent pracuje za niego”. Komentator z Hacker News, cytowany przez Addy’ego Osmaniego, ujął to najkrócej: „Już nie kodujesz, tylko nadzorujesz”.

„Programiści stają się managerami agentów… W zasadzie to samo robiłem jako manager i liczyłem, że jakoś to będzie”, mówi Adam. Część inżynierów uznała, że „to narzędzie nie jest dla mnie”, innym trzeba tłumaczyć równoległe agenty „jak mechanizm branchowania”, a dla Adama „tu naprawdę chodzi o nastawienie ludzi”. Te rozmowy zabierają managerowi czas, a przy 26 osobach ten czas musi pochodzić z obiegu informacji.

Spisz obieg informacji, zanim cokolwiek zautomatyzujesz

Zaczęliśmy od listy tego, co Adam powtarza co tydzień.

Wychwytywanie ryzyk to na przykład złapanie projektu, który powinien się skończyć w przyszłym kwartale, choć praca jest „wciąż na 10%”. Żadna z tych czterech rzeczy nie jest przywództwem. Wszystkie to obieg informacji i spadają na managera, bo wiedza o tym, jak je robić, siedzi tylko w jego głowie.

Więc to spisaliśmy. Adam najpierw omówił to z Claude’em: „Zacząłem rozmawiać z Claude’em, wyjaśniłem mu, co robię, i zaczęliśmy spisywać reguły”. Każda reguła dostała identyfikator, na przykład SU-5. Oto reguła cotygodniowego statusu:

# 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

Identyfikatory są potrzebne w trudnych rozmowach. Kiedy projekt zostaje oflagowany, a ktoś się z tym nie zgadza, wskazuje SU-5. Jak mówi Adam: „Kłócimy się o regułę, a nie o uczucia”.

Spisanie reguły to najtrudniejsza część i Adam to przyznaje: „Na początku to jest najtrudniejsze”. Manager w kilka sekund wie, że projekt jest zagrożony. Nazwanie warunków, które go do tego doprowadziły, trwa dłużej, i właśnie to nazwanie jest delegowaniem.

Im lepiej potrafisz wyjaśnić swój osąd, tym pewniej możesz go delegować.

Skrypt wykonuje reguły. AI dostaje tylko decyzje wymagające osądu.

To część, którą zbudowaliśmy razem. Od lat buduję dashboardy o efektywności zespołów deweloperskich i to dzięki nim mogłem kierować ponad 80 zespołami. Z Adamem rozwinęliśmy ten pomysł o AI i tak powstał EM Dashboard, dzięki któremu tech manager spędza mniej czasu na sprawach operacyjnych i się nie wypala.

Pierwsza wersja Adama, sprzed dwóch lat, była statyczną stroną, która tylko pokazywała dane. Przez 4 miesiące budowaliśmy razem EM Dashboard na prawdziwych przypadkach użycia Adama, najpierw z Augment Code, potem z Claude Code. Ma 9 ekranów i kosztuje około 170 USD miesięcznie, za zautomatyzowane pompy danych i wywołania LLM, które pomagają przygotowywać szkice odpowiedzi.

Pod ekranami to zwykła hydraulika. Pompy danych co 4 godziny pobierają dane z Jira, Slacka, e-maila, kalendarza i CI, z dostępem tylko do odczytu, i zapisują surowe zrzuty oraz oczyszczoną bazę ludzi, projektów i aktualizacji. Potem zwykły skrypt sprawdza na tej bazie około 100 reguł, zapisanych prostym językiem w 5 plikach. Nie zużywa ani jednego tokena AI i za każdym razem daje tę samą odpowiedź.

Adam wyjaśnia, dlaczego to ważne: „Kiedy masz algorytmy, nie zużywasz tokenów, i mogę odświeżać bazę dość często, nie wydając ani jednego tokena”.

Dopiero kiedy praca wymaga zrozumienia, skrypt woła Claude’a przez Anthropic API i przekazuje mu tylko rekordy wybrane przez regułę: żeby podsumował długi wątek na Slacku, przygotował szkic aktualizacji albo wybrał pierwszą piątkę. Wynik wraca do aplikacji jako szkic, razem ze źródłami i regułami, z których skorzystał. Dzięki temu jest tanio, przewidywalnie i łatwo to sprawdzić, bo reguły to kod, który możemy przeczytać.

Diagram odwzorowuje projekt, który zbudowaliśmy.

Drugi wybór projektowy to granica między czytaniem a działaniem. Wszystko, co tylko czyta, działa samo; wszystko, co dotyczy człowieka, czeka na „tak” od Adama. W praktyce to komentarz w Jira, ponaglenie na Slacku, przesunięte spotkanie albo raport dla szefa Adama, a każde z nich do tego momentu czeka w aplikacji.

Ostatnia kolumna to to, co zostaje dla Adama: decyzje i rozmowy. Cały wolumen przeszedł na skrypt.

Następnie planujemy obniżyć miesięczny koszt modeli i automatyzacji do około 120 USD, a na początku Q1 2027 wdrożyć dashboard w innych zespołach i u ich Engineering Managerów.

Zautomatyzowaliśmy przygotowanie, godzinę zostawiliśmy

Dlaczego brief przed 1:1 jest dla Adama najważniejszy? „Chcę, żeby to spotkanie w pełni należało do tej osoby. Nie chcę spędzać połowy 1:1 na tym, nad czym pracujesz i na jakim to jest etapie”.

Najprostszy sposób, żeby przetrwać 16+ osób, to przerzedzić 1:1 do jednego w miesiącu i zostawić rozmowę o statusie w tych, które przetrwały. Adam zostawił je co dwa tygodnie i przeniósł część statusową do briefu, więc godzina wróciła do człowieka.

Gallup podaje powód, żeby nie skracać tej godziny. Spośród pracowników, którzy zdecydowanie zgadzają się, że w ostatnim tygodniu dostali wartościowy feedback, zaangażowanych jest około 7 na 10. Wśród tych, którzy go nie dostali, około 1 na 4.

Feedback to ta część, którą może dać tylko manager. Pisałem o tym, do czego służy dobre 1:1, i o zadawaniu pytań zamiast zbierania statusów. Brief sprawia, że przy 26 osobach to wciąż jest możliwe.

Adam pilnuje tej granicy. „Pomaga mi się przygotować, ale to ja prowadzę rozmowę. To narzędzie wspierające, a nie narzędzie, które powie mi, co mam tej osobie powiedzieć albo co mam z nią zrobić”.

„Jego agent skarżył się mojemu agentowi”

Tej części historii ufam najbardziej, bo widziałem na własne oczy, jak się wysypała.

W sierpniu do zespołu Adama dołączyła nowa osoba i Adam chciał mieć z nią cotygodniowe, 45-minutowe 1:1. Nie było wolnego terminu. Adam zapytał Claude’a i Claude też żadnego nie znalazł. Przejrzał sierpień, wrzesień i październik i wrócił z odpowiedzią: nie ma miejsca, jeśli mam przestrzegać wszystkich reguł, które mi dałeś.

Kalendarz był mapą tego, jak szybko rosła organizacja. Każda nowa osoba dostawała 1:1 tam, gdzie akurat było miejsce. „Musiałem zrobić defragmentację kalendarza”.

Adam napisał więc arkusz widoczny wyżej, z jednym wierszem na osobę i regułami kalendarza na górze. Ręczne dopasowanie 26 osób do tych reguł byłoby „koszmarem”, więc Claude miał odwołać wszystkie 26 cyklicznych 1:1 i utworzyć je od nowa.

Zanim Claude dotknął choćby jednego zaproszenia, Adam napisał do zespołu na Slacku: „Uprzedzam, że Claude wprowadza te zmiany w moim imieniu”.

Co mogło pójść nie tak? Strefy czasowe to oczywisty strzał. Prywatne notatki z 1:1 udostępnione niewłaściwym osobom to gorszy scenariusz, a Adam przyznaje, że w ogóle o tym nie pomyślał.

Trzy dni później jeden z inżynierów odpisał w wątku. Nowy termin kolidował z jego dotychczasowym 1:1 z kolegą. Pod wiadomością, małymi szarymi literami: „Sent using @Claude”.

Adam podsumował to tak: „Jego agent skarżył się mojemu agentowi”.

Adam wrócił do Claude’a: mówiłem ci, żebyś sprawdził kalendarze wszystkich, zanim przesuniesz 1:1.

„Masz całkowitą rację”, odpowiedział Claude. Odpowiedź Adama była mniej uprzejma: popraw termin, przeproś wszystkich i dopilnuj, żeby ludzie zrozumieli, czyja to była pomyłka.

Claude napisał więc w wątku, we własnym imieniu: „Trochę mi głupio. To całkowicie moja pomyłka. Dobra wiadomość: już naprawione”. Cały zespół się śmiał, bo teraz dwa agenty AI ustalały kalendarz między sobą.

Potrzebne było drugie, poprawione uruchomienie i była to jedyna pomyłka na 26 przesuniętych spotkań. Od tamtej pory w popołudnie z 1:1 Adam siedzi godzinami w tej samej sali, a ludzie po prostu się zmieniają.

Potem dodaliśmy zabezpieczenie, którego zabrakło przy pierwszym uruchomieniu. Codzienny agent sprawdza teraz 1:1 na najbliższe dwa tygodnie: kalendarz Adama, kalendarz drugiej osoby i salę. Proponuje poprawki.

Wyciągnęliśmy z tego jedną lekcję. Delegowanie do AI nie usuwa odpowiedzialności. Zmienia to, co musisz zweryfikować.

Człowiek, czytając arkusz reguł, sprawdziłby kalendarz drugiej osoby bez proszenia. Claude zrobił to, co było w arkuszu, i nic więcej.

Deleguj pracę. Odpowiedzialność zostaw sobie.

Ta wpadka ukształtowała reguły, według których Adam prowadzi zespół. Wynikają z jego trzech zasad na 2027 rok.

Dawaj przykład

Adam otwarcie pokazuje, jak używa AI, łącznie z tym, co nie działa. Kiedy eksperyment się sypie, Adam i zespół śmieją się z tego razem. Adam oczekuje, że inżynierowie będą używać AI, ale nie narzuca narzędzi.

Rozmawiaj ze mną przez swojego agenta, jeśli to ma sens

„To zupełnie w porządku, jeśli ktoś zdecyduje się komunikować ze mną przez swoich agentów, o ile to ma sens. W porządku jest też, jeśli przez agenta napisze cały dokument, o ile to nie jest 60 czy 70 stron papki z AI i nadal jest w stanie się pod nim podpisać”.

Więcej materiału to jeszcze nie produktywność

PRD na 20 stron wygenerujesz w kilka minut. Jeśli jego przejrzenie kosztuje wszystkich godziny, zespół nie przyspieszył. Inżynierowie odpowiadają za to, co produkują ich agenty, a managerowie i liderzy też odpowiadają za wyniki.

„Mój agent to zrobił” to nie wymówka

„Bardzo łatwo będzie powiedzieć: to nie moja wina, to mój agent. Odpowiada zawsze osoba, która uruchomiła agenta. Inaczej to będzie prawdziwy koszmar”.

To dotyczy też Adama. Pomyłka z kalendarzem była jego i to on musiał wziąć ją na siebie, a przeprosiny poszły, bo Adam o nie poprosił. Wiadomości na Slacku do zespołu Adam też pisze osobiście, bo mają brzmieć jak on.

Claude zaprotestuje raz. Najlepsi ludzie będą się kłócić dalej.

Ludzie są pierwsi na liście trzech zasad.

„AI rzadko się ze mną dalej kłóci. Może zaprotestować raz, ale kiedy powiem mu »nie, rób«, zrobi to. Twoi najlepsi ludzie będą się z tobą kłócić. Jeśli coś jest podejrzane, pójdą i spróbują ci udowodnić, że mają rację”.

AI rzadko kłóci się dalej. Twoi najlepsi ludzie tak.

To ta część pracy, którą chroni system. Manager, który spędza tydzień na przekazywaniu informacji, nie ma już czasu wysłuchać inżyniera, który się nie zgadza. Manager, którego obieg informacji działa na regułach, ten czas ma.

Dlatego też Adam nie zrobił tego sam. Zapytany, jak zachować tę samą pojemność umysłową przy 26 osobach, wymienił ludzi przed narzędziami: „Mieć właściwych ludzi i właściwy zespół, to jest, powiedziałbym, klucz”.

Zapytany, czego szuka w trzecim liderze, Adam wymienił nastawienie na ludzi, komunikację, umiejętność pracy z AI i ustalania priorytetów. I jeszcze jeden test: kiedy ich zespół rośnie, „liczbą ludzi albo liczbą agentów”, utrzymują tempo, tak że „nie musiałbym się zastanawiać, jak skalować tę osobę”.

AI dla managerów: pierwszy workflow jeszcze w tym tygodniu

Nie potrzebujesz dziewięciu ekranów ani własnej aplikacji, żeby zacząć. My zaczęliśmy od jednej reguły.

1. Wybierz jedno powtarzalne zadanie managerskie

Dobrym kandydatem jest to, na myśl o którym w piątek robi Ci się słabo. U nas był to cotygodniowy przegląd statusu.

2. Spisz w 3 do 5 regułach, jak o nim decydujesz

Jeśli pisanie idzie opornie, niech agent przeprowadzi z Tobą wywiad. Otwórz Claude’a albo ChatGPT i napisz: chcę to zautomatyzować, zadawaj mi pytania, a na końcu napisz mi plik MD z regułami.

Przykład Adama na piątkowy przegląd statusu: „W każdy piątek sprawdzam, czy moje projekty idą zgodnie z planem. Oto pięć rzeczy, na które patrzę. Pomóż mi ocenić aktualizacje z tego tygodnia”.

3. Pozwól AI je stosować i poprawiaj reguły tam, gdzie się myli

Na początku „nie przejmuj się tokenami”. Puść wszystko przez AI i patrz na wynik. Kiedy jest zły, nie poprawiaj wyniku ręcznie.

„Idź i popraw reguły, żeby następnym razem dało się to powtórzyć”. Reguły zamień w skrypt później, kiedy przestaną się zmieniać.

4. Przy każdym nowym modelu uruchom te same reguły jeszcze raz

Część prób Adama się nie udała, bo AI nie mogło dostać się do firmowego portalu albo proces był zbyt złożony. Adam próbuje ponownie przy każdym nowym modelu, bo możliwości ciągle się przesuwają. To samo podejście sprawdza się przy nadrabianiu zaległości po urlopie, kwartalnym slajdzie o kondycji inżynierii i rocznej dokumentacji R&D z całego roku historii w Jira.

Jeśli wolisz, żeby pierwszy plik z regułami napisała cała grupa twoich managerów w jednej sali, prowadzę ten przypadek jako keynote i praktyczny warsztat dla Engineering Managerów, po angielsku lub po czesku.

Zanim weźmiesz 16 osób

Duża rozpiętość zwykle przytrafia się managerom, a nie jest ich wyborem. Etat po kimś, kto odszedł, zostaje zamrożony, „bo zespół ma teraz Copilota”, reorganizacja łączy dwa zespoły i rok później manager ma 14 osób i ten sam tydzień. O tym dryfie pisałem w tekście o tym, co agenty AI zmieniają dla managera pierwszej linii. Szesnaście osób, które Ci się przytrafiły, i szesnaście osób, pod które zbudowałeś system, to dwie różne prace.

Zanim więc powiesz „tak” szesnastu osobom, sprawdź trzy rzeczy.

Czy potrafisz spisać swój obieg informacji?

Jeśli nie potrafisz wymienić pięciu rzeczy, które co tydzień robisz, żeby zespół wiedział, co się dzieje, nie przekażesz ich skryptowi. Zacznij od tego, jeszcze przed reorganizacją.

Kto jest właścicielem Twojego kalendarza?

Punktem zwrotnym dla Adama było jedno zdanie: „Skarżenie się szefowi, że mam za dużo pracy albo za dużo spotkań, to nie jest rozwiązanie. Nikt tego za mnie nie rozwiąże. Muszę być adwokatem swojego kalendarza, swojego czasu i swoich priorytetów”.

Kto pomoże Ci udźwignąć 16 osób?

Adam ma obok siebie dwóch mocnych Team Leadów. W tekście o rozwidleniu kariery w 2027 roku pisałem, że zespół zostaje przy mniej więcej ośmiu ludziach. To prawda dla managera, który wciąż ręcznie przekazuje wszystkie informacje. Ten przypadek pokazuje, jak wygląda druga strona tego rozwidlenia, kiedy obieg informacji działa na regułach.

Które z Twoich cotygodniowych rutyn dałoby się do piątku spisać jako pięć reguł? Jeśli chcesz zbudować to dla grupy swoich managerów, do tego służy Mentor in Residence. Jeśli chodzi tylko o Ciebie i Twój kalendarz, zacznij od mentoringu dla AI Engineering Managera.

[Czas pisania: 6 h]