“Açık Örgütlenme”: Kaosta kaybolmamak ve milyonları birleştirmemek

Red Hat, Rus açık kaynak topluluğu ve katılan herkes için önemli bir gün geldi; Rusça yayınlandı Jim Whitehurst'un kitabı Açık Organizasyon: Sonuç Getiren Tutku. Red Hat olarak en iyi fikirlere ve en yetenekli insanlara nasıl yol gösterdiğimizi, aynı zamanda kaos içinde kaybolmamayı ve dünya çapında milyonlarca insanı nasıl birleştirebileceğimizi ayrıntılı ve canlı bir şekilde anlatıyor.

“Açık Örgütlenme”: Kaosta kaybolmamak ve milyonları birleştirmemek

Bu kitap aynı zamanda yaşam ve pratikle de ilgilidir. Açık organizasyon modelini kullanarak bir şirketin nasıl kurulacağını ve onu etkili bir şekilde yönetmeyi öğrenmek isteyen herkes için birçok tavsiye içerir. Aşağıda kitapta verilen ve şu anda not alabileceğiniz en önemli ilkelerden birkaçı yer almaktadır.

Jim'in şirketteki istihdam geçmişi dikkat çekicidir. Açık kaynak dünyasında tantana olmadığını ancak liderliğe yeni bir yaklaşımın olduğunu gösteriyor:

"İşe alım sorumlusuyla konuştuktan sonra bir röportajla ilgilendiğimi belirttim ve o da Pazar günü Raleigh, Kuzey Carolina'daki Red Hat genel merkezine uçmanın sakıncası olup olmadığını sordu. Pazar gününün buluşmak için tuhaf bir gün olduğunu düşündüm. Ancak Pazartesi günü yine de New York'a uçacağım için genel olarak yolumdaydı ve kabul ettim. Atlanta'dan uçağa bindim ve Raleigh Durham Havalimanı'na indim. Oradan beni Kuzey Carolina Üniversitesi kampüsündeki Red Hat binasının önüne bırakan bir taksiye bindim. Pazar günü sabah 9:30'du ve etrafta kimse yoktu. Işıklar kapalıydı ve kontrol ettiğimde kapıların kilitli olduğunu gördüm. İlk başta kandırıldığımı düşündüm. Taksiye binmek için döndüğümde çoktan gitmiş olduğunu gördüm. Çok geçmeden yağmur yağmaya başladı, şemsiyem yoktu.

Tam taksiye binmek için bir yere gitmek üzereyken, daha sonra Red Hat'in yönetim kurulu başkanı ve CEO'su olacak Matthew Shulick arabasına bindi. "Merhaba" diye selamladı. “Biraz kahve içmek ister misin?” Bu bir röportaja başlamanın alışılmadık bir yolu gibi görünüyordu ama kesinlikle biraz kahve almam gerektiğini biliyordum. Sonuçta havaalanına taksiye binmenin benim için daha kolay olacağını düşündüm.

Kuzey Carolina'da pazar sabahları oldukça sessizdir. Öğleden önce açılan bir kahve dükkanı bulmamız biraz zaman aldı. Kahvehane şehrin en iyisi ve en temizi değildi ama işe yaradı ve orada taze demlenmiş kahve içebiliyordunuz. Bir masaya oturduk ve konuşmaya başladık.

Yaklaşık otuz dakika sonra işlerin gidişatından hoşlandığımı fark ettim; Röportaj geleneksel değildi ama sohbetin kendisi çok ilginç çıktı. Matthew Shulick, Red Hat'in kurumsal stratejisinin veya Wall Street'teki imajının ince noktalarını tartışmak yerine (ki buna hazırlıklıydım) umutlarım, hayallerim ve hedeflerim hakkında daha fazla bilgi sordu. Artık Shulik'in şirketin alt kültürüne ve yönetim tarzına uyup uymayacağımı değerlendirdiğini açıkça görüyorum.

Bitirdikten sonra Shulick beni şirketin baş danışmanı Michael Cunningham'la tanıştırmak istediğini söyledi ve onunla erken bir öğle yemeği için buluşmamı önerdi. Kabul ettim ve ayrılmaya hazırlandık. Daha sonra muhatabım cüzdanının yanında olmadığını keşfetti. "Ah," dedi. - Param yok. Peki sen?" Bu beni şaşırttı ama param olduğunu ve kahvenin parasını ödemekten çekinmediğimi söyledim.

Birkaç dakika sonra Shulik beni küçük bir Meksika restoranına bıraktı ve orada Michael Cunningham'la tanıştım. Ancak bunu yine geleneksel bir röportaj veya iş toplantısı takip etmedi, ancak ilginç bir sohbet daha gerçekleşti. Hesabı ödemek üzereyken restoranın kredi kartı makinesinin bozuk olduğu ortaya çıktı ve sadece nakit kabul edebiliyorduk. Cunningham bana döndü ve ödemeye hazır olup olmadığımı sordu çünkü yanında hiç nakit yoktu. New York'a gideceğim için çok param vardı, bu yüzden öğle yemeğini ödedim.

Cunningham beni havaalanına götürmeyi teklif etti ve onun arabasına bindik. Birkaç dakika sonra sordu, “Durup benzin almamın bir sakıncası var mı? Tam gaz yolumuza devam edeceğiz." "Sorun değil" diye yanıtladım. Pompanın ritmik sesini duyar duymaz pencere vuruldu. Cunningham'dı bu. "Hey, burada kredi kartı kabul etmiyorlar" dedi. "Biraz para ödünç alabilir miyim?" Bunun gerçekten bir röportaj mı yoksa bir çeşit dolandırıcılık mı olduğunu merak etmeye başladım.

Ertesi gün New York'tayken bu röportajı Red Hat'te eşimle tartıştım. Ona konuşmanın çok ilginç olduğunu söyledim ama bu insanların beni işe alma konusunda ciddi olup olmadıklarından emin değildim: belki de sadece bedava yiyecek ve benzin istiyorlardı? Bugünkü toplantıyı hatırladığımda, Shulick ve Cunningham'ın açık sözlü insanlar olduğunu ve bana birlikte kahve içebilecekleri, öğle yemeği yiyebilecekleri veya benzin doldurabilecekleri herhangi bir kişi gibi davrandıklarını anlıyorum. Evet, ikisinin de parasız kalması komik ve hatta komik. Ama onlar için mesele para değildi. Açık kaynak dünyası gibi onlar da kırmızı halı sermeye ya da başkalarını her şeyin mükemmel olduğuna ikna etmeye çalışmaya inanmıyorlardı. Sadece beni daha iyi tanımaya çalışıyorlardı, farklılıklarımızı etkilemeye ya da vurgulamaya çalışmıyorlardı. Kim olduğumu bilmek istediler.

Red Hat'teki ilk röportajım bana buradaki işin farklı olduğunu açıkça gösterdi. Bu şirketin, en azından diğer şirketlerin çoğunda geleneksel olan biçimde, geleneksel bir hiyerarşisi ve yöneticilere yönelik özel bir muamelesi yoktu. Zamanla Red Hat'in meritokrasi ilkesine inandığını da öğrendim: ister üst düzey yönetimden, ister bir yaz stajyerinden gelsin, her zaman en iyi fikri uygulamaya değer. Başka bir deyişle, Red Hat'teki ilk deneyimim bana liderliğin geleceğinin neye benzediğini gösterdi."

Meritokrasiyi geliştirmek için ipuçları

Meritokrasi açık kaynak topluluğunun temel değeridir. Bizim için piramidin hangi seviyesini işgal ettiğiniz önemli değil, asıl önemli olan fikirlerinizin ne kadar iyi olduğudur. İşte Jim'in önerdiği şey:

  • Asla “Patronun istediği bu” demeyin ve hiyerarşiye güvenmeyin. Bu size kısa vadede yardımcı olabilir ancak meritokrasiyi bu şekilde inşa edemezsiniz.
  • Başarıları ve önemli katkıları kamuoyu önünde takdir edin. Bu, tüm ekibin kopyalandığı basit bir teşekkür e-postası olabilir.
  • Şunu düşünün: Otoriteniz hiyerarşideki konumunuzun (veya ayrıcalıklı bilgilere erişiminizin) bir işlevi mi, yoksa kazandığınız saygının bir sonucu mu? İlki ise ikincisi üzerinde çalışmaya başlayın.
  • Geri bildirim isteyin ve belirli bir konu hakkında fikir toplayın. Her şeye tepki vermeli, yalnızca en iyiyi test etmelisiniz. Ancak sadece en iyi fikirleri alıp onlarla ilerlemeyin; meritokrasi ruhunu güçlendirmek için her fırsatı değerlendirin ve bunu hak eden herkese itibar edin.
  • Ekibinizin örnek bir üyesini, her zamanki çalışma alanıyla ilgili olmasa bile ilginç bir görev teklif ederek takdir edin.

Bırakın rock yıldızlarınız tutkularını takip etsin

Coşku ve katılım, açık bir organizasyonda çok önemli iki kelimedir. Kitapta sürekli tekrarlanıyorlar. Ancak tutkulu, yaratıcı insanların çok çalışmasını sağlayamazsınız, değil mi? Aksi takdirde yeteneklerinin sunduğu her şeyi alamazsınız. Red Hat'te kendi projelerinin önündeki engeller mümkün olduğunca ortadan kaldırılıyor:

“İnovasyonu teşvik etmek için şirketler birçok şeyi dener. Google'ın yaklaşımı ilginç. Google'ın her evde tanındığı 2004 yılından bu yana, İnternet sektöründeki yöneticiler ve ideologlar, etkileyici başarısını tekrarlamak için şirketin ana sırrını çözmeye çalıştılar. En ünlü ama şu anda kapalı olan programlardan biri, tüm Google çalışanlarından zamanlarının yüzde 20'sini neredeyse istedikleri her şeyi yaparak geçirmelerinin istenmesiydi. Buradaki fikir, çalışanların iş dışında tutkulu oldukları kendi projelerini ve fikirlerini takip etmeleri durumunda yenilik yapmaya başlayacaklarıydı. Başarılı üçüncü taraf projeleri bu şekilde ortaya çıktı: GoogleSuggest, İçerik için AdSense ve Orkut; hepsi bu yüzde 20'lik deneyden geldi; etkileyici bir liste! […]

Red Hat'te daha az resmi bir yaklaşım benimsiyoruz. Her çalışanımızın “inovasyona” ne kadar zaman ayırması gerektiğine dair belirlenmiş bir politikamız yok. İnsanlara kendilerini eğitmeleri için özel zaman vermek yerine, çalışanların zamanlarını yeni şeyler öğrenerek geçirme hakkını kazanmalarını sağlıyoruz. Dürüst olmak gerekirse, pek çok insanın bu kadar az zamanı var ama iş gününün neredeyse tamamını inovasyona ayırabilenler de var.

En tipik durum şuna benzer: Birisi bir yan proje üzerinde çalışır (eğer bunun önemini yöneticilere - doğrudan işyerinde veya çalışma saatleri dışında - kendi inisiyatifiyle açıklarsa) ve daha sonra bu çalışma tüm işleri kapsayabilir. şimdiki saatleri.”

Beyin fırtınasından daha fazlası

“Lirik bir ara söz. Alex Fakeney Osborne, bugün onun devamı olan sinektik yöntemi olan beyin fırtınası yönteminin mucididir. Bu fikrin İkinci Dünya Savaşı sırasında, Osborne'un bir Alman denizaltısının torpido saldırısı tehlikesiyle karşı karşıya olan bir Amerikan kargo konvoyunun gemilerinden birine komuta ettiği sırada ortaya çıkması ilginçtir. Sonra kaptan, Orta Çağ korsanlarının başvurduğu tekniği hatırladı: Mürettebatın başı dertteyse, tüm denizciler sırayla güvertede toplanır ve sorunu çözmenin bir yolunu önerirlerdi. İlk bakışta saçma olanlar da dahil olmak üzere pek çok fikir vardı: örneğin, tüm ekiple bir torpido patlatma fikri. Ancak her gemide bulunan gemi pompasının jeti ile bir torpidoyu yavaşlatmak, hatta rotasını değiştirmek oldukça mümkündür. Sonuç olarak, Osborne bir buluşun patentini bile aldı: Geminin yan tarafına, yan boyunca su akışını yönlendiren ek bir pervane monte edildi ve torpido yan yana kayıyor.

Jim'imiz açık bir organizasyonda çalışmanın o kadar kolay olmadığını sürekli tekrarlıyor. Hiç kimse fikrini savunma ihtiyacından kurtulamadığı için yönetim bile bunu anlıyor. Ancak mükemmel sonuçlar elde etmek için gereken yaklaşım tam olarak budur:

“Çevrimiçi [açık kaynak] forumlar ve sohbet odaları genellikle bir yazılım hatasının en iyi şekilde nasıl düzeltileceğinden bir sonraki güncellemede hangi yeni özelliklerin dikkate alınması gerektiğine kadar her şey hakkında canlı ve bazen sert tartışmalarla doludur. Kural olarak, bu, yeni fikirlerin öne sürüldüğü ve biriktirildiği tartışmaların ilk aşamasıdır, ancak her zaman bir sonraki tur olan eleştirel analiz vardır. Bu tartışmalara herkes katılabilse de kişinin kendi konumunu tüm gücüyle savunmaya hazır olması gerekir. Popüler olmayan fikirler en iyi ihtimalle reddedilecek, en kötü ihtimalle alay konusu olacaktır.

Linux işletim sisteminin yaratıcısı Linus Torvalds bile kodda önerilen değişikliklere katılmadığını ifade ediyor. Bir gün, Red Hat'in önde gelen geliştiricilerinden biri olan Linus ve David Howells, Red Hat'in talep ettiği ve müşterilerimize güvenlik sağlamaya yardımcı olacak bir kod değişikliğinin yararları hakkında hararetli bir tartışmaya girdiler. Howells'in talebine yanıt olarak Torvalds şunu yazdı: “Açıkçası bu [basılamaz kelime] aptalca. Her şey bu aptal arayüzlerin etrafında dönüyor gibi görünüyor ve tamamen aptalca sebeplerden dolayı. Bunu neden yapmalıyız? Artık mevcut X.509 ayrıştırıcısını sevmiyorum. Aptalca karmaşık arayüzler yaratılıyor ve şimdi bunlardan 11 tane olacak: Linus 9.”

Teknik detayları bir kenara bırakan Torvalds, bir sonraki mesajında ​​da aynı ruhla ve alıntı yapmaya cesaret edemeyeceğim şekilde yazmaya devam etti. Bu tartışma o kadar gürültülü oldu ki The Wall Street Journal'ın sayfalarına bile yansıdı. […]

Bu tartışma, özel mülk, özgür olmayan yazılım üreten şirketlerin çoğunun, hangi yeni özellikler veya değişiklikler üzerinde çalışacakları konusunda açık bir tartışmaya sahip olmadıklarını göstermektedir. Ürün hazır olduğunda şirket ürünü müşterilere gönderiyor ve yoluna devam ediyor. Aynı zamanda, Linux söz konusu olduğunda, hangi değişikliklerin gerekli olduğu ve en önemlisi bunların neden gerekli olduğu konusundaki tartışmalar azalmıyor. Bu da elbette tüm süreci çok daha karmaşık ve zaman alıcı hale getiriyor."

Erken yayın, sık yayın

Geleceği tahmin edemeyiz, bu yüzden denemek zorundayız:

“Erken lansman, sık güncelleme” ilkesiyle çalışıyoruz. Herhangi bir yazılım projesinin temel sorunu, kaynak kodundaki hata veya hata riskidir. Açıkçası, yazılımın bir sürümünde (versiyonunda) ne kadar çok değişiklik ve güncelleme toplanırsa, bu sürümde hataların olma olasılığı da o kadar yüksek olur. Açık kaynak yazılım geliştiricileri, yazılım sürümlerini hızlı ve sık bir şekilde yayınlayarak herhangi bir programda ciddi sorun yaşama riskinin azaldığını fark ettiler; sonuçta, tüm güncellemeleri bir kerede piyasaya sunmuyoruz, her sürüm için birer birer getiriyoruz. Zamanla bu yaklaşımın yalnızca hataları azaltmakla kalmayıp aynı zamanda daha ilginç çözümlere de yol açtığını fark ettik. Sürekli olarak küçük iyileştirmeler yapmanın uzun vadede daha fazla yenilik yarattığı ortaya çıktı. Belki de burada şaşırtıcı bir şey yoktur. Kaizen a veya yalın b gibi modern üretim süreçlerinin temel ilkelerinden biri, küçük ve artan değişikliklere ve güncellemelere odaklanmaktır.

[…] Üzerinde çalıştığımız şeylerin çoğu başarılı olmayabilir. Ancak neyin işe yarayıp neyin yaramadığını merak ederek çok fazla zaman harcamak yerine küçük deneyler yapmayı tercih ediyoruz. En popüler fikirler sizi başarıya götürecek, işe yaramayanlar ise kendiliğinden yok olup gidecektir. Bu şekilde şirketi fazla riske sokmadan tek bir şey yerine birçok şeyi deneyebiliriz.

Bu, kaynakları tahsis etmenin rasyonel bir yoludur. Örneğin, insanlar bana sıklıkla hangi açık kaynak projelerinin ticarileştirileceğini nasıl seçeceğimizi soruyor. Bazen projeler başlatırken çoğu zaman mevcut projelere atlıyoruz. Küçük bir mühendis grubu (bazen tek bir kişi) açık kaynak topluluğunun projelerinden birine katkıda bulunmaya başlar. Proje başarılı olursa ve müşterilerimiz arasında talep görürse, üzerinde daha fazla zaman ve çaba harcamaya başlarız. Aksi takdirde geliştiriciler yeni bir projeye geçer. Teklifi ticarileştirmeye karar verdiğimizde proje o kadar büyümüş olabilir ki çözümü belli olur. Yazılım dışı olanlar da dahil olmak üzere çeşitli projeler doğal olarak Red Hat'te ortaya çıkıyor, ta ki artık birisinin bu proje üzerinde tam zamanlı çalışması gerektiği herkes için netleşene kadar."

İşte kitaptan bir alıntı daha:

“Bu rolü yerine getirmek için yarının liderlerinin geleneksel organizasyonlarda gözden kaçırılan özelliklere sahip olması gerektiğini fark ettim. Açık bir organizasyonu etkili bir şekilde yönetmek için bir liderin aşağıdaki niteliklere sahip olması gerekir.

  • Kişisel güç ve güven. Sıradan liderler başarıya ulaşmak için konumsal gücü - konumlarını - kullanırlar. Ancak meritokraside liderlerin saygı kazanması gerekir. Ve bu ancak tüm cevaplara sahip olmadıklarını kabul etmekten korkmamaları durumunda mümkündür. Ekipleriyle en iyi çözümleri bulmak için sorunları tartışmaya ve hızlı karar vermeye istekli olmaları gerekir.
  • Sabır. Medya nadiren bir liderin ne kadar "sabırlı" olduğuna dair hikayeler anlatır. Ama gerçekten sabırlı olması gerekiyor. Ekibinizden en iyi çabayı ve sonuçları almak için çalıştığınızda, saatlerce konuştuğunuzda ve doğru yapılana kadar işleri defalarca tekrarladığınızda sabırlı olmanız gerekir.
  • Yüksek EQ (duygusal zeka). Çoğu zaman liderlerin zekasını IQ'larına odaklanarak teşvik ediyoruz, oysa gerçekte dikkate alınması gereken şey duygusal zeka bölümü veya EQ puanıdır. Eğer o insanlarla çalışamıyorsanız, diğerlerinin en akıllısı olmanız yeterli değildir. Red Hat gibi işine bağlı çalışanlardan oluşan topluluklarla çalıştığınızda ve etrafınızdaki kimseye emir verme yeteneğiniz olmadığında, dinleme, analitik düşünme ve olayları kişisel algılamama yeteneğiniz inanılmaz derecede değerli hale gelir.
  • Farklı zihniyet. Geleneksel organizasyonlardan gelen liderler, her eylemin yeterli bir karşılık alması gerektiğini öngören quid pro quo (Latince "quid pro quo") ruhuyla yetiştirilmişlerdi. Ancak belirli bir topluluk oluşturmaya yatırım yapmak istediğinizde uzun vadeli düşünmeniz gerekir. Bu, herhangi bir yanlış adımın dengesizlik yaratabileceği ve hemen fark edemeyeceğiniz uzun vadeli kayıplara yol açabileceği, hassas bir şekilde dengelenmiş bir ekosistem oluşturmaya çalışmak gibidir. Liderlerin, ne pahasına olursa olsun bugün sonuç elde etmelerini gerektiren zihniyetten kurtulmaları ve geleceğe yatırım yaparak daha fazla fayda sağlayacak şekilde iş yapmaya başlamaları gerekiyor.”

Ve neden önemlidir?

Red Hat, geleneksel hiyerarşik organizasyondan çok farklı ilkelere göre yaşıyor ve faaliyet gösteriyor. Ve işe yarıyor, bizi ticari açıdan başarılı ve insani olarak mutlu ediyor. Bu kitabı, Rus şirketleri arasında, farklı yaşamak isteyen ve yaşayabilen insanlar arasında açık örgütlenme ilkelerini yayma umuduyla tercüme ettik.

okumak, dene!

Kaynak: habr.com

Yorum ekle