- Apple’da mühendislik lideri Michael Lopp, ürünleri hızla geliştirmenin mümkün olduğu bu çağda insan odaklı operasyon ve muhakemenin daha da önemli olduğunu vurguluyor
- “Kararı kim veriyor ve bu karar nasıl uygulanıyor?” sorusu, mühendisliğin gerçek özünü oluşturuyor
- Kod yazma becerisinden çok, insan odaklı organizasyon ve liderlik kurumun performansını belirliyor
- Borland, Netscape, Palantir, Slack gibi farklı ortamlarda edindiği deneyimlere dayanarak organizasyon yapısı, iş birliği kültürü ve liderliğin temel yetkinliklerini somut biçimde ortaya koyuyor
- Teknik liderlikten çok organizasyonun işletimi, insanlar arası iş birliği ve insanı anlama konularına odaklanıyor
- Bu röportaj, basit bir teknik tartışmadan ziyade sürdürülebilir ve etkili mühendislik organizasyonları tasarlamaya yoğunlaşıyor; ürün ekipleriyle ilişki, insan odaklı yetkinlikler ve iyi liderin nitelikleri gibi başlıklarda kuruculara ve teknik liderlere pratik öneriler sunuyor
Mühendislik organizasyonunun yapısı nasıl tasarlanmalı?
- Farklı sektörlerde de ortak başarı unsurları olarak mühendisliğe duyulan güven, hızlı büyüme ve akıllı yetenekleri işe alma öne çıkıyor
- Buna dayanarak başarılı bir mühendislik organizasyonu tasarlamak için üç pratik öneri sunuyor
Tip #1: “Wolf Time”ı teşvik edin
- Mühendislerin zamanını %71 gerçek iş / %29 serbest üretim zamanı olarak bölün
- Bu %29’luk bölüm, “ölçülemeyen ve açıklanması gerekmeyen zaman” olarak; yaratıcılık ve gönüllü inisiyatifin filizlendiği alan
- Palantir’de bunu resmileştirme girişimi başarısız oldu → biçimselleştirmektense gayriresmî teşvik ve iletişim daha etkili
- Örnek: Her cuma gayriresmî fikir paylaşım zamanı önerisi
> “Ekip üyeleri bu zamanın gerçekten tanındığını fark etmezse, toplantı aralarında bunu gizlice yaparlar ve hiçbir şey büyümez”
Tip #2: Tartışma ne kadar düzenliyse o kadar iyidir
- Harika ürünler mühendislik, tasarım ve ürün olmak üzere üç alanın iş birliğinden doğar
- Bu iş birliği çoğu zaman çatışma içerir, ancak tam da bu tartışma ürün kalitesini yükselten temel unsurdur
- “Bu bir tasarım sorunu mu, ürün sorunu mu, yoksa özelliğin anlaşılmasıyla ilgili bir sorun mu?” gibi konularda ekip içinde canlı tartışmalar olmalı
- Liderler, fikirlerin yalnızca aşağıdan yukarıya değil, yukarıdan aşağıya doğru da sorgulanmasını teşvik etmeli
- Kurucular ile çalışanlar arasındaki tartışmaların şirketin yönünü değiştirdiği anlar sık sık yaşanır
Tip #3: Ölçeklenebilir bir operasyon sistemi kurun
- İyi muhakeme + operasyonel yetkinlik, ölçeklenebilir ürünlerin temelidir
- Muhakeme, sadece sonuca ulaşmak değil, “neden o kararı verdiğini” açıklayabilme becerisidir
- Sorumluluk (Accountability), “anlatılabilecek bir hikâyeye” sahip olmak anlamına gelir
- Az sayıdaki kişinin muhakemesinin tüm sisteme yayılabilmesi için net süreçler gerekir
- Sadece işe alım sürecine bakmak bile operasyon kalitesini gösterir (yanıt hızı, takvimin netliği vb.)
- Startup olmayı bahane edip süreçleri görmezden gelmeyin → bir şirket kurmak, aynı zamanda bir operasyon kurmaktır
Mühendislik ve ürün ekipleri arasındaki ilişki nasıl güçlendirilir?
- Ürün ekibi ile mühendislik ekibi arasındaki gerilim ve yanlış anlama eski bir hikâye olsa da,
yüksek kaliteli bir ürünü ölçeklenebilir şekilde inşa etmek için bu ilişkiyi iyi biçimde işlemek şarttır
- Kötü bir PM, mühendislerin ürünü sahiplenmeden yalnızca takip etmesine neden olur,
- İyi bir PM ise mühendislerin “bunu neden yaptıklarını” tam olarak anlamasına yardımcı olur
- Lopp, mühendisi “nasıl (how)” insanı, PM’i ise “neden (why)” insanı olarak tanımlıyor
- Ürün ekibi müşterinin hikâyesini aktarmalı, nasıl inşa edileceğini ise mühendislere ve tasarımcılara bırakmalı
- Kilit nokta, “neden”i paylaşmaktır
> “Bu özelliği neden yapıyoruz?” sorusunu PM’e değil, doğrudan mühendise sorun
- Cevap “PM öyle istedi” ise bu öfkelendirici bir durumdur
- Asıl sorun, ürün ekibinin muhakemesinin yanlış olması değil; mühendisin bağlamı anlamamış olmasıdır
> "Mühendis, ürünü elleriyle yapan kişidir. ‘Bunu neden yaptığını’ anlamadan çalışan mühendislerin olduğu bir organizasyon başarısız olur"
- Slack’te neden engelleme özelliği olmadığı sorulduğunda Stewart, “bilginin herkes tarafından görülebilmesi önemlidir” şeklindeki felsefeyi açıkça anlatıyor
- Bunun bir özellik değil, vizyon meselesi olduğu bakış açısı paylaşılıyor
- İyi bir ürün yöneticisi, her bir özelliği veya fikri ürünün genel vizyonu içinde bağlama oturtarak aktarabilmelidir
- Bu da herkesin odaklanması gereken ‘why’ın bir parçasıdır
Harika bir lider nasıl biri olmalı?
- Gerçek mühendislik liderliği, yalnızca teknik yetkinliğin ötesine geçer
- “Sonuçta liderlik, insanlarla çalışma sanatıdır”
-
Liderlik özelliği #1: Esneklik (Malleability) sahibidir
- Lider, farklı karakterde insanlarla çalışır ve buna göre kendi tarzını ayarlayabilmelidir
- Pinterest ve Slack’te ekipleri tamamen farklı şekillerde yönettiğine dair kendi deneyimini örnek vererek bunu vurguluyor
- Yeni yöneticilere her zaman aynı soruyu soruyor: “Geri bildirim aldıktan sonra neyi değiştirdin?”
- Ekip yapısı da sabit ölçütlere göre değil, birlikte çalışırken ortaya çıkan güçlü ve zayıf yönlere göre yeniden düzenlenmeli
- Bunun için her 6 ayda bir yeniden organizasyon yapıyor
-
Liderlik özelliği #2: Hikâye anlatma becerisi yüksektir
- Mikroyönetime karşı güçlü bir tepki gösteriyor: "Mühendislere ne yapacaklarını söylemek kadar sinir bozucu bir şey yok"
- Bunun yerine liderin “kutu (Box) ve çorba (Soup)” sunması gerektiğini söylüyor
- Kutu: fikirler ve bağlamla doldurulmuş alan
- Çorba: ekip üyelerinin özgürce içebileceği veya birleştirebileceği bilgi tabanı
- Talimat vermek yerine ilham veren hikâyeler sunulduğunda, insanlar kendi başlarına karar verir ve gelişir
- Bazı ekip üyeleri “Bana sadece ne yapmam gerektiğini söyleyin” der, ama onlar bile sonunda bunu kendi tarzlarında yorumlar
> Liderin görevi çorbayı vermektir. İçip içmemek ya da içine ne katacakları onların seçimidir.
-
Liderlik özelliği #3: Ekip üyelerinin motivasyonunu ve hedeflerini anlar
- Lider, her bir ekip üyesinin neyle geliştiğini ve neyle motive olduğunu bilmelidir
- Örnek: Teknik meydan okumaların hayattaki itici gücü olduğu bir mühendise sürekli problem çözme fırsatları sağlamak
- Başka bir örnek: Palantir’deki bir asistan, ödül odaklı motivasyonunu açıkça ortaya koyuyor → bu da net bir yönetim imkânı sağlıyor
- Esas mesele, her kişinin “tek bir temel motivasyonunu” kavramak ve ona sürekli yatırım yapmaktır
- Bunun için merak (curiosity) ve durmaksızın “neden?” diye sorma zorunludur
> Lider, ekip üyelerinin kendilerinin bile fark etmediği motivasyonları keşfetmeli ve büyüme fırsatları yaratmalıdır.
Sonuç: Başarılı mühendisliğin özü insanı anlamaktır
- Başarılı mühendislik organizasyonları, sorunsuz işleyen insan dinamiklerine (Human Dynamics) bağlıdır
- Harika ürünler üstün bireylerden değil, iyi iş birliği yapan insanların toplamından doğar
- Liderin rolü, organizasyonu oluşturan insanları güçlendirmekle başlar
- “Mühendislik ekipleri, karmaşık ve harika insanlardan oluşan dev bir doku (tapestry)”
- Bu dokunun yapısını ve akışını anlamaya çalışma çabası, ürünün değerinin tüm organizasyon boyunca etkili biçimde aktarılmasını sağlayan anahtardır
> "İnsanların nasıl etkileşime girdiğini anlamaya yönelik bir motivasyona sahip olduğunuzda, şirketiniz ürünün değerini ölçekli biçimde sunmaya hazır hale gelir."
6 yorum
Michael Lopp’un işlettiği, teknik liderler için bir Slack var.
RLS - Rands Leadership Slack
İlgilenenler bir göz atabilir. Şu anda 36.000’den fazla kişinin katıldığı devasa bir Slack.
Katılmak için yukarıdaki bağlantıdaki içeriği dikkatlice okuyup Lopp’a e-posta göndermeniz gerekiyor.
İsim/meslek/neden katılmak istediğiniz/RLS’yi nereden duyduğunuz/LinkedIn veya Twitter gibi hesaplarınız
Pahalı bir mühendisi işe aldıysanız, kalem oynatan biri olmasına bakıp mühendisi bir LLM gibi görerek, sanki bir şeyi şıp diye ortaya çıkaran bir Doraemon’a emir verir gibi en ufak şeye kadar şöyle yap böyle yap demek yerine, sadece kendi vizyonunuzu paylaşın; onu hayata geçirecek mühendislik yaklaşımı zaten o kişinin uzmanlık alanı olduğundan, bırakın işini kendi bildiği gibi yapsın deniyor yani.
Dikkatle dinleyince, nedense aklıma bizim ülkede kırsalda müstakil ev yaptırmak ya da eski bir apartman dairesini yeniletmek isteyen insanların usta, müteahhit ya da mimarla didişip durduğu o tartışma silsilesi geliyor, neden acaba?
İkinci durum biraz farklı bir bağlam değil mi?
Müstakil ev ya da eski apartman dairesi tadilatı,
öncelikle işten çok bir hayali gerçekleştirme alanına daha yakın;
üstelik inşaat/tadilat şirketine güvenip işi teslim ettikten sonra kazıklanma gibi şeyler nedense gerçekten çok sık yaşanıyor...
Sahibi işi bizzat yapmayıp birine yaptırsa yine aynı durumun ortaya çıkacağını düşünüyorum.
Ne kadar iyi anlatırsanız anlatın yanlış anlaşılmalar oluyor; ne kadar titiz davranırsanız davranın yine de akla gelmeyen alanlar çıkıyor.
Sahibin söylemediği kısımları tek tek sorarak ilerlemek çok zaman alıyor ve insanı bunaltıyor; bu yüzden uzmanın kendi inisiyatifiyle hallettiği epey çok şey oluyor ve galiba bütün sürtüşme de oralardan çıkıyor.
Bu arada, anlaşılan SI şirketlerinden pek kazık yememişsiniz; bu açıdan size imrendim.
Son zamanlarda okuduğum Modern Software Engineering de aklıma geliyor. Çünkü yalnızca geliştirmenin kendisinden değil, ekip ve organizasyondan da söz ediyor.
Mühendislik liderliği hakkında çeşitli görüşler ve yöntemler var, ancak özünde hepsinin ekip üyelerini anlamaya dayandığı konusunda hemfikiriz gibi görünüyor. Ekip üyelerini anlamak kulağa kolay gelse de, karşılıklı geri bildirimler yoluyla lider ile ekip üyeleri arasında empatiye dayalı bir güvenin inşa edilmesi gerektiğini düşünüyorum. Bunun bir anda oluşan bir şey olmadığını da görüyorum. Düşünmeye değer bu güzel içerik için teşekkürler.