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
