En viktig dag har kommet for Red Hat, det russiske open source-miljøet og alle involverte – den ble publisert på russisk . Hun forteller i detalj og levende hvordan vi i Red Hat gir de beste ideene og de dyktigste menneskene veien, og også om hvordan man ikke går seg vill i kaoset og forener millioner av mennesker rundt om i verden.
Denne boken handler også om liv og praksis. Den inneholder mange råd for alle som ønsker å lære å bygge en bedrift ved å bruke den åpne organisasjonsmodellen og effektivt administrere den. Nedenfor er noen av de viktigste prinsippene gitt i boken som du kan legge merke til akkurat nå.
Jims ansettelseshistorie i selskapet er bemerkelsesverdig. Det viser at det ikke er noen fanfare i åpen kildekode-verden, men det er en ny tilnærming til ledelse:
«Etter å ha snakket med rekruttereren, uttrykte jeg interesse for et intervju, og han spurte om jeg kunne tenke meg å fly til Red Hat-hovedkvarteret i Raleigh, North Carolina, på søndag. Jeg syntes søndag var en merkelig dag å møte. Men siden jeg likevel skulle fly til New York på mandag, var det generelt sett på vei, og jeg takket ja. Jeg gikk om bord på et fly fra Atlanta og landet på Raleigh Durham flyplass. Derfra tok jeg en taxi som satte meg av foran Red Hat-bygningen på University of North Carolina campus. Det var søndag, 9:30, og ingen var i nærheten. Lysene var av, og da jeg sjekket fant jeg at dørene var låst. Først trodde jeg at jeg ble lurt. Da jeg snudde meg for å sette meg inn i taxien igjen, så jeg at den allerede hadde gått. Veldig snart begynte det å regne, jeg hadde ikke paraply.
Akkurat da jeg skulle dra et sted for å ta en taxi, stoppet Matthew Shulick, senere styreleder og administrerende direktør i Red Hat, opp i bilen hans. "Hei," hilste han. "Vil du ha en kaffe?" Dette virket som en uvanlig måte å starte et intervju på, men jeg visste at jeg definitivt trengte å få meg litt kaffe. Til slutt, tenkte jeg, ville det være lettere for meg å ta en taxi til flyplassen.
Søndag morgen er ganske stille i North Carolina. Det tok oss en stund bare å finne en kaffebar som åpnet før kl. Kaffebaren var ikke den beste i byen og ikke den reneste, men den fungerte og man kunne drikke nytraktet kaffe der. Vi satte oss ved et bord og begynte å snakke.
Etter omtrent tretti minutter skjønte jeg at jeg likte hvordan ting gikk; Intervjuet var ikke tradisjonelt, men selve samtalen viste seg å være veldig interessant. I stedet for å diskutere de fineste punktene i Red Hats bedriftsstrategi eller dens image på Wall Street – noe jeg hadde forberedt meg på – spurte Matthew Shulick mer om mine håp, drømmer og mål. Nå er det klart for meg at Shulik vurderte om jeg ville passe til subkulturen og ledelsesstilen til selskapet.
Etter at vi var ferdige, sa Shulick at han ønsket å introdusere meg for selskapets generaladvokat, Michael Cunningham, og foreslo at jeg skulle møte ham nå for en tidlig lunsj. Jeg sa ja, og vi gjorde oss klare til å dra. Da oppdaget samtalepartneren min at han ikke hadde lommeboken med seg. "Oops," sa han. - Jeg har ingen penger. Og du?" Dette overrasket meg, men jeg svarte at jeg hadde penger og ikke hadde noe imot å betale for kaffen.
Noen minutter senere slapp Shulik meg av på en liten meksikansk restaurant, hvor jeg møtte Michael Cunningham. Men igjen, ingen tradisjonelle intervjuer eller forretningsmøter fulgte, men en annen interessant samtale fant sted. Da vi skulle betale regningen viste det seg at restaurantens kredittkortautomat var ødelagt, og vi kunne bare ta imot kontanter. Cunningham snudde seg mot meg og spurte om jeg var klar til å betale, for han hadde ikke kontanter med seg. Siden jeg skulle til New York hadde jeg mye penger, så jeg betalte for lunsj.
Cunningham tilbød seg å kjøre meg til flyplassen, og vi gikk i bilen hans. Etter noen minutter spurte han: «Har du noe imot at jeg stopper og får bensin? Vi går for fullt." "Ikke noe problem," svarte jeg. Så snart jeg hørte den rytmiske lyden av pumpen, banket det på vinduet. Det var Cunningham. "Hei, de tar ikke kredittkort her," sa han. "Kan jeg låne penger?" Jeg begynte å lure på om dette virkelig var et intervju eller en slags svindel.
Dagen etter, mens jeg var i New York, diskuterte jeg dette intervjuet med min kone på Red Hat. Jeg fortalte henne at samtalen var veldig interessant, men jeg var ikke sikker på om disse menneskene var seriøse med å ansette meg: kanskje de bare ville ha gratis mat og bensin? Når jeg husker det møtet i dag, forstår jeg at Shulick og Cunningham rett og slett var åpne mennesker og behandlet meg som enhver annen person som de kunne ta kaffe, lunsj eller fylle bensin med. Ja, det er morsomt og til og med morsomt at de begge endte opp uten penger. Men for dem handlet det ikke om penger. De, i likhet med open source-verdenen, trodde ikke på å rulle ut røde løpere eller prøve å overbevise andre om at alt var perfekt. De prøvde bare å bli bedre kjent med meg, ikke prøve å imponere eller påpeke forskjellene våre. De ville vite hvem jeg var.
Mitt første intervju på Red Hat viste meg tydelig at arbeidet her var annerledes. Dette selskapet hadde ikke et tradisjonelt hierarki og særbehandling for ledere, i hvert fall i den formen som er vanlig i de fleste andre virksomheter. Over tid lærte jeg også at Red Hat tror på prinsippet om meritokrati: det er alltid verdt å prøve å implementere den beste ideen, uavhengig av om den kommer fra toppledelsen eller fra en sommerpraktikant. Med andre ord, min første erfaring på Red Hat introduserte meg for hvordan fremtiden for lederskap ser ut.»
Tips for å dyrke meritokrati
Meritokrati er kjerneverdien til åpen kildekode-fellesskapet. Det spiller ingen rolle for oss hvilket nivå av pyramiden du okkuperer, det viktigste er hvor gode ideene dine er. Her er hva Jim foreslår:
- Aldri si, "Det er det sjefen vil," og ikke stol på hierarki. Dette kan hjelpe deg på kort sikt, men det er ikke slik du bygger et meritokrati.
- Offentlig anerkjenne suksesser og viktige bidrag. Dette kan være en enkel takke-e-post med hele teamet på kopi.
- Tenk på: er din autoritet en funksjon av din posisjon i hierarkiet (eller tilgang til privilegert informasjon), eller er det et resultat av respekten du har opparbeidet deg? Hvis den første, begynn å jobbe med den andre.
- Be om tilbakemelding og samle ideer om et spesifikt emne. Du bør reagere på alt, teste kun det beste. Men ikke bare ta de beste ideene og gå videre med dem – benytt enhver anledning til å styrke meritokratiets ånd, gi æren til alle som fortjener det.
- Gjenkjenne et eksemplarisk medlem av teamet ditt ved å tilby et interessant oppdrag, selv om det ikke er i deres vanlige arbeidsfelt.
La rockestjernene dine følge lidenskapen deres
Entusiasme og involvering er to svært viktige ord i en åpen organisasjon. De gjentas stadig i boken. Men du kan ikke få lidenskapelige kreative mennesker til å jobbe hardt, ikke sant? Ellers får du rett og slett ikke alt talentet deres har å tilby. Hos Red Hat jevnes hindringer for egne prosjekter ut så mye som mulig:
"For å drive innovasjon prøver bedrifter mange ting. Googles tilnærming er interessant. Siden Google ble kjent i alle hjem i 2004, har ledere og ideologer i internettbransjen forsøkt å avdekke selskapets hovedhemmelighet for å gjenta dens imponerende suksess. Et av de mest kjente, men for øyeblikket stengte programmene var at alle Google-ansatte ble bedt om å bruke 20 prosent av tiden sin på nesten hva de ville. Tanken var at hvis ansatte forfulgte sine egne prosjekter og ideer som de brenner for utenfor jobben, ville de begynne å innovere. Slik oppsto vellykkede tredjepartsprosjekter: GoogleSuggest, AdSense for Content og Orkut; de kom alle fra dette 20 prosent eksperimentet - en imponerende liste! […]
Hos Red Hat tar vi en mindre formell tilnærming. Vi har ingen faste retningslinjer for hvor mye tid hver av våre ansatte skal bruke på «innovasjon». I stedet for å gi folk dedikert tid til å utdanne seg selv, sørger vi for at ansatte får retten til å bruke tiden sin på å lære nye ting. For å være ærlig har mange svært lite tid, men det er også de som kan bruke nesten hele arbeidsdagen på innovasjon.
Det mest typiske tilfellet ser omtrent slik ut: noen jobber med et sideprosjekt (hvis han forklarte dets betydning for ledere - direkte på arbeidsplassen; eller i ikke-arbeidstid - på eget initiativ), og senere kan dette arbeidet ta opp alt hans nåværende timer."
Mer enn idédugnad
«Lyrisk digresjon. Alex Fakeney Osborne er oppfinneren av idédugnadsmetoden, en fortsettelse av denne i dag er synectics-metoden. Det er merkelig at denne ideen dukket opp under andre verdenskrig, da Osborne befalte et av skipene til en amerikansk lastekonvoi som sto i fare for et torpedoangrep fra en tysk ubåt. Så husket kapteinen teknikken som sjørøverne i middelalderen tyr til: hvis mannskapet fikk problemer, samlet alle sjømennene seg på dekk for å bytte på å foreslå en måte å løse problemet på. Det var mange ideer, inkludert absurde ved første øyekast: for eksempel ideen om å blåse på en torpedo med hele teamet. Men med strålen fra en skipspumpe, som er tilgjengelig på alle skip, er det fullt mulig å bremse en torpedo eller til og med endre kursen. Som et resultat patenterte Osborne til og med en oppfinnelse: en ekstra propell er montert på siden av skipet, som driver en vannstrøm langs siden, og torpedoen glir langs siden.
Vår Jim gjentar stadig at det ikke er så lett å jobbe i en åpen organisasjon. Selv ledelsen får det, siden ingen er spart for å forsvare sin mening. Men dette er akkurat den tilnærmingen som trengs for å oppnå utmerkede resultater:
«Nettbaserte [åpen kildekode]-fora og chatterom er ofte fylt med livlige og noen ganger bittere diskusjoner om alt fra hvordan man best kan fikse en programvarefeil til hvilke nye funksjoner som bør vurderes i neste oppdatering. Som regel er dette den første fasen av diskusjoner, der nye ideer legges frem og akkumuleres, men det er alltid en neste runde - kritisk analyse. Selv om hvem som helst kan delta i disse debattene, må en person være forberedt på å forsvare sin posisjon med all makt. Upopulære ideer vil i beste fall bli avvist, i verste fall latterliggjort.
Til og med Linus Torvalds, skaperen av Linux-operativsystemet, uttrykker sin uenighet med de foreslåtte endringene i koden. En dag kom Linus og David Howells, en av Red Hats ledende utviklere, inn i en heftig debatt om fordelene ved en kodeendring som Red Hat hadde bedt om som ville bidra til å gi sikkerhet til kundene våre. Som svar på Howells' forespørsel skrev Torvalds: «Ærlig talt, dette er [ikke-utskrivbare ord] idiotisk. Alt ser ut til å dreie seg om disse dumme grensesnittene, og av helt dumme grunner. Hvorfor skal vi gjøre dette? Jeg liker ikke den eksisterende X.509-parseren lenger. Dumme komplekse grensesnitt blir laget, og nå vil det være 11 av dem. – Linus 9.»
Ser man bort fra tekniske detaljer, fortsatte Torvalds å skrive i samme ånd i neste melding – og på en slik måte at jeg ikke tør å sitere. Denne tvisten var så høy at den til og med kom inn på sidene til The Wall Street Journal. […]
Denne debatten viser at de fleste selskaper som produserer proprietær, ikke-fri programvare ikke har en åpen debatt om hvilke nye funksjoner eller endringer de kanskje jobber med. Når produktet er klart, sender selskapet det ganske enkelt til kundene og går videre. Samtidig, når det gjelder Linux, avtar ikke diskusjonene om hvilke endringer som trengs og – viktigst av alt – hvorfor de er nødvendige. Dette gjør selvfølgelig hele prosessen mye mer rotete og tidkrevende.»
Slipp tidlig, slipp ofte
Vi kan ikke forutsi fremtiden, så vi må bare prøve:
"Vi opererer etter prinsippet om "tidlig lansering, hyppige oppdateringer." Hovedproblemet til ethvert programvareprosjekt er risikoen for feil eller feil i kildekoden. Jo flere endringer og oppdateringer som samles inn i én versjon (versjon) av programvaren, jo større er sannsynligheten for at det vil være feil i denne versjonen. Utviklere av åpen kildekode har innsett at ved å gi ut programvareversjoner raskt og ofte, reduseres risikoen for alvorlige problemer med et hvilket som helst program – vi bringer tross alt ikke alle oppdateringer til markedet på en gang, men én om gangen for hver versjon. Over tid la vi merke til at denne tilnærmingen ikke bare reduserer feil, men også fører til mer interessante løsninger. Det viser seg at kontinuerlig å gjøre små forbedringer skaper mer innovasjon i det lange løp. Kanskje det ikke er noe overraskende her. Et av nøkkelprinsippene for moderne produksjonsprosesser som kaizen a eller lean b er fokus på små og inkrementelle endringer og oppdateringer.
[…] Mye av det vi jobber med vil kanskje ikke lykkes. Men i stedet for å bruke mye tid på å lure på hva som vil fungere og hva som ikke vil, foretrekker vi å gjennomføre små eksperimenter. De mest populære ideene vil føre til suksess, og de som ikke fungerer vil visne bort av seg selv. På denne måten kan vi prøve mange ting i stedet for bare én ting, uten stor risiko for selskapet.
Dette er en rasjonell måte å allokere ressurser på. For eksempel spør folk meg ofte hvordan vi velger hvilke åpen kildekode-prosjekter som skal kommersialiseres. Mens vi noen ganger setter i gang prosjekter, hopper vi oftest bare inn i eksisterende. En liten gruppe ingeniører – noen ganger bare én person – begynner å bidra til et av åpen kildekode-fellesskapets prosjekter. Hvis prosjektet er vellykket og etterspurt blant våre kunder, begynner vi å bruke mer tid og krefter på det. Hvis ikke, går utviklerne videre til et nytt prosjekt. Innen vi bestemmer oss for å kommersialisere forslaget, kan prosjektet ha vokst i en slik grad at løsningen er åpenbar. Ulike prosjekter, inkludert ikke-programvare, dukker naturlig opp gjennom Red Hat til det blir klart for alle at nå må noen jobbe med dette på heltid.»
Her er et annet sitat fra boken:
«Jeg innså at for å møte denne rollen, må morgendagens ledere ha egenskaper som rett og slett blir oversett i konvensjonelle organisasjoner. For å effektivt lede en åpen organisasjon, må en leder ha følgende egenskaper.
- Personlig styrke og selvtillit. Vanlige ledere bruker posisjonell makt – deres posisjon – for å oppnå suksess. Men i et meritokrati må ledere tjene respekt. Og dette er bare mulig hvis de ikke er redde for å innrømme at de ikke har alle svarene. De må være villige til å diskutere problemer og ta beslutninger raskt for å finne de beste løsningene med teamet sitt.
- Tålmodighet. Media forteller sjelden historier om hvor "tålmodig" en leder er. Men han må virkelig være tålmodig. Når du jobber for å få best mulig innsats og resultater fra teamet ditt, har samtaler i timevis og gjentar ting om og om igjen til det er gjort riktig, må du være tålmodig.
- Høy EQ (emosjonell intelligens). Altfor ofte fremmer vi ledernes intelligens ved å fokusere på deres IQ, når det som virkelig må tas i betraktning er deres emosjonelle intelligenskvotient, eller EQ-poengsum. Å være den smarteste personen blant andre er ikke nok hvis du ikke er i stand til å jobbe med disse menneskene. Når du jobber med fellesskap av engasjerte ansatte som Red Hat, og du ikke har muligheten til å bestille noen rundt, blir din evne til å lytte, behandle analytisk og ikke ta ting personlig utrolig verdifull.
- Annen mentalitet. Ledere som kom fra tradisjonelle organisasjoner ble oppdratt med ånden av quid pro quo (latin for "quid pro quo"), ifølge hvilken enhver handling skulle få en tilstrekkelig avkastning. Men når du ønsker å investere i å bygge et bestemt fellesskap, må du tenke langsiktig. Det er som å prøve å bygge et delikat balansert økosystem, der ethvert feiltrinn kan skape ubalanse og føre til langsiktige tap som du kanskje ikke legger merke til med en gang. Ledere må kvitte seg med tankegangen som krever at de oppnår resultater i dag, for enhver pris, og begynne å gjøre forretninger på en måte som lar dem høste større fordeler ved å investere i fremtiden.»
Og hvorfor er det viktig
Red Hat lever og opererer etter prinsipper som er svært forskjellige fra en tradisjonell hierarkisk organisasjon. Og det fungerer, det gjør oss kommersielt vellykkede og menneskelig lykkelige. Vi oversatte denne boken i håp om å spre prinsippene om åpen organisasjon blant russiske selskaper, blant mennesker som ønsker og kan leve annerledes.
, Prøv det!
Kilde: www.habr.com