"Oop Organisasie": Hoe om nie in chaos te verdwaal en miljoene te verenig nie

’n Belangrike dag het aangebreek vir Red Hat, die Russiese oopbrongemeenskap en almal wat betrokke is – dit is in Russies gepubliseer Jim Whitehurst se boek, The Open Organisation: Passion That Gets Results. Sy vertel in detail en lewendig hoe ons by Red Hat die beste idees en die mees talentvolle mense die pad gee, en ook oor hoe om nie in die chaos te verdwaal en miljoene mense regoor die wêreld te verenig nie.

"Oop Organisasie": Hoe om nie in chaos te verdwaal en miljoene te verenig nie

Hierdie boek handel ook oor die lewe en praktyk. Dit bevat baie raad vir enigiemand wat wil leer hoe om 'n maatskappy te bou deur die oop organisasie-model te gebruik en dit doeltreffend te bestuur. Hieronder is 'n paar van die belangrikste beginsels wat in die boek gegee word waarvan jy nou kan kennis neem.

Jim se diensgeskiedenis by die maatskappy is merkwaardig. Dit wys dat daar geen fanfare in die oopbronwêreld is nie, maar daar is 'n nuwe benadering tot leierskap:

“Nadat ek met die werwer gepraat het, het ek belangstelling in 'n onderhoud uitgespreek, en hy het gevra of ek sou omgee om Sondag na Red Hat-hoofkwartier in Raleigh, Noord-Carolina, te vlieg. Ek het gedink Sondag is 'n vreemde dag om te ontmoet. Maar aangesien ek nog Maandag na New York sou vlieg, was dit oor die algemeen op pad, en ek het ingestem. Ek het op 'n vliegtuig van Atlanta geklim en op die Raleigh Durham-lughawe geland. Vandaar het ek 'n taxi geneem wat my voor die Red Hat-gebou op die Universiteit van Noord-Carolina-kampus afgelaai het. Dit was Sondag, 9:30, en niemand was daar nie. Die ligte was af en toe ek nagegaan het, het ek gevind dat die deure gesluit is. Ek het eers gedink ek word geflous. Toe ek omdraai om terug in die taxi te klim, sien ek dat dit reeds vertrek het. Baie gou het dit begin reën, ek het nie 'n sambreel gehad nie.

Net toe ek iewers heen wou gaan om 'n taxi te haal, het Matthew Shulick, later voorsitter van die raad van direkteure en uitvoerende hoof van Red Hat, in sy motor stilgehou. "Hallo," groet hy. "Wil jy koffie drink?" Dit het na 'n ongewone manier gelyk om 'n onderhoud te begin, maar ek het geweet ek moet beslis 'n bietjie koffie kry. Uiteindelik, het ek gedink, sou dit vir my makliker wees om 'n taxi na die lughawe te haal.

Sondagoggende is redelik stil in Noord-Carolina. Dit het ons 'n rukkie geneem net om 'n koffiewinkel te kry wat voor die middag oopgemaak het. Die koffiewinkel was nie die beste in die stad nie en nie die skoonste nie, maar dit het gewerk en jy kon varsgebroude koffie daar drink. Ons het by 'n tafel gaan sit en begin gesels.

Na ongeveer dertig minute of wat het ek besef dat ek hou van hoe dinge verloop; Die onderhoud was nie tradisioneel nie, maar die gesprek self was baie interessant. In plaas daarvan om die fyner punte van Red Hat se korporatiewe strategie of sy beeld op Wall Street te bespreek – iets waarvoor ek voorberei het – het Matthew Shulick meer gevra oor my hoop, drome en doelwitte. Nou is dit vir my duidelik dat Shulik beoordeel het of ek by die subkultuur en bestuurstyl van die maatskappy sou pas.

Nadat ons klaar was, het Shulick gesê dat hy my wil voorstel aan die maatskappy se algemene raad, Michael Cunningham, en voorgestel dat ek hom nou vir 'n vroeë middagete ontmoet. Ek het ingestem en ons het gereed gemaak om te vertrek. Toe ontdek my gespreksgenoot dat hy nie sy beursie by hom het nie. "Oeps," het hy gesê. - Ek het geen geld nie. En jy?" Dit het my verras, maar ek het geantwoord dat ek geld het en nie omgee om vir die koffie te betaal nie.

’n Paar minute later het Shulik my by ’n klein Mexikaanse restaurant afgelaai waar ek Michael Cunningham ontmoet het. Maar weereens het geen tradisionele onderhoud of sakevergadering gevolg nie, maar nog 'n interessante gesprek het plaasgevind. Toe ons die rekening wou betaal, het dit geblyk dat die restaurant se kredietkaartmasjien stukkend was en ons kon net kontant aanvaar. Cunningham het na my gedraai en gevra of ek gereed is om te betaal, want hy het geen kontant by hom nie. Sedert ek New York toe was, het ek baie kontant gehad, so ek het vir middagete betaal.

Cunningham het aangebied om my lughawe toe te ry, en ons het in sy motor gegaan. Na 'n paar minute het hy gevra: "Gee jy om as ek stop en gas kry? Ons gaan volstoom voort.” “Geen probleem nie,” het ek geantwoord. Sodra ek die ritmiese klank van die pomp hoor, was daar 'n klop aan die venster. Dit was Cunningham. "Haai, hulle neem nie kredietkaarte hier nie," het hy gesê. "Kan ek geld leen?" Ek het begin wonder of dit regtig 'n onderhoud of 'n soort bedrogspul was.

Die volgende dag, terwyl ek in New York was, het ek hierdie onderhoud met my vrou by Red Hat bespreek. Ek het vir haar gesê die gesprek was baie interessant, maar ek was nie seker of hierdie mense ernstig is om my aan te stel nie: dalk wou hulle net gratis kos en gas hê? As ek vandag daardie ontmoeting onthou, verstaan ​​ek dat Shulick en Cunningham bloot oop mense was en my behandel het soos enige ander persoon saam met wie hulle koffie kon drink, middagete of gas kon vul. Ja, dit is snaaks en selfs snaaks dat hulle albei sonder geld beland het. Maar vir hulle het dit nie oor die geld gegaan nie. Hulle het, soos die oopbronwêreld, nie daaraan geglo om rooi tapyte uit te rol of ander te probeer oortuig dat alles perfek is nie. Hulle het net probeer om my beter te leer ken, nie om ons verskille te probeer beïndruk of uit te wys nie. Hulle wou weet wie ek is.

My eerste onderhoud by Red Hat het my duidelik gewys dat die werk hier anders was. Hierdie maatskappy het nie 'n tradisionele hiërargie en spesiale behandeling vir bestuurders gehad nie, ten minste in die vorm wat in die meeste ander maatskappye gebruiklik is. Met verloop van tyd het ek ook geleer dat Red Hat in die beginsel van meritokrasie glo: dit is altyd die moeite werd om die beste idee te probeer implementeer, ongeag of dit van senior bestuur of van 'n somerintern kom. Met ander woorde, my eerste ervaring by Red Hat het my bekendgestel aan hoe die toekoms van leierskap lyk.”

Wenke vir die kweek van meritokrasie

Meritokrasie is die kernwaarde van die oopbrongemeenskap. Dit maak nie vir ons saak watter vlak van die piramide jy beset nie, die belangrikste ding is hoe goed jou idees is. Hier is wat Jim voorstel:

  • Moet nooit sê: "Dit is wat die baas wil hê nie," en moenie op hiërargie staatmaak nie. Dit kan jou dalk op kort termyn help, maar dit is nie hoe jy ’n meritokrasie bou nie.
  • Erken suksesse en belangrike bydraes in die openbaar. Dit kan 'n eenvoudige dankie-e-pos wees met die hele span op kopie.
  • Oorweeg: is jou gesag 'n funksie van jou posisie in die hiërargie (of toegang tot bevoorregte inligting), of is dit 'n gevolg van die respek wat jy verdien het? As die eerste, begin werk aan die tweede.
  • Vra vir terugvoer en versamel idees oor 'n spesifieke onderwerp. Jy moet op alles reageer, net die beste toets. Maar moenie net die beste idees neem en daarmee voortgaan nie – benut elke geleentheid om die gees van meritokrasie te versterk, deur krediet te gee aan almal wat dit verdien.
  • Erken 'n voorbeeldige lid van jou span deur 'n interessante opdrag aan te bied, al is dit nie in hul gewone werksveld nie.

Laat jou rocksterre hul passie volg

Entoesiasme en betrokkenheid is twee baie belangrike woorde in 'n oop organisasie. Hulle word voortdurend in die boek herhaal. Maar jy kan nie passievolle kreatiewe mense kry om hard te werk nie, reg? Andersins kry jy eenvoudig nie alles wat hul talent bied nie. By Red Hat word struikelblokke vir hul eie projekte soveel as moontlik uitgelig:

“Om innovasie aan te dryf, probeer maatskappye baie dinge. Google se benadering is interessant. Sedert Google in 2004 in elke huis bekend geword het, het bestuurders en ideoloë in die internetbesigheid probeer om die maatskappy se hoofgeheim te ontrafel om sy indrukwekkende sukses te herhaal. Een van die bekendste, maar tans geslote programme was dat alle Google-werknemers gevra is om 20 persent van hul tyd te spandeer om byna enigiets te doen wat hulle wou. Die idee was dat indien werknemers hul eie projekte en idees nastreef waaroor hulle passievol was buite die werk, hulle sou begin innoveer. Dit is hoe suksesvolle derdeparty-projekte ontstaan ​​het: GoogleSuggest, AdSense for Content en Orkut; hulle het almal uit hierdie 20 persent eksperiment gekom—'n indrukwekkende lys! […]

By Red Hat volg ons 'n minder formele benadering. Ons het nie ’n vasgestelde beleid oor hoeveel tyd elkeen van ons werknemers aan “innovasie” moet bestee nie. In plaas daarvan om mense toegewyde tyd te gee om hulself op te voed, maak ons ​​seker dat werknemers die reg verdien om hul tyd te spandeer om nuwe dinge te leer. Om eerlik te wees, baie mense het baie min sulke tyd, maar daar is ook diegene wat amper hul hele werksdag aan innovasie kan spandeer.

Die mees tipiese geval lyk so: iemand werk aan 'n syprojek (as hy die belangrikheid daarvan aan bestuurders verduidelik het - direk by die werkplek; of gedurende nie-werksure - op eie inisiatief), en later kan hierdie werk alles in beslag neem sy huidige ure.”

Meer as dinkskrum

“Liriese afwyking. Alex Fakeney Osborne is die uitvinder van die dinkskrummetode, waarvan 'n voortsetting vandag die sinektiese metode is. Dit is eienaardig dat hierdie idee tydens die Tweede Wêreldoorlog verskyn het, toe Osborne een van die skepe van 'n Amerikaanse vragkonvooi aangevoer het wat gevaar was vir 'n torpedo-aanval deur 'n Duitse duikboot. Toe onthou die kaptein die tegniek wat die seerowers van die Middeleeue gebruik het: as die bemanning in die moeilikheid beland het, het al die matrose op die dek bymekaargekom om om die beurt 'n manier te voorstel om die probleem op te los. Daar was baie idees, insluitend absurde idees met die eerste oogopslag: byvoorbeeld die idee om met die hele span op 'n torpedo te blaas. Maar met die straal van 'n skeepspomp, wat op elke skip beskikbaar is, is dit heel moontlik om 'n torpedo te vertraag of selfs sy koers te verander. As gevolg hiervan het Osborne selfs 'n uitvinding gepatenteer: 'n bykomende skroef is aan die kant van die skip gemonteer, wat 'n stroom water langs die kant aandryf, en die torpedo gly langsaan.

Ons Jim herhaal voortdurend dat dit nie so maklik is om in 'n oop organisasie te werk nie. Selfs die bestuur kry dit, aangesien niemand die behoefte ontsien word om hul mening te verdedig nie. Maar dit is presies die benadering wat nodig is om uitstekende resultate te behaal:

“Aanlyn [oopbron] forums en kletskamers is dikwels gevul met lewendige en soms bittere besprekings oor alles van hoe om 'n sagtewarefout die beste reg te stel tot watter nuwe kenmerke in die volgende opdatering oorweeg moet word. As 'n reël is dit die eerste fase van besprekings, waartydens nuwe idees na vore gebring en opgehoop word, maar daar is altyd 'n volgende rondte - kritiese ontleding. Alhoewel enigiemand aan hierdie debatte kan deelneem, moet 'n persoon bereid wees om sy posisie met alle mag te verdedig. Ongewilde idees sal op sy beste verwerp word, in die ergste geval bespot word.

Selfs Linus Torvalds, die skepper van die Linux-bedryfstelsel, spreek sy onenigheid uit met die voorgestelde veranderinge aan die kode. Eendag het Linus en David Howells, een van Red Hat se hoofontwikkelaars, 'n hewige debat beland oor die meriete van 'n kodeverandering wat Red Hat versoek het wat sal help om sekuriteit aan ons kliënte te bied. In reaksie op Howells se versoek het Torvalds geskryf: “Eerlik gesê, dit is [ondrukbare woord] idioot. Dit lyk asof alles om hierdie dom koppelvlakke draai, en om heeltemal dom redes. Hoekom moet ons dit doen? Ek hou nie meer van die bestaande X.509-ontleder nie. Dom komplekse koppelvlakke word geskep, en nou sal daar 11 van hulle wees. – Linus 9.”

Om tegniese besonderhede tersyde te laat, het Torvalds in die volgende boodskap voortgegaan om in dieselfde gees te skryf – en op so ’n manier dat ek nie durf aanhaal nie. Hierdie dispuut was so hard dat dit selfs op die bladsye van The Wall Street Journal gekom het. […]

Hierdie debat toon dat die meeste maatskappye wat eie, nie-vrye sagteware vervaardig, nie 'n oop debat voer oor watter nuwe kenmerke of veranderinge hulle dalk aan werk nie. Wanneer die produk gereed is, stuur die maatskappy dit eenvoudig aan kliënte en gaan aan. Terselfdertyd, in die geval van Linux, bedaar besprekings oor watter veranderinge nodig is en – die belangrikste – hoekom dit nodig is, nie. Dit maak die hele proses natuurlik baie meer deurmekaar en tydrowend.”

Laat vroeg vry, laat dikwels vry

Ons kan nie die toekoms voorspel nie, so ons moet net probeer:

"Ons werk volgens die beginsel van "vroeë bekendstelling, gereelde opdaterings." Die sleutelprobleem van enige sagtewareprojek is die risiko van foute of foute in die bronkode. Natuurlik, hoe meer veranderinge en opdaterings in een weergawe (weergawe) van sagteware versamel word, hoe groter is die waarskynlikheid dat daar foute in hierdie weergawe sal wees. Oopbronsagteware-ontwikkelaars het besef dat deur sagteware-weergawes vinnig en gereeld vry te stel, die risiko van ernstige probleme met enige program verminder word – ons bring immers nie alle opdaterings op een slag na die mark nie, maar een op 'n slag vir elke weergawe. Met verloop van tyd het ons opgemerk dat hierdie benadering nie net foute verminder nie, maar ook tot meer interessante oplossings lei. Dit blyk dat voortdurend klein verbeterings op die lang termyn meer innovasie skep. Miskien is hier niks verbasends nie. Een van die sleutelbeginsels van moderne vervaardigingsprosesse soos kaizen a of lean b is 'n fokus op klein en inkrementele veranderinge en opdaterings.

[…] Baie van dit waaraan ons werk sal dalk nie slaag nie. Maar in plaas daarvan om baie tyd te spandeer om te wonder wat sal werk en wat nie, verkies ons om klein eksperimente uit te voer. Die gewildste idees sal tot sukses lei, en dié wat nie werk nie, sal vanself wegkwyn. Op hierdie manier kan ons baie dinge probeer eerder as net een ding, sonder veel risiko vir die maatskappy.

Dit is 'n rasionele manier om hulpbronne toe te wys. Byvoorbeeld, mense vra my dikwels hoe ons kies watter oopbronprojekte om te kommersialiseer. Terwyl ons soms projekte inisieer, spring ons meer dikwels as nie bloot in bestaandes. ’n Klein groepie ingenieurs—soms net een persoon—begin bydra tot een van die oopbrongemeenskap se projekte. As die projek suksesvol is en in aanvraag onder ons kliënte is, begin ons meer tyd en moeite daaraan bestee. Indien nie, gaan die ontwikkelaars aan na 'n nuwe projek. Teen die tyd dat ons besluit om die voorstel te kommersialiseer, het die projek dalk so gegroei dat die oplossing voor die hand liggend is. Verskeie projekte, insluitend nie-sagtewareprojekte, duik natuurlik regdeur Red Hat op totdat dit vir almal duidelik word dat iemand nou voltyds hieraan sal moet werk.”

Hier is nog 'n aanhaling uit die boek:

“Ek het besef dat om hierdie rol te vervul, môre se leiers eienskappe moet hê wat eenvoudig misgekyk word in konvensionele organisasies. Om 'n oop organisasie effektief te lei, moet 'n leier oor die volgende eienskappe beskik.

  • Persoonlike krag en selfvertroue. Gewone leiers gebruik posisionele mag – hul posisie – om sukses te behaal. Maar in 'n meritokrasie moet leiers respek verdien. En dit is net moontlik as hulle nie bang is om te erken dat hulle nie al die antwoorde het nie. Hulle moet bereid wees om probleme te bespreek en vinnig besluite te neem om die beste oplossings saam met hul span te vind.
  • Geduld. Die media vertel selde stories oor hoe “geduldig” ’n leier is. Maar hy moet regtig geduldig wees. Wanneer jy werk om die beste pogings en resultate van jou span te kry, ure lank gesprekke voer en dinge oor en oor herhaal totdat dit reg gedoen is, moet jy geduldig wees.
  • Hoë EQ (emosionele intelligensie). Te dikwels bevorder ons die intelligensie van leiers deur op hul IK te fokus, terwyl wat werklik in ag geneem moet word hul emosionele intelligensiekwosiënt, of EQ-telling, is. Om die slimste mens onder ander te wees, is nie genoeg as jy nie met daardie mense kan werk nie. Wanneer jy met gemeenskappe van betrokke werknemers soos Red Hat werk, en jy het nie die vermoë om enigiemand rond te bestel nie, word jou vermoë om te luister, analities te verwerk en dinge nie persoonlik op te neem nie, ongelooflik waardevol.
  • Ander mentaliteit. Leiers wat uit tradisionele organisasies gekom het, is opgevoed met die gees van quid pro quo (Latyns vir "quid pro quo"), waarvolgens elke aksie 'n voldoende opbrengs moet ontvang. Maar wanneer jy wil belê in die bou van 'n spesifieke gemeenskap, moet jy langtermyn dink. Dit is soos om 'n fyn gebalanseerde ekosisteem te probeer bou, waar enige verkeerde stap 'n wanbalans kan skep en tot langtermynverliese kan lei wat jy dalk nie dadelik opmerk nie. Leiers moet ontslae raak van die ingesteldheid wat vereis dat hulle vandag resultate moet behaal, tot elke prys, en begin sake doen op ’n manier wat hulle in staat stel om groter voordele te pluk deur in die toekoms te belê.”

En hoekom is dit belangrik

Red Hat leef en werk volgens beginsels wat baie verskil van 'n tradisionele hiërargiese organisasie. En dit werk, dit maak ons ​​kommersieel suksesvol en menslik gelukkig. Ons het hierdie boek vertaal in die hoop om die beginsels van oop organisasie onder Russiese maatskappye te versprei, onder mense wat anders wil en kan leef.

Lees, probeer dit!

Bron: will.com

Voeg 'n opmerking