«Open organisatie»: Hoe je niet verloren gaat in de chaos en miljoenen kunt verenigen

Een belangrijke dag is aangebroken voor Red Hat, de Russische open source-gemeenschap en iedereen die erbij betrokken is – het boek van Jim Whitehurst "Open Organization: A Passion that Works" is verschenen in het Russisch. Het vertelt uitgebreid en levendig over hoe we bij Red Hat de beste ideeĆ«n en de meest getalenteerde mensen een podium geven, en ook hoe je niet verloren raakt in de chaos en miljoenen mensen van over de hele wereld kunt verenigen.Daarnaast gaat dit boek over leven en praktijk. Het bevat veel tips voor iedereen die wil leren hoe je een bedrijf kunt opbouwen volgens het model van een open organisatie en het effectief kunt leiden. Hieronder volgen enkele belangrijke principes uit het boek die je nu al in gedachten kunt houden.

«Open organisatie»: Hoe je niet verloren gaat in de chaos en miljoenen kunt verenigen

Jim's aanstelling bij het bedrijf is opmerkelijk. Het laat zien dat er in de wereld van open source geen fanfares zijn, maar wel een nieuwe aanpak van leiderschap:

Video afspelen

"Na het gesprek met de recruiter gaf ik aan geĆÆnteresseerd te zijn in een sollicitatiegesprek, en hij vroeg of ik het erg vond om op zondag naar het hoofdkantoor van Red Hat in Raleigh, North Carolina te vliegen. Ik dacht dat zondag een vreemde dag was voor een afspraak. Maar omdat ik toch al van plan was om op maandag naar New York te vliegen, was het voor mij eigenlijk op de weg, en ik stemde toe. Ik stapte in een vliegtuig vanuit Atlanta en arriveerde op de luchthaven van Raleigh-Durham. Van daar nam ik een taxi die me voor het gebouw van Red Hat op de campus van de Universiteit van North Carolina afzette. Het was zondag, het was 9:30 uur en er was niemand in de buurt. Het licht was uitgeschakeld en toen ik controleerde, ontdekte ik dat de deuren op slot waren. In eerste instantie dacht ik dat ze me in de maling namen. Toen ik me omdraaide om terug te keren naar de taxi, 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 halen, kwam Matthew Szulik, later voorzitter van de raad van bestuur en CEO van Red Hat, met zijn auto aanrijden. "Hallo," zei hij. "Wil je een kopje koffie drinken?" Dit leek me een ongebruikelijke manier om een sollicitatiegesprek te beginnen, maar ik besefte dat ik beslist koffie nodig had. Uiteindelijk dacht ik dat het later gemakkelijker zou zijn om een taxi naar de luchthaven te krijgen.

Net toen ik van plan was om ergens heen te gaan om een taxi te nemen, kwam Matthew Shullik, later de voorzitter van de raad van bestuur en de CEO van Red Hat, op zijn auto aangereden. "Hallo," groette hij. "Wil je een kopje koffie?" Dit leek me een ongebruikelijk begin van een interview, maar ik besefte dat ik zeker koffie nodig had. Uiteindelijk dacht ik, het wordt makkelijker om een taxi naar de luchthaven te nemen.

Op zondag is het 's ochtends redelijk rustig in North Carolina. Het kostte wat tijd om een cafƩ te vinden dat eerder dan middag opengging. Het cafƩ bleek niet de beste in de stad en niet de schoonste, maar het was open en daar kon ik vers gezette koffie drinken. We gingen aan een tafeltje zitten en begonnen een gesprek.

Na een minuut of dertig besefte ik dat ik het leuk vond hoe alles ging; het interview was niet traditioneel, maar het gesprek bleek erg interessant. In plaats van te discussiĆ«ren over de fijne kneepjes van de corporate strategie van Red Hat of het imago daarvan op Wall Street – waar ik me op had voorbereid – stelde Matthew Shulik meer vragen over mijn hoop, dromen en doelen. Nu begrijp ik dat Shulik evalueerde of ik zou passen bij de subcultuur en managementstijl van het bedrijf.

Nadat we klaar waren, vertelde Shulik dat hij me wilde introduceren aan de hoofdaanklager van het bedrijf, Michael Cunningham, en stelde voor om hem nu te ontmoeten tijdens een vroege lunch. Ik stemde toe, en we stonden op om te vertrekken. Toen ontdekte mijn gesprekspartner dat hij zijn portemonnee niet bij zich had. 'Oeps,' zei hij. 'Ik heb geen geld. Heb jij dat?' Dit verraste me, maar ik antwoordde dat ik geld had en dat ik bereid was om voor de koffie te betalen.

Enkele minuten later zette Shulik me af bij een klein Mexicaans eettentje, waar ik Michael Cunningham ontmoette. Maar opnieuw volgde er geen traditioneel interview of zakelijke vergadering, maar een ander interessant gesprek. Toen we de rekening wilden betalen, bleek de betaalautomaat in het restaurant kapot te zijn, en ze konden alleen contant geld accepteren. Cunningham keek me aan en vroeg of ik wilde betalen, omdat hij geen contant geld bij zich had. Aangezien ik naar New York ging, had ik genoeg contant geld, dus ik betaalde voor de lunch.

Cunningham bood aan me om me naar de luchthaven te brengen, en we reden in zijn auto. Na een paar minuten vroeg hij: "Vind je het erg als ik stop om te tanken? We zullen snel weer weg zijn." – "Geen probleem," antwoordde ik. Zodra ik het ritmische gebonk van de pomp hoorde, klopte het op het raam. Het was Cunningham. "HĆ©, hier accepteren ze geen creditcards," zei hij. "Mag ik wat geld lenen?" Ik begon me af te vragen of dit gesprek echt een sollicitatie was of dat het een keer wat anders was.

De volgende dag, terwijl ik in New York was, besprak ik dit interview bij Red Hat met mijn vrouw. Ik vertelde haar dat het gesprek erg interessant was, maar ik was niet zeker of deze mensen echt van plan waren me aan te nemen: misschien hadden ze gewoon gratis eten en benzine nodig? Als ik me vandaag die meeting herinner, realiseer ik me dat Shulik en Cunningham gewoon open mensen waren die me behandelden als ieder ander met wie ze een kop koffie konden drinken, lunchen of tanken. Ja, het is grappig en zelfs aandoenlijk dat ze allebei geen geld hadden. Maar voor hen ging het niet om het geld. Ze geloofden, net als de wereld rond open source, niet in het oprollen van rode loper of in pogingen om de gesprekspartner te overtuigen dat alles perfect is. Ze wilden gewoon mij beter leren kennen en niet indruk maken of wijzen op onze verschillen. Ze wilden weten wie ik was.

Mijn eerste sollicitatiegesprek bij Red Hat liet me duidelijk zien dat werken hier een andere manier van doen is. In dit bedrijf was er geen traditionele hiƫrarchie en speciale omgangsvormen voor leidinggevenden, althans niet in de vorm zoals dat gebruikelijk is in de meeste andere bedrijven. In de loop van de tijd leerde ik ook dat Red Hat gelooft in het principe van meritocratie: je moet altijd proberen de beste ideeƫn te implementeren, ongeacht of ze komen van het senior management of van een stagiair die voor de zomer is aangenomen. Met andere woorden, mijn eerste indruk van Red Hat hielp me te zien hoe de toekomst van leiderschap eruit ziet.

Tips voor het bevorderen van meritocratie

Meritocratie is de belangrijkste waarde van de open source gemeenschap. Het maakt niet uit op welk niveau van de piramide je staat, het belangrijkste is hoe goed je ideeƫn zijn. Dit is wat Jim biedt:

  • Zeg nooit: "Dat wil de baas" – en vertrouw niet op hiĆ«rarchieĆ«n. Dit kan je op de korte termijn helpen, maar je bouwt er geen meritocratie mee op.
  • Erken publiekelijk successen en belangrijke bijdragen aan het gemeenschappelijke doel. Dit kan een eenvoudige dank-e-mail zijn, met het hele team in kopie.
  • Denk na: is jouw autoriteit afhankelijk van je positie in de hiĆ«rarchie (of van toegang tot vooraanstaande informatie) of is het het resultaat van verdiend respect? Als het eerste het geval is, begin dan te werken aan het tweede.
  • Vraag om feedback en verzamel ideeĆ«n over een specifiek onderwerp. Reageer op alles, test alleen het beste. Maar neem niet zomaar de beste ideeĆ«n en ga verder – gebruik elke kans om de geest van meritocratie te versterken door iedereen die dat verdient te erkennen.
  • Markeer een voorbeeldige teamlid door een interessante taak aan te bieden, zelfs als deze niet direct verband houdt met zijn of haar gebruikelijke werkgebied.

Laat je 'rocksterren' hun passie volgen.

Enthousiasme en betrokkenheid zijn twee zeer belangrijke woorden in een open organisatie. Ze worden constant herhaald in het boek. Maar je kunt enthousiaste creatieve mensen niet gewoon dwingen om ā€˜van begin tot eind’ te werken, toch? Anders krijg je gewoon niet alles wat hun talent te bieden heeft. Bij Red Hat worden obstakels voor persoonlijke projecten tot een minimum beperkt:

ā€˜Om innovaties te beheren, probeert een bedrijf veel. De aanpak van Google is interessant. Sinds Google in 2004 in elk huishouden bekend werd, hebben leiders en visionairs in de internetbusiness geprobeerd het grote geheim van het bedrijf te ontrafelen, om zijn indrukwekkende succes te herhalen. Een van de bekendste, maar momenteel gesloten programma's, hield in dat alle Google-werknemers werd aangeboden om 20 procent van hun werktijd te besteden aan praktische zaken waar ze zelf voor kiezen. Het idee was als volgt: als medewerkers hun eigen projecten en ideeĆ«n waar ze ook buiten het werk gepassioneerd over zijn, gaan realiseren, beginnen ze innovaties te creĆ«ren. Zo ontstonden succesvolle zijprojecten: GoogleSuggest, AdSense for Content en Orkut; al deze kwamen voort uit dat 20 procent-experiment – een indrukwekkende lijst! [...]

Bij Red Hat hanteren we een minder formele aanpak. We hebben geen vast beleid voor hoeveel tijd elke medewerker aan 'innovatie' moet besteden. In plaats van aan mensen afzonderlijke tijd voor zelfontwikkeling toe te wijzen, zorgen we ervoor dat medewerkers het recht verdienen om hun tijd aan nieuwe ideeƫn te besteden. Eerlijk gezegd hebben velen daar vaak niet veel tijd voor, maar er zijn ook degenen die bijna hun hele werkdag aan innovatie kunnen besteden.

Een typisch geval ziet er als volgt uit: iemand werkt aan een extern project (als hij de managers de betekenis ervan heeft uitgelegd – direct op de werkplek; of in zijn vrije tijd – uit eigen initiatief), en later kan dit werk een aanzienlijk deel van zijn beschikbare uren innemen.

Meer dan alleen brainstormen.

Een lyrische uitweiding. Alex F. Osborn is de uitvinder van de brainstormmethode, waarvan de voortzetting vandaag de synectics-methode is. Het is interessant dat dit idee ontstond tijdens de Tweede Wereldoorlog, toen Osborn bevoCommander van een van de schepen in een Amerikaanse konvooi die onderhevig was aan een torpedoaanval van een Duitse onderzeeƫr. Op dat moment herinnerde de kapitein zich een techniek die door middeleeuwse piraten werd gebruikt: als de bemanning in de problemen kwam, verzamelde iedereen zich op het dek om om de beurt oplossingen voor het probleem aan te bieden. Er waren veel ideeƫn, zelfs aanvankelijk absurde, zoals het idee om met de hele bemanning op de torpedo te blazen. Maar met de straal van de pompen aan boord van elk schip kan men de torpedo heel goed vertragen of zelfs van koers veranderen. Uiteindelijk patentte Osborn zelfs zijn uitvinding: een extra schroef wordt aan de zijkant van het schip gemonteerd die een straal water langs de zijden blaast, waarlangs de torpedo glijdt.

Onze Jim herhaalt constant dat het in een open organisatie niet zo eenvoudig is om te werken. Zelfs het management krijgt het zwaar, aangezien niemand ontkomt aan de noodzaak om zijn mening te verdedigen. Maar deze aanpak is precies wat nodig is om uitstekende resultaten te bereiken:

Online forums [open source developers] en chats zijn vaak gevuld met levendige, en soms zelfs scherpe discussies over alles – van hoe je het beste een softwarefout kunt oplossen tot welke nieuwe functies in de volgende update moeten worden overwogen. Over het algemeen is dit de eerste fase van discussies waarin nieuwe ideeĆ«n naar voren worden gebracht en verzameld, maar er is altijd een volgende ronde – een kritische analyse. Hoewel iedereen aan deze discussies kan deelnemen, moet een persoon bereid zijn zijn standpunt met alle kracht te verdedigen. Onpopulaire ideeĆ«n worden in het beste geval afgewezen, in het slechtste geval belachelijk gemaakt.

Zelfs Linus Torvalds, de maker van het Linux-besturingssysteem, uit zijn onvrede over de voorgestelde wijzigingen in de code. Een keer raakten Linus en David Howell, een van de hoofduitvoerders bij Red Hat, verwikkeld in een verhitte discussie over de voordelen van de codewijziging die door Red Hat werd gevraagd, om de veiligheid voor onze klanten te waarborgen. In antwoord op Howell's verzoek schreef Torvalds: "Eerlijk gezegd, dit [vloekwoord] is onzin. Het lijkt wel alsof het allemaal om die domme interfaces draait, en om volslagen onzinnige redenen. Waarom zouden we dit moeten doen? Ik vind de bestaande X.509 parser al niet leuk. Er worden idioot complexe interfaces gemaakt, en nu worden het er 11. – Linus 9".

De technische details even terzijde latend, bleef Torvalds in zijn volgende boodschap in dezelfde geest schrijven – en op een manier die ik niet durf te citeren. Dit geschil was zo luidruchtig dat het zelfs de pagina's van The Wall Street Journal bereikte. […]

Dit geschil laat zien dat de meeste bedrijven die propriĆ«taire, niet-vrije software uitbrengen, geen open debatten hebben over welke nieuwe kenmerken of wijzigingen ze kunnen doorvoeren. Wanneer een product klaar is, stuurt het bedrijf het gewoon naar de klanten en gaat verder. Tegelijkertijd, in het geval van Linux, houdt de discussie over welke wijzigingen noodzakelijk zijn en – het belangrijkste – waarom ze noodzakelijk zijn, niet op. Dit maakt het proces natuurlijk veel rommeliger en tijdrovender.

Release early, release often

We kunnen de toekomst niet voorspellen, dus moeten we gewoon proberen:

«Wij hanteren 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 worden verzameld in één release (versie) van software, hoe groter de kans is dat er bugs in die versie zijn. Ontwikkelaars van open source-software hebben zich gerealiseerd dat met snelle en frequente releases van software het risico op ernstige problemen met een programma vermindert - aangezien we niet alle updates in één keer op de markt brengen, maar per deel voor elke versie. In de loop der tijd hebben we gemerkt dat deze aanpak niet alleen het aantal fouten vermindert, maar ook leidt tot interessantere oplossingen. Blijkt dat voortdurende kleine verbeteringen uiteindelijk meer innovatie creëren. Misschien is er niets verrassends aan. Een van de sleutelprincipes van moderne productieprocessen, zoals kaizen a of lean b, is de focus op kleine en geleidelijke veranderingen en updates.

[…] Veel van wat we doen, zal misschien niet succesvol zijn. Maar in plaats van veel tijd te besteden aan de vraag wat zal werken en wat niet, geven we er de voorkeur aan om kleine experimenten uit te voeren. De meest gevraagde ideeĆ«n zullen succesvol zijn, terwijl degenen die niet werken, vanzelf verwelken. Op deze manier kunnen we veel dingen uitproberen, in plaats van slechts ƩƩn, en dat zonder al te veel risico voor het bedrijf.

Dit is een rationele manier om middelen te verdelen. Mensen vragen me vaak hoe we beslissen welke open-sourceprojecten we moeten commercialiseren. Hoewel we soms projecten initiƫren, sluiten we ons vaker aan bij bestaande projecten. Een klein team ingenieurs - en soms zelfs ƩƩn persoon - begint bij te dragen aan een van de open-sourceprojecten. Als het project succesvol is en in de smaak valt bij onze klanten, beginnen we er meer tijd en moeite in te steken. Als dat niet het geval is, schakelen de ontwikkelaars over naar een nieuw project. Tegen de tijd dat we besluiten een aanbod te comercialiseren, kan het project zo zijn gegroeid dat de beslissing vanzelfsprekend is. De meest uiteenlopende projecten, waaronder die niet gerelateerd aan software, ontstaan op natuurlijke wijze binnen het hele bedrijf Red Hat, totdat het iedereen duidelijk wordt dat iemand hier nu constant mee aan de slag moet.

Hier is nog een citaat uit het boek:

ā€œIk realiseerde me dat voor het vervullen van zo'n rol de leiders van morgen kenmerken moeten hebben die in gewone organisaties vaak over het hoofd worden gezien. Om effectief te leiden in een open organisatie, moet een leider beschikken over de volgende kwaliteiten.

  • Persoonlijke kracht en zelfvertrouwen. Gewone leiders gebruiken positionele macht - hun functie - om succes te behalen. Maar in een meritocratie moeten leiders respect verdienen. Dit is alleen mogelijk wanneer ze niet bang zijn toe te geven dat ze niet op alle vragen antwoorden hebben. Ze moeten bereid zijn om problemen te bespreken en snel beslissingen te nemen om samen met hun team de beste oplossingen te vinden.
  • Geduld. De media vertellen zelden verhalen over hoe "geduldig" een leider is. Maar hij moet echt geduldig zijn. Wanneer je werkt om het beste uit je team te halen en resultaten te boeken, urenlang dialogen voert en iets steeds weer herhaalt totdat het allemaal goed gedaan is, moet je geduld hebben.
  • Hoge EQ (emotionele intelligentie). Te vaak adverteren we de intellectuele mogelijkheden van leiders, waarbij we ons richten op hun IQ, terwijl we in werkelijkheid hun emotionele intelligentie, oftewel EQ, in overweging moeten nemen. De slimste persoon zijn onder de anderen is niet genoeg als je niet in staat bent om met deze mensen samen te werken. Wanneer je werkt met gemeenschappen van betrokken medewerkers, zoals bij Red Hat, en je hebt niet de mogelijkheid om iemand iets te bevelen, wordt je vermogen om te luisteren, analytisch te verwerken en niet alles persoonlijk te nemen, ongelooflijk waardevol.
  • Een andere mentaliteit. Leiders afkomstig uit traditionele organisaties zijn grootgebracht in de geest van quid pro quo (Latijn voor 'iets voor iets'), waarbij elke actie een adequate tegenprestatie moet krijgen. Maar wanneer je van plan bent te investeren in het creĆ«ren van een bepaalde gemeenschap, moet je op lange termijn denken. Het is alsof je probeert een fijngebalanceerd ecosysteem te bouwen, waarbij elke verkeerde stap een disbalans kan creĆ«ren en leiden tot langdurige verliezen die je misschien niet meteen opmerkt. Leiders moeten afscheid nemen van het type denken dat hen vereist resultaten vandaag en tegen elke prijs te behalen, en moeten beginnen met een manier van werken die hen in staat stelt om grotere voordelen te behalen door te investeren in de toekomst.

En waarom dit belangrijk is

Red Hat leeft en werkt volgens principes die sterk verschillen van die van een traditionele organisatie met hiƫrarchische struktuur. En dat werkt, het maakt ons commercieel succesvol en gelukkig. We hebben dit boek vertaald in de hoop de principes van een open organisatie onder Russische bedrijven te verspreiden, onder mensen die anders willen en kunnen leven.

Lees, probeer het!

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster