„Nyílt szervezet”: Hogyan ne vessz el a káoszban és egyesítsd a milliókat

Fontos nap érkezett el a Red Hat, az orosz nyílt forráskódú közösség és minden érintett számára – oroszul jelent meg Jim Whitehurst könyve, a The Open Organization: Passion That Gets Results. Részletesen és szemléletesen meséli el, hogy mi a Red Hatnél hogyan adjuk meg a legjobb ötleteket és a legtehetségesebb embereket, és arról is, hogyan ne vessz el a káoszban, és hogyan egyesítsünk emberek millióit szerte a világon.

„Nyílt szervezet”: Hogyan ne vessz el a káoszban és egyesítsd a milliókat

Ez a könyv az életről és a gyakorlatról is szól. Rengeteg tanácsot tartalmaz mindazoknak, akik szeretnének megtanulni, hogyan építsenek fel egy vállalatot a nyílt szervezeti modell segítségével és hogyan irányítsák azt hatékonyan. Az alábbiakban felsorolunk néhányat a könyvben található legfontosabb alapelvekből, amelyeket már most tudomásul vehetsz.

Jim munkás múltja a cégnél figyelemre méltó. Ez azt mutatja, hogy a nyílt forráskódú világban nincs fanfár, de van egy új megközelítés a vezetésben:

„Miután beszéltem a toborzóval, érdeklődést mutattam egy interjú iránt, és megkérdezte, nem lenne-e kedvem vasárnap az észak-karolinai Raleigh-ben lévő Red Hat főhadiszállására repülni. Azt hittem, a vasárnap furcsa nap volt a találkozásra. De mivel hétfőn még New Yorkba akartam repülni, általában már úton voltam, és beleegyeztem. Repülőgépre szálltam Atlantából, és leszálltam a Raleigh Durham repülőtéren. Innen taxiba szálltam, amely lerakott a Red Hat épülete előtt az Észak-Karolinai Egyetem campusán. Vasárnap volt, 9:30, és senki sem volt a közelben. A lámpák le voltak kapcsolva, és miután ellenőriztem, az ajtók zárva voltak. Először azt hittem, hogy becsapnak. Ahogy megfordultam, hogy visszaszálljak a taxiba, láttam, hogy az már elment. Nagyon hamar elkezdett esni az eső, nem volt esernyőm.

Épp amikor mentem valahova taxit fogni, Matthew Shulick, a Red Hat igazgatótanácsának későbbi elnöke és vezérigazgatója beállt az autójába. – Szia – köszönt. – Szeretnél inni egy kávét? Ez szokatlan módnak tűnt az interjú megkezdéséhez, de tudtam, hogy mindenképpen innom kell egy kávét. Végső soron úgy gondoltam, hogy könnyebb lesz elkapnom egy taxit a repülőtérre.

A vasárnap reggelek meglehetősen csendesek Észak-Karolinában. Eltartott egy ideig, amíg megtaláltunk egy kávézót, amely dél előtt megnyílt. A kávézó nem volt a legjobb a városban és nem a legtisztább, de működött, és ott lehetett frissen főzött kávét inni. Leültünk egy asztalhoz és beszélgetni kezdtünk.

Körülbelül harminc perc múlva rájöttem, hogy tetszik a dolgok menete; Az interjú nem volt hagyományos, de maga a beszélgetés nagyon érdekesre sikerült. Matthew Shulick ahelyett, hogy a Red Hat vállalati stratégiájának vagy Wall Street-i imázsának finomabb pontjait tárgyalta volna – amire már felkészültem –, többet kérdezett a reményeimről, álmaimról és céljaimról. Most már világos számomra, hogy Shulik felmérte, hogy megfelelek-e a cég szubkultúrájának és vezetési stílusának.

Miután befejeztük, Shulick azt mondta, hogy be akar mutatni a cég főtanácsosának, Michael Cunninghamnek, és azt javasolta, hogy találkozzam vele most egy korai ebédre. Beleegyeztem és indulni készültünk. Aztán beszélgetőtársam rájött, hogy nincs nála a pénztárca. – Hoppá – mondta. - Nincs pénzem. És te?" Ez meglepett, de azt válaszoltam, hogy van pénzem, és nem bánom, hogy fizetek a kávéért.

Néhány perccel később Shulik kirakott egy kis mexikói étterembe, ahol találkoztam Michael Cunninghammel. De ismét nem hagyományos interjú vagy üzleti megbeszélés következett, hanem egy újabb érdekes beszélgetésre került sor. Amikor a számlát ki akartuk fizetni, kiderült, hogy az étterem bankkártya-automata elromlott, és csak készpénzt tudunk elfogadni. Cunningham hozzám fordult, és megkérdezte, kész vagyok-e fizetni, mert nem volt nála készpénz. Mivel New Yorkba mentem, sok készpénzem volt, ezért fizettem az ebédet.

Cunningham felajánlotta, hogy elvisz a repülőtérre, és az ő kocsijával mentünk. Néhány perc múlva megkérdezte: „Nem bánod, ha megállok és benzint kapok? Teljes gőzzel megyünk tovább." – Semmi gond – válaszoltam. Amint meghallottam a szivattyú ritmikus hangját, kopogtattak az ablakon. Cunningham volt. – Hé, itt nem fogadnak el hitelkártyát – mondta. "Kölcsönkérhetek egy kis pénzt?" Elkezdtem azon tűnődni, hogy ez tényleg egy interjú, vagy valami csalás.

Másnap New Yorkban megbeszéltem ezt az interjút a feleségemmel a Red Hatnél. Mondtam neki, hogy a beszélgetés nagyon érdekes volt, de nem voltam benne biztos, hogy ezek az emberek komolyan gondolták-e a felvételemet: lehet, hogy csak ingyen ételt és benzint akarnak? Emlékszem a mai találkozóra, megértem, hogy Shulick és Cunningham egyszerűen nyitott emberek voltak, és úgy bántak velem, mint bárki mással, akivel együtt kávézhattak, ebédelhettek vagy tankolhattak benzint. Igen, vicces, sőt vicces, hogy mindketten pénz nélkül végeztek. De számukra ez nem a pénzről szólt. A nyílt forráskódú világhoz hasonlóan ők sem hittek a vörös szőnyegek kiterítésében, és nem akartak meggyőzni másokat arról, hogy minden tökéletes. Csak próbáltak jobban megismerni, nem próbáltak lenyűgözni vagy rámutatni a különbségeinkre. Tudni akarták, ki vagyok.

Az első interjúm a Red Hatnél egyértelműen megmutatta, hogy itt más a munka. Ez a cég nem rendelkezett hagyományos hierarchiával és különleges bánásmóddal a vezetőkkel szemben, legalábbis abban a formában, ahogy az a legtöbb vállalatnál megszokott. Idővel azt is megtanultam, hogy a Red Hat hisz a meritokrácia elvében: mindig a legjobb ötletet érdemes megpróbálni megvalósítani, függetlenül attól, hogy felső vezetéstől vagy nyári gyakornoktól érkezik. Más szavakkal, a Red Hatnél szerzett első tapasztalatom bemutatott, hogyan néz ki a vezetés jövője.”

Tippek a meritokrácia ápolásához

A meritokrácia a nyílt forráskódú közösség alapértéke. Számunkra nem mindegy, hogy a piramis melyik szintjét foglalod el, a lényeg az, hogy mennyire jók az ötleteid. Íme, amit Jim javasol:

  • Soha ne mondd: „Ez az, amit a főnök akar”, és ne hagyatkozz a hierarchiára. Ez rövid távon segíthet, de nem így építhetsz meritokráciát.
  • Nyilvánosan ismerje el a sikereket és a fontos hozzájárulásokat. Ez lehet egy egyszerű köszönő e-mail a teljes csapattal.
  • Fontolja meg: a tekintélye a hierarchiában elfoglalt pozíciójának (vagy a kiemelt információkhoz való hozzáférésének) a függvénye, vagy a kiérdemelt tisztelet eredménye? Ha az első, kezdjen el dolgozni a másodikon.
  • Kérjen visszajelzést és gyűjtsön ötleteket egy adott témában. Mindenre reagálni kell, csak a legjobbat tesztelni. De ne csak a legjobb ötleteket ragadd meg és folytasd velük – ragadj meg minden lehetőséget a meritokrácia szellemének erősítésére, elismerést adva mindenkinek, aki megérdemli.
  • Ismerje fel csapatának egy példamutató tagját azzal, hogy érdekes megbízást ad, még akkor is, ha az nem a megszokott munkaterületükhöz tartozik.

Hagyja, hogy rocksztárjai kövessék szenvedélyüket

A lelkesedés és a részvétel két nagyon fontos szó egy nyitott szervezetben. Folyamatosan ismétlődnek a könyvben. De a szenvedélyes kreatív embereket nem lehet kemény munkára rávenni, igaz? Ellenkező esetben egyszerűen nem kapsz meg mindent, amit a tehetségük kínál. A Red Hatnél a saját projektjeik előtt álló akadályokat a lehető legjobban elhárítják:

„Az innováció ösztönzése érdekében a vállalatok sok mindent kipróbálnak. Érdekes a Google megközelítése. Amióta a Google 2004-ben minden otthonban ismertté vált, az internetes üzletág vezetői és ideológusai megpróbálták megfejteni a cég fő titkát, hogy megismételjék lenyűgöző sikerét. Az egyik leghíresebb, de jelenleg lezárt program az volt, hogy a Google összes alkalmazottját arra kérték, hogy ideje 20 százalékát töltse azzal, amit csak akar. Az ötlet az volt, hogy ha az alkalmazottak a munkájukon kívül is megvalósítják saját projekteiket és ötleteiket, amelyek iránt szenvedélyesek, akkor innovációba kezdenek. Így születtek sikeres harmadik féltől származó projektek: GoogleSuggest, AdSense Kontextusban és Orkut; mind ebből a 20 százalékos kísérletből származtak – lenyűgöző lista! […]

A Red Hatnél kevésbé formális megközelítést alkalmazunk. Nincs meghatározott irányelvünk arra vonatkozóan, hogy minden alkalmazottunknak mennyi időt kell „innovációra” fordítania. Ahelyett, hogy időt szentelnénk az embereknek önképzésre, gondoskodunk arról, hogy az alkalmazottak jogot szerezzenek arra, hogy idejüket új dolgok tanulására fordítsák. Őszintén szólva sokaknak nagyon kevés idejük van, de vannak olyanok is, akik szinte az egész munkanapjukat innovációval tölthetik.

A legjellemzőbb eset valahogy így néz ki: valaki egy mellékprojekten dolgozik (ha ennek fontosságát - közvetlenül a munkahelyen; vagy munkaszüneti időben - saját kezdeményezésére elmagyarázta a vezetőknek), és később ez a munka elfoglalhat mindent. jelenlegi órái."

Több mint ötletelés

„Lírai kitérő. Alex Fakeney Osborne az ötletbörze módszer feltalálója, melynek mai folytatása a synectics módszer. Érdekes, hogy ez az ötlet a második világháború idején jelent meg, amikor Osborne egy amerikai teherszállító konvoj egyik hajóját vezényelte, amelyet egy német tengeralattjáró torpedótámadása fenyegetett. Aztán a kapitánynak eszébe jutott a technika, amelyhez a középkor kalózai folyamodtak: ha a legénység bajba került, az összes matróz összegyűlt a fedélzeten, hogy felváltva javaslatot tegyenek a probléma megoldására. Sok ötlet volt, köztük első pillantásra abszurd is: például az az ötlet, hogy az egész csapattal egy torpedóra fújjunk. De a hajószivattyú sugárjával, amely minden hajón elérhető, nagyon is lehetséges a torpedó lelassítása vagy akár az irány megváltoztatása. Ennek eredményeként Osborne még egy találmányt is szabadalmaztatott: a hajó oldalára egy további légcsavart szereltek, amely vízáramot hajt az oldal mentén, és a torpedó elcsúszik mellette.

Jimünk folyton azt hajtogatja, hogy nem is olyan könnyű nyitott szervezetben dolgozni. Még a vezetőség is rájön, hiszen senkit sem kíméli meg a véleményének megvédése. De pontosan ez a megközelítés szükséges a kiváló eredmények eléréséhez:

„Az online [nyílt forráskódú] fórumok és csevegőszobák gyakran tele vannak élénk és néha éles vitákkal a szoftverhibák legjobb kijavításának módjától kezdve egészen addig, hogy milyen új funkciókat érdemes figyelembe venni a következő frissítésben. Általában ez a megbeszélések első szakasza, amely során új ötletek kerülnek elő és halmozódnak fel, de mindig van egy következő kör - kritikai elemzés. Bár ezekben a vitákban bárki részt vehet, az embernek fel kell készülnie arra, hogy minden erejével megvédje álláspontját. A népszerűtlen ötleteket legjobb esetben elutasítják, legrosszabb esetben nevetségessé teszik.

Még Linus Torvalds, a Linux operációs rendszer megalkotója is nem ért egyet a kódon javasolt változtatásokkal. Egy napon Linus és David Howells, a Red Hat egyik vezető fejlesztője heves vitába keveredett a Red Hat által kért kódmódosítás érdemeiről, amely elősegítené ügyfeleink biztonságát. Howells kérésére válaszolva Torvalds ezt írta: „Őszintén szólva, ez [nem nyomtatható szó] idióta. Úgy tűnik, minden ezek körül a hülye interfészek körül forog, és teljesen hülye okokból. Miért tegyük ezt? A meglévő X.509 értelmező már nem tetszik. Hülye összetett felületek készülnek, és most 11 lesz belőlük. – Linus 9.”

A technikai részleteket figyelmen kívül hagyva Torvalds a következő üzenetben is ugyanebben a szellemben írt – méghozzá úgy, hogy nem merek idézni. Ez a vita olyan hangos volt, hogy még a The Wall Street Journal oldalaira is felkerült. […]

Ez a vita azt mutatja, hogy a legtöbb, saját tulajdonú, nem ingyenes szoftvert gyártó vállalat nem folytat nyílt vitát arról, hogy milyen új funkciókon vagy változtatásokon dolgozhatnak. Amikor a termék készen van, a vállalat egyszerűen kiszállítja azt az ügyfeleknek, és továbblép. Ugyanakkor a Linux esetében nem csillapodnak el a viták arról, hogy milyen változtatásokra van szükség és - ami a legfontosabb - miért van szükség ezekre. Ez természetesen sokkal zavarosabbá és időigényesebbé teszi az egész folyamatot.”

Korán engedje el, gyakran engedje el

A jövőt nem tudjuk megjósolni, ezért csak meg kell próbálnunk:

„A „korai indítás, gyakori frissítések” elve alapján működünk. Bármely szoftverprojekt kulcsproblémája a forráskód hibáinak vagy hibáinak kockázata. Nyilvánvaló, hogy minél több módosítást és frissítést gyűjtenek össze a szoftver egy kiadásában (verziójában), annál nagyobb a valószínűsége annak, hogy ebben a verzióban hibák lesznek. A nyílt forráskódú szoftverfejlesztők rájöttek, hogy a szoftververziók gyors és gyakori kiadásával minden programnál csökken a komoly problémák kockázata – elvégre nem egyszerre hozzuk forgalomba az összes frissítést, hanem mindegyik verzióhoz egyenként. Idővel észrevettük, hogy ez a megközelítés nemcsak a hibákat csökkenti, hanem érdekesebb megoldásokhoz is vezet. Kiderült, hogy a folyamatos apró fejlesztések hosszú távon több innovációt eredményeznek. Talán nincs itt semmi meglepő. A modern gyártási folyamatok, például a kaizen a vagy a lean b egyik kulcsfontosságú elve a kis és fokozatos változtatásokra és frissítésekre való összpontosítás.

[…] Sok minden, amin dolgozunk, nem biztos, hogy sikerül. De ahelyett, hogy sok időt töltenénk azon, hogy mi fog működni és mi nem, inkább kis kísérleteket végzünk. A legnépszerűbb ötletek vezetnek a sikerhez, a nem működők pedig maguktól elsorvadnak. Így sok mindent kipróbálhatunk, nem csak egyet, anélkül, hogy nagy kockázatot jelentene a cég.

Ez egy racionális módja az erőforrások elosztásának. Például az emberek gyakran kérdezik tőlem, hogyan válasszuk ki, hogy mely nyílt forráskódú projekteket kívánjuk kereskedelmi forgalomba hozni. Míg néha kezdeményezünk projekteket, gyakran egyszerűen belevágunk a meglévőkbe. Mérnökök egy kis csoportja – néha csak egy személy – elkezd részt venni a nyílt forráskódú közösség egyik projektjében. Ha a projekt sikeres és igényes ügyfeleink körében, több időt és energiát fordítunk rá. Ha nem, a fejlesztők egy új projektre lépnek. Mire úgy döntünk, hogy a javaslatot kereskedelmi forgalomba hozzuk, a projekt már akkorára nőtt, hogy a megoldás kézenfekvő. Különféle projektek, beleértve a nem szoftvereseket is, természetesen felbukkannak a Red Haten, amíg mindenki számára világossá nem válik, hogy most valakinek ezen a teljes munkaidőben dolgoznia kell.”

Íme egy másik idézet a könyvből:

„Rájöttem, hogy ennek a szerepnek a betöltéséhez a holnap vezetőinek olyan jellemzőkkel kell rendelkezniük, amelyeket a hagyományos szervezetek egyszerűen figyelmen kívül hagynak. Egy nyitott szervezet hatékony vezetéséhez a vezetőnek a következő tulajdonságokkal kell rendelkeznie.

  • Személyes erő és magabiztosság. A hétköznapi vezetők a helyzeti hatalmat – pozíciójukat – használják fel a siker eléréséhez. De egy meritokráciában a vezetőknek tiszteletet kell kivívniuk. Ez pedig csak akkor lehetséges, ha nem félnek beismerni, hogy nincs mindenre a válaszuk. Hajlandónak kell lenniük megvitatni a problémákat és gyorsan meghozni a döntéseket, hogy csapatukkal megtalálják a legjobb megoldást.
  • Türelem. A média ritkán mesél arról, hogy mennyire „türelmes” egy vezető. De tényleg türelmesnek kell lennie. Amikor azon dolgozik, hogy a legjobb erőfeszítéseket és eredményeket érje el csapata, órákon át beszélget, és ismételgeti a dolgokat újra és újra, amíg jól nem sikerül, türelmesnek kell lennie.
  • Magas EQ (érzelmi intelligencia). Túl gyakran segítjük elő a vezetők intelligenciáját azáltal, hogy az IQ-jukra összpontosítunk, amikor igazán figyelembe kell venni az érzelmi intelligencia hányadosát vagy az EQ-pontszámát. Nem elég a legokosabb embernek lenni mások mellett, ha nem tud ezekkel az emberekkel együtt dolgozni. Amikor olyan elkötelezett alkalmazottak közösségeivel dolgozik együtt, mint a Red Hat, és nincs lehetősége arra, hogy bárkit a közelébe rendeljen, hihetetlenül értékessé válik az a képessége, hogy figyeljen, analitikusan feldolgozza, és ne vegye személyesen a dolgokat.
  • Más mentalitás. A hagyományos szervezetekből érkezett vezetőket a quid pro quo (latinul „quid pro quo”) szellemében nevelték, amely szerint minden tettnek megfelelő megtérülést kell kapnia. De ha egy adott közösség felépítésébe szeretne befektetni, hosszú távon kell gondolkodnia. Ez olyan, mintha egy finoman kiegyensúlyozott ökoszisztémát próbálnánk felépíteni, ahol minden rossz lépés felboríthatja az egyensúlyt, és hosszú távú veszteségekhez vezethet, amelyeket nem biztos, hogy azonnal észrevesz. A vezetőknek meg kell szabadulniuk attól a gondolkodásmódtól, amely megköveteli tőlük, hogy ma, bármi áron eredményeket érjenek el, és úgy kezdjenek üzletet folytatni, hogy a jövőbe való befektetés révén nagyobb haszonra tegyenek szert.”

És miért fontos

A Red Hat olyan elvek szerint él és működik, amelyek nagyon különböznek egy hagyományos hierarchikus szervezettől. És működik, üzletileg sikeressé és emberileg boldoggá tesz bennünket. Ezt a könyvet annak reményében fordítottuk le, hogy a nyitott szervezet elveit elterjesszük az orosz cégek körében, olyan emberek között, akik másképp akarnak és tudnak élni.

olvas, próbáld ki!

Forrás: will.com

Hozzászólás