Terfi ettiğinizde herkes aynı şeyi söyler: "Artık iş insanlarla ilgili." Bir liderlik kitabı okuyun, daha iyi birebir görüşmeler yapın, delege etmeyi öğrenin. Bu tavsiyeler yanlış değil, ama asıl ilk kırılan şeyi ıskalıyor.
İlk kırılan şey, doğrulukla olan ilişkinizdir.
Sigorta rezerv hesaplama pipeline'ları ya da banka mutabakat işleri üzerinde çalışan kıdemli bir geliştirici olarak gerçeklikle basit bir sözleşmeniz vardı: kodunuz sabah 2'de çalışırdı, çıktının sahibi sizdiniz ve sabah 8'de bir şey yanlışsa onu siz düzeltirdiniz. Geri bildirim döngüsü dardı. Suçun yüzeyi küçüktü. SQL'i okur, bilirdiniz.
Yönetici olduğunuzda bu sözleşme dağılır. Artık geceleri ekibinizin kararları çalışıyor — onların join'leri, bir policy_status alanı hakkındaki varsayımları, bu çeyrekte "aktif müşteri"nin ne anlama geldiğine dair yorumları. Hâlâ siz sorumlusunuz ama bizzat sizin vermediğiniz değer yargılarından sorumlusunuz.
Gerçek geçiş budur. İnsan becerileri değil. Güven mimarisi.
Gerçekte neler değişir
İş biriminiz koddan kararlara kayar. Eskiden pull request gönderiyordunuz. Şimdi kapsam, tanımlar ve ödünleşimler hakkında kararlar gönderiyorsunuz — ve bu kararlar günler veya haftalar sonra başkaları tarafından, çoğu zaman öngöremediğiniz değişikliklerle hayata geçiriliyor. Genç bir analist "iptal edilen poliçeleri hariç tut" sözünü duyuyor ve önceki ekibinde böyle yapıldığı için, sessizce iptal edilenleri de listeden çıkarıveriyor.
Hata ayıklama yüzeyiniz patlar. Bir bug artık bir fonksiyonun içinde değildir. İş birimindeki bir paydaşın sözlü talebi, bir analistin yorumu, bir veri mühendisinin uygulaması ve bir dashboard tüketicisinin sonucu okuyuşu arasındaki devir teslimlerin içindedir. Dört çeviri katmanı, her biri kayıplı.
Zaman ufukları aynı anda hem uzar hem kısalır. Şimdi verdiğiniz stratejik kararlar, altı ay sonraki olay raporlarında karşınıza çıkar. Bu sırada bir düzenleyicinin belirli bir mutabakat farkı hakkındaki sorusuna gün sonuna kadar cevap vermeniz beklenir. Geliştiriciler sprint zamanında yaşar. Yöneticiler aynı anda iki saatte yaşar.
Yetkiniz müzakere edilebilir hale gelir. Geliştirici olarak kod üzerinde yetkiniz vardı. Bir Türk bankası ya da sigortacısında yönetici olarak ise neredeyse hiçbir konuda tek başınıza yetkiniz yoktur. Risk birimi maruziyetin bir tanımını ister. Finans bir başkasını. Aktüerya üçüncüsünü. Seçme şansınız yok — sadece aracılık etme şansınız var.
Neler değişmez (ve bu neden önemlidir)
Teknik taban yerinden kıpırdamaz. Tam tersine, daha da önemli hale gelir.
Düzenlemeye tabi finansal veride, pipeline'ı okuyamayan bir yönetici, bir şeyin yanlış olduğunda kokuyu alamayan bir yöneticidir. Olay incelemelerinde başını sallayıp duran yöneticiler gördüm; çünkü meşru bir açıklamayla, işini korumaya çalışan birinin kendinden emin tınılı uydurmasını birbirinden ayıramıyorlardı. Ekip kimin blöfle geçiştirilebileceğini hızla öğrenir.
Aynı kalan şeyler:
- Hâlâ kodu okumanız gerekir. Her gün yazmanız değil ama okumanız. Ay sonu işlerindeki mantığı örnekleme yoluyla kontrol edin. İmzalamadan önce düzenleyici raporun arkasındaki gerçek SQL'e bakın.
- Hâlâ veri alanını derinlemesine anlamanız gerekir. Bir IBNR rezervinin gerçekte ne olduğunu. FX yeniden değerleme zamanlamasının neden önemli olduğunu. Bir Solvency II veya BDDK raporunun kaynak sistemlere nasıl bağlandığını. Hiçbir framework sizi bundan kurtarmaz.
- Hâlâ "bu sayı bana doğru görünmüyor" diyebilen kişi olmanız gerekir. Veri kalitesinde örüntü tanıma işin yarısıdır ve sizden ekibinize aktarılamaz. Onu kendiniz keskin tutmak zorundasınız.
Mutabakat boşluğu
Yeni yöneticilerin yandığı yer tam burası: kodunuzun eskiden garanti ettiği şeyle ekibinizin kararlarının fiilen ürettiği şey arasında bir boşluk vardır ve bunu aktif olarak mutabık kılmak zorundasınız.
Somut bir örnek. Orta ölçekli bir sigorta şirketinin veri ekibini yönetmek üzere bir role giriyorsunuz. Selefiniz temiz görünümlü bir mimari bırakmış: dbt modelleri, dokümante edilmiş kaynaklar, dişe dokunur bir test seti. Üç ay sonra finans, aylık yönetim kurulu paketindeki hasar oranının iki çeyrektir yaklaşık 1,5 puan yanlış olduğunu işaret ediyor. Kazmaya başlıyorsunuz.
Pipeline çalışıyor. Testler geçiyor. Kod sağlam.
Sorun şu: dokuz ay önce bir ürün yöneticisi, poliçe yönetim sisteminde iptal iadelerinin kaydedilme şeklini değiştirmiş; ekibinizdeki bir analist bunu fark edip bir CASE ifadesini "ayarlamış"; kimse dokümantasyonu güncellememiş; aktüerya ekibi de mutabakatlarında eski tanımı kullanmaya devam etmiş. Her katman kendi içinde tutarlıydı. Sistem bir bütün olarak yalan söylüyordu.
Güven mimarisiyle kastettiğim şey budur. İşiniz artık kodu doğru kılmak değildir. İşiniz, koda gömülü varsayımların, çıktıyı kullanan insanların zihnindeki varsayımların ve iş dünyası gerçeğindeki varsayımların eşzamanlı kalmasını sağlamaktır. Bunlar birbirinden kaydığında — ki hep kayarlar — düzenleyiciden önce bunu öğrenmenin bir yoluna sahip olmanız gerekir.
Pratikte bu nasıl görünür
Düzenleyici ortamın bağışlayıcı olmadığı ve araç setinin sanıldığından daha az olgun olduğu Türk finans ve sigorta bağlamında işe yaradığını gördüğüm birkaç şey:
- Tanımları sahipleriyle birlikte yazıya dökmeye zorlayın. Kimsenin okumadığı bir wiki değil. "Aktif poliçe"nin tek bir tanımının, onaylayan tek bir iş sahibinin ve bir tarihin bulunduğu kısa, sürümlenmiş bir doküman. Değiştiğinde, görünür biçimde değişsin.
- Aylık bir "varsayım sapması" gözden geçirmesi yapın. Üst yönetime ya da düzenleyicilere giden üç sayıyı seçin. Her birini kaynağa kadar geriye doğru izleyin. Her çeyrekte en az bir sürprizle karşılaşacaksınız. Bunu denetçinin değil sizin bulmanız daha iyidir.
- Bir ayağınızı kodda tutun. Yasal raporlamayı etkileyen her şeyin SQL'ini hâlâ ben gözden geçiriyorum. Ekibim yapamadığı için değil — yapabilirler — onu okumak, gerçekten ne bildiğimiz ile neyi varsaydığımız konusunda beni dürüst tuttuğu için.
- Devir teslimleri asıl ürün olarak ele alın. Dashboard'daki sayı teslim edilen şey değildir. Onu hazırlayan analist ile onu okuyan yönetici arasındaki ortak anlayış teslim edilen şeydir. Mühendisliği buna göre yapın.
Kimsenin söylemediği kısım
Bu geçişin sessiz kısmı şu: yaklaşık bir yıl boyunca kendinizi daha az yetkin hissedeceksiniz. Eskiden ticket kapatıyordunuz. Şimdi neredeyse görünür hiçbir şey kapatmıyorsunuz. İş, yukarı akışta — gerçekleşmeyen olayı önlemek, başlamadan kötü projeyi öldürmek, yönetim kurulu paketine ulaşmadan önce tanım sapmasını yakalamak.
Bunların hiçbiri bir commit geçmişinde görünmez.
Bu geçişi iyi yapan geliştiriciler, kendilerini çıktıyla ölçmeyi bırakıp ekiplerinin neyi yanlış yapmadığıyla ölçmeye başlayanlardır. Bununla yaşamak daha zor bir metriktir ama işe uyan tek metrik budur.