Lider technologiczny na podstawie przypadków

utworzone przez Marcin Żmigrodzki

“Jeżeli ogrodzisz ludzi płotem, otrzymasz owce. Daj ludziom przestrzeń, której potrzebują”.

William L. McKnight, prezes 3M

“Najpierw ludzie, zyski podążą!”

Jerry Sanders, prezes AMD

““Jeśli byłoby możliwe stworzenie warunków, w których ludzie mogliby się zjednoczyć w duchu pracy zespołowej i w pełni wykorzystać swoje umiejętności technologiczne, to taka organizacja przyniosłaby niezmierną radość i niezliczone korzyści.”

Masaru Ibuka, prezes Sony

“Tylko paranoicy przetrwają”

Andy Grove, prezes Intel

“Osoby o naprawdę wysokich oczekiwaniach mają bardzo niską odporność”

Jensen Huang, prezes Nvidia

Artykuł jest fragmentem książki Bardziej niż Agile będącej w trakcie druku: https://onepress.pl/ksiazki/bardziej-niz-agile-marcin-zmigrodzki,baragi.htm#format/d

Generał Groves, kierujący projektem Manhattan, określony został przez bliskiego podwładnego jako najgorszy sukinkot. Był człowiekiem aroganckim, przekonanym o słuszności swoich opinii i narzucającym innym swoją wizję działania. Jednocześnie potrafił skutecznie zarządzać setkami inżynierów i naukowców i doprowadzić do skonstruowania bomy atomowej. Ludzie bali się wejść do windy ze Stevem Jobsem, aby nie narazić się i nie zostać zwolnionym.

Liderzy innowacyjni są różnymi ludźmi. Czasem są sympatycznymi kolegami, a czasem zawziętymi despotami. Zatem warto się zastanowić, co ich łączy. 

Zatem ten rozdział postanowiłem napisać od innej strony. Dotąd źródłem wiedzy były badania naukowe, dobre praktyki cytowane w rozmowach oraz koncepcje publikowane przez uznanych autorów w książkach. W trakcie jednej z konferencji o zarządzaniu projektami uczestnik zagadnął mnie, czy czytam biografie słynnych liderów w biznesie. Odparłem, że raczej nie, bo nie pasjonuje mnie literatura hagiograficzna, ale po paru dniach zreflektowałem się.

Studium pojedynczego przypadku znajduje się dość nisko na piramidzie dowodów, ale jednak stoi wyżej niż stwierdzenie “mi się wydaje…”, “a guru na TED powiedział, że …”. Gdyby zebrać kilka przypadków i spróbować dokonać metaanalizy cech słynnych liderów oraz ich stylów zarządzania, to może udałoby się oddzielić aureolę od eklezjasty. Tak powstał ten rozdział.

Do analizy dobrałem kilka znanych postaci ze świata biznesu, a dokładniej ze spółek technologicznych. Były to Thomas Edison (założyciel Menlo Park Laboratory oraz Edison Electric Light Company przekształconej później w giganta General Electric, wynalazca ponad setki rozwiązań, w tym cewki indukcyjnej, mikrofonu, fonografu, żarówki elektrycznej, silnika prądu stałego, betoniarki, krzesła elektrycznego), Alexander Bell (założyciel Bell Labs przekształcone później w AT&T giganta telekomunikacyjnego), William Shockley (Shockley Semiconductors, nagroda Nobla za wymyślenie tranzystora), Joseph C. Wilson (założyciel Xerox), David Packard i William Hewlett (założyciele HP), Masaru Ibuka i Akio Morita (założyciele Sony), Gordon Moore (założyciel Intel), William Gates (założyciel Microsoft), Steve Jobs (założyciel Apple, Pixar), Jensen Huang (założyciel Nvidia), Jerry Sanders (założyciel AMD), Elon Musk (założyciel Paypal, Tesla, Spacex), Larry Page (założyciel Google), Richard Branson (założyciel serii firm ze słowem Virgin w nazwie).

Kryteria doboru, jakie przyjąłem były takie: firma musiała osiągnąć spektakularny sukces biznesowy (tu wyjątkiem jest William Shockley, ale o tym później), sukces musiał opierać się na przełomowych innowacjach technologicznych, lider musiał był założycielem firmy i być bezpośrednio odpowiedzialny za jej rozwój przez dłuższy okres (z tego powodu odrzuciłem IBM, których początki były dość pogmatwane, jednocześnie wyjątkiem jest McKnight z 3M, który nie zakładał tej firmy, ale całe zawodowe życie był z nią związany).

Lektura książek oraz oglądanie dokumentów o tych osobistościach pozwoliło mi wyciągnąć wnioski na temat cech, które się powtarzały. Niektóre z nich były dość oczywiste, ale inne mniej. Poniżej je omawiam.

Ekspert technologiczny

Wszystkie wymienione wyżej postaci łączyła cecha, którą określiłbym jako ekspert w technologii, a przynajmniej ktoś, kto jest mocno zainteresowany aspektami technologicznymi. Ani jeden z liderów innowacyjnych przedsiębiorstw technologicznych nie oddawał całkowicie kompetencji technicznych związanych z tworzeniem produktu czy technologii. Czasem delegowali wspólnikom obowiązki biznesowe, ale i to rzadko. Techniczne zawsze były po stronie lidera. Oczywiście lider nie wykonywał wszystkich prac samodzielnie, firmy, którymi zarządzali miały po kilka tysięcy pracowników. Jednak regularnie w wybranych obszarach lider schodził ze swoich szczytów wiele szczebli niżej, aż do poziomu gruntu, i skupiał swoją uwagę na detalach.

To burzy mit o tym, że wystarczy znać się na zarządzaniu, aby być w stanie poprowadzić innowacyjny zespół techniczny. Mam przekonanie, że to jest nieefektywne.

Wobec Steve Jobsa narosło sporo kontrowersji odnośnie jego wiedzy technicznej, bowiem nie miał kierunkowego wykształcenia. Steve Wozniak w jednym z wywiadów bardzo krytycznie wypowiadał się odnośnie wkładu w technikalia swojego wspólnika. Ale nawet wobec niego jego współpracownicy uznają, że był w stanie wejść w skrajnie drobne detale rozwiązań. 

Zacytuję Breta Bilberry’ego, który pracował w Apple przy iMacu: “Musieliśmy wymienić zewnętrzną kamerę iSight, która była kamerą CCD, na wewnętrzną kamerę CMOS. Stworzyliśmy prototyp iMaca z nowym przetwornikiem obrazu CMOS i umieściliśmy go obok systemu ze starym zewnętrznym przetwornikiem CCD iSight. Było to porównanie A/B i zorganizowaliśmy je w sali zarządu, gdzie Steve mógł przyjść i obejrzeć je, kiedy miał czas. Kiedy przyszedł czas, aby Steve porównał jakość naszego prototypu z istniejącym zewnętrznym iSightem, Steve zaczął zadawać mi bardzo szczegółowe i konkretne pytania techniczne. Miałem odpowiedzi, ale on kopał coraz głębiej, aż zapytał o różnicę między charakterystyką zbierania światła przez CCD i CMOS. Nie takich pytań można spodziewać się od dyrektora generalnego dużej firmy. Steve brał udział we WSZYSTKIM w Apple, od marketingu po inżynierię.”

Członkowie zespołu muszą czuć, że mają oparcie merytoryczne w swoim liderze, że jego wizja wypływa z głębokiej wiedzy o elektronice, fizyce, chemii, mechanice itd. 

Alexander Bell pracował samodzielnie nad technologią a później działającym prototypem telefonu. Pierwszą rozmowę telefoniczną o treści “Watson, chodź tutaj, chce się z tobą zobaczyć” wykonał samodzielnie do swojego asystenta, który przebywał na innym piętrze budynku. Był biznesmenem, negocjował z inwestorami, kupcami, ale i technologiem.

Joseph Wilson, założyciel Xerox, delegował skutecznie decyzyjność na swoich ludzi, ale autorzy książki na jego temat podkreślają, że doskonale orientował się w technologii kserokopiowania.

Akio Morita oraz Masaru Ibuka przed Sony założyli warsztaty naprawiające radioodbiorniki. Ibuka kierował bezpośrednio badaniami nad kolorowym telewizorem Trinitron, Morita brał udział w projektowaniu pierwszego tranzystorowego odbiornika radiowego mieszczącego się w kieszeni. Obaj byli zapalonymi inżynierami i tworzyli wiele technicznych rozwiązań. Morita w swojej książce stwierdził wprost o swoim wspólniku: “Mieliśmy szczęście, że mieliśmy geniusza takiego jak Ibuka, który potrafił całkowicie skoncentrować się na innowacyjnym projektowaniu i produkcji produktów”.

Sergey Brin i Larry Page samodzielnie stworzyli pierwszą wersję wyszukiwarki zwaną BackRub i czuwali nad jej dalszym rozwojem, gdy Google stawał się korporacją. Page w roli CEO posunął się nawet do zwolnienia kierowników projektów, stwierdzając, że nie lubi, gdy nie inżynierowie nadzorują inżynierów, bo mają ograniczoną wiedzę technologiczną. Uczciwie dodam, że zwolnienie kierowników projektów doprowadziło do problemów związanych z właściwą alokacją ludzi, koordynacją zadań i blokadami organizacyjnymi. Google z powrotem zaczął zatrudniać na to stanowisko, gdy prezesem został Eric Schmidt.

Ciekawe jest jeszcze to, że w tym samym roku 1996, kiedy Brin i Page zaczęli tworzyć swój algorytm indeksowania stron PageRank, inny student Yanhong Li zaczął tworzyć swój o nazwie RankDex. Jego idea była podobna, lecz biznesowo nie poszło mu tak dobrze, jak założycielom Google i po kilku latach wrócił do rodzinnych Chin. Tam jednak założył dzisiejszego giganta i konkurenta Google, czyli Baidu. Kolejny ekspert technologiczny w roli lidera olbrzymiej organizacji.

Przy czym lider nie musi być najwyższej klasy ekspertem w danej technologii. Musi umieć zadawać właściwe pytania schodzące do bardzo niskiego poziomu oraz potrafić łączyć pozornie odległe wątki ze sobą. Niektórzy nazywają to myśleniem systemowym.Opowiadana jest słynna historia medalu za nieposłuszeństwo wręczonego przez Packarda inżynierowi, który wbrew zajmował się projektowanie prototypu wyświetlacza komputerowego. FAA (Federal Aviation Administration) poszukiwała wyświetlacza dla wież kontroli lotów, który pokazywałby samoloty znajdujące się wokół lotniska. HP niechętnie podeszło do tego projektu. Wczesne testy nie rokowały dobrze i David Packard nakazał skasowanie tego projektu. Przez rok ów inżynier rozwiał prototyp dokonując równocześnie jego miniaturyzacji. Regularnie też demonstrował go klientom. Kiedy po roku Packard zorientował się, że prace nad monitorem dalej trwają, zirytował się i oznajmił: Sądziłem, że nakazałem ubić tą rzecz. Na co ów inżynier odparł – Nie, mówiłeś, że nie chcesz tego więcej widzieć w laboratorium. No i, nie zobaczysz. Jest na produkcji.” Nie muszę dodawać, że monitor okazał się gigantycznym sukcesem dla HP. Kilkanaście lat później Packard wręczył owemu inżynierowi medal za nieposłuszeństwo w uznaniu jego niezależnego myślenia i uporu.

Z tą samą intencją wspierania niezależności myślenia pracowników William L. McKnight wprowadził w 1948 roku w 3M regułę 15%, mówiącą o tym, że 15% czasu pracownik może poświęcać na własne projekty.

Nie mogę jednak nie wspomnieć o problemie, który znajduje się na drugim końcu osi nieposłuszeństwa, o projektach podwodnych. Pewna firma dostarczająca urządzenia z obszaru inteligentnych budynków zatrudniała dziesiątki inżynierów, zaangażowanych i mądrych ludzi. Z uwagi na przejęcie przez większego gracza zarząd został odwołany, a nie został powołany nowy. Ci inżynierowie specjalizujący się w projektach hardware i software jak już wspomniałem byli zmotywowani, więc nie chcieli się nudzić w czasie, gdy nie został wskazany nowy kierunek strategiczny. Zaczęli więc sami planować i realizować projekty według własnego widzimisię. Teoretycznie projekty były zgodne z technologią firmy, ale nie były uzgodnione na poziomie strategicznym. Aby uniknąć zablokowania, pilnowali, aby projekty nie przekroczyły pewnej kwoty i przemknęły pod radarem audytu finansowego. Tak narodził się termin “projekty podwodne”, czyli projekty organizowane oddolnie, bez wiedzy przełożonych. Inżynierowie dostali do zabawy piaskownicę z najdroższymi i najnowocześniejszymi zabawkami, w dodatku zabawę nimi mogli sobie wpisać do CV. Sytuacja trwała kilka lat aż nowy zarząd przejął kontrolę nad podwodnymi projektami.

Gordon Moore najpierw był inżynierem w Shockley Semiconductors, gdzie opracowywał proces oczyszczania krzemu, następnie razem ze zdradziecką ósemką uciekł od Williama Shockleya do Fairchild Semiconductors, gdzie został dyrektorem badań i rozwoju, aby wreszcie rozpocząć własną działalność w Intelu. Brał bezpośredni udział w projektowaniu układów zintegrowanych i procesorów. W swoim artykule Learning The Silicon Valley Way podsumował to zdaniem, że naukowcy musieli nauczyć się, jak zostać menedżerami. “Menedżerowie technologiczni muszą przede wszystkim być naukowcami z głębokim zrozumieniem tematu. Jednak wymagania firmy oznaczają, że poziom ogólności typowy dla laboratorium uniwersyteckiego jest zdecydowanie zbyt nieefektywna. Ci technologowie-menedżerowie muszą być w stanie wytyczyć najkrótszą drogę do wykonalnego odkrycia.”

William Gates był programistą, zaczął programować, kiedy miał 13 lat. Wspólnie z Paulem Allenem napisał interpreter języka BASIC dla komputera Altair 8080. Przez wiele lat rozwoju Microsoftu był zaangażowany bezpośrednio w kodowanie.

Elon Musk znany jest ze swojego zaangażowania w detale techniczne opracowywanych rozwiązań. Mimo braku formalnego wykształcenia uplasował się jako głównego technologa i projektanta statków kosmicznych w Spacex. W wywiadzie stwierdził, że “przeczytałem wiele książek, rozmawiałem z wieloma ekspertami i mam świetny zespół”.

Okresowe mikrozarządzanie

Warto delegować, warto zostawiać ludziom swobodę i decyzyjność. Mam nadzieję, że przekonałem cię lektura poprzednich rozdziałów, że autonomia wpływa na motywację wewnętrzną, a ta z kolei ma pozytywny efekt na kreatywność i innowacyjność. Założyciele HP, 3M czy Intela podkreślali wagę oddawania władzy i zaufania pracownikom. Powszechny jest pogląd, że nie da się utrzymać kompetentnych i kreatywnych ludzi bez delegowania decyzyjności. 

Jednak analiza zachowań znanych liderów technologicznych nie jest tak jednoznaczna w tej kwestii i pokazuje jeszcze jedno zjawisko. Otóż wielu liderów z wymienionej listy ewidentnie, choć okazjonalnie angażowało się w mikrozarządzanie. Słynne są wspomnienia, jak to Elon Musk schodził na linię produkcyjną i ingerował w procesy technologiczne, albo Thomas Edison sam przeprowadzał eksperymenty z prądnicami. Wyobraźcie sobie taką sytuację, prezes wielkiej korporacji, nazwijmy ja Apple, osobiście dobiera krój czcionki w systemie operacyjnym i układa teksty na plakatach reklamowych, a to właśnie robił Steve Jobs.

To mikrozarządzanie ma jedna specyfikę okresową. To znaczy lider, wyczuwając, że zbliża się moment zwrotny, schodzi do poziomu operacyjnego, chce lepiej poznać naturę problemu i gdy upewni się, że wszystko gra, albo odwrotnie, że pojawił się konflikt i należy dokonać zwrotu, wycofuje się na wyższy poziom zarządzania.  

Pewnego razu David Packard, gdy zorientował się, że tłumik akustyczny nie przechodzi testów bezpośrednio się w nie zaangażował i sprawdzał wyniki wspólnie z inżynierami. Z drugiej strony w wielu miejscach spotkał refleksję, że w HP kładziono dużą presję na delegowanie uprawnień w dół. Chodziło o budowanie samodzielności i odwagi w podejmowaniu śmiałych inicjatyw.

Thomas Edison w trakcie poszukiwania właściwego włókna do żarówki sam testował wiele materiałów od tkanin, przez papier, po różne gatunki traw i drzew. Cel był prosty zwiększyć czas żarzenia do wielu dni, aby żarówka stała się komercyjnym produktem, na którym można zarobić. Edison pracował bezpośrednio w swoim warsztacie, przeprowadzał eksperymenty. Wręcz słynne stały się jego drzemki na stole warsztatów, bo jak sam stwierdzał lepiej mu się śpi na twardym i szybciej może wrócić do pracy.

Joseph Wilson znany był z tego, że zbierał tony informacji, aby szczegółowo zrozumieć zalety i wady różnych alternatyw, ale potem sam podejmował decyzje. Czasem były to decyzje na bardzo niskim poziomie szczegółowości. Jednocześnie współcześni mu podkreślają, że dla wszystkich było jasne, że sam też bierze odpowiedzialność za nie w razie porażki. “Nie był technologie, ale potrafił zainspirować ludzi, którzy byli i trzymać ich przy sobie przez wiele, wiele lat ograniczonych i raczej zniechęcających rezultatów” – Linowitz prezes Xeroxa. Jednak muszę też podkreślić, że znany był ze swojej umiejętności delegowania i niewchodzenia w szczegóły, gdy tego sytuacja nie wymagała.

Ibuka i Morita z Sony potrafili zejść na poziom uzgadniania szczegółowy kampanii reklamowej walkmana, technicznych aspektów radia kieszonkowego, tłumaczenia kontraktów z angielskiego, czy zmiany sposobu prowadzenia księgowości w firmie.

Wraz ze wzrostem organizacji niemożliwe jest, aby lider był zaangażowany we wszystkie działania, bo wtedy stałby się wąskim gardłem blokującym rozwój firmy. Wtedy najważniejsze jest, by lider potrafił wybrać obszary strategiczne lub momenty zwrotne w obszarach niestrategicznych i wtedy punktowo schodził na poziom operacyjny. Czasem jest w projekcie X, a czasem w Y, a czasem w Z.

Gates znany był z tego, że często angażował się w projekty na poziomie operacyjnym. “Mógł przesiedzieć czternaście godzin na spotkaniach, podczas których jeden zespół za drugim pojawiał się, poruszając tematy tak odmienne, jak systemy operacyjne, aplikacje zwiększające produktywność, internet, inteligentne zegarki, gry wideo, badania, poczta elektroniczna, bazy danych, przeglądarki. Z najlepszymi z nich potrafił zagłębiać się w szczegóły.” Fathi.

Jeden z moich rozmówców wspomniał, jak w Virgin Galactic zdarzało się Richardowi Bransonowi wędrować po piętrach i zagadywać poszczególnych pracowników, których napotykał. Nie było też rzadkością, że założyciel firm spod nazwy Virgin włączał się na różnych spotkaniach i omawiał szczegóły projektów z zespołami.

Jensen Huang, założyciel Nvidia, deklaruje, że codziennie otrzymuje i czyta 100 e-maili od pracowników na temat tego, co dzieje się w ich projektach i otoczeniu. E-maile zawierają informacje o pięciu najważniejszych rzeczach, które przydarzyły się pracownikowi. Z resztą Nvidia ma płaską strukturę i prezes jest w bliskim kontakcie dyrektorami, specjalistami, czy absolwentami uczelni, którzy pojawiają się w firmie. Aby skrócić kanały komunikacji bezpośrednio pod nim ulokowano aż 50 menedżerów. 

Bezpośredni styl komunikacji Elona Muska, pomijający struktury organizacyjne, jest powszechnie podkreślany przez dziennikarzy i współpracowników. Wręcz zachęca swoich ludzi do tego, aby wychodzili ze spotkań, z których nic nie wynoszą, ani nic nie wniosą. Zamiast tego lepiej jest pogadać w cztery oczy na korytarzu.

Łatwość schodzenia na niski poziom struktur organizacyjnych dopełniał fakt, że ci liderzy w większości byli technologami, albo co najmniej mieli łatwość wchodzenia w technologie.

Powyższe zjawiska zatem charakteryzuje się zmienną wysokością, na której szybuje lider. Czasem obserwuje rynek i swoją organizację z poziomu strategicznego, by nagle zanurkować w trawę i przyjrzeć się pojedynczej inicjatywie lub technicznemu problemowi. Moment później jednak z powrotem wzbija się na pułap przynależny zarządowi dużej korporacji.

Minusem takiej praktyki jest to, że drobnych spraw w dużej organizacji są miriady i gdyby wszystko miało wymagać zaangażowania lidera, to stałby się potwornie wąskich gardłem dla procesów decyzyjnych. Plusem natomiast jest wykazywanie swoich podwładnych zainteresowania i wchodzenie z nim w interakcje, a to, jak już przedstawiono w poprzednim rozdziale wzmacnia pozytywną więź (słowo kluczowe LMX – leader – member exchange).

Determinacja i ciekawość

Lider daje osobisty przykład ponadnormatywnego, wręcz nieludzkiego zaangażowania w pracę. Gates znany był z tego, że sypiał pod biurkiem i natychmiast wracał do pracy. Edison sypiał na stołach warsztatowych, a jego obiady o północy organizowane dla pracowników przeszły do historii, Jobs potrafił podobno pracować przez kilka dni z rzędu bez przerwy.

Taka postawa dawał dużą dynamikę prac przy opracowywaniu technologii i prototypów. Ale oferowała jeszcze jedną korzyść, osobisty przykład dla zespołu. To było świadome lub nie narzędzie motywacji. Ludzie Edisona lubili spędzać czas z szefem w laboratorium, według wspomnień po tym wielkim wynalazcy, czuli się częścią czegoś wyjątkowego. Często zdarzało się, że wychodzili z pracy o piątej rano.

Słynna jest historia, gdy jedna z pracownic Microsoft znalazła Billa Gatesa pod swoim biurkiem. Założyciel korporacji został w pracy i zdrzemnął się zamiast wracać do domu.

W książce Joe Wilson and the Creation of Xerox podkreśla się rolę głównego bohatera w długoterminowym podtrzymywaniu zaangażowania w zespole. Po drodze do stworzenia działające komercyjnie kserokopiarki było wiele zakrętów, które trzeba było przebyć i ścian, które trzeba było przebić. I zespół wielokrotnie miał szansę zarzucić prace, gdy napotykał kolejna przeszkodę. Ale wtedy pojawiał się lider, który śmiałą wizją i konsekwentnym wsparciem nie pozwalał, aby zespół zwątpił w sukces. Z drugiej strony w wieku 43 lat miał atak serca z powodu nadmiernego obciążenia pracą.

Gordon Moore ukuł w 1965 roku jedno z najbardziej trwałych a jednocześnie precyzyjnych praw współczesnego okresu ludzkości. Zauważył on, że liczba tranzystorów umieszczanych na płytkach podwajała się co roku, że postęp technologiczny był geometrycznie stały. Gdy trzy lata później założył wspólnie z Robertem Noycem Intela na tym prawie oparł strategię marketingową firmy. Otóż produkcja chipów była droga, za droga w ich wyobrażeniu dla przeciętnej korporacji, jednak podążając za prawem Moore’a nie tylko liczba ich rosła, ale i koszt produkcji spadał. W związku z tym postanowiono sprzedawać chipy poniżej początkowych kosztów, wierząc, że wraz ze wzrostem skali sprzedaży oraz redukcją kosztów jednostkowych, staną się rentowne. Dzięki temu zabiegowi nie zahamowali rozwijającego się rynku na procesory zaporowymi stawkami. Prawo Moore’a jest spełniane przez kolejne generacje procesorów od ponad 50 lat i zdeterminowało rozwój Intela na pół wieku przez stałe zapewnianie inwestycji w badania i rozwój firmy, ciągłą optymalizację procesów produkcyjnych.

“Bill Gates i Paul Allen wykazywali się intelektualną ciekawością i eksperymentowaniem, biorąc udział w maratonach kodowania. Pracowali po dwanaście godzin lub dłużej, często pozostając w budynku przez trzy do czterech dni z rzędu.” za W. Isaacson Innovators.

Gdy został założony Intel, zdecydowano nie organizować osobnego laboratorium badawczo-rozwojowego. Zamiast tego laboratorium zlokalizowano bezpośrednio przy linii produkcyjnej, aby skrócić dystans między naukowcami a pracownikami. Jak przyznaje sam Moore, to mogło negatywnie wpłynąć na efektywność produkcji, ale znacząco przyspieszyło transfer innowacji.

Wysokie wymagania i globalna wizja

Gdy Edison odkrył, że najlepszym materiałem na żarnik żarówki jest zwęglony bambus określonego gatunku. Po pierwsze wysłał człowieka do Japonii, aby ten zebrał wszystkie gatunki bambusów oraz aby podpisał kontrakt z rolnikiem, który miał uprawiać wybrany gatunek na potrzeby produkcji żarówek. Ale oprócz tego, Edison wysłał innych swoich ludzi w podróże po całym świecie w celu znalezienia jeszcze lepszego żarnika. Testowane wszelakie drzewa, trawy i materiały nieorganiczne. Cel był jeden, wydłużyć świecenie ich produktu o kolejnych kilka dni. Jednak Edison nie projektował wyłącznie żarówki. On tworzył cały system dostarczania energii, aby oświetlić domy, biura i fabryki. W jego skład wchodziły linie energetyczne, oprzyrządowanie, generatory prądy. Edison chciał oświetlić Amerykę.

Sony od samego początku, kiedy jeszcze było warsztatem zatrudniającym kilku inżynierów i ich pierwszy hit, radio tranzystorowe było mglistą koncepcją, już myślało o ekspansji na całą Japonię a potem świat.

Wyszukałem opinie byłych pracowników o AMD i wszystkie głosy powtarzają jeden wniosek atmosfera była świetna, ale z wysoką presją na wynik. W efekcie to owocowało wysoką krzywą uczenia się.

Jensen Huang wprost deklaruje w jednym z wywiadów, że nie tworzy dalekosiężnych planów, bo firma jest jak żywy organizm, oddycha, reaguje na otoczenie i ciągle się zmienia. Wartością jest elastyczność i podążanie z aktualnie najciekawszym kierunkiem. W innym z wywiadów potwierdził, ze krąży o nim opinia, że jest wymagającym perfekcjonistą, z którym trudno jest pracować. Dodał też, że nie da się inaczej tworzyć trudnych rzeczy.

Prawo Moore, dotyczące dynamiki miniaturyzacji tranzystorów na obwodzie drukowanym obowiązuje nieprzerwanie od pół wieku nie dlatego, że jest boskie w swej naturze, a dlatego, że tysiące inżynierów w Intel i innych firmach z branży co roku przesuwają granice poznania.

Podsumowując, ciężko jest nie zauważyć, że wszyscy analizowani liderzy zachowywali się zgodnie ze stylem transformacyjnym. 

Słynne są bezpośrednie e-maile od Elona Muska do wybranych pracowników, w których wywiera presję często używając zwrotów ultra hard core, extreme hard core, absolutely hard core itp. Presja na wynik dochodzi w jego przypadku do wypychania z zespołów słabszych pracowników i czasem nawet masowych zwolnień, jak w przypadku momentu przejęcia Twittera, gdy zwolniono 80% pracowników. Od pozostałych oczekiwał 80 godzinnego tygodnia pracy. Jednocześnie trudno o bardziej śmiałą wizję, niż tą, która ma Spacex. Dzięki znaczącej redukcji kosztów wynoszenia na orbitę, doprowadzić do kolonizacji Marsa.

Według słów Jensena Huanga Nvidia ma wizja przyspieszenia operacji na komputerach, wszelkich działań. Od przyśpieszania grafiki w grach komputerowych, przez kopanie bitcoinów, po algorytmy AI.

Cel ponad ludzi

To nie jest powszechna reguła, że cel biznesowy stawia się ponad ludzi, ale w wielu firmach technologicznych dostrzegłem to zjawisko.

Gdy okazało się, że kieszonkowe radio Sony jest za duże do kieszeni koszuli, wówczas Akio Morita nakazał pracownikom firmy noszenie koszul z większymi kieszeniami, żeby radio dobrze prezentowało się na ulicy. 

Współpracownicy Steve’a Jobsa regularnie obawiali się natknąć na niego w windzie, aby nie narazić się na niezadowolenie szefa. Potrafił też dawać to samo zadanie dwóch zespołom i zapowiedzieć, że ten który wykona to gorzej zostanie zwolniony. “Steve (Jobs), podobnie jak Napoleon, miał dwie twarze. Z jednej strony był genialnym geniuszem i prawdziwym wyrzutkiem. Z drugiej strony – wychodził na wierzch jego brak troski i wrażliwości wobec ludzi, jego brak szacunku i dyktatorskie zachowanie” – Haden 2020.

Mam wrażenie, że gdyby tym liderom technologicznym zadać pytanie o wagę ludzi, czy celu, bez wahania wskazaliby to drugie. Z perspektywy czytelnika ich biografii to wygląda tak, jakby cel miał być na tyle wspaniałym wyzwaniem, że ludzie z radością powinni się przyłączać i poświęcać życie osobiste. Jeżeli firma odniosła spektakularny sukces, to człowiek mógł powiedzieć o sobie, że uczestniczył w czymś wielkim i warto było znosić trudnego lidera. Ale jeśli jego firma bankrutowała, jak założone przez Nikola Teslę Wardenclyffe Laboratory, to perspektywa jego była zgoła inna.

William Shockley w trakcie prac nad tranzystorem jeszcze w Bell Labs przejawiał tendencje do dominowania nad zespołem, co w połączeniu z charakterystycznym dla niego mikrozarządzaniem wprowadzało nieprzyjemną atmosferę. Jednak mimo konfliktów zespół inżynierów pod jego kierownictwem, pracując często wieczorami, osiągnął sukces i zaprojektował pierwszy tranzystor, zapoczątkowując nową erę cyfrową i zdobywając kilka lat później nagrodę Nobla.

Bill Gates znany był ze swojego szorstkiego i konfrontacyjnego stylu współpracy z ludźmi. Potrafił zapamiętywać numery rejestracyjne aut na parkingu, aby ustalić, kto jeszcze jest w pracy, o drugiej rano wysyłał e-maile zaczynające się od zdania “To najgłupszy kawałek kody, jaki kiedykolwiek został napisany”. Był też znany z wykorzystania prac ludzi, z którymi się przyjaźnił, jeżeli to dałoby korzyści Microsoftowi. Gdy IBM nie dogadał z DRI na temat zakupu ich systemu operacyjnego do nowych komputerów PC, zwrócił się do Microsoftu mylnie sądząc, że ta firma stworzyła system CP/M. Gates kupił podobny system od Seattle Computer, nadał mu nazwę MS-DOS i odsprzedał licencję IBM. Problem polegał na tym, że MS-DOS był podejrzanie podobny do CP/M, a wcześniej Gates uzgodnił z prezesem DRI, z którym się przyjaźnił, że nie będą robili sobie nawzajem konkurencji. Microsoft miał zająć sektor języków programowania, a DRE systemów operacyjnych. Atrakcyjna cena zakupu (50 000$) i wizja gigantycznych zysków od IBM zmieniają percepcję sytuacji. Z resztą sam Paul Allen, współzałożyciel Microsoftu, podobno twierdził, że praca z partnerem “była piekłem”.

Larry Ellison, założyciel Oracle, znany był z wybuchu gniewu na ludzi, które owocowało nawet godzinnymi tyradami inwektyw. Jeff Bezos z Amazon również znany jest z wybuchów wściekłości i obrażania pracowników, jak opisuje to Jeffrey Pfeffer w swojej książce.

Oczywiście znajdziemy tutaj sporo wyjątków, np. Hewlett Packard. Jak wspominają pracownicy w dokumentach filmowych o tej firmie, obaj założyciele niesłychanie dbali o relacje. Traktowali swoją organizację jak rodzinę. Packard podobno pamiętał szczegóły życia rodzinnego swoich ludzi, gdy firma miała już tysiąc zatrudnionych. HP jako jeden z pierwszych w Ameryce organizował pikniki rodzinne już niedługo po wojnie. Obaj founderzy opowiadają w wywiadach, że dla nich przede wszystkim istotne były zostawić świadectwo, wpłynąć pozytywnie na społeczeństwo. Zarabianie pieniędzy było tylko narzędziem do tego. Koniecznym, bo ludziom trzeba wypłacać pensje, bo trzeba inwestować w rozwój technologii, ale pieniądze nie były ostateczną wartością. Wyjątkiem też wydaje się tu być postawa Jerriego Sandersa, który jako jeden z pierwszych zaczął dzielić się zyskami z pracownikami i w okresach kryzysów zamiast zwalniać ludzi, wydłużał tydzień pracy, aby szybciej wypuścić nowe produkty na rynek.

Akio Morita w wywiadzie deklarował, że firmę traktuje niczym rodzinę a nie zasób, który można kupić lub sprzedać. W Sony koncentrowano się na lojalności pracowników i ich satysfakcji z pracy.

Wspomniane wcześniej losy Twittera po przejęciu przez Elona Muska podkreślają moją interpretację tej postawy, że cel jest najważniejszy, ludzie są narzędziem, koniecznym, unikalnym, ale narzędziem do jego osiągnięcia.

Uczestnictwo w rozpoznawalnym sukcesie

Na kartach tej książki dużo piszę o krytycznej roli motywacji wewnętrznej w procesach kreatywnych. Jednak w tym momencie przedstawię coś przeciwstawnego. 

Jeżeli organizacja nie odnosi sukcesu, który byłby zauważalny nie tylko dla samego zespołu, ale przede wszystkim dla otoczenia, to pojawia się ryzyko odejść.

Wyobraźmy sobie takie warunki pracy. Despotyczny, ale i genialny lider narzuca nierealne tempo prac. Siedzi w firmie po kilkanaście godzin dziennie i źle patrzy, gdy inni wychodzą wcześniej. Jest wiecznie poirytowany i niezadowolony z otrzymywanego efektu. Non stop krytykuje podwładnych, żądając więcej i lepiej. Ma obsesję na punkcie jakości, atrakcyjności produktu, zdobywania wiedzy o technologii. Wreszcie wierzy, że zna się osobiście na wszystkich niuansach technologicznych, marketingowych i biznesowych. Ingeruje regularnie wbrew ustalonym strukturom zarządzania, wręcz mikrozarządza, co może wzbudzać frustrację.

Jak podaje Jeffrey Pfeffer w książce Przywództwo Mity i Prawdy, często cechą liderów, którzy osiągnęli sukces jest ponad przeciętny poziom uwielbienia dla siebie samego, zwanego narcyzmem. Narcyzi wyrażają niepewne poglądy z dużą pewnością siebie, co może powodować, że ich podwładni mają większą skłonność do uwierzenia i podążania za nimi. A większa skłonność do podążania sprzyja determinacji i osiąganiu sukcesu za wszelką cenę.

 Wniosek – musi istnieć silny atraktor, który przeważa negatywne aspekty pracy w takiej organizacji. Jest to poczucie brania udziału w czymś wyjątkowym. Potwierdzają to wspomnienia pracowników Apple, HP, Microsoft, Menlo Park Laboratory, Tesla i innych. Ludzie nie odchodzili, siedzieli po nocach i wytrzymywali presję lidera, bo wierzyli, że stają się częścią czegoś wyjątkowego. Stoi przed nimi jedna szansa w życiu, wpiszą sobie do CV uwielbianą markę i wreszcie zmienią świat.

Z opowieści pracowników wynika, że potrafią naprawdę sporo znieść. Znalazłem pełno historii o maratonach pracy trwających po wiele dni, w trakcie których lider miotał się, wściekał, obrażał i krytykował ludzi. A ci i tak zostawali, a przynajmniej na tyle dużo z nich, żeby projekt mogły się toczyć.

Jednak nie można przegiąć. William Shockley w trakcie projektu tworzenia tranzystora dał się poznać jako fatalny menedżer. Ambitny, nerwowy, z dużym ego. W pewnym momencie popadł w konflikt z pozostałymi dwoma inżynierami, gdy ci stworzyli pierwszy prototyp, który działał, nie uprzedzając go o tym. Do tego stopnia bał się, że jego nazwisko nie znajdzie się na patencie, że chciał tamtych dwóch pozbawić prawa do bycia uznanym za autorów. Poszedł dalej, bo w swoim zapędzie opracował inną konstrukcję tranzystora, która o ironio okazała się dużo lepsza. Pierwotny tranzystor był używany tylko przez pewien czas w AT&T do przełączania rozmów jako zastępca lamp. Projekt Shockleya stał się podstawą rewolucji cyfrowej. Shockley odszedł z AT&T i założył Shockley Semiconductors w Palo Alto, dając podwaliny pod powstanie Doliny Krzemowej. Zatrudnił nowych inżynierów. Rok później ósemka z nich miała dość swojego szefa i zwolniła się by założyć Fairchild Semiconductors. Shockley nazwał ich zdrajcami, stąd ich pseudonim “zdradziecka ósemka”. Firma twórcy tranzystora po paru latach znikła z rynku, zaś Fairchild Semiconductors stało się liderem na rynku półprzewodników i dało początek takim korporacjom jak Intel i AMD.

Negatywne zachowania lidera muszą być równoważone wizją gratyfikacji, aby pracownicy pozostali i angażowali się na wyjątkowym poziomie. I ta gratyfikacja ma często wymiar zewnętrzny w postaci uznania otoczenia. Gdy Edison opracował wreszcie żarówkę, jego laboratorium stało się miejscem pielgrzymek dziennikarzy, polityków i zwykłych obywateli, który chcieli podziwiać to cudo. Były dni, gdy w Menlo Park było tak tłoczno od gości, że nie dało się pracować.

Każda premiera Apple była gigantyczną ceremonią na miarę otwarcia igrzysk olimpijskich i to dosłownie. Zliczyłem, że filmiki na Youtube z premiera iPhone 1 miały przynajmniej 100 milionów wyświetleń. Rok później miała miejsce olimpiada w Pekinie, filmy z jej otwarcia obejrzano 13 milionów razy. A teraz wyobraźcie sobie, że byliście członkiem zespołu projektu iPhone i odtąd rodzina, znajomi i przypadkowe osoby muszą słuchać, jak to ze Stevem Jobsem myliście zęby w biurowej łazience po trzech nocach w pracy. Motywacja zewnętrzna może działać jak afrodyzjak, gdy jest wsparta wyjątkowo dużą atencją otoczenia.

Podsumowując, ludzie chcą brać udział w przełomowych wydarzeniach i dużo wytrzymają, jeżeli wierzą w sukces, nawet mikrozarządzajacego, psychopatycznego despotę. Więc, jeżeli lider jest sympatycznym, charyzmatycznym, wspierającym przywódca, to motywacja jego ludzi może wzrosnąć do kwadratu.

Jednak, jeżeli zespół przez dłuższy czas nie odnosi sukcesu, gratyfikacja jest zbyt długo odkładana, to zaryzykuję stwierdzenie, że zespół straci zapał niezależnie od tego, jak sympatyczny jest lider. Charyzma nie wystarczy, gdy projekt zmierza ku klęsce. I charyzma nie jest konieczna, gdy projekt okazuje się wiktorią.

Podsumowanie

Powyższe rozważania o profilu lidera technologicznego, który skutecznie inspiruje ludzi i egzekwuje wdrażanie innowacji warto studiować z krytycznym dystansem. Po pierwsze mamy do czynienia z małą próbą. Po drugie analiza skażona jest syndromem przetrwania, zagłębialiśmy się w przypadki tylko tych, którzy odnieśli sukces. Podejrzewam, że na każdego przywódcę, któremu udało się stworzyć liczącą się na rynku organizację, przypada kilkudziesięciu takich, którzy na skutek trudnego charakteru, złego momentu wejścia na rynek, braku wsparcia finansowego, czy działań konkurencji, przegrali. O nich literatura, ani podcasty nie wspomną. Może poza takimi cmentarzyskami startupów, jak Failory (www.failory.com).

Jednak dobra kombinacja z jednej strony ekstremalnej presji na innowacje, uczenie się, eksplorację nowych kierunków, z drugiej strony bezpośrednie relacje z liderem, który potrafi natychmiast zmienić kierunek rozwoju organizacji i realokować duże środki, pomijając biurokrację korporacyjną wreszcie po trzecie osłodzenie presji i chaosu związanego z ciągłymi zmianami uczestniczeniem w rozpoznawalnym sukcesie, może zapewnić niesamowite paliwo dla motywacji.

Jeszcze jedno zastrzeżenie muszę dodać. Powyższe wnioski pasują do sytuacji, gdy organizacja uzależnia swój rozwój od ciągłych innowacji. Gdy stara się być liderem i nadawać kierunek rynkowi. W przypadku, gdy przewaga firmy wynika z innych czynników, jak na przykład niskie koszty produkcji, intensywny marketing, monopol na surowce, liderzy o innych cechach mogą okazać się wartościowi.

Cztery główne rodzaje projektów

utworzone przez Marcin Żmigrodzki

Na potrzeby rozważań prowadzonych w tej książce podzieliłem świat zarządzania projektami na cztery kategorie: kaskadowe, zwinne, optymalizacyjne i tytułowe eksploracyjne. Schematycznie ilustruje to poniższy diagram.

Rys. Rodzaje projektów.

W dalszej części tego rozdziału omówię wszystkie te kategorie, aby zarysować Ci, drogi czytelniku, szerszą perspektywę.

Artykuł jest fragmentem książki Bardziej niż Agile będącej w trakcie druku: https://onepress.pl/ksiazki/bardziej-niz-agile-marcin-zmigrodzki,baragi.htm#format/d

Ludzkość projekty realizuje od kilkunastu tysięcy lat. Od kiedy zaczęliśmy podejmować większe wyzwania wymagające koordynacji dużej grupy ludzi okazało się, że osiągamy lepsze efekty, gdy planujemy z góry nasze przedsięwzięcie. Dwanaście tysięcy lat temu Göbekli Tepe, którego wysokość sięga piętnastu metrów było konstruowane przez kilkaset lat. Stawiana osiem tysięcy lat później piramida Djosera o wysokości sześćdziesięciu dwóch metrów była budowana około trzydziestu lat. Rzymskie Koloseum zbudowane kolejne dwa i pół tysiąca lat później wznoszone było na wysokość 48 metrów przez dziewięć lat. Sześć lat zajęło zbudowanie niemal kilometrowej wysokości Burj Kalify. Pomijając oczywiste uproszczenia dotyczące złożoności tych projektów, postęp nastąpił. W dużej mierze zawdzięczamy go lepszym technologiom, ale również lepszej organizacji pracy olbrzymich zastępów specjalistów. 

Taka filozofia współpracy zakładała szczegółowe planowanie, a potem rozliczanie ludzi z wykonywania planu. Zakładała też precyzyjne rozdzielanie zadań, aby ograniczyć chaos. Jej siłą była zdolność skalowania. Sprawdzała się zarówno w małych przedsięwzięciach, jak stawiania wieży wartowniczej, jak i w gigantycznych. Machu Picchu przez 30 lat wznosiły setki ludzi od inżynierów, który wytyczali przebieg murów, tarasów i kanałów wodnych po niewolników, którzy wciągali bloki granitu szczyt góry.

Przewijając sześćset lat wprzód po Machu Picchu docieramy do epoki tworzenia standardów zarządzania projektami, z których najpopularniejszym okazał się PMBOK Guide. Wyewoluował on najpierw na bazie potrzeby realizacji dużych inwestycji powojennych i zimnowojennych w USA, a potem w całym świecie zachodu i wreszcie globu. Z początkowego sektora konstrukcyjno-budowlanego rozpropagowany został na konsulting, IT, produkcję i inne obszaru gospodarki.

Równolegle wraz ze wzrostem skali produkcji masowej oraz presją na zadowolenie klientów i redukcję kosztów produkcji, magazynowania i transportu wyłoniły się dwa podejścia Lean i Six Sigma na dwóch krańcach naszej planety. Komponentem każdego z nich z osobna stało się prowadzenie projektów optymalizacyjnych. Six Sigma nawet zaproponowała wprowadzenie całego cyklu życia projektu składającego się z pięciu etapów o nazwie DMAIC (w sumie to zaproponowała trzy cykle życia projektów, bo jeszcze mniej znane DMADV i DFSS). Zatem pojawiło się drugie podejście do prowadzenia projektu, które mówiło “weź funkcjonujący proces i uruchom na nim projekt, którego celem będzie odkrycie i wdrożenie usprawnień.” 

W duchu Lean optymalizacja miała przynieść skrócenie czasu przejścia procesu i w efekcie większą responsywność na zmiany popytu oraz oszczędności. W duchu Six Sigmy optymalizacja owocowała większą powtarzalnością procesu, mówiąc żargonowo jego stabilizacją, co też przyczyniało się do oszczędności.

Na początku XXI wieku dojrzała koncepcja mówiąca o tym, że nie cały projekt trzeba z góry planować. Wystarczy, że zespół w ponawianych cyklach będzie przybliżał się do ideału, jednocześnie odkrywając, czym ten ideał jest. 

Jakie mamy korzyści takiego podejścia? Po pierwsze na początku nie w pełni rozumiemy, jakiego efekty finalnego się spodziewamy, a po drugie ciężko precyzyjnie oszacować ile to zajmie. Zatem zamiast popełniać błędy, bo po prostu zaakceptujmy naszą niepewność. Zaufajmy, że zespół zmotywowanych specjalistów da radę. Będzie starał się z całych sił i dostarczy najlepszy możliwy rezultat. Przy takich założenia powstały metodyki zwinne. Po kolejnych dwudziestu latach widzimy, że wyścig wśród metodyk zwinnych wygrały Scrum i Kanban. Tak narodziła się trzecia gałąź metodyk projektowych, ale również całej filozofii współpracy ludzi, nazwana zwinnością.

Jednak tempo przemian na świecie narasta. Modny stał się termin VUCA od ang. volatility, uncertainty, complexity and ambiguity, czyli zmienność, niepewność, złożoność i niejednoznaczność.

Jak się okazało po dwóch dekadach praktycznych doświadczeń, Scrum, czy Kanban dedykowane są do mniejszych zespołów, które z grubsza znają wizję końca, natomiast szczegóły wymagań oraz sposób ich realizacji może być doprecyzowywany w trakcie realizacji. 

Rosnąca zmienność powoduje, że coraz częściej konieczne jest gwałtowne modyfikowanie kierunku projektu, albo oznacza wręcz, że nie wiadomo, gdzie zespół ma dotrzeć, tylko w trakcie to musi ujawnić.

I tu na wściekłym strusiu wpada czwarty jeździec, projekt eksploracyjny. Projekt, który zaczyna się w mgle chaosu (fuzzy frontend) i często w nim kończy, ale którego główną wartością jest nabranie kompetencji jak ujeżdżać ów chaos. W takich projektach porażka jest często powodem do dumy. 

Argument za narastającą potrzebą wyjścia poza zwinność daje raport Gartnera o tytule Hype Cycle for Enterprise Architecture 2021 i 2022. Otóż pojawiają się tam takie zagadnienia, jak Agile poza IT, zwinne zarządzanie projektem, architektura zwinna i wszystkie one znajdują się na odcinku rosnącego rozczarowania. W innym raporcie Gartnera o tytule Agile and DevOps dotyczącym koncepcji zarządczych w IT w 2020 roku pojawiła się koncepcja Hypothesis Driven Development, ale 2022 została włączona do koncepcji Feature Management.

Projekt eksploracyjny definiowany jest w artykułach naukowych, jako projekt, w którym niejasny jest cel oraz sposób jego realizacji. Warto zauważyć, że sam termin eksploracyjnych projektów nie pojawia się w ogóle w raporcie. 

Nazwa eksploracyjny została wybrana subiektywnie. W świecie projektów bardziej niepewnych niż zwinne i kaskadowe pojawia się wiele terminów. Inne znane terminy to badawczo-rozwojowe, resilience management (zarządzanie odpornością), ekstremalne, eksperymentalne, hypothesis driven development, model spiralny zarządzania projektami. Dla uniknięcia nieporozumień dalej będę używał tylko jednej nazwy – eksploracyjne na oznaczenie ich wszystkich. Projekt eksploracyjny charakteryzuje się tym, że ma nieprecyzyjne cele, niekompletny zakres oraz nie da się zidentyfikować wszystkich ryzyk. Generalnie w takim projekcie niewiele wiemy i musimy zabrać się za odkrywanie.

Tu warto nadmienić, że jedną z powracających cech takich projektów jest zarządzanie niepewnością a nie ryzykiem. Różnica polega na tym, że ryzyka da się zmierzyć, a niepewność z powodu braku wiedzy pozostaje niemierzalna. Jest to też jeden z pierwszych wniosków z wywiadów, które przeprowadziłem, przygotowując się do tej książki. Za wyjątkiem dwóch osób, które częściowo odpowiedziały twierdząco, ponad pięćdziesięciu moich rozmówców odparło, że nie stosuje ilościowych metod zarządzania ryzykiem w swoich projektach eksploracyjnych. Jeszcze raz powtórzę, bo to musi wybrzmieć. Ponad 90% praktyków skrajnie niepewnych projektów nie zarządza ryzykiem w sposób bardziej zaawansowany. 

Przygotowując się do pierwszych wywiadów zakładałem, że moi rozmówcy potwierdzą mi, że zarządzanie ryzykiem jest ważne i stosują je na co dzień. Stało się dokładnie odwrotnie.

Zacząłem drążyć, jakie są powody takiego stanu rzeczy i głównym uzasadnieniem okazało się to, że po prostu w trakcie eksploracji nie posiadamy danych. Ryzykiem za pomocą narzędzi statystycznych można zarządzać tylko wtedy, gdy dysponujemy próbą z wcześniejszych podobnych sytuacji. W tym wypadku wkraczamy na nieznany ląd. Próba bardzo często składa się z jednego elementu i właśnie w tej chwili jest on badany. Jeden z końcowych rozdziałów książki poświęcam właśnie aspektom, których wciąż brakuje w praktykach prowadzenia projektów eksploracyjnych.

Kolejny rodzaj projektów, który warto wymienić to projekty optymalizacyjne. Są to przedsięwzięcia, które uruchamiane są w obszarze istniejącego już procesu i ich zadaniem jest jego poprawa. Przykładami takich projektów są Six Sigma i Lean. W takich projektach zakres w rozumieniu zbioru zadań jest na początku nieznany, bowiem trzeba odkryć, co wymaga naprawy w procesie. Natomiast znany jest zakres w rozumieniu miejsca, gdzie będzie dokonywana poprawa. Przykładowo może to być gniazdo produkcyjne, fragment procesu obiegu dokumentów, wybrany dział. Na wejściu znajduje się proces na wyjściu proces, który działa szybciej, taniej, mniej awaryjnie, bardziej powtarzalnie, dając większą satysfakcję klientom.

Na ogół efektem projektów optymalizacyjnych są nie rewolucyjne zmiany w istniejących procesach, raczej usprawnienia niż totalne przemodelowanie wybranych obszarów organizacji.

Skalowanie zwinności

utworzone przez Marcin Żmigrodzki

Obok budowania motywacji wewnętrznej, skalowanie zwinnych projektów na całą organizację jest moim zdaniem Graalem, którego poszukują zarządy.

Tak, jak warto mieć zaangażowanych ludzi, którym chce się podważać status quo i wdrażać innowacje, to duże organizacje chciałyby sklonować ideę małego zwinnego projektu na całość firmy.

Przez nasz kraj, podobnie, jak przez całą zachodnią gospodarkę przelała się fala transformacji zwinnych. Dotknęła ona szczególnie sektor finansowy i telekomunikacyjny, czyli wszędzie tam, gdzie wymagana jest wysoka innowacyjność oraz większość projektów zależy od zmian w głównych systemach informatycznych. Co ciekawe ta fala transformacji agile nie dotknęła sektora produkcji, ani usług publicznych. Jednak tam, gdzie pojawiła się, pozostawiła ślad. W poniższym tekście zbiorę moje refleksje na temat tego, jak mogłaby a jak wygląda taka transformacja.

Kontrola vs. zwinność

Duże organizacje potrzebują kontroli i struktur. Struktur organizacyjnych: działów, pionów, sekcji, bo człowiek ma ograniczoną rozpiętość kierowania i komunikacji, struktur zakresu: WBS, epic/feature/story/task, bo długie listy zadań mają tendencję do zaśmiecania się, struktur kosztów: budżety działowe, projektowe, zadaniowe, bo tak jak łatwiej rozliczać i kontrolować wydatki, struktury czasu: plany strategiczne, mapy drogowe, kamienie milowe, daty wypuszczeń, Gantty, wersje, bo podobnie jak przy kosztach tak łatwiej jest kontrolować rzeczywistość.

Natomiast pojedynczy zespół dobrze, aby pozostawał zwinny, ze zbiorową odpowiedzialnością, płaską strukturą, krótką listą zadań, planem na najbliższy sprint i nie zwracaniem uwagi na budżet.

Według metodyk skalujących agile gdzieś po drodze powinna zajść transformacja z klasycznego zarządzania i waterfall na agile. I jeszcze powinna ona być niezauważona dla zespołów, aby nie psuć zaangażowania. Na górze mamy plany bazowe, procenty realizacji KPI, odchylenia od terminów mapy drogowej, a na dole autonomię i swobodę.

Toteż dochodzi do wypaczeń. Przykładowo wg SAFE nadal wyceniajmy zadania w storypointach, ale cichaczem umówmy się, że 1 storypoint = 1 dzień i porównujmy produktywność między zespołami oraz wprowadźmy analizę odchyleń.

To magiczne przejście od agile do waterfall zachodzi przez stopniowe dokładanie kolejnych wskaźników kontrolnych. To tak jakby gotować żabę, jak będziemy robili to powoli, to może nie zorientuje się, że już nie jest taka zwinna. Drugi sposób na przejście to zrzucenie odpowiedzialności na kierowników projektów. Od góry można ich rozliczać z celów i planów bazowych, a od dołu zmusić do współpracy z niezależnymi zespołami. Piszę to z dużą ironią, bo oba sposoby na przejście od agile do waterfall często generują serie konfliktów.

Ciekawy przykładem kontroli na górze a zwinności na dole jest model spiralny Barry’ego Boehma stosowany w DARPA. Projekt w nim przechodzi przez cykle inicjacji, produkcji i walidacji, które pozwalają na utrzymanie kontroli inwestycyjnej, ale na dole, na poziomie zespołu może być tak zwinny, jak tylko chce.

Jeden ze znajomych, poddany transformacji agile, przytoczył mi ciekawy argument. Na ogólne narzekanie na bałagan powstały po transformacji zapytałem go, a gdzie to dobrze działa. Odparł, że tam, gdzie jest dobry product owner z biznesu, który wie czego chce, rozumie naturę technologii i ma na wyłączność zwinny zespół technologów. Podoba mi się ten argument. Aby transformacja agile powiodła się musimy mieć wielu product ownerów o wysokich kompetencjach biznesowych i elementarnych technicznych, którzy wiedzą czego chcą i mają na wyłączność swoje zespoły. Wraca nam idea lidera transformacyjnego, ale w wydaniu nie dyrektora a product ownera.

Problemem tylko jest fakt, że zespoły częstokroć nie są dostępne na wyłączność. Ludzie migrują, zespoły migrują i generalnie mamy dużą macierzowość. Podejście kaskadowe za pomocą szczegółowego planowania radzi sobie z tym wyzwaniem, natomiast agile ma tu problem i ludzie często wpadają w multitasking.

Motywacja do innowacji

Dlaczego organizacje potrzebują przejścia od kontroli do zwinności na poziomie pojedynczego zespołu. Powodów jest kilka: moda, argumenty rekrutacyjne dla nowych kandydatów („my nie jesteśmy złą korporacją, żółty ptak z ulicy Sezamkowej też był wielki a jaki sympatyczny”). I wreszcie mamy najważniejszy argument, tj. pozostawienie autonomii, bo ta buduje motywację wewnętrzną, zaś motywacja wewnętrzna jest silnie skorelowana z innowacyjnością.

To nie jest niewykonalne. Mimo skomplikowanych metodyk można nie niszczyć zaangażowania. Wszystko zależy od stylu, tak stylu, który każe powstrzymywać się od przesadnej ingerencji i wysłuchać maluczkich, bowiem w nich tkwi potencjał.

Pozytywny wniosek jest taki, że styl zachowania się lidera, niezależnie od przyjętego frameworku pozwala zachować poczucie autonomii w zespole. Chodzi o to, aby ludzie rozumieli uzasadnienie decyzji i mogli wywrzeć na nią wpływ.

Inżynieria oprogramowania

SAFE fajnie uwzględnił to, że oprogramowanie buduje się w specyficzny sposób, inaczej niż domy, inaczej niż nowe produkty AGD i inaczej niż kampanie marketingowe dla przykładu. Znajdziemy tu architektury, infrastruktury, wydania, stabilizację jakości, specyficzne role, jak analitycy, programiści i testerzy. I moim zdaniem dobry framework powinien uwzględniać specyfikę produkcji w danym sektorze.

Stosowanie sztywnych wydań, gdy sednem projektów jest tworzenie hardware’ów i logistyka komponentów nie działa tak, jak pisanie kodu, nie ma sensu. A z takiej założenia wychodzi Scrum for Hardware, co z resztą było gwoździem do jego trumny.

Dzielenie się wiedzą

Innowacje potrzebują kilku rzeczy, wybrane z nich, które akurat sobie przypomniałem to: zasoby, autonomia, presja na kreatywność oraz wiedza. Bez wiedzy odkrywamy koło na nowo i rzucamy infantylne pomysły.

Zwinność niestety może powodować zamykanie się zespołów w swoich bąblach poznawczych. Owszem w Scrumie regularnie dochodzi do dzielenia się wiedzą: na standupach, w ciągu dnia na kawie, na Slacku, czy na retrospektywie, ale ten oddziaływanie jest ograniczone do zespołu. Wiedza nie paruje na całą organizację tak, jakby mogła.

Spotify proponuje odpowiedź na to w postaci idei gildii, SAFe wspólnoty praktyków, DAD proponuje wszystko, co się da, więc pewnie też coś na dzielenie się wiedzą. Jednak bariery siedzą w mentalności ludzi a nie w technikach. Ja muszę nie bać się zadać pytania, ja muszę być krytyczny wobec siebie, aby wiedzieć, kiedy stanąłem pod ścianą i dopiero wówczas poproszę o pomoc. Z drugiej strony mój światły kolega musi mieć czas na udzielenie mi pomocy. Tego nie zbuduje się technikami, tylko budowaniem motywacji oraz świadomości.

Wdrażanie

I tu dochodzimy do szalenie ważnego aspektu, który bywa pomijany przez takich gigantów zarządzania, jak IPMA, PMI, IIBA, natomiast całkiem ładnie obsłużył go SAFE. W jaki sposób wdrożyć daną metodykę? PMBOK Guide ma z dodatkami około 1000 stron, a wdrażaniu metodyki na nim opartej poświęcono może z dwie. Nie da się wziąć encyklopedii i jej zainstalować w organizacji, a o tym zapomnieli twórcy DAD.

Potrzebne jest opracowanie drogi wdrażania skali w agile, a niekoniecznie konkretnego frameworku. Z resztą sam Spotify oznajmił ustami jednego z technologów, że model nazwany imieniem firmy już dawno wygląda inaczej. Nie ma właściwie modelu Spotify, jest kultura organizacyjna, która prowokuje do ciągłej ewolucji w imię autonomii zespołów i skoordynowanego rozwoju strategicznego.

Warto wspomnieć, że tą rolę, przewodnika po drodze ku transformacji, starają się też wypełnić konsultanci oraz wewnętrzni liderzy zmian.

To, co ostatecznie przebije się po dzisiejszym kryzysie transformacji agile, to podejście indywidualne. Organizacje raczej będą konstruowały własne frameworki, nazywając je jedynie za pomocą znanych terminów jak SAFE czy Spotify. Zwinność jest raczej drogą niż celem. Takie podejście sprawdziło się w lean i waterfallu. Do doskonałości można dążyć, podejmując dziesiątki racjonalnych decyzji i wybierając własną ścieżkę. Ale doskonałości nigdy nie osiągniemy.

Organizacje krok po kroczku powinny wskazywać priorytety w uzwinnianiu i utrzymywaniu kontroli. Tutaj wyraźnie widoczna jest cykliczność, na przemian zarząd uelastycznia zespoły, dając im autonomię i usztywnia przywracając kontrolę. Wszystko po to, aby znaleźć właściwy balans.

Z każdą taką pętlą uzwinniania/usztywniania wdrażane są kolejne techniki i metody pracy. A to retrospektywa, a to zakres opisany od strategii do zadania, a to sprinty, a regulowane release’y, a to samoorganizujące się zespoły, a to monitorowanie pracy, aby wyłapać wąskie gardła. Nie ma jednej drogi. Jest odkrywani, co organizacji pasuje najlepiej w danej chwili, a co trzeba zmienić.

Dla uczciwości dodam, że DAD przywołuje koncepcję Choose Your WOW, czyli wybierz swój sposób pracy. Ale robi to na tak ogólnym poziomie i zasypuje tak dużą ilością technik od sasa do lasa, że DAD staje się niestrawny.

Podsumowanie

W tytule artykułu przytoczyłem wykres popularności wyszukiwania Google Trends dla SAFe i kilku innych frameworków/metodyk. Jak widać trakcję uzyskały dwa, a jej skalę widać w porównaniu do na przykład PMI DAD – Disciplined Agile Delivery – to ta czerwona niewidoczna linia na wykresie.

Dlaczego akurat SAFE i Spotify się przebiły? Mam dwa argumenty: właściwy czas, łatwość wdrażania, adresowanie właściwych problemów. Oba modele pojawiły się dość wcześnie, gdy zainteresowanie skalowaniem dopiero narastało. DAD dołączył dużo później, co IMHO wykluczyło go z rywalizacji. Oba modele też adresują istotne potrzeby. SAFE streściłbym do potrzeby przez zarząd kontroli wśród wielu „zwinnych” projektów. Celowo słowo „zwinny” oprawiłem w cudzysłów, bo często przy wdrażaniu SAFE gubiona jest filozofia i mindset agile. DAD natomiast stara się budować kulturę współpracy z pominięciem wielu „twardych” aspektów, jak inżynieria oprogramowania, czy struktury decyzyjne. Na swoje nieszczęście LESS i S@S znalazły się w rozkroku pomiędzy dwoma atraktorami. Jak zarząd chciał utrzymania kontroli w zwinności uwaga firm ściągana była przez SAFE, jak natomiast firma chciała zbudować zwinną kulturę, nie ingerując w operacje i projekty, to w kierunku Spotify.

Jednak jak widać nawet te dwa wiodące podejścia również szczyt mają już za sobą.