Birçok kurumda escalation kelimesi hâlâ başarısızlık çağrışımı taşıyor. Bir ekip başka bir ekibi sürece dahil ettiğinde, konuşma çoğu zaman teknik riski küçültmekten çok “neden daha erken fark edilmedi” tartışmasına kayıyor. Bu kültürün doğal sonucu, ekiplerin yardım istemeyi geciktirmesi oluyor. Teknik lider için asıl iş, escalation kararını kişilerden bağımsızlaştırmak ve bunu blameless bir çalışma kuralına dönüştürmektir.
Blameless escalation neden ayrı bir liderlik konusu?
Çünkü incident yönetimindeki en pahalı gecikmeler genellikle teknik karmaşıklıktan değil, sosyal friksiyondan çıkar. Ekip sinyalin büyüdüğünü görür ama başka bir ekibi çağırmak için çok bekler. Bunun nedeni çoğu zaman yeterli telemetry değil, “erken çağırırsam panik yaratmış olur muyum” endişesidir.
Blameless çerçeve bu belirsizliği azaltır. Escalation kararı kişisel cesarete veya kıdeme değil, önceden tanımlanmış eşiklere dayanır. Böylece süreç, yardım isteme psikolojisini değil, risk paylaşım disiplinini yönetir.
Hangi eşikler önceden tanımlanmalı?
Ben sahada dört eşiğin açık yazılmasını çok değerli buluyorum:
- Müşteri etkisi başladıysa ya da başlamak üzereyse
- Runbook dışı adım gerektiren teknik belirsizlik oluştuysa
- Tek ekip içinde çözülemeyecek bağımlılık açığa çıktıysa
- Müdahale süresi hizmet hedefini tehdit etmeye başladıysa
Bu maddeler basit görünür; ama net yazılmadığında her ekip kendi toleransına göre davranır. Sonuçta aynı risk seviyesinde iki farklı tepki doğar.
Suçlayıcı olmayan süreç pratikte nasıl kurulur?
İlk kural şudur: escalation, “hata yaptık” cümlesinin kurumsal karşılığı değildir. Daha doğru cümle, “risk artık daha geniş koordinasyon gerektiriyor” olmalıdır. Bu dil farkı küçüktür ama müdahale hızını doğrudan etkiler.
İkinci kural, sürecin toplantı anında icat edilmemesidir. Rollerin baştan belirlenmesi gerekir:
- Olay komutası kimde kalır?
- Hangi ekipler hangi sırayla çağrılır?
- Kim teknik karar kaydını tutar?
- Kim dış iletişim özetini üretir?
Bu netlik yoksa escalation, çözüm hızlandıran mekanizma olmaktan çıkıp kaotik bir yayın listesine döner.
Teknik liderin dili neden belirleyici?
Teknik liderler olay anında sadece karar vermez; olayın nasıl hissedildiğini de belirler. “Neden daha önce haber vermediniz?” sorusu birkaç saniyede tüm kültürü zehirleyebilir. Bunun yerine şu sorular daha sağlıklıdır:
- Hangi sinyal bu eşiği geçti?
- Şu anda hangi bağımlılık bizi yavaşlatıyor?
- Hangi uzmanlık eksik olduğu için kapsamı genişletiyoruz?
Bu yaklaşım, kişileri değil sistemi görünür kılar. Özellikle kıdemli mühendisler için bu dil modeli mentorluk etkisi de üretir; genç mühendisler yardım istemenin kariyer riski olmadığını görür.
Escalation sonrası hangi kayıtlar tutulmalı?
Blameless kültürün kalıcı olması için süreç sonrasında üç kayıt mutlaka oluşmalıdır:
- Eşik gerçekten doğru yerde mi tetiklendi?
- Daha erken tetiklenebilseydi ne değişirdi?
- Hangi runbook, alarm veya sahiplik boşluğu bu ihtiyacı doğurdu?
Burada amaç savunma hazırlamak değil, eşikleri zamanla iyileştirmektir. Aksi halde ekipler aynı tartışmayı sonraki olayda tekrar yaşar.
Kurumsal yapılarda en sık görülen anti-pattern
Bazı kurumlar escalation matrisini çok ayrıntılı yazar ama gerçek hayatta kimsenin açıp okuyamayacağı kadar ağır hâle getirir. Bazıları ise tamamen sezgiye bırakır. İki uç da sorunludur. İyi model, birkaç net eşik ve birkaç net rol üzerinden çalışır.
Bir başka hata da escalation’ı yalnızca kritik olaylara ayırmaktır. Oysa orta şiddette tekrar eden olaylar için erken koordinasyon kurulmazsa aynı desen ileride daha pahalı patlar. Teknik liderin görevi sadece yangın anında bağırmak değil, koordinasyonun geç kalma maliyetini düşürmektir.
Sonuç
Teknik liderler için blameless escalation çerçevesi, incident yönetiminin iletişim katmanını olgunlaştırır. Eşikler açık, roller net ve dil suçlayıcı değilse ekipler daha erken yardım ister, daha sakin karar alır ve bilgi daha düzenli akar. Kurumsal ölçekte gerçek hız, kahramanlıktan değil doğru anda doğru kişileri devreye sokan güvenli süreçlerden çıkar.