Tech Lead: En İyi Developer Değil, Kararın Sahibi

Sahadan: 11 PR, tek onay

Mart başında emir ekibinde bir tech lead’e ihtiyacımız vardı. Ben iki ekibin yöneticisiydim ve teknik kararlara yetişemiyordum. Seçim kolaydı: ekibin en iyi developer’ı. En zor hataları o buluyordu, emir yönlendirme kodunun yarısını o yazmıştı, herkes zaten ona soruyordu.

Terfiyi verirken tek cümle kurdum: “Artık teknik taraf senin.” Teknik tarafın ne olduğunu, nerede bittiğini söylemedim. Üstüne iki şey ekledim. Kritik modüllerdeki her PR onun onayından geçecekti. Ve iki junior’ın performans notlarını o yazacaktı, çünkü “teknik tarafı sen daha iyi bilirsin”.

Üç ay sonra, Mayıs sonunda tablo şuydu:

• İlk review bekleme süresi (medyan) Şubat’ta 0,6 gündü, Mayıs’ta 2,3 gün.
• Haftasının 19 saati review, 9 saati toplantıya gidiyordu. Kendi story’sine 12 saat kalıyordu.
• O story, iki kişinin işinin bağlı olduğu story’ydi. Üç sprint üst üste taşındı.
• Ekip 34 puan taahhüt ediyor, 21 puan teslim ediyordu.

Bire birde bunu bana kendisi söyledi: “Üç aydır ne iş yaptığımı bilmiyorum. Kod yazıyorsam review bekliyor, review yapıyorsam kodum bekliyor. Akşam 22:00’de commit atıyorum ki gündüz onay verebileyim.”

Hata onun değildi. Ona bir unvan vermiştim ama bir rol vermemiştim. Rolün boşluğunu da iki yerden doldurmuştum: benim yapmam gereken insan işlerinin bir kısmıyla ve eskiden yaptığı kod işinin tamamıyla.

İki rol, iki soru

Tech lead ile engineering manager aynı ekibe bakar ama farklı sorulara cevap verir. İkisini aynı kişide birleştiren ekipler de var; sorun birleştirmek değil, sınırı hiç konuşmamak.

Performans notlarını tech lead’e yazdırmak bu sınırı en pahalı yerden deliyor. Tech lead’in işi review’da “bu yaklaşım neden riskli” demek. Aynı kişi aynı hafta not da veriyorsa, o yorum artık bir teknik görüş değil, bir değerlendirme gibi okunuyor. Junior’lardan biri bir ay sonra bire birde şöyle dedi: “Onunla artık kod konuşamıyorum. Her yorumda not veriyor gibi hissediyorum.”

Karar hakları tablosu

Haziran’ın ilk haftası oturup tek sayfalık bir tablo yazdık. Amaç iki kişinin gücünü paylaştırmak değil. Amaç ekipteki herkesin “bunu kime soracağım” sorusunu tek bakışta cevaplaması.

Tablonun en işe yarayan kısmı kalın yazılar değil, “bilgilenir” hücreleri. Mimari kararda “bilgilenir” yazan satırı okuduğum gün, kendi alışkanlığımı gördüm: teknik tartışmalara girip son cümleyi ben kuruyordum. Tech lead’in kararını ben verince, ekip bir sonraki sefer ona değil bana geliyordu.

Gri alanlar yine çıkıyor. Tech lead ile ben aynı konuda farklı düşündüğümüzde çatışma yazısındaki geri dönülebilirlik testini kullanıyoruz: karar kolay geri alınıyorsa sahibi karar verir ve ilerleriz.

İlk gri alan tablonun ikinci haftasında çıktı. Bir developer üç PR üst üste standardın dışında hata yönetimi yazdı. Teknik bir konu mu, insan konusu mu? Şu ayrımda anlaştık: review’da standardı tech lead söyler, bir kez, iki kez. Aynı şey üçüncü kez tekrarlanıyorsa konu artık kodla ilgili değildir; davranışla ilgilidir ve bana geçer. Bire birde açıldığında sebep basit çıktı: standardın yazılı hâlini hiç okumamıştı, çünkü linki kimse paylaşmamıştı.

Tech lead ne kadar kod yazar?

Bu soruda iki uç da yanlış. Hiç kod yazmayan tech lead, verdiği kararların bedelini hissetmiyor; standardı koyuyor ama o standartla bir hafta yaşamıyor. Eskisi gibi yazan tech lead ise bizim yaşadığımızı yaşıyor: kararlar ve review’lar onun kodunu bekliyor, onun kodu kararları bekliyor.

Yöneticinin kod yazıp yazmaması ayrı bir soru; orada kod opsiyonel. Tech lead için kod zorunlu, ama yeri farklı. Bizde haftanın yaklaşık %40’ı. Asıl kural oran değil, konum:

Test basit: tech lead bir hafta hastalansa hangi story durur? Cevap “hiçbiri” değilse, tech lead kritik yolda. Mayıs’ta bu sorunun cevabı “emir yönlendirme story’si ve ona bağlı iki iş”ti. Elindeki story’yi ekipteki orta seviye bir developer’a devrettik; ilk iki gün birlikte pair yaptılar. Devretmenin kendisini delegasyon yazısında anlattım; burada tekrar etmeyeceğim.

Oranı tahminle değil takvimle ölçüyoruz: iki haftada bir, tech lead’in takvimini ve commit geçmişini yan yana koyup beş dakika bakıyoruz. Haziran’ın ilk iki haftasında oran %22’de kaldı, çünkü review yükü hemen düşmedi. %40’a ancak CODEOWNERS değişikliğinden sonra çıktı.

Onay kapısı değil, standart

“Kritik modüllerde her PR tech lead onayından geçer” kuralını ben koymuştum. Niyet kaliteyi korumaktı. Sonuç ise iki şey oldu. Birincisi bekleme; o Salı sabahki 11 PR. İkincisi daha sinsi: ekip standardı değil, onun zevkini öğrendi. “Bunu nasıl yazarsa onaylar” sorusu, “doğrusu ne” sorusunun yerini aldı.

Değiştirdiğimiz şey bir dosya oldu. Standardı iki sayfaya yazdık, modüllere ayrı sahipler atadık. Tech lead yalnızca sınırlarda kaldı:

# ONCE: her sey tek kisiden geciyor
*                          @tech-lead

# SONRA: modul sahipleri; tech lead yalnizca sinirlarda
/emir-yonlendirme/         @emir-sahibi-1 @emir-sahibi-2
/pozisyon/                 @pozisyon-sahibi
/raporlama/                @raporlama-sahibi

# servisler arasi sozlesme ve sema: geri almasi pahali
/ortak/sozlesmeler/        @tech-lead
/db/migrations/            @tech-lead @emir-sahibi-1

Son iki satırın mantığı şu: tech lead’in onayı, geri alması pahalı olan yerde değerli. Bir fonksiyonun adı yanlışsa ertesi gün düzeltilir. Servisler arası bir sözleşme yanlışsa üç ekip etkilenir. Onay hakkını pahalı yere topladık, ucuz yerden çektik.

İlk hafta modül sahiplerinden ikisi onay vermeye çekindi ve PR’ları yine tech lead’e etiketledi. Tech lead de onayladı; alışkanlık iki taraflıydı. İkinci hafta bir kural koyduk: tech lead, sahibi olmadığı bir modülde onay vermez, sadece yorum yazar. Bu küçük kural, CODEOWNERS dosyasından daha çok şey değiştirdi.

Neden en iyi developer değil?

En iyi developer bir problemi en iyi çözen kişi. Tech lead ise bir problemin nasıl çözüleceğine karar veren, o kararı yazan ve başkasına uygulatan kişi. İkisi aynı insanda olabilir, ama aynı beceri değil.

Seçerken artık üç şeye bakıyorum:

1. Kararını yazıyor mu? Bir paragraf: ne karar verildi, neden, hangi alternatif neden elendi. Yazılmayan karar her seferinde yeniden sorulur.
2. Kararı başkası uygulayabiliyor mu? Kendi yazdığında harika olan bir tasarım, başkası yazınca dağılıyorsa o tasarım değil, bir kişinin becerisi.
3. Yanıldığını söyleyebiliyor mu? Tech lead’in yanlış kararı geri alması, doğru kararı savunmasından daha nadir ve daha değerli.

Bizim tech lead’imiz üçünde de iyiydi. Sorun kişide değil, ona verdiğim rolün tanımsız olmasındaydı. Rolü tek sayfaya yazınca bunu kendisi de gördü.

KARAR VERIR : mimari yon, servis siniri, kod standardi,
              kutuphane secimi, olay aninda teknik karar
GORUS VERIR : ise alim, performans (ornek ile), sprint kapsami
KARISMAZ    : kariyer gorusmesi, maas, kisiler arasi catisma

KOD         : haftanin ~%40'i
              kritik yolda story YOK
REVIEW      : sozlesme + sema PR'lari zorunlu, gerisi istege bagli
YAZAR       : her karar icin 1 paragraf (ne, neden, elenen secenek)

GOZDEN GECIRME : ceyrekte bir, yonetici ile 30 dk

Ne izlemeli?

Bende işe yaramayanlar

• Performans notlarını tech lead’e yazdırmak. “Teknik tarafı o daha iyi bilir” dedim. Bilir, ama not veren kişiyle kod konuşulmuyor. Artık tech lead somut örnek veriyor, değerlendirmeyi ben yazıyorum ve imza benim.
• “Her PR tech lead onayından geçer” kuralı. Kaliteyi korumadı; kaliteyi tek kişinin takvimine bağladı.
• “Birlikte karar veririz” demek. Tablodan önce gri alanlar için bu cümleyi kurmuştuk. İki hafta boyunca teknik borç sıralamasında kimse karar vermedi, çünkü ikimiz de diğerini bekledi. Birlikte karar, çoğu zaman kimsenin kararı.
• Tech lead’i toplantılardan tamamen çekmek. Yükünü azaltmak için ürün toplantılarından çıkardım. İki hafta sonra onun bilmediği bir teknik kısıtla bir özellik söz verildi. Toplantı sayısını değil, toplantıdaki rolünü azaltmak gerekiyordu.

Kontrol listesi

Sonuç

O Salı’dan altı hafta sonra ilk review bekleme süresi 2,3 günden 0,7 güne indi. Tech lead’in haftalık review süresi 19 saatten 7 saate düştü. Sprint’te 34 puanın 30’u teslim edildi. Üç sprint taşınan story, devredildiği sprint’te kapandı — onun yazmadığı ama onun kararına göre yazılmış kodla.

Hiçbiri yeni bir beceriden gelmedi. Kişi aynıydı, ekip aynıydı. Değişen tek şey, rolün nerede başlayıp nerede bittiğinin yazılı olmasıydı. Son bire birde kendisi özetledi: “Artık ne iş yaptığımı biliyorum. Karar veriyorum, yazıyorum, başkası yapıyor.”

Hatam onu seçmek değildi; ona bir unvan verip rolü kendi hâline bırakmaktı. Tech lead’in en iyi kodu, başkasının yazdığı ve onun kararına uyan koddur.