En viktig dag har kommit för Red Hat, den ryska öppen källkodsgemenskapen och alla inblandade – den publicerades på ryska . Hon berättar i detalj och levande hur vi på Red Hat ger de bästa idéerna och de mest begåvade människorna vägen, och även om hur man inte går vilse i kaoset och förenar miljontals människor runt om i världen.
Den här boken handlar också om livet och praktiken. Den innehåller många råd för alla som vill lära sig att bygga ett företag med den öppna organisationsmodellen och effektivt hantera det. Nedan finns några av de viktigaste principerna i boken som du kan ta del av just nu.
Jims anställningshistoria hos företaget är anmärkningsvärd. Det visar att det inte finns någon fanfar i världen med öppen källkod, men det finns ett nytt förhållningssätt till ledarskap:
"Efter att ha pratat med rekryteraren uttryckte jag intresse för en intervju och han frågade om jag skulle ha något emot att flyga till Red Hats högkvarter i Raleigh, North Carolina, på söndag. Jag tyckte att söndagen var en konstig dag att träffas på. Men eftersom jag ändå skulle flyga till New York på måndag var det i allmänhet på väg, och jag tackade ja. Jag gick ombord på ett plan från Atlanta och landade på Raleigh Durham Airport. Därifrån tog jag en taxi som släppte av mig framför Red Hat-byggnaden på University of North Carolinas campus. Det var söndag, 9:30, och ingen var i närheten. Belysningen var släckt och vid kontroll upptäckte jag att dörrarna var låsta. Först trodde jag att jag blev lurad. När jag vände mig om för att gå in i taxin igen såg jag att den redan hade gått. Mycket snart började det regna, jag hade inget paraply.
Precis när jag skulle åka någonstans för att ta en taxi, stannade Matthew Shulick, senare styrelseordförande och VD för Red Hat, upp i sin bil. "Hej", hälsade han. "Vill du ha lite kaffe?" Det här verkade vara ett ovanligt sätt att börja en intervju, men jag visste att jag definitivt behövde få lite kaffe. I slutändan tänkte jag att det skulle vara lättare för mig att ta en taxi till flygplatsen.
Söndagsmorgnar är ganska lugna i North Carolina. Det tog oss ett tag bara att hitta ett kafé som öppnade före kl. Kaféet var inte det bästa i stan och inte det renaste, men det fungerade och där kunde man dricka nybryggt kaffe. Vi satte oss vid ett bord och började prata.
Efter ungefär trettio minuter insåg jag att jag gillade hur det gick; Intervjun var inte traditionell, men själva samtalet visade sig vara mycket intressant. Istället för att diskutera de finare punkterna i Red Hats företagsstrategi eller dess image på Wall Street – något jag hade förberett mig på – frågade Matthew Shulick mer om mina förhoppningar, drömmar och mål. Nu står det klart för mig att Shulik bedömde om jag skulle passa in i företagets subkultur och ledarstil.
När vi var klara sa Shulick att han ville presentera mig för företagets chefsjurist, Michael Cunningham, och föreslog att jag skulle träffa honom nu för en tidig lunch. Jag gick med på det och vi gjorde oss redo att gå. Då upptäckte min samtalspartner att han inte hade sin plånbok med sig. "Hoppsan," sa han. - Jag har inga pengar. Och du?" Detta överraskade mig, men jag svarade att jag hade pengar och inte hade något emot att betala för kaffet.
Några minuter senare släppte Shulik av mig på en liten mexikansk restaurang, där jag träffade Michael Cunningham. Men återigen följde ingen traditionell intervju eller affärsmöte, utan ett annat intressant samtal ägde rum. När vi skulle betala räkningen visade det sig att restaurangens kreditkortsautomat var trasig och vi kunde bara ta emot kontanter. Cunningham vände sig till mig och frågade om jag var redo att betala, eftersom han inte hade några kontanter med sig. Sedan jag skulle till New York hade jag mycket kontanter, så jag betalade för lunchen.
Cunningham erbjöd sig att köra mig till flygplatsen och vi åkte i hans bil. Efter några minuter frågade han: "Har du något emot om jag stannar och får gas? Vi kommer att gå för fullt." "Inga problem", svarade jag. Så fort jag hörde pumpens rytmiska ljud knackade det på fönstret. Det var Cunningham. "Hej, de tar inte kreditkort här," sa han. "Kan jag låna pengar?" Jag började undra om det här verkligen var en intervju eller någon form av bluff.
Nästa dag, medan jag var i New York, diskuterade jag den här intervjun med min fru på Red Hat. Jag sa till henne att samtalet var väldigt intressant, men jag var inte säker på om de här personerna menade allvar med att anställa mig: de kanske bara ville ha gratis mat och bensin? När jag minns det mötet idag förstår jag att Shulick och Cunningham helt enkelt var öppna människor och behandlade mig som vilken annan person som helst som de kunde ta kaffe, lunch med eller tanka med. Ja, det är roligt och till och med roligt att de båda slutade utan pengar. Men för dem handlade det inte om pengarna. De, liksom open source-världen, trodde inte på att rulla ut röda mattor eller försöka övertyga andra om att allt var perfekt. De försökte bara lära känna mig bättre, inte försöka imponera på eller påpeka våra olikheter. De ville veta vem jag var.
Min första intervju på Red Hat visade mig tydligt att arbetet här var annorlunda. Detta företag hade ingen traditionell hierarki och särbehandling av chefer, åtminstone i den form som är bruklig i de flesta andra företag. Med tiden har jag också lärt mig att Red Hat tror på principen om meritokrati: det är alltid värt att försöka implementera den bästa idén, oavsett om den kommer från ledningen eller från en sommarpraktikant. Med andra ord, min första erfarenhet på Red Hat introducerade mig till hur framtiden för ledarskap ser ut.”
Tips för att odla meritokrati
Meritokrati är kärnvärdet för öppen källkodsgemenskap. Det spelar ingen roll för oss vilken nivå av pyramiden du upptar, det viktigaste är hur bra dina idéer är. Här är vad Jim föreslår:
- Säg aldrig "Det är vad chefen vill" och lita inte på hierarkin. Detta kan hjälpa dig på kort sikt, men det är inte så du bygger en meritokrati.
- Erkänn offentligt framgångar och viktiga bidrag. Detta kan vara ett enkelt tackmeddelande med hela teamet på kopia.
- Tänk på: är din auktoritet en funktion av din position i hierarkin (eller tillgång till privilegierad information), eller är det ett resultat av den respekt du har förtjänat? Om den första, börja arbeta med den andra.
- Be om feedback och samla idéer om ett specifikt ämne. Man ska reagera på allt, testa bara det bästa. Men ta inte bara de bästa idéerna och gå vidare med dem – ta alla tillfällen i akt att stärka meritokratins anda och ge kredit till alla som förtjänar det.
- Erkänn en exemplarisk medlem av ditt team genom att erbjuda ett intressant uppdrag, även om det inte är inom deras vanliga arbetsfält.
Låt dina rockstjärnor följa sin passion
Entusiasm och engagemang är två mycket viktiga ord i en öppen organisation. De upprepas ständigt i boken. Men du kan inte få passionerade kreativa människor att arbeta hårt, eller hur? Annars får du helt enkelt inte allt deras talang har att erbjuda. På Red Hat utjämnas hinder för deras egna projekt så mycket som möjligt:
”För att driva innovation försöker företag många saker. Googles tillvägagångssätt är intressant. Sedan Google blev känt i alla hem 2004 har chefer och ideologer inom internetbranschen försökt reda ut företagets huvudhemlighet för att upprepa dess imponerande framgång. Ett av de mest kända, men för närvarande stängda programmen var att alla Google-anställda ombads ägna 20 procent av sin tid åt att göra nästan vad de ville. Tanken var att om medarbetarna drev egna projekt och idéer som de brinner för utanför jobbet, så skulle de börja förnya sig. Så här uppstod framgångsrika tredjepartsprojekt: GoogleSuggest, AdSense for Content och Orkut; de kom alla från detta 20-procentiga experiment – en imponerande lista! […]
På Red Hat tar vi ett mindre formellt tillvägagångssätt. Vi har ingen fastställd policy för hur mycket tid var och en av våra anställda ska lägga på "innovation". Istället för att ge människor dedikerad tid att utbilda sig själva ser vi till att anställda förtjänar rätten att ägna sin tid åt att lära sig nya saker. Om jag ska vara ärlig har många väldigt lite sådan tid, men det finns också de som kan lägga nästan hela sin arbetsdag på innovation.
Det mest typiska fallet ser ut ungefär så här: någon arbetar med ett sidoprojekt (om han förklarade dess betydelse för chefer - direkt på arbetsplatsen; eller under icke-arbetstid - på eget initiativ), och senare kan detta arbete ta upp allt hans nuvarande timmar."
Mer än brainstorming
”Lyrisk utvikning. Alex Fakeney Osborne är uppfinnaren av brainstormingmetoden, en fortsättning på vilken idag är synektikmetoden. Det är märkligt att denna idé dök upp under andra världskriget, när Osborne befäl över ett av fartygen på en amerikansk lastkonvoj som var i fara för en torpedattack av en tysk ubåt. Då kom kaptenen ihåg en teknik som medeltidens pirater tog till: om besättningen fick problem samlades alla sjömän på däck för att turas om att föreslå ett sätt att lösa problemet. Det fanns många idéer, inklusive absurda vid första anblicken: till exempel idén att blåsa på en torped med hela laget. Men med strålen från en fartygspump, som finns på alla fartyg, är det fullt möjligt att bromsa en torped eller till och med ändra dess kurs. Som ett resultat patenterade Osborne till och med en uppfinning: en extra propeller är monterad på sidan av fartyget, som driver en ström av vatten längs sidan, och torpeden glider längs med."
Vår Jim upprepar hela tiden att det inte är så lätt att arbeta i en öppen organisation. Till och med ledningen får det, eftersom ingen slipper behöva försvara sin åsikt. Men detta är exakt det tillvägagångssätt som behövs för att uppnå utmärkta resultat:
"Online-forum och chattrum är ofta fyllda med livliga och ibland hårda diskussioner om allt från hur man bäst fixar en programvarubugg till vilka nya funktioner som bör övervägas i nästa uppdatering. Som regel är detta den första fasen av diskussioner, under vilken nya idéer läggs fram och ackumuleras, men det finns alltid en nästa omgång - kritisk analys. Även om vem som helst kan delta i dessa debatter måste en person vara beredd att försvara sin ståndpunkt med all sin kraft. Impopulära idéer kommer i bästa fall att förkastas, i värsta fall förlöjligas.
Till och med Linus Torvalds, skaparen av operativsystemet Linux, uttrycker sin oenighet med de föreslagna ändringarna av koden. En dag hamnade Linus och David Howells, en av Red Hats ledande utvecklare, i en het debatt om fördelarna med en kodändring som Red Hat hade begärt som skulle bidra till att ge säkerhet till våra kunder. Som svar på Howells begäran skrev Torvalds: "Ärligt talat är detta [ord som inte går att skriva ut] idiotiskt. Allt verkar kretsa kring dessa dumma gränssnitt, och det av helt dumma skäl. Varför ska vi göra detta? Jag gillar inte den befintliga X.509-parsern längre. Dumma komplexa gränssnitt skapas, och nu kommer det att finnas 11 av dem. – Linus 9.”
Bortsett från tekniska detaljer, fortsatte Torvalds att skriva i samma anda i nästa meddelande – och på ett sådant sätt att jag inte vågar citera. Denna tvist var så högljudd att den till och med hamnade på sidorna i The Wall Street Journal. […]
Den här debatten visar att de flesta företag som producerar proprietär, icke-fri programvara inte har en öppen debatt om vilka nya funktioner eller förändringar de kanske arbetar med. När produkten är klar skickar företaget den helt enkelt till kunderna och går vidare. Samtidigt, när det gäller Linux, avtar inte diskussionerna om vilka förändringar som behövs och – viktigast av allt – varför de är nödvändiga. Detta gör naturligtvis hela processen mycket mer rörig och tidskrävande.”
Släpp tidigt, släpp ofta
Vi kan inte förutse framtiden, så vi måste bara försöka:
"Vi arbetar efter principen om "tidig lansering, frekventa uppdateringar." Det viktigaste problemet med alla programvaruprojekt är risken för fel eller buggar i källkoden. Ju fler ändringar och uppdateringar som samlas in i en version (version) av programvaran, desto större är sannolikheten att det kommer att finnas buggar i den här versionen. Utvecklare av öppen källkod har insett att genom att släppa mjukvaruversioner snabbt och ofta minskar risken för allvarliga problem med vilket program som helst – vi tar trots allt inte ut alla uppdateringar till marknaden på en gång, utan en åt gången för varje version. Med tiden märkte vi att detta tillvägagångssätt inte bara minskar fel utan också leder till mer intressanta lösningar. Det visar sig att ständigt göra små förbättringar skapar mer innovation på sikt. Kanske är det inget som överraskar här. En av nyckelprinciperna för moderna tillverkningsprocesser som kaizen a eller lean b är fokus på små och inkrementella förändringar och uppdateringar.
[…] Mycket av det vi jobbar med kanske inte lyckas. Men istället för att spendera mycket tid på att undra vad som kommer att fungera och vad som inte fungerar, föredrar vi att genomföra små experiment. De mest populära idéerna kommer att leda till framgång, och de som inte fungerar kommer att vissna bort av sig själva. På så sätt kan vi prova många saker snarare än bara en sak, utan större risk för företaget.
Detta är ett rationellt sätt att fördela resurser. Till exempel frågar folk mig ofta hur vi väljer vilka projekt med öppen källkod som ska kommersialiseras. Även om vi ibland initierar projekt, hoppar vi oftare än inte helt enkelt in i befintliga. En liten grupp ingenjörer – ibland bara en person – börjar bidra till ett av open source-gemenskapens projekt. Om projektet blir framgångsrikt och efterfrågat bland våra kunder börjar vi lägga mer tid och kraft på det. Om inte går utvecklarna vidare till ett nytt projekt. När vi bestämmer oss för att kommersialisera förslaget kan projektet ha växt så pass att lösningen är uppenbar. Olika projekt, inklusive icke-mjukvara, dyker naturligtvis upp i Red Hat tills det står klart för alla att nu kommer någon att behöva arbeta med detta på heltid.”
Här är ett annat citat från boken:
”Jag insåg att för att uppfylla denna roll måste morgondagens ledare ha egenskaper som helt enkelt förbises i konventionella organisationer. För att effektivt leda en öppen organisation måste en ledare ha följande egenskaper.
- Personlig styrka och självförtroende. Vanliga ledare använder positionell makt – deras position – för att nå framgång. Men i en meritokrati måste ledare tjäna respekt. Och detta är bara möjligt om de inte är rädda för att erkänna att de inte har alla svar. De måste vara villiga att diskutera problem och fatta beslut snabbt för att hitta de bästa lösningarna med sitt team.
- Tålamod. Media berättar sällan historier om hur "tålmodig" en ledare är. Men han måste verkligen ha tålamod. När du arbetar för att få bästa möjliga insats och resultat från ditt team, har samtal i timmar och upprepar saker om och om igen tills det är rätt gjort, måste du ha tålamod.
- Hög EQ (emotionell intelligens). Alltför ofta främjar vi ledarnas intelligens genom att fokusera på deras IQ, när det som verkligen behöver beaktas är deras emotionella intelligenskvot, eller EQ-poäng. Att vara den smartaste personen bland andra räcker inte om du inte kan arbeta med dessa människor. När du arbetar med gemenskaper av engagerade medarbetare som Red Hat, och du inte har förmågan att beställa någon, blir din förmåga att lyssna, bearbeta analytiskt och inte ta saker personligt otroligt värdefull.
- Annan mentalitet. Ledare som kom från traditionella organisationer uppfostrades med andan av quid pro quo (latin för "quid pro quo"), enligt vilken varje åtgärd bör få en adekvat avkastning. Men när du funderar på att investera i att bygga en viss gemenskap måste du tänka långsiktigt. Det är som att försöka bygga ett känsligt balanserat ekosystem, där alla fel steg kan skapa en obalans och leda till långsiktiga förluster som du kanske inte märker direkt. Ledare måste bli av med tankesättet som kräver att de uppnår resultat idag, till varje pris, och börja göra affärer på ett sätt som gör att de kan dra större fördelar genom att investera i framtiden.”
Och varför är det viktigt
Red Hat lever och verkar enligt principer som skiljer sig mycket från en traditionell hierarkisk organisation. Och det fungerar, det gör oss kommersiellt framgångsrika och mänskligt lyckliga. Vi översatte den här boken i hopp om att sprida principerna för öppen organisation bland ryska företag, bland människor som vill och kan leva annorlunda.
, försök!
Källa: will.com