Nadszedł ważny dzień dla Red Hat, rosyjskiej społeczności open source i wszystkich zaangażowanych – w języku rosyjskim ukazała się . Szczegółowo i żywo opowiada, jak w Red Hat dajemy szansę najlepszym pomysłom i najbardziej utalentowanym ludziom, a także o tym, jak nie zagubić się w chaosie i zjednoczyć miliony ludzi na całym świecie.
A ta książka mówi też o życiu i praktyce. Znajdziesz w niej wiele wskazówek dla wszystkich, którzy chcą nauczyć się budować firmę w modelu organizacji otwartej i efektywnie nią zarządzać. Poniżej przedstawiamy kilka najważniejszych zasad zawartych w książce, które możesz zanotować już teraz.
Historia zatrudnienia Jima w firmie jest ciekawa. Pokazuje, że w świecie otwartego kodu nie ma fanfar, ale jest nowa koncepcja przywództwa:
„Po rozmowie z rekruterem wyraziłem zainteresowanie rozmową kwalifikacyjną, a on zapytał, czy nie miałbym nic przeciwko temu, aby w niedzielę polecieć do siedziby firmy Red Hat w Raleigh w Karolinie Północnej. Pomyślałem, że niedziela to dziwny dzień na spotkanie. Ale ponieważ i tak planowałem lecieć w poniedziałek do Nowego Jorku, właściwie miałem po drodze, więc się zgodziłem. Wsiadłem w samolot z Atlanty i wylądowałem w porcie lotniczym Raleigh-Durham. Stamtąd wziąłem taksówkę, która wysadziła mnie przed budynkiem firmy Red Hat na terenie kampusu Uniwersytetu Karoliny Północnej. Była niedziela, było 9:30 rano, i nikogo w pobliżu. Światło było wyłączone, a po sprawdzeniu odkryłem, że drzwi są zamknięte. Początkowo pomyślałem, że żartują ze mnie. Kiedy się odwróciłem, by wrócić do taksówki, zobaczyłem, że ona już odjechała. Niedługo potem zaczął padać deszcz, nie miałem parasola.
Tylko chciałem iść gdzieś, by złapać taksówkę, gdy Matthew Shulik, późniejszy przewodniczący rady dyrektorów i dyrektor generalny firmy Red Hat, podjechał swoim samochodem. „Cześć – przywitał się. – Chcesz napić się kawy?” To wydało mi się dziwnym początkiem rozmowy kwalifikacyjnej, ale zdawałem sobie sprawę, że zdecydowanie potrzebuję kawy. Ostatecznie, pomyślałem, później będzie mi łatwiej złapać taksówkę na lotnisko.
W niedzielę w Północnej Karolinie rankiem jest dość cicho. Zajęło nam trochę czasu, aby po prostu znaleźć kawiarnię, która otwierała się wcześniej niż w południe. Kawiarnia okazała się nie najlepsza w mieście i niezbyt czysta, ale działała i można było tam wypić świeżo parzone kawę. Usiedliśmy przy stoliku i zaczęliśmy rozmowę.
Po około trzydziestu minutach zdałem sobie sprawę, że podoba mi się, jak wszystko przebiega; rozmowa nie była tradycyjna, ale sama rozmowa okazała się bardzo interesująca. Zamiast omawiać niuanse strategii korporacyjnej firmy Red Hat lub jej wizerunku na Wall Street – czyli tym, do czego się przygotowałem – Matthew Shulik pytał bardziej o moje nadzieje, marzenia i cele. Teraz rozumiem, że Shulik oceniał, czy pasuję do subkultury i stylu zarządzania firmy.
Po zakończeniu Shulik powiedział, że chciałby przedstawić mnie głównemu prawnikowi firmy Michaelowi Cunninghamowi i zaproponował spotkanie z nim teraz, na wczesnym lunchu. Zgodziłem się i zaczęliśmy się zbierać. Następnie mój rozmówca odkrył, że nie ma ze sobą portfela. „Ups,” powiedział. „Nie mam pieniędzy. A ty?” To zaskoczyło mnie, ale odpowiedziałem, że mam pieniądze i nie mam nic przeciwko temu, aby zapłacić za kawę.
Po kilku minutach Shulik wysadził mnie w małej meksykańskiej knajpce, gdzie spotkałem się z Michaelem Cunninghamem. Ale żadnej tradycyjnej rozmowy kwalifikacyjnej ani spotkania biznesowego ponownie nie było, za to odbyła się kolejna interesująca rozmowa. Kiedy mieliśmy zapłacić rachunek, okazało się, że w restauracji zepsuła się maszyna do płatności kartą kredytową i mogą przyjmować tylko gotówkę. Cunningham zwrócił się do mnie z pytaniem, czy jestem gotowy zapłacić, ponieważ nie miał przy sobie gotówki. Ponieważ wybierałem się do Nowego Jorku, miałem dużo gotówki, więc zapłaciłem za lunch.
Canningem zaproponował, że podwiezie mnie na lotnisko, więc pojechaliśmy jego samochodem. Po kilku minutach zapytał: „Czy nie masz nic przeciwko, jeśli zatrzymam się na tankowanie? Pojedziemy na pełnym gazie”. – „Nie ma sprawy”, odpowiedziałem. Gdy tylko usłyszałem rytmiczny dźwięk pompy, ktoś zapukał w okno. To był Canningem. „Hej, nie akceptują kart kredytowych, powiedział. – Czy mogę pożyczyć trochę pieniędzy?” Zaczynałem się zastanawiać, czy to naprawdę była rozmowa kwalifikacyjna, czy może jakaś mistyfikacja.
Następnego dnia, będąc w Nowym Jorku, omawiałem z moją żoną to spotkanie w firmie Red Hat. Opowiedziałem jej, że rozmowa była bardzo interesująca, ale nie byłem pewien, czy ci ludzie naprawdę mają zamiar mnie zatrudnić: może po prostu potrzebowali darmowego jedzenia i paliwa? Wspominając dziś to spotkanie, rozumiem, że Szulik i Canningem byli po prostu otwartymi ludźmi, którzy traktowali mnie jak każdego innego, z kim mogli wypić kawę, zjeść obiad lub zatankować. Tak, to zabawne, a nawet komiczne, że obaj byli bez pieniędzy. Ale dla nich to nie chodziło o pieniądze. Tak jak świat wokół otwartego kodu, nie wierzyli w rozwijanie czerwonych dywanów ani w próbę przekonania rozmówcy, że wszystko jest idealne. Chcieli po prostu lepiej mnie poznać, a nie robić wrażenie czy wskazywać na nasze różnice. Chcieli wiedzieć, kim jestem.
Moje pierwsze spotkanie w firmie Red Hat wyraźnie pokazało mi, że praca tutaj ma inny charakter. W tej firmie nie było tradycyjnej hierarchii ani szczególnego reżimu dla kierowników, przynajmniej w takiej formie, jak to jest w większości innych firm. Z czasem dowiedziałem się również, że firma Red Hat wierzy w zasadę merito-kracji: zawsze warto spróbować wcielić w życie najlepsze pomysły, niezależnie od tego, czy pochodzą one z najwyższego kierownictwa, czy od stażysty zatrudnionego na letnią pracę. Innymi słowy, moje pierwsze wrażenie z Red Hat zapoznało mnie z tym, jak wygląda przyszłość przywództwa.
Porady dotyczące pielęgnowania merito-kracji
Meritokracja to główna wartość społeczności otwartego kodu. Nie ma dla nas znaczenia, na jakim szczeblu piramidy się znajdujesz, liczy się, jak dobre są twoje pomysły. Oto, co proponuje Jim:
- Nigdy nie mów: „Tak chce szef” – i nie polegaj na hierarchii. Może to pomóc w krótkim okresie, ale nie zbudujesz w ten sposób meritokracji.
- Publicznie uznawaj sukcesy i istotne wkłady w wspólne przedsięwzięcia. Może to być prosta wiadomość e-mail z podziękowaniami, w której kopii znajduje się cały zespół.
- Pomyśl: czy twój autorytet zależy od pozycji w hierarchii (lub dostępu do uprzywilejowanych informacji), czy jest wynikiem zdobytej przez ciebie respektu? Jeśli to pierwsze – zacznij pracować nad drugim.
- Proś o opinie i zbieraj pomysły na konkretny temat. Reaguj na wszystkie, przetestuj tylko najlepsze. Ale nie po prostu bierz najlepsze pomysły i idź z nimi dalej – wykorzystaj każdą okazję, aby wzmocnić ducha meritokracji, oddając hołd wszystkim, którzy na to zasługują.
- Wyróżnij wzorowego członka swojego zespołu, proponując mu ciekawe zadanie, nawet jeśli nie dotyczy ono jego zwykłego obszaru działalności.
Niech twoje „gwiazdy rocka” podążają za swoją pasją.
Entuzjazm i zaangażowanie to dwa bardzo ważne słowa w otwartej organizacji. W książce są one stale powtarzane. Ale nie możesz zmusić entuzjastycznych, kreatywnych ludzi do pracy „od do”, prawda? W przeciwnym razie nie wykorzystasz wszystkiego, co może zaoferować ich talent. W Red Hat przeszkody dla własnych projektów są zminimalizowane:
Aby zarządzać innowacjami, firmy próbują wiele. Interesujące podejście firmy Google. Odkąd Google, począwszy od 2004 roku, stała się znana w każdym domu, liderzy i ideolodzy w internecie starali się rozwiązać główną tajemnicę firmy, aby powtórzyć jej imponujący sukces. Jednym z najbardziej znanych, ale obecnie zamkniętych programów było to, że wszystkim pracownikom Google proponowano spędzać 20 procent czasu pracy praktycznie na wszystkim, co im się spodoba. Idea była następująca: jeśli pracownicy będą realizować własne projekty i pomysły, którymi są zainteresowani poza pracą, zaczną tworzyć innowacje. W ten sposób powstały udane projekty zewnętrzne: GoogleSuggest, AdSense for Content i Orkut; wszystkie one powstały w wyniku tego eksperymentu z 20 procentami – imponujący zestaw!
W Red Hat stosujemy mniej formalne podejście. Nie mamy ustalonej polityki dotyczącej tego, ile czasu każdy z naszych pracowników powinien poświęcać na „innowacje”. Zamiast wyznaczać osobny czas na samokształcenie, sprawiamy, że pracownicy zdobywają prawo do poświęcania swojego czasu na nowości. Szczerze mówiąc, wielu z nich ma na to bardzo mało czasu, ale są też tacy, którzy mogą poświęcić niemal cały dzień roboczy na innowacje.
Najbardziej typowy przypadek wygląda mniej więcej tak: ktoś pracuje nad zewnętrznym projektem (jeśli wyjaśnił menedżerom jego znaczenie – albo w godzinach pracy, albo w czasie wolnym – z własnej inicjatywy), a później ta praca może zajmować wszystkie jego godziny obecności.
Więcej niż burza mózgów
«Liryczna dygresja. Alex F. Osborn – wynalazca metody „burzy mózgów”, z której współcześnie wywodzi się metoda syntezy. Ciekawe, że pomysł ten narodził się podczas II wojny światowej, gdy Osborn dowodził jednym z amerykańskich statków w konwoju, który znalazł się w niebezpieczeństwie podczas ataku torpedowego przez niemiecką łódź podwodną. Kapitan przypomniał sobie sposób, który stosowali średniowieczni piraci: jeśli załoga popadała w kłopoty, wszyscy marynarze gromadzili się na pokładzie, aby na przemian proponować sposoby rozwiązania problemu. Pojawiło się wiele pomysłów, w tym na pierwszy rzut oka absurdalnych: na przykład pomysł, aby cała załoga dmuchnęła na torpedę. Jednak strumień z pompy okrętowej, która jest na każdym statku, może rzeczywiście spowolnić torpedę lub nawet zmienić jej kurs. W rezultacie Osborn nawet opatentował wynalazek: dodatkowy śrub wmontowany w bok statku wytwarza strumień wody wzdłuż burty, a torpeda przesuwa się obok.
Nasz Jim często powtarza, że w organizacji otwartej nie jest łatwo pracować. Nawet kierownictwo odczuwa to, ponieważ nikt nie jest zwolniony z konieczności bronienia swojego zdania. Ale właśnie takie podejście jest potrzebne, aby osiągnąć doskonałe wyniki:
„Fora online [programistów open source] i czaty często wypełnione są ożywionymi, a czasami i kąśliwymi dyskusjami na każdy temat – od tego, jak najlepiej naprawić błąd w oprogramowaniu, po to, jakie nowe funkcje powinny być rozważane w najnowszej aktualizacji. Zwykle to pierwsza faza dyskusji, w której pojawiają się i gromadzą nowe pomysły, ale zazwyczaj następuje następna runda – krytyczna analiza. Chociaż każdy może uczestniczyć w tych sporach, człowiek musi być gotów bronić swojego stanowiska z całych sił. Niepopularne pomysły są w najlepszym razie odrzucane, w najgorszym – wyśmiewane.
Nawet Linus Torvalds, twórca systemu operacyjnego Linux, wyraża swoje niezadowolenie z proponowanych zmian w kodzie. Kiedyś Linus i David Howell, jeden z wiodących programistów w firmie Red Hat, podjęli gorącą dyskusję na temat zalet zmiany kodu, o którą prosiła firma Red Hat, co pomogłoby zapewnić bezpieczeństwo naszym klientom. W odpowiedzi na prośbę Howella Torvalds napisał: „Szczerze mówiąc, to [niecenzuralne słowo] idiotyzm. Wszystko wydaje się obracać wokół tych głupich interfejsów, i to z całkowicie idiotycznych powodów. Dlaczego mamy to robić? Już nie lubię istniejącego parsera X.509. Tworzone są idiotycznie skomplikowane interfejsy, a teraz ich będzie 11. – Linus 9”.
Zostawiając techniczne szczegóły na boku, Torvalds w kolejnym komunikacie kontynuował w tym samym duchu – i tak, że nie odważę się cytować. Ta dyskusja była tak głośna, że nawet trafiła na strony The Wall Street Journal. […]
Ta dyskusja pokazuje, że w większości firm produkujących programy proprietarne i zamknięte nie ma otwartych debat na temat nowych cech czy zmian, nad którymi mogą pracować. Gdy produkt jest gotowy, firma po prostu wysyła go do klientów i idzie dalej. W przypadku Linuxa dyskusje na temat tego, jakie zmiany są potrzebne i – co najważniejsze – dlaczego są potrzebne, nie milkną. Oczywiście, to sprawia, że cały proces jest znacznie bardziej chaotyczny i czasochłonny.
Wydawaj wcześnie, wydawaj często
Nie możemy przewidzieć przyszłości, dlatego musimy po prostu spróbować:
Działamy według zasady „wczesne uruchomienie, częste aktualizacje”. Kluczowym problemem każdego projektu programistycznego jest ryzyko błędów lub wad w kodzie źródłowym. Oczywiste jest, że im więcej zmian i aktualizacji gromadzi się w jednym wydaniu (wersji) oprogramowania, tym większe prawdopodobieństwo, że w tej wersji znajdą się błędy. Deweloperzy oprogramowania z otwartym kodem źródłowym zdali sobie sprawę, że szybkie i częste wydawanie wersji oprogramowania zmniejsza ryzyko wystąpienia poważnych problemów z jakimkolwiek programem – w końcu wypuszczamy na rynek nie wszystkie aktualizacje naraz, ale w porcjach w każdej wersji. Z czasem zauważyliśmy, że podejście to 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 końcu tworzy więcej innowacji. Możliwe, że nie ma w tym nic dziwnego. Jedną z kluczowych zasad nowoczesnych procesów produkcyjnych, takich jak kaizen a lub lean b, jest skupienie się na niewielkich i stopniowych zmianach oraz aktualizacjach.
[…] Wiele z tego, nad czym pracujemy, może nie przynieść sukcesu. Ale zamiast tracić mnóstwo czasu, zastanawiając się, co się sprawdzi, a co nie, wolimy przeprowadzać niewielkie eksperymenty. Najbardziej pożądane pomysły przyniosą sukces, a te, które się nie sprawdzą, same wygasną. W ten sposób możemy spróbować wielu rzeczy, a nie tylko jednej, i to bez większego ryzyka dla firmy.
To jest rozsądny sposób zarządzania zasobami. Na przykład, ludzie często pytają mnie, jak wybieramy, które projekty open source warto skomercjalizować. Chociaż czasami inicjujemy projekty, częściej po prostu dołączamy do istniejących. Mała grupa inżynierów – a czasami nawet jedna osoba – zaczyna wnosić wkład w jeden z projektów społeczności open source. Jeśli projekt odnosi sukces i cieszy się zainteresowaniem naszych klientów, zaczynamy poświęcać mu więcej czasu i wysiłków. Jeśli nie, deweloperzy przechodzą do nowego projektu. W momencie, gdy decydujemy się na komercjalizację oferty, projekt może rozrosnąć się na tyle, że decyzja staje się oczywista. Najróżniejsze projekty, w tym te niezwiązane z oprogramowaniem, naturalnie pojawiają się w całej firmie Red Hat, aż wszystkim staje się jasne, że ktoś musi teraz zająć się tym na stałe.
Oto kolejny cytat z książki:
„Zdałem sobie sprawę, że aby spełnić taką rolę, jutrzejsi liderzy muszą różnić się cechami, na które w zwykłych organizacjach po prostu nie zwraca się uwagi. Aby skutecznie kierować otwartą organizacją, lider powinien posiadać następujące cechy.
- Osobista siła i pewność siebie. Zwykli liderzy korzystają z władzy pozycyjnej – swojej roli – aby osiągnąć sukces. Ale w meritokracji liderzy muszą zasłużyć na szacunek. A to możliwe tylko wtedy, gdy nie boją się przyznać, że nie mają odpowiedzi na wszystkie pytania. Powinni być gotowi do omawiania problemów i szybkiego podejmowania decyzji, aby znaleźć najlepsze rozwiązania wspólnie z zespołem.
- Cierpliwość. Media rzadko opowiadają historie o tym, jak „cierpliwy” jest lider. Ale naprawdę musi być cierpliwy. Gdy pracujesz, aby wydobyć z zespołu maksymalne wysiłki i wyniki, godzinami prowadzisz dialog i powtarzasz coś wciąż na nowo, aż wszystko zostanie zrobione poprawnie – musisz mieć cierpliwość.
- Wysoki EQ (inteligencja emocjonalna). Zbyt często promujemy możliwości intelektualne liderów, koncentrując się na ich IQ, podczas gdy w rzeczywistości musimy uwzględnić ich współczynnik inteligencji emocjonalnej, czyli ocenę EQ. Bycie najinteligentniejszą osobą w grupie nie wystarcza, jeśli nie potrafisz współpracować z innymi. Kiedy współpracujesz ze społecznościami zaangażowanych pracowników, takimi jak w Red Hat, i nie masz możliwości nikomu rozkazywać, twoja zdolność do słuchania, analitycznego przetwarzania informacji oraz niestrajania zbyt osobowo staje się niezwykle cenna.
- Inna mentalność. Liderzy przybywający z tradycyjnych organizacji dorastali w duchu quid pro quo (łac. „coś za coś”), zgodnie z którym każdy krok musi przynosić odpowiednią wartość zwrotną. Jednak gdy planujesz inwestycję w tworzenie konkretnej społeczności, musisz myśleć długoterminowo. To jak budowa delikatnie zbalansowanego ekosystemu, w którym każdy fałszywy ruch może spowodować brak równowagi i prowadzić do długoterminowych strat, które mogą nie być od razu widoczne. Liderzy powinni uwolnić się od myślenia, które wymaga osiągania rezultatów natychmiast i za wszelką cenę, i zacząć prowadzenie działań, które pozwolą zyskać dzięki inwestycjom w przyszłość.
Dlaczego to ważne
Red Hat żyje i działa zgodnie z zasadami, które znacznie różnią się od tradycyjnych organizacji z hierarchiczną strukturą. I to działa, czyni nas komercyjnie udanymi i ludzkie szczęśliwymi. Przetłumaczyliśmy tę książkę w nadziei na rozpowszechnienie zasad otwartej organizacji wśród rosyjskich firm, wśród ludzi, którzy chcą i mogą żyć inaczej.
, spróbuj!
Źródło: habr.com
