Delegowanie bez oddawania odpowiedzialności

„Masz to poprowadzić” potrafi oznaczać bardzo różne rzeczy. Dla pracownika: wybierz rozwiązanie i dowieź wynik. Dla managera: przygotuj propozycję, ale każdą ważniejszą decyzję uzgodnij ze mną. Obie strony dowiadują się o tej różnicy dopiero wtedy, gdy coś już zostało obiecane albo zmienione.

W takim układzie pracownik ma zgadywać. Jeśli zapyta, usłyszy, że powinien być bardziej samodzielny. Jeśli zdecyduje, może dostać pretensję, że nie skonsultował. Po kilku takich doświadczeniach zacznie przesyłać szefowi każdą drobnostkę. Manager uzna to za dowód niedojrzałości zespołu, choć sam nauczył ludzi, że samodzielność jest obarczona nieprzewidywalnym ryzykiem.

Manager odpowiada za dobór osoby, dostępne zasoby i granice przekazanych uprawnień. Pracownik odpowiada za wykonanie w tym zakresie oraz za informowanie o przeszkodach. Tytułowe nieoddawanie odpowiedzialności dotyczy obowiązków szefa wobec organizacji. Nie oznacza, że wykonawca jest zwolniony z oceny własnych decyzji ani że przełożony ma podejmować je za niego. Bez tego rozróżnienia łatwo zamienić delegowanie w przerzucanie winy w jedną albo w drugą stronę.

Autonomia musi mieć określony zakres

Jocko Willink używa formuły „Discipline equals freedom”, która jest również tytułem jego książki. W odniesieniu do delegowania odczytuję ją jako argument za jasnymi ustaleniami. Gdy wiadomo, w jakich granicach można działać, nie trzeba pytać przełożonego przy każdym ruchu. To moje zastosowanie tej myśli do zarządzania pracą zespołu. (St. Martin’s Press, Discipline Equals Freedom)

Załóżmy, że programista ma przygotować migrację danych. Może wybrać implementację, podzielić pracę i zaplanować testy. Nie może samodzielnie zaakceptować utraty danych ani obiecać klientowi przerwy w działaniu usługi. Te granice trzeba ustalić przed pracą, podobnie jak dostęp do środowiska i osobę uprawnioną do zatwierdzenia wdrożenia.

Bez tego manager może później zarzucić opóźnienie człowiekowi, który czekał na cudzą decyzję. Może też oczekiwać inicjatywy tam, gdzie wcześniej karał za samodzielny wybór. Z perspektywy pracownika najbezpieczniej będzie wtedy pytać o wszystko. Nie jest to szczególnie wydajne, ale bywa racjonalną odpowiedzią na zachowanie przełożonego.

Zakres samodzielności można zwiększać stopniowo. Przy pierwszym zadaniu osoba przygotowuje rekomendację, a manager pomaga ją ocenić. Przy kolejnym sama decyduje i informuje. Z czasem konsultuje już tylko wyjątki. Ważne, żeby obie strony wiedziały, na którym etapie są, i nie musiały zgadywać tego z reakcji szefa.

Kiedy manager powinien wrócić do tematu

Sposób informowania o postępie powinien wynikać z ryzyka. Przy krótkim zadaniu wystarczy ustalenie terminu i zgłoszenie przeszkody. Przy migracji produkcyjnej potrzebny będzie konkretny punkt kontrolny. Jeśli test odtworzenia nie przejdzie do czwartku, wracamy do decyzji o wdrożeniu. To daje większą jasność niż ogólne „daj znać, jak coś będzie nie tak”.

Wczesna eskalacja ryzyka powinna być oczekiwanym elementem pracy. Jeżeli człowiek zgłasza, że przekroczył ustaloną granicę, najpierw trzeba rozwiązać problem. Złość na sam fakt zgłoszenia uczy go, że następnym razem lepiej poczekać. Wtedy manager dostanie mniej wiadomości, ale niekoniecznie mniej ryzyka.

Przełożony też powinien mieć termin na odpowiedź. Jeżeli tylko on może zatwierdzić zmianę zakresu, a przez tydzień nie reaguje, opóźnienie nie jest dowodem braku inicjatywy wykonawcy. Rozsądne ustalenie obejmuje więc również zastępstwo albo sposób eskalacji, gdy szef jest niedostępny. W przeciwnym razie delegujemy pracę, ale pozostawiamy sobie prawo do jej bezterminowego zatrzymania.

W praktyce przydaje się rozdzielenie odbioru wyniku od kontroli sposobu pracy. Przy migracji interesuje mnie zgodność danych, wynik próby odtworzenia i możliwość zatrzymania operacji. Nie muszę zatwierdzać każdej funkcji pomocniczej w skrypcie. Jeżeli rozwiązanie narusza standard zespołu, wyjaśniam który i dlaczego. „Ja bym to zrobił inaczej” może być uwagą w dyskusji, ale samo w sobie nie jest powodem do odebrania decyzji.

Po zakończeniu zadania warto omówić konkretny przebieg. Czy wynik odpowiadał ustaleniom? Gdzie zabrakło danych lub uprawnień? Czy wykonawca zareagował na problem we właściwym momencie? Ten przegląd powinien pomóc określić zakres następnego zadania. Samo „poszło dobrze” nie wyjaśnia, na czym można oprzeć większą autonomię.

Błąd może uzasadniać dodatkowy przegląd albo czasowe ograniczenie pewnej decyzji. Powinno to dotyczyć rozpoznanej luki, z jasnym warunkiem powrotu do samodzielności. Cofnięcie wszystkich uprawnień po jednym potknięciu jest wygodne dla szefa, ale trudno na tym budować zaufanie oparte na przewidywalności.

Przed kolejnym zadaniem chcę więc ustalić wynik, granice samodzielności i moment, w którym potrzebna będzie moja decyzja. Potem mam obowiązek uszanować ten podział. Jeżeli za każdym razem wracam i przejmuję sterowanie przy pierwszym dyskomforcie, nie powinienem dziwić się, że ludzie przestają podejmować decyzje. Zespół bardzo uważnie obserwuje, ile autonomii szef rzeczywiście potrafi znieść.