Mühendislik Liderleri İçin Anti-Pattern’ler
(review.firstround.com)- CTO’lar veya mühendislik liderleriyle görüştüğümüzde en sık konuşulan konu, CEO’nun “mühendislik hızını artırın” baskısı oluyor
- Satış ya da işe alımdan farklı olarak mühendislikte net performans göstergeleri yok
- Mühendislik liderleri açısından CEO’ya “mühendislik bir sanattır, bu yüzden çıktıları öngörmek zordur” demek kolay değil
- Mühendislik liderleri ile yönetim kadrosu arasındaki görüş ayrılıklarının nedenleri
- Mühendislik liderleri, kalıplaşmış liderlik tavsiyelerini fazla katı biçimde izleme eğiliminde
- Bir pratiğin faydalı ya da faydasız olduğunu genelleyince, bunu organizasyonun koşullarına göre uygulamak zorlaşıyor
- Duruma göre bir pratiği izleyip izlememeye ya da yeni bir yaklaşım deneyip denememeye karar vermek, etkili mühendislik liderliğinin özü
- Carta CTO’su Will Larson’ın podcast’te anlattıklarının derlendiği bir yazı
Mühendislik liderliğinde 3 anti-pattern
- Mikroyönetimden kaçınma
- Kusurlu metrikleri ölçmekten kaçınma
- Liderin ekip için şemsiye olması
[Anti-pattern #1: Mikroyönetimden kaçınma]
En iyi mühendislik yöneticisi olmak için birbiriyle çelişen üç rol
- Mühendislik yöneticileri birbiriyle çelişen üç rolü aynı anda üstlenmek zorunda; en iyileri bu roller arasında ustalıkla geçiş yapabiliyor
- Yönetim ekibinin bir üyesi olarak rol: işi nasıl büyüteceğini düşünmek
- Bazen mühendislik bütçesini kısmak gibi “genel olarak mühendislik için kötü” kararlar almak gerekebilir
- Buna, belirli konularda mühendisliğin sesinin daha az çıktığı bir iş birimi modeline geçmek de dahil olabilir
- Mühendislik yöneticisi olarak rol
- Mühendislik organizasyonunu işletmek için gereken politika yapısını anlamak ve etkili bir insan lideri olmanın yollarını aramak
- Mühendis olarak rol
- Dış baskılara rağmen teknik mükemmeliyet ve mühendislik uygulamasından sorumlu olmak
- Teknik kalite çıtasını yüksek tutmak gerekir
- Yönetim ekibinin bir üyesi olarak rol: işi nasıl büyüteceğini düşünmek
- Birçok yönetici bu üç rolden birine aşırı ağırlık verme eğiliminde
- Hangi rolde olursa olsun, artık işe yaramayan yönetim pratiklerine tutunan liderler hata yapar
- Bir anda bir ekibin yöneticisi olduğunuzda, teknik olarak ekibin yaptığı her şey hakkında en fazla bağlama sahip kişi olursunuz; ama aynı zamanda bir insan yöneticisine de dönüşürsünüz
- Bu noktada insanlara sürekli ayrıntılardan uzak durmaları tavsiye edilir
- Yeni mühendislik yöneticileri sık sık “koddan uzaklaş” tavsiyesi alır
- Bunun bazı kişiler için faydalı olabileceği kabul ediliyor
- Ancak son derece yetkin yöneticiler, yönettikleri alan hakkında belli ölçüde ayrıntılı anlayışa sahip olur
- Ayrıntılardan fazla uzaklaşırsanız sadece bir bürokrata dönüşürsünüz; çok sayıda mühendislik yöneticisinin sonunda bürokrata dönüşmesinin nedeni de bu
Liderlik tarzını geliştirmek
- Larson, mühendislik yöneticilerine mikroyönetim terimini tamamen unutmalarını ve bunun yerine seçebilecekleri farklı liderlik tarzları geliştirmeye odaklanmalarını öneriyor
- Önünüzde net bir yol yoksa ya da ileriye dönük bağlama sahip kişiler sert biçimde fikir ayrılığı yaşıyorsa, ayrıntılara inip kararı kendiniz vermek faydalı olabilir
- Bu sayede işi gerçekten değiştirebilecek kaldıraç noktalarını, ekibin ulaşması gereken sonuçları, bunların hangi sürede yapılacağını ve kullanıcılara nasıl daha iyi hizmet verileceğini anlayabilirsiniz
- Kararlara dair daha güçlü bir kanaat geliştirmek, ömür boyu süren bir pratik; Larson da bunun üzerinde hâlâ çalıştığını söylüyor
- “Ne yapıyoruz? Bunu neden yapıyoruz? Veri ne diyor? Verinin gerçek kaynağı neresi?” gibi soruları aylık ya da çeyreklik olarak sormak, ayrıntılara daha derin inmeye yardımcı olur
Ayrıntılara yaklaşmak için iki taktik
-
“Çatışma madenciliği” ile bağlam kazanmak
- Yeni bir ortamda küçük bağlam farklarını kaçırmak bile operasyonel başarıyı zedeleyebilir
- Karşıt bakış açısına sahip kişilerle konuşmak zaman alsa da “çatışmanın tohumlarını” bulma süreci önemlidir
- Başarılı liderler “Organizasyona uyum sağlamak için ben nasıl değişmeliyim?” diye sorar; “Organizasyonu benim tarzıma uydurmak için nasıl değiştirmeliyim?” diye değil
-
Ayrıntıları dokümante etmek
- Strateji her yerde ama neredeyse hiç dokümante edilmiyor
- Önemli kararların gerekçesi çoğu zaman yazılı hale getirilmiyor
- Dokümantasyon kültürü kurmak, hızlı hareket eden mühendislik organizasyonlarının anahtarı
- Yeni liderler, kendi stratejilerini oluşturmadan önce mevcut her şeyi incelemeli ve diğer şirketlerin başarı örneklerini kıyas noktası olarak almalı
- Strateji belgesi yazarken Richard Rumelt’in “Good Strategy, Bad Strategy” çerçevesinin kullanılması öneriliyor
- Stratejiyi ne kadar kötü yazarsanız yazın, sadece dokümante etmek bile onu bir gecede iyileştirebilir
[Anti-pattern #2: Kusurlu metrikleri ölçmekten kaçınma]
- Ölçüm konusunda anti-pattern’ler çok yaygın
- İdeal dünyada rahatça “bunu ölçmemeliyiz” denebilir, ama bunu yapmak çevrenizdeki organizasyonun öğrenme hızını sadece yavaşlatır
- Mühendislik yöneticisinin yapabileceği en değerli işlerden biri, diğer yöneticilere mühendisliğin nasıl çalıştığını öğretmektir
Zihinsel modelleri geliştirmeye odaklanmak
- Metriklerin gerçeği göstermesini isteriz, ama metrikler yalnızca hakikati göstermek için değil, insanları eğitmek için de vardır
- Kendi zihinsel modelinizin incinmesinden çok, yönetim kurulu ya da CEO’nun zihinsel modelini bilgilendirmeyi dert etmelisiniz
CEO’yu ayrıntılara çekmek
- “Bu, ölçmek için korkunç bir yöntem” demek yerine, “Buradan başlayalım ve bu şekilde ölçmenin sınırlarını anlayana kadar derine inelim” demek gerekir
- İnsanları zorla ayrıntılardan uzaklaştırmak asla iyi bir yöntem değildir. Onları ayrıntıların içine çekip orada eğitmek gerekir
[Anti-pattern #3: Ekip için şemsiye olmak]
- Geçmişte, ekibi korumak için yöneticinin bir “şemsiye” gibi davranmasına inanılıyordu
- Ancak ekibi gerçeklikten korumak, uzun vadede ekibe zarar verir
- Hem yöneticilerin hem de mühendislerin önemli konuşmalara katılabilmesi gerekir
Stratejik kararlar için yeni bir bakış açısı gerekli
- Bottom-Up strateji
- Artısı: Ekibin hızlı hareket etmesini ve araçları kontrol etmesini sağlar
- Eksisi: Odaklı teknik yatırım yapma kapasitesi yoktur ve bilgiye biraz geç ulaşılır
- Top-Down strateji
- Eksisi: Tüm kararların CTO ya da mimari grup tarafından alınması verimsizdir
- Komiteler nadiren en iyi kararı verir
“Navigator” kullanarak karar almayı hızlandırmak
- Her iş biriminde “mini CTO” gibi çalışan bir “navigator” rolü oluşturarak karar alma hızlandırılabilir
- Böylece sahada en çok bağlama sahip kişilerin, teknoloji yığınıyla ilgili en uygun kararları vermesi sağlanır
- Başarı için dersler:
- Dokümantasyonu atlamayın
- Sonradan değerlendirme yapın
- Güvenilecek kişileri seçerken son derece dikkatli olun
- Organizasyon, az sayıdaki kişinin muhakemesinin birikimidir; bundan kaçınmak mümkün değildir
Sonuç
- Kuralları aşırı katı izlemenin riski
- Şirketle birlikte mühendislik ekibi büyümeye başladığında, liderler geçmişte birçok iyi niyetli yöneticiyi zor durumda bırakan şeyleri unutmamalıdır
- Nihai hedef, insanların merakla istisnaları aramasını sağlayan yüksek kaliteli mekanizmalar kurmaktır
- Öğrenme çemberi (Learning Circle)
- Larson son üç buçuk yıldır iki haftada bir “öğrenme çemberi” düzenliyor
- 6 ila 10 CTO, VP of Engineering veya teknoloji şirketlerinden diğer kıdemli mühendislik yöneticileri bir araya gelip güncel durumlarını paylaşıyor, taktik ve süreç sorunlarını tartışıyor
- Her toplantı, sırayla kişi başı 1 dakika boyunca o hafta neye odaklandıklarını ve hangi konuyu konuşmak istediklerini söylemeleriyle başlıyor
- Konular hakkında yaklaşık 5 dakika konuştuktan sonra grup birini seçiyor ve sonraki yaklaşık 20 dakika boyunca onu derinlemesine ele alıyor
- Konular, “Bu proje yüzünden zor durumdayım” ile “Gerçekten harika birini yeni işe aldık, çok heyecanlıyım” arasında değişebiliyor
- Larson son üç buçuk yıldır iki haftada bir “öğrenme çemberi” düzenliyor
- Pratik yoluyla öğrenme
- Pratik yaparak öğrenen kişiler, öğrenme çemberi ya da kişisel değerlendirme gibi düzenli düşünme alışkanlıklarına dayanarak, kuralları ince ayarla uygulamak için gereken öz farkındalığı kendilerinde zorunlu olarak geliştirebilir
- Larson, “Benimkine benzer hatalar yapmış başkalarının derslerinden öğrenerek daha iyi bir lider oldum” diyor
9 yorum
Son kısımdaki "Larson, '... daha iyi bir lider oldum' diyor." ifadesi bana biraz utanç verici geliyor. Keşke onun yerine "Liderler ... yapabilmek için sürekli çaba göstermeli. Ben de hâlâ eksiklerim olan biriyim ve daha iyi olmak için uğraşıyorum" gibi bir ifade olsaydı; o zaman okuması daha rahat olurdu. Bu fazla Kore usulü bir bakış açısı mı? ^^;;
Bunun Kore'ye özgü bir bakış açısı olup olmadığını sormanızdan, konuya oldukça hakim olduğunuz anlaşılıyor; bana kalırsa konuşmacı narsisizm sergiliyor da değil, bu yüzden böyle bir tepki biraz şaşırtıcı geliyor.
Yazının özüne ya da içeriğine değil de konuşanın tavrına odaklanmak oldukça Kore'ye özgü görünüyor
"Anti-pattern #1: Mikro yönetimden kaçınma" deniyor ama sonra mikro yönetimi unutun denmesi, anlatımın akışını garipleştiriyor.
Mikroyönetimi kötü bir şey, yapılmaması gereken bir şey olarak görüp koşulsuz biçimde kaçınmanın anti-pattern olduğu söyleniyor. Mesele bunun mikroyönetim olup olmadığına karar vermek değil, gerektiğinde ayrıntılarla ilgilenmek gerektiği.
En azından bunu "Anti-pattern: mikro yönetimi bir seçenek olarak görmek" ya da "detaylarla ilgilenmeyi mikro yönetimle aynı şey sanmak" şeklinde ifade etselerdi, bağlam biraz daha akıcı olurdu. Yazının niyetini anlıyorum ama sonuçta vermek istediği mesaj, "mikro" yönetim yerine detaylarla ilgilenen bir yönetim yapılması gerektiği, değil mi?
CTO'lar veya mühendislik liderleriyle görüştüğümde en sık konuştuğumuz konu, CEO'nun "mühendislik hızını artırın" baskısı oluyor
Satış veya işe alımdan farklı olarak, mühendislikte net performans göstergeleri yok
Mühendislik liderinin açısından CEO'ya "mühendislik bir sanattır, bu yüzden çıktıları öngörmek zordur" demek kolay değil
Bu yazı hakkındaki Hacker News görüşlerine de göz atın.