Rezygnacja z pracy nigdy nie była łatwiejsza niż w przypadku remote. Nie musisz przekonywać swojej drugiej połowy do przeprowadzki do innego miasta, a nawet kontynentu. Nie musisz przekonywać jej do zmiany pracy, a nawet rezygnacji z całej kariery. Nie musisz wyrywać dzieci z ich komfortowego środowiska, szkoły i pierwszych przyjaciół w życiu.

Zmiana remote staje się tak prosta, jak zmiana obszaru roboczego Slack.

Czy po pierwszym przeczytaniu brzmi to dla Ciebie przerażająco? Jeśli tak, to prawdopodobnie jesteś, podobnie jak ja, założycielem lub liderem remote . Ale powiem Ci coś – to najlepsza rzecz, jaka może spotkać Twoją firmę:

Im niższa bariera rezygnacji z pracy, tym większa motywacja liderów do tworzenia doskonałego miejsca pracy dla wszystkich. A doskonałe miejsce pracy często przekłada się na prosperujący biznes. Jest to sytuacja korzystna dla wszystkich.

Aby określić zasady przewodnie pozwalające zbudować dobrze prosperującą remote , przyjrzyjmy się formie organizacyjnej, w której granice odejścia lub rezygnacji są dosłownie zerowe, miejscu, w którym Twój wkład jest w wielu przypadkach widoczny nawet bez bezpośredniej interakcji na żywo z innymi członkami społeczności: społeczności open source.

Każdego dnia miliony osób zaangażowanych w projekty open source (OS) poświęcają znaczną część swojego czasu na pracę nad projektami, nie spotykając się nawet z innymi członkami społeczności. Czy to szaleństwo? Nie, wcale nie. Być może siedzą tuż obok Ciebie w biurze coworkingowym, chętnie rozmawiają i chodzą razem na lunch.

Uważam, że społeczność Open Source Software (OSS) dostarcza remote wielu interesujących spostrzeżeń na temat tego, jak stworzyć sprzyjające środowisko remote . Oto, co szczególnie mnie zainspirowało:

1. Wysoki poziom dopasowania do misji jest kluczowy dla remote

Nie wyobrażam sobie struktury organizacyjnej, w której indywidualni współpracownicy i długoterminowa misja projektu byłyby lepiej dopasowane niż w OSS. Współpracownicy Open Source dołączają (zatrudniają się) do społeczności poprzez aktywny wkład, bez żadnych początkowych zachęt poza swoją pasją do większego celu projektu i perspektywą bycia częścią społeczności o podobnych poglądach, skupionej wokół niego. Najbliższym odpowiednikiem takiego poziomu dopasowania między zatrudnieniem a misją w tradycyjnej firmie byłoby zatrudnianie wyłącznie naszych najbardziej entuzjastycznych klientów. Bardzo trudno jest to osiągnąć na dużą skalę. Jednak, zwłaszcza w remote , jasne dopasowanie do misji jest niepodważalne. Aby przyciągnąć talenty, które są w wysokim stopniu zgodne z naszą misją, remote muszą myśleć bardziej jak projekty OSS: publikować i rozpowszechniać treści dotyczące swojej misji, klientów, kultury i zespołu, aby dać kandydatom przejrzysty obraz firmy. Ruch budowania w przestrzeni publicznej jest inspirujący, a my w tl;dv staramy się to robić coraz częściej, ponieważ wierzymy, że jest to najlepszy sposób na przyciągnięcie podobnie myślących talentów. 

2. Przejrzysta dokumentacja i procesy sprzyjają autonomii i niezależności.

Pisanie kodu, sprawdzanie kodu, tworzenie treści... możliwości wniesienia wkładu w OSS są różnorodne. Projekty open source muszą być zaprojektowane w taki sposób, aby każdy nowy członek społeczności mógł wnieść swój wkład w sposób autonomiczny. Dlatego też każdy projekt ma jasno określone zasady społeczności, szczegółową dokumentację, a także bardzo przejrzysty system współpracy, który umożliwia poszczególnym współpracownikom śledzenie ewolucji projektów, a także indywidualnego wkładu innych osób. Podobnie jak w przypadku OSS, odnoszące sukcesy remote starają się projektować swoją dokumentację i przepływy pracy w sposób, który w jak największym stopniu promuje niezależność pracowników i przejrzystość. Na początku jest to dość trudne zadanie, ale jego wpływ na szybkość działania zespołu narasta z czasem i wraz z każdym nowym zatrudnieniem. My również wciąż uczymy się, jak ulepszać i utrzymywać naszą dokumentację i procesy. Zalecamy początkującym remote rozpoczęcie tego procesu od pierwszego dnia, warto! Przydatnymi inspiracjami na początek są Aula Brain i oczywiście GitLab Handbook.

3. Komunikacja asynchroniczna

Wspomniałem już o przemyślanej dokumentacji i procesach w projektach open source, ale również kanały komunikacji w projektach open source są w większości asynchroniczne. GitHub, Discord, dedykowane fora... większość problemów jest rozwiązywana całkowicie asynchronicznie. Dla niektórych czytelników może to być szokujące, ale obecnie prosperują wielomilionowe firmy, które nigdy nie potrzebowały ani jednego spotkania. To daje do myślenia, prawda? To świetny punkt odniesienia dla każdej remote , a komunikacja asynchroniczna powinna zdecydowanie stanowić domyślny tryb komunikacji. Dobrą zasadą może być to, że spotkanie jest potrzebne, gdy 3 wiadomości wysłane tam i z powrotem nie pozwalają rozwiązać problemu asynchronicznie. Większość (99,9%) remote nie powinna polegać wyłącznie na komunikacji asynchronicznej, ponieważ zazwyczaj są to bardziej heterogeniczne grupy ludzi i generalnie nieco mniej skupione na inżynierii niż społeczność OSS. Bardziej „tradycyjne” remote składają się z osób o różnym doświadczeniu zawodowym, stanowiąc prawdziwą mieszankę sprzedawców, pracowników działu kadr, marketingu, obsługi klienta, finansów i inżynierii oprogramowania, gdzie spotkania są ważne dla zapewnienia emocjonalnej spójności w firmie. W końcu większość naszej komunikacji ma charakter niewerbalny. Niektóre badania, takie jak raport Uniwersytetu Stanowego w Minnesocie, wskazują nawet, że 93% naszej komunikacji ma charakter niewerbalny. Spotkania mają kluczowe znaczenie dla zainicjowania i rozpoczęcia współpracy, badań, generowania i uzyskiwania spostrzeżeń, przekazywania informacji zwrotnych oraz podejmowania decyzji biznesowych. Dzięki tl;dv możesz wprowadzić spotkania oparte na komunikacji asynchronicznej do swojego zestawu remote i osiągnąć odpowiednią równowagę.

A więc… przyszłość pracy remote wyglądać jak system operacyjny?

Wierzę, że coraz więcej remote będzie czerpać inspirację z procesów i kultury społeczności Open Source. W końcu społeczności Open Source są już sprawdzonym modelem organizacyjnym współpracy na dużą skalę. 

Odłóżmy na bok wszystkie opisy techniczne: kto nie chciałby zarabiać na rozwiązywaniu problemów , które naprawdę go interesują, wraz z ludźmi, którym również na nich zależy? 😉

Przyszłość rysuje się w jasnych barwach!