Deadline24: Lekcja Ekstremalnej Presji

Kontynuując temat rozliczenia się z Extreme Ownershipem, a dokładnie z jego implementacją i zrozumieniem, postanowiłem dziś zejść na niższy poziom — poziom praw bojowych — i pokazać jak się one mają do chaosu i stresu.

Panika

W 2014 roku coś mnie pokusiło (a raczej ktoś, bo to, że się zdecydowałem, to zasługa moich kolegów i mentorów Tymka i Sebastiana), by pójść na konkurs programistyczny Deadline 24 Lite. Zespół dostawał 3 zadania. Budował 3 boty. Boty miały za zadanie konkurować z innymi botami pisanymi w czasie tego konkursu przez inne zespoły.

Dostaję zadanie. Siedzę przed ekranem komputera. Zegar odlicza pierwszą godzinę z 24.

Mam framework, który już komunikuje się z serwerem, napisany przez kolegów. Przeanalizowałem dokumentację frameworka wcześniej. Odpaliłem go, żeby potem nie było. Wszystko technicznie działa.

I totalnie nie wiem, co robić. Nic nie działa. Wszyscy pozostali punktują, a ja osiągam poziom 0. Jedno wielkie okrągłe zero w głowie i na tablicy.

Przez ten cały stres i ogarniającą mnie panikę nie zauważam w instrukcji sleepа, który ma czekać 2 sekundy, podczas gdy czas odpowiedzi maksymalny to 1 sekunda.

Jak to mówi stare przysłowie: dupa i kamieni kupa.

Mija 5. godzina konkursu, ja przepisuję algorytm grania w karty i nadal nic.

Już jest ten moment, że chcę wszystko rzucić i pójść sobie do domu.

Nawet nie wiem o co pytać, a tym bardziej nie chcę truć gitary pozostałym członkom zespołu.

Do tego momentu uważałem się za dobrego programistę, znającego wiele technik, w tym TDD — Test Driven Development. Czułem się pewnie i w języku, w którym programowałem (C#), i lubiłem rozwiązywać problemy programistyczne.

W tym momencie na chwilę przestałem.

To jest frycowe, które płaci się przy pierwszym podejściu do takich konkursów. Każdy tam był. Ale chcę pokazać coś więcej niż “oj, zdarza się”.

Matematyka Paniki

Gdy byłem pod presją to mój mózg nie chciał sięgać po nowe rozwiązania. Raczej myślał o tym by uciec stamtąd. To po co sięgamy w takiej sytuacji to sprawdzone i wypróbowane rozwiązania. Problem w tym, że gdy gubisz się po raz pierwszy w nowej sytuacji, nie masz nic przetestowanego.

Na koncie miałem już kilka fuckupów na produkcji, sytuacji w które trzeba było siedzieć po godzinach czy weekendami, bo ktoś źle wyestymował lub wyszło coś niespodziewanego.

Z takimi sytuacjami radziłem sobie dobrze. W tym wypadku wszystko było nowe i inne.

Pierwsze kilka godzin to było… w sumie nic. Losowe zmiany w kodzie. Czytanie instrukcji bez zrozumienia. Restartowanie IDE. Nic konstruktywnego.

Brakowało tylko, bym zaczął latać po pokoju w stroju szamana, tańcząc taniec w intencji oświecenia.

Dopiero po kilku godzinach, gdy adrenalina opadła i mózg wrócił do działania, pojawiły się właściwe pytania:

• Co da mi szybko punkty? (nie “jak wygrać”, ale “jak dostać choć jeden punkt”)
• Jak poznam, że to działa? (mały, widoczny krok)
• Po czym poznam, że go zrobiłem? (konkretny sygnał sukcesu)
• Jaki jest następny krok? (nie wszystkie kroki, tylko następny)
• Jak mogę to testować w izolacji? (bez pełnej symulacji całego systemu)

Przyszły naturalnie. Choć musiały utorować sobie drogę.

Prawa Bojowe w Praktyce

Te pięć pytań to nie przypadek. To moja podświadoma próba zastosowania praw bojowych z Extreme Ownership.

W trakcie pierwszego konkursu nie miałem bladego pojęcia o Extreme Ownershipie. Nikt nie miał, bo książka jeszcze wtedy nie istniała. W trakcie drugiego czytania książki autorstwa Jocko Willinka i Leif’a Babina, zauważyłem duże podobieństwo między tym co przeżyłem, a tym co uczą oni.

Operatorzy SEALs żyją pod ekstremalną presją i w sytuacjach, które są dla nich ekstremalne, ale robią wszystko poprzez ciężki trening oraz planowanie, by minimalizować ryzyko porażki, lub co gorsze śmierci.

Moją ekstremalną sytuacją był właśnie udział w edycji, gdzie testowi poddane zostało wszystko co wydawało mi się, że potrafię jako dobry programista. Jak widać z różnym skutkiem.

Podobnie jak oni chciałem się czegoś nauczyć, a nawet musiałem — by nie wypaść fatalnie w pierwszej edycji i kolejnych, jeśli zdecyduje się na udział.

Przyjrzyjmy się tym prawom w praktyce.

Simple: Plany muszą być proste

“Co da mi szybko punkty?” to nie jest pytanie o kompletną strategię. To pytanie o najprostszy możliwy pierwszy krok. W panice próbowałem ogarnąć wszystko naraz: łączenie z serwerem, logikę bota, optymalizację, strategię. To nie działa.

Jak nie uprościsz — nikt cię nie zrozumie. Albo będą udawać, że rozumieją, i nic nie zrobią.

Prioritize and Execute: Ustal priorytety i rób po kolei

“Jaki jest następny krok?” — nie wszystkie kroki. Następny. O najwyższym priorytecie.

Pod presją naturalny odruch to robić wszystko naraz. Poprawiać sleep, czytać instrukcję, debugować, pisać logikę, testować. Efekt? Nic nie jest zrobione dobrze.

Jak robisz wszystko naraz, jeździsz z pustą taczką. Inni widzą ruch, ale z punktu widzenia celów stoisz w miejscu. 5 zadań × 20% ukończenia = 0 punktów. Lepiej: 1 zadanie × 100% ukończenia = punkty.

Ruch, a nie bezruch

Z połączenia tych dwóch praw wyniknęła dla mnie ciekawa rzecz.

Warto się ruszać w jakimkolwiek kierunku i nie przekreślać sobie drogi do zmiany decyzji.

Ja musiałem szukać odpowiedzi na pytanie: “Co da mi szybko punkty?” — czyli prostota planu i priorytetyzacja.

Często w tej sytuacji lepiej jest zrobić krok w jakąkolwiek stronę niż stać bezczynnie. Ja zrobiłem tak, by bot wybierał jakąkolwiek kartę z ręki. Nie najlepszą, bo nie wiedziałem co to wtedy znaczy. Nie najgorszą, z tej samej przyczyny. Którąkolwiek.

I wtedy pojawiły się pierwsze punkty. Do dziś pamiętam radość, gdy zobaczyłem na tablicy wyników 0.2 punkta. Inni zgarniali po 30–40, ale ja dostałem swoje pierwsze 0.2.

Potem doprowadziłem go do stanu, że punktował już normalnie. O 22:30 był już drugi na serwerze. Więc mogłem zająć się innymi rzeczami…

Rozwiązałem swój problem. Ale konkurs to nie solowa operacja.

Praca Zespołowa

Gdy ogarnąłem burdel we własnej głowie i zacząłem być wartościowym graczem, okazało się, że z pomocą przyszły pozostałe dwa prawa bojowe.

Byliśmy w końcu trzyosobowym zespołem. A ja do tego momentu, ogarnięty własnymi problemami, byłem… tylko ogarnięty własnymi problemami. Siedziałem w swojej bańce paniki, podczas gdy dwóch innych ludzi robiło swoje — i nikt mi nie pomagał, bo nikt nie wiedział, że może pomóc.

Decentralized Command: Jasne granice, autonomia w działaniu

Pierwszym krokiem było poproszenie o pomoc techniczną. Nie “ratujcie mnie”, ale konkretne pytanie do konkretnej osoby. To otworzyło coś ważniejszego: zacząłem wychodzić z własnego kodu i zaglądać do tego, co robią inni.

Nie po to, żeby kontrolować. Po to, żeby zrozumieć, co każdy robi w swoim kawałku systemu. I jak to robi. Każdy z nas miał swojego bota, swój obszar odpowiedzialności, jasne granice. Ale te granice nie musiały być murami.

Cover and Move: Osłaniaj i wspieraj

I tu stało się coś, czego nie planowałem.

Dla “odmóżdżenia” zacząłem przeglądać kod i wyniki Seby. I zauważyłem: jego bot non stop był zalewany. Brakowało mu worków dookoła wyspy — które pominął, bo inaczej zinterpretował dokumentację.

Powiedziałem mu to. Poprawił. Zaczął działać lepiej.

Za chwilę Seba zadał mi pytanie w drugą stronę: “Czemu masz tylko dwa kolory w kartach? Czarny i czerwony?”

Nie wiedziałem. Spojrzałem. Rzeczywiście — nie grałem nigdy w karty, więc wydawało mi się, że są tylko dwa kolory: czerwony i czarny, a są cztery: karo, kier, pik i trefl.

To jest Cover and Move w najczystszej formie. Nie chodzi o to, żeby jeden ciągnął drugiego za rękę. Chodzi o to, że każdy działa autonomicznie w swoim obszarze, ale jednocześnie ma oczy na to, co dzieje się obok. Widzisz coś, co twój kolega przeoczył — mówisz. On widzi twój blind spot — mówi ci.

Nie konkurowaliśmy. Wspieraliśmy się.

Trochę szydery potem ze mnie było i z tych dwóch kolorów, ale to już pochodna kultury, w której się oboje wychowaliśmy.

Co Zostaje Po Presji

Potem dopiero możemy być zespołem. Ale to wymaga komunikacji i priorytetyzacji. Małych, zauważalnych kroczków, a nie jednego skoku na główkę.

I jeszcze jedno — by móc poruszać się w kryzysie, muszę ufać, że inni robią co potrafią najlepiej jak się da. I jednocześnie pozwalać im pomagać mi dojść do celu, tak jak ja pomagam im. Żebyśmy razem ogarnęli misję.

Po presji przychodzi ewaluacja

Gdy konkurs się skończył, nie świętowałem ani nie narzekałem na wynik — a zajęliśmy drugie miejsce. Usiadłem i zapisałem:

• Co zadziałało? (pytania, które przełożyły chaos na konstruktywne kroki)
• Co nie zadziałało? (sleep(2000), czytanie 50-stronowej instrukcji pod presją)
• Co zrobię inaczej następnym razem? (przygotować minimalne środowisko testowe PRZED startem)

Należy się przygotować na kolejny kryzys. Może on nie nadejdzie — ale z obecnego da się wycisnąć kwaśny sok z cytryny.

Ja lubię feedback na świeżo. Żeby wiedzieć o czym mówimy i skupić się na tym co istotne. Nie chodzi o to, żeby palić czarownice — chodzi o to, żebyśmy za rok byli lepiej przygotowani. Do kolejnej edycji Deadline24, ale też do wszystkiego co przyjdzie po niej.

Bo samo to doświadczenie sprawia, że staję się lepszym członkiem zespołu. Lepszym programistą. Może w przyszłości także liderem, który pomoże innym odnaleźć się w tak chaotycznej i nieprzewidywalnej sytuacji.

To jest proste jak budowa cepa.

Epilog: Frycowe to Inwestycja

Prawa bojowe brzmią prosto na papierze. Ale pod presją, gdy zegar odlicza i wszystko się sypie, muszą być podskórne. Przećwiczone. Automatyczne.

I jedyny sposób, żeby tam dotarły, to przejść przez ból pierwszego razu, wyciągnąć wnioski i świadomie je wypracować w spokoju.

Extreme Ownership mówi jasno: im twardszy trening, im bliżej sytuacji ekstremalnych — ale w kontrolowanym środowisku — tym mniejsze ryzyko, gdy naprawdę się posypie.

To działa tak samo z zespołem. Nie czekam na kryzys, żeby sprawdzić czy wiedzą co robić. Daję im środowisko, które jest wymagające, ale nie zabójcze. Dobre do nauki, ale nie tak komfortowe, żeby niczego się nie nauczyli.

Bo to jest cykl: uczysz się czegoś, wchodzi ci to pod skórę, sprawdzasz w boju. Jak nie pyka — albo coś zrobiłeś źle, albo po prostu to nie jest twoje. Tak czy siak — wiesz więcej niż przed.

Jako ojciec wiem, że nie da się dzieci ustrzec przed wszystkim. Choćbym latał i wszędzie przykleił folię bąbelkową, to i tak się kiedyś przewróci — choćby na podwórku. Tak samo jest w zespole. Nie sprawisz, że wszyscy będą żyli długo i szczęśliwie. To nie bajka. To życie usłane błędami, z których naprawdę można się dużo nauczyć. I przygotować się, by drugi raz nie popełnić tych samych błędów.

To druga część serii o architekturze liderstwa. Pierwsza część o Extreme Ownership dostępna tutaj.