W zeszłym tygodniu poświęciłem cały artykuł na opisanie roli Solution Architecta w AWS. Generalnie zamiar był taki, aby zamknąć temat w ramach jednego wpisu. "Prawie" mi się to udało, bo napomknąłem o specyficznej kulturze organizacji, ale nie rozwijałem tematu, żeby nie rozdmuchiwać za bardzo (już i tak długiego) posta.

Dziś zamierzam uzupełnić tę lukę (a od przyszłego tygodnia jedziemy już z zupełnie innym tematem, i wracamy do języka angielskiego - sorry, not sorry).

Jeśli spodziewasz się w miarę kompletnego opisu kultury Amazonu, to niestety muszę Cię rozczarować. Napisano całe książki na ten temat (np. "Working Backwards" C. Bryara i B. Carra) i ... z perspektywy osoby, która dołączyła do organizacji po ich przeczytaniu, muszę przyznać, że faktycznie nie rozmijają się one z prawdą. Zatem odsyłam Cię właśnie do nich, a w tym artykule skoncentruję się na tych aspektach, które są bardziej odczuwalne (specyficzne?)  z perspektywy osoby dołączającej do organizacji. Nie będzie zatem nic o "two pizza teams", "service-oriented Bezos memo", "door desks" i innych takich. Well, maybe next time.

Zanim zaczniemy na dobre: będę pisał o kulturze Amazonu, ale z perspektywy pracownika AWS (Amazon Web Services). Teoretycznie jest to ta sama kultura, ale oczywiście nie mam danych wystarczających, aby potwierdzić lub zadać kłam tej tezie.

Duży, ale inaczej

Co na wstępie trzeba wiedzieć o AWS? No coż, to jest bardzo duża organizacja. Ale (co ciekawe), bardzo duża organizacja, która umiała (nauczyła?) się przeskalować w sposób, który nie zabił jej efektywności. Pod tym względem - mówimy o prawdziwym unikacie. Więc np. zdecydowanie nie nazwałbym jej (typową) korporacją. Nie zrozumcie mnie źle - tu SĄ elementy/mechanizmy typowe (i prawdopodobnie niezbędne do funkcjonowania) dla typowej korporacji tej skali, ale są one bardzo mocno oddzielone od pracy znakomitej większości pracowników. Gdybym miał to krótko opisać, to pewnie tak:

Każdy ma tu swoją robotę do wykonania, ale praca dzieje się "równolegle" (każdy zajmuje się swoją działką), zamiast typowego (?) układu: pracownik <- nadzorca L1 <- nadzorca L2 <- ...

Jak to możliwe? Dlaczego to (tak sprawnie) działa? To wypadkowa kilku elementów:

  1. Po pierwsze struktura jest mocno płaska (jak na taką liczebność) - i leadership jest oczekiwany od KAŻDEGO (literalnie): każdy musi umieć przyjąć właścicielstwo nad tematem i go poprowadzić (zamiast np. marudzić). Oczywiście skala i stopień komplikacji tematów powinny korespondować z doświadczeniem i umiejętnościami danej osoby.
  2. "Single-Threaded Leadership" - gloria i chwała nie dla tych, którzy wezmą "na klatę" 100 tematów (które potem ciągną się latami), ale tych, którzy zobowiążą się np. do jednego, ale sprawnie, efektywnie i transparentnie doprowadzą go do końca (a potem oczywiście wezmą się za kolejny ;>).
  3. Jak zbudować decyzyjność bez konieczności ciągłego nadzoru i posiadania "approvera" naszym działań? W Amazonie odbywa się to poprzez tzw. Leadership Principles - swoiste przykazania (stały zestaw), na które ludzie powołują się w praktycznie każdej konwersacji: znacznie łatwiej jest przeforsować jakąkolwiek decyzję, jeśli jest ona zgodna z (wspiera, implementuje) Leadership Principles - dla kogoś dołączającego do organizacji taki model argumentacji może być sporym zaskoczeniem.
  4. No i koniec końców - Tenets. Czyli zbiór zasad działania (modus operandi) właściwych dla naszej roli/funkcji (opartych oczywiście na pomyśle na daną rolę ORAZ na Leadership Principles - w kontekście tejże roli. Taka "mini-konstytucja", którą zawsze można ulepszyć ("Unless You Know Any Better" jest powtarzane jak mantra)

W praktyce: działając transparentnie (pokazując wyniki swojej pracy) w ramach swoich Tenets i w swoich priorytetach kierując się Leadership Principles, a do tego nie rozdrabniając się (zgodnie z "Single-Threaded Leadership"), jesteśmy w stanie działać w dużej mierze samodzielnie i autonomicznie.

Brzmi dobrze? To fajnie, ale wbrew pozorom nie jest to idealny układ dla każdego. Jak to?

  • odnajdą się w nim ludzie "goal-driven", ale nie "task-driven" - wymaga dobrej organizacji pracy własnej (focus, transparencja) i dużej konsekwencji (autonomia wiąże się z jasno-sprecyzowaną odpowiedzialnością)
  • niektórzy lubią hierarchię (kontrolę) i możliwość stopniowego budowania swojego dominium - w AWS zdecydowanie trudniej będzie im o samo-realizację
  • "Single-Threaded Leadership" to nie tylko ułatwienie priorytetyzowania i ograniczenie przełączania kontekstu: nie możesz rzucić się na ciekawy temat a potem (gdy zrobisz to co najciekawsze i się znudzisz) po prostu go zostawić bez właścicielstwa; "You build it = you run it" aplikuje się tu w całej rozciągłości

"Peculiar"

Autonomia autonomią, ale nie bez powodów o kulturze Amazonu mówi się "peculiar", czyli ... hmmm, osobliwa?

  1. Po pierwsze, to kultura słowa pisanego. MUSISZ umieć wyrażać swoje myśli w sposób zwięzły, precyzyjny, przekonujący. Każdy musi umieć napisać narrative, 6-pagera, PR-FAQ, itd. Oraz dokumentować swoją pracę w sposób który zdejmuje z Ciebie bycie the "single-source-of-truth".
  2. Pisanie to jedna strona medalu - wiem, że to brzmi wręcz niedorzecznie, ale ... musisz umieć ... czytać. Ze zrozumieniem, krytycznie, całkiem sporo. To nie mit - spotkania często rozpoczynają się np. od 10 minut na przeczytanie krótkiego dokumentu i cel jest taki, aby zakończyły się w sposób konstruktywny (posunęły temat do przodu w kwestiach merytorycznych). To trudniejsze niż się wydaje.
  3. Równie ważna (jak umiejętność pisania/czytania) jest zdolność do podejmowania decyzji. Znowu - brzmi to trywialnie, ale sprowadza się do rozpoznania ("w locie"), czy mamy do czynienia z decyzją przypominającą obrotowe drzwi jednokierunkowe (decyzja nie-/trudno-odwoływalna, z poważnymi/drogimi konsekwencjami) czy dwukierunkowe (decyzja, którą łatwo/szybko można odwrócić) - o ile te drugie nie wymagają dłuższej deliberacji i powinny być podejmowane bardzo szybko (predkość >>> pewność), to te pierwsze wymagają właściwego rozpoznania i głębszego zastanowienia.
  4. "Peculiarity" objawia się również np. przy rekrutacji (wiedza teoretyczna/deklaracje są znacznie mniej istotne niż odniesienia do faktycznych doświaczeń/zachowań i wprowadzanie deklaracji w czyn) oraz poprzez tzw. Day 1 culture - tu nikt nie podnieca się specjalnie osiągnięciami dnia wczorajszego: dziś jest zupełnie nowe rozdanie, które może przewrócić status quo do góry nogami, więc lepiej skoncentruj się, jakbyś startował(a) z pozycji totalnego underdoga.

I  jeszcze jednej ważny (bardzo osobisty) wtręt. To, co się naprawdę bardzo udało, a o czym się praktycznie nie mówi - w przeciwieństwie do baaardzo wielu firm międzynarodowych, AWS nie jest firmą oddziałową a prawdziwie globalną. Nigdy nie czułem się częścią "AWS Polska" albo "AWS Europa Centralna", ale "AWS" - firma jest zorganizowana tak, abym miał minimum handicapu względem moich kolegów i koleżanek z regionów, gdzie np. AWS jest lokalnie obecny (biura) znacznie dłużej (np. US).

Nie wiem czy zdajecie sobie z tego sprawę w pełni, ale to jest KOLOSALNA różnica. Ten sam dostęp do zasobów, ludzi, narzędzi, bez względu na to czy pracujecie z Seattle, Warszawy czy Bangalore - to jest game-changing factor: czy to jeśli chodzi o Wasz rozwój czy możliwość zrobienia prawdziwej różnicy w forpoczcie kolejnej fali technologicznej rewolucji ...

Ten model oczywiście nie będzie pasował wszystkim:

  • nie każdy umie/chce pisać (w sposób efektywny) - tego trzeba się nauczyć, to trzeba stale trenować (praktykując) i wbrew pozorom nie jest to trywialne
  • wiele osób ma odruch/instynkt chomikowania wiedzy i budowania swojej krytyczności poprzez wchodzenie w rolę eksperta magazynującego unikalną wiedzę (bo tak szybciej, bo szkoda czasu, ...) - w AWS natomiast KAŻDY musi mieć świadomość, że ... de facto jest tylko trybem w maszynie - wartościowym, użytecznym, ale też bezwzględnie wymienialnym
  • z tymi decyzjami też nie ma lekko - nie da się uciec od accountability; tu nie spoczywa ono na managerach/szefach - każdy jest właścicielem/opiekunem swoich zobowiązań (co oczywiście wymaga pewnej dojrzałości i zawsze stanowi pewne obciążenie psychiczne)

Myślenie długoterminowe

Gros osób "wychowywanych" zawodowo w innych firmach jest przyzwyczajonych do podejmowania decyzji zoptymalizowanych na efekt krótko-terminowy ("dowieź ten projekt", "dokończ ten sprint", "zrób wynik na ten kwartał"). To dość wygodny układ - nie wymaga ani wielkiej cierpliwości, ani podpierania się danymi (w sposób zdyscyplinowany). W AWS działa to inaczej ...

  1. Korzyść długoterminowa >>> korzyść krótkoterminowa. Co oznacza konieczność nie tylko strategicznego myślenia, ale też posiadania umiejności budowania mechanizmów typu "koło zamachowe", czyli takich, które stopniowo wzmacniają swój własny efekt (output dodaje się do inputu kolejnej "iteracji").
  2. Właśnie - mechanizmy - w AWS wszyscy zdają sobie sprawę z tego, że dobre chęci to zdecydowanie za mało. Dlatego powszechne jest budowanie tzw. "mechanizmów", które zachęcają a czasami wręcz zmuszają do pożądanych zachowań (np. postępowania zgodnie z tenetami). Mechanizm może być automatyzacją, raportem, narzędziem, procesem, itp. - przede wszystkim jest formą utrwalania kultury przez jej wzmocnioną automatycznie habitualizację.
  3. Jeśli myślisz, że wiesz co oznacza bycie "data-driven", to zapraszam do AWS :) Tu nie możesz po prostu wyskoczyć na środek ze swoją opinią i "podeprzeć" się swoim stanowiskiem (a'la HiPPO) - dosłownie każdy może zapytać o przesłanki (twarde dane) i ... na ogół pytają :) Poważane są zarówno twarde dane liczbowe jak i udokumentowane tzw. "anecdotes" (real-life cases, ilustrujące ciekawe przypadki, które mogą ginąć - z różnych powodów - w statystyce).
  4. To że coś jest nie/trudno-mierzalne, nikogo tu nie paraliżuje. Po prostu, jeśli nie jesteśmy w stanie użyć outcome metrics (wskaźników mierzących wynik naszych działań), to posiłkujemy się input metrics (miarami naszych wysiłków, którymi chcemy osiągnąć te wyniki) i badamy, czy ma miejsce jakikolwiek (miejmy nadzieję: pozytywny) wpływ na outcome. Nie jest to model doskonały, ale pomaga w ustawieniu odp. kierunku.
  5. At last but not least - to może nie brzmi w specjalnie fascynujący sposób - ale gros decyzji produktowych w tej firmie jest podejmowanych w oparciu o 2 pryncypia: feedback od użytkowników/klientów ("customer obsessed") i tzw. "working backwards", czyli zamiast stawiania na jakieś zupełnie nowatorskie (ale jeszcze nie umieszczone w żadnym konkretnym kontekście) wizje, zdecydowanie wychodzimy od realnego (udokumentowanego, mierzalnego) problemu i staramy się go punktowo (/systemowo) zaadresować.

Powyższe punkty będą trudne do przełknięcia dla wielu osób:

  • człowiek czasem ma wrażenie, że mechanizmy nim wręcz RZĄDZĄ - i budzi to pewien dyskomfort (swoista "bezduszność" systemu) - ale o ile mamy prawo je feedbackować (wpływając na ich ewolucję - bo przecież sami je budujemy), trzymamy się zasady "disagree & commit" - mechanizmy nie są po to, aby je obchodzić
  • największy szok poznawczy to wejście w kulturę data-driven; Twoja role/pozycja/staż nie ma żadnego znaczenia - KAŻDY może zakwestionować Twoją opinię (zapytać o twarde dane na jej poparcie) i ... ludzie to robią; oczywiście wyrabia to nawyk pro-aktywnego sięgania do danych, ale na początku może być bardzo trudne (zwłaszcza, gdy ktoś ma mocno wybujałe ego ;>)
  • konieczność uzasadniania swoich propozycji/pomysłów twardą wartością dla klienta (zamiast kreślenia wizjonerskich pomysłów sprzedażowych ...) może dla wielu osób brzmieć jak "kaganiec", ograniczający bardziej odważne/nowatorskie pomysły - no cóż, taki jest Amazonowy pomysł na rozwój i wzrost: są obiektywne dane mówiące, że może on mieć sens :)

Podsumowując

Pracuję zawodowo od 21 lat. Miałem okazję pracować w oraz doradzać bardzo różnym organizacjom. Myślę, że Amazon jest zdecydowanie najbardziej wyrazistą z nich. O ile małe organizacje często mają mocną kulturę, która przyszła z ich founderami (i ich przekonaniami/filozofią pracy), to im większa organizacja, tym szybciej się ona (kultura) zatraca. W bardziej dysfunkcyjnych środowiskach tworzy się anty-kultura, w pozostałych osobne kultury per zespół (zależne od liderów). Amazonowi udało się przed tym (pewnie nie do końca, ale w dużej mierze) obronić.

Z jednej strony żałuję, że nie miałem szansy poznać AWS jeszcze przed pandemią (w wariancie bardziej "stacjonarnym"), ale zdaję sobie sprawę, że to właśnie pandemia zdjęła wiele geograficznych barier na rynku pracy - być może gdyby nie COVID, nigdy nie wylądowałbym w AWS.

Jak znam życie, wiele osób tak silną kulturę będzie określać mianem "sekty" - dla mnie wyrazista kultura oznacza mocny "social contract": wszyscy bardzo dobrze wiemy "na jakim wózku jedziemy", do czego się zobowiązujemy, czego od siebie oczekujemy. Lubię to, bo widzę na co się piszę.

Oczywiście trudno przełknąć świadomość bycia zastępowalnym trybem maszyny (bez względu na poziom stanowiska), ale nie jest to zła cena za możliwość przyjrzenia się z bliska jak można efektywnie skalować dużą i skomplikowaną organizację, jak buduje się największą platformę chmurową na świecie, jak kształtuje się kolejne generacje produktów, które będą za chwilę używane do uruchamiania aplikacji Internetowych w hiper-skali.

Mnie to przekonało. Na ile przekonuje to Ciebie - no cóż, nie mnie oceniać. Ale jeśli pojawią się jakies pytania/wątpliwości odnośnie czekolwiek co napisałem powyżej - zapraszam do kontaktu.

P.S.

To NIE jest materiał oficjalny AWS, tylko moje osobiste obserwacje.
Opinie i opisy są moje i nie muszą odpowiadać oficjalnej terminologii (/stanowisku) Amazonu.
Za artykuł nikt mi nie zapłacił, ani nikt nie zlecił mi jego napisania. Żadne informacje zawarte w artykule nie są poufne, więc nie ujawniam niczego o czym nie napisano już oficjalnie w wielu źródłach (Amazonowych i zewnętrznych).

Share this post