Root cause działa świetnie w IT. Z ludźmi bywa trochę trudniej.

W technologii szukamy przyczyny problemu. System przestał działać. Co się wydarzyło? Gdzie pojawił się błąd? Co go wywołało? Jak usunąć przyczynę? Jak zapobiec powtórzeniu? Pięć razy „dlaczego” i jedziemy. Bardzo lubię ten sposób pracy. Problem w tym, że kiedy człowiek zaczyna traktować sam siebie jak incident produkcyjny, robi się trochę trudniej.

„Dlaczego taki jestem?”

To pytanie może być wartościowe. Ale może też prowadzić w nieskończoną pętlę. Dlaczego nie potrafię odmówić? Bo boję się reakcji. Dlaczego się jej boję? Bo zależy mi na akceptacji. Dlaczego aż tak zależy mi na akceptacji? Bo… Można kopać bardzo głęboko. I czasem ma to sens. Ale nie każda rozmowa potrzebuje wykopalisk archeologicznych. Czasem pytanie o przeszłość pomaga zrozumieć. Czasem jednak ważniejsze staje się: „Skoro to już widzisz — co chcesz zrobić teraz?”

Poszukiwanie przyczyny źródłowej zakłada, że istnieje błąd

I tutaj pojawia się pierwsza różnica. W systemie komunikat błędu sugeruje, że stan rzeczy odbiega od stanu oczekiwanego. Znamy oczekiwany rezultat. Mamy rzeczywisty rezultat. Jest luka. Szukamy przyczyny. Ale kto ustala oczekiwany rezultat dla człowieka? Rodzina? Przełożony? Kultura organizacji? Ja sprzed dziesięciu lat? Osoba, z którą się porównuję? Co właściwie oznacza: „Powinnam być bardziej pewna siebie”? Bardziej niż teraz? Tak samo jak ktoś inny? W każdej sytuacji? I skąd wiemy, że brak pewności siebie rzeczywiście jest tutaj problemem?

Czasami problem jest źle nazwany

To znamy również z IT. Zgłoszenie mówi:

„Raport w Power BI działa wolno.” Po godzinie okazuje się, że Power BI jest niewinny. Problem jest gdzie indziej. Z człowiekiem może być podobnie. Klient przychodzi: „Muszę być bardziej produktywny.” A rozmowa odkrywa: „Nie chcę już robić połowy rzeczy, do których próbuję się zmotywować.” Albo: „Muszę nauczyć się lepiej zarządzać czasem.” A pod spodem: „Nie potrafię powiedzieć nie.” Albo: „Nie wiem, jak podjąć decyzję.” A po chwili: „Tak naprawdę wiem. Nie podoba mi się tylko cena tej decyzji.” To są zupełnie inne perspektywy.

Diagnoza ≠ Świadomość

W technologii diagnoza jest często dokładnie tym, czego potrzebujemy. W coachingu świadomość może być ważniejsza niż etykieta. Nie muszę wiedzieć: „jaki jest Twój problem?” Mogę być ciekawa: „co zauważasz?” Nie muszę określać: „dlaczego tak reagujesz?” Mogę zapytać: „co dzieje się z Tobą w tej sytuacji?” Nie muszę decydować: „co będzie dla Ciebie właściwe?” Mogę zapytać: „co jest tutaj ważne dla Ciebie?” Niby niewielka różnica. A zmienia właściciela procesu.

Debugging człowieka ma jeszcze jedną wadę

Każdy developer zna sytuację, w której po naprawieniu jednego błędu pojawiają się trzy kolejne. 😉 Z człowiekiem można zrobić coś podobnego. „Naprawiam” brak pewności siebie. Potem okazuje się, że człowiek przestał słuchać intuicji, która wcześniej chroniła go przed pochopnymi decyzjami. „Naprawiam” perfekcjonizm. A razem z nim próbuję wyrzucić dokładność i standardy, które są jedną z jego największych sił. Dlatego wolę inne pytanie: Jak możesz mieć dostęp do swojej siły, nie będąc przez nią sterowaną automatycznie? To pytanie szczególnie lubię również w pracy z Enneagramem i leadership.

Może nie potrzebujemy znać przyczynę problemu

Czasem oczywiście warto zrozumieć, skąd coś się wzięło. Ale coaching nie zawsze potrzebuje odpowiedzi na: „Co mnie zepsuło?” Może potrzebować: „Co to dla mnie znaczy?” „Co jest dla mnie ważne?” „Jakie mam możliwości?” „Co chcę wybrać?” W technologii chcę, żeby system zachowywał się przewidywalnie. Od człowieka oczekuję czegoś dokładnie odwrotnego. Możliwości uczenia się. Zmiany. Zaskoczenia siebie. Zobaczenia czegoś, czego wcześniej nie widział. Dlatego technologii nadal szukam pierwotnej przyczyny. Człowieka wolę nie debuggować.

Zobacz, jak wykorzystuję różne perspektywy w coachingu →