En vigtig dag er kommet for Red Hat, det russiske open source-fællesskab og alle involverede – den blev udgivet på russisk . Hun fortæller detaljeret og levende, hvordan vi hos Red Hat giver de bedste ideer og de dygtigste mennesker vejen, og også om, hvordan man ikke farer vild i kaosset og forener millioner af mennesker rundt om i verden.
Denne bog handler også om livet og praksis. Den indeholder en masse råd til alle, der ønsker at lære at bygge en virksomhed op ved hjælp af den åbne organisationsmodel og lede den effektivt. Nedenfor er et par af de vigtigste principper i bogen, som du kan notere dig lige nu.
Jims ansættelseshistorie i virksomheden er bemærkelsesværdig. Det viser, at der ikke er nogen fanfare i open source-verdenen, men der er en ny tilgang til ledelse:
"Efter at have talt med rekrutteringsmanden udtrykte jeg interesse for et interview, og han spurgte, om jeg ville have noget imod at flyve til Red Hats hovedkvarter i Raleigh, North Carolina, på søndag. Jeg syntes søndag var en mærkelig dag at mødes på. Men da jeg alligevel skulle flyve til New York om mandagen, var det generelt på vej, og jeg takkede ja. Jeg gik ombord på et fly fra Atlanta og landede i Raleigh Durham Lufthavn. Derfra tog jeg en taxa, der satte mig af foran Red Hat-bygningen på University of North Carolina campus. Det var søndag kl. 9, og der var ingen i nærheden. Lysene var slukket, og ved kontrol fandt jeg, at dørene var låst. Først troede jeg, at jeg blev narret. Da jeg vendte mig om for at stige ind i taxaen igen, så jeg, at den allerede var gået. Meget snart begyndte det at regne, jeg havde ikke en paraply.
Lige da jeg skulle til at tage et sted hen for at fange en taxa, stoppede Matthew Shulick, senere bestyrelsesformand og administrerende direktør for Red Hat, i sin bil. "Hej," hilste han. "Vil du have noget kaffe?" Dette virkede som en usædvanlig måde at starte et interview på, men jeg vidste, at jeg helt sikkert skulle have noget kaffe. I sidste ende tænkte jeg, at det ville være nemmere for mig at tage en taxa til lufthavnen.
Søndag morgen er ret stille i North Carolina. Det tog os et stykke tid bare at finde en kaffebar, der åbnede før kl. Kaffebaren var ikke den bedste i byen og ikke den reneste, men den virkede og man kunne drikke friskbrygget kaffe der. Vi satte os ved et bord og begyndte at snakke.
Efter omkring tredive minutter eller deromkring indså jeg, at jeg kunne lide, hvordan tingene foregik; Interviewet var ikke traditionelt, men selve samtalen viste sig at være meget interessant. I stedet for at diskutere de finere sider af Red Hats virksomhedsstrategi eller dets image på Wall Street – noget jeg havde forberedt mig på – spurgte Matthew Shulick mere om mine håb, drømme og mål. Nu er det klart for mig, at Shulik vurderede, om jeg ville passe til virksomhedens subkultur og ledelsesstil.
Da vi var færdige, sagde Shulick, at han ville præsentere mig for virksomhedens generaladvokat, Michael Cunningham, og foreslog, at jeg mødte ham nu til en tidlig frokost. Jeg sagde ja, og vi gjorde os klar til at tage afsted. Så opdagede min samtalepartner, at han ikke havde sin pung med. "Ups," sagde han. - Jeg har ingen penge. Og dig?" Dette overraskede mig, men jeg svarede, at jeg havde penge og ikke havde noget imod at betale for kaffen.
Et par minutter senere satte Shulik mig af på en lille mexicansk restaurant, hvor jeg mødte Michael Cunningham. Men igen fulgte intet traditionelt interview eller forretningsmøde, men en anden interessant samtale fandt sted. Da vi skulle betale regningen, viste det sig, at restaurantens kreditkortautomat var gået i stykker, og vi kunne kun tage imod kontanter. Cunningham vendte sig mod mig og spurgte, om jeg var klar til at betale, for han havde ingen kontanter med sig. Siden jeg skulle til New York, havde jeg mange kontanter, så jeg betalte for frokost.
Cunningham tilbød at køre mig til lufthavnen, og vi gik i hans bil. Efter et par minutter spurgte han: "Har du noget imod, hvis jeg stopper og får gas? Vi går på fuld damp." "Intet problem," svarede jeg. Så snart jeg hørte den rytmiske lyd fra pumpen, bankede det på ruden. Det var Cunningham. "Hey, de tager ikke kreditkort her," sagde han. "Må jeg låne nogle penge?" Jeg begyndte at spekulere på, om dette virkelig var et interview eller en form for fidus.
Den næste dag, mens jeg var i New York, diskuterede jeg dette interview med min kone på Red Hat. Jeg fortalte hende, at samtalen var meget interessant, men jeg var ikke sikker på, om disse mennesker var seriøse med at ansætte mig: måske ville de bare have gratis mad og gas? Når jeg husker det møde i dag, forstår jeg, at Shulick og Cunningham simpelthen var åbne mennesker og behandlede mig som enhver anden person, med hvem de kunne få kaffe, frokost eller fylde benzin med. Ja, det er sjovt og endda sjovt, at de begge endte uden penge. Men for dem handlede det ikke om pengene. De, ligesom open source-verdenen, troede ikke på at rulle røde løbere ud eller forsøge at overbevise andre om, at alt var perfekt. De prøvede bare at lære mig bedre at kende, ikke at imponere eller påpege vores forskelligheder. De ville vide, hvem jeg var.
Mit første interview hos Red Hat viste mig tydeligt, at arbejdet her var anderledes. Denne virksomhed havde ikke et traditionelt hierarki og særbehandling af ledere, i hvert fald i den form, der er sædvanlig i de fleste andre virksomheder. Med tiden lærte jeg også, at Red Hat tror på princippet om meritokrati: Det er altid værd at prøve at implementere den bedste idé, uanset om den kommer fra den øverste ledelse eller fra en sommerpraktikant. Med andre ord, min første oplevelse hos Red Hat introducerede mig til, hvordan fremtidens lederskab ser ud.”
Tips til at dyrke meritokrati
Meritokrati er kerneværdien af open source-fællesskabet. Det er lige meget for os, hvilket niveau af pyramiden du besætter, det vigtigste er, hvor gode dine ideer er. Her er hvad Jim foreslår:
- Sig aldrig: "Det er det, chefen vil have", og stol ikke på hierarki. Dette kan hjælpe dig på kort sigt, men det er ikke sådan, du opbygger et meritokrati.
- Offentligt anerkend succeser og vigtige bidrag. Dette kunne være en simpel tak-e-mail med hele teamet på kopi.
- Overvej: er din autoritet en funktion af din position i hierarkiet (eller adgang til privilegeret information), eller er det et resultat af den respekt, du har optjent? Hvis den første, skal du begynde at arbejde på den anden.
- Bed om feedback og indhent ideer om et bestemt emne. Du bør reagere på alt, test kun det bedste. Men tag ikke bare de bedste ideer og gå videre med dem – benyt enhver lejlighed til at styrke meritokratiets ånd, og giv kredit til alle, der fortjener det.
- Anerkend et eksemplarisk medlem af dit team ved at tilbyde en interessant opgave, selvom den ikke er inden for deres sædvanlige arbejdsfelt.
Lad dine rockstjerner følge deres passion
Entusiasme og involvering er to meget vigtige ord i en åben organisation. De gentages konstant i bogen. Men du kan ikke få passionerede kreative mennesker til at arbejde hårdt, vel? Ellers får du simpelthen ikke alt, hvad deres talent har at byde på. Hos Red Hat udjævnes forhindringer for deres egne projekter så meget som muligt:
”For at drive innovation forsøger virksomheder mange ting. Googles tilgang er interessant. Siden Google blev kendt i alle hjem i 2004, har ledere og ideologer i internetbranchen forsøgt at opklare virksomhedens hovedhemmelighed for at gentage dens imponerende succes. Et af de mest berømte, men i øjeblikket lukkede programmer var, at alle Google-medarbejdere blev bedt om at bruge 20 procent af deres tid på næsten alt, hvad de ville. Tanken var, at hvis medarbejderne forfulgte deres egne projekter og ideer, som de brændte for uden for arbejdet, ville de begynde at innovere. Sådan opstod succesfulde tredjepartsprojekter: GoogleSuggest, AdSense til indhold og Orkut; de kom alle fra dette 20 procent eksperiment – en imponerende liste! […]
Hos Red Hat tager vi en mindre formel tilgang. Vi har ikke en fast politik for, hvor meget tid hver af vores medarbejdere skal bruge på "innovation". I stedet for at give folk dedikeret tid til at uddanne sig selv, sørger vi for, at medarbejderne optjener retten til at bruge deres tid på at lære nye ting. For at være ærlig har mange mennesker meget lidt sådan tid, men der er også dem, der kan bruge næsten hele deres arbejdsdag på innovation.
Det mest typiske tilfælde ser nogenlunde sådan ud: nogen arbejder på et sideprojekt (hvis han forklarede dets betydning for ledere - direkte på arbejdspladsen; eller i ikke-arbejdstid - på eget initiativ), og senere kan dette arbejde fylde alt hans nuværende timer."
Mere end brainstorming
“Lyrisk digression. Alex Fakeney Osborne er opfinderen af brainstorming-metoden, en fortsættelse af denne i dag er synectic-metoden. Det er mærkeligt, at denne idé dukkede op under Anden Verdenskrig, da Osborne kommanderede et af skibene på en amerikansk fragtkonvoj, der var i fare for et torpedoangreb fra en tysk ubåd. Så huskede kaptajnen den teknik, som middelalderens pirater tyede til: Hvis besætningen kom i problemer, samledes alle sømændene på dækket for på skift at foreslå en måde at løse problemet på. Der var mange ideer, inklusive absurde ved første øjekast: for eksempel ideen om at blæse på en torpedo med hele holdet. Men med strålen fra en skibspumpe, som er tilgængelig på ethvert skib, er det sagtens muligt at bremse en torpedo eller endda ændre dens kurs. Som et resultat patenterede Osborne endda en opfindelse: en ekstra propel er monteret på siden af skibet, som driver en strøm af vand langs siden, og torpedoen glider ved siden af."
Vores Jim gentager konstant, at det ikke er så nemt at arbejde i en åben organisation. Selv ledelsen får det, da ingen er skånet for behovet for at forsvare deres mening. Men dette er præcis den tilgang, der er nødvendig for at opnå fremragende resultater:
“Online [open source] fora og chatrum er ofte fyldt med livlige og til tider hårde diskussioner om alt fra hvordan man bedst kan rette en softwarefejl til hvilke nye funktioner der skal overvejes i den næste opdatering. Som regel er dette den første fase af diskussioner, hvor nye ideer fremsættes og akkumuleres, men der er altid en næste runde - kritisk analyse. Selvom enhver kan deltage i disse debatter, skal en person være parat til at forsvare sin holdning med al sin magt. Upopulære ideer vil i bedste fald blive afvist, i værste fald latterliggjort.
Selv Linus Torvalds, skaberen af Linux-operativsystemet, udtrykker sin uenighed med de foreslåede ændringer af koden. En dag kom Linus og David Howells, en af Red Hats førende udviklere, ind i en heftig debat om fordelene ved en kodeændring, som Red Hat havde anmodet om, og som ville hjælpe med at give sikkerhed til vores kunder. Som svar på Howells' anmodning skrev Torvalds: "Helt ærligt, dette er [ikke-udskrivbare ord] idiotisk. Alt ser ud til at dreje sig om disse dumme grænseflader, og det af helt dumme grunde. Hvorfor skulle vi gøre dette? Jeg kan ikke lide den eksisterende X.509-parser længere. Der bliver skabt dumme komplekse grænseflader, og nu vil der være 11 af dem. – Linus 9.”
Ser man bort fra tekniske detaljer, fortsatte Torvalds med at skrive i samme ånd i næste besked – og det på en sådan måde, at jeg ikke tør citere. Denne strid var så høj, at den endda kom ind på siderne i The Wall Street Journal. […]
Denne debat viser, at de fleste virksomheder, der producerer proprietær, ikke-fri software, ikke har en åben debat om, hvilke nye funktioner eller ændringer de måske arbejder på. Når produktet er klar, sender virksomheden det blot til kunderne og går videre. Samtidig forsvinder diskussionerne om, hvilke ændringer der er nødvendige og – vigtigst af alt – hvorfor de er nødvendige, ikke i Linux tilfælde. Dette gør selvfølgelig hele processen meget mere rodet og tidskrævende.”
Slip tidligt, slip ofte
Vi kan ikke forudsige fremtiden, så vi må bare prøve:
"Vi opererer efter princippet om "tidlig lancering, hyppige opdateringer." Nøgleproblemet ved ethvert softwareprojekt er risikoen for fejl eller fejl i kildekoden. Det er klart, at jo flere ændringer og opdateringer, der indsamles i én udgivelse (version) af software, jo større er sandsynligheden for, at der vil være fejl i denne version. Open source softwareudviklere har indset, at ved at frigive softwareversioner hurtigt og hyppigt, mindskes risikoen for alvorlige problemer med ethvert program – vi bringer trods alt ikke alle opdateringer til markedet på én gang, men én ad gangen for hver version. Med tiden har vi bemærket, at denne tilgang ikke kun reducerer fejl, men også fører til mere interessante løsninger. Det viser sig, at løbende små forbedringer skaber mere innovation i det lange løb. Måske er der ikke noget overraskende her. Et af nøgleprincipperne i moderne fremstillingsprocesser såsom kaizen a eller lean b er fokus på små og trinvise ændringer og opdateringer.
[…] Meget af det, vi arbejder med, lykkes måske ikke. Men i stedet for at bruge meget tid på at spekulere på, hvad der virker, og hvad der ikke vil, foretrækker vi at udføre små eksperimenter. De mest populære ideer vil føre til succes, og de, der ikke virker, vil visne væk af sig selv. På denne måde kan vi prøve mange ting frem for kun én ting, uden den store risiko for virksomheden.
Dette er en rationel måde at allokere ressourcer på. For eksempel spørger folk mig ofte, hvordan vi vælger, hvilke open source-projekter, der skal kommercialiseres. Mens vi nogle gange sætter projekter i gang, springer vi oftere end ikke blot ud i eksisterende. En lille gruppe ingeniører – nogle gange kun én person – begynder at bidrage til et af open source-fællesskabets projekter. Hvis projektet er vellykket og efterspurgt blandt vores kunder, begynder vi at bruge mere tid og kræfter på det. Hvis ikke, går udviklerne videre til et nyt projekt. På det tidspunkt, hvor vi beslutter os for at kommercialisere forslaget, kan projektet være vokset i en sådan grad, at løsningen er oplagt. Forskellige projekter, herunder ikke-software, dukker naturligvis op i hele Red Hat, indtil det bliver klart for alle, at nu skal nogen arbejde på dette på fuld tid."
Her er endnu et citat fra bogen:
“Jeg indså, at for at opfylde denne rolle, skal morgendagens ledere have karakteristika, som simpelthen overses i konventionelle organisationer. For effektivt at lede en åben organisation skal en leder have følgende egenskaber.
- Personlig styrke og selvtillid. Almindelige ledere bruger positionel magt – deres position – for at opnå succes. Men i et meritokrati skal ledere tjene respekt. Og det er kun muligt, hvis de ikke er bange for at indrømme, at de ikke har alle svarene. De skal være villige til at diskutere problemer og træffe beslutninger hurtigt for at finde de bedste løsninger sammen med deres team.
- Tålmodighed. Medierne fortæller sjældent historier om, hvor "tålmodig" en leder er. Men han skal virkelig være tålmodig. Når du arbejder på at få den bedste indsats og resultater fra dit team, har samtaler i timevis og gentager tingene igen og igen, indtil det er gjort rigtigt, skal du være tålmodig.
- Høj EQ (emotionel intelligens). Alt for ofte fremmer vi lederes intelligens ved at fokusere på deres IQ, når det, der virkelig skal tages i betragtning, er deres følelsesmæssige intelligenskvotient eller EQ-score. At være den klogeste person blandt andre er ikke nok, hvis du ikke er i stand til at arbejde med disse mennesker. Når du arbejder med fællesskaber af engagerede medarbejdere som Red Hat, og du ikke har mulighed for at bestille nogen rundt, bliver din evne til at lytte, bearbejde analytisk og ikke tage ting personligt utrolig værdifuld.
- En anden mentalitet. Ledere, der kom fra traditionelle organisationer, blev opdraget med ånden af quid pro quo (latin for "quid pro quo"), ifølge hvilken enhver handling skulle modtage et passende afkast. Men når du ønsker at investere i at opbygge et bestemt fællesskab, skal du tænke langsigtet. Det er som at forsøge at bygge et delikat afbalanceret økosystem, hvor ethvert forkert skridt kan skabe en ubalance og føre til langsigtede tab, som du måske ikke bemærker med det samme. Ledere skal slippe af med den tankegang, der kræver, at de opnår resultater i dag, for enhver pris, og begynde at drive forretning på en måde, der giver dem mulighed for at høste større fordele ved at investere i fremtiden.”
Og hvorfor er det vigtigt
Red Hat lever og opererer efter principper, der er meget forskellige fra en traditionel hierarkisk organisation. Og det virker, det gør os kommercielt succesfulde og menneskeligt glade. Vi oversatte denne bog i håbet om at udbrede principperne om åben organisation blandt russiske virksomheder, blandt mennesker, der ønsker og kan leve anderledes.
, Prøv det!
Kilde: www.habr.com