Staff Engineer: Kıdem Değil, Etki Alanı

Sahadan: yedi ay, 64 story point

Aynı çeyrekte emir ekibi ile ödeme ekibi arasında üç olay yaşadık. Üçünün de kökü aynıydı: bakiye rezervasyonu. Emir servisi rezervasyonu 30 saniye sonra bırakıyor, ödeme servisi aynı rezervasyonu 5 dakika boyunca geçerli sayıyordu. Arada kalan emirler ya iki kez bakiye düşüyor ya da hiç düşmüyordu.

Her olayda ilgili ekip kendi tarafını yamadı. Üç olay, üç yama, hiçbiri ortak bir sözleşme değil. Sorun iki ekibin arasındaydı ve arada kimsenin masası yoktu.

İşin acı tarafı şu: iki servisi de en iyi bilen kişi o staff mühendisti. Sorunu ilk olayda görmüş, “bir ara yazarım” demişti. O “ara” hiç gelmedi. Çünkü sprint planlamasında emir ekibinin kapasitesine %100 sayılıyordu. Ona ayrılmış boş saat sıfırdı.

Hata benimdi. Unvanı ödül olarak vermiştim: iyi kod yazıyordu, piyasada ilgi görüyordu, ayrılmasın istedim. Unvanı değiştirdim, işini değiştirmedim. Yedi ay boyunca ekipteki en pahalı kıdemli mühendis olarak çalıştı — ve bu onun değil, benim tanımımın sonucuydu.

Staff ne işe yarıyor

Kıdemli mühendis bir sistemin sahibidir. Staff ise sistemler arasındaki boşluğun sahibidir. Bu boşluk her büyüyen organizasyonda oluşuyor: ekip sayısı arttıkça “bu kimin işi?” sorusunun cevabı olmayan konular da artıyor. Staff’ın işi bu konuların sahibi olmak. Dört başlıkta topluyorum.

1. Ekipler arası teknik sorunlar

Hiçbir ekibin tek başına çözemeyeceği sorunlar: iki servis arasındaki sözleşme, üç ekibin ayrı ayrı yazdığı retry mantığı, herkesin kullandığı ama kimsenin sahiplenmediği bir kütüphane. Bu sorunların ortak özelliği, her ekibin backlog’unda “düşük öncelik” olarak durmaları. Tek bir ekip için gerçekten düşük önceliklidirler. Toplamda değil.

2. Yazılı öneri

Staff’ın yöneticilik yetkisi yok. Kimseye “böyle yapacaksın” diyemez. Elindeki tek araç ikna, ikna da yazıyla ölçekleniyor. İki sayfalık bir öneri beş ekibe aynı anda gidebilir, toplantı gidemez. Önerinin iskeleti sade:

BASLIK    : Bakiye rezervasyon suresinin tek kaynagi
SAHIBI    : staff muhendis
ETKILENEN : emir ekibi, odeme ekibi
SON TARIH : yorumlar 9 gun icinde

1. SORUN      : bugun ne oluyor? (olay sayisi, rakam)
2. ONERI      : ne degisecek? (tek paragraf)
3. SECENEKLER : dusunulen ve elenen yollar, neden elendi
4. MALIYET    : hangi ekip ne kadar is yapacak
5. GERI ALMA  : yanlis cikarsa nasil doneriz
6. ACIK SORU  : yazarin cevabini bilmedigi seyler

# Kural: "Secenekler" bolumu bossa oneri degil, emirdir.

“Seçenekler” bölümünü önemsiyorum. Elenen yolları yazmayan öneri, okuyanı aynı yolları yeniden tartışmaya itiyor. “Açık soru” bölümü de yazarın her şeyi bilmediğini kabul ettiği yer; yorumların çoğu oraya geliyor.

3. Görünmeyen bağlayıcı iş

Tanya Reilly’nin “glue work” dediği iş: olay sonrası aksiyonların iki ekip arasında kimde kaldığını takip etmek, yeni gelen mühendise sistem haritasını çizmek, iki ekibin aynı kütüphanenin farklı sürümlerini kullandığını fark etmek. Bu işlerin story point’i yok, demo’su yok. Bu yüzden kimse ödüllendirmiyor ve bu yüzden kimse yapmıyor.

Glue work’ü staff’ın tanımına açıkça yazmazsan iki şeyden biri oluyor: ya hiç yapılmıyor ya da ekibin en yardımsever kişisi yapıyor ve terfi değerlendirmesinde “teknik üretimi düşük” diye geri dönüyor. İkincisi daha kötü.

Görünür kılmak için küçük bir şey yaptık: staff’ın haftalık notuna ayrı bir “bağlayıcı iş” satırı ekledik. Üç madde, birer cümle. “Ödeme ekibinin açık olay aksiyonunu emir ekibine devrettim.” “İki ekibin HTTP istemcisini aynı sürüme çektik.” Tek başına küçük işler. Çeyrek sonunda alt alta okuyunca, en az iki olası olayın önünü kesmiş bir liste çıktı.

4. Neyin yapılmayacağına karar vermek

Düzeltmeden sonraki çeyrekte raporlama ekibi yeni bir mesaj altyapısına geçmek istedi. Tasarım staff’ın önüne incelemede geldi. Teknik olarak mantıklıydı. Staff mühendis bir sayfalık bir not yazdı: “Şimdi değil. Günlük mesaj hacmi 250 binin altında; mevcut kuyruk bunu taşıyor. 1,5 milyonu geçerse yeniden bakarız.” Bu not ekibe altı haftalık bir göçü kazandırdı. Hayır demenin gerekçesi ve yeniden bakma koşulu olmalı; bunu teknik strateji yazısındaki hayır listesinde anlatmıştım. Staff, o listeyi günlük kararlara taşıyan kişi.

Tech lead’den farkı

Tech lead bir ekibin teslimatının teknik sahibidir: sprint’in içindedir, ekibin kodu ve teknik kararları onun sorumluluğundadır. Staff ise tek bir ekibin değil, ekipler arasındaki boşluğun sahibidir. Tech lead “bu ekip nasıl teslim eder?” sorusuna bakar, staff “bu üç ekip neden aynı sorunu üç kez çözüyor?” sorusuna. Aynı kişi ikisini de yapabilir, ama aynı haftada ikisine birden tam vakit ayıramaz. Bu farkı ayrı bir yazıda açacağım.

Etki alanını nasıl seçtik

“Ekipler arası sorunlar” bir alan değil, bir kategori. Kişiye kategori verirsen her şeye bakar, hiçbir şeyi bitirmez. Alanın bir adı, bir sınırı ve bir ölçüsü olmalı. Seçerken üç soru sorduk:

1. Son iki çeyrekte hangi olaylar iki ekibin arasında kaldı? Olay kayıtlarını açtık. 11 olayın 5’i birden fazla ekibe dokunuyordu; 3’ü rezervasyon, 2’si hesap ekstresi.
2. Bu alanı zaten en iyi kim biliyor? Staff’ın alanı, bilgisinin zaten yoğun olduğu yerden başlamalı. Sıfırdan öğrenilecek bir alan ilk çeyreği yiyor.
3. Alan bir yılda küçülebilir mi? İyi bir alan zamanla daralır: sözleşmeler yazılır, ekipler kendi başına karar verebilir hâle gelir. Hiç küçülmeyen alan, bir ekibin işini staff’a yıktığın anlamına gelir.

Sonuçta alanın adı şu oldu: “emir ile para hareketleri arasındaki sözleşmeler”. Tek cümle, iki ekip, bir ölçü: bu sınırdan çıkan olay sayısı. Ekstre tarafını bilerek dışarıda bıraktık. İki alanı birden vermek, ilk denemede yaptığım “her yere bak” hatasının biraz daha kibar hâli olurdu.

Staff’ın haftası

Unvanı düzelttiğimiz hafta oturup bir takvim çizdik. Amaç saatleri kilitlemek değildi; “staff olarak ne yapıyorsun?” sorusunun cevabını görünür kılmaktı.

IS                                           SAAT    PAY
------------------------------------------------------------
Sprint isi (kritik yol DISINDA)               12     %30
Ekipler arasi sorun + yazili oneri            10     %25
Baska ekiplerin tasarim ve kod incelemesi      6     %15
Eslesme ve mentorluk                           5     %12
Glue work (olay takibi, dokuman, harita)       4     %10
Okuma, dusunme, bos zaman                      3      %8

# Kural 1: Sprint isi kritik yolda olmaz. Staff izne cikarsa
#          hicbir teslim tarihi kaymamali.
# Kural 2: "Bos zaman" satiri silinmez. Ekipler arasi sorunlari
#          fark etmek icin toplantisiz saat gerekir.

İlk ay bu tablo tutmadı. Sprint işi %30’da kalmadı, %45’e çıktı. Bu kez sebep ben değildim; ekip alışkanlığıydı. Zor bir iş gelince herkes yine ona bakıyordu. Çözüm basit oldu: sprint planlamasında staff’ın kapasitesini ayrı bir satır olarak yazdık ve o satır dolunca yeni iş almadı.

Nasıl olmalı, nasıl bozuluyor

Bir de ters yönde bozulma var: staff’ı her kararın onay kapısı yapmak. Bütün tasarımlar ondan geçiyorsa ekipler karar vermeyi bırakıyor ve staff yeni bir darboğaz oluyor. Hedef, onun yazdıklarına bakılarak onsuz doğru kararlar alınması.

Başarı nasıl ölçülür

O çeyrek değerlendirmesinde soru doğruydu, ama elimdeki ölçü yanlıştı. Onunla değerlendirseydim 64 story point’i başarı sayacaktım.

Kapasiteyi açıp alanı verdikten sonra ilk iş rezervasyon önerisi oldu. İki sayfa, iki ekip, 9 günlük yorum süresi, bir tane 40 dakikalık toplantı. Altı hafta sonra uygulamadaydı. Sonraki iki çeyrekte rezervasyon kaynaklı olay sayısı sıfır. Aynı dönemde kapattığı story point 64’ten 21’e düştü. Bu düşüşü ilk gördüğümde bir an tedirgin oldum — ta ki eski ölçüyle baktığımı fark edene kadar.

Yokluk testini de o dönemde yaptık, planlamadan. Staff mühendis iki hafta izne çıktı. Emir ekibinin sprint’i kaymadı, çünkü kritik yolda işi yoktu. Daha önemlisi, ödeme ekibi o iki haftada rezervasyon süresine dokunan bir değişiklik yaptı ve kimseye sormadı. Önerideki tabloya baktılar, doğru kararı verdiler. Staff’ın işe yaradığını en net orada gördüm: o yokken, onun yazdığı şey karar veriyordu.

Ne izlemeli?

Bende işe yaramayanlar

• Unvanı elde tutma aracı olarak vermek. Kişi kaldı, ama unvanın anlamı ekipte yedi ay boyunca “en kıdemli kodcu” oldu. Sonra düzeltmek, baştan doğru tanımlamaktan zor oldu.
• “Etki alanını kendin bul” demek. İlk düzeltmede kapasiteyi açtım ama alan vermedim. Üç hafta boyunca herkesin toplantısına girdi, hiçbir konunun sahibi olmadı. Alanın bir adı olmalı; adı olmayan alan, her yer demek.
• Her şeye yazılı öneri. Heves büyüktü: 11 haftada 14 öneri yazıldı, ortalama iki yorum aldı. Eşik koyduk: yalnızca birden fazla ekibi etkileyen ya da geri alınması bir sprintten uzun sürecek kararlar. Öneri sayısı düştü, okunma arttı.

Kontrol listesi

Sonuç

O Çarşamba sorduğum soru doğruydu, ama yedi ay geç gelmişti. Sorunun cevabını baştan ben belirlemiştim: ona bir etki alanı vermemiş, onu kapasitenin %100’üne yazmıştım. 64 story point, benim tanımımın dürüst bir çıktısıydı.

Staff unvanı “iyisin” demek değil. “Şu boşluk artık senin” demek. Boşluğun adını koymazsan, kişi en iyi bildiği şeye döner: kendi ekibinin sprint’ine.

Test şu: staff’ına “bu çeyrekte hangi sorunun sahibiydin?” diye sor. Cevap bir story point sayısıysa, sorun onda değil, sende.