Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jak stworzyć atmosferę safe to fail (i dlaczego to ważne)

Karolina Janicka IT Project Manager / Service Owner for SIA and EVR
Poznaj zalety atmosfery safe to fail w zespole oraz dowiedz się, jak o nią zadbać.
Jak stworzyć atmosferę safe to fail (i dlaczego to ważne)

Safe to fail. Kolejny buzz word, który obija nam się o uszy w ostatnim czasie. Chwilowa moda? Czy może jednak stoi za tym coś więcej? Na to pytanie postaram się odpowiedzieć.


Do szeroko pojętego IT trafiłam trochę przez przypadek. Nie wskazywałyby na to ani młodzieńcze pasje, ani kierunek studiów. Niemniej – stało się. A dziś nie wyobrażam sobie, że mogło się to wszystko potoczyć inaczej.  

Głód wiedzy, zdobywania doświadczeń i determinacja, pchały mnie coraz dalej w obranej ścieżce kariery. I nagle stało się. BUM – tu masz swój zespół, powodzenia. Miałam to szczęście, że mogłam się przygotować. Mogłam poczytać, zrobić parę szkoleń, słowem – chciałam być dla mojego zespołu takim managerem, na jakiego zasługują. Przeanalizowałam chyba wszystkie sytuacje, których byłam świadkiem bądź uczestnikiem, aby postarać się odnaleźć własną drogę do bycia managerem. Na warsztat wzięłam również sytuacje prywatne – będąc mamą dwójki świeżo zaznajomionych ze żłobkiem dzieci, na co dzień musiałam się borykać z, paradoksalnie, bardzo podobnymi problemami, które przede mną czekały. 

Nic nie mogło mnie przygotować na to, co mnie spotkało. Początkowo mój zakres obowiązków jako Service Managera miał obejmować jedno narzędzie z zakresu integracji. Szybko dowiedziałam się, że dostałam pakiet 2w1, wraz z narzędziem do korelacji eventów z monitoringu. ‘Ale spokojnie, tam się nic nie dzieje’. Jasne. 

Problem był w sumie prosty – architektura rozwiązania sprawiała, że powierzone mi narzędzia stały dosłownie pośrodku – mówiąc krótko: nie było wiadomo, z której strony przyjdzie cios, za to doskonale było wiadomo, że pole rażenia dotknie sporą liczbę klientów. Dodatkowo współistniejące problemy z wydajnością, niespójnością danych, procedury pisane przez deweloperów dla deweloperów – to nie mogło się skończyć dobrze. 

I niestety nie skończyło się dobrze. Średnio co tydzień – dwa mieliśmy mniejsze lub większe przygody. Większość z nich wiązała się z koniecznością odpalenia całej procedury związanej z tzw. Major Incident (lub po prostu – P1). Przy którejś okazji moja managerka zadzwoniła do mnie z pretensją – po co korzystamy z procedury MI, skoro nasz downtime zamyka się w czasie 2-3h?! Oczywiście, moje argumenty były standardowe: zasięg rażenia, ilość dotkniętych klientów, potencjalne przegapienie P1 z monitoringu dla jednego bądź więcej klientów…

Niemniej jednak – jej słowa zmusiły mnie do refleksji. Dlaczego inne MI trwają często kilkanaście godzin lub więcej? I co takiego sprawia, że nasze zamykają się w 2-3? Ilekroć zastanawiałam się nad tym zagadnieniem, zawsze dochodziłam do jednej konkluzji. I to tak paradoksalnej, że do dziś wydaje mi się ona nieco groteskowa. A mianowicie: nasze MI trwały krócej, ponieważ jestem matką dwójki małych dzieci

Oczywiście, nie chcę tym samym umniejszać zdolności i wiedzy moich kolegów z zespołu Operations czy z zespołu Development (a ludzi miałam tam wspaniałych!). Przecież to oni odwalali całą robotę, wszystkie pomysły były przecież ich! Ja tylko byłam obok. Tylko tyle… i aż tyle. 

Wiecie, co uznałam (i nadal uznaję!) za główny trzon, wokół którego buduję swoją ścieżkę na wychowanie moich urwisów? Cel, żeby wyrosły na samodzielne, samoświadome jednostki, zdolne do oceny ryzyka – i do podjęcia go. Słowem – tak, jestem tą niedobrą matką, która pięć razy powtórzy ‘Kochanie, proszę, uważaj, możesz się uderzyć’ po czym… będzie tulić rozżalone dziecko, które właśnie się uderzyło. Oczywiście, to nie znaczy, że moje dzieci biegają z 30-cm nożem, ale na pewno nie pozwolę sobie na to, by obkładać cały dom poduszkami, zaklejać każde gniazdko, prostować schody czy inne cuda. Czy jestem sadystką? Może. Ale wiem jedno – możemy milion razy powtórzyć komuś, że coś jest niebezpieczne. Słowa nie znaczą nic, doświadczenia – wszystko. Dlatego całą swoją uwagę skupiłam nie na zabezpieczaniu całego domu – a na stworzeniu takiego środowiska, żeby dzieci mogły te doświadczenia zdobyć bez permanentnych urazów. 

Po części nieświadomie przeniosłam te praktyki w moje życie zawodowe. W przypadku każdej akcji mój zespół był pewien, że:

  • Jestem przy nich i jako Service Manager – biorę całą odpowiedzialność na siebie
  • Mogą liczyć na mój spokój i gotowość do podjęcia odważnych decyzji


Moi koledzy mieli pełną swobodę w doborze środków do poradzenia sobie z aktualnym problemem i przywrócenia funkcjonalności narzędzia. Bardzo skupiałam się na tym, żeby nie wisieć nad nimi i nie żądać sprawozdania co 5 min (choć uwierzcie, było to trudne). Za zasadę przyjęłam 15 min – jeśli w trakcie tego czasu nie miałam żadnej aktualizacji, spokojnie o to pytałam. Jak słyszałam ‘nie teraz’ – nie obrażałam się. Wiedziałam doskonale, że im również zależy na rozwiązaniu problemu. Czy to z ‘poczucia misji’ czy po prostu ‘bo chcę iść spać’ – nie obchodziły mnie pobudki. Ważne było, że gramy do jednej bramki. Musiałam im zaufać – znali narzędzie lepiej, niż ja kiedykolwiek poznam. 

Wiele razy słyszałam (lub czytałam na wspólnym czacie) „Dobra, Karolina, można to zrobić tak (…)”. Po tym następowały z mojej strony 3 pytania:

  • Próbowaliście już tego?
  • Jaki jest potencjalny impact?
  • Jakie są szanse, że zacznie działać?


Pierwsze pytanie było raczej skierowane w celu walidacji, jak bardzo wiarygodne są odpowiedzi na kolejne dwa. Drugie pozwalało na zrozumienie, czym ryzykujemy (i, tak naprawdę – na ile rozumiemy problem, bo odpowiedzi ‘nie mam pojęcia, ale chyba…’ też były akceptowane). Trzecie pozwalało oszacować czy warto podjąć ryzyko, a >50% było obiecującą wartością. Zdziwieni? To niedokładnie czytacie 😊 Najważniejsze, to rozumieć motywację drugiej osoby. Ja miałam pewność co do dwóch rzeczy:

  • Oni znali narzędzie lepiej niż ja – znali je dłużej i pracowali na nim na co dzień 
  • Wszyscy chcieliśmy zamknąć temat i 
    • Pójść spać*
    • Cieszyć się weekendem*
    • Skończyć pracę*


*Zakreśl właściwe


Czy w takim układzie proponowaliby rozwiązania sabotujące działania narzędzia? Raczej nie. Raczej – bo pewna walidacja i świadomość działania narzędzia zawsze są konieczne. 

Niektóre propozycje były nietuzinkowe. Większość – po prostu bezczelna. Szczerze? Nie zmieniłabym żadnej decyzji z serii ‘no to dajesz…’. Mieliśmy 95%-ową skuteczność. Czemu nie 100%? Bo raz, jeden, jedyny raz, mój inżynier, wykończony kolejną ‘atrakcją’ w trakcie jego dyżuru, źle zrestartował serwer, co doprowadziło do kolejnego downtime’u z powodów czysto ludzkich.

Moje największe osiągnięcie? Właśnie to. Ten moment, kiedy zadzwonił i sam z siebie się przyznał, że po ludzku ‘dał ciała’… Mógł ściemniać, że to dalej ten sam problem bądź inny, mógł powiedzieć cokolwiek. A po prostu się przyznał: byłem zmęczony, nie wyszło. Szczerze? Właśnie takie chwile są największą nagrodą. Chwile, które pokazują, że zespół ufa sobie nawzajem, że współpracuje, i, przede wszystkim – że jesteśmy w tym razem, na dobre i na złe. Górnolotnie? Może. Ale tak naprawdę poznajemy się nawzajem dopiero w trudnych sytuacjach, a nie, kiedy wszystko jest pięknie.

Jest jeszcze jedna rzecz, o której warto wspomnieć: komunikacja. Wiadomo, zawsze trzeba zadbać o to, żeby odpowiednio poinformować o zaistniałej sytuacji, nawet jeśli jest to niewygodne. Mój zespół wiedział jedno: od komunikacji jestem ja. Nie chodzi tu o to, że zrobię to lepiej, niż oni. Przede wszystkim chodziło o ochronę ich. Jeśli jakiś z ich pomysłów by się nie powiódł – trudno, zdarza się. Wszelkie zażalenia trafiłyby na moje biurko. Dlaczego to takie ważne? Jesteśmy zespołem. Nie ma żadnego sensu publicznie pokazywać, czyj pomysł nie wypalił, kto nie dał rady. Co to da? Dziś ten, jutro tamten, a pojutrze - może ja? Każdy ma prawo do gorszego dnia, złej decyzji. Te tematy można analizować we własnym gronie. 

Jakbym miała dać sugestie (naprawdę, sugestie, a nie gotowy przepis) na to, jak zbudować w zespole środowisko safe to fail? To kilka prostych, a jednocześnie bardzo trudnych kroków:

  • Zaufajcie sobie
  • Zrozumcie swoją motywację
  • Uznajcie, że jesteście jednym zespołem, na dobre i na złe
  • Znajdźcie odpowiedni balans pomiędzy kontrolą a samodzielnością


Dlaczego prostych kroków? Ponieważ są oczywiste. Pracujecie ze sobą, logiczne, że musicie się zrozumieć, ufać sobie, jesteście zespołem. Dlaczego to takie trudne? No właśnie. Wielu managerów jest tak skupionych na celu, na dostarczeniu odpowiedniej dostępności, funkcjonalności, wydajności, że staje się niemal niemożliwe, aby zaakceptować porażkę lub niedowiezienie targetów.

Z drugiej strony, warto sobie zadać pytanie, co jest ważniejsze? Czy dostarczenie SLA, czy KPI za wszelką cenę, ryzykując, że motywacja zespołu sięgnie dna czy zespół się wykruszy, i w końcu i tak staniemy przed ścianą? Czy może pozwolenie sobie i innym na bycie człowiekiem, zbudowanie zespołu, w którym więzi przetrwają lata, kosztem jednego czy dwóch miesięcy ‘poślizgu’? 

Czy warto? WARTO. Dlaczego? Powody są proste. Zespół, który ma oparcie i wie, że może polec, będzie odważniejszy. Będzie próbować nowych rozwiązań. Będzie mieć odwagę wyjść z pudła i znaleźć swoją drogę, kto wie, może dzięki temu narodzi się coś wielkiego? A w działaniach operacyjnych? Tym bardziej warto! Przecież ogromną różnicę sprawi redukcja czasu downtime’u kilku – lub nawet kilkunastokrotna! Dlatego – do dzieła. Nie ma uniwersalnej drogi. Nie ma uniwersalnej prawdy. Najważniejsze jest, żebyśmy po prostu zaakceptowali, że jesteśmy ludźmi. I pamiętaj, ‘nie myli się, kto nic nie robi’.

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 130 tysiącami naszych czytelników

Dowiedz się więcej