En vigtig dag er kommet for Red Hat, det russiske open source-fĂŠllesskab og alle involverede â bogen . Den beskriver detaljeret og levende, hvordan vi i Red Hat giver de bedste idĂ©er og de mest talentfulde mennesker en chance, og hvordan man ikke mister sig selv i kaos og samler millioner af mennesker verden over.
Denne bog handler ogsÄ om liv og praksis. Den indeholder mange rÄd til alle, der Þnsker at lÊre at bygge en virksomhed efter modellen for en Äben organisation og lede den effektivt. Nedenfor er nogle af de vigtigste principper nÊvnt i bogen, som du kan tage til efterretning allerede nu.
Historien om Jims ansĂŠttelse i virksomheden er bemĂŠrkelsesvĂŠrdig. Den viser, at der i en Ă„ben kildekode-verden ikke er nogen fanfare, men derimod en ny tilgang til ledelse:
«Efter samtalen med rekrutteringspersonen gav jeg udtryk for min interesse for et interview, og han spurgte, om jeg havde noget imod at flyve til Red Hats hovedkontor i Raleigh, North Carolina, om sÞndagen. Jeg tÊnkte, at sÞndag var en mÊrkelig dag for et mÞde. Men da jeg alligevel skulle flyve til New York om mandagen, var det stort set pÄ vejen, sÄ jeg sagde ja. Jeg satte mig pÄ flyet fra Atlanta og landede i Raleigh-Durham lufthavn. Derfra tog jeg en taxa, som satte mig af foran Red Hats bygning pÄ North Carolina University's campus. Det var sÞndag, klokken var 9:30 om morgenen, og der var ikke nogen i nÊrheden. Lyset var slukket, og efter at have tjekket, fandt jeg ud af, at dÞrene var lÄst. FÞrst tÊnkte jeg, at de drillede mig. Da jeg vendte mig om for at gÄ tilbage til taxaen, sÄ jeg, at den allerede var kÞrt.
Bare da jeg var ved at overveje at gÄ et sted hen for at fange en taxa, kom Matthew Szulik, senere bestyrelsesformand og administrerende direktÞr for Red Hat, rullende i sin bil. «Hej,» hilste han. «Vil du have noget kaffe?» Det virkede som en usÊdvanlig begyndelse pÄ et interview, men jeg vidste, at jeg bestemt havde brug for at fÄ noget kaffe. Jeg tÊnkte, at det ville gÞre det lettere for mig at fÄ en taxa til lufthavnen senere.
SÞndag formiddag i North Carolina er der temmelig stille. Det tog os lidt tid bare at finde en café, der Äbnede fÞr middag. Caféen var ikke den bedste i byen og heller ikke den reneste, men den var Äben, og man kunne fÄ en god kop kaffe. Vi satte os ved et bord og begyndte at tale.
Efter omkring tredive minutter indsĂ„ jeg, at jeg kunne lide, hvordan det hele gik; interviewet var ikke traditionelt, men selve samtalen viste sig at vĂŠre meget interessant. I stedet for at diskutere detaljerne i Red Hats virksomhedsstrategi eller dens image pĂ„ Wall Street â altsĂ„ det, jeg var forberedt pĂ„ â spurgte Matthew Shulik mere om mine hĂ„b, drĂžmme og mĂ„l. Nu forstĂ„r jeg, at Shulik vurderede, om jeg ville passe ind i virksomhedens subkultur og ledelsesstil.
Da vi var fÊrdige, meddelte Shulik, at han gerne ville introducere mig for virksomhedens hovedadvokat Michael Cunningham, og han foreslog, at vi mÞdtes med ham nu til en tidlig frokost. Jeg accepterede, og vi gjorde klar til at gÄ. SÄ opdagede min samtalepartner, at han ikke havde sin pung med. "Ups," sagde han. "Jeg har ikke penge. Hvad med dig?" Det tog mig lidt pÄ sengen, men jeg svarede, at jeg havde penge, og jeg havde intet imod at betale for kaffen.
Efter et par minutter satte Shulik mig af ved en lille mexicansk café, hvor jeg mÞdte Michael Cunningham. Men der fulgte igen ikke noget traditionelt interview eller forretningsmÞde, men derimod endnu en interessant samtale. Da vi skulle til at betale regningen, viste det sig, at restaurantens kreditkortmaskine var i stykker, og at vi kun kunne betale kontant. Cunningham vendte sig mod mig og spurgte, om jeg var villig til at betale, fordi han ikke havde kontanter med. Da jeg skulle til New York, havde jeg masser af kontanter, sÄ jeg betalte for frokosten.
Canningham tilbĂžd at kĂžre mig til lufthavnen, og vi kĂžrte i hans bil. Efter et par minutter spurgte han: âHar du noget imod, at jeg stopper for at tanke? Vi skal kĂžre hurtigtâ. â âIngen problemerâ, svarede jeg. SĂ„ snart jeg hĂžrte den rytmiske lyd fra pumpen, blev der banket pĂ„ vinduet. Det var Canningham. âHey, de accepterer ikke kreditkort herâ, fortalte han. âMĂ„ jeg lĂ„ne lidt penge?â Jeg begyndte at spekulere pĂ„, om dette virkelig var et interview, eller om det var en form for svindel.
NÊste dag, mens jeg var i New York, talte jeg med min kone om interviewet hos Red Hat. Jeg fortalte hende, at samtalen var meget interessant, men jeg var ikke sikker pÄ, om de virkelig havde til hensigt at ansÊtte mig: mÄske havde de bare brug for gratis mad og benzin? NÄr jeg ser tilbage pÄ det mÞde i dag, forstÄr jeg, at Shulik og Canningham bare var Äbne mennesker, der behandlede mig som enhver anden, man kunne tage en kop kaffe med, fÄ frokost eller tanke benzin sammen med. Ja, det er sjovt og endda komisk, at de begge endte uden penge. Men for dem handlede det ikke om penge. De, ligesom verden omkring open source, troede ikke pÄ at rulle det rÞde lÞber ud eller pÄ at forsÞge at overbevise intervieweren om, at alt var perfekt. De ville bare gerne lÊre mig at kende bedre og forsÞgte ikke at imponere eller pÄpege vores forskelle. De ville vide, hvem jeg var.
Mit fÞrste interview hos Red Hat klarede tydeligt at vise mig, at arbejdet her har en anden karakter. I denne virksomhed var der ikke den traditionelle hierarki og sÊrlige ordninger for ledere, i hvert fald ikke i den form, som det er almindeligt i de fleste andre virksomheder. Over tid lÊrte jeg ogsÄ, at Red Hat tror pÄ meritokrati-princippet: det er altid vÊrd at forsÞge at realisere den bedste idé, uanset om den kommer fra ledelsen eller en praktikant ansat til sommerjob. Med andre ord, mit fÞrste indtryk af Red Hat introducerede mig til, hvordan fremtidens ledelse ser ud.
Tips til at kultivere meritokrati
Meritokrati er den grundlÊggende vÊrdi i open source-fÊllesskabet. Det betyder ikke noget, hvilken position du har i pyramiden; det er vigtigt, hvor gode dine idéer er. Her er hvad Jim foreslÄr:
- Sig aldrig: "Det Ăžnsker chefen" â og stol ikke pĂ„ hierarkiet. Det kan hjĂŠlpe dig pĂ„ kort sigt, men du bygger ikke meritokrati pĂ„ den mĂ„de.
- Anerkend offentligt succeser og vigtige bidrag til det fÊlles mÄl. Det kan vÊre en simpel takke-email, hvor hele holdet er cc'et.
- Overvej: Er din autoritet afhĂŠngig af din placering i hierarkiet (eller adgang til privilegeret information), eller er den et resultat af den respekt, du har opnĂ„et? Hvis det fĂžrste â sĂ„ begynd at arbejde pĂ„ det sidstnĂŠvnte.
- Bed om feedback og indsamle idĂ©er om et specifikt emne. Du skal reagere pĂ„ alt, og afprĂžve kun det bedste. Men tag ikke blot de bedste idĂ©er og gĂ„ videre med dem â brug enhver mulighed for at styrke Ă„nden af meritokrati ved at anerkende alle, der fortjener det.
- FremhÊv et fremragende medlem af dit team ved at give dem en spÊndende opgave, selvom den ikke relaterer til deres sÊdvanlige arbejdsomrÄde.
Lad jeres "rockstjerner" fĂžlge deres passion.
Entusiasme og engagement â to meget vigtige ord i en Ă„ben organisation. De gentages konstant i bogen. Men du kan ikke tvinge passionerede kreative mennesker til at arbejde "fra 9 til 5", vel? Ellers fĂ„r du ikke alt, hvad deres talent kan tilbyde. I Red Hat bliver hindringer for egne projekter minimeret mest muligt:
"For at styre innovation prĂžver virksomheder mange ting. Googles tilgang er interessant. Siden Google blev kendt i hvert hjem fra 2004, har ledere og ideologer i internetbranchen forsĂžgt at finde den hemmelige opskrift bag virksomhedens imponerende succes. Et af de mest kendte, men i Ăžjeblikket lukkede programmer, var, at alle Google-medarbejdere fik mulighed for at bruge 20 procent af deres arbejdstid pĂ„ nĂŠsten alt, hvad de Ăžnskede. Ideen var den fĂžlgende: hvis medarbejderne begyndte at realisere deres egne projekter og idĂ©er, som de brĂŠndte for udover arbejdet, ville de begynde at skabe innovation. SĂ„ledes opstod succesfulde sideprojekter: GoogleSuggest, AdSense for Content og Orkut; alle kom fra dette eksperiment med de 20 procent â en imponerende liste! [âŠ]"
Vi hos Red Hat anvender en mindre formel tilgang. Vi har ikke nogen fast politik for, hvor meget tid hver af vores medarbejdere skal bruge pĂ„ 'innovation'. I stedet for at afsĂŠtte tid til selvstudium, gĂžr vi det muligt for medarbejderne at optjene retten til at bruge deres tid pĂ„ nye projekter. Ărligt talt har mange ikke meget tid til dette, men der er ogsĂ„ dem, der kan bruge nĂŠsten hele arbejdsdagen pĂ„ innovation.
Det mest typiske tilfĂŠlde ser omtrent sĂ„dan ud: nogen arbejder pĂ„ et sideprojekt (hvis de har forklaret medarbejderne dets betydning â direkte pĂ„ arbejdspladsen; eller i fritiden â pĂ„ egen initiative), og senere kan dette arbejde fylde hele deres arbejdstid.
Mere end bare brainstorming
«Et lyrisk afbrud. Alex F. Osborn â opfinderen af metode for 'brainstorming', som i dag er grundlaget for synectics-metoden. Interessant nok opstod denne idĂ© under Anden Verdenskrig, da Osborn befandt sig som kaptajn pĂ„ et af de amerikanske lastskibe, der blev truet af et tysk ubĂ„dsangreb. Dengang huskede kaptajnen en teknik, som piraterne i middelalderen brugte: hvis besĂŠtningen kom i problemer, samlede alle sĂžfolkene om bord for at foreslĂ„ lĂžsninger pĂ„ skift. Der kom mange idĂ©er, herunder tilsyneladende absurde som idĂ©en om at blĂŠse pĂ„ torpedoen hele besĂŠtningen. Men med strĂžmmen fra skibets pumpe, der findes pĂ„ hvert skib, kan torpedoen faktisk bremses eller endda ĂŠndre kurs. Som fĂžlge heraf fik Osborn endda patent pĂ„ opfindelsen: en ekstra skrue monteres i skibets skrog, som driver en strĂ„le vand langs bordet, mens torpedoen glider ved siden af.
Vores Jim gentager konstant, at det ikke er sÄ let at arbejde i en Äben organisation. Selv ledelsen fÄr sin del, da ingen slipper for at skulle forsvare sin mening. Men netop denne tilgang er nÞdvendig for at opnÄ fremragende resultater:
Online forum [open source developers] and chats are often filled with lively, and sometimes sharp discussions about everything â from how to best fix a software bug to what new features to consider in the next update. Typically, this is the first phase of discussions, where new ideas are put forward and accumulated, but there is always a subsequent round â critical analysis. While anyone can participate in these debates, one needs to be prepared to defend their position with all their might. Unpopular ideas may be dismissed at best, or ridiculed at worst.
Even Linus Torvalds, the creator of the Linux operating system, expresses his disagreement with proposed changes to the code. Once, Linus and David Howells, a leading developer at Red Hat, engaged in a heated debate about the merits of the code changes requested by Red Hat, which would help ensure security for our clients. In response to Howells' request, Torvalds wrote: "Honestly, this [expletive] is idiocy. Everything seems to revolve around these stupid interfaces, and for completely idiotic reasons. Why should we do it this way? I'm already not fond of the existing X.509 parser. Idiotic complex interfaces are being created, and now there will be 11 of them. â Linus 9".
Setting aside the technical details, Torvalds continued to write in the same vein in his next message â so much so that I would not dare to quote it. This dispute was so loud that it even made it into the pages of The Wall Street Journal. [âŠ]
This dispute shows that in most companies producing proprietary, non-free software, there are no open debates about what new features or changes they might be working on. When the product is ready, the company simply sends it to clients and moves on. At the same time, in the case of Linux, discussions about what exactly changes are needed and â most importantly â why they are necessary do not quiet down. This, of course, makes the whole process much messier and more labor-intensive.
Release early, release often
We cannot foresee the future, so we must just try:
«Vi arbejder ud fra princippet om 'hurtig lancering, hyppige opdateringer'. NĂžgleproblemet for enhver softwareprojekt er risikoen for fejl eller bugs i kildekoden. Det er Ă„benlyst, at jo flere ĂŠndringer og opdateringer der samles i Ă©n udgivelse (version) af softwaren, jo stĂžrre er sandsynligheden for, at denne version vil have bugs. Udviklere af open source-software har indset, at med hurtig og hyppig udgivelse af softwareversioner mindskes risikoen for alvorlige problemer med et hvilket som helst program â for vi lancerer ikke alle opdateringer pĂ„ Ă©n gang, men i portioner til hver version. Over tid har vi bemĂŠrket, at denne tilgang ikke kun reducerer antallet af fejl, men ogsĂ„ fĂžrer til mere interessante lĂžsninger. Det viser sig, at ved konstant at lave smĂ„ forbedringer skabes der i sidste ende flere innovationer. MĂ„ske er der ikke noget overraskende i dette. Et af de centrale principper for moderne produktionsprocesser, sĂ„som kaizen a eller lean b, er fokus pĂ„ smĂ„ og gradvise ĂŠndringer og opdateringer.
[âŠ] Meget af det, vi arbejder med, kan mĂ„ske ikke fĂžre til succes. Men i stedet for at bruge en masse tid pĂ„ at gruble over, hvad der vil fungere, og hvad der ikke vil, foretrĂŠkker vi at lave smĂ„ eksperimenter. De mest efterspurgte idĂ©er vil fĂžre til succes, mens dem, der ikke fungerer, vil visne vĂŠk af sig selv. PĂ„ den mĂ„de kan vi prĂžve mange ting, i stedet for kun Ă©n, uden stor risiko for virksomheden.
Dette er en rationel mĂ„de at fordele ressourcer pĂ„. For eksempel spĂžrger folk ofte mig, hvordan vi vĂŠlger, hvilke open source-projekter der skal kommercialiseres. Selvom vi nogle gange initierer projekter, tilslutter vi os oftere eksisterende. En lille gruppe ingeniĂžrer â og nogle gange kun Ă©n person â begynder at bidrage til et af samfundets open source-projekter. Hvis projektet er succesfuldt og efterspurgt af 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 at kommercialisere tilbuddet, kan projektet vĂŠre vokset til en stĂžrrelse, hvor beslutningen er indlysende. Mange forskellige projekter, herunder dem der ikke er relateret til software, opstĂ„r naturligt i hele Red Hat, indtil det bliver klart for alle, at nogen nu bliver nĂždt til at arbejde med dette kontinuerligt.
Her er endnu et citat fra bogen:
«Jeg indsÄ, at for at leve op til en sÄdan rolle, skal morgendagens ledere have egenskaber, som almindelige organisationer slet ikke fokuserer pÄ. For effektivt at lede en Äben organisation skal lederen have fÞlgende kvaliteter.
- Personlig styrke og selvtillid. Almindelige ledere bruger positionsmagt â deres stilling â til at opnĂ„ succes. Men i en meritokratisk kultur skal ledere fortjene respekt. Og det er kun muligt, hvis de ikke er bange for at indrĂžmme, at de ikke har svarene pĂ„ alle spĂžrgsmĂ„l. De skal vĂŠre villige til at diskutere problemer og hurtigt trĂŠffe beslutninger for at finde de bedste lĂžsninger sammen med deres team.
- TÄlmodighed. Nyhedsmedierne fortÊller sjÊldent historier om, hvor "tÄlmodig" en leder er. Men de skal virkelig vÊre tÄlmodige. NÄr du arbejder for at fÄ det bedste fra dit teams indsats og resultater, bruger timer pÄ dialog og gentager noget igen og igen, indtil alt er udfÞrt korrekt, skal du have tÄlmodighed.
- HÞj EQ (emotionel intelligens). Alt for ofte reklamerer vi for lederen intelligens, med fokus pÄ deres IQ, nÄr det i virkeligheden er nÞdvendigt at tage hensyn til deres emotionelle intelligenskvotient, eller EQ-vurdering. At vÊre den klogeste person blandt andre er ikke nok, hvis du ikke er i stand til at samarbejde med disse mennesker. NÄr du arbejder med grupper af engagerede medarbejdere, som i Red Hat, og ikke har mulighed for at befale nogen, bliver din evne til at lytte, analysere og ikke tage alt personligt utrolig vÊrdifuld.
- En anden mentalitet. Ledere, der kommer fra traditionelle organisationer, er opdraget i Änden af quid pro quo (lat. «gerning for gerning»), hvor hver handling skal give et passende udbytte. Men nÄr du skal investere i opbygningen af et bestemt fÊllesskab, bÞr du tÊnke langsigtet. Det er som at forsÞge at bygge et fint afbalanceret Þkosystem, hvor enhver forkert skridt kan skabe ubalance og fÞre til langsigtede tab, som du mÄske ikke straks bemÊrker. Ledere mÄ frigÞre sig fra den type tankegang, der krÊver, at de opnÄr resultater med det samme og for enhver pris, og begynde at forretningsfÞre pÄ en mÄde, der muliggÞr stÞrre gevinster ved at investere i fremtiden.
Og hvorfor det er vigtigt
Red Hat lever og arbejder efter principper, der er meget forskellige fra en traditionsorganisation med hierarkisk struktur. Og det fungerer, det gÞr os kommercielt succesfulde og menneskeligt lykkelige. Vi har oversat denne bog i hÄbet om at sprede principperne for en Äben organisation blandt russiske virksomheder, blandt folk der Þnsker og kan leve anderledes.
, prĂžv!
Kilde: habr.com
