Nadszedł ważny dzień dla Red Hat, rosyjskiej społeczności open source i wszystkich zaangażowanych w sprawę – opublikowano go w języku rosyjskim . Szczegółowo i obrazowo opowiada, jak w Red Hat wyznaczamy ścieżki najlepszym pomysłom i najbardziej utalentowanym ludziom, a także jak nie zgubić się w chaosie i zjednoczyć miliony ludzi na całym świecie.
Ta książka jest także o życiu i praktyce. Zawiera wiele porad dla każdego, kto chce dowiedzieć się, jak zbudować firmę w oparciu o otwarty model organizacji i efektywnie nią zarządzać. Poniżej znajduje się kilka najważniejszych zasad podanych w tej książce, z którymi możesz już teraz się zapoznać.
Historia zatrudnienia Jima w firmie jest niezwykła. Pokazuje, że w świecie open source nie ma fanfar, ale istnieje nowe podejście do przywództwa:
„Po rozmowie z rekruterem wyraziłem zainteresowanie rozmową kwalifikacyjną, a on zapytał, czy miałbym coś przeciwko przylocie w niedzielę do siedziby Red Hat w Raleigh w Północnej Karolinie. Myślałam, że niedziela to dziwny dzień na spotkanie. Ale ponieważ w poniedziałek miałem jeszcze lecieć do Nowego Jorku, w sumie było już po drodze i zgodziłem się. Wsiadłem do samolotu z Atlanty i wylądowałem na lotnisku w Raleigh Durham. Stamtąd wziąłem taksówkę, która wysadziła mnie przed budynkiem Red Hat na kampusie Uniwersytetu Karoliny Północnej. Była niedziela, godzina 9:30 i nikogo nie było w pobliżu. Światła były wyłączone, a po sprawdzeniu okazało się, że drzwi były zamknięte. Na początku myślałem, że mnie oszukano. Kiedy odwróciłem się, żeby wrócić do taksówki, zobaczyłem, że już odjechała. Bardzo szybko zaczął padać deszcz, nie miałem parasola.
Gdy miałem już gdzieś złapać taksówkę, Matthew Shulick, późniejszy prezes zarządu i dyrektor generalny Red Hat, podjechał do swojego samochodu. – Cześć – przywitał się. „Chcesz napić się kawy?” Wydawało mi się to niezwykłym sposobem na rozpoczęcie rozmowy kwalifikacyjnej, ale wiedziałem, że zdecydowanie muszę napić się kawy. Pomyślałem, że w końcu łatwiej będzie mi złapać taksówkę na lotnisko.
Niedzielne poranki w Karolinie Północnej są dość spokojne. Znalezienie kawiarni otwartej przed południem zajęło nam trochę czasu. Kawiarnia nie była najlepsza w mieście i nie najczystsza, ale działała i można było tam napić się świeżo parzonej kawy. Usiedliśmy przy stole i zaczęliśmy rozmawiać.
Po około trzydziestu minutach zdałem sobie sprawę, że podoba mi się obecny rozwój sytuacji; Rozmowa nie była tradycyjna, ale sama rozmowa okazała się bardzo interesująca. Zamiast omawiać niuanse strategii korporacyjnej Red Hat lub jej wizerunku na Wall Street – na co się przygotowałem – Matthew Shulick zapytał więcej o moje nadzieje, marzenia i cele. Teraz jest dla mnie jasne, że Shulik oceniał, czy będę pasować do subkultury i stylu zarządzania firmą.
Kiedy skończyliśmy, Shulick powiedział, że chce mnie przedstawić głównemu radcy prawnemu firmy, Michaelowi Cunninghamowi, i zasugerował, żebym spotkał się z nim teraz na wczesnym lunchu. Zgodziłam się i przygotowaliśmy się do wyjścia. Wtedy mój rozmówca odkrył, że nie ma przy sobie portfela. – Ups – powiedział. - Nie mam pieniędzy. A ty?" Zaskoczyło mnie to, ale odpowiedziałem, że mam pieniądze i nie mam nic przeciwko zapłaceniu za kawę.
Kilka minut później Shulik podrzucił mnie do małej meksykańskiej restauracji, gdzie spotkałem Michaela Cunninghama. Ale znowu nie doszło do tradycyjnej rozmowy kwalifikacyjnej ani spotkania biznesowego, ale odbyła się kolejna interesująca rozmowa. Kiedy już mieliśmy zapłacić rachunek, okazało się, że w restauracji zepsuł się automat do kart kredytowych i mogliśmy przyjmować tylko gotówkę. Cunningham zwrócił się do mnie i zapytał, czy jestem gotowy zapłacić, ponieważ nie ma przy sobie gotówki. Ponieważ jechałem do Nowego Jorku, miałem dużo gotówki, więc zapłaciłem za lunch.
Cunningham zaproponował, że odwiezie mnie na lotnisko i pojechaliśmy jego samochodem. Po kilku minutach zapytał: „Czy masz coś przeciwko, jeśli zatrzymam się i zatankuję? Pójdziemy pełną parą.” „Nie ma problemu” – odpowiedziałem. Gdy tylko usłyszałem rytmiczny dźwięk pompy, rozległo się pukanie do okna. To był Cunningham. „Hej, nie przyjmują tu kart kredytowych” – powiedział. "Czy mogę pożyczyć trochę pieniędzy?" Zacząłem się zastanawiać, czy to naprawdę był wywiad, czy jakiś rodzaj oszustwa.
Następnego dnia, będąc w Nowym Jorku, omówiłem ten wywiad z moją żoną w Red Hat. Powiedziałem jej, że rozmowa była bardzo interesująca, ale nie byłem pewien, czy ci ludzie poważnie myślą o zatrudnieniu mnie: może po prostu chcieli darmowego jedzenia i benzyny? Wspominając to dzisiejsze spotkanie, rozumiem, że Shulick i Cunningham byli po prostu otwartymi ludźmi i traktowali mnie jak każdą inną osobę, z którą mogli wypić kawę, lunch lub zatankować benzynę. Tak, to zabawne, a nawet zabawne, że oboje zostali bez pieniędzy. Ale dla nich nie chodziło o pieniądze. Oni, podobnie jak świat open source, nie wierzyli w rozwijanie czerwonych dywanów i przekonywanie innych, że wszystko jest idealne. Chcieli po prostu lepiej mnie poznać, a nie robić wrażenie czy podkreślać nasze różnice. Chcieli wiedzieć, kim jestem.
Moja pierwsza rozmowa w Red Hat wyraźnie pokazała mi, że praca tutaj jest inna. W tej firmie nie było tradycyjnej hierarchii i specjalnego traktowania menadżerów, przynajmniej w takiej formie, jaka jest zwyczajowo stosowana w większości innych firm. Z biegiem czasu dowiedziałem się też, że Red Hat wyznaje zasadę merytokracji: zawsze warto starać się wdrożyć najlepszy pomysł, niezależnie od tego, czy pochodzi on od wyższej kadry zarządzającej, czy od wakacyjnego stażysty. Innymi słowy, moje pierwsze doświadczenie w Red Hat pokazało mi, jak wygląda przyszłość przywództwa”.
Wskazówki dotyczące kultywowania merytokracji
Merytokracja jest podstawową wartością społeczności open source. Nie ma dla nas znaczenia, na jakim poziomie piramidy się znajdujesz, najważniejsze jest to, jak dobre są Twoje pomysły. Oto, co sugeruje Jim:
- Nigdy nie mów: „Tego chce szef” i nie polegaj na hierarchii. Może to ci pomóc na krótką metę, ale nie w ten sposób buduje się merytokrację.
- Publicznie uznawaj sukcesy i ważne wkłady. Może to być prosty e-mail z podziękowaniami, zawierający kopię całego zespołu.
- Zastanów się: czy Twój autorytet jest funkcją Twojej pozycji w hierarchii (lub dostępu do uprzywilejowanych informacji), czy też wynika z szacunku, na jaki sobie zapracowałeś? Jeśli to pierwsze, zacznij pracować nad drugim.
- Poproś o opinię i zbierz pomysły na konkretny temat. Należy reagować na wszystko, testować tylko najlepszych. Ale nie kieruj się tylko najlepszymi pomysłami i realizuj je – wykorzystuj każdą okazję, aby wzmacniać ducha merytokracji, okazując uznanie każdemu, kto na to zasługuje.
- Wyróżnij wzorowego członka swojego zespołu, oferując ciekawe zadanie, nawet jeśli nie jest ono związane z jego normalną dziedziną pracy.
Pozwól swoim gwiazdom rocka podążać za swoją pasją
Entuzjazm i zaangażowanie to dwa bardzo ważne słowa w otwartej organizacji. Powtarzają się one w książce stale. Ale nie można zmusić kreatywnych ludzi z pasją do ciężkiej pracy, prawda? W przeciwnym razie po prostu nie dostaniesz wszystkiego, co ma do zaoferowania ich talent. W Red Hat maksymalnie niwelujemy przeszkody dla własnych projektów:
„Aby stymulować innowacje, firmy próbują wielu rzeczy. Podejście Google jest interesujące. Odkąd w 2004 roku Google stał się znany w każdym domu, dyrektorzy i ideolodzy branży internetowej próbowali rozwikłać główny sekret firmy, aby powtórzyć jej imponujący sukces. Jeden z najsłynniejszych, choć obecnie zamkniętych programów, polegał na tym, że wszystkich pracowników Google'a poproszono o spędzenie 20 procent swojego czasu na robieniu niemal wszystkiego, co im się podoba. Pomysł był taki, że jeśli pracownicy będą realizować poza pracą własne projekty i pomysły, które ich pasjonują, zaczną wprowadzać innowacje. Tak powstały udane projekty stron trzecich: GoogleSuggest, AdSense dla treści i Orkut; wszystkie pochodziły z tego 20-procentowego eksperymentu – lista imponująca! […]
W Red Hat stosujemy mniej formalne podejście. Nie mamy ustalonej polityki dotyczącej tego, ile czasu każdy z naszych pracowników powinien spędzać na „innowacjach”. Zamiast dawać ludziom czas na naukę, dbamy o to, aby pracownicy mieli prawo do spędzania czasu na nauce nowych rzeczy. Szczerze mówiąc, wiele osób ma bardzo mało takiego czasu, ale są też tacy, którzy niemal cały dzień pracy mogą spędzić na innowacjach.
Najbardziej typowy przypadek wygląda mniej więcej tak: ktoś pracuje nad pobocznym projektem (jeśli wyjaśnił menadżerom jego znaczenie – bezpośrednio w miejscu pracy lub w godzinach poza pracą – z własnej inicjatywy), a później tę pracę mogą pochłonąć wszyscy jego obecne godziny.”
Więcej niż burza mózgów
„Dygresja liryczna. Alex Fakeney Osborne jest wynalazcą metody burzy mózgów, której kontynuacją jest dziś metoda synektyki. Ciekawe, że pomysł ten pojawił się podczas drugiej wojny światowej, kiedy Osborne dowodził jednym ze statków amerykańskiego konwoju towarowego, któremu groził atak torpedowy niemieckiego okrętu podwodnego. Wtedy kapitan przypomniał sobie technikę stosowaną przez średniowiecznych piratów: jeśli załoga wpadała w kłopoty, wszyscy marynarze gromadzili się na pokładzie, aby na zmianę sugerować sposób rozwiązania problemu. Pomysłów było wiele, także na pierwszy rzut oka absurdalnych: np. pomysł wysadzenia torpedy całą drużyną. Ale za pomocą strumienia pompy okrętowej, który jest dostępny na każdym statku, całkiem możliwe jest spowolnienie torpedy, a nawet zmiana jej kursu. W rezultacie Osborne opatentował nawet wynalazek: na burcie statku zamontowano dodatkowe śmigło, które napędza strumień wody wzdłuż burty, a torpeda ślizga się po burcie.
Nasz Jim nieustannie powtarza, że nie jest łatwo pracować w otwartej organizacji. Nawet kierownictwo to rozumie, ponieważ nikt nie jest oszczędzony konieczności obrony swojego zdania. Ale to jest dokładnie podejście potrzebne do osiągnięcia doskonałych wyników:
„Fora internetowe i pokoje rozmów [open source] są często wypełnione ożywionymi, a czasem zaciekłymi dyskusjami na każdy temat, od tego, jak najlepiej naprawić błąd oprogramowania, po jakie nowe funkcje należy uwzględnić w następnej aktualizacji. Z reguły jest to pierwsza faza dyskusji, podczas której zgłaszane i gromadzone są nowe pomysły, ale zawsze następuje kolejna runda – krytyczna analiza. Chociaż w tych debatach może uczestniczyć każdy, należy być przygotowanym na obronę swojego stanowiska ze wszystkich sił. Niepopularne pomysły zostaną w najlepszym przypadku odrzucone, a w najgorszym wyśmiane.
Nawet Linus Torvalds, twórca systemu operacyjnego Linux, wyraża swój sprzeciw wobec proponowanych zmian w kodzie. Pewnego dnia Linus i David Howells, jeden z głównych programistów firmy Red Hat, wdali się w gorącą debatę na temat zalet zmiany kodu, o którą prosił Red Hat, a która pomogłaby zapewnić bezpieczeństwo naszym klientom. W odpowiedzi na prośbę Howellsa Torvalds napisał: „Szczerze mówiąc, jest to [słowo niedrukowalne] idiotyczne. Wszystko wydaje się kręcić wokół tych głupich interfejsów i to z całkowicie głupich powodów. Dlaczego powinniśmy to zrobić? Nie podoba mi się już istniejący parser X.509. Tworzą się głupie, skomplikowane interfejsy, a teraz będzie ich 11. – Linus 9.”
Pomijając szczegóły techniczne, Torvalds w dalszym ciągu pisał w tym samym duchu w następnej wiadomości – i to w taki sposób, że nie ośmielę się cytować. Spór ten był tak głośny, że trafił nawet na łamy „The Wall Street Journal”. […]
Ta debata pokazuje, że większość firm produkujących zastrzeżone, niewolne oprogramowanie nie prowadzi otwartej debaty na temat nowych funkcji lub zmian, nad którymi mogą pracować. Kiedy produkt jest już gotowy, firma po prostu wysyła go do klientów i rusza dalej. Jednocześnie w przypadku Linuksa nie cichną dyskusje na temat tego, jakie zmiany są potrzebne i – co najważniejsze – dlaczego są one konieczne. To oczywiście sprawia, że cały proces jest znacznie bardziej chaotyczny i czasochłonny”.
Wypuszczaj wcześnie, wypuszczaj często
Nie możemy przewidzieć przyszłości, więc musimy po prostu spróbować:
„Działamy w oparciu o zasadę „wczesne uruchomienie, częste aktualizacje”. Kluczowym problemem każdego projektu oprogramowania jest ryzyko błędów lub błędów w kodzie źródłowym. Oczywiście im więcej zmian i aktualizacji zgromadzonych jest w jednym wydaniu (wersji) oprogramowania, tym większe prawdopodobieństwo, że w tej wersji pojawią się błędy. Twórcy oprogramowania typu open source zdali sobie sprawę, że szybkie i częste wydawanie wersji oprogramowania zmniejsza ryzyko poważnych problemów z jakimkolwiek programem - w końcu nie wprowadzamy na rynek wszystkich aktualizacji od razu, ale pojedynczo dla każdej wersji. Z biegiem czasu zauważyliśmy, że takie podejście nie tylko zmniejsza liczbę błędów, ale także prowadzi do ciekawszych rozwiązań. Okazuje się, że ciągłe wprowadzanie drobnych ulepszeń w dłuższej perspektywie tworzy więcej innowacji. Być może nie ma tu nic zaskakującego. Jedną z kluczowych zasad nowoczesnych procesów produkcyjnych, takich jak kaizen a czy Lean B, jest koncentracja na małych, przyrostowych zmianach i aktualizacjach.
[…] Wiele z tego, nad czym pracujemy, może się nie udać. Ale zamiast spędzać dużo czasu na zastanawianiu się, co zadziała, a co nie, wolimy przeprowadzać małe eksperymenty. Najpopularniejsze pomysły poprowadzą do sukcesu, a te, które się nie sprawdzą, same uschną. W ten sposób możemy wypróbować wiele rzeczy, a nie tylko jedną, bez większego ryzyka dla firmy.
Jest to racjonalny sposób alokacji zasobów. Na przykład ludzie często pytają mnie, w jaki sposób wybieramy projekty open source do komercjalizacji. Chociaż czasami inicjujemy projekty, najczęściej po prostu wskakujemy do istniejących. Mała grupa inżynierów – czasem tylko jedna osoba – zaczyna brać udział w jednym z projektów społeczności open source. Jeśli projekt odniesie sukces i cieszy się zainteresowaniem wśród naszych klientów, zaczynamy poświęcać mu więcej czasu i wysiłku. Jeśli nie, programiści przechodzą do nowego projektu. Zanim zdecydujemy się na komercjalizację propozycji, projekt mógł urosnąć do tego stopnia, że rozwiązanie będzie oczywiste. Różne projekty, w tym niezwiązane z oprogramowaniem, naturalnie pojawiają się w Red Hat, dopóki dla wszystkich nie stanie się jasne, że teraz ktoś będzie musiał pracować nad tym na pełny etat.
Oto kolejny cytat z książki:
„Zdałem sobie sprawę, że aby sprostać tej roli, przyszli liderzy muszą posiadać cechy, które są po prostu pomijane w konwencjonalnych organizacjach. Aby skutecznie kierować otwartą organizacją, lider musi posiadać następujące cechy.
- Osobista siła i pewność siebie. Zwykli przywódcy wykorzystują władzę pozycyjną – swoją pozycję – aby osiągnąć sukces. Ale w merytokracji przywódcy muszą zasłużyć na szacunek. A jest to możliwe tylko wtedy, gdy nie boją się przyznać, że nie znają odpowiedzi na wszystkie pytania. Muszą chcieć omawiać problemy i szybko podejmować decyzje, aby wspólnie ze swoim zespołem znaleźć najlepsze rozwiązania.
- Cierpliwość. Media rzadko opowiadają historie o tym, jak „cierpliwy” jest lider. Ale naprawdę musi uzbroić się w cierpliwość. Kiedy pracujesz, aby uzyskać jak najwięcej wysiłku i jak najlepszych wyników od swojego zespołu, godzinami rozmawiasz i powtarzasz pewne rzeczy, aż wszystko zostanie zrobione dobrze, musisz uzbroić się w cierpliwość.
- Wysokie EQ (inteligencja emocjonalna). Zbyt często promujemy inteligencję liderów, koncentrując się na ich IQ, podczas gdy tak naprawdę należy wziąć pod uwagę ich iloraz inteligencji emocjonalnej, czyli wynik EQ. Bycie najmądrzejszą osobą spośród innych nie wystarczy, jeśli nie potrafisz pracować z tymi ludźmi. Kiedy współpracujesz ze społecznościami zaangażowanych pracowników, takimi jak Red Hat, i nie możesz nikomu rozkazywać, Twoja umiejętność słuchania, analitycznego przetwarzania i nie brania wszystkiego do siebie staje się niezwykle cenna.
- Inna mentalność. Liderów wywodzących się z organizacji tradycyjnych wychowywano w duchu quid pro quo (łac. „quid pro quo”), zgodnie z którym każde działanie powinno otrzymać odpowiedni zwrot. Ale jeśli chcesz zainwestować w budowanie konkretnej społeczności, musisz myśleć długoterminowo. To jak próba zbudowania delikatnie zrównoważonego ekosystemu, w którym każdy zły krok może spowodować brak równowagi i doprowadzić do długoterminowych strat, których możesz nie zauważyć od razu. Liderzy muszą pozbyć się sposobu myślenia, który wymaga od nich osiągania wyników już dziś, za wszelką cenę, i zacząć prowadzić działalność gospodarczą w sposób, który pozwoli im czerpać większe korzyści poprzez inwestowanie w przyszłość.
I dlaczego to jest ważne
Red Hat żyje i działa w oparciu o zasady, które bardzo różnią się od tradycyjnej organizacji hierarchicznej. I to działa, sprawia, że odnosimy sukcesy komercyjne i jesteśmy szczęśliwi po ludzku. Przetłumaczyliśmy tę książkę w nadziei szerzenia zasad otwartej organizacji wśród rosyjskich firm, wśród ludzi, którzy chcą i mogą żyć inaczej.
, Spróbuj!
Źródło: www.habr.com