Platform dönüşümü konuşulurken çoğu kurum araç listesini, internal developer platform’u veya self-service katalogları öne çıkarıyor. Fakat dönüşümün asıl kırıldığı yer teknoloji seçimi değil, aynı değişimi farklı ekiplerin farklı anlamasıdır. Operasyon ekibi risk kontrolü görür, ürün ekibi hız baskısı hisseder, yönetim ise maliyet ve görünürlük ister. Teknik liderin değeri tam burada ortaya çıkar: aynı dönüşümü bu grupların anlayacağı ortak bir dile çevirmek.
Neden çeviri rolü diyorum?
Çünkü platform dönüşümünde en sık görülen problem teknik yanlışlık değil, semantik kopukluktur. “Golden path”, “guardrail”, “self-service” veya “platform ownership” gibi ifadeler farklı ekiplerde farklı çağrışımlar üretir. Teknik lider bu kavramları soyut bırakırsa dönüşüm dirençle karşılaşır.
İyi teknik lider şunu yapar:
- Mühendislik kararını iş etkisine bağlar.
- Operasyon kaygısını hız düşmanlığı gibi göstermeden açıklar.
- Ürün ekibine yeni sınırların nedenini anlatır.
- Yönetim tarafına ölçülebilir kazanımı sade dille sunar.
Dönüşüm neden genelde toplantılarda yavaşlar?
Çünkü aynı masa etrafındaki herkes aynı kelimeleri kullanıyor gibi görünse de aynı problemi konuşmaz. Örneğin bir platform ekibi “standart pipeline” dediğinde ürün ekibi bunu ek özgürlük kaybı olarak okuyabilir. Operasyon ekibi ise kontrol mekanizması olarak görebilir. Teknik lider burada yalnızca moderatör değildir; kavram çakışmalarını açığa çıkarmak zorundadır.
Hangi konular en çok çeviri gerektirir?
Benim sık gördüğüm başlıklar şunlar:
- Ortak CI/CD akışları
- Erişim ve kimlik politikaları
- Observability zorunlulukları
- Platform ekiplerinin hizmet seviyesi beklentileri
- İstisna yönetimi ve mimari yönetişim
Bu başlıklarda dil netleşmediğinde teknik olarak doğru karar bile gereksiz direnç üretir.
Peki bu çeviri pratikte nasıl yapılır?
Benim etkili bulduğum yöntem üç katmanlıdır:
- Önce kavramı sadeleştiririm: örneğin “guardrail”, hata yapmayı zorlaştıran güvenli varsayılanlar demektir.
- Sonra ekip bazlı etkisini ayırırım: ürün ekibi için hız, operasyon için kontrol, yönetim için ölçülebilirlik.
- Son olarak sınırları netlerim: bu model hangi iş yükleri için geçerli, hangi durumda istisna var?
Bu yöntem, teknik belirsizliği yönetişim tartışmasına dönüşmeden yönetmeyi sağlar.
Mentorluk boyutu neden önemli?
Platform dönüşümü yalnızca kıdemli mühendislerin değil, daha genç ekip üyelerinin de günlük çalışma modelini değiştirir. Bu noktada teknik liderin mentorluk rolü devreye girer:
- Neden yeni akışa geçildiğini anlatmak
- İstisna istemenin meşru sınırlarını öğretmek
- Runbook ve ownership kültürünü görünür kılmak
- Sürekli şikâyet edilen değil, sürekli açıklanan liderlik pratiği göstermek
Bu davranışlar olmadan dönüşüm “yukarıdan gelen süreç” gibi algılanır.
Başarılı olduğunuzu nasıl anlarsınız?
İyi sinyaller genelde şunlardır:
- Ekipler yeni platform akışını başkalarına savunmaya başlar.
- İstisna talepleri daha net ve gerekçeli gelir.
- Incident sırasında ortak kelime dağarcığı oluşur.
- Yönetim toplantılarında platform yatırımı araç listesi yerine çıktı metrikleriyle anlatılır.
Sonuç
Platform dönüşümünde teknik liderin çeviri rolü, çoğu zaman görünmez ama belirleyici bir yetkinliktir. Çünkü kurumsal mimarilerde dönüşüm yalnızca sistemleri değil, insanların birlikte çalışma şeklini de değiştirir. Ortak dil kurulmadan ortak platform kurulmuş sayılmaz. Kıdemli mühendislik pratiğinde kalıcı etki yaratmak isteyenler için en güçlü kaldıraçlardan biri tam olarak budur.