- Farklı alanlardan uzmanların bir araya geldiği bir ortamda lider, teknik ayrıntıları bilmekten çok sorunları birbirine bağlama ve çözüm yönünü belirleme rolünü üstlenir
- Liderlikte basit teknik bilgiden ziyade çeviri becerisi ve sosyal yetkinlikler önemlidir; çatışma anlarını koordine etmeli ve ortak hedefi vurgulamalıdır
- Önemli olan herkesin derin uzmanlığından çok gerçek sorunun tanımı ve çözüm yönünü netleştirmek, tartışmaların kullanıcı ihtiyaçları ve sonuçlara bağlanmasını sağlamaktır
- Etkili lider, her şeyi biliyormuş gibi davranmak yerine “Bilmiyorum” diyebilme cesaretine sahiptir ve uzmanların inisiyatif alarak katkı sunabileceği bir alan yaratır
- Liderin gerçek değeri bakış açılarını çevirmek, probleme bağlam kazandırmak ve iş birliği alanı oluşturmakta yatar; bu da en iyi sonuçları ortaya çıkaran temel unsurdur
Son dönemde fark ettiğim şey
- Bir toplantı odasında farklı alanlardan uzman geliştiriciler ve ürün ekibiyle birlikte çalışıyorum
- Belirli bir teknolojide en üst düzey uzmanlığa sahip değilim ama lead developer rolünü üstleniyorum
- Uzmanlar arasında lider olarak benim rolüm tüm cevapları bilmek değil, cevapları bulup birbirine bağlama becerisine sahip olmak
Technical Leadership
- Lider, teknik bilgi derinliğinden çok ekipler arası iletişimi mümkün kılan etkili bir çevirmen rolünü oynar
- Backend geliştirme ekibinin takvim açıklamalarını ya da ürün ekibinin gereksinimlerini her bir tarafın bakış açısından tercüme ederek ekip iş birliğini sağlar
Leading is a Social Skill
- Yalnızca teknik güvenilirlik yeterli değildir; gerçek üretkenliği yaratan şey sosyal becerilerdir
- Geliştiriciler arasındaki tartışmaları okuyup ne zaman arabuluculuk yapılacağına ya da ilerletileceğine karar verebilme yeteneği gerekir
- Etkili iletişim yalnızca dokümanlarla değil, aktif diyalog yoluyla kurulur
Leading is Remembering the Goal
- Uzmanlar ayrıntılı teknik konulara daha kolay gömülür, ancak lider genel hedefe odaklanmalıdır
- Teknik tartışmanın kendisine değil, kullanıcı deneyiminin özündeki probleme ve iş hedeflerine netlik kazandırmak önemlidir
- Problemin özü açık şekilde tanımlanmazsa ekip üyeleri kendi analiz biçimlerine göre hareket edip asıl meseleyi kaçırabilir
- Liderin sorumluluğu, ekibin problemi doğru anlamasını ve aynı hedefe bakmasını sağlayacak çeviriyi yapmaktır
Leading is Saying "I Don't Know"
- Tüm cevapları biliyormuş gibi davranmak yerine "Bilmiyorum, birlikte öğrenelim" diyebilmek güven ve açık bir kültür yaratır
- Bu yaklaşım uzmanlara soru sorma ve tartışma alanı tanır, herkesin kendi yetkinliğini ortaya koymasına fırsat verir
- Lider, konu uzmanlarına karar hakkı ve söz hakkı verirken tartışmanın üretken yönünü gösterir
- İki uzman uygulama yöntemi konusunda anlaşamadığında liderin rolü "doğru cevabı" seçmek değil, trade-off'lar ve kullanıcı etkisi açısından bir çerçeve sunmaktır
The Translation Challenge
- Lider; geliştirici dili, ürün dili ve yönetici dilini duruma göre çevirebilmelidir
- Geliştiriciler: "Kimlik doğrulama servisinde uygun bir circuit breaker yoksa yük altında zincirleme arızalar oluşabilir"
- Ürün ekibi: "Giriş sistemiyle ilgili bir sorun tüm uygulamayı etkileyebilir; bu yüzden koruyucu bir mekanizma eklememiz gerekiyor ve takvim bir hafta uzuyor"
- Yöneticiler: "Bu sprint'te sistem kararlılığını önceliklendirerek iş riskini azaltıyoruz"
- Uzmanların diğer departmanların dilini de öğrenmesini beklemek gerekmez; lider bu boşluğu kapatan köprü olmalıdır
Beyond "Because, that's why!"
- "Ben liderim, o yüzden böyle yapıyoruz" yaklaşımı güveni ve iş birliği kültürünü zedeler, ekip verimliliğini düşürür
- Ekibe yetişkin bireyler gibi davranmak ve kararların nedenini ile bağlamını net biçimde açıklamak önemlidir
- "Daha temkinli bir yaklaşım seçmemizin nedeni, hata durumunda maliyetin yüksek olması; sonrasında bunu yinelemeli olarak iyileştirebiliriz"
- "Ek iş gibi gelebilir ama mimari hedeflerle uyumlu olduğu için sonraki özellik geliştirmelerine yardımcı olacak"
- "Bu en zarif çözüm olmayabilir ama verilen takvim içinde bunu güvenle yayına alabiliriz"
- Uzmanlık gösterisini bir kenara bıraktıkça gerçek liderlik sergilemek mümkün olur
Liderin ekibe sunması gereken değer
- Net problem tanımı sağlamak
- Karar bağlamını yeterince açıklamak
- Ekipler arasındaki bakış açısı farklarını çevirmek
- Gereksiz karmaşıklıktan korumak
- En iyi sonucu çıkaracak ortamı oluşturmak
Sonuç
- Uzmanlardan oluşan bir organizasyonda teknik liderlik, komuta ve kontrolden çok bağ kurma ve bağlam sunma üzerine kuruludur
- Lider, enstrümanı bizzat çalan kişi değil; orkestranın tek bir eseri tamamlamasına yardımcı olan şef gibidir
- Bu, odadaki en zeki kişi olmaya çalışmaktan çok daha ilginç bir meydan okumadır
4 yorum
Tersinden düşününce, uzmanların olmadığı bir ortamda bizzat uzman olmak zorunda kalındığını düşünüyorum.
Elbette teknik liderliğin dışında başka türden liderlikler de yapmak istediğim oluyor, ancak bilgiyi iyi paylaşmayan ekip üyeleriyle karşılaşınca bunu bile yapmak zorlaşıyor; bu yüzden durumun koşullara göre değiştiğini düşünüyorum.
Harika bir bakış açısı.
Böyle çalışmalıyım
Hacker News yorumu
Bir takım lideri olarak, mümkün olduğunca “Ben liderim ve buna böyle karar verdim” tarzı kararlar almaktan kaçınırım; ama gerekirse bunu tereddüt etmeden yapabilmek gerektiğini de vurguluyorum. Herkesin görüşünü dinleyip dikkatle karar vermek için zaman ayırırım, ancak takım önemsiz ayrıntılar üzerinde sonsuz tartışmalara saplandığında, lider olarak düzeni sağlamak gerektiğini fark ettim. Steve Jobs’un “Herkesi mutlu etmek istiyorsan lider olma, dondurma sat” dediği sözü sık sık düşünürüm. Böyle durumlar geçtikten sonra güveni yeniden inşa etmek ve neden o şekilde davranmak zorunda kaldığını takım arkadaşlarına açıklamak çok önemlidir
Ben de bu dersi zor yoldan öğrendim. İlk kez yönetici olduğumda, her zaman herkesin uzlaşmasını sağlayabileceğimi ve takımın doğal olarak ortak bir çizgide birleşeceğini safça düşünüyordum. Harika bir takımda bu başta işe yaradı, ama sonra sadece başka ekiplerin 25 yıl önceki yöntemlerinde ısrar eden mühendislerle çalışmaya başlayınca, ortak zemin oluşmasını bekleyerek çok fazla zaman kaybettim. Sonunda, ekip üyeleri görüşlerini yeterince ortaya koyduktan sonra yönü belirleyip kararı vermesi gereken anın lidere geldiğini fark ettim
Benim deneyimimde, F50’de birkaç yıl çalışırken benzer bir durum yaşadım. Üç kilit kişinin bulunduğu bir alanda, A seçeneği dışarıdan iyi görünse de gerçekte ciddi sorunları olduğunu sadece biz biliyorduk; bunu anlatsak da ekibi ikna edemedik, bu yüzden oylamayı fiilen geçersiz sayıp yöneticimizle görüştükten sonra doğru kararı alabildik. Bu süreçte, sonucu doğrudan üstlenecek kişinin istediği yön (C seçeneği) yerine çoğunluğun görüşüne (A seçeneği) uyulduğunda projede sürekli sorun ve gecikme yaşandığını derinden anladım. Buradaki önemli nokta şu: sorumluluğu ve sonuçları doğrudan taşıyan kişiler, popüler oylama yerine bir tür "veto hakkına" sahip olmalı ki proje ilerleyebilsin. Büyük projelerde farklı alanlar için birden çok lider karar almalı ve yalnızca tıkanma olduğunda üst yönetici net karar vermelidir. Lider karar vermekten kaçındığında herkes sadece memnuniyetsizliğini dile getiriyor ve bu da ekip moralini ciddi biçimde düşürüyor; bunu çok can sıkıcı şekilde yaşadım
Steve Jobs’un ekibi bir odaya kapatıp ortak bir vizyon bulana kadar tartıştırdığı hikâye de aklıma geliyor. Herkesi aynı yöne çekmek zor, ama bu başarılmazsa uygulama gücü ciddi biçimde düşüyor. Ayrıca ekip üyelerinin görüşlerini yok sayarsanız, onlar da kendilerini yok sayılmış hisseder; sonuç önemli olsa bile bu, uzun vadede sürdürülebilir bir yöntem değil
“Herkesin sesini duymak” ile “herkese veto hakkı vermek” tamamen farklı şeyler. Lider olarak tıkanıklığı kırmak temel bir görev diye düşünüyorum. Elbette her konuda lider karar vermek zorundaysa, bu ya bir yönetim sorununun, ya motivasyon eksikliğinin, ya da takımın stratejiyi anlamadığının işaretidir
Benim tercih ettiğim yaklaşım, “Bu iş doğrudan senin sorumluluğunda olsaydı kararın ne olurdu, bana söyle” demek. Liderin görevi her zaman kararı bizzat vermek değil, mutlaka bir karar çıkmasını sağlamaktır
Bu alanda biraz uzmanlığım olduğunu düşünüyorum. Geçmişte daha önce üç kez başarısız olmuş bir projenin liderliğine getirildim ve her ekipten en iyi altı mühendisle çalıştım. Herkesin güçlü görüşleri ve bunların sağlam gerekçeleri vardı; ama “Hata yapan düşmanı rahatsız etme” sözündeki gibi, “Arkadaşın iyi bir şey yapıyorsa onu engelleme” tavrını benimsemeye çalıştım. Yaklaşımım şuydu: “Senin sorumluluğunda olmayan bir parçaysa, gidip iyi yapabileceğin başka bir şey üret.” Rolleri doğal biçimde dağıttık, birbirimizi yumuşak şekilde etkiledik ve daha az önemli kısımlarda mükemmeliyet aramadan esnek davrandık. Sonuç başarılı oldu ve birçok yetenekli insanın bir araya geldiği bir ekipte, birbirinden öğrenen ve sadece gerçekten tartışılması gereken noktalara odaklanan bir yapı kurmuş olmaktan büyük gurur duyuyorum
Yaşadığınız deneyimin, Servant Leadership(ilgili wiki bağlantısı) denen liderlik anlayışına benzediğini düşünüyorum. Benim de sevdiğim liderlik yaklaşımı bu
Üstün mühendislerin, aşırı müdahale olmadan kendi fikirlerini sahiplenip hayata geçirmelerine alan açmak için lider olarak gerçek güvene, özdenetime ve özgüvene ihtiyaç olduğunu düşünüyorum
Ürün ekibi her “basit” özellik istediğinde aklıma bunun için en az 3 takım gerekeceği ve her birinin mikroservislerini güncellemek zorunda kalacağımız geliyor. Bu yüzden bazen modern web sistemlerinden gerçekten nefret ediyorum
Buradaki sorun bence modern web’in kendisinden çok, tek bir “basit” özelliğin bağımlılıklarının 3 ayrı mikroservise dağılmış olduğu bir mimari. Sonuçta asıl neden daha çok kötü sistem tasarımı
Peki o zaman başka ne tür alternatifler var, merak ediyorum
Benim deneyimime göre, “Ben liderim” demek özgüven eksikliği gibi görünebildiği için bundan kaçınmak daha iyi; bunun yerine tüm bilgileri toplayıp karar verdikten sonra, “Tamam, şimdi bunu böyle yapalım” ya da “Bunu bu şekilde yapmanızı istiyorum” diyebilmek gerekir
Sorunun özü yanlış anlaşılma değil, karşılıklı güven eksikliği. Bir ekip bir işin 2 hafta süreceğini söylediğinde, diğer ekip bunun bir günde yapılabileceğini düşünüp buna güvenmiyor. Yeterli güven olsa, karşı tarafın o konuda daha uzman olduğunu kabul etmek mümkün olurdu; ama gerçekte insanlar, yapılan süre tahmininin işin gerçek yükünü değil, biraz pay bırakma hesabını yansıttığından şüpheleniyor. Böyle durumlarda yeterli açıklama ve dayanak paylaşmak güven oluşturmaya yardımcı olur
Yaklaşık bir yıl önce lead developer olarak terfi ettim. Rolümün ve sorumluluklarımın ne olduğu konusunda kafam karışıktı, ama ana yazıda anlatılanlara benzer şekilde düşünerek çalıştığımı görünce içim rahatladı. Birkaç gün önce “geliştirici olmayan birinin bakış açısından tutorial nasıl okunur” üzerine bir yazıya rastlayıp çok bağ kurmuştum; sanırım doğru yönde ilerliyorum
Ben de yazılıma komşu ürün geliştirme ekiplerinde, liderin baskıcı biçimde yönettiği üç örnek gördüm ve her seferinde sonuç kötüydü. Takım liderliğini birkaç kez kendim yapınca, benim rolümün bir “komutan” değil, bir “merkez ve arabulucu” olmak olduğunu fark ettim. Ekip üyeleri arasında çatışma olduğunda gerilimi azaltmak, soru olduğunda kaygıyı düşürmek, bir fikir çıktığında uygulanabilirliğini ve değerini değerlendirmek, kaynak gerektiğinde de kimin yardımcı olabileceğini bulup bağlantı kurmak benim işim. Bir sorun çıktığında sorumluluğu üstlenir ve çözüm için ekibi motive ederim. Bütün bunları öğrenmem 10 yıldan fazla sürdü. En iyi kişi değilim ve adım da çoğu insan tarafından bilinmiyor, ama takımın bir “üyesi” olarak çalıştığımda sonuçlar daha iyi oluyor ve yetenek kaybı azalıyor. Bir lider olarak “Ben de tam bilmiyorum ama gelin cevabı birlikte bulalım” diyebilmenin gerçekten önemli olduğunu düşünüyorum. Bu, uzman insanlara belirsizliğe alan tanıyor, savunmaya geçmelerini engelliyor ve yalnız olmadıkları hissini veriyor. Geçmişte liderlerinden dışlanmış ya da kendini değiştirilebilir bir parça gibi hissetmiş olanların teselli bulmasını isterim; bir lider ekibini uzun süre iyi yönetmek istiyorsa, insanları makine gibi değil, birbirine özen gösterilmesi gereken varlıklar olarak görmesi gerekir
Yazarın metnin sesli kaydını kendisinin yapmış olmasına hayran kaldım
“It's because that's why” ifadesini sevdiğini söyleyerek, bu alana ilgi duyanlara Vanessa Van Edwards’ın kitaplarının duruma uygun sıcaklık ve uzmanlık sinyalleri vermeyi öğrenmek açısından çok yardımcı olduğunu öneriyor. Tek bir kişi tüm cevapları veremez ama kendisinin pek çok olumlu deneyimi olmuş
Karar verme konusunda, işin “bir kararın mutlaka çıkmasını sağlamak”tan hem daha fazlası hem de daha azı olduğunu düşünüyorum. Birincisi, mümkünse kararı başkasının doğrudan vermesini sağlamayı öneririm. Apple döneminde Jean-Louis Gassee’nin, önüne anlaşmazlıkla gelen yöneticilere ikisinin de hoşlanmayacağı bir karar verdiği ve bunun üzerine onların gidip kendi aralarında uzlaşabilecekleri bir alternatif bulup geri geldikleri yönünde bir anekdot vardır. İkincisi, tüm paydaşların gerçekten kararı benimsemesini sağlamak gerekir ve kişi önce bunu kendisi yapmalıdır. Bunun, rüzgâra göre yön değiştiren yöneticiler için çok zor olduğunu da eklerim. Hukuk öğrencileri her zaman dikkatli ve analitik düşünür, ama avukatlar kararlı biçimde savunmak zorundadır; herkesi ikna etmeye dönük bir tavır geliştirmek gerekir. Elbette her zaman ideal uzlaşma olmaz; bu yüzden müşteri ya da sonuç hedefi gibi somut bir referans noktası belirlemek, kararı ilerletmeye ve uygulamayı sağlamaya yardımcı olabilir