Ana sayfa → Ekip Yönetimi
Developer’dan Yöneticiye: Terfi Değil, Meslek Değişikliği
Ekipteki en iyi mühendisi yönetici yapıyoruz ve buna “terfi” diyoruz. Oysa yaptığımız şey, birine on yılda öğrendiği mesleği bıraktırıp hiç yapmadığı bir işe başlatmak. Üstelik başarısız olursa da geri dönemeyeceği bir işe.
- İki ayrı meslek. Biri sistemleri, diğeri insanları ölçekliyor; ortak yanları sandığından az.
- Ölçü net: bir hafta kod yazmasan kimse bekliyor mu? Bekliyorsa ekibin darboğazısın.
- Yanlış eşleşme iki kayıp. İyi bir mühendisi kaybedersin, mutsuz bir yönetici kazanırsın.
- Geri dönüş bir başarısızlık değil. Ama ancak önceden konuşulmuşsa öyle sayılır.
İlk hafta neyin değiştiğini fark etmiyorsun
Yeni unvan geliyor, masa aynı kalıyor, ekibin aynı. Sen de doğal olarak eskisi gibi çalışıyorsun: sprint’te iki story alıyorsun, en zor olanı seçiyorsun — çünkü en hızlı sen çözersin. Bu, mantıklı görünen ve neredeyse herkesin yaptığı ilk hata.
Ben de yaptım. Geçişimin ikinci sprint’inde ödeme tarafındaki en kritik story bendeydi. Aynı hafta iki bire bir, bir işe alım süreci, bir de üretim olayı çıktı. Story yerinde saydı; ona bağlı üç kişi Perşembe gününü bekleyerek geçirdi.
Retro’da bunu bana söyleyen kişi ekipteki en kıdemsiz mühendisti: “Sen meşgulken kimse o kodu açmıyor, çünkü senin işin sanıyor.” Ölçtüğümde daha net gördüm: o sprint benim beklettiğim toplam süre, benim yazdığım koddan çok daha pahalıydı.
İşin gerçekten ne değişti
Geçişi zorlaştıran şey iş yükü değil, geri bildirim döngüsünün uzaması. Mühendislikte 20 dakikada bilirsin: test geçti mi, geçmedi mi. Yöneticilikte bir kararın doğru olup olmadığını çoğu zaman aylar sonra öğrenirsin.
| Mühendis | Yönetici | |
|---|---|---|
| Çıktı | Senin yazdığın kod | Ekibin çıkardığı iş |
| Geri bildirim | Dakikalar | Haftalar, bazen aylar |
| İyi gün hissi | “Şunu bitirdim” | “Bugün ne yaptım ki?” |
| Başarı ölçüsü | Çözdüğün problem | Sensiz de çözülen problem |
Bu tablonun üçüncü satırı ilk aylarda insanı en çok yıpratan yer. Akşam bilgisayarı kapatırken elinde gösterilecek bir şey olmuyor. Oysa o gün bir işe alım kararını düzeltmiş, bir çatışmayı büyümeden çözmüş ve bir kişinin ayrılmasını engellemiş olabilirsin — hiçbiri commit geçmişinde görünmüyor.
“Yine de review’a girer miyim?”
En sık gelen soru bu ve cevabı kategorik değil. Kod yazmayı tamamen bırakan yönetici, altı ay içinde tahminleri sorgulayamaz hale geliyor: “bu üç gün sürer” dendiğinde iç sesi susuyor. Bırakmayan yönetici ise ekibi bekletiyor.
- Küçük araçlar, script’ler, geliştirici ortamını hızlandıran işler
- Prototip: “bu yaklaşım tutar mı” sorusunu ucuzlatan bir gün
- Review’a girmek — ama son söz sahibi olarak değil
- Nöbet sırasına girmek (ara sıra; acıyı unutmamak için)
- Sprint taahhüdünde yer alan bir story
- Kritik yolda, başkalarının beklediği bir iş
- “En zorunu ben alayım” refleksi
- Mimari kararı tek başına verip bitirmek
Tek cümlelik ölçü: bir hafta hiç kod yazamasan kimse beklemede kalmıyorsa doğru işleri alıyorsun demektir.
Kime teklif etmeli
“En iyi mühendis” kötü bir ölçüt. Daha iyi bir ölçüt şu: bu kişi başkasının işini kolaylaştırınca keyif alıyor mu? Bunu terfi öncesinde de görebilirsin — kimse sormadan onboarding dokümanını güncelleyen, review’da “şöyle de yapılır” diye örnek yazan, kendi işi yavaşlasa da yeni geleni oturtan kişi.
Teklif ederken de dürüst bir cümle gerekiyor: “Bu bir terfi değil, farklı bir iş. Altı ay dene; sana göre değilse eski rolüne dönmen bir başarısızlık sayılmayacak — bunu şimdiden ekiple de konuşacağım.” Bu son kısım söylenmezse geri dönüş yolu kapanır ve mutsuz bir yönetici yıllarca yerinde kalır. Bedelini de ekip öder.
İlk 90 gün
- 1. hafta: bire birleri kur, gündemi onlara bırak. Hiçbir şeyi değiştirme.
- 2-4. hafta: dinle ve yaz. Ekibin şikâyet listesini çıkar; ilk ay sadece en ucuz iki maddeyi çöz.
- 5-8. hafta: kritik yoldan çık. Elindeki story’leri devret, devrederken bırak.
- 9-12. hafta: ilk zor konuşmayı yap. Erteledikçe zorlaşan tek şey odur.
Kontrol listesi
- Bu hafta kimse benim yüzümden beklemede kaldı mı?
- Ekipte benden başka mimari karar verebilen kaç kişi var?
- Son bir ayda bana gelen kötü haberler erken mi geldi, geç mi?
- Takvimimde kesintisiz düşünme bloğu kaldı mı?
- Kod yazma isteğim bir ihtiyaç mı, yoksa ölçülebilir bir çıktıya duyduğum özlem mi?
- Bu işi seviyor muyum — yoksa sadece geri dönmek zor mu geliyor?
Sonuç
Yöneticilik bir üst seviye değil, yan bir dal. İyi yapıldığında ekibin çıkardığı iş senin tek başına çıkarabileceğinin katları olur; kötü yapıldığında ise hem iyi bir mühendis kaybedilir hem de bir ekip yavaşlar.
En sağlıklı işaret şu: altı ay sonra ekip senin olmadığın bir haftayı sorunsuz geçirebiliyorsa doğru yoldasın. Bunu bir eksiklik gibi değil, işin tanımı gibi oku.