«Öppen organisation»: Hur man inte går vilse i kaoset och förenar miljoner

Det har kommit en viktig dag för Red Hat, den ryska open source-gemenskapen och alla berörda – på ryska har publicerats boken av Jim Whitehurst "Öppen organisation: Passion som ger resultat". Den beskriver detaljerat och livligt hur vi på Red Hat ger bästa idéer och de mest begåvade människor utrymme, samt hur man kan navigera i kaos och förena miljontals människor över hela världen.

Och dessutom handlar den här boken om livet och praktik. Den innehåller många råd för alla som vill lära sig att bygga företag med modellen öppen organisation och leda den effektivt. Nedan följer några av de viktigaste principerna som tas upp i boken, som du kan ta med dig redan nu.

Det är värt att notera hur Jim fick jobb i företaget. Den visar att i en värld av öppen källkod finns det inga fanfarer, men det finns en ny ledarskapsansats:

«Efter samtalet med rekryteraren uttryckte jag mitt intresse för en intervju, och han frågade om jag skulle ha något emot att flyga till Red Hats huvudkontor i Raleigh, North Carolina, på en söndag. Jag tänkte att söndagen var en underlig dag för ett möte. Men eftersom jag ändå planerade att flyga till New York på måndag, var det i stort sett på vägen, så jag gick med på det. Jag satte mig på planet från Atlanta och landade på Raleigh-Durham flygplats. Därifrån tog jag en taxi som släppte av mig framför Red Hats byggnad på campus vid University of North Carolina. Det var söndag, klockan var 9:30 på morgonen, och det fanns ingen i närheten. Ljuset var avstängt, och när jag kontrollerade såg jag att dörrarna var låsta. Först trodde jag att de skämtade med mig. När jag vände mig för att återvända till taxin såg jag att den redan hade åkt. Snart började det regna, och jag hade ingen paraply.

Precis när jag tänkte gå någonstans för att få tag på en taxi, kom Matthew Szulik, som senare blev styrelseordförande och vd för Red Hat, körande i sin bil. "Hej," hälsade han. "Vill du ta en kopp kaffe?" Jag tyckte att det var ett ovanligt sätt att börja en intervju, men jag visste att jag verkligen behövde en kopp kaffe. Slutligen tänkte jag att det skulle bli lättare för mig att få en taxi till flygplatsen efteråt.

På söndagar är det ganska tyst i North Carolina på morgonen. Det tog oss ett tag att helt enkelt hitta ett café som öppnade innan middag. Caféet visade sig inte vara det bästa i staden och inte det renaste, men det var öppet och vi kunde få nybryggt kaffe. Vi satte oss vid ett bord och började prata.

Efter ungefär trettio minuter insåg jag att jag gillade hur allt flöt på; intervjun var inte traditionell, men samtalet var riktigt intressant. Istället för att diskutera detaljerna i Red Hats företagsstrategi eller dess image på Wall Street – det vill säga det jag hade förberett mig för – frågade Matthew Shulik mer om mina förhoppningar, drömmar och mål. Nu förstår jag att Shulik bedömde om jag skulle passa in i företagets subkultur och ledarskapsstil.

När vi var klara med samtalet meddelade Shulik att han ville introducera mig för företagets huvudjurist, Michael Cunningham, och föreslog att vi skulle träffa honom nu, över en tidig lunch. Jag gick med på det, och vi började förbereda oss att gå. Då upptäckte min samtalspartner att han inte hade sin plånbok med sig. 'Oops,' sa han. 'Jag har inga pengar. Hur är det med dig?' Det överraskade mig, men jag svarade att jag hade pengar och att jag inte hade något emot att betala för kaffen.

Några minuter senare släppte Shulik av mig vid en liten mexikansk snabbmatsrestaurang, där jag mötte Michael Cunningham. Men något traditionellt intervju eller affärsmöte följde återigen inte, utan istället fick vi ytterligare ett intressant samtal. När vi skulle betala notan visade det sig att restaurangen hade problem med sin kortläsare, och vi kunde endast betala kontant. Cunningham vände sig till mig och frågade om jag var redo att betala eftersom han inte hade några kontanter med sig. Eftersom jag var på väg till New York hade jag mycket kontanter, så jag betalade för lunchen.

Cunningham erbjöd 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 tankar? Vi kommer att köra i högsta fart." – "Inga problem," svarade jag. Så snart jag hörde det rytmiska ljudet av pumpen, hördes ett knackande vid fönstret. Det var Cunningham. "Hej, de accepterar inte kreditkort här," sa han. – "Kan jag låna några pengar?" Jag började undra om detta verkligen var en intervju eller någon slags bedrägeri.

Nästa dag, medan jag var i New York, diskuterade jag denna intervju på Red Hat med min fru. Jag berättade för henne att samtalet var mycket intressant, men jag var osäker på om de verkligen ville anställa mig: kanske de bara behövde gratis mat och bensin? När jag idag minns det mötet förstår jag att Shulik och Cunningham bara var öppna människor som behandlade mig som vilken annan person som helst, med vilken de kunde ta en kopp kaffe, äta lunch eller tanka bensin. Ja, det är lustigt och till och med komiskt att de båda var utan pengar. Men för dem handlade det inte om pengar. De, liksom världen omkring öppen källkod, trodde inte på att rulla ut röda mattor eller att försöka övertyga intervjuobjektet om att allt är perfekt. De ville bara lära känna mig bättre och gjorde inget försök att imponera eller påpeka våra skillnader. De ville veta vem jag var.

Min första intervju på Red Hat visade tydligt för mig att arbetet här är av ett annat slag. I detta företag fanns det ingen traditionell hierarki eller något särskilt läge för chefer, åtminstone inte i den form som är vanlig i de flesta andra företag. Med tiden har jag också lärt mig att företaget Red Hat tror på meritokratins princip: man bör alltid försöka förverkliga den bästa idén, oavsett om den kommer från högsta ledningen eller en praktikant som anställts för sommaren. Med andra ord, mitt första intryck av Red Hat introducerade mig för hur framtiden för ledarskap ser ut.

Tips för att odla meritokrati

Meritokrati är det främsta värdet i den öppna källkodens samhälle. Det spelar ingen roll vilken nivå du befinner dig på i pyramiden, det viktigaste är hur bra dina idéer är. Så här säger Jim:

• Säg aldrig: "Så vill chefen" – och lita inte på hierarkin. Det kan hjälpa dig på kort sikt, men du bygger inte meritokrati på det sättet.
• Dela offentligt erkännande för framgångar och viktiga bidrag till det gemensamma målet. Det kan vara ett enkelt tack-mail, där hela teamet är kopierat.
• Tänk efter: Beror din auktoritet på din plats i hierarkin (eller på tillgången till privilegierad information) eller är det ett resultat av den respekt du har förtjänat? Om det första – börja arbeta med det andra.
• Be om feedback och samla idéer kring ett specifikt ämne. Du bör reagera på allt, men bara implementera det bästa. Men ta inte bara de bästa idéerna och gå vidare med dem – använd varje möjlighet att förstärka meritokratins anda genom att ge erkännande till alla som förtjänar det.
• Utmana en framstående medlem av ditt team genom att ge dem en intressant uppgift, även om den inte hör till deras vanliga arbetsområde.

Låt dina "rockstjärnor" följa sin passion.

Entusiasm och engagemang – två mycket viktiga ord i en öppen organisation. I boken upprepas de ständigt. Men du kan inte tvinga entusiastiska kreativa personer att arbeta "från morgon till kväll", eller hur? Annars får du inte ut allt som deras talang kan erbjuda. På Red Hat minimeras hinder för egna projekt så mycket som möjligt:

"För att styra innovationer försöker företag mycket. Intressant är Googles angreppssätt. Sedan Google blev känt i varje hem från och med 2004 har ledare och tänkare inom internetbranschen försökt lista ut företagets hemlighet för att upprepa dess imponerande framgång. Ett av de mest kända, men i nuläget nedlagda, programmen var att alla Google-anställda fick möjlighet att använda 20 procent av sin arbetstid på i stort sett vad de ville. Idén var att om anställda började genomföra sina egna projekt och idéer, som de brinner för utöver sitt arbete, skulle de börja skapa innovationer. Så uppstod framgångsrika sidoprojekt: Google Suggest, AdSense for Content och Orkut; alla kom från detta 20-procentsexperiment – en imponerande lista! [...]"

Vi på Red Hat tillämpar inte en så formell strategi. Vi har ingen fast politik för hur mycket tid varje anställd bör ägna åt "innovationer". Istället ser vi till att anställda tjänar rätt att använda sin tid på nya projekt. Om vi ska vara ärliga, så har många inte mycket tid, men det finns även de som kan ägna nästan hela arbetsdagen åt innovationer.

Det mest typiska fallet ser ut på följande sätt: någon arbetar med ett sidoprojekt (om personen har förklarat dess betydelse för cheferna – antingen under arbetstid eller på sin egen tid – av egen initiativ), och senare kan detta arbete ta upp hela deras arbetstid.

Mer än en hjärnstorm

"Ett lyriskt avbrott. Alex Faikny Osborn – uppfinnaren av metoden 'hjärnstorm', vars fortsättning är dagens synetikmetod. Det är intressant att denna idé kom till under andra världskriget, när Osborn befäste ett av de amerikanska lastfartygen som utsattes för torpedattack av en tysk ubåt. Kaptenen kom ihåg en metod som medeltida pirater använde: om besättningen hade problem samlades alla sjömän på däck för att turas om att föreslå lösningar. Det fanns många idéer, inklusive de som vid första anblick verkade absurda: till exempel att blåsa på torpeden med hela besättningen. Men med en pumpstråle som finns på varje fartyg kan man faktiskt bromsa torpeden eller till och med ändra dess kurs. Som ett resultat patenterade Osborn även sin uppfinning: en extra propeller monterades på fartygets sida som förde en stråle av vatten längs sidan, och torpeden gled bredvid."

Vår Jim upprepar hela tiden att det inte är så lätt att arbeta i en öppen organisation. Även ledningen får kämpa, eftersom ingen är befriad från att behöva försvara sina åsikter. Men just den här strategin krävs för att uppnå utmärkta resultat:

«Onlineforum för [öppen källkod utvecklare] och chattar är ofta fyllda med livliga, och ibland bitande diskussioner om allt – från hur man bäst åtgärdar ett programvarufel till vilka nya funktioner som bör övervägas i nästa uppdatering. Normalt sett är detta den första fasen av diskussionerna, där nya idéer föreslås och samlas, men det finns alltid en nästa runda – en kritisk analys. Även om alla kan delta i dessa debatter, måste man vara beredd att försvara sin ståndpunkt med all kraft. Opopulara idéer avfärdas ofta, i bästa fall, men i värsta fall hånas de.

Till och med Linus Torvalds, skaparen av operativsystemet Linux, uttrycker sitt missnöje med föreslagna förändringar i koden. Någon gång hade Linus och David Howells, en av de ledande utvecklarna på Red Hat, en het diskussion om fördelarna med att ändra koden som företaget Red Hat efterfrågade för att säkerställa säkerhet för våra kunder. Som svar på Howells begäran skrev Torvalds: «Ärligt talat, det är [opublicerat ord] idioti. Allt verkar handla om dessa dumma gränssnitt, och av helt idiotiska skäl. Varför ska vi göra så här? Jag gillar redan inte den befintliga X.509-parsen. Idiotiska komplexa gränssnitt skapas, och nu kommer det att finnas 11 av dem. – Linus 9».

Utan att gå in på tekniska detaljer fortsatte Torvalds i sitt nästa meddelande att skriva på samma sätt – och sådant att jag inte vågar citera. Denna debatt hördes så högt att den till och med hamnade i The Wall Street Journal. […]

Denna debatt visar att det i de flesta företag som släpper proprietära, icke-fria program inte pågår öppna debatter om vilka nya funktioner eller förändringar de kan arbeta med. När produkten är klar skickar företaget helt enkelt den till sina kunder och går vidare. Samtidigt har diskussioner om vilka förändringar som verkligen behövs – och, viktigast av allt, varför de behövs – inte tystnat i fallet med Linux. Detta gör förstås hela processen mycket mer oordnad och tidskrävande."

Släpp tidigt, släpp ofta

Vi kan inte förutsäga framtiden, så vi måste helt enkelt prova:

Vi arbetar utifrån principen "tidig lansering och frekventa uppdateringar". Den centrala problematiken i varje programprojekt är risken för fel eller buggar i koden. Det är uppenbart att ju fler förändringar och uppdateringar som samlas i en enda version av mjukvaran, desto högre är risken för att det finns buggar i just den versionen. Utvecklare av öppen källkod har insett att med snabba och frekventa mjukvaruversioner minskar risken för allvarliga problem med programvaran – eftersom vi inte lanserar alla uppdateringar på en gång, utan i portioner per version. Med tiden har vi märkt att denna metod inte bara minskar antalet fel, utan också leder till mer intressanta lösningar. Det visar sig att kontinuerliga små förbättringar så småningom leder till fler innovationer. Det finns kanske inget överraskande i detta. En av de centrala principerna för moderna produktionsprocesser, såsom kaizen eller lean, är fokus på små och gradvisa förändringar och uppdateringar.

[…] Mycket av det vi arbetar med kanske inte kommer att lyckas. Men istället för att slösa tid på att grubbla över vad som kommer att fungera och vad som inte kommer att göra det, föredrar vi att genomföra små experiment. De mest efterfrågade idéerna kommer att lyckas, medan de som inte fungerar kommer att dö ut av sig själva. På så sätt kan vi pröva mycket istället för bara något, utan särskild risk för företaget.

Det här är ett rationellt sätt att fördela resurser. Till exempel frågar folk mig ofta hur vi väljer vilka open source-projekt som ska kommersialiseras. Även om vi ibland initierar projekt, kopplar vi oftast bara in oss i befintliga. En liten grupp ingenjörer – eller ibland en enda person – börjar bidra till ett av open source-gemenskapens projekt. Om projektet är framgångsrikt och efterfrågat av våra kunder börjar vi lägga mer tid och kraft på det. Om inte, går utvecklarna vidare till ett nytt projekt. Vid tidpunkten när vi beslutar att kommersialisera erbjudandet kan projektet ha växt till den grad att beslutet är uppenbart. Olika projekt, inklusive de som inte är relaterade till programvara, uppstår naturligt i hela Red Hat-företaget, tills det blir klart för alla att någon nu måste arbeta med detta konstant.

Här är ytterligare ett citat från boken:

„Jag insåg att för att leva upp till en sådan roll måste morgondagens ledare ha egenskaper som vanliga organisationer helt enkelt inte uppmärksammar. För att kunna leda en öppen organisation effektivt måste ledaren ha följande kvaliteter.

• Personlig styrka och självförtroende. Vanliga ledare använder positional makt – sin position – för att lyckas. Men i en meritokrati måste ledarna förtjäna respekt. Och det är möjligt endast om de inte är rädda för att erkänna att de inte har svar på alla frågor. De måste vara beredda att diskutera problem och snabbt fatta beslut för att tillsammans med sitt team hitta de bästa lösningarna.
• Tålamod. Media berättar sällan historier om hur "tålamodig" en ledare är. Men de måste faktiskt vara tålmodiga. När du arbetar för att få ut det mesta av din teamsinsatser och resultat, hålla långa dialoger och repetera något igen och igen tills allt görs rätt, behöver du ha tålamod.
• Hög EQ (emotionell intelligens). Alltför ofta marknadsför vi ledarnas intellektuella förmågor, och fokuserar på deras IQ, när vi i verkligheten måste ta hänsyn till deras emotionella intelligenskvot, eller EQ. Att vara den smartaste personen bland andra är inte tillräckligt om du inte kan samarbeta med dessa människor. När du arbetar med engagerade anställdas gemenskaper, som på Red Hat, och inte har möjlighet att beordra någon, blir din förmåga att lyssna, analytiskt bearbeta och inte ta allting personligt otroligt värdefull.
• En annan mentalitet. Ledare som kommer från traditionella organisationer har fostrats i en anda av quid pro quo (lat. "tjänst för tjänst"), enligt vilken varje handling måste få en adekvat avkastning. Men när du planerar att investera i att skapa en viss gemenskap, bör du tänka långsiktigt. Det är som att försöka bygga ett finjusterat ekosystem, där varje felaktigt steg kan skapa obalans och leda till långsiktiga förluster som du kanske inte märker omedelbart. Ledare måste göra sig av med det typ av tänkande som kräver att de uppnår resultat idag till varje pris, och istället börja bedriva affärer som gör det möjligt att få större vinster genom investeringar i framtiden.

Och varför det är viktigt

Red Hat lever och arbetar enligt principer som skiljer sig mycket från en traditionell organisation med hierarkisk struktur. Och det fungerar, det gör oss kommersiellt framgångsrika och mänskligt lyckliga. Vi har översatt denna bok i hopp om att sprida principerna för öppen organisation bland ryska företag, bland människor som vill och kan leva annorlunda.

Läs, prova!

Källa: habr.com