Een belangrijke dag is aangebroken voor Red Hat, de Russische open source-gemeenschap en alle betrokkenen: het werd in het Russisch gepubliceerd . Ze vertelt gedetailleerd en levendig hoe wij bij Red Hat de beste ideeën en de meest getalenteerde mensen het pad wijzen, en ook hoe we niet verdwalen in de chaos en miljoenen mensen over de hele wereld verenigen.
Dit boek gaat ook over het leven en de praktijk. Het bevat veel advies voor iedereen die wil leren hoe hij een bedrijf kan opbouwen volgens het open organisatiemodel en hoe hij dit effectief kan beheren. Hieronder staan enkele van de belangrijkste principes uit het boek waar u nu meteen kennis van kunt nemen.
Jim's arbeidsverleden bij het bedrijf is opmerkelijk. Het laat zien dat er geen ophef is in de open source-wereld, maar dat er een nieuwe benadering van leiderschap bestaat:
“Nadat ik met de recruiter had gesproken, toonde ik interesse in een interview en hij vroeg of ik het erg zou vinden om zondag naar het Red Hat-hoofdkwartier in Raleigh, North Carolina te vliegen. Ik vond zondag een vreemde dag om elkaar te ontmoeten. Maar aangezien ik maandag nog naar New York zou vliegen, was het over het algemeen onderweg, en ik stemde ermee in. Ik stapte in een vliegtuig vanuit Atlanta en landde op Raleigh Durham Airport. Van daaruit nam ik een taxi die me afzette voor het Red Hat-gebouw op de campus van de Universiteit van North Carolina. Het was zondag, 9 uur, en er was niemand in de buurt. De lichten waren uit en bij controle ontdekte ik dat de deuren op slot waren. In eerste instantie dacht ik dat ik voor de gek werd gehouden. Toen ik me omdraaide om weer in de taxi te stappen, zag ik dat deze al was vertrokken. Al snel begon het te regenen, ik had geen paraplu.
Net toen ik op het punt stond ergens heen te gaan om een taxi te nemen, stopte Matthew Shulick, later voorzitter van de raad van bestuur en CEO van Red Hat, in zijn auto. ‘Hallo,’ begroette hij. “Wil je wat koffie?” Dit leek een ongebruikelijke manier om een interview te beginnen, maar ik wist dat ik absoluut koffie nodig had. Uiteindelijk dacht ik dat het voor mij gemakkelijker zou zijn om een taxi naar het vliegveld te nemen.
Zondagochtenden zijn behoorlijk rustig in North Carolina. Het kostte ons een tijdje om een koffieshop te vinden die vóór de middag openging. Het koffietentje was niet de beste van de stad en ook niet de schoonste, maar het werkte wel en je kon er vers gezette koffie drinken. We gingen aan een tafel zitten en begonnen te praten.
Na ongeveer dertig minuten besefte ik dat ik het prettig vond hoe de dingen gingen; Het interview was niet traditioneel, maar het gesprek zelf bleek erg interessant. In plaats van de details van de bedrijfsstrategie van Red Hat of het imago ervan op Wall Street te bespreken – iets waar ik me op had voorbereid – vroeg Matthew Shulick meer naar mijn hoop, dromen en doelen. Nu is het mij duidelijk dat Shulik aan het beoordelen was of ik zou passen bij de subcultuur en managementstijl van het bedrijf.
Nadat we klaar waren, zei Shulick dat hij me wilde voorstellen aan de algemeen adviseur van het bedrijf, Michael Cunningham, en stelde voor dat ik hem nu zou ontmoeten voor een vroege lunch. Ik stemde toe en we maakten ons klaar om te vertrekken. Toen ontdekte mijn gesprekspartner dat hij zijn portemonnee niet bij zich had. ‘Oeps,’ zei hij. - Ik heb geen geld. Jij ook?" Dit verraste mij, maar ik antwoordde dat ik geld had en het niet erg vond om voor de koffie te betalen.
Een paar minuten later zette Shulik me af bij een klein Mexicaans restaurant, waar ik Michael Cunningham ontmoette. Maar wederom volgde er geen traditioneel interview of zakelijke bijeenkomst, maar vond er weer een interessant gesprek plaats. Toen we op het punt stonden de rekening te betalen, bleek dat de creditcardautomaat van het restaurant kapot was en we alleen contant geld konden accepteren. Cunningham wendde zich tot mij en vroeg of ik bereid was te betalen, omdat hij geen contant geld bij zich had. Omdat ik naar New York ging, had ik veel contant geld, dus betaalde ik voor de lunch.
Cunningham bood aan mij naar het vliegveld te brengen, en we gingen in zijn auto. Na een paar minuten vroeg hij: 'Vind je het erg als ik stop en ga tanken? Wij gaan met volle kracht vooruit." “Geen probleem,” antwoordde ik. Zodra ik het ritmische geluid van de pomp hoorde, werd er op het raam geklopt. Het was Cunningham. 'Hé, ze accepteren hier geen creditcards,' zei hij. "Kan ik wat geld lenen?" Ik begon me af te vragen of dit echt een interview was of een soort oplichterij.
De volgende dag, terwijl ik in New York was, besprak ik dit interview met mijn vrouw bij Red Hat. Ik vertelde haar dat het gesprek heel interessant was, maar ik wist niet zeker of deze mensen serieus waren om mij in dienst te nemen: misschien wilden ze gewoon gratis eten en benzine? Als ik me die ontmoeting van vandaag herinner, begrijp ik dat Shulick en Cunningham gewoon open mensen waren en mij behandelden als ieder ander persoon met wie ze koffie konden drinken, lunchen of tanken. Ja, het is grappig en zelfs grappig dat ze allebei zonder geld zijn beland. Maar voor hen ging het niet om het geld. Zij geloofden, net als de open source-wereld, niet in het uitrollen van rode lopers of in het proberen anderen ervan te overtuigen dat alles perfect was. Ze probeerden me alleen maar beter te leren kennen, niet om indruk te maken of op onze verschillen te wijzen. Ze wilden weten wie ik was.
Uit mijn eerste interview bij Red Hat bleek duidelijk dat het werk hier anders was. Dit bedrijf kende geen traditionele hiërarchie en speciale behandeling voor managers, althans niet in de vorm die gebruikelijk is in de meeste andere bedrijven. In de loop van de tijd heb ik ook geleerd dat Red Hat gelooft in het principe van meritocratie: het is altijd de moeite waard om te proberen het beste idee te implementeren, ongeacht of het van het senior management komt of van een zomerstagiaire. Met andere woorden: mijn eerste ervaring bij Red Hat liet me kennismaken met hoe de toekomst van leiderschap eruit ziet.”
Tips voor het cultiveren van meritocratie
Meritocratie is de kernwaarde van de open source-gemeenschap. Het maakt voor ons niet uit op welk niveau van de piramide u zich bevindt, het belangrijkste is hoe goed uw ideeën zijn. Dit is wat Jim voorstelt:
- Zeg nooit: “Dat is wat de baas wil”, en vertrouw niet op hiërarchie. Dit kan je op de korte termijn helpen, maar zo bouw je niet aan een meritocratie.
- Erken publiekelijk successen en belangrijke bijdragen. Dit kan een eenvoudige bedankmail zijn met het hele team in kopie.
- Bedenk: is uw autoriteit een functie van uw positie in de hiërarchie (of toegang tot bevoorrechte informatie), of is het een resultaat van het respect dat u heeft verdiend? Als het eerste het geval is, begin dan aan het tweede te werken.
- Vraag om feedback en verzamel ideeën over een specifiek onderwerp. Je moet op alles reageren, alleen het beste testen. Maar neem niet alleen de beste ideeën en ga ermee verder; grijp elke gelegenheid aan om de geest van meritocratie te versterken, en geef eer aan iedereen die het verdient.
- Herken een voorbeeldig lid van uw team door een interessante opdracht aan te bieden, ook al valt deze niet binnen hun gebruikelijke werkveld.
Laat je rocksterren hun passie volgen
Enthousiasme en betrokkenheid zijn twee hele belangrijke woorden in een open organisatie. Ze worden voortdurend herhaald in het boek. Maar je kunt gepassioneerde creatieve mensen toch niet hard laten werken? Anders krijg je simpelweg niet alles wat hun talent te bieden heeft. Bij Red Hat worden obstakels voor de eigen projecten zoveel mogelijk geëgaliseerd:
“Om innovatie te stimuleren, proberen bedrijven veel dingen. De aanpak van Google is interessant. Sinds Google in 2004 in ieder huishouden bekend werd, hebben leidinggevenden en ideologen in de internetwereld geprobeerd het belangrijkste geheim van het bedrijf te ontrafelen om het indrukwekkende succes ervan te herhalen. Een van de bekendste, maar momenteel gesloten, programma's was dat alle Google-werknemers werd gevraagd 20 procent van hun tijd te besteden aan bijna alles wat ze wilden. Het idee was dat als werknemers hun eigen projecten en ideeën zouden nastreven waar ze buiten het werk een passie voor hadden, ze zouden gaan innoveren. Zo ontstonden succesvolle projecten van derden: GoogleSuggest, AdSense for Content en Orkut; ze kwamen allemaal uit dit 20 procent-experiment – een indrukwekkende lijst! […]
Bij Red Hat hanteren we een minder formele aanpak. We hebben geen vast beleid met betrekking tot hoeveel tijd elk van onze medewerkers aan ‘innovatie’ moet besteden. In plaats van mensen tijd te geven om zichzelf te onderwijzen, zorgen we ervoor dat werknemers het recht verdienen om hun tijd te besteden aan het leren van nieuwe dingen. Eerlijk gezegd hebben veel mensen heel weinig tijd, maar er zijn ook mensen die bijna hun hele werkdag aan innovatie kunnen besteden.
Het meest typische geval ziet er ongeveer zo uit: iemand werkt aan een bijproject (als hij het belang ervan aan managers heeft uitgelegd – direct op de werkplek; of tijdens niet-werkuren – op eigen initiatief), en later kan dit werk alle werkzaamheden in beslag nemen. zijn huidige uren.”
Meer dan brainstormen
“Lyrische uitweiding. Alex Fakeney Osborne is de uitvinder van de brainstormmethode, waarvan vandaag de dag de synectische methode een voortzetting is. Het is merkwaardig dat dit idee ontstond tijdens de Tweede Wereldoorlog, toen Osborne het bevel voerde over een van de schepen van een Amerikaans vrachtkonvooi dat gevaar liep voor een torpedo-aanval door een Duitse onderzeeër. Toen herinnerde de kapitein zich een techniek waartoe de piraten uit de Middeleeuwen hun toevlucht namen: als de bemanning in de problemen kwam, verzamelden alle matrozen zich aan dek om om de beurt een manier voor te stellen om het probleem op te lossen. Er waren veel ideeën, waaronder absurde op het eerste gezicht: bijvoorbeeld het idee om met het hele team op een torpedo te blazen. Maar met de straal van een scheepspomp, die op ieder schip aanwezig is, is het heel goed mogelijk een torpedo af te remmen of zelfs van koers te veranderen. Als gevolg daarvan patenteerde Osborne zelfs een uitvinding: aan de zijkant van het schip wordt een extra propeller gemonteerd, die een stroom water langs de zijkant aandrijft, en de torpedo schuift langszij.”
Onze Jim herhaalt voortdurend dat het niet zo eenvoudig is om in een open organisatie te werken. Zelfs het management snapt het, want niemand wordt de noodzaak bespaard om zijn mening te verdedigen. Maar dit is precies de aanpak die nodig is om uitstekende resultaten te bereiken:
“Online [open source] forums en chatrooms zijn vaak gevuld met levendige en soms bittere discussies over van alles, van hoe je een softwarefout het beste kunt oplossen tot welke nieuwe functies in de volgende update in overweging moeten worden genomen. In de regel is dit de eerste fase van de discussies, waarin nieuwe ideeën naar voren worden gebracht en verzameld, maar er is altijd een volgende ronde: kritische analyse. Hoewel iedereen aan deze debatten kan deelnemen, moet iemand bereid zijn zijn standpunt met alle macht te verdedigen. Impopulaire ideeën zullen in het beste geval worden afgewezen en in het slechtste geval belachelijk worden gemaakt.
Zelfs Linus Torvalds, de maker van het Linux-besturingssysteem, geeft aan dat hij het niet eens is met de voorgestelde wijzigingen in de code. Op een dag raakten Linus en David Howells, een van de hoofdontwikkelaars van Red Hat, verwikkeld in een verhit debat over de voordelen van een codewijziging waar Red Hat om had verzocht en die onze klanten veiligheid zou bieden. In antwoord op het verzoek van Howells schreef Torvalds: “Eerlijk gezegd is dit [onafdrukbaar woord] idioot. Alles lijkt om deze stomme interfaces te draaien, en om volkomen stomme redenen. Waarom zouden we dit doen? Ik vind de bestaande X.509-parser niet meer leuk. Er worden stomme, complexe interfaces gemaakt, en nu zullen het er elf zijn – Linus 11.”
Technische details buiten beschouwing gelaten, bleef Torvalds in het volgende bericht in dezelfde geest schrijven - en op zo'n manier dat ik niet durf te citeren. Dit dispuut was zo luidruchtig dat het zelfs op de pagina's van The Wall Street Journal terechtkwam. […]
Dit debat laat zien dat de meeste bedrijven die propriëtaire, niet-vrije software produceren, geen open debat voeren over de nieuwe mogelijkheden of veranderingen waaraan ze zouden kunnen werken. Wanneer het product klaar is, verzendt het bedrijf het eenvoudigweg naar klanten en gaat verder. Tegelijkertijd nemen in het geval van Linux de discussies over welke veranderingen nodig zijn en – belangrijker nog – waarom ze nodig zijn, niet af. Dit maakt het hele proces uiteraard veel rommeliger en tijdrovender.”
Laat vroeg los, laat vaak los
We kunnen de toekomst niet voorspellen, dus we moeten het gewoon proberen:
“We werken volgens het principe van ‘vroege lancering, frequente updates’. Het belangrijkste probleem van elk softwareproject is het risico op fouten of bugs in de broncode. Het is duidelijk dat hoe meer wijzigingen en updates er in één release (versie) van de software worden verzameld, hoe groter de kans is dat er bugs in deze versie voorkomen. Open source-softwareontwikkelaars hebben zich gerealiseerd dat door softwareversies snel en frequent uit te brengen, het risico op ernstige problemen met welk programma dan ook wordt verkleind. We brengen immers niet alle updates in één keer op de markt, maar één voor één voor elke versie. In de loop van de tijd hebben we gemerkt dat deze aanpak niet alleen het aantal fouten vermindert, maar ook tot interessantere oplossingen leidt. Het blijkt dat het voortdurend doorvoeren van kleine verbeteringen op de lange termijn voor meer innovatie zorgt. Misschien is er hier niets verrassends. Een van de belangrijkste principes van moderne productieprocessen zoals kaizen a of lean b is de focus op kleine en stapsgewijze veranderingen en updates.
[…] Veel van waar we aan werken, zal misschien niet slagen. Maar in plaats van veel tijd te besteden aan het afvragen wat wel en niet werkt, voeren we liever kleine experimenten uit. De meest populaire ideeën zullen tot succes leiden, en de ideeën die niet werken zullen vanzelf verdwijnen. Zo kunnen we veel dingen proberen in plaats van slechts één ding, zonder veel risico voor het bedrijf.
Dit is een rationele manier om middelen toe te wijzen. Mensen vragen mij bijvoorbeeld vaak hoe we kiezen welke open source-projecten we gaan commercialiseren. Hoewel we soms projecten initiëren, springen we vaker wel dan niet gewoon in bestaande projecten. Een kleine groep ingenieurs – soms maar één persoon – begint bij te dragen aan een van de projecten van de open source-gemeenschap. Als het project succesvol is en er veel vraag naar is bij onze klanten, gaan we er meer tijd en moeite aan besteden. Zo niet, dan gaan de ontwikkelaars verder met een nieuw project. Tegen de tijd dat we besluiten het voorstel te commercialiseren, kan het project zover gegroeid zijn dat de oplossing voor de hand ligt. Verschillende projecten, ook niet-softwareprojecten, ontstaan als vanzelf binnen Red Hat, totdat het voor iedereen duidelijk wordt dat nu iemand hier fulltime aan zal moeten werken.”
Hier is nog een citaat uit het boek:
“Ik realiseerde me dat de leiders van morgen, om deze rol te kunnen vervullen, kenmerken moeten hebben die in conventionele organisaties eenvoudigweg over het hoofd worden gezien. Om effectief leiding te kunnen geven aan een open organisatie moet een leider over de volgende kwaliteiten beschikken.
- Persoonlijke kracht en zelfvertrouwen. Gewone leiders gebruiken positionele macht – hun positie – om succes te behalen. Maar in een meritocratie moeten leiders respect verdienen. En dit is alleen mogelijk als ze niet bang zijn om toe te geven dat ze niet alle antwoorden hebben. Ze moeten bereid zijn problemen te bespreken en snel beslissingen te nemen om met hun team de beste oplossingen te vinden.
- Geduld. De media vertellen zelden verhalen over hoe ‘geduldig’ een leider is. Maar hij moet echt geduld hebben. Wanneer u eraan werkt om de beste inzet en resultaten van uw team te behalen, urenlang gesprekken voert en dingen keer op keer herhaalt totdat het goed is gedaan, moet u geduld hebben.
- Hoge EQ (emotionele intelligentie). Te vaak bevorderen we de intelligentie van leiders door ons te concentreren op hun IQ, terwijl waar echt rekening mee gehouden moet worden hun emotionele intelligentiequotiënt of EQ-score is. Onder andere de slimste persoon zijn is niet voldoende als je niet met die mensen kunt samenwerken. Wanneer je werkt met gemeenschappen van betrokken medewerkers zoals Red Hat, en je hebt niet de mogelijkheid om iemand de leiding te geven, wordt je vermogen om te luisteren, analytisch te verwerken en dingen niet persoonlijk op te vatten ongelooflijk waardevol.
- Andere mentaliteit. Leiders die uit traditionele organisaties voortkwamen, werden opgevoed met de geest van quid pro quo (Latijn voor ‘quid pro quo’), volgens welke elke actie een adequate beloning zou moeten krijgen. Maar als je wilt investeren in het opbouwen van een bepaalde gemeenschap, moet je op de lange termijn denken. Het is alsof je probeert een subtiel uitgebalanceerd ecosysteem op te bouwen, waarbij elke verkeerde stap een onevenwichtigheid kan veroorzaken en tot langdurige verliezen kan leiden die je misschien niet meteen opmerkt. Leiders moeten zich ontdoen van de mentaliteit die hen verplicht om vandaag, tegen elke prijs, resultaten te boeken, en moeten gaan ondernemen op een manier die hen in staat stelt grotere voordelen te behalen door te investeren in de toekomst.”
En waarom is het belangrijk
Red Hat leeft en opereert volgens principes die heel anders zijn dan die van een traditionele hiërarchische organisatie. En het werkt, het maakt ons commercieel succesvol en menselijk gelukkig. We hebben dit boek vertaald in de hoop de principes van open organisatie te verspreiden onder Russische bedrijven, onder mensen die anders willen en kunnen leven.
, probeer het!
Bron: www.habr.com