Nikt nie wie, co robi. I to jest normalne.

Od zawsze myślałem, że świat jest bardziej poukładany niż jest w rzeczywistości. Że w korporacjach istnieją zasady, procedury i dobre praktyki, które sprawiają, że wszystko działa jak w zegarku. Że seniorzy i liderzy wiedzą dokładnie co robić, a juniorzy po prostu muszą się tego nauczyć.

Prawda jest taka, że świat jest bardzo chaotyczny, niepewny i pełen niedoskonałości. Można by pomyśleć, że działa na trytytki.

Nikt nie wie co dokładnie ma robić

Każdy zespół i każda firma operuje na niepełnych informacjach i mniej lub bardziej uzasadnionych przeczuciach. Nikt nie wie dokładnie co robić, ale wszyscy próbują zrobić coś, co pcha sprawy do przodu. To jest normalne i zdrowe.

Ta pewność siebie, którą widzisz u seniorów, tech leadów i CTO na konferencjach, jest w dużej mierze performancem. Nie dlatego że są nieuczciwi, ale dlatego że nauczyli się mówić zdecydowanie o rzeczach, co do których mają 60% pewności. Taka jest praca. Im wyżej w hierarchii, tym lepiej opanowana ta umiejętność.

Jest w tym zresztą paradoks: im więcej wiesz, tym bardziej zdajesz sobie sprawę z tego, jak mało wiesz. Juniorzy często brzmią pewniej niż seniorzy, bo nie widzą jeszcze ile rzeczy może pójść nie tak.

Przykład z IT: nikt nie wie jak zrobić dobry framework do JavaScripta. Next.js przeszedł przez wiele iteracji, eksperymentów i błędów. Dziś wygląda na całkowicie inny produkt niż ten, który był na początku. Ale nikt nie wie jak będzie wyglądał za rok, bo nikt nie wie jakie problemy i wyzwania pojawią się po drodze.

Duża część rzeczy powstaje przy minimalnym wysiłku

Produkty, firmy, projekty, które wyglądają na dopracowane, szczególnie te mniejsze, często są efektem kilku godzin pracy, a nie miesięcy. Software house, który sprawia wrażenie bardzo profesjonalnego, może być prowadzony przez trzy osoby i może być zrobiony z dobrej templatki strony. Z drugiej strony, projekt, w który ktoś włożył pół roku, może wyglądać gorzej niż coś zrobionego w weekend.

Wiele razy zdarzyło mi się, że firma, która wyglądała na profesjonalną, była prowadzona przez ludzi, którzy nie mieli pojęcia o biznesie, marketingu czy sprzedaży - po prostu Januszex. Z drugiej strony, widziałem projekty, które były robione przez ludzi z pasją i wiedzą, ale wyglądały jakby były zrobione w 5 minut. To pokazuje, że wygląd i jakość nie zawsze idą w parze.

Wysoka jakość efektu końcowego i wysoki nakład pracy to dwie różne rzeczy. Często nie mają ze sobą wiele wspólnego.

Większość wartości pochodzi z pierwszych 20-40% pracy. Reszta to polerowanie, które rzadko widzi ktoś poza autorem.

Przykład: software house, który używa AI do tworzenia produktów. Na pierwszy rzut oka produkt wygląda na dopracowany, ale w rzeczywistości jest tak, że nie ma testów, dokumentacji, wszystko jest pogmatwane i nie wiadomo jak to działa. Najlepsze jest to, że takie firmy prowadzone są przez osoby, które mają pojęcie o programowaniu, ale specjalnie nie dbają o jakość, bo wiedzą, że to nie jest kluczowe dla ich biznesu. Klienci i tak będą zadowoleni, bo dostaną coś, co działa wystarczająco dobrze. Problem dopiero pojawi się, gdy klient będzie chciał coś dodać albo zmienić, ale wtedy będzie już za późno, bo kod będzie tak zły, że nikt nie będzie chciał się do niego dotknąć. To jest często spotykana sytuacja w małych firmach IT.

Odwrócony przykład: wiele osób, w tym ja, ma tendencję do nadmiernego dopieszczania CV, portfolio czy innych rzeczy, które są ważne ale nie kluczowe. Czasami wysiłek nie tylko nie koreluje z efektem, ale aktywnie przeszkadza, prowadząc do paraliżu decyzyjnego i odkładania w nieskończoność.

Pieniądze nie są dobrym miernikiem wartości

Można mieć wrażenie, że pieniądz jest najbardziej „obiektywną” częścią całego systemu. Że coś kosztuje tyle, ile jest warte, i że rynek w jakiś sposób wycenia rzeczy w miarę precyzyjnie. W praktyce to kolejny obszar, w którym działa ta sama zasada: wystarczająco dobrze, wystarczająco szybko, wystarczająco wiarygodnie.

Pieniądz rzadko jest wprost nagrodą za jakość w sensie technicznym. Jest nagrodą za dopasowanie do problemu, który ktoś realnie ma w danym momencie. To oznacza, że możesz robić coś lepiej w sensie absolutnym i zarabiać mniej, jeśli to „lepiej” nie rozwiązuje niczego istotnego albo przychodzi za późno. I odwrotnie, czyli można robić coś przeciętnego, ale trafiającego w konkretny ból rynku i być za to dobrze wynagradzanym.

Duża część tego, co nazywamy dobrym zarobkiem, jest też subiektywna. 20 tysięcy złotych może być ogromną kwotą dla jednej osoby i przeciętną dla innej, w zależności od kontekstu, kosztów życia, zobowiązań i punktu odniesienia. Pieniądz nie ma naturalnej skali „dużo-mało”, tylko skalę relacyjną, którą każdy ustawia sobie inaczej.

Do tego dochodzi jeszcze coś mniej intuicyjnego: ludzie nie płacą tylko za rezultat, ale za redukcję niepewności. W wielu przypadkach kupuje się nie tyle produkt czy usługę, co spokój decyzyjny, czas albo ryzyko, które ktoś bierze na siebie. Dlatego branding, reputacja, jak coś wygląda i pewność komunikacji potrafią mieć większy wpływ na cenę niż sama jakość techniczna.

To też tłumaczy, dlaczego rynek często nagradza rzeczy wystarczająco dobre + na czas bardziej niż rzeczy optymalne, ale spóźnione. W świecie ograniczonych zasobów i niepełnych informacji liczy się nie maksymalizacja jakości, tylko minimalizacja ryzyka złej decyzji.

Pieniądz wzmacnia przy tym iluzję porządku. Wysokie stawki, duże firmy i poważne rozmowy sprawiają, że łatwo uwierzyć, że gdzieś musi istnieć dobrze zaprojektowany system, w którym wszystko jest policzone i przewidywalne. A często jest dokładnie odwrotnie, tylko stawki są większe, a decyzje nadal podejmowane są na podstawie heurystyk, doświadczenia i tego, co „mniej więcej działa”.

Gdyby cena była dobrym miernikiem rzeczywistej wartości, trudno byłoby wyjaśnić istnienie tysięcy produktów premium, których przewaga funkcjonalna jest minimalna względem tańszych odpowiedników. A jednak ludzie regularnie płacą wielokrotnie więcej za markę, opakowanie, historię produktu czy sygnał społeczny, jaki wysyła jego posiadanie. W praktyce kupujemy nie tylko rzeczy, ale również znaczenia przypisane do tych rzeczy.

Przykładowa sytuacja: zatrudnianie hydraulika

Załóżmy, że masz wyciek z rury w mieszkaniu w sobotę o 23:50. Dzwonisz do trzech hydraulików:

• Pierwszy mówi, że może przyjechać za 30 minut, ale kosztuje 500 zł.
• Drugi mówi, że może przyjechać za 2 godziny, ale kosztuje 300 zł.
• Trzeci mówi, że może przyjechać rano, ale kosztuje 150 zł.

Zastanów się którego z nich byś wybrał i dlaczego. Zapewne dla wielu pierwszy będzie najlepszym wyborem, dlatego że:

• Redukuje stres i niepewność związaną z zalaniem mieszkania.
• Pieniądz jest buforem dla wykonawcy usługi. Wyciek może być bardzo poważny, albo banalny do naprawienia. Płacąc więcej, płacisz też za to, że ktoś bierze na siebie ryzyko, że będzie musiał zrobić coś więcej niż tylko zakręcić wodę.
• Dopasowanie do problemu. Najlepszy hydraulik w mieście, który przyjdzie za tydzień, jest tu bezużyteczny. Wygrywa ten, który rozwiązuje twój konkretny problem w tym konkretnym momencie.

Przykład z mojego doświadczenia:

Kiedyś dostałem zlecenie stworzenia aplikacji webowej. Z braku doświadczenia i ze strachu przed odrzuceniem wyceniłem go zbyt nisko. Myślałem, że to lepsze niż nie dostać go wcale. Projekt szybko zaczął puchnąć, a z małego zlecenia zrobił się potężny, skomplikowany system.

Zamiast na bieżąco raportować problemy i renegocjować stawkę, zacząłem gonić własny ogon. Efekt? Choć dowoziłem coraz większą wartość techniczną, klient był niezadowolony i mnie poganiał.

Gdybym wtedy potrafił argumentować swoje decyzje, pokazywać wyzwania technologiczne i to, jakie ryzyka dla jego biznesu eliminuję, bez problemu dostałbym 40-50% więcej. Te dodatkowe pieniądze nie byłyby dopłatą za “lepsze linijki kodu”, ale opłatą za jego święty spokój i poczucie kontroli. Przez brak komunikacji wokół projektu urosła chmura niepewności, a klient zamiast partnera widział po prostu opóźniającego się wykonawcę. Pieniądz na rynku nie wycenia kodu, wycenia redukcję stresu u tego, kto płaci.

Dopiero wtedy zrozumiałem, że nie warto bać się wyceny swojej pracy. Klient nie płaci za wykonanie zadań, płaci za efekt po swojej stronie, za problemy które znikają i ryzyko które bierzesz na siebie. Klient który odpada przy wyższej stawce, często nie miał budżetu adekwatnego do swojego problemu. To nie jest twoja strata.

Gdzie nie spojrzysz, to jest mniej więcej

Można by pomyśleć że to patologia. Że gdzieś istnieje firma, branża albo poziom kariery gdzie wszystko jest poukładane i pewne. Nie istnieje.

Świat nie czeka na optymalne rozwiązania, bo optymalne rozwiązania prawie nigdy nie są dostępne na czas. Działa na rozwiązaniach wystarczających, wdrożonych wystarczająco szybko, przez ludzi którzy mniej więcej wiedzą co robią.

Herbert Simon - ekonomista, laureat Nobla, opisał to pojęciem „satisficing”: ludzie i organizacje nie maksymalizują, tylko szukają pierwszego rozwiązania które jest wystarczająco dobre. Tak działa ludzki mózg, tak działają firmy, tak działa rynek. Nie dlatego że jesteśmy leniwi, ale dlatego że w warunkach niepewności i ograniczonych zasobów, „wystarczająco dobre teraz” prawie zawsze bije „idealne za późno”.

Schematy są dużo rzadsze, niż nam się wydaje. Większość z nich nie opisuje świata takim, jaki jest, tylko daje przybliżenie, które jest wystarczająco dobre w określonym kontekście. Frameworki, procesy czy modele biznesowe to bardziej mapa niż teren. Problem zaczyna się wtedy, gdy ktoś myli jedno z drugim i zakłada, że rzeczywistość będzie zachowywać się zgodnie z diagramem.

Tak naprawdę podobnie jest niemal wszędzie. Aplikując do firmy, nie wiesz dokładnie czego szuka rekruter, które doświadczenia uzna za najważniejsze ani jakie cechy przeważą ostatecznie na twoją korzyść. Możesz znaleźć dziesiątki poradników, ale żaden z nich nie opisze w pełni konkretnej sytuacji.

Schematy są przydatne jako punkt wyjścia, ale rzadko działają jako uniwersalna instrukcja obsługi. Trzymanie się ich zbyt kurczowo może wręcz przeszkadzać, bo ogranicza kreatywność, eksperymentowanie i zdolność adaptacji do sytuacji, które nie pasują do podręcznikowego przypadku.

Co mam przez to na myśli? To, że jeśli chcesz być w czymś dobry, to po ucz się i rozwijaj. Brzmi dziwnie, ale tak to działa. Nie każdy wie wszystko o wszystkim, percepcja ludzi na temat kogoś jest często bardziej złożona niż rzeczywistość. Czasami ludzie wydają się mieć wszystko pod kontrolą, ale w rzeczywistości też nie wiedzą dokładnie co robią. Nie ma jednego przepisu na sukces, ale jest wiele małych kroków, które zwiększają szansę, że osiągniesz cel.

Przykład z życia codziennego: Idziesz do sklepu po chleb. Po drodze zauważasz, że w chodniku praktycznie co metr kostka jest krzywo ułożona. No niby jest krzywo, ale nikomu nie przeszkadza, więc nikt z tym nic nie robi. W sklepie masz do wyboru 5 różnych rodzajów chleba. Nie masz czasu ani energii, żeby analizować skład, porównywać ceny i pytać o rekomendacje. Wybierasz ten, który wygląda na wystarczająco dobry i jest w miarę świeży. Wracając do domu mijasz pracownika miasta, który kosi trawę. Zamiast idealnie przyciąć każdy krzak, po prostu jedzie kosiarką i robi to wystarczająco dobrze, żeby trawa nie była za długa. Tak wygląda większość rzeczy w życiu. Nie są idealne, ale są wystarczająco dobre, żeby działać.

Co z tym zrobić

Satisficing ma sens dopóki nie działasz z rzeczami które rosną. Baza danych jest wystarczająco szybka do momentu gdy nie jest. Kod jest wystarczająco czytelny do momentu gdy musisz go zmienić o 2 w nocy. W IT dług techniczny jest jedną z niewielu rzeczy które narastają bez twojej zgody i przypominają o sobie w najgorszym momencie.

Dlatego głęboka wiedza techniczna jest w tej branży ceniona inaczej niż gdzie indziej. Nie dlatego że IT jest bardziej merytokratyczne. Ale dlatego że ktoś kto rozumie bazę danych widzi problem zanim dane urosną dziesięciokrotnie. Satisficing jest domyślnym trybem świata, ale żeby wiedzieć kiedy go wyłączyć, musisz rozumieć co trzymasz.

To jest właśnie odpowiedź na to, że nikt nie wie co dokładnie ma robić. Nie wszyscy muszą wiedzieć wszystko, ale ktoś musi wiedzieć wystarczająco dużo żeby zobaczyć minę zanim na nią wejdzie. Impostor syndrome często bierze się z porównywania się do ludzi którzy brzmią pewniej niż są, ale w IT pewność siebie nie ochroni cię przed bazą danych która przestała działać o 2 w nocy.

I może dlatego świat nie jest zbudowany dobrze. Jest zbudowany wystarczająco dobrze, żeby się nie rozpadł w trakcie użytkowania.