--- title: "Rozpiętość kierowania: 16+ podwładnych dzięki AI" description: "Rozpiętość kierowania od 5 do 8 osób to limit obiegu informacji. AI dla managerów w praktyce: EM prowadzi 26 podwładnych w tych samych godzinach." url: "https://www.marian.coach/pl/blog/how-many-direct-reports-too-many/" lang: "pl" image: "https://www.marian.coach/images/blog/how-many-direct-reports-too-many/infographic.webp" --- ![Przed AI Engineering Manager tkwi w plątaninie strzałek łączących go z zespołem i innymi managerami; po AI między managerem a zespołem stoi warstwa AI, skryptów i danych](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/infographic.webp) Z AI Dashboardem dla Engineering Managera przeszliśmy od chaosu do zarządzania ponad 16 bezpośrednimi podwładnymi ze wsparciem 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](https://www.gallup.com/workplace/700718/span-control-optimal-team-size.aspx) (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](https://www.gallup.com/workplace/700718/span-control-optimal-team-size.aspx). Ś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. ![Odrysowany ekran aplikacji: Today's Priorities z podsumowaniem od Claude'a i pierwszą piątką ułożoną z siedmiu źródeł; dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/ranked-list.webp) Pierwsza piątka wynika ze spisanych reguł o tym, co może odblokować tylko Adam. Odrysowane z aplikacji Adama, dane demo. ![Ekran celów zespołów: cele na Q4 dla trzech zespołów z paskami postępu, statusami i regułami, które oflagowały dwa z nich; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/team-goals-mock.webp) Dziewięć celów w trzech zespołach, każdy ze statusem i regułą, która go ustawiła. Poglądowa makieta, dane demo. 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ć. ![Odrysowany ekran aplikacji: szkic aktualizacji statusu ze znacznikami Scope, Quality i Schedule, jego źródłami i regułami oraz przyciskiem Yes, post; dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/status-draft.webp) Piątkowy szkic ze znacznikami Scope, Quality i Schedule oraz źródłami, z których skorzystał Claude. Odrysowane z aplikacji Adama, dane demo. 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. Raport dla szefa Adama przychodzi jako gotowy szkic. Adam go poprawia i klika „tak”. ![Ekran raportów: jednostronicowy cotygodniowy raport dla szefa Adama, w którym każde stwierdzenie ma oznaczone źródło, i przycisk wysyłki; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/manager-report-mock.webp) Jednostronicowy cotygodniowy raport dla szefa Adama, przy każdym stwierdzeniu jego źródło. Poglądowa makieta, dane demo. ### 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ę. ![Odrysowany ekran aplikacji: brief przed 1:1 z sekcjami Last time, Open items, Worth raising z podlinkowanymi źródłami ze Slacka i Suggested agenda; dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/one-on-one-brief.webp) To Adam czyta pięć minut przed 1:1. Odrysowane z aplikacji Adama, dane demo. 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. Adam wie, co się dzieje u 26 osób, i nie traci dodatkowego czasu na szukanie. ![Ekran What's happening: podsumowanie nocy od Claude'a, strumień pogrupowany według zespołów z oznaczeniami źródeł i ramka z tym, czego nie czyta; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/whats-happening-mock.webp) Jeden strumień zamiast 150 kanałów i lista tego, co pomija. Poglądowa makieta, dane demo. ### 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ł. ![Ekran statusów: siedem projektów z właścicielem, regułą, która wyznacza termin aktualizacji i stan spóźnienia, obok szkicu ponaglenia na Slacku od Claude'a; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/chasing-status-mock.webp) Siedem projektów, reguła, która wyznacza termin każdej aktualizacji, i szkic ponaglenia dla spóźnionego. Poglądowa makieta, dane demo. ![Ekran źródeł: pięć kart źródeł z liczbą pobranych pozycji i 0 tokenów AI, nad wątkiem ze Slacka liczącym 64 wiadomości, podsumowanym przez Claude'a; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/collecting-context-mock.webp) 64 przeczytane wiadomości, jedna decyzja zostawiona Adamowi. Poglądowa makieta, dane demo. ![Ekran radaru ryzyk: siedem projektów oflagowanych regułami RK i SU, wykres zagrożonych pozycji z ośmiu tygodni i pierwsza piątka ułożona przez Claude'a; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/spotting-risk-mock.webp) Reguły flagują ryzyko, Claude układa ranking, Adam decyduje, co najpierw. Poglądowa makieta, dane demo. ## 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. | Źródło | Liczba | Co mierzy ta liczba | | --- | --- | --- | | [Gallup, dane z 2025 roku](https://www.gallup.com/workplace/700718/span-control-optimal-team-size.aspx) | średnia 12,1, mediana 5 do 6 | zaangażowanie; nie ma jednej właściwej rozpiętości, decyduje talent managera i jego własna praca indywidualna | | [Jellyfish](https://jellyfish.co/blog/manager-to-engineer-ratio/) | około 1:6 do 1:9 w organizacjach o wysokiej wydajności, takich jak Google, Microsoft i Amazon | stosunek liczby managerów do inżynierów | | [Jade Rubick](https://www.rubick.com/span-of-control/) | 4 do 8 na początku, 8 do 10, gdy organizacja dojrzewa, 12 „dość trudne”, 20 rzadko robione dobrze | dojrzałość organizacji | | [Archetypy managerów według McKinseya](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/how-to-identify-the-right-spans-of-control-for-your-organization) | grający trener 3 do 5, koordynator 15+ | jaką część pracy stanowi koordynacja | 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ą](https://www.gallup.com/workplace/700718/span-control-optimal-team-size.aspx), 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](https://johnfarrier.com/engineering-manager-span-of-control-in-the-age-of-ai/): 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](https://www.marian.coach/blog/ai-agents-first-line-engineering-manager/), 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. ![Slajd: zespoły inżynierskie nawet o około 30% szybsze, około 35% mniej czasu od rozpoczęcia do ukończenia, więcej kodu czekającego na review; lider inżynierii ma więcej zależności, więcej spotkań i 2,5 raza więcej godzin z nakładającymi się spotkaniami](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/teams-faster-week-worse.webp) Trzy zespoły, od kwietnia do września, 2025 wobec 2026. Dane z Jira i kalendarza Adama, średnie, zaokrąglone. 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. Zespoły dowiozły 81% kwartalnej roadmapy w Q3 2026, wobec 55% w Q2 2026. Adam widzi, które cele idą zgodnie z planem, i nie musi nikogo ganiać. To jeden przypadek zmierzonego wzorca. W [danych Faros AI](https://www.faros.ai/blog/ai-software-engineering) 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](https://www.atlassian.com/blog/developer/developer-experience-report-2025) 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](https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/) 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](https://addyo.substack.com/p/the-80-problem-in-agentic-coding), 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ń. ![Slajd: co powtarzam co tydzień? Ganianie za aktualizacjami statusu, zbieranie kontekstu, wychwytywanie ryzyk, przygotowanie do 1:1](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/weekly-routines.webp) Przy każdej rutynie zadawaliśmy jedno pytanie: którą część może zrobić AI, a która potrzebuje Adama? 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. ![Slajd z diagramem: pięć źródeł zasila około 100 reguł uruchamianych jako kod co 4 godziny bez tokenów AI, a Anthropic API obsługuje tylko podsumowania, szkice i pierwszą piątkę](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/rules-as-code.webp) „Mój agent nie działa cały dzień. Działa skrypt, który woła AI tylko wtedy, gdy potrzebny jest osąd”. 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. ![Diagram architektury: pięć źródeł, pompy danych co 4 godziny, przechowywanie na AWS, silnik reguł, Claude do decyzji wymagających osądu, aplikacja i bramka zatwierdzania przed każdym zapisem; architektura poglądowa](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/architecture-diagram.webp) Pięć źródeł, pompy danych, przechowywanie na AWS jako jedna z opcji, silnik reguł, Claude do osądu i bramka zatwierdzania przed narzędziami. Architektura poglądowa. 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. | Zadanie z obiegu informacji | Skrypt, według reguły, bez tokenów | Claude | Czeka na „tak” od Adama | Zostaje przy Adamie | | --- | --- | --- | --- | --- | | Ganianie za statusem | kto jest winien aktualizację, co się spóźnia | przygotowuje przyjazne ponaglenie | wysłanie ponaglenia | rozmowa, gdy projekt dalej się obsuwa | | Zbieranie kontekstu | co 4 godziny pobiera dane z Jira, Slacka, e-maila, kalendarza i CI | podsumowuje długie wątki | nic, tylko czyta | decyzja | | Wychwytywanie ryzyk | flaguje aktualizacje Yellow i Red oraz minione daty dev-complete | układa pierwszą piątkę | nic, tylko czyta | co odblokować najpierw | | Raportowanie statusu | wylicza zmiany w Jira i wątki na Slacku | przygotowuje szkic aktualizacji, pokazuje zastosowane reguły | publikacja gdziekolwiek | poprawki | | Przygotowanie do 1:1 | zbiera wspólny dokument z notatkami, Slacka i kanał funkcji | pisze brief i proponowaną agendę | nic, tylko czyta | rozmowa | | Kalendarz (dodany po wpadce) | codziennie sprawdza 1:1 na najbliższe dwa tygodnie | proponuje poprawki | każda zmiana | z kim Adam się spotyka i jak często | Ostatnia kolumna to to, co zostaje dla Adama: decyzje i rozmowy. Cały wolumen przeszedł na skrypt. ![Ekran uruchomień: przebiegi co 4 godziny z liczbą pobranych rekordów, odpalonych reguł, wywołań Claude'a, tokenów i kosztem oraz miesięczny koszt około 170 USD; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/pipeline-run-mock.webp) Każde uruchomienie w jednej tabeli, w każdym po kilka wywołań Claude’a. Poglądowa makieta, dane demo. 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](https://www.gallup.com/workplace/700718/span-control-optimal-team-size.aspx). 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](https://www.marian.coach/blog/one-on-ones/), i o [zadawaniu pytań zamiast zbierania statusów](https://www.marian.coach/blog/manager-as-coach/). 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ś. ![Slajd: odbuduj z Claude'em 26 cyklicznych 1:1 z arkusza reguł: tylko popołudnia, bez 1:1 w piątki, szanuj siłownię, dojazdy i stałe spotkania, sala dla każdego 1:1](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/rebuild-26-one-on-ones.webp) Arkusz, który Adam dał Claude’owi pod koniec sierpnia. 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. Claude odbudował 26 cyklicznych 1:1 z jednego arkusza reguł. Jedno poszło źle i nauczyło nas, co trzeba weryfikować. ![Ekran kalendarza: odbudowa 26 cyklicznych 1:1 sprawdzona według sześciu reguł, z jedną oflagowaną kolizją i poprawką od Claude'a; poglądowa makieta, dane demo](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/calendar-rebuild-mock.webp) 26 spotkań 1:1 sprawdzonych według sześciu reguł kalendarza, z oflagowaną kolizją jednej nowej osoby. Poglądowa makieta, dane demo. 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. ![Slajd: trzy zasady na 2027: 1 najpierw ludzie, 2 skaluj siebie z AI, 3 deleguj pracę, zachowaj odpowiedzialność](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/three-principles.webp) Trzy zasady Adama 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. ![Slajd: Twój pierwszy workflow AI w zarządzaniu w czterech krokach: wybierz jedno zadanie, spisz 3 do 5 reguł, pozwól AI je stosować i poprawiaj reguły, uruchamiaj je ponownie przy każdym nowym modelu](https://www.marian.coach/images/blog/how-many-direct-reports-too-many/first-ai-workflow.webp) Cztery kroki. Pierwszy zmieści się w jedno popołudnie. ### 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](https://www.marian.coach/speaker/ai-engineering-manager/), 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](https://www.marian.coach/blog/ai-agents-first-line-engineering-manager/). 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](https://www.marian.coach/blog/ai-engineering-manager-2027/) 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](https://www.marian.coach/mentor-in-residence/). Jeśli chodzi tylko o Ciebie i Twój kalendarz, zacznij od [mentoringu dla AI Engineering Managera](https://www.marian.coach/ai-engineering-manager-mentor/). \[Czas pisania: 6 h\] ## Najczęstsze pytania ### Ilu bezpośrednich podwładnych to za dużo dla Engineering Managera? + Większość porad stawia granicę na pięciu do ośmiu osobach, a według danych Gallupa z 2025 roku mediana dla managera w USA to pięciu do sześciu bezpośrednich podwładnych. Ta granica obowiązuje, dopóki manager ręcznie przekazuje statusy, kontekst, ryzyka i przygotowanie do 1:1. Kiedy te rutyny działają jako spisane reguły, skrypt i szkice od AI, 16 osób i więcej jest do udźwignięcia: Engineering Manager, którego mentoruję, prowadzi 26 bezpośrednich podwładnych, ma z nimi 1:1 co dwa tygodnie i dwóch Team Leadów do pomocy. Samo 1:1 zostaje ludzkie. ### Czy AI może pomóc managerowi prowadzić więcej bezpośrednich podwładnych? + Tak, jeśli AI przejmuje obieg informacji, a nie ludzi. W EM Dashboard, który zbudowaliśmy z Engineering Managerem, którego mentoruję, około 100 spisanych reguł działa jako skrypt co cztery godziny, bez tokenów AI, a Claude dostaje tylko podsumowania, szkice i pierwszą piątkę priorytetów. Organizacja urosła z 8 do 26 bezpośrednich podwładnych, a dashboard to sposób, w jaki EM utrzymał te same godziny pracy. W Q3 2026, pierwszym pełnym kwartale z dashboardem, zespoły dowiozły 81% kwartalnej roadmapy, wobec 55% w Q2 2026. To liczby samego EM z jednej organizacji, a nie wynik kontrolowanego badania. ### Jak przygotować się do 1:1 z pomocą AI i nie oddać mu rozmowy? + Niech AI zbuduje brief wyłącznie z pracy: ze wspólnych notatek z poprzedniego spotkania, otwartych spraw i ich właścicieli oraz z tego, co dana osoba poruszyła na Slacku albo na kanale swojej funkcji, przy każdym punkcie z linkiem do źródła. Przeczytaj go pięć minut przed spotkaniem, a rozmowę poprowadź sam. Kiedy status znika z 1:1, ta godzina może należeć do drugiej osoby. ### Jak zautomatyzować aktualizacje statusu w zespole inżynierskim? + Najpierw spisz regułę: kiedy projekt jest winien aktualizację, kiedy uznajesz go za zagrożony i co się dzieje, gdy aktualizacja się spóźnia. Niech skrypt stosuje ją do danych z Jira, Slacka i komentarzy statusowych, niech AI przygotuje szkic aktualizacji i pokaże, z jakich źródeł i reguł skorzystało, a szkic popraw sam, zanim zostanie opublikowany. ### Czego manager nigdy nie powinien delegować agentowi AI? + Odpowiedzialności za wynik i rozmowy z człowiekiem. Agent może przygotować szkic, ułożyć ranking i zaplanować spotkanie, ale kiedy przesuwa spotkanie albo ponagla kogoś z zespołu, za efekt odpowiada manager, który go uruchomił. Regułę ustaliliśmy z Engineering Managerem, którego mentoruję, po tym, jak agent ustawił 1:1 na godzinę, która była już zajęta: wszystko, co tylko czyta, działa samo; wszystko, co dotyczy człowieka, czeka na „tak” od EM. [Mentoring 1:1](https://www.marian.coach/engineering-manager-mentor/) ## Chcesz przejść od rad do działania? Mentoring 1:1 dla Engineering Managerów, Tech Leadów i CTO. 317 mentee od 2019 roku. Za sesję ocenioną poniżej 8/10 nie płacisz. Pierwsze intro jest bezpłatne. [Umów bezpłatne 30-minutowe intro →](https://www.marian.coach/meet) ## Czytaj dalej - [![Platform engineering: business case, który przekona zarząd](https://www.marian.coach/images/blog/platform-team-business-case/infographic.webp) ### Platform engineering: business case, który przekona zarząd Zarząd nie płaci za procenty. Business case dla platform engineering: jeden kwartał roadmapy, zwrot w trzech, dowożenie w parze z adopcją produktu. 1 listopada 2026 · Autor: Marian Czytaj → ](https://www.marian.coach/pl/blog/platform-team-business-case/) - [![Jak rozmawiać z zarządem: najpierw wyceń, potem się spieraj](https://www.marian.coach/images/blog/how-to-talk-to-executives/infographic.webp) ### Jak rozmawiać z zarządem: najpierw wyceń, potem się spieraj Inżynier przegrywa spór z zarządem, kiedy ma rację w złej walucie. Wyceń obie opcje, przynieś liczbę trafną w 80% i wróć z rekomendacją. 20 października 2026 · Autor: Marian Czytaj → ](https://www.marian.coach/pl/blog/how-to-talk-to-executives/) - [![CTO zarobki: ile zarabia CTO i kiedy wystarczą dwa dni](https://www.marian.coach/images/blog/chief-ai-officer-salary/infographic.webp) ### CTO zarobki: ile zarabia CTO i kiedy wystarczą dwa dni Ile zarabia CTO, a ile Chief AI Officer w USA, Europie Zachodniej, Czechach i Polsce? Pełny rachunek za pierwszy rok i kiedy wystarczy fractional CTO. 18 października 2026 · Autor: Marian Czytaj → ](https://www.marian.coach/pl/blog/cto-zarobki/) ### Nowe artykuły prosto na Twoją skrzynkę. Your emailZapisz się Jesteś na liście. Dziś nic nie przyjdzie. Pierwszego maila wyślę, gdy lista ruszy, a Ty będziesz na niej od początku. [Connect on LinkedIn →](https://www.linkedin.com/in/mariankamenistak/)[See the free tools →](https://www.marian.coach/ai-coaching-tools/) ## Structured data ```json {"@context":"https://schema.org","@type":"ProfessionalService","name":"Marian Kamenistak | Engineering Leadership Mentoring","url":"https://www.marian.coach/pl/blog/how-many-direct-reports-too-many/","image":"https://www.marian.coach/images/blog/how-many-direct-reports-too-many/infographic.webp","description":"Rozpiętość kierowania od 5 do 8 osób to limit obiegu informacji. AI dla managerów w praktyce: EM prowadzi 26 podwładnych w tych samych godzinach.","serviceType":["Engineering leadership mentoring","Engineering manager coaching","CTO coaching","Fractional CTO","Leadership development for software engineers"],"hasOfferCatalog":{"@type":"OfferCatalog","name":"Engineering leadership mentoring and advisory","itemListElement":[{"@type":"Offer","itemOffered":{"@type":"Service","name":"1:1 engineering leadership mentoring","description":"One-to-one mentoring for engineering leaders from Staff Engineer to CTO. 60-minute sessions, weekly or bi-weekly.","url":"https://www.marian.coach/pricing/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Engineering manager coaching","description":"Coaching for first-time and experienced engineering managers: delegation, performance, hiring, team scaling.","url":"https://www.marian.coach/engineering-manager-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"CTO and VP Engineering mentoring","description":"Mentoring for CTOs, VPs of Engineering and Heads of Engineering running 30-200 person organisations.","url":"https://www.marian.coach/cto-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Mentor in Residence","description":"A dedicated onsite mentor for your engineering organisation, booked by the quarter.","url":"https://www.marian.coach/mentor-in-residence/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Fractional CTO","description":"Part-time CTO engagements for companies without a full-time technology leader.","url":"https://www.marian.coach/fractional-cto/"}}]},"telephone":"+420 736 519 879","email":"marian@marian.coach","sameAs":["https://www.linkedin.com/in/mariankamenistak/","https://www.youtube.com/@engineeringleaders","https://github.com/marian-kamenistak","https://www.engineeringleaders.io/","https://www.elc-conference.io/","https://www.marianslist.com/","https://www.mentoringhub.io/"],"address":{"@type":"PostalAddress","streetAddress":"Varšavská 715/36, Vinohrady","addressLocality":"Praha 2","postalCode":"12000","addressCountry":"CZ"},"geo":{"@type":"GeoCoordinates","latitude":50.0734418,"longitude":14.4385757},"openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],"opens":"09:00","closes":"17:00"}],"priceRange":"329–395 EUR","areaServed":[{"@type":"Place","name":"Europe"},{"@type":"Country","name":"Czechia"},{"@type":"Country","name":"Slovakia"},{"@type":"Country","name":"Poland"},{"@type":"Place","name":"North America"}]} {"@context":"https://schema.org","@type":"Person","@id":"https://www.marian.coach/#person","name":"Marian Kamenistak","url":"https://www.marian.coach/","image":"https://www.marian.coach/images/blog/how-many-direct-reports-too-many/infographic.webp","jobTitle":["Engineering Leadership Mentor","Fractional CTO & Chief AI Officer","Founder, Engineering Leaders Community","Engineering Manager Coach","CTO Coach","Keynote Speaker"],"hasOccupation":[{"@type":"Occupation","name":"Engineering Leadership Mentor"},{"@type":"Occupation","name":"Fractional CTO & Chief AI Officer"}],"worksFor":{"@type":"Organization","name":"Engineering Leaders Community","url":"https://www.engineeringleaders.io/"},"alumniOf":[{"@type":"Organization","name":"Mews"},{"@type":"Organization","name":"Databricks"}],"knowsLanguage":["English","Czech","Slovak"],"knowsAbout":["Engineering leadership","Engineering management","Scaling engineering teams","CTO mentoring","Engineering org design","VP of Engineering role","Engineering director role","CTPO role","Team lead development","Staff engineer career path","Fractional CTO engagements","AI-assisted engineering leadership","Conference keynotes on engineering leadership","Panel moderation","Podcast guest — engineering leadership"],"homeLocation":{"@type":"Place","name":"Prague, Czechia"},"sameAs":["https://www.linkedin.com/in/mariankamenistak/","https://www.youtube.com/@engineeringleaders","https://github.com/marian-kamenistak","https://www.engineeringleaders.io/","https://www.elc-conference.io/","https://www.marianslist.com/","https://www.mentoringhub.io/","https://www.crunchbase.com/person/marian-kamenistak","https://www.wikidata.org/wiki/Q140488098","https://developers.mews.com/author/marian/","https://startupdisrupt.com/speakers/marian-kamenistak/","https://theorg.com/org/engineering-leaders-community/org-chart/marian-kamenistak"]} {"@context":"https://schema.org","@type":"WebPage","url":"https://www.marian.coach/pl/blog/how-many-direct-reports-too-many/","name":"Rozpiętość kierowania: 16+ podwładnych dzięki AI","inLanguage":"pl","dateModified":"2026-11-01T00:00:00.000Z"} {"@context":"https://schema.org","@type":"FAQPage","inLanguage":"pl","mainEntity":[{"@type":"Question","name":"Ilu bezpośrednich podwładnych to za dużo dla Engineering Managera?","acceptedAnswer":{"@type":"Answer","text":"Większość porad stawia granicę na pięciu do ośmiu osobach, a według danych Gallupa z 2025 roku mediana dla managera w USA to pięciu do sześciu bezpośrednich podwładnych. Ta granica obowiązuje, dopóki manager ręcznie przekazuje statusy, kontekst, ryzyka i przygotowanie do 1:1. Kiedy te rutyny działają jako spisane reguły, skrypt i szkice od AI, 16 osób i więcej jest do udźwignięcia: Engineering Manager, którego mentoruję, prowadzi 26 bezpośrednich podwładnych, ma z nimi 1:1 co dwa tygodnie i dwóch Team Leadów do pomocy. Samo 1:1 zostaje ludzkie."}},{"@type":"Question","name":"Czy AI może pomóc managerowi prowadzić więcej bezpośrednich podwładnych?","acceptedAnswer":{"@type":"Answer","text":"Tak, jeśli AI przejmuje obieg informacji, a nie ludzi. W EM Dashboard, który zbudowaliśmy z Engineering Managerem, którego mentoruję, około 100 spisanych reguł działa jako skrypt co cztery godziny, bez tokenów AI, a Claude dostaje tylko podsumowania, szkice i pierwszą piątkę priorytetów. Organizacja urosła z 8 do 26 bezpośrednich podwładnych, a dashboard to sposób, w jaki EM utrzymał te same godziny pracy. W Q3 2026, pierwszym pełnym kwartale z dashboardem, zespoły dowiozły 81% kwartalnej roadmapy, wobec 55% w Q2 2026. To liczby samego EM z jednej organizacji, a nie wynik kontrolowanego badania."}},{"@type":"Question","name":"Jak przygotować się do 1:1 z pomocą AI i nie oddać mu rozmowy?","acceptedAnswer":{"@type":"Answer","text":"Niech AI zbuduje brief wyłącznie z pracy: ze wspólnych notatek z poprzedniego spotkania, otwartych spraw i ich właścicieli oraz z tego, co dana osoba poruszyła na Slacku albo na kanale swojej funkcji, przy każdym punkcie z linkiem do źródła. Przeczytaj go pięć minut przed spotkaniem, a rozmowę poprowadź sam. Kiedy status znika z 1:1, ta godzina może należeć do drugiej osoby."}},{"@type":"Question","name":"Jak zautomatyzować aktualizacje statusu w zespole inżynierskim?","acceptedAnswer":{"@type":"Answer","text":"Najpierw spisz regułę: kiedy projekt jest winien aktualizację, kiedy uznajesz go za zagrożony i co się dzieje, gdy aktualizacja się spóźnia. Niech skrypt stosuje ją do danych z Jira, Slacka i komentarzy statusowych, niech AI przygotuje szkic aktualizacji i pokaże, z jakich źródeł i reguł skorzystało, a szkic popraw sam, zanim zostanie opublikowany."}},{"@type":"Question","name":"Czego manager nigdy nie powinien delegować agentowi AI?","acceptedAnswer":{"@type":"Answer","text":"Odpowiedzialności za wynik i rozmowy z człowiekiem. Agent może przygotować szkic, ułożyć ranking i zaplanować spotkanie, ale kiedy przesuwa spotkanie albo ponagla kogoś z zespołu, za efekt odpowiada manager, który go uruchomił. Regułę ustaliliśmy z Engineering Managerem, którego mentoruję, po tym, jak agent ustawił 1:1 na godzinę, która była już zajęta: wszystko, co tylko czyta, działa samo; wszystko, co dotyczy człowieka, czeka na „tak” od EM."}}]} {"@context":"https://schema.org","@type":"BlogPosting","headline":"Rozpiętość kierowania: 16+ podwładnych dzięki AI","description":"Rozpiętość kierowania od 5 do 8 osób to limit obiegu informacji. AI dla managerów w praktyce: EM prowadzi 26 podwładnych w tych samych godzinach.","inLanguage":"pl","articleSection":"engineering-management","datePublished":"2026-11-01T00:00:00.000Z","dateModified":"2026-11-01T00:00:00.000Z","author":{"@id":"https://www.marian.coach/#person"},"publisher":{"@type":"Organization","name":"Marian Kamenistak","url":"https://www.marian.coach/","logo":{"@type":"ImageObject","url":"https://www.marian.coach/favicon-192x192.webp","width":192,"height":192}},"image":{"@type":"ImageObject","url":"https://www.marian.coach/images/blog/how-many-direct-reports-too-many/infographic.webp"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.marian.coach/pl/blog/how-many-direct-reports-too-many/"},"keywords":"engineering-management, ai, one-on-ones, leadership","wordCount":4381,"timeRequired":"PT20M","isAccessibleForFree":true} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Strona główna","item":"https://www.marian.coach/pl/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://www.marian.coach/pl/blog/"},{"@type":"ListItem","position":3,"name":"Rozpiętość kierowania: 16+ podwładnych dzięki AI","item":"https://www.marian.coach/pl/blog/how-many-direct-reports-too-many/"}]} ```