Teknik liderliğin zor tarafı çoğu zaman problemi görmek değil, gördüğü problemi kurumun karar diline çevirmektir. Mühendislik tarafında yüksek hata oranı, dar boğaz yaratan veritabanı kilitleri ya da yama gecikmeleri net birer risk sinyalidir. Fakat yönetim masasına geldiğinizde aynı başlıklar çoğunlukla bütçe, teslim tarihi, itibar, uyumluluk veya müşteri deneyimi ekseninde tartışılır. Aradaki köprü kurulmadığında teknik ekip haklı, yönetim de ikna olmamış olur.
Neden salt teknik dil yetmez?
Kurumsal yapılarda teknik liderin karşısındaki paydaşların hepsi aynı soyutlama seviyesinde çalışmaz. Operasyon müdürü hizmet kesintisinin yeniden yaşanıp yaşanmayacağını sorar. Finans tarafı riskin maliyetini duymak ister. Ürün tarafı takvim kaymasını bilmek ister. Siz ise “queue saturation”, “single AZ dependency” veya “sertifika rotasyonu eksik” diyorsunuzdur.
Bu ifadeler mühendislik için doğrudur ama karar üretmek için eksiktir. Çünkü yönetim teknik semptomu değil, semptomun iş etkisini değerlendirir.
İyi tercüme neyi değiştirir?
İyi risk tercümesi, teknik ayrıntıyı saklamaz; onu karar verilebilir hale getirir. Benim pratikte en faydalı bulduğum çerçeve dört sorudan oluşuyor:
- Risk bugün hangi sistem davranışında görünür hale geldi?
- Bu risk gerçekleşirse hangi iş sonucu bozulur?
- Riski küçültmek için hangi yatırım veya kısıt gerekiyor?
- Kararı geciktirmenin maliyeti nedir?
Bu yapı sayesinde “Redis failover testi yapılmadı” cümlesi, “ödeme akışında tek düğüm bağımlılığı var; kesinti tekrarlarsa yoğun saatte sipariş kaybı oluşur; iki sprintlik dayanıklılık yatırımı gerekir” cümlesine dönüşür.
Alarmı değil, karar yüzeyini anlatmak gerekir
Teknik liderler bazen çok fazla veri taşıyarak daha ikna edici olacağını düşünür. Oysa yönetim toplantısında amaç ham veri dökmek değil, doğru karar yüzeyini açmaktır. Bunun için risk notunu şu katmanlarda kurmak daha güçlü olur:
- Belirti: Şu anda ne görüyoruz?
- Etki: Bu durum neyi bozabilir?
- Olasılık: Yakın dönemde tekrar etme ihtimali nedir?
- Seçenek: Hangi yatırım veya taviz masada?
- Son tarih: Karar hangi pencere kapanmadan alınmalı?
Bu beşli, teknik borcu dramatize etmeden görünür kılar.
Yönetim için en işe yarayan ölçü birimleri
Her şeyi para ile konuşmak da her şeyi teknik skorlarla konuşmak kadar eksik olabilir. Kurum tipine göre aşağıdaki ölçüler daha işe yarar:
- Hizmet kesintisi tekrarlama olasılığı
- Kritik teslimat takvimine etkisi
- Uyumluluk veya denetim açığı oluşturma riski
- Operasyonel yükün birkaç kişide toplanması
- Müşteri güveni veya iç paydaş güveni kaybı
Örneğin sertifika yaşam döngüsü dağınıklığı, yalnızca güvenlik açığı değildir. Aynı zamanda gece müdahalesi ihtimalini artıran bir operasyon riski ve değişiklik hızını yavaşlatan bir teslim riski olabilir.
Kötü tercümenin iki yaygın biçimi
İlk hata, riski korku diliyle anlatmaktır. “Her an her şey olabilir” ifadesi teknik olarak bazen doğru hissettirse de karar üretmez. Çünkü önceliklendirme için göreli etki gerekir.
İkinci hata ise tam tersidir: riski fazlasıyla sterilize etmek. Burada da lider, teknik ayrıntıyı o kadar yumuşatır ki yatırım ihtiyacının gerçek ağırlığı kaybolur. Sonuçta yönetim hafif bir bakım işi duyduğunu sanır, ekip ise kırılgan bir altyapı ile çalışmaya devam eder.
Risk kaydı ile toplantı dili aynı olmalı
Tek seferlik sunumlar yerine yaşayan risk kaydı kullanmak büyük fark yaratır. Çünkü her yeni incident, audit bulgusu veya kapasite sorunu sıfırdan tartışılmaz; var olan risk envanterinde yerini bulur. Ben şu alanların özellikle faydalı olduğunu görüyorum:
- Risk başlığı ve açık teknik bağlam
- Etkilenen servis veya iş yeteneği
- Mevcut azaltıcı kontrol
- Açık kalan boşluk
- İstenen karar veya yatırım
- Sahip ekip ve gözden geçirme tarihi
Bu kayıt, teknik liderin her toplantıda aynı gerçeği farklı kelimelerle yeniden savunma yükünü azaltır.
Ne zaman yükseltmek gerekir?
Her teknik eksiklik yönetim seviyesine çıkmamalı. Yükseltme eşiği genelde şu durumda oluşur:
- Risk birden fazla ekip sınırına taşıyorsa
- Çözüm yerel backlog ile kapanmayacak kadar büyükse
- İş önceliği ile mühendislik gereksinimi arasında açık gerilim varsa
- Regülasyon, güvenlik veya itibar etkisi doğrudan görünüyorsa
Bu eşik oluştuğunda teknik liderin görevi daha çok alarm üretmek değil, kurumu seçime zorlamadan seçimsiz bırakmamaktır.
Sonuç
Teknik liderler için yönetime teknik risk tercümesi, sunum becerisi değil kurumsal mühendislik disiplinidir. Risk doğru çevrildiğinde yönetim teknik ekibin ne söylediğini daha net anlar, mühendislik de neden yatırım istediğini savunulabilir biçimde ortaya koyar. Kurumun olgunluğu da burada görünür: problemi en erken gören ekip ile kararı veren masa aynı cümlede buluşabildiğinde.