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? 1 000
Bo bez tego to mamy takich właśnie, 1 001
ileś tam atomów, nie? 1 002
Które każdy sobie wykonuje jakieś rzeczy, 1 003
ale overall zaczynamy robić rzeczy wolniej, nie? 1 004
Bo ze względu na synchronizację pomiędzy nimi, 1 005
konflikty i tak dalej, nie? 1 006
Więc mierzenie na poziomie organizacji, 1 007
to co my robiliśmy, no to właśnie mierzyliśmy 1 008
ilość zmian wprowadzonych do systemu jako requesty, 1 009
mierzyliśmy czas i dalej mierzymy 1 010
ile one czekają w backlogu, tak? 1 011
Oprócz tego zbieramy input pod tytułem 1 012
ilu ludzi zgłasza taką potrzebę, 1 013
jakie są metryki, które na to wpływają, 1 014
na podstawie tego podejmujemy decyzję, co robić, 1 015
no i potem jaki jest czas implementacji tego do wdrożenia. 1 016
Tu mi przypomniałeś, muszę kiedyś opisać, 1 017
nie wiem, czy w formie jakiegoś artykułu, 1 018
czy w jakiejś innej, 1 019
ale robiłem dokładnie coś takiego, 1 020
czyli musiałem zaprojektować 1 021
i wdrożyć w organizacji, 1 022
to było akurat w Amazonie. 1 023
To było akurat, może nie to, 1 024
że framework do mierzenia prędkości decyzji, 1 025
tylko bardziej, bo te decyzje były bardziej eksperymentalne, 1 026
czyli bardziej do mierzenia eksperymentów 1 027
i te eksperymenty były bardzo często właśnie 1 028
eksperymentami organizacyjnymi. 1 029
A i teraz rzeczywiście wymyślenie tego, 1 030
jak to mierzyć od początku, 1 031
jakiegoś zaproponowania jakiegoś modelu accountability 1 032
i wysiąganie z tego wniosków 1 033
i też patrzenie, jak ludzie reagują 1 034
w momencie, kiedy poziom transparencji jest naprawdę wysoki, 1 035
to było bardzo ciekawe doświadczenie. 1 036
To też kiedyś muszę opisać, 1 037
ale warto to robić. 1 038
W każdej organizacji warto to robić właśnie. 1 039
Tempo, realizacji, zmian. 1 040
No to taki dłuższy temat. 1 041
Dobrze, słuchajcie, ale... 1 042
Aż, by the way, ograniczać czas na wprowadzenie tych zmian. 1 043
Do tego odcinka o podejmowaniu decyzji też odsyłam, 1 044
bo tam o tym rozmawialiśmy, 1 045
bo wiesz, możesz z jednej strony powiedzieć tempo, 1 046
a z drugiej zmiana musi się zmieścić w X, tak? 1 047
To tak swoją taką szymek. 1 048
Ja bym też zarzucił takie prowokacyjne pytanie. 1 049
Czy może być metryka, która mówi o tym, 1 050
że ilość metryk, które mamy, to już jest za dużo? 1 051
Tak, jak zaczynamy spędzać czas na metrykach, 1 052
na patrzeniu w niej więcej niż ten... 1 053
To się akurat da zmierzyć, bo to jest... 1 054
Może nie wprost, ale wiesz, bo to jest... 1 055
Jeżeli mierzysz czas, my akurat to robiliśmy, 1 056
nad czym ludzie spędzają czas w firmie, 1 057
nie tylko nad, wiesz, zadaniami projektowymi itd., 1 058
to widzisz po jakimś czasie, 1 059
że na przykład rośnie ci czas związany z czymś, nie? 1 060
I potem jest tylko kwestia tego, 1 061
że jeżeli na to patrzysz faktycznie, nie? 1 062
Czyli na przykład rośnie ci czas, 1 063
gdzie ktoś mówi, że analizował coś, nie? 1 064
Jeżeli masz na to kategorię, to jest okej. 1 065
Jeżeli to faktycznie zaczyna być znaczące, 1 066
to podzielenie tego i zajrzenie, 1 067
to dlaczego ludzie nad tym spędzają czas, 1 068
to się da zrobić, 1 069
ale trzeba nad tym po prostu mieć taki jakby fokus, nie? 1 070
Czyli trzeba powiedzieć, 1 071
chcemy wiedzieć, nad czym ludzie spędzają czas 1 072
i reagować, jak zaczynają go spędzać więcej, 1 073
nad rzeczami, które nie kontrybuują do, wiesz, odbioru. 1 074
Powiedziałbyś więcej, jak sobie mierzycie? 1 075
W sensie, to jest kwestia, nie wiem, time-trackingu 1 076
czy bardziej kwestia tasków, 1 077
czy, nie wiem, rzeczy w kalendarzu? 1 078
Tak z ciekawości. 1 079
No to jednak ostatnia rzecz, 1 080
tu mam kilka osób z firmy, 1 081
to mam weryfikację od ręki, 1 082
zaraz mi napiszą, czy mówię dobrze, czy źle. 1 083
Więc to my mieliśmy dość specyficzne podejście do tego, 1 084
bo od początku w firmie po prostu mieliśmy to układane tak, 1 085
że cały czas jest mierzony w taki sposób, 1 086
że kategoryzujesz go na swoim kalendarzu, nie? 1 087
Tylko że kategoryzujesz nie tylko czas, 1 088
który jest spędzony na projektach i tak dalej, 1 089
tylko też na innych rzeczach, nie? 1 090
I zaczynaliśmy od bardzo prostych rzeczy 1 091
pod tytułem to jest czas dla klienta, 1 092
to jest czas dla firmy, nie? 1 093
Ale potem to trochę podzieliliśmy, 1 094
więc wiesz, nagle wiesz dokładnie typu na przykład, 1 095
że ktoś pracuje nad projektem, nad którym projektem, 1 096
potem pracuje nad management, 1 097
nad jaką częścią management, nie? 1 098
I z tego możesz zacząć wyciągać, 1 099
sobie patrzeć i mówisz, 1 100
okej, no to w firmie rośnie overall czas spędzany 1 101
na cod management, no to podzielimy go na dwa 1 102
i zobaczmy, którego jest więcej i tak dalej, i tak dalej. 1 103
Okej, okej, rozumiem. 1 104
Chociaż to pewnie jest dość rzecz specyficzna 1 105
do firm, które pracują dla kogoś, 1 106
w sensie dla klientów, a nie dla startupów, 1 107
bo wyobrażam sobie, że w większości startupów 1 108
mógłby być i dać duży pushback na coś podobnego. 1 109
Mógłby być, ale jak ja rozmawiałem już 1 110
z kilkoma firmami poza swoją, 1 111
właśnie takich bardziej startupowych, 1 112
to według mnie powinny zacząć to robić, 1 113
bo zawsze powtarza się to samo, 1 114
że ktoś mówi właśnie albo tracimy pieniądze, 1 115
albo idzie to wolno, albo ten, 1 116
i ktoś zadaje pytanie na przykład, 1 117
ile czasu spędzacie nad tym 1 118
i jest odpowiedź, no nie wiem, nie? 1 119
Robimy rzeczy i to jest to, 1 120
że jak robimy rzeczy, 1 121
to nie wiemy nad czym je robimy. 1 122
Albo jak ktoś nic nie robi. 1 123
Właśnie mi uświadomiłeś, 1 124
że w tym samym projekcie 1 125
u nas w miarę bezinwazyjnie 1 126
zostało wdrożone dosyć szybko 1 127
logowanie czasu w SAP-ie, 1 128
ale nie na zasadzie logowania tam, 1 129
nad czym konkretnie pracuję, 1 130
tylko bardziej rozkład czasu, tak? 1 131
Czyli na przykład, przede wszystkim, 1 132
i to akurat jest dokładnie odpowiedź 1 133
na to pytanie, 1 134
że rozróżnialiśmy czas produkcji, 1 135
jakby listy feature'ów 1 136
od czasu, nie wiem, na przykład, 1 137
jeżeli bug dotyczył feature'a, 1 138
który jeszcze nie jest wdrożony, 1 139
no to on się zaliczał do czasu 1 140
produkcji feature'a. 1 141
Albo na przykład splanowanie, 1 142
jakby było kilka takich kategorii 1 143
i to było, muszę Ci powiedzieć, 1 144
tak jak na SAP od razu wszyscy właśnie 1 145
mieli na początku wątpliwości, 1 146
co z tego wyjdzie, 1 147
to nawet w miarę to działało. 1 148
Oczywiście dało się nieźle to rozpoznać. 1 149
Trochę nam skręciło 1 150
i wrócimy na główny tor, 1 151
ale to dokładnie właśnie o to chodzi, nie? 1 152
Że wiesz, że to jest, bo to nawiązuje do tego, 1 153
co Sebastian powiedział i o czym rozmawialiśmy. 1 154
Jak mierzyć i jak wiedzieć, bo w tym samym 1 155
mierzeniu czasu to nie chodzi o to, żeby tam pilnować 1 156
każdej godziny człowieka, tylko żeby wiedzieć, 1 157
jakie masz trendy, nie? Bo masz nagle trend taki, 1 158
że organizacja zaczyna spędzać więcej 1 159
czasu na tym, żeby być organizacją 1 160
niż na dostarczaniem tego, 1 161
jaka jest wartość, nie? No i wtedy 1 162
ktoś musi wejść i powiedzieć, panowie, 1 163
zaczynamy spędzać połowę czasu nie wiadomo na czym, nie? 1 164
Trzeba coś z tym zrobić. 1 165
No i to bardziej o to chodzi. 1 166
Tutaj nam, wiesz, wchodzi ta standardowa 1 167
reguła, że żeby coś poprawić, musisz to 1 168
zmierzyć, tak? Żeby wiedzieć w ogóle, 1 169
gdzie masz 1 170
podunek i tutaj myślę, że płynnie 1 171
przechodzimy do pytania, które 1 172
chcieliśmy sobie i wam zadać, 1 173
czyli wiecie, czy trend 1 174
spowolnienia da się spowolnić 1 175
albo nawet odwrócić, tak? 1 176
Czyli czy możemy 1 177
jako liderzy właśnie, 1 178
jako członkowie zespołów, 1 179
jako liderzy, jako osoby 1 180
decyzyjne w firmach 1 181
ten trend 1 182
faktycznie opanować, 1 183
wziąć na warsztat 1 184
i w takim razie 1 185
moje pytanie do was 1 186
jest właśnie jak? Czyli, 1 187
no tutaj już mówimy o mierzeniu, więc 1 188
może przejdę. 1 189
To ja sobie wejdę na początek z czymś innym, bo już 1 190
wskazałem wcześniej, ale mi nie powypełniliście, to teraz 1 191
to powiem. Bo pytanie jest, znaczy 1 192
pierwszy odpowiedź jest tak i zaraz 1 193
przejdę może do tego, jak tam 1 194
jakoś można do tego podejść, ale według mnie 1 195
wzrost tej organizacji 1 196
jest jedna, taki model, który 1 197
ja akurat lubię, który 1 198
czyli wywodzący się gdzieś tam 1 199
z tych rzeczy dookoła, 1 200
niektórzy wiedzą, że ja się tym zajmuję, ale 1 201
Pioneer Settlers Town Planners, nie? 1 202
Dlaczego się to sprowadza? 1 203
Sprowadza się do tego, że trzeba sobie zdradzać sprawę, 1 204
że w organizacji nie wszyscy muszą być tak samo 1 205
szybcy, nie? Czyli bo 1 206
Pioneer Settlers Town Planners to jest taki 1 207
model, który 1 208
Simon Wardley wypracował 1 209
z okazji swojego Worldly Mapping. 1 210
Worldly Mapping to jest taki podejście do myślenia o strategii 1 211
value chain itd. 1 212
Gdzie jest powiedziane, słuchajcie, w organizacji macie 1 213
grupę pionierów, którzy po prostu 1 214
ruszają się szybko, zabijają 1 215
rośliny, kopią coś tam, 1 216
umierają i idą nowi 1 217
pionierzy. Macie settlersów, 1 218
którzy po prostu już nie 1 219
są takimi pionierami, 1 220
ale jeszcze są generalnie 1 221
szybko się poruszają, zajmują jakiś 1 222
teren, kombinują, tworzą 1 223
nowe rzeczy i na końcu masz town planners. 1 224
Ludzie, którzy już po prostu weszli do miasta, 1 225
budują to miasto według planu, powoli, 1 226
na lata, nie? I chyba to 1 227
jest clou tego, że w zasadzie w organizacji 1 228
musisz mieć te trzy rzeczy 1 229
ruszające się różnie. Tam ten 1 230
model daje taki fajny mental model, 1 231
który mówi i one powinny od siebie 1 232
kraszć. Czyli ci pionierzy produkują szybko, 1 233
rozwalają rzeczy, mają inne 1 234
metryki w ogóle i każda z tych rzeczy ma 1 235
inne metryki, każda z tych części organizacji, 1 236
nie? Czyli to, co Sebastian powiedział, 1 237
np. pionierzy robią eksperymenty 1 238
i są mierzeni z success, 1 239
failure rate tych eksperymentów. I failure 1 240
ma być większy niż success, np. 1 241
setlerzy są mierzeni z tego, jak 1 242
efektywnie potrafią poprawiać po pionierach, 1 243
a town planners mają np. takie KPI 1 244
typowo efektywnościowe, 1 245
np. velocity, jak już ktoś chce wierzyć. 1 246
To taka pierwsza rzecz, którą 1 247
według mnie warto sobie opowiedzieć 1 248
i wtedy inaczej się o tym myśli po prostu, 1 249
bo nie próbujesz zawracać całej organizacji. 1 250
To też wynika, bo powiedziałeś, że 1 251
to wyszło od Wardleya, on to chyba 1 252
i tak w ogóle jeszcze wziął od kogoś innego, 1 253
bo ja ten mowy wziąłem u Hoffmana, 1 254
ale ten mowy chyba wyszedł od Collinsa, 1 255
czyli jeszcze z lat jakichś osiemdziesiątych, 1 256
ale ważne jest to, że ten podział 1 257
on wynika z tego po prostu, 1 258
że potrzeby organizacji się zmieniają z czasem, 1 259
czyli gdzieś, gdzie już 1 260
udało się, nie wiem, wypracować 1 261
jakiś np. product market fit, 1 262
gdzie już udało się wypracować pewne ramy, 1 263
no to potem już tego trzeba pilnować, ta dynamika, 1 264
która tam jest potrzebna, jest zupełnie inna. 1 265
Więc tak, to jest nie do uniknięcia, to ja się jakby 1 266
z tym zupełnie zmiażdżam. 1 267
Wiesz dlaczego ja lubię to podejście 1 268
i ten model? Bo to unika, 1 269
pozwala uniknąć frustracji organizacji. 1 270
No bo jak masz organizację, która urosła od 1 271
dwudziestu do stu pięćdziesięciu osób np., 1 272
to może być, o Boże, teraz jest inaczej, 1 273
zwolniliśmy i tak dalej, 1 274
pojawiają się urban stories, jak to wcześniej było lepiej, 1 275
a tutaj jest powiedziane, ok, to, że 1 276
zwalniamy w jakimś stopniu, jest naturalnym 1 277
cyklem rozwoju organizacji, będzie część ludzi, 1 278
która będzie się poruszała wolniej, 1 279
ale musimy się upewnić, że mamy część ludzi, 1 280
która porusza się szybciej. Swoją drogą, ja kiedyś 1 281
nawet trafiłem na taki, to trochę 1 282
do Wojtka, który często 1 283
powołuje się na różnego rodzaju psychotesty 1 284
i tak dalej, ale faktycznie na taki test, 1 285
który mówi, gdzie ty jesteś 1 286
jako człowiek na tej skali? Która jest twoja 1 287
preferencja? I takie 1 288
zestawienie, że jeżeli chcesz mieć dobrze zbalansowaną 1 289
organizację poruszającą się średnio 1 290
w miarę ok, to powinieneś sobie zbalansować 1 291
tak jakby ludzi z ich preferencjami, nie? 1 292
Ale wiesz co, to ja się uniknę trochę głębiej, 1 293
bo to, że niektórzy mogą mieć problemy 1 294
z rozpoznaniem, że moja część organizacji 1 295
to już jest na przykład na etapie gdzieś tam 1 296
tych powiedzmy żandarmów, 1 297
którzy po prostu pilnują, to to jest jakby 1 298
pół problemu. Druga połowa problemu to jest taka, 1 299
że organizacja czasami musi wykonać 1 300
ten krok wstecz, czyli na przykład 1 301
musi się bronić przed jakąś dystrupcją, musi się 1 302
bronić przed takim ruchem rynkowym 1 303
i w miejscu, gdzie właśnie było 1 304
spokojnie, stabilnie i wolno, 1 305
to tam w tym momencie trzeba 1 306
wprowadzić trochę inną 1 307
metodę wprowadzenia na przykład zmian, 1 308
czy trzeba wprowadzić tych settlersów, tych pionierów 1 309
i z tym organizacje mają problem. 1 310
Nie umieją tego robić, dlatego, że tam już 1 311
na miejscu nie ma ludzi, którzy pasują do tego 1 312
mentalnie, a różnego rodzaju 1 313
modele tak zwanych wewnętrznych startupów 1 314
w większych organizacjach, 1 315
one się dosyć świetnie sprawdzały. 1 316
No i tutaj wchodzimy w trochę taki temat 1 317
zachęcający o politykę, bo to jest 1 318
czy dla kto to zawrócić i dlaczego, bo 1 319
znaczy zawrócić się da, może niekoniecznie 1 320
właśnie, dlaczego wszedłem z tym 1 321
pionierów, 1 322
townbuilders i settlersów, bo właśnie 1 323
może nie trzeba 1 324
zawracać całej organizacji, ale 1 325
pytanie jest, gdzie jest ten core, który musi 1 326
na przykład zacząć pracować 1 327
szybciej albo, znaczy 1 328
to jest bardzo trudne w ogóle, nie? Ja 1 329
szczerze powiem, nawet może 1 330
miałem jakieś podejście, że chciałem też takiego mieć w firmie, 1 331
to się nie do końca udało, ale to jest trudne według 1 332
mnie, jeżeli chodzi o organizację, o wprowadzenie 1 333
takiego. Dlaczego? 1 334
Bo tutaj zaczynamy, jeżeli organizacja 1 335
jest skutecznie duża, to zaczynamy niestety, 1 336
ale wchodzić na podwórka 1 337
różnych ludzi, którzy mogą po prostu wprowadzać 1 338
inercję, no bo jeżeli my chcemy 1 339
przyspieszyć coś, a ktoś jest mierzony jakimś 1 340
KPI-em i jak sam 1 341
tego nie lubię, ale życie nauczyło 1 342
mnie, że niestety tak to działa, 1 343
to ktoś może nie być zainteresowany 1 344
przyspieszeniem, nie? 1 345
Więc żeby, czy ten trend 1 346
da się spowolnić, albo zatrzymać, albo 1 347
nawet odwrócić? Tak. Czego to 1 348
z mojego doświadczenia wymaga? Mocnego 1 349
leadership, który po prostu 1 350
patrzy na to, że chce 1 351
to zrobić i nie boi się wprowadzenia 1 352
zmian. Jaki w tym jest największy 1 353
według mnie przeszkoda? No właśnie 1 354
inercja organizacji przed tym, żeby te zmiany 1 355
wprowadzać, żeby to poprawić. Potem zaczyna się 1 356
bardzo takie tło pod 1 357
tłem, może będę źle wyglądał, nie? 1 358
No nie wiem. 1 359
Stąd na samym, właśnie stąd na samym 1 360
początku jedną z kategorii, którą ja sobie 1 361
wiesz, wymieniłem, 1 362
była ta kultura organizacji, bo ona 1 363
bezpośrednio według mnie bardzo mocno 1 364
nam będzie 1 365
wspomagała to spowalnianie lub 1 366
pozwalała przyspieszyć. Więc tutaj też 1 367
stąd moje myślenie też o prawie 1 368
Conwaya, bo jeżeli mam, 1 369
tak jak wspomnieliście, tą, Sebastian, 1 370
twoja druga kategoria organizacji, która 1 371
wiecie, ja pracowałem na przykład z bankami, które 1 372
miały 350 lat i dosłownie 1 373
strasznie 1 374
się cieszyłem, bo 1 375
pracowałem z firmą, którą oglądałem na 1 376
Westernach, to samo logo. 1 377
I to jest firma, która od 1 378
350 lat buduje 1 379
swoje procesy. Tam 1 380
nie jest łatwo coś zmienić, nie jest łatwo 1 381
coś udowodnić i też 1 382
są pewne, pewne od razu 1 383
wiecie tam, ta kultura 1 384
i ta inercja, o której ty mówisz, 1 385
jest bardzo mocno zbudowana 1 386
w core tej organizacji, więc tego nie 1 387
jesteśmy w stanie szybko ruszyć. Teraz pytanie, 1 388
czy ta firma musi się szybko poruszać 1 389
i musi się szybko zmieniać? To jest całkiem 1 390
inna kwestia. 1 391
Moim zdaniem tak, dlatego że jak na każdą firmę gdzieś tam 1 392
na jakimś etapie czeka tak zwany 1 393
film, a ono może być tuż za 1 394
rogiem, może być gdzieś dalej, ale też 1 395
to wpływa ogólnie mobilizująco 1 396
na ludzi. No jeżeli jest taka firma, w której 1 397
wewnątrz nie ma jakiejś, jakiegoś 1 398
jakichś zdrowia wewnętrznej presji, 1 399
to tam kultura się w ogóle rozpieprzy całkowicie. 1 400
Ale słuchajcie, bo mamy tylko 7 minut, 1 401
a tak naprawdę to jest bardzo ważne pytanie, 1 402
być może najważniejsze pytanie całego tego odcinka. 1 403
Jak spowolnić spowolnienie, 1 404
albo potencjalnie je odwrócić? To może tak, 1 405
konkretnie w punktach. Ja mam parę rzeczy 1 406
wypisanych. Dla mnie, może 1 407
tak zacznę od środka. To takie 1 408
wprowadzenie, uwaga, będę bluzgał, kultury 1 409
wypierdalania. Nie mam tu na myśli 1 410
wyrzucania ludzi, tylko po prostu 1 411
kultury wycinania rzeczy, które są bzdurne, 1 412
krytykowania rzeczy, które są bzdurne. 1 413
Być może nawet wprowadzenie 1 414
ról, które służą tylko i wyłącznie 1 415
śledzeniu głupot w organizacji. 1 416
Albo wprowadzenia 1 417
ról, to już parę razy się pojawiło 1 418
przy naszych odcinkach, w takiej 1 419
formacie barrejzera, 1 420
czyli kogoś, kto po prostu kwestionuje, 1 421
challenge'uje i faktycznie 1 422
jest w stanie odfiltrować głupie 1 423
pomysły. A więc wprowadzenie 1 424
tego typu kultury, wprowadzenie mechanizmów, które 1 425
taką kulturę 1 426
wzmacniają, to uważam, że jest bardzo istotne. 1 427
Dalej, trochę tam o tym powiedział 1 428
Tomek, bo Tomek powiedział trochę o różnych 1 429
poziomach organizacji i zmianie na różnych poziomach organizacji. 1 430
Więc moim zdaniem strong leadership 1 431
na różnych poziomach organizacji i jeszcze 1 432
dodatkowo pełne accountability i transparencja, 1 433
żeby na każdym poziomie faktycznie dało się 1 434
wprowadzić zmianę w odpowiednim 1 435
tempie. I teraz co ważne, 1 436
to powiedzieliśmy sobie 1 437
wcześniej trochę na temat 1 438
the goal, ja bym jeszcze nawet trochę rozwinął, 1 439
czyli poszedłem w kierunku Reiner Senna 1 440
i jego the flow, czyli rozumienie 1 441
tak naprawdę tego, jak 1 442
dzieje się praca, czyli 1 443
przepływu w pracy i rozumienie 1 444
tego, jak to optymalizować i też 1 445
wprowadzenie bardzo mocnych mechanizmów 1 446
typu na przykład single-threaded leadership 1 447
i work in progress limit. 1 448
Dlatego, że nasze organizacje, te 1 449
najwolniejsze, zazwyczaj mają problem właśnie z tym 1 450
i tu trochę wracam do tej kultury wypierdzielania, 1 451
że zdają się 1 452
zbyt wieloma rzeczami. Ten fokus się 1 453
strasznie rozbija i 1 454
na tym cierpie accountability, bo wszyscy 1 455
mają milion priorytetów, nie do końca 1 456
jeszcze umieją mierzyć jakieś takie 1 457
swoje rezultaty w ramach tego, a więc 1 458
tutaj wprowadzenie takiego mocnego governance'u 1 459
pracy to bardzo pomaga. 1 460
I jeszcze dodatkowo, 1 461
no ta kultura mierzenia, 1 462
zaczęliśmy na początku od tego, że jak 1 463
mierzyć, nie da się zarządzić. Czyli 1 464
zastanowienie się dokładnie na tym, co mierzymy, 1 465
jak mierzymy. Właśnie, to jest bardzo ważne, 1 466
czasami powinniśmy po prostu mierzyć trendy, mierzyć 1 467
komparatywnie, bo nie da się czegoś mierzyć w kategoriach 1 468
absolutnych. A więc 1 469
to są takie bardzo ważne rzeczy, które ja bym 1 470
dodał. A w znosie tego 1 471
Bar-Razera to powiedziałbym, że 1 472
szczególnie istotne jest 1 473
trzymanie czegoś takiego 1 474
w kontekście rekrutacji 1 475
i też pilnowania tej kultury. 1 476
A to jest coś, co zostało absolutnie 1 477
zaniedbane przez bardzo wiele firm 1 478
od kilku ostatnich lat, bo wszyscy czuli 1 479
gigantyczną presję na to, że 1 480
rynek jest taki, jaki jest, strasznie ciężko jest kogokolwiek 1 481
dostać, więc koniec końców zaczęły cierpieć standardy. 1 482
Ale to bardzo 1 483
negatywnie wpłynęło na bardzo wiele firm, 1 484
o czym oczywiście głośno się nie mówi, no bo 1 485
nikt do tego się przyznać nie chce. 1 486
Dobra, ja się trochę zagadałem, a czy 1 487
Wy też macie jakieś swoje kandydatki? 1 488
Dobra, to ja od razu się odniosę i 1 489
lecę. Kilka rzeczy, które 1 490
Ty powiedziałeś, ubrałbym 1 491
taką grupę, żeby zainwestować w jakość, 1 492
bo tak naprawdę 1 493
brak jakości w firmach 1 494
technologicznych jest chyba jednym 1 495
z najbardziej, największym takim faktorem 1 496
technicznym, projektowym z powalniania. 1 497
Czyli, że zamiast 1 498
rozwiązywać właściwe problemy, 1 499
rozwiązujemy problemy 1 500
niedopracowania naszych 1 501
projektów czy naszych rozwiązań w przeszłości. 1 502
Drugą 1 503
część kategorii, którą Ty 1 504
powiedziałeś, bym zamknął w takim 1 505
ja bym to powiedział o takim 1 506
mindful decision making, czyli, że 1 507
podejmowanie, nauczenie 1 508
się właściwego podejmowania decyzji. 1 509
Mi się bardzo podoba to, co powiedziałeś o 1 510
Barraizerze. W naszej prywatnej 1 511
rozmowie kiedyś 1 512
nazwałeś to także sparring 1 513
partnerstwem i to jest coś, co 1 514
strasznie mi siadło, Sebastian, i tu 1 515
oczywiście jestem bardzo wdzięczny, bo ja uważam, 1 516
że w ogóle tego jest bardzo 1 517
mało i nie doceniamy 1 518
tego sparring 1 519
partnera w naszych pomysłach, 1 520
czyli idea jest taka, jakikolwiek mam 1 521
pomysł, jakikolwiek mam 1 522
projekt, jakikolwiek 1 523
temat na warsztacie, 1 524
biorę kogoś, kto mi ten temat zboksuje 1 525
ze mną, tak, żeby faktycznie wyszła 1 526
z tego najlepsza decyzja. Ja bym 1 527
do tego jeszcze dodał, co 1 528
Ty powiedziałeś, 1 529
fire drill. I to jest takie bardzo 1 530
fajne, praktyczne 1 531
ćwiczenie, które 1 532
pomoże nam zidentyfikować jako liderom, 1 533
gdzie nasze 1 534
procesy, gdzie nasza technologia, 1 535
gdzie nasze 1 536
automatyzacje albo na przykład 1 537
mierzenie i alerty nie działają. 1 538
Czyli zasymulować sobie, 1 539
umówić się z zespołem, że symulujemy 1 540
na przykład, nie wiem, tam w zależności 1 541
od tego, jaka jest charakterystyka firmy, na przykład 1 542
Black Friday, zakładając nagle 1 543
trzy razy większy ruch 1 544
i przygotowujemy się całym 1 545
zespołem albo nawet robimy 1 546
już bardzo konkretną 1 547
symulację. I właśnie 1 548
tutaj bym jeszcze odniósł do 1 549
systems thinking i do książek 1 550
DevOpsowych, szczególnie do DevOps Headbook, 1 551
to co tak naprawdę 1 552
tutaj, to clue tego, 1 553
o czym my rozmawiamy, to jest 1 554
identyfikacja największego bottlenecku 1 555
w naszym procesie i 1 556
naprawienie jego i później 1 557
wzięcie kolejnego warsztatu. Czyli tak naprawdę 1 558
to jest, Ty wspomniałeś też, 1 559
Sebastian, to jest też o 1 560
systems theory, tak naprawdę i theory 1 561
of constraints, więc 1 562
te dwie rzeczy na pewno bardzo 1 563
fajnie omawia DevOps Headbook, 1 564
który bardzo serdecznie polecam. Tomek? 1 565
Ja nie wiem, czy dodam coś 1 566
bardziej mądrego, niech moi doświadczeni 1 567
koledzy z mojego punktu widzenia 1 568
wierzą, tylko ja przez ostatnie 1 569
kilka lat bardziej patrzyłem na to właśnie z punktu 1 570
widzenia organizacji, już to jednak bardzo 1 571
ważne jest to, żeby 1 572
na liderstwie 1 573
organizacji była jednak 1 574
chęć do zmiany, tak, i 1 575
żeby to było też egzemplowane, 1 576
bo jak tego przestanie, 1 577
jak to przestanie być, ktoś nie będzie 1 578
przelegał status quo, to się mniej lub bardziej 1 579
zacznie rozjeżdżać. 1 580
Pojawia się chęć zmiany organizacji, 1 581
ale u ludzi. Tak, tak, tak. 1 582
I faktycznie to, 1 583
ja to widzę po rozmowach, 1 584
właśnie to Ty już wspomniałem, po rozmowach 1 585
z kilkoma firmami, 1 586
które gdzieś tam poprosiły mnie o jakąś 1 587
rozmowę, że faktycznie 1 588
brakuje tego spojrzenia na takiego 1 589
opartego o dane, bo każdy coś tam czuje, 1 590
coś tam wie, ale jak nie widać tego 1 591
na danych, to naprawdę ciężko jest po prostu 1 592
dyskutować, nie, czy my faktycznie jesteśmy wolniejsi, 1 593
czy nie, co na to wpływa. No i tutaj 1 594
się pojawiają te rzeczy, które powiedzieliście. 1 595
No więc widzę, że faktycznie przyszłotygodniowy 1 596
heads-up odcinek o podejmowaniu 1 597
decyzji jest dobrym follow-upem do tej 1 598
całej rozmowy tutaj dzisiaj. 1 599
Śmieszny wtręt odnośnie 1 600
naszej tutaj teorii versus real life. 1 601
Najbardziej, najpopularniejsza 1 602
praktyka odnośnie przyspieszenia organizacji, 1 603
która wbrew pozorom jest całkiem 1 604
skuteczna, jest jaka? Wywalić CTO 1 605
i wziąć kogoś innego. 1 606
Dlaczego? Dlatego, że w tym 1 607
momencie, to jest czasami taki reset 1 608
i jeszcze dołożenie dodatkowej 1 609
presji i pokazanie w tej 1 610
presji w widoczny sposób dla całej 1 611
jeszcze organizacji inżynierskiej. 1 612
Widzisz, ale to nie do końca tak, 1 613
to znaczy akurat, wiesz, mamy 1 614
naszą firmę x, użyjmy już, 1 615
która jest x twitterem, 1 616
gdzie to widać bardzo, 1 617
ale z drugiej strony właśnie, wiesz, to zależy, 1 618
jak organizacja się zmienia, bo ja widziałem kilka takich 1 619
przykładów, no bo pamiętajmy, że jak 1 620
firma jest już dosyć duża, 1 621
no to ma zarząd, 1 622
ma leadership, zarząd, 1 623
CEO, 1 624
zarząd i potem jeszcze może być board. 1 625
I jeżeli na przykład, wiesz, 1 626
wymienisz tego CEO, ale wyżej 1 627
zarząd, board nie ma chęci na zmiany, 1 628
to szybko go ubiją. Dlaczego? Bo niektóre 1 629
wskaźniki też ma... 1 630
Sprowadzanie zmian, przyspieszanie organizacji 1 631
i tak dalej ma swoje konsekwencje, na przykład jakie, 1 632
że przez jakiś czas reaktor będzie wyglądał 1 633
inaczej, nie? I to trzeba wszystko ustać 1 634
jako organizacja, bo 1 635
żeby przyspieszyć, to niestety, 1 636
ale też może być, że będzie taki okres, gdzie zwolnienie 1 637
będzie jeszcze większe, nie? Bo na przykład przestaniemy 1 638
robić rzeczy. No dobrze. 1 639
Dobrze, słuchajcie, kończymy dokładnie. Jesteśmy już 1 640
po dziewiątej trzydzieści. Słuchajcie, dzięki bardzo 1 641
dyskusję. Uważam, że fajnie się rozmawiało. 1 642
Dużo ciekawych rzeczy padło. Oczywiście 1 643
nie wyczerpaliśmy tematu, bo ja tu jeszcze 1 644
mam u siebie chyba ze cztery odrębne 1 645
tygoje całkowicie. Nawet połowy listy 1 646
naszych pytań chyba nie przeszliśmy. 1 647
Ale to dobrze, ale to dobrze. 1 648
W międzyczasie jeszcze takie małe przypomnienie. 1 649
Rzucajcie okiem na nasze odcinki 1 650
City of Morning Brew. Są już dwa. 1 651
Niedługo pojawi się kolejny, 1 652
bo jest już nagrany, jest już w postprodukcji. 1 653
Oprócz tego 1 654
cóż, zapraszamy na kolejne 1 655
City of Morning Coffee, które już 1 656
za dwa tygodnie, na razie jeszcze nie powiemy jaki temat. 1 657
Zapraszamy do zapisywania się 1 658
do naszego newslettera, 1 659
do naszych subskrypcji. Wtedy dostajecie 1 660
informacje na temat kolejnych odcinków 1 661
i na pewno niczego nie przegapicie. 1 662
Słyszymy się już niedługo. Mam nadzieję, że ciągle 1 663
na aplikacji czy to Twitter, czy to X. 1 664
Ale tu różnie może być. 1 665
Elona Ruchów nikt nie przewidzi. Dzięki bardzo. 1 666
Dziękuję. Miłego weekendu wszystkim. 1 667
Dzięki. Miłego weekendu. Trzymajcie się.