CTO Morning Coffee

Ok, udało się dołączyć do Sebastiana, bo już myślałem, że będę dzisiaj sam.

Albo, że Spaces odwaliło jakiś nowy numer.

Albo, że Sebastian nie znalazł Spaces po lewej stronie w menu.

Cześć, cześć, witam wszystkich.

No bo dzisiaj jest w ogóle jakiś historyczny odcinek, dlatego, że będziemy live, ale nie wszyscy działający z tej samej aplikacji.

Bo androidowcy chyba już są zaktualizowani najnowszym brandingiem i oni będą w X Spaces.

A ci, tak, a jabłkowcy ciągle jeszcze w Twitterze, więc to będzie takie spotkanie ponad podziałami.

Wielki podział.

Nie, ale to jest trochę śmieszne, że w sumie co tydzień nie wiadomo, w jakiej aplikacji będziemy rozmawiać.

Ale, ale, ale, no cóż, przynajmniej nic się nie...

Zanim Wojtek dołączy jeszcze chwilę, bo napisał, że minutę, ale jeżeli chodzi o ten cały rebranding, to faktycznie to, że jeszcze nie zmienili nazwy aplikacji, to jest ciekawe.

Chyba się boją tego, że ludzie przestaną ją znajdować po prostu, nie?

Wiesz, że jak ktoś szuka, to nie będzie mógł znaleźć, że to jest X teraz, nie?

No, zobaczymy.

Wszystko jest możliwe.

Tak, czekamy na Wojtka, czekamy na naszego chłopaka z rozkładówki Forbes'a.

Jeżeli ktoś jeszcze nie widział w najnowszym numerze Forbes'a...

Ja już to powiedziałem.

Chyba już dostępnym w sprzedaży, w kioskach, nie wiem, pikach, to już jest wywiad z Wojtkiem.

Także warto się zapoznać.

Dobra lektura na wakacje.

Dobrze, nie na okładce.

To jest tak, to jest, to jest, to jest ła wróżła podobno.

Ci, ci z okładki idą do więzienia, ale to spoko.

Z głębodzią.

Wojtek już jest z nami, więc teraz musimy już być poważni.

Możemy zaczynać chyba z...

Dzień dobry, wiedziałem, że będzie od razu malutka szpila.

Malutka szpila, cześć.

Obgadaliśmy dziort góry do góry.

Dobrze, słuchajcie, mamy jeszcze trzy po, więc tak, przejdźmy do standardowych naszych obrzędów.

To jest CTO Morning Coffee, nasze superfajne co dwutygodniowe, a czasem nawet częściej spotkania, gdzie rozmawiamy sobie o technologii, o zarządzaniu, o leadership'ie, a zwłaszcza o tych aspektach, które są interesujące dla tak zwanych senior technical leaders, czyli CTOs, ale nie tylko, i również oczywiście tych aspirujących.

No właśnie, każde takie spotkanie ma swój konkretny temat.

Dzisiejszy temat, ja sobie tak robocznie nazwałem slowdown, ale bardziej malowniczy sposób opisaliśmy go w social media, czy śmierć od tysiąca ostrzy, dlaczego organizacje technologiczne spowalniają wraz ze wzrostem, no i przede wszystkim, czy da się to odwrócić, zatrzymać.

Sam przy tych wakacji fajnie, że z nami jesteście.

Mała, małe info odnośnie konwencji naszych spotkań.

Przez tą godzinę rozmawiamy sobie swobodnie, czyli każdy może zabrać głos, każdy może skomentować, wystarczy skorzystać z funkcjonalności, która się nazywa roboczo podnieść łapkę w aplikacji, no bo niestety przez weba tylko możecie nas słuchać, ale nie możecie się jeszcze udzielać.

Może się to zmieni, kto wie.

W każdym razie zachęcamy do tego, żeby również zabierać głos.

My możemy nie zauważyć tego od razu, więc się nie zniechęcajcie i podnoście tę łapkę dalej.

Nasze spotkania, oczywiście no, my sobie bardzo mocno cenimy tą wersję live, dlatego że wtedy właśnie możemy sobie porozmawiać w większym gronie, w szerokim gronie, ale one są również archiwizowane w postaci podcastu, więc jeżeli ktoś zbije na nasz landing page cityomorning.coffee znajdzie tam linki.

Oprócz tego od około tygodnia mamy już też spotkania w formie już nie na żywo, tylko zupełnie asynchronicznie, na YouTubie.

One się nazywają City of Morning Brew, więc linki możecie znaleźć, no, czy to po prostu szukając naszej listy na YouTubie, City of Morning Brew, czy właśnie również poprzez naszego landing page'a.

Jeżeli chodzi o formułę naszych spotkań, no to przede wszystkim staramy się, tak, zachować pewną dozę profesjonalizmu, zdrową dozę, czyli nie krytykujemy jakichś indywidualnych osób, nie krytykujemy nawet firm, jeżeli krytykujemy, to krytykujemy jakieś postawy.

Chyba to są najważniejsze rzeczy, o których miałem powiedzieć, czy o czymś zapomniałem?

Ja zawsze myślę, czy ty masz jakiś prompt, który leci i po prostu ten prompt jest z odcinka na odcinek coraz lepszy.

To jest wszystko zautomatyzowane, panie kolego.

Ale zanim przejdziemy do merytoryum, chciałem powiedzieć, że w takim razie odgadywanie kolegów poprzez nie jest wykreślone z listy, więc dobrze, jedziemy.

Dobra, słuchajcie, temat, muszę przyznać, że mi się bardzo podoba i to jest zjawisko, które na pewno każdy z nas się z nim zetkną.

Na pewno każdy z nas jego dotyka.

Czasami to są problemy, które potrafią wywalić, jeżeli nie organizację, to nawet część organizacji.

Więc zastanawiam się, od czego to ugryźć, więc może, słuchajcie, pierwsze takie pytanie rozgrzewkowe.

Jakie widzicie w ogóle właśnie takie główne powody, jakieś takie drajwery, faktory tego, że zwalniamy w naszych firmach, tak?

Czyli w tych mamy organizację technologiczną, mamy firmy, oczywiście każda teraz firma praktycznie jest organizacją technologiczną przede wszystkim.

Jeżeli do kogoś jeszcze to nie doszło, to witamy w 2023 roku.

No właśnie, no i produkujemy jakiś produkt software'owy oparty o architekturę cloudową, no i te działania nasze coraz bardziej zwalniają.

Od momentu seeda, w którym pięknie nam poszły pieniądze, wiecie, pracowaliśmy pewnie długo i pocieczała, budując bardzo szybko, wypuszczając feature'y, wszystko nam pięknie rosło, później nagle się okazuje, że nagle zespoły nam jako liderom mówią, że to wszystko zajmuje 2-3 razy tyle, co my byśmy dali z tematy.

No dobra, więc wracając.

Ja mam chyba wymienionych 7 powodów, ale zacznę od tych trzech najgrubszych.

A właśnie taki może dyskrement jeszcze na samym początku.

To rozważanie będzie wyglądać zupełnie inaczej dla firm, które rzeczywiście na początku były szybkie i zwalniają, i widzą, że zwalnia ich tempo, versus firmy, które no od samego początku nie były szybkie i po prostu chcą przyspieszyć.

Więc to jest zupełnie inny rodzaj rozważania.

Do twojego jeszcze dodam, versus firmy, które już zapomniały, że były szybkie i już są wolne.

Okej, to dla mnie ta druga kategoria.

Bardzo dobry podział.

Nie, bardzo dobry podział, ja też mam swoje typy, więc no zapraszam do dyskusji.

Tak, więc te trzy grube powody, bo może powiem te trzy grube, a potem też oddam komuś głos, a ewentualnie wbiję jeszcze z czymś później.

Dla mnie te trzy grube powody to jest tak, to są długi, zaraz wyjaśnię co mam na myśli mówiąc długi.

Drugi to jest entropia, a trzeci to jest nasza tendencja do tego, żeby tylko dodawać, a nigdy usuwać.

I to są według mnie trzy najgrubsze powody.

Więc tak, o co mam na myśli mówiąc długi?

Mówiąc długi mam na myśli nie tylko i wyłącznie dług techniczny, ale też jego ekwiwalenty w innych sferach działania firmy.

Procesowy.

Dług, dokładnie, dług procesowy, ale też dług projektowy, tylko projektowy w sensie designu, bo to jest zupełnie inny rodzaj długu.

Więc wszystkie te sfery mają pewnego rodzaju konsekwencje podejmowania, nazwijmy to umownie decyzji na skróty, które się kumulują i koniec końców to all together to wprowadzi do tego, że zwalniamy.

A drugi taki powód z tych trzech, które wyjaśniam, to jest entropia.

Entropia, czyli no bo tak, firma albo produkt informatyczny to nie jest coś białkowego, to nie jest jakaś forma życia, ale z drugiej strony wszelkiego rodzaju jakieś małe takie inkonsystencje albo małe niedopatrzenia, albo luki w jakimś procesie governance'u, czegokolwiek, one prowadzą do spadania standardów, do tego, że gdzieś tam jakaś konwencja, która dawałaby nam jakąś stałą jakość, pewność pewnej prędkości, że ona się po prostu rozmywa, że tracimy ją.

I ta entropia, kiedy ona się już wkrada, strasznie ciężko jest ją zatrzymać.

Na początku tego nie widzimy, to są jakieś niedopatrzenia, natomiast to jest też coś, co się kumuluje z czasem.

No i to jest w końcu ta trzecia rzecz, która wydaje mi się akurat prosta, nie ma co jakaś specjalnie tłumaczyć, to jest to, że my jako ludzie mamy taką świadomość, że my dodajemy wartość, kiedy budujemy coś, a strasznie ciężko nam pozbywać się czegoś, co na przykład nie ma sensu, albo coś, co już nie jest potrzebne, albo czegoś, co się nie sprawdziło.

Teraz w związku z tym to cały czas rośnie baza naszego kodu, ilość naszych rozwiązań, jesteśmy z tego dumni, jest nam ciężko się tego pozbywać, nie mamy takiej kultury pozbywania się, no i to też summa summarum prowadzi do wzrostu kompleksji.

To są te trzy główne moje powody.

Bardzo fajnie to ugryzłeś.

Bardzo ciekawe dla mnie strony, bo ja ugryzłem to całkiem inaczej, chociaż podobnie dla mnie.

Pierwsza kategoria tych problemów to jest tak naprawdę organizacja i kultura.

I tutaj zaraz do tego nawiążę.

Druga to jest ta wiedza, o której wspomniałeś, no i trzecie też miałem dług, chociaż bardziej się skupiłem na, pewnie na technicznym, bo tutaj dla mnie ten dług procesowy jest w tej organizacji.

Więc pierwsza i najważniejsza rzecz, którą myślę, że obserwujemy, to jest tak naprawdę, wynika z wiedzy i chyba to jest dla mnie najważniejsza grupa i jeżeli o tym myślę, to przede wszystkim wiesz, że jeżeli mówimy o zespołach działających, to to są zespoły, które świetnie mają opanowaną wymianę wiedzy, czyli tak naprawdę kluczowe jest to, żeby wymieniać się wiedzą.

I tutaj mamy tak naprawdę, jak ja o tym myślę, takie dwa od razu prawa, które nam się nasuwają, czyli prawo Brooksa i Conwaya.

I tutaj od razu już dla osób, które mogą mnie kojarzyć w wymienie, czy prawo Brooksa, to jest to prawo, które mówi, jaka jest ilość komunikacji potrzebna w projekcie, jeżeli chodzi i czas do jego ukończenia.

Czyli tam naprawdę mamy, ile na przykład linii komunikacji jest potrzebnych, żeby skomunikować różne osoby.

I oczywiście to rośnie bardzo wykładniczo, jeżeli chodzi o ilość osób, które wymieniają się danym informacjom.

Oczywiście tworzenie produktów, to jest przede wszystkim wymiana informacji, czyli wymiana wiedzy domenowej, wymiana wiedzy technicznej, wymiana chociażby już planu wykonania danego projektu.

Więc zauważcie tutaj, jak szybko porusza się zespół, który ma trzy do pięciu osób, z Waszego doświadczenia, a jak szybko porusza się zespół, który jest dziesięć do piętnastu osób.

To jest właśnie prawo Brooksa, więc chętnie do niego pewnie jeszcze wrócę.

No i też od razu chciałem tutaj przypomnieć prawo Conwaya, czyli tak naprawdę bezpośrednio to, jaką mamy strukturę i kulturę komunikacji w firmie, też wpłynie na nasze rozwiązanie.

Czyli jeżeli organizacja, i tutaj pewnie do tego drugiego typu organizacji, do którego nawiązałeś szczególnie, jeżeli organizacja nam skręciła w silosy, no to oczywiście wpłynie to też na silosy w architekturze systemu, w technologii i w rozwiązaniach.

Natomiast Tomek...

No dobrze.

Nie chcę zabierać głosu.

Ja wejdę trochę...

Nie, no zabieraj głos.

Ja wejdę trochę...

No dzień dobry.

Trochę skończę do jednej rzeczy, którą powiedziałeś.

Może nie kończę, ale takie skrytowanie, bo powiedziałeś, że największym wyzwaniem jest to wymienianie wiedzy.

Wy chyba poruszyliście wszystko, co ja bym też poruszył, tylko ja patrzę na to trochę inaczej może, bo dla mnie kluczem jest to, co Sebastian poruszył, czyli... i on to zabiera wiele rzeczy, czyli entropia.

Bo prawda jest taka, że jak organizacja rośnie, żeby utrzymać to tempo tak jakby działania szybkiej organizacji, która podejmuje szybko decyzje, szybko robi rzeczy i tak dalej, no to musimy, krótko mówiąc, walczyć przeciwko tej entropii, czyli mieć w organizacji najpierw celowo podjąć decyzję, że chcemy ją zwalczać, tak?

Albo inaczej, że chcemy zachować to tempo.

I to niestety wymaga wysiłku.

I teraz z wzrostem tej organizacji ten wysiłek się robi coraz większy, nie?

I w którymś momencie niestety następuje odpuszczenie.

Albo inaczej nie da się już zwalczyć wszystkiego.

Z czego się to bierze?

Głównie ze względu na to, że pojawia się wzrostem ilości ludzi, zespołów, bo tu się wszystko na siebie nakłada.

Żaden z tych powodów nie jest jednym.

One wszystkie ze sobą grają, ale ze wzrostem ilości ludzi, zespołów i tak dalej wzrasta coraz bardziej ilość czasu potrzebna na synchronizowanie ludzi, na przekazywanie nawet, jeżeli wprowadzamy jakąś zmianę, na przekazywanie nawet takich podstawowych principles, czy zasad działania pomiędzy tymi ludźmi, pomiędzy zespołami.

A z drugiej strony spada w tych zespołach poziom adopcji tego, nie?

Czyli wiesz, jeżeli my mówimy, możemy czy działać tak.

Jak mieliśmy dwa zespoły, to łatwo im to przekazać.

Jak mamy dziesięć zespołów, to każdy z nich zaczyna lekko robić deviation od tego.

Jak zaczyna się robić deviation od tego, to powstaje wysiłek na to, żeby to wyrównać.

I to jest niestety negatywna pętla zbrodna, nie?

Bo każda iteracja zmiany czegokolwiek w firmie, każda iteracja dołożenia kolejnego produktu, dołożenia kolejnego zespołu i tak dalej powoduje, że ta pętla zmiany się wydłuża, nie?

I w ten sposób zaczynamy działać wolniej, wolniej, wolniej.

Niestety faktycznie dużym powodem jest to, co powiedział Sebastian, czyli tendencja do dokładania, tak?

Czyli mało kto się zastanawia, co usunąć z organizacji.

No i zaczyna nam narastać, nie?

Zaczyna nam narastać dług w różnych rodzajach, czyli i procesowy, i techniczny, i organizacyjny.

I ta pętla z każdym taką iteracją się zaczyna wydłużać, nie?

Więc te wszystkie rzeczy, które powiedzieliście, one działają razem, ale według mnie to narzut na zwalczanie tej entropii po prostu zaczyna rosnąć bardzo szybko w miarę rozwoju organizacji.

Najgorsze, że chyba trochę się zgadzamy we wszystkim, więc mało dyskusji.

Słuchajcie, zapraszamy serdecznie do wypowiedzi.

Jeżeli się zgadzacie lub chcecie wejść w kontrze, to przypominamy, że serdecznie zapraszamy.

Każdy z nas się na pewno zetknął z problemami, kiedy i jak zwalnialiście.

I właśnie o tym jest ten odcinek.

Sebastian.

Mam jeszcze kilka powodów, może takich trochę ciekawszych case'ów, trochę bardziej węższych, ale które też w sumie akurat mogą wzbudzić dyskusję.

Bo tak, mam wrażenie, że czasami to, że my zwalniamy, to jest też efekt, uwaga, survivorship bias.

To znaczy, że zauważamy ten efekt tylko i wyłącznie u firm, które były naprawdę szybkie kiedyś.

One były naprawdę szybkie, bo trochę wygrały los na loterii.

A przez ten los na loterii rozumiem, że naprawdę miały świetny, bardzo sfokusowany wstępny team, ludzi, którzy mieli drive, którzy byli fully accountable, którzy byli dobrymi organizatorami, którzy potrafili, jak to się mówi, getting shit done.

I teraz przeżyły tego typu organizacje, które były naprawdę szybkie, natomiast później ta kultura się rozjechała.

Czyli na początku udało się wygrać ten los na loterii, ale tego losu się nie udało przeskalować.

Czyli nie udało się utrzymać tej superfantastycznej kultury i to jest cena sukcesu takiej organizacji.

I tutaj sobie możemy za chwileczkę podwagować, czy to tak musi się dziać, czy taką kulturę można się utrzymać w jakiś potencjalny sposób, ale uważam, że to jest dosyć popularny case.

Kolejny ciekawy efekt, dla którego, moim zdaniem, organizacje zwalniają, to jest, powiedzieliśmy wcześniej, bo Tomek też się do tego dorzucił, że my nie umiemy usuwać, tylko umiemy budować.

Ale jeszcze nie umiemy innej, jednej ważnej rzeczy.

Czyli nie umiemy dobrze wdrażać nawet dobrze przemyślanych zmian.

Co mam na myśli?

Mam na myśli tak zwany lava flow efekt.

Czyli na przykład nauczyliśmy się czegoś, stwierdziliśmy, że stara architektura była do dupy i teraz będziemy mieli nową, lepszą architekturę.

I nawet mamy pomysł, jak ta nowa architektura powinna wyglądać.

I nawet umiemy zacząć ją gdzieś tam budować, ale nie umiemy posprzątać tej starej.

I teraz po czterech latach mapa naszego systemu to tak naprawdę wygląda jak taka lava spływająca z czubka wulkanu, która sobie znalazła jakieś ścieżki w lewo, prawo, lewo, prawo, czyli jest takim patchworkiem wszystkich starych architektur, które się pojawiały w ramach naszego systemu w przeciągu całego życia naszej firmy.

Nie dotyczy to...

Ja ci wejdę taki szybki, bo to jest podobne i w softwareze, i w wytwarzaniu czegoś w organizacji, ale co jest ważne tutaj, bo nie potrafimy wdrażać tych zmian dlatego, że ludzie nie widzą zmiany jako zmiany do wdrożenia, tylko po prostu jest let's do it, nie?

Żeby to zadziałało, żeby ten, to faktycznie trzeba się nad tym poświęcić czas.

I to jest to, co mówiłem wcześniej o tym, że wysiłek wkładany w to, żeby ta organizacja dalej działała szybciej, niestety rośnie wykładniczo, nie?

Potem...

Zgadzam się, ale ja bym to jeszcze podsumował tak bardziej dobitnie.

Ja bym po prostu powiedział, że mamy problem ze sformułowaniem dobrego accountability za zmianę.

Czyli, że ta zmiana to nie jest tylko i wyłącznie to nowe, piękne, ładne, ale ta zmiana to jest to sprzątanie tego systemu, który był wcześniej.

I nie ma jednego oddzielnego, drugiego, trzeba zrobić obie rzeczy i jest się rozliczanym z obu rzeczy.

Więc koniec końców to się sprowadza tak do tego, co powiedziałeś, natomiast ja bym to tak sfrezował bardziej dobitnie.

Ale za sprzątanie rzeczy nikt nie dostaje sex off letter i bonus.

Dokładnie, nikt nie dostaje laurów, okej.

I wiecie co, jeszcze...

Bo dużo rzeczy my tak wymienili, tych składowych, więc może poprzestajmy, ale mam jeszcze jedną rzecz w sumie, którą chciałem powiedzieć.

Niby taka oczywista, ale jakoś nie padła.

No, na początku nam się wydawało, że byliśmy superfajni, superszybci, ale też dlatego, że my zaczynaliśmy z niskiego pułapu.

Nie było tego complexity.

Nie było pięćdziesięciu tysięcy jakichś już feature'ów, które trzeba było rozważyć, dodając kolejny feature i jego zależności.

Tylko po prostu, no...

Przestartowaliśmy z jakimś tam carte blanche.

Natomiast z czasem, no, rośnie to complexity.

I rośnie nie tylko to complexity accidental, które wynika tam, nie wiem, ze złego doboru technologii, albo w ogóle z tego, że technologia jest czasami skomplikowana, ale rośnie też takie inherent complexity, czyli to, że no, ta nasza domena już stała się...

Ten nasz model domeny stał już się dosyć skomplikowany.

Już się zamykam, bo tych powodów można byłoby zmnożyć bez końca.

Powiedziałeś coś, do czego jeszcze nie nawiązaliśmy, ale to faktycznie ja na pewno kilka razy miałem okazję odczuć.

Czyli w momencie, kiedy budujemy całkowicie nowy zespół, i to oczywiście jest teraz pytanie, czy to jest nowy zespół od samego początku firmy, czy to jest całkowicie nowy zespół w większej firmie, na pewno ten start jest z reguły bardzo szybki.

I tutaj też jest bardzo ciekawe właśnie, że z reguły dobieramy osoby, które nam pasują kulturowo, które mają poczucie misji, mają poczucie też jakiegoś purpose fajnego i pewnie mają ochotę i wiecie, są w stanie rozbijać skały, żeby się przebić.

Więc tutaj na to też chciałem zwrócić uwagę i może będzie fajnie do tego wrócić.

Cześć, Grześku.

Dołącz do nas, jesteś?

A przepraszam, zmotywał mi mikrofon.

Taki psikus.

Ja chciałem się podzielić doświadczeniem z Wami.

Aktualnie, można powiedzieć, przeżywam je.

Jestem w startupie, który w bardzo wczesnej fazie, prawie na początku do niego dołączyłem i to jest ten przykład, gdzie jesteśmy wolni od początku.

Na pokład przyszło bardzo dużo seniorów, tak chcieliśmy to zbudować, że jak weźmiemy dużo seniorów, to będzie hulać od początku.

Bardzo szybko się okazało w takiej prostej przysłowie, że gdzie kucharek sześć, tam nie ma co jeść.

To znaczy, świetni ludzie na pokładzie, ale zbyt dużo dyskusji.

Każdy chciał pokazać, wiecie, to, co najlepsze i przynieść na pokład to takie top of the top, to swoje doświadczenie, co wyniósł z każdego projektu.

Ja pamiętam, jak my na przykład kilka tygodni dyskutowaliśmy nad modelem realizowania aplikacji i biznes się puka w głowę.

Co się dzieje?

Czemu nie jesteśmy w stanie dowozić?

No bo tutaj po prostu to nie działało.

I szczerze powiem, pierwszy raz się spotkałem z taką sytuacją.

Myślałem, że tam, gdzie będzie dużo doświadczonych ludzi, to będzie hulać.

Zaczęliśmy rosnąć, tam w szczycie nas było naprawdę już pod 20 osób i nadal nie byliśmy szybcy.

Pierwszy raz się z taką sytuacją spotkałem.

Zawiodło wiele rzeczy, komunikacja się rozrosła, zaczęło się jakieś, musiało wejść planowanie, koordynacja, zadań, sporo rzeczy.

Moje przeczucie było takie, że to nie wypali i posypało się rzeczywiście.

Nas jest teraz kilka osób.

Działamy, dowozimy.

Może nie jest idealnie.

Ja się z tym czuję dobrze i mam obawy, co dalej.

Bo wiadomo, że na dłuższą metę tak nie pociągniemy.

W takim kilkuosobowym zespole, takich powiedzmy ninja developers, którzy lubią taki klimat i dowiozą zawsze wszystko.

Może nie w najlepszej jakości, ale w końcu to startup w ówczesnej fazie.

I mam obawy przed ponownym wzrostem, bo chcemy zatrudniać, chcemy brać ludzi, ale można powiedzieć, że spaliliśmy się trochę.

Także takie moje doświadczenie.

Dzięki, Grzesiek.

To jest ciekawe, co powiedziałaś, bo ja tylko powiem, że przed wzrostem to się wszyscy boją, ale tam da się ogarnąć.

Trzymam dołączył do nas...

Może sekundkę, jeszcze się wbiję, tylko żeby do Grzeszka uderzyć.

Wiesz, Grzegorz, był taki odcinek, bo wydaje mi się, że to, z czym wy macie problem, to jest taki strong leadership i jasna accountability culture.

Więc był fajny odcinek, ten my mieliśmy na temat decision making, więc rzuć sobie uchem na ten odcinek.

Tam jest dużo fajnych patternów odnośnie disagree and commit, odnośnie modelu racji, jeszcze paru innych modeli, odnośnie tego, jak dzielić decyzje na jednokierunkowe, dwukierunkowe.

Wydaje mi się, że tam jest dużo takiego food for thought, które może się Wam przydać.

Już się zamykam.

Patrzę w szklaną kulę i ten odcinek będzie w przyszły czwartek też, czyli na YouTubie.

Szymek, byłeś następny.

Tak, cześć Wam.

Pierwsze moje tutaj uczestnictwo, więc bardzo jestem zainspirowany i tak trochę z innej strony też mogę się podzielić.

Znaczy tak, oczywiście taki też komentarz, że nietrudno sobie wyobrazić, że takie początki potrafią być bardzo trudne.

Ja akurat chciałem się podzielić doświadczeniem o tyle innej strony, że miałem ogromną przyjemność dołączenia do dużej firmy, która cały czas działa jako startup.

Około dwóch tysięcy osób i nie mogłem się nadać na najfajniejsze moje doświadczenie w kontekście procesów, kultury i różnych innych rzeczy.

I to tak zacząłem się stanawiać, przede wszystkim jak usłyszałem to hasło entropii.

W przypadku tego projektu, w którym pracowałem w sumie około 3,5 roku, kilku projektów w sumie tam zmieniałem, no to między innymi było takie podejście, gdzie doświadczone osoby, te, które jakby już czuły ten klimat, tę atmosferę, założenia różne i tak dalej, dbano o to, żeby one właśnie na przykład przychodziły do nowych projektów i dzieliły się tym, co już jest wiadome, żeby utrzymać, starać się utrzymać ten poziom.

I to ja obserwowałem od samego początku, kiedy na przykład nowa osoba, gdzie ja byłem w projekcie, mimo wszystko, że byłem jakimś tam team leaderem, dzieliła się ze mną, że tutaj robimy tak, tam inaczej, tam coś tam, ale również kolejna rzecz, był ogromny nacisk przy szukaniu TPM-ów, czyli jakby więcej niż Scrum Masterów do projektu, żeby mechanikę i tak dalej, wszystko mieli dobrze opracowane, w sensie byli dobrze doświadczeni.

I w efekcie, oprócz tego również, no jakby w kontekście tej kultury, tak, to, co było bardzo fajne, pierwszy raz w ogóle się z czymś takim spotkałem, mieliśmy mniej więcej raz na pół roku coś takie jak Agile Health Assessment, tak jakby meta-retrospection, gdzie rozmawialiśmy o tym, jak te procesy nam funkcjonują, czy się zgadzamy, czy nie, były głosowania, action pointy i takie różne rzeczy.

Także naprawdę wyjątkowe doświadczenie, w ogóle poza Polską, więc też nerwowo na początku, bo z całą rodziną wyjechałem, ale najlepsze moje doświadczenie i faktycznie ta entrepia była cały czas w tym projekcie taka zdecydowanie większa niż na początku, ale przy dwóch tysiącach osób nie mogłem się nadziwić, że naprawdę firma całkiem nieźle sobie radzi.

Ja bym może nawet zaproponował, żebyśmy tam się odezwieli, może kiedyś byśmy zrobili dobrą rozmowę z tobą, jak to wygląda z takiego przykładu, bo przykład jest dobry.

Tak, ja mogę powiedzieć, że znam firmę, która ma siedem tysięcy osób i też bardzo szybko działa, także też myślę, że to będzie dobry temat na odcinek.

Robert, byłeś kolejnym naszym gościem.

No to wygląda.

Hej wszystkim.

Na początku chciałem powiedzieć, że w sumie zgadzam się z wszystkimi obserwacjami na początku, ale wydaje mi się, że w naszej dyskusji brakuje jednej rzeczy, albo spoiler alert i chcieliśmy o tym rozmawiać trochę później, ale wydaje mi się, że jest to dość ważna taka postawa tej dyskusji, bo cały czas mówimy o tym, ok, czy jakiś team dowodzi szybko, czy wolno, ale wydaje mi się, że ważnym kontekstem w tym jest, żeby definiować, co to w ogóle znaczy, że team idzie szybko, czy wolno.

Wydaje mi się, że sam miałem w tym dość często problem, żeby to zdefiniować, bo jakby wydaje mi się, że ciężko jest to dość odnieść, bo wiadomo, różne produkty mają różne problemy i niektóre problemy po prostu są, no można powiedzieć, trywialne do rozwiązania i nawet wewnątrz jednej firmy.

To też jest dość ciekawe, że mogłoby się wydać, że niektóre teamy na przykład są dużo bardziej wydajne, a niektóre dużo mniej, tylko, że niektóre pracują nad jakimiś zgodnie prostymi kludami, a niektóre mają bardzo gęstą logikę domenową, którą ciężko rozkminić.

Także to wydaje mi się dość ważna rzecz, ale tak mówię, no też chętnie posłucham na przykład, czy macie jakieś ciekawe odniesienia co do tego, kiedy faktycznie team jakiś idzie wolno, czy szybko.

No jedyne, co mi przychodzi do głowy, to rzeczy typu State of DevOps Report, więc może do części ludzi to będzie, część ludzi to coś powie, ale pewnie jest to jakieś odniesienie, ale też może są jeszcze jakieś ciekawsze.

Właśnie mieliśmy przejść do tego tematu.

Ja się uśmiecham.

Ja się uśmiecham, bo właśnie powinien był być dobry, zrobiłeś nam spoiler, a to miało być tak.

Zanim przejdziemy do tego.

No ja teraz wejdę i słuchajcie, i mówię, że jest sobie demo przed firmą, załóżmy w startupie, przychodzi pan prezes, patrzy i ma wrażenie, płacę za wiecie 50, 100, 200 osób i matko boska, nic nie zostało zrobione.

Wybucha na tym spotkaniu, Scrum Master staje na środku i mówi, pokazuje wykres velocity i mówi, no spaliliśmy 200 story pointów o 10% więcej niż w tamtym tygodniu.

Więc od razu słuchajcie, wrzucam tutaj szpilę i pytam się, i co z tym velocity się podziało?

Nikt nie chce podjąć wyzwania?

Nastąpiła cisza.

No nie mierzymy tempa organizacji żadnym velocity, to jest bez sensu zupełnie.

To są dwa ciekawe tematy.

Ale nazwa wskazuje.

To są dwa ciekawe tematy, bo jeden temat, wydaje mi się, który Robert poruszył, to jest to, czy my rzeczywiście zwolniliśmy, spowolniliśmy, może w ten sposób, bo zwolnienie to się jednak w polskim języku inaczej kojarzy, a drugi temat to jest, żeby rzeczywiście to mierzyć, bo to są trochę mimo wszystko, ja wiem, że bardzo profesjonalne, ale trochę osobne tematy.

A więc może właśnie, to zacznijmy od tego jak mierzyć i czy da się w ogóle mierzyć.

Mamy taką tendencję, że my przy tym mierzeniu to schodzimy czasami do szczegółu, czyli próbujemy porównać jedną historijkę, czy feature z innym, no i wtedy się rzeczywiście rozjeżdżamy.

Rozjeżdżamy się, bo na przykład, jeżeli nawet te ekrany były podobne, w sensie ten, który tworzyliśmy dwa lata temu i ten, który tworzyliśmy teraz, to tworzyliśmy je w innych okolicznościach, w innym kontekście, więc tego nie ma sensu porównywać.

Więc z takiej mojej perspektywy, to jeżeli chodzi o porównywanie i mierzenie, to gdzieś na poziomie pojętego itemu nie, na poziomie statystycznym tak, ale trzeba mieć tych danych statystycznych naprawdę sporo i trzeba też cały czas pilnować BIAS-ów, które są, bo tam jakieś BIAS-y będą na pewno.

Ja bym się...

To, co u mnie dobrze działało, to jest spojrzenie na proces wytwórczy, rozpisanie sobie go i zrozumienie jego na przykład metryk składowych, czyli nie patrzenie całościowo, no bo fajnie jest, jeżeli jesteśmy w stanie zmierzyć na przykład jakiś cycle time, to okej, tylko że ten cycle time na jakim poziomie, bo ta jednak rozdzielczość tych tematów, które dowozimy, potrafi być bardzo różna.

Ale spojrzenie na metryki składowe, na przykład na jakiś decision making, czyli właśnie ile zajmuje nam objęcia jakiejś decyzji, ile ludzi jest przy... po drodze zaangażowanych, ile jest etapów, ale tak samo metryki techniczne składowe, czyli spojrzenie na to, jaki jest czas kompilacji, jaki jest czas deployment-u, jaki jest failure rate na różnym poziomie, inne rzeczy.

Ja też tutaj dodam, czyli na przykład też właśnie procesy wokół technologii, czyli na przykład czas potrzebny na review.

To też dużo mówi, bo to są te handlowery często, które mamy w zespołach, które są ukryte bardzo dużo.

Ilość outstripów przy takim review też, ileś uwag, które to jest jak najbardziej tak.

Ale tak samo, jeżeli chodzi o tą naszą entropię, mówiliśmy tutaj o problemach z wiedzą, więc mierzenie jakości dokumentacji, ja wiem, że to brzmi trochę w szalony sposób, ale to też się robi.

To też można robić, mierzenie jej kompletności również.

Można też mierzyć różne overheady, czyli na przykład spojrzeć historycznie, jaki był na przykład ratio ludzi, którzy tworzą oprogramowanie, ogólnie to całej organizacji kiedyś, jaki jest teraz, i przyjrzeć się temu krytycznie, czyli dlaczego ten ratio się zmienił i teraz czy ta zmiana jest uzasadniona, czy ta zmiana jest uzasadniona we wszystkich miejscach.

Czyli podsumowując, moim zdaniem system thinking, czyli patrzymy na jakąś część organizacji jako pewnego rodzaju system, gdzie mamy pewnego rodzaju przepływy pracy, gdzie mamy pewnego rodzaju tak zwane stacki, stosy, gdzie ta praca się akumuluje.

Jeżeli rozumiemy te przepływy, to w tym momencie jesteśmy zaproponować metryki, gdzieś tam na jakimś poziomie inputów, outputów tych przepływów i mierzyć te metryki, no i tylko musimy mieć przekonanie, że faktycznie te metryki mają duży wpływ już na ten efekt końcowy.

No i ewentualnie statystyka, ale żeby mieć statystykę, żeby to na poziomie statystycznym takie rozważenia prowadzić, to trzeba mieć naprawdę dużo danych i jeszcze pewnego rodzaju governance, żeby te dane były efektem ubocznym naszej pracy, a nie jakimiś uznaniowymi wprowadzonymi informacjami.

Nie jest to łatwe, ale się da.

Ja chyba przywołam tak tylko jako referencję, jeżeli ktoś jeszcze nie czytał, a wątpię, że, bo jak mówisz o tym wszystkim, to przychodzi mi do głowy klasy pod tytułem The Goal, czyli książka o teorii ograniczeń tak naprawdę i o przepływie pracy i tak dalej, i tak dalej, bo to się do tego sprowadza to, co powiedziałeś, czyli pomierzenie gdzie jesteśmy, co gdzie idzie, jak idzie i tak dalej, nie?

Tak, dokładnie.

Tomek, ja tutaj mam pytanie.

Szymek, bo ty mówiłeś, że jesteście faktycznie już dosyć dużą organizacją, która bardzo szybko działa i cię zaskoczyła.

Co mierzycie z tego, co Sebastian wymienił?

To w ogóle był projekt, który już się skończył.

Gdzieś w okolicach początku COVID-u w sensie.

Ja byłem za granicą i wróciłem do Polski.

Natomiast co było mierzone?

Pierwsza rzecz tak od razu też natychmiast mi się uruchomiły wspomnienia, jak tutaj mówicie o tym.

Pierwsza rzecz to było po prostu Velocity w sprintach, w różnych projektach.

Akurat było tak, że ja też pracowałem wspólnie z TPM-em, z którym też przechodziliśmy do jakichś tam kolejnych zespołów i na przykład w ogóle na samym początku dekompozyrowaliśmy nowy zespół.

Mieliśmy taką historię, że rozjechaliśmy się z estymacjami bardzo.

Coś tam nam zajęło trzy miesiące, miało zająć miesiąc mniej więcej, czyli przy dwutygodniowych sprintach.

Ale wyciągnęliśmy wnioski i potem mieliśmy tak rzędu 90% przewidywalność tego, co estymowaliśmy, więc to była podstawowa rzecz.

Natomiast z innych rzeczy na przykład bardzo ciekawa jest kwestia tej dokumentacji.

U nas to po prostu działało, tak można by powiedzieć.

Bo czasami jest tak, że kolejna rzecz jeszcze na poziomie organizacji mieliśmy OKR.

Tylko to było na poziomie zarządu.

Była idea, żeby to wprowadzać potem coraz niżej, żeby poszczególni menadżerowie mieli swoje KR, żeby nawet ludzie w zespołach mieli.

I to było tak na etapie, że ci menadżerowie też zaczęli nad tym pracować.

I w tym sensie myślę, że to przekładało się na to, no bo nie da się mierzyć wszystkiego, prawda?

W tym sensie to się przekładało na to, że pewne rzeczy rzeczywiście nieźle działały.

Były rzeczy, które nie działały aż tak super, ale na przykład dokumentacje mieliśmy fajne, jakieś tam różne runbooki.

No bo też z tą dokumentacją nie można przesadzić.

W pewnym momencie jakby szczególnie w tak dużej organizacji zaczyna się robić ogromny problem komunikacyjny, tak?

Jak to wszystko przekazywać, zarządzać i tak dalej.

Więc ja myślę, że kluczowe metryki to były OKR-y.

Mieliśmy też metryki.

Kolejną rzeczą jeszcze, którą mieliśmy ciekawą, to było first to know, czyli wprowadzanie rozwiązań takich, w których wiedzieliśmy o tym, że są jakieś błędy wcześniej niż użytkownicy to zgłaszali.

I to też było mierzone czas rozwiązania problemu na przykład, tak?

Więc myślę, że to były główne metryki, które funkcjonowały.

No dobrze, dużo przykładów padło.

Jeśli ktoś ma coś ze swojej strony do dużo pieniędzy mierzyć, to dajcie znać albo złączajcie się.

Ja może z drugiego, z trochę innego punktu, bo tutaj idę, bo rozmawiamy tutaj dużo o wytwarzaniu oprogramowania i tak dalej.

A ja też uważam, że to organizacja ma tam dużo do powiedzenia, jak to działa.

I to jest ciekawe, bo o ile wiesz, wszyscy tutaj mówimy, jak mierzyć to, jeżeli chodzi o wytwarzanie, oprogramowanie i tak dalej, to pytanie jest, jak mierzyć tempo zmian w organizacji.

I tutaj się podzielę, że my mieliśmy jakieś takie wyzwanie, jak robiliśmy w firmie rzeczy.

Ale też mieliśmy właśnie podejście trochę, jak Sebastian powiedział, żeby o czymś w ogóle rozmawiać.

Czy my jesteśmy wolniejsi, czy szybsi?

To jest subiektywne, więc trzeba mieć to pomierzone jakoś.

I w którymś momencie faktycznie zaczęliśmy mierzyć na poziomie organizacji, się zastanawialiśmy, jak to robić.

No i generalnie pierwsze co, to właśnie to jest system.

Czyli trzeba wiedzieć, jakie zmiany robisz.

Podejść do tego trochę jak do software'u na końcu.

I my zaczęliśmy na przykład mierzyć takie rzeczy, ile zmiana czeka w kolejce, zanim zacznie być wprowadzana.

Czyli generalnie, ile mamy rzeczy, które czekają w kolejce, zgłaszanych przez użytkowników, czy w ogóle przez biznes, jako proces, że trzeba coś zmienić, sprawdzić i tak dalej.

Z drugiej strony zaczęliśmy mierzyć rzeczy, na które to wpływa.

Czyli na przykład, jeżeli ktoś mówi, że coś nie działa, albo działa wolno, to na jaką część to wpływa?

Czyli na przykład, jeżeli nam faktury wpływają w taki sposób, to ile nam schodzi ze ściągnięciem płatności.

I potem jest decyzja pod tytułem to, co implementujemy.

I potem też zaczęliśmy patrzeć na to, to jak długo trwa to od implementacji do wdrożenia.

Czyli od decyzji, że coś robimy, do momentu, aż to jest wdrożone w organizacji.

No i z tego, jak się zacznie faktycznie na to mierzyć, i to nasze IT to już robiło tego i też, no to zaczyna pokazywać się taki obrazek pod tytułem ludzie zgłaszają rzeczy, tych rzeczy jest coraz więcej, ale one coraz rzadziej idą do produkcji.

I to jest faktycznie wtedy metryka tego, że zaczynasz ruszać się wolniej, nie?

Bo organizacji w zmianę literalnie zaczynasz wprowadzać coraz rzadziej, nie?

Ale żeby zacząć to robić, to właśnie na poziomie organizacji trzeba się pochylić nad tym, żeby nawet zbierać te rzeczy w jednym miejscu, nie?

Czyli żeby jak ktoś chce zrobić sobie jakąś zmianę, no to generalnie ona jest jakąś gdzieś ukonstytuowana, jest powiedziane, robimy taką rzecz, jest jakiś backlog tego i tak dalej, nie?

Bo bez tego to mamy takich właśnie, ileś tam atomów, nie?

Które każdy sobie wykonuje jakieś rzeczy, ale overall zaczynamy robić rzeczy wolniej, nie?

Bo ze względu na synchronizację pomiędzy nimi, konflikty i tak dalej, nie?

Więc mierzenie na poziomie organizacji, to co my robiliśmy, no to właśnie mierzyliśmy ilość zmian wprowadzonych do systemu jako requesty, mierzyliśmy czas i dalej mierzymy ile one czekają w backlogu, tak?

Oprócz tego zbieramy input pod tytułem ilu ludzi zgłasza taką potrzebę, jakie są metryki, które na to wpływają, na podstawie tego podejmujemy decyzję, co robić, no i potem jaki jest czas implementacji tego do wdrożenia.

Tu mi przypomniałeś, muszę kiedyś opisać, nie wiem, czy w formie jakiegoś artykułu, czy w jakiejś innej, ale robiłem dokładnie coś takiego, czyli musiałem zaprojektować i wdrożyć w organizacji, to było akurat w Amazonie.

To było akurat, może nie to, że framework do mierzenia prędkości decyzji, tylko bardziej, bo te decyzje były bardziej eksperymentalne, czyli bardziej do mierzenia eksperymentów i te eksperymenty były bardzo często właśnie eksperymentami organizacyjnymi.

A i teraz rzeczywiście wymyślenie tego, jak to mierzyć od początku, jakiegoś zaproponowania jakiegoś modelu accountability i wysiąganie z tego wniosków i też patrzenie, jak ludzie reagują w momencie, kiedy poziom transparencji jest naprawdę wysoki, to było bardzo ciekawe doświadczenie.

To też kiedyś muszę opisać, ale warto to robić.

W każdej organizacji warto to robić właśnie.

Tempo, realizacji, zmian.

No to taki dłuższy temat.

Dobrze, słuchajcie, ale...

Aż, by the way, ograniczać czas na wprowadzenie tych zmian.

Do tego odcinka o podejmowaniu decyzji też odsyłam, bo tam o tym rozmawialiśmy, bo wiesz, możesz z jednej strony powiedzieć tempo, a z drugiej zmiana musi się zmieścić w X, tak?

To tak swoją taką szymek.

Ja bym też zarzucił takie prowokacyjne pytanie.

Czy może być metryka, która mówi o tym, że ilość metryk, które mamy, to już jest za dużo?

Tak, jak zaczynamy spędzać czas na metrykach, na patrzeniu w niej więcej niż ten...

To się akurat da zmierzyć, bo to jest...

Może nie wprost, ale wiesz, bo to jest...

Jeżeli mierzysz czas, my akurat to robiliśmy, nad czym ludzie spędzają czas w firmie, nie tylko nad, wiesz, zadaniami projektowymi itd., to widzisz po jakimś czasie, że na przykład rośnie ci czas związany z czymś, nie?

I potem jest tylko kwestia tego, że jeżeli na to patrzysz faktycznie, nie?

Czyli na przykład rośnie ci czas, gdzie ktoś mówi, że analizował coś, nie?

Jeżeli masz na to kategorię, to jest okej.

Jeżeli to faktycznie zaczyna być znaczące, to podzielenie tego i zajrzenie, to dlaczego ludzie nad tym spędzają czas, to się da zrobić, ale trzeba nad tym po prostu mieć taki jakby fokus, nie?

Czyli trzeba powiedzieć, chcemy wiedzieć, nad czym ludzie spędzają czas i reagować, jak zaczynają go spędzać więcej, nad rzeczami, które nie kontrybuują do, wiesz, odbioru.

Powiedziałbyś więcej, jak sobie mierzycie?

W sensie, to jest kwestia, nie wiem, time-trackingu czy bardziej kwestia tasków, czy, nie wiem, rzeczy w kalendarzu?

Tak z ciekawości.

No to jednak ostatnia rzecz, tu mam kilka osób z firmy, to mam weryfikację od ręki, zaraz mi napiszą, czy mówię dobrze, czy źle.

Więc to my mieliśmy dość specyficzne podejście do tego, bo od początku w firmie po prostu mieliśmy to układane tak, że cały czas jest mierzony w taki sposób, że kategoryzujesz go na swoim kalendarzu, nie?

Tylko że kategoryzujesz nie tylko czas, który jest spędzony na projektach i tak dalej, tylko też na innych rzeczach, nie?

I zaczynaliśmy od bardzo prostych rzeczy pod tytułem to jest czas dla klienta, to jest czas dla firmy, nie?

Ale potem to trochę podzieliliśmy, więc wiesz, nagle wiesz dokładnie typu na przykład, że ktoś pracuje nad projektem, nad którym projektem, potem pracuje nad management, nad jaką częścią management, nie?

I z tego możesz zacząć wyciągać, sobie patrzeć i mówisz, okej, no to w firmie rośnie overall czas spędzany na cod management, no to podzielimy go na dwa i zobaczmy, którego jest więcej i tak dalej, i tak dalej.

Okej, okej, rozumiem.

Chociaż to pewnie jest dość rzecz specyficzna do firm, które pracują dla kogoś, w sensie dla klientów, a nie dla startupów, bo wyobrażam sobie, że w większości startupów mógłby być i dać duży pushback na coś podobnego.

Mógłby być, ale jak ja rozmawiałem już z kilkoma firmami poza swoją, właśnie takich bardziej startupowych, to według mnie powinny zacząć to robić, bo zawsze powtarza się to samo, że ktoś mówi właśnie albo tracimy pieniądze, albo idzie to wolno, albo ten, i ktoś zadaje pytanie na przykład, ile czasu spędzacie nad tym i jest odpowiedź, no nie wiem, nie?

Robimy rzeczy i to jest to, że jak robimy rzeczy, to nie wiemy nad czym je robimy.

Albo jak ktoś nic nie robi.

Właśnie mi uświadomiłeś, że w tym samym projekcie u nas w miarę bezinwazyjnie zostało wdrożone dosyć szybko logowanie czasu w SAP-ie, ale nie na zasadzie logowania tam, nad czym konkretnie pracuję, tylko bardziej rozkład czasu, tak?

Czyli na przykład, przede wszystkim, i to akurat jest dokładnie odpowiedź na to pytanie, że rozróżnialiśmy czas produkcji, jakby listy feature'ów od czasu, nie wiem, na przykład, jeżeli bug dotyczył feature'a, który jeszcze nie jest wdrożony, no to on się zaliczał do czasu produkcji feature'a.

Albo na przykład splanowanie, jakby było kilka takich kategorii i to było, muszę Ci powiedzieć, tak jak na SAP od razu wszyscy właśnie mieli na początku wątpliwości, co z tego wyjdzie, to nawet w miarę to działało.

Oczywiście dało się nieźle to rozpoznać.

Trochę nam skręciło i wrócimy na główny tor, ale to dokładnie właśnie o to chodzi, nie?

Że wiesz, że to jest, bo to nawiązuje do tego, co Sebastian powiedział i o czym rozmawialiśmy.

Jak mierzyć i jak wiedzieć, bo w tym samym mierzeniu czasu to nie chodzi o to, żeby tam pilnować każdej godziny człowieka, tylko żeby wiedzieć, jakie masz trendy, nie?

Bo masz nagle trend taki, że organizacja zaczyna spędzać więcej czasu na tym, żeby być organizacją niż na dostarczaniem tego, jaka jest wartość, nie?

No i wtedy ktoś musi wejść i powiedzieć, panowie, zaczynamy spędzać połowę czasu nie wiadomo na czym, nie?

Trzeba coś z tym zrobić.

No i to bardziej o to chodzi.

Tutaj nam, wiesz, wchodzi ta standardowa reguła, że żeby coś poprawić, musisz to zmierzyć, tak?

Żeby wiedzieć w ogóle, gdzie masz podunek i tutaj myślę, że płynnie przechodzimy do pytania, które chcieliśmy sobie i wam zadać, czyli wiecie, czy trend spowolnienia da się spowolnić albo nawet odwrócić, tak?

Czyli czy możemy jako liderzy właśnie, jako członkowie zespołów, jako liderzy, jako osoby decyzyjne w firmach ten trend faktycznie opanować, wziąć na warsztat i w takim razie moje pytanie do was jest właśnie jak?

Czyli, no tutaj już mówimy o mierzeniu, więc może przejdę.

To ja sobie wejdę na początek z czymś innym, bo już wskazałem wcześniej, ale mi nie powypełniliście, to teraz to powiem.

Bo pytanie jest, znaczy pierwszy odpowiedź jest tak i zaraz przejdę może do tego, jak tam jakoś można do tego podejść, ale według mnie wzrost tej organizacji jest jedna, taki model, który ja akurat lubię, który czyli wywodzący się gdzieś tam z tych rzeczy dookoła, niektórzy wiedzą, że ja się tym zajmuję, ale Pioneer Settlers Town Planners, nie?

Dlaczego się to sprowadza?

Sprowadza się do tego, że trzeba sobie zdradzać sprawę, że w organizacji nie wszyscy muszą być tak samo szybcy, nie?

Czyli bo Pioneer Settlers Town Planners to jest taki model, który Simon Wardley wypracował z okazji swojego Worldly Mapping.

Worldly Mapping to jest taki podejście do myślenia o strategii value chain itd.

Gdzie jest powiedziane, słuchajcie, w organizacji macie grupę pionierów, którzy po prostu ruszają się szybko, zabijają rośliny, kopią coś tam, umierają i idą nowi pionierzy.

Macie settlersów, którzy po prostu już nie są takimi pionierami, ale jeszcze są generalnie szybko się poruszają, zajmują jakiś teren, kombinują, tworzą nowe rzeczy i na końcu masz town planners.

Ludzie, którzy już po prostu weszli do miasta, budują to miasto według planu, powoli, na lata, nie?

I chyba to jest clou tego, że w zasadzie w organizacji musisz mieć te trzy rzeczy ruszające się różnie.

Tam ten model daje taki fajny mental model, który mówi i one powinny od siebie kraszć.

Czyli ci pionierzy produkują szybko, rozwalają rzeczy, mają inne metryki w ogóle i każda z tych rzeczy ma inne metryki, każda z tych części organizacji, nie?

Czyli to, co Sebastian powiedział, np. pionierzy robią eksperymenty i są mierzeni z success, failure rate tych eksperymentów.

I failure ma być większy niż success, np. setlerzy są mierzeni z tego, jak efektywnie potrafią poprawiać po pionierach, a town planners mają np. takie KPI typowo efektywnościowe, np. velocity, jak już ktoś chce wierzyć.

To taka pierwsza rzecz, którą według mnie warto sobie opowiedzieć i wtedy inaczej się o tym myśli po prostu, bo nie próbujesz zawracać całej organizacji.

To też wynika, bo powiedziałeś, że to wyszło od Wardleya, on to chyba i tak w ogóle jeszcze wziął od kogoś innego, bo ja ten mowy wziąłem u Hoffmana, ale ten mowy chyba wyszedł od Collinsa, czyli jeszcze z lat jakichś osiemdziesiątych, ale ważne jest to, że ten podział on wynika z tego po prostu, że potrzeby organizacji się zmieniają z czasem, czyli gdzieś, gdzie już udało się, nie wiem, wypracować jakiś np. product market fit, gdzie już udało się wypracować pewne ramy, no to potem już tego trzeba pilnować, ta dynamika, która tam jest potrzebna, jest zupełnie inna.

Więc tak, to jest nie do uniknięcia, to ja się jakby z tym zupełnie zmiażdżam.

Wiesz dlaczego ja lubię to podejście i ten model?

Bo to unika, pozwala uniknąć frustracji organizacji.

No bo jak masz organizację, która urosła od dwudziestu do stu pięćdziesięciu osób np., to może być, o Boże, teraz jest inaczej, zwolniliśmy i tak dalej, pojawiają się urban stories, jak to wcześniej było lepiej, a tutaj jest powiedziane, ok, to, że zwalniamy w jakimś stopniu, jest naturalnym cyklem rozwoju organizacji, będzie część ludzi, która będzie się poruszała wolniej, ale musimy się upewnić, że mamy część ludzi, która porusza się szybciej.

Swoją drogą, ja kiedyś nawet trafiłem na taki, to trochę do Wojtka, który często powołuje się na różnego rodzaju psychotesty i tak dalej, ale faktycznie na taki test, który mówi, gdzie ty jesteś jako człowiek na tej skali?

Która jest twoja preferencja?

I takie zestawienie, że jeżeli chcesz mieć dobrze zbalansowaną organizację poruszającą się średnio w miarę ok, to powinieneś sobie zbalansować tak jakby ludzi z ich preferencjami, nie?

Ale wiesz co, to ja się uniknę trochę głębiej, bo to, że niektórzy mogą mieć problemy z rozpoznaniem, że moja część organizacji to już jest na przykład na etapie gdzieś tam tych powiedzmy żandarmów, którzy po prostu pilnują, to to jest jakby pół problemu.

Druga połowa problemu to jest taka, że organizacja czasami musi wykonać ten krok wstecz, czyli na przykład musi się bronić przed jakąś dystrupcją, musi się bronić przed takim ruchem rynkowym i w miejscu, gdzie właśnie było spokojnie, stabilnie i wolno, to tam w tym momencie trzeba wprowadzić trochę inną metodę wprowadzenia na przykład zmian, czy trzeba wprowadzić tych settlersów, tych pionierów i z tym organizacje mają problem.

Nie umieją tego robić, dlatego, że tam już na miejscu nie ma ludzi, którzy pasują do tego mentalnie, a różnego rodzaju modele tak zwanych wewnętrznych startupów w większych organizacjach, one się dosyć świetnie sprawdzały.

No i tutaj wchodzimy w trochę taki temat zachęcający o politykę, bo to jest czy dla kto to zawrócić i dlaczego, bo znaczy zawrócić się da, może niekoniecznie właśnie, dlaczego wszedłem z tym pionierów, townbuilders i settlersów, bo właśnie może nie trzeba zawracać całej organizacji, ale pytanie jest, gdzie jest ten core, który musi na przykład zacząć pracować szybciej albo, znaczy to jest bardzo trudne w ogóle, nie?

Ja szczerze powiem, nawet może miałem jakieś podejście, że chciałem też takiego mieć w firmie, to się nie do końca udało, ale to jest trudne według mnie, jeżeli chodzi o organizację, o wprowadzenie takiego.

Dlaczego?

Bo tutaj zaczynamy, jeżeli organizacja jest skutecznie duża, to zaczynamy niestety, ale wchodzić na podwórka różnych ludzi, którzy mogą po prostu wprowadzać inercję, no bo jeżeli my chcemy przyspieszyć coś, a ktoś jest mierzony jakimś KPI-em i jak sam tego nie lubię, ale życie nauczyło mnie, że niestety tak to działa, to ktoś może nie być zainteresowany przyspieszeniem, nie?

Więc żeby, czy ten trend da się spowolnić, albo zatrzymać, albo nawet odwrócić?

Tak.

Czego to z mojego doświadczenia wymaga?

Mocnego leadership, który po prostu patrzy na to, że chce to zrobić i nie boi się wprowadzenia zmian.

Jaki w tym jest największy według mnie przeszkoda?

No właśnie inercja organizacji przed tym, żeby te zmiany wprowadzać, żeby to poprawić.

Potem zaczyna się bardzo takie tło pod tłem, może będę źle wyglądał, nie?

No nie wiem.

Stąd na samym, właśnie stąd na samym początku jedną z kategorii, którą ja sobie wiesz, wymieniłem, była ta kultura organizacji, bo ona bezpośrednio według mnie bardzo mocno nam będzie wspomagała to spowalnianie lub pozwalała przyspieszyć.

Więc tutaj też stąd moje myślenie też o prawie Conwaya, bo jeżeli mam, tak jak wspomnieliście, tą, Sebastian, twoja druga kategoria organizacji, która wiecie, ja pracowałem na przykład z bankami, które miały 350 lat i dosłownie strasznie się cieszyłem, bo pracowałem z firmą, którą oglądałem na Westernach, to samo logo.

I to jest firma, która od 350 lat buduje swoje procesy.

Tam nie jest łatwo coś zmienić, nie jest łatwo coś udowodnić i też są pewne, pewne od razu wiecie tam, ta kultura i ta inercja, o której ty mówisz, jest bardzo mocno zbudowana w core tej organizacji, więc tego nie jesteśmy w stanie szybko ruszyć.

Teraz pytanie, czy ta firma musi się szybko poruszać i musi się szybko zmieniać?

To jest całkiem inna kwestia.

Moim zdaniem tak, dlatego że jak na każdą firmę gdzieś tam na jakimś etapie czeka tak zwany film, a ono może być tuż za rogiem, może być gdzieś dalej, ale też to wpływa ogólnie mobilizująco na ludzi.

No jeżeli jest taka firma, w której wewnątrz nie ma jakiejś, jakiegoś jakichś zdrowia wewnętrznej presji, to tam kultura się w ogóle rozpieprzy całkowicie.

Ale słuchajcie, bo mamy tylko 7 minut, a tak naprawdę to jest bardzo ważne pytanie, być może najważniejsze pytanie całego tego odcinka.

Jak spowolnić spowolnienie, albo potencjalnie je odwrócić?

To może tak, konkretnie w punktach.

Ja mam parę rzeczy wypisanych.

Dla mnie, może tak zacznę od środka.

To takie wprowadzenie, uwaga, będę bluzgał, kultury wypierdalania.

Nie mam tu na myśli wyrzucania ludzi, tylko po prostu kultury wycinania rzeczy, które są bzdurne, krytykowania rzeczy, które są bzdurne.

Być może nawet wprowadzenie ról, które służą tylko i wyłącznie śledzeniu głupot w organizacji.

Albo wprowadzenia ról, to już parę razy się pojawiło przy naszych odcinkach, w takiej formacie barrejzera, czyli kogoś, kto po prostu kwestionuje, challenge'uje i faktycznie jest w stanie odfiltrować głupie pomysły.

A więc wprowadzenie tego typu kultury, wprowadzenie mechanizmów, które taką kulturę wzmacniają, to uważam, że jest bardzo istotne.

Dalej, trochę tam o tym powiedział Tomek, bo Tomek powiedział trochę o różnych poziomach organizacji i zmianie na różnych poziomach organizacji.

Więc moim zdaniem strong leadership na różnych poziomach organizacji i jeszcze dodatkowo pełne accountability i transparencja, żeby na każdym poziomie faktycznie dało się wprowadzić zmianę w odpowiednim tempie.

I teraz co ważne, to powiedzieliśmy sobie wcześniej trochę na temat the goal, ja bym jeszcze nawet trochę rozwinął, czyli poszedłem w kierunku Reiner Senna i jego the flow, czyli rozumienie tak naprawdę tego, jak dzieje się praca, czyli przepływu w pracy i rozumienie tego, jak to optymalizować i też wprowadzenie bardzo mocnych mechanizmów typu na przykład single-threaded leadership i work in progress limit.

Dlatego, że nasze organizacje, te najwolniejsze, zazwyczaj mają problem właśnie z tym i tu trochę wracam do tej kultury wypierdzielania, że zdają się zbyt wieloma rzeczami.

Ten fokus się strasznie rozbija i na tym cierpie accountability, bo wszyscy mają milion priorytetów, nie do końca jeszcze umieją mierzyć jakieś takie swoje rezultaty w ramach tego, a więc tutaj wprowadzenie takiego mocnego governance'u pracy to bardzo pomaga.

I jeszcze dodatkowo, no ta kultura mierzenia, zaczęliśmy na początku od tego, że jak mierzyć, nie da się zarządzić.

Czyli zastanowienie się dokładnie na tym, co mierzymy, jak mierzymy.

Właśnie, to jest bardzo ważne, czasami powinniśmy po prostu mierzyć trendy, mierzyć komparatywnie, bo nie da się czegoś mierzyć w kategoriach absolutnych.

A więc to są takie bardzo ważne rzeczy, które ja bym dodał.

A w znosie tego Bar-Razera to powiedziałbym, że szczególnie istotne jest trzymanie czegoś takiego w kontekście rekrutacji i też pilnowania tej kultury.

A to jest coś, co zostało absolutnie zaniedbane przez bardzo wiele firm od kilku ostatnich lat, bo wszyscy czuli gigantyczną presję na to, że rynek jest taki, jaki jest, strasznie ciężko jest kogokolwiek dostać, więc koniec końców zaczęły cierpieć standardy.

Ale to bardzo negatywnie wpłynęło na bardzo wiele firm, o czym oczywiście głośno się nie mówi, no bo nikt do tego się przyznać nie chce.

Dobra, ja się trochę zagadałem, a czy Wy też macie jakieś swoje kandydatki?

Dobra, to ja od razu się odniosę i lecę.

Kilka rzeczy, które Ty powiedziałeś, ubrałbym taką grupę, żeby zainwestować w jakość, bo tak naprawdę brak jakości w firmach technologicznych jest chyba jednym z najbardziej, największym takim faktorem technicznym, projektowym z powalniania.

Czyli, że zamiast rozwiązywać właściwe problemy, rozwiązujemy problemy niedopracowania naszych projektów czy naszych rozwiązań w przeszłości.

Drugą część kategorii, którą Ty powiedziałeś, bym zamknął w takim ja bym to powiedział o takim mindful decision making, czyli, że podejmowanie, nauczenie się właściwego podejmowania decyzji.

Mi się bardzo podoba to, co powiedziałeś o Barraizerze.

W naszej prywatnej rozmowie kiedyś nazwałeś to także sparring partnerstwem i to jest coś, co strasznie mi siadło, Sebastian, i tu oczywiście jestem bardzo wdzięczny, bo ja uważam, że w ogóle tego jest bardzo mało i nie doceniamy tego sparring partnera w naszych pomysłach, czyli idea jest taka, jakikolwiek mam pomysł, jakikolwiek mam projekt, jakikolwiek temat na warsztacie, biorę kogoś, kto mi ten temat zboksuje ze mną, tak, żeby faktycznie wyszła z tego najlepsza decyzja.

Ja bym do tego jeszcze dodał, co Ty powiedziałeś, fire drill.

I to jest takie bardzo fajne, praktyczne ćwiczenie, które pomoże nam zidentyfikować jako liderom, gdzie nasze procesy, gdzie nasza technologia, gdzie nasze automatyzacje albo na przykład mierzenie i alerty nie działają.

Czyli zasymulować sobie, umówić się z zespołem, że symulujemy na przykład, nie wiem, tam w zależności od tego, jaka jest charakterystyka firmy, na przykład Black Friday, zakładając nagle trzy razy większy ruch i przygotowujemy się całym zespołem albo nawet robimy już bardzo konkretną symulację.

I właśnie tutaj bym jeszcze odniósł do systems thinking i do książek DevOpsowych, szczególnie do DevOps Headbook, to co tak naprawdę tutaj, to clue tego, o czym my rozmawiamy, to jest identyfikacja największego bottlenecku w naszym procesie i naprawienie jego i później wzięcie kolejnego warsztatu.

Czyli tak naprawdę to jest, Ty wspomniałeś też, Sebastian, to jest też o systems theory, tak naprawdę i theory of constraints, więc te dwie rzeczy na pewno bardzo fajnie omawia DevOps Headbook, który bardzo serdecznie polecam.

Tomek?

Ja nie wiem, czy dodam coś bardziej mądrego, niech moi doświadczeni koledzy z mojego punktu widzenia wierzą, tylko ja przez ostatnie kilka lat bardziej patrzyłem na to właśnie z punktu widzenia organizacji, już to jednak bardzo ważne jest to, żeby na liderstwie organizacji była jednak chęć do zmiany, tak, i żeby to było też egzemplowane, bo jak tego przestanie, jak to przestanie być, ktoś nie będzie przelegał status quo, to się mniej lub bardziej zacznie rozjeżdżać.

Pojawia się chęć zmiany organizacji, ale u ludzi.

Tak, tak, tak.

I faktycznie to, ja to widzę po rozmowach, właśnie to Ty już wspomniałem, po rozmowach z kilkoma firmami, które gdzieś tam poprosiły mnie o jakąś rozmowę, że faktycznie brakuje tego spojrzenia na takiego opartego o dane, bo każdy coś tam czuje, coś tam wie, ale jak nie widać tego na danych, to naprawdę ciężko jest po prostu dyskutować, nie, czy my faktycznie jesteśmy wolniejsi, czy nie, co na to wpływa.

No i tutaj się pojawiają te rzeczy, które powiedzieliście.

No więc widzę, że faktycznie przyszłotygodniowy heads-up odcinek o podejmowaniu decyzji jest dobrym follow-upem do tej całej rozmowy tutaj dzisiaj.

Śmieszny wtręt odnośnie naszej tutaj teorii versus real life.

Najbardziej, najpopularniejsza praktyka odnośnie przyspieszenia organizacji, która wbrew pozorom jest całkiem skuteczna, jest jaka?

Wywalić CTO i wziąć kogoś innego.

Dlaczego?

Dlatego, że w tym momencie, to jest czasami taki reset i jeszcze dołożenie dodatkowej presji i pokazanie w tej presji w widoczny sposób dla całej jeszcze organizacji inżynierskiej.

Widzisz, ale to nie do końca tak, to znaczy akurat, wiesz, mamy naszą firmę x, użyjmy już, która jest x twitterem, gdzie to widać bardzo, ale z drugiej strony właśnie, wiesz, to zależy, jak organizacja się zmienia, bo ja widziałem kilka takich przykładów, no bo pamiętajmy, że jak firma jest już dosyć duża, no to ma zarząd, ma leadership, zarząd, CEO, zarząd i potem jeszcze może być board.

I jeżeli na przykład, wiesz, wymienisz tego CEO, ale wyżej zarząd, board nie ma chęci na zmiany, to szybko go ubiją.

Dlaczego?

Bo niektóre wskaźniki też ma...

Sprowadzanie zmian, przyspieszanie organizacji i tak dalej ma swoje konsekwencje, na przykład jakie, że przez jakiś czas reaktor będzie wyglądał inaczej, nie?

I to trzeba wszystko ustać jako organizacja, bo żeby przyspieszyć, to niestety, ale też może być, że będzie taki okres, gdzie zwolnienie będzie jeszcze większe, nie?

Bo na przykład przestaniemy robić rzeczy.

No dobrze.

Dobrze, słuchajcie, kończymy dokładnie.

Jesteśmy już po dziewiątej trzydzieści.

Słuchajcie, dzięki bardzo dyskusję.

Uważam, że fajnie się rozmawiało.

Dużo ciekawych rzeczy padło.

Oczywiście nie wyczerpaliśmy tematu, bo ja tu jeszcze mam u siebie chyba ze cztery odrębne tygoje całkowicie.

Nawet połowy listy naszych pytań chyba nie przeszliśmy.

Ale to dobrze, ale to dobrze.

W międzyczasie jeszcze takie małe przypomnienie.

Rzucajcie okiem na nasze odcinki City of Morning Brew.

Są już dwa.

Niedługo pojawi się kolejny, bo jest już nagrany, jest już w postprodukcji.

Oprócz tego cóż, zapraszamy na kolejne City of Morning Coffee, które już za dwa tygodnie, na razie jeszcze nie powiemy jaki temat.

Zapraszamy do zapisywania się do naszego newslettera, do naszych subskrypcji.

Wtedy dostajecie informacje na temat kolejnych odcinków i na pewno niczego nie przegapicie.

Słyszymy się już niedługo.

Mam nadzieję, że ciągle na aplikacji czy to Twitter, czy to X. Ale tu różnie może być.

Elona Ruchów nikt nie przewidzi.

Dzięki bardzo.

Dziękuję.

Miłego weekendu wszystkim.

Dzięki.

Miłego weekendu.

Trzymajcie się.