Holakracja w software house

Tomasz Dziurko

27 Jul 2021.8 minutes read

Holakracja w software house

ciąg dalszy wywiadu z Tomkiem Dziurko, VP of Engineering SoftwareMill

czytaj część pierwszą

O tym, jak podejmowane są decyzje w SoftwareMill, jak działają cechy i dlaczego firma zdecydowała się na swoją wersję holakracji z Tomkiem Dziurko rozmawia Kamila Stępniowska.

Kamila Stępniowska (KS): Im bliżej zaczęłam poznawać SoftwareMill, tym bardziej pod względem kultury organizacji zaczął mi się kojarzyć ze Spotify. Z tego, co wiem, nie czerpaliście inspiracji z tej strony, natomiast pewnego rodzaju świeżą inspiracją jest dla Was Netflix. W jednym z wewnętrznych klubów czytelniczych omawialiście „No Rules Rules: Netflix and the Culture of Reinvention” Reeda Hastingsa. Czy myślicie o wdrożeniu którychś z proponowanych w niej rozwiązań organizacyjnych?

Tomasz Dziurko (TD): Planujemy. To, co nam się bardzo spodobało, to duży nacisk na kulturę feedbacku — bardzo szczerej, częstej informacji zwrotnej, skupionej na tym, co można robić lepiej. Książka szeroko opisuje system dawania feedbacku oraz sposoby jego przekazywania, żeby był on konstruktywny i nie odbierany jako atak personalny. W SoftwareMill działamy na podobnych zasadach, jednak po lekturze widzimy, że możemy to robić jeszcze lepiej. Zdajemy sobie sprawę, że dawanie feedbacku i odbieranie go to kulturowo ciężki temat. Dlatego zakładam, że małymi krokami dojdziemy do podobnego miejsca w jakim jest Netflix, czyli dawania feedbacku jak najczęściej. Taki feedback “na świeżo” jest dużo bardziej efektywny, bo obie strony mają jeszcze w głowach całą sytuację i łatwiej jest się porozumieć.

KS: Wydaje się, że SoftwareMill jest firmą bardzo otwartą na wewnętrzną dyskusję. Nie macie działów, tylko tak zwane cechy. Rozumiem, że to o wiele więcej niż różnica w nazewnictwie.

TD: Kiedyś SoftwareMill był płaską firmą, czyli każdy mógł się wypowiedzieć w każdym obszarze. W momencie kiedy była do podjęcia jakaś decyzja, każdego pytaliśmy o zdanie, wspólne decyzje podejmowaliśmy drogą ogólnofirmowego głosowania. I to było fajne. Ten sposób sprawdzał się u nas do momentu, kiedy urośliśmy do około 40 osób. Wtedy okazało się, wszystkich decyzji nie da się podejmować wspólnie. Część osób nie ma wiedzy ani kontekstu, żeby świadomie zagłosować za lub przeciw jakiejś opcji. Uznaliśmy więc, że trzeba trochę te grupy kompetencyjne zawęzić do osób, które naprawdę chcą w danym obszarze się udzielać, są zainteresowane tym, co się w nim dzieje i znają dany kawałek działalności firmy. Wprowadziliśmy holakrację, a przynajmniej od tego wyszliśmy.

W SoftwareMill, tak jak wspomniałaś, mamy Cechy — każdy obszar działania firmy ma swój cech. Ma też swojego mistrza cechu, który koordynuje działania, żeby te rzeczy, które mają się dziać rzeczywiście się działy. Teraz wiele mniejszych decyzji dotyczących konkretnego obszaru działania firmy zapada w cechach. Decyzje są podejmowane przez osoby, które mają wiedzę, kontekst i świadomość, jakie są ryzyka, konsekwencje, cele biznesowe oraz powody określonego działania. Co ważne, do cechu może przynależeć każdy — trzeba wyrazić chęć i też trochę świadomie zdecydować „Ok, interesuje mnie dany obszar działania firmy, więc chcę się tym zajmować, chcę i mam czas, żeby ten temat śledzić”.

Nie zrezygnowaliśmy do końca z płaskiej struktury. Nadal decyzje, które mają wpływ na całą firmę, podejmujemy przez głosowanie wszystkich osób. Tutaj trzymamy się wartości, na których wyrósł SoftwareMill, że każdy z nas może dodać swoją cegiełkę i tworzyć to jak wygląda firma.

zdjęcie: zespół SoftwareMill na pierwszej ogólnofirmowej integracji po lockdownowej przerwie

KS: Brzmi, jakbyście w firmie kładli duży nacisk na autonomię i samodzielność.

TD: Od początku celem założycieli było, żeby firma była samoorganizująca się. SoftwareMill założyli programiści, którzy chcieli programować i równolegle prowadzić firmę. Dlatego do pomocy potrzebowali ludzi, którzy chcą aktywnie angażować się w pracę nie tylko projektową i tę firmę współtworzyć. Aby móc funkcjonować w takich warunkach musimy sobie nawzajem ufać. Bez zaufania trudno o transparentność, bez której z kolei nie ma dostępu do wiedzy potrzebnej do podejmowania dobrych decyzji.

Jeśli mała grupa, na przykład zespół projektowy, ma wszystkie informacje potrzebne do podjęcia decyzji to może taką decyzję podjąć sama. Nie dotyczy to oczywiście sytuacji, gdy w grę wchodzi na przykład ryzyko finansowe lub strategiczny obszar działania całej firmy. Ale w większości przypadków, autonomia, samodzielność zespołów ma u nas sens. Główną tego zaletą jest to, że decyzje zapadają szybciej i są podejmowane przez osoby, które mają najlepszą wiedzę.

W skrajnym przypadku to zespół może podjąć decyzję o zakończeniu współpracy z klientem, mimo że płaci on regularnie i z finansowego punktu widzenia wszystko jest OK. Jeżeli zespół uzna, że sposób współpracy w projekcie nie jest dla nas akceptowalny, a próby naprawy tej sytuacji nie przynoszą skutków, to mogą powiedzieć: „Bardzo trudno się nam z tym klientem współpracuje, próby uzdrowienia sytuacji nic nie pomogły, więc chcemy zakończyć ten projekt”. Wtedy my, jako firma, taki projekt kończymy. I to jest decyzja zespołu. Takie decyzje nie są podejmowane pochopnie. Wcześniej zespół sygnalizuje problem na forum firmy i pyta o radę. Wtedy inne osoby w SoftwareMill, które mają doświadczenie we współpracy z trudnymi klientami starają się przyjść z pomocą i zaproponować kilka pomysłów na rozwiązanie impasu.

KS: Wow! To jest naprawdę bardzo duża autonomia i bardzo duże zaufanie do zespołu. To trochę jakby prowadzić własny startup w firmie, coś takiego.

TD: Decyzja o zakończeniu projektu nigdy nie jest prosta, ale taka autonomia jest możliwa dzięki temu, że działamy transparentnie. Wszyscy u nas wiedzą, jak wygląda sytuacja finansowa firmy, jakie projekty się niedługo kończą, czy i ilu klientów czeka na dostępny zespół z naszej strony. To umożliwia oddolne podejmowanie lepszych decyzji, bo zespoły mają kontekst i od klienta, i od firmy.

KS: To trochę jak w Spotify. Tam jeżeli ktoś potrzebował jakiegoś sprzętu komputerowego, to w biurach (jeszcze jak funkcjonowały normalnie biura), były ogólnodostępne półki ze sprzętem. Można było wziąć na przykład myszkę, monitor czy nawet laptop. Te przedmioty miały napisane ceny, ale to nie chodziło o to, że pracownik za to płacił, tylko po prostu żeby w momencie, w którym bierzesz tego laptopa z półki, żebyś wiedział/a, jaki to jest koszt dla firmy. Ale nikt nie musiał zatwierdzać tego, że bierzesz danego laptopa czy myszkę. Czyli też bardzo duża transparentność i bardzo duże zaufanie.

TD: U nas drobne rzeczy, za 500-1000 złotych, ludzie kupują sami i potem firma im zwraca koszt. Dajmy na to, że potrzebujesz myszki albo słuchawek — nie ma problemu, kup sobie. Jak masz wątpliwości czy to dobry pomysł, to zapytaj kolegę z zespołu. W czasie rekrutacji często mówię, że jak chcesz sobie kupić pozłacaną myszkę i nie jesteś przekonany, no to pytasz kolegi: „Słuchaj, jest taka pozłacana myszka, z nią będzie mi się naprawdę super pracowało, czy to dobry pomysł?”. No i jeżeli kolega uzna, że spoko, to kupujesz taką myszkę :)

Eskalowanie drobnych decyzji wyżej sprawia, że kupienie czegoś jest droższe. Tak samo dyskusja w dwadzieścia osób na temat czy wydać na coś 200 czy 500 złotych powoduje, że sama decyzja kosztuje 10 razy więcej. Nawet jeśli zaoszczędziliśmy te 300 złotych, bo kupimy coś tańszego, to sumarycznie tracimy, więc to jest tak naprawdę bez sensu.

Jeżeli chodzi o droższe zakupy sprzętowe, to zgłaszamy to do administracji i tam organizują zakup. Nie oszczędzamy na sprzęcie, staramy się kupować mocniejsze modele komputerów. Ze słabszymi jest potem problem, bo po roku/dwóch nikt nie chce ich używać, bo nie są wystarczające nawet dla osób, które nie programują.

KS: W takim wypadku tym bardziej ta niepisana zasada, że trochę trudniej się do was dostać wydaje się sensowna, bo w momencie, w którym już jest się w organizacji, można korzystać z wolności i z tych wszystkich dobrodziejstw. Pewnie ma to wpływ na to, że tak wiele osób zostaje na dłużej.

TD: W tej chwili mamy 25 osób, które są w SoftwareMill co najmniej 4 lata. Cieszy to, że wiele osób widzi tutaj miejsce dla siebie przez dłużej niż rok czy dwa. Może dlatego że tu po prostu jest fajnie.

Sporo jest też u nas osób, które były wcześniej w dużych firmach. Zobaczyły ile jest tam organizacyjnego narzutu, procedur, które ktoś gdzieś kiedyś wymyślił i potem nie bardzo ktokolwiek ma siłę przebicia, żeby to zmienić. W SoftwareMill ludzie doceniają brak tego co my nazywamy „corporate goodies”. Jeśli widzimy, że jest coś, co nam przeszkadza w efektywnej pracy, to po pierwsze myślimy czy na pewno jest to niezbędne, a jeśli tak, to czy da się zautomatyzować. Z reguły okazuje się, że można to co najmniej znacznie uprościć, jeśli nie wyeliminować. Moim zdaniem jednym z najbardziej frustrujących elementów pracy jest świadomość, że masz do zrobienia coś kreatywnego i ważnego, ale musisz się oderwać, żeby zająć się papierologią albo formalnościami. W SoftwareMill na szczęście tego nie ma.

KS: To tak na koniec, podchodząc do tematu zatrudnienia od drugiej strony. Jakie cechy ma w Twoich oczach dobry senior?

TD: Z mojej perspektywy, kiedy przeglądam CV bardziej doświadczonych osób, to poza technicznymi umiejętnościami zwracam uwagę na informacje, w czym dana osoba pomogła klientowi. Jakie było business value w danym projekcie. Na przykład opis, że razem z zespołem zmienił architekturę, dzięki czemu system był w stanie obsługiwać dużo więcej requestów od klientów. Inna osoba podaje, że zmienili sposób wdrażania aplikacji, dzięki czemu czas, gdy aplikacja nie działa, spadł o X procent. Zmiany mogą być nie tylko techniczne, można również pomóc klientowi zmniejszyć ilość błędów poprzez wprowadzenie usprawnień w procesie wytwarzania oprogramowania. A jeśli senior dostrzega takie sprawy to nie jest tylko koderem, ale zaczyna być partnerem dla klienta czy biznesu.

Biznes nie potrzebuje tylko kodu w małych, świetnie podzielonych klasach i pokrycia testów na poziomie 90% — potrzebuje, żeby dany system działał szybko, był niezawodny i spełniał swoje funkcje. Pokrycie testami czy super podział na klasy to jest dla klienta droga, a nie cel sam w sobie. Jeżeli programista to rozumie, to jest trochę wyższy poziom niż koder, który dostaje zadanie ze sprintu, robi je i bierze kolejne bez większej refleksji.

Do SoftwareMill szukamy programistów biznesowo świadomych. Wtedy zespoły dużo lepiej funkcjonują, a klienci dużo bardziej wolą pracować z ludźmi, którzy rozumieją zarówno kod jak i biznes, który za ten kod płaci. Taki programista zada kilka trudnych pytań, spróbuje lepiej zrozumieć daną domenę i dzięki temu może się okazać, że jakiś pomysł klienta jest zły, albo do zadania należy podejść zupełnie od innej strony niż pierwotnie planowano. Inaczej należy podchodzić do funkcjonalności, które pełnią poboczną rolę w biznesie klienta, a inaczej do elementów procesu, który jest odpowiedzialny za 90% przychodów jego firmy. Taka świadomość, moim zdaniem, cechuje dobrego seniora.

KS: Brzmi sensownie. Zarówno ze strony pracownika, jak i klienta. Tomku, dzięki za rozmowę i trzymam kciuki za dalszy rozwój SoftwareMill!

Nota: Kamila Stępniowska współpracuje z SoftwareMill w ramach Ginger Tech.

Chcesz poznać lepiej nasz zespół? Obejrzyj video i zobacz jak to jest być częścią #SoftwareMillVibes ;) Albo… dołącz do nas!

Blog Comments powered by Disqus.