Przez ostatnie 15 lat miałem okazję działać w różnych firmach - od dużych korporacji, przez szybko rosnące software house’y, do prężnie rozwijających się startupów. Dopiero po jakimś czasie zacząłem łączyć kropki i zdołałem wyodrębnić kilka powtarzających się, negatywnych schematów, które występowały w większości tych organizacji. I tutaj muszę od razu zaznaczyć, że to moje obserwacje i doświadczenia - Twoje, drogi czytelniku, mogą być zupełnie inne 🙂
Nauczyłem się, z czasem, rozpoznawać te schematy z wyprzedzeniem, diagnozować ich źródła i próbować naprawiać przy pomocy prostych i ogólnodostępnych narzędzi. Chciałbym się z Tobą tym doświadczeniem podzielić - w nadziei, że mogą Ci się przydać w przyszłości.
Części, które planuję w tym cyklu:
- Rozdmuchana struktura
- Brak widoczności pracy
- Nadmierna hierarchiczność
- Kult zajętości
- Nadopiekuńczość
- Iluzja deadline’ów
- Presja sukcesu
Zapraszam do zapoznania się z pierwszą z siedmiu części. Zaczniemy od tego jak organizacje rozwiązują problemy poprzez tworzenie ról i zatrudnianie nowych osób. Przedstawię z czego moim zdaniem wynika ten problem, jak go diagnozować i rozwiązywać.
Objawy
Masz czasem wrażenie, że nawet proste decyzje ciągną się tygodniami, a samemu chodzisz od jednego do drugiego managera aby uzyskać odpowiedź? Jednocześnie widzisz, że pojawiają się kolejne osoby, a nawet całe działy, które mają pomóc w ‘ogarnianiu’ właśnie tych tematów? To może być oznaka tego, że Twoja organizacja cierpi na niekontrolowany rozrost struktury.
Kilka przykładów nadmiernego rozrostu struktury:
- Zespoły nie naprawiają błędów od klientów, priorytetyzują pracę nad nowymi rzeczami? Zatrudnijmy “koordynatora do rozdzielania błędów”.
- Praca nad produktem opóźnia się, zespoły są zablokowane? Zatrudnijmy “delivery managera”, który będzie koordynował deadline’y, zależności i planowanie
- Nie mamy pomysłu jak doceniać pracowników? Promujmy ich na “team leadów”, nawet jeśli mają mieć pod sobą jedną osobę
- Scrum Masterzy nie potrafią (lub nie mogą) wejść na poziom organizacji i proponować tam zmian? Zatrudnijmy “agile coacha”, który będzie wymyślał jak inni mają pracować
Problem nadmiernego rozrostu struktury jest szczególnie widoczny w momencie rozwoju małych firm, które próbują w ten sposób rozwiązać problem sprostania zwiększonemu zapotrzebowaniu na ich usługi (czyli mamy nowych klientów, inwestorów, etc.). Aby sprostać nowym zamówieniom, zatrudniane są nowe osoby, co zwiększa złożoność całego systemu i wymusza zmianę sposobu działania. Często w takiej sytuacji zaczyna brakować jasnych procesów, umiejętności, ram autonomii zespołów czy działającej pętli uczenia się. Dodatkowo mam wrażenie, że w kluczowych momentach wzrostu nikt w organizacji nie zadaje sobie pytania: co jest problemem, który ta nowa rola/osoba ma rozwiązać?
A nawet, jeśli je zadaje, to dochodzi do wniosku, że ‘szeregowi pracownicy’ nie są w stanie tego problemu rozwiązać.
Mając do wyboru dwie drogi rozwiązania problemu skalowania:
- Analizę problemu, wypracowanie nowych procesów, a następnie dostarczenie obecnym ludziom umiejętności aby te procesy wdrażali i rozwijali
- Zatrudnienie osoby w nowej roli, która ten problem ‘ogarnie’
organizacje bardzo często wybierają tę drugą opcję. Jest ona prostsza, bardziej zrozumiała, wpisuje się w istniejące schematy - bo przecież wiadomo, że organizacje rosną i potrzebują nowych osób. Wszyscy tak robią.
Tymczasem zamiast rozwiązywać faktyczny problem, tworzony jest dodatkowy element struktury, który dodaje złożoności do całego systemu. Nie dość, że zwiększa to koszty stałe działania firmy (tworząc nowe etaty), to niekoniecznie przekłada się to później na skrócenie czasu dostarczania wartości.
Za jakiś czas może się okazać, że nowa rola czy dział mierzą się z kolejnym problemem (którego może sami są częścią) i będą lobbować za stworzeniem kolejnego stanowiska, które na pewno tym razem już załatwi sprawę…
Schemat ten bardzo dobrze przedstawił Jürgen De Smet na swoim wystąpieniu na Agile Warsaw. Podziękowania dla Piotrka Gdańca, który podzielił się tym ze mną.
Leczenie
Zamiast leczyć rozdmuchaną strukturę, lepiej zapobiegać jej niepochamowanemu rozrostowi. Nie zawsze będzie tak, że nowa rola okaże się zbędna. Zawsze jednak warto zapytać: jaki problem chcemy rozwiązać?
Aby sprawdzić, czy Twoja organizacja przejawia chęć nadmiernego rozrostu struktury, wsłuchaj się w to, o czym rozmawiają liderzy w kuluarach. Stwierdzenia takie, jak:
- “Developerzy nie chcą tego robić. Zresztą i tak szkoda ich czasu na to. Pewnie ktoś mógłby to robić…”
- “Te błędy ciągle się powtarzają, przydałby się ktoś, kto sprawdzi jeszcze raz przed wypuszczeniem na proda…”
- “Zespoły ze sobą nie gadają. Dobrze by było, aby ktoś synchronizował pracę…”
mogą sugerować, że jest jakiś problem, a w głowach liderów już kształtuje się rozwiązanie: dodajmy kolejną osobę i/lub stwórzmy nowe stanowisko.
Warto też obserwować metryki związane z przepływem wartości w organizacji. Szukaj symptomów zapychania się systemu - zwiększający się i starzejący się WIP, wydłużający się cycle time, wzrastająca ilość zablokowanych zadań. To może być sygnał tego, że za chwilę pojawi się 'potrzeba' stworzenia roli do synchronizacji, koordynacji i pilnowania deadline'ów.
W takich sytuacjach jest jeszcze czas, aby zareagować. Spróbuj zorganizować sesje RCA (root cause analysis) i sprawdzić co leży u źródła tych problemów. Każda z tych sytuacji wymieniona powyżej może mieć inne przyczyny.
Przykłady
Część problemów będzie wynikać z tego, że utworzyły się silosy, które powodują zależności i wydłużają czas dostarczania wartości end-to-end. Wtedy możesz zastosować value stream mapping do tego, aby zobrazować jak płynie wartość w organizacji i kto jest potrzebny, aby wytworzyć coś od początku do końca. Następnie zasugerować takie zmiany, które doprowadzą do bliższej współpracy ról, które są potrzebne do wytworzenia czegoś end-to-end - eliminując w ten sposób potrzebę ról koordynujących współpracę między zespołami.
W innych sytuacjach może się okazać, że brakuje nam pewnych technologicznych możliwości aby dostarczać nasz produkt częściej i/lub z mniejszą ilością błędów. Aby uniknąć powstawania ról, których jedynym zadaniem będzie “dodatkowa weryfikacja i release”, możesz przeanalizować efektywność procesu - gdzie praca jest manualna, gdzie przechodzi najwięcej błędów - i wypracować plan automatyzacji.
Jeszcze kiedy indziej okaże się, że mamy do czynienia z pętlą braku zaufania. Management nie widzi inicjatywy pracowników do podejmowania działań spoza ich ‘codziennych’ czynności, więc bierze na siebie dodatkowe projekty i związane z tym decyzje. Z kolei członkowie zespołu nie wiedzą, czy mogą podejmować jakieś decyzje samodzielnie i wolą się ‘nie wychylać’ skoro i tak manager za nich przejmie jakiś temat. W takiej sytuacji możesz (zamiast tworzyć rolę np. “leadera projektów wewnętrznych”) stworzyć razem z zespołem i managementem macierz delegacji aby określić jakie procesy mogą być zarządzane przez sam zespół.
Podsumowanie
Którekolwiek narzędzie zastosujesz, warto doprowadzić do sytuacji, której rozwiązaniem będzie opis nowego procesu (lub aktualizacja istniejącego) - łącznie ze sposobem jego utrzymania, aktualizacji i implementacji.
Każdy proces, choćby nie wiadomo jak perfekcyjnie opisany, musi żyć i podlegać inspekcji i adaptacji - bez tego umrze. A wtedy przyjdzie ktoś, kto zada moje ulubione pytanie: a może jednak potrzebujemy tam tego delivery managera? 🙂