Senior'dan Staff ve Principal'a Geçiş - Teknik Liderlik mi, Yöneticilik mi?
"Bir sonraki adımın ne?" sorusu Senior yazılımcılara çoğunlukla yöneticilik seçeneğiyle geliyor. Takım liderliği, mühendislik yöneticiliği, departman başkanlığı. Sanki kod yazmaya devam etmek kariyer durgunluğunun işaretiymiş gibi.
Bu bir yanılgı. Ve bu yanılgı, pek çok nitelikli yazılımcının kariyer kararlarını kötü veri üzerinden aldığı anlamına geliyor.
Senior sonrasında teknik etki büyütmek - Staff, Principal veya Lead Engineer unvanlarına giden yol - yöneticilikten farklı bir beceri seti, farklı bir tatmin kaynağı ve Türkiye'de giderek daha fazla somutlaşan bir kariyer kanalı.
İki Yol, İki Beceri Seti
Yöneticilik ile teknik liderlik sık sık birbirine karıştırılıyor. Bunun nedeni kısmen Türkiye yazılım sektöründeki unvan belirsizliği, kısmen de her iki rolün de "kıdemli" etiketini taşıması.
Fark temel düzeyde şu:
Yöneticilik - insanları, süreçleri ve takım dinamiklerini yönetmek. Performans görüşmesi yapmak, işe alım sürecini yürütmek, öncelikleri iş birimiyle müzakere etmek, ekip içi gerginlikleri çözmek. Teknik üretim zamanla arka plana çekiliyor.
Teknik liderlik - sistemleri, mimarileri ve teknik yönü şekillendirmek. Kodu hala yazıyorsun, ancak artık salt bireysel katkı değil: başkalarının daha iyi kod yazmasını sağlıyorsun, mimari kararları alıyor veya yönlendiriyorsun, teknik borcu şirket önceliği haline getiriyorsun.
Bu iki yolu tercih meselesine indirgemek de yanlış. Birini doğal olarak yapabileceğin, diğerini ise zorlanarak yapacağın bir yol var. Ve tercih ettiğin yol, kariyer memnuniyetini doğrudan etkiliyor.
"Yöneticilik Zorunlu" Yanılgısının Kaynağı
Türkiye'deki yazılım şirketlerinin büyük çoğunluğu 2010'lı yıllara kadar IC kıdem yolunu tanımlamamıştı. Yönetim hiyerarşisi netken teknik hiyerarşi belirsizdi. Bu düzen şu inancı doğurdu: ilerlemenin tek yolu insanları yönetmek.
Bu inanç hala yaygın, ama artık daha az geçerli. Sebepleri şunlar:
Yabancı şirket etkisi: Türkiye'de ofis açan ya da uzaktan istihdam eden yabancı şirketlerin getirdiği seviyelendirme sistemleri IC track'i görünür kıldı. Staff, Principal, Distinguished - bu unvanlar artık CV'lerde yer alıyor.
Büyüyen mühendislik organizasyonları: 50-200 kişilik yazılım takımlarında IC track hem organizasyonel hem ekonomik açıdan mantıklı hale geldi. Her kıdemli yazılımcıyı yöneticiye çevirmek ekibin teknik kapasitesini eritiyor.
Uzaktan çalışma: Yurtdışı şirketlerle çalışan yazılımcılar IC track normlarını Türkiye iş piyasasına taşıdı.
Staff ve Principal Seviyelerinde Ne Beklenir?
Unvanlar şirketten şirkete değişiyor. Ama beklentilerin özü oldukça tutarlı:
Staff Engineer (Kadro Mühendisi)
Katkın takım sınırlarını aşıyor. Birden fazla ekibi etkileyen teknik kararlarda sesini duyuruyorsun. Teknik yön belgelerini (RFC, ADR) yazıyor ya da inceliyorsun. Belirsiz, "kimin yapacağı belli olmayan" problemleri üstleniyorsun.
Principal Engineer
Katkın birden fazla ürün ya da alan kapsıyor. Şirketin teknik stratejisini etkiliyorsun. Diğer kıdemli mühendislerin çalışma biçimini değiştiriyorsun - mentorluk değil, mimari ve süreç üzerinden kaldıraç.
Her iki seviyede de kilit soru aynı: "Katkın seni olmayan birinin çalışmasını nasıl etkiliyor?"
Buna henüz yanıt veremiyorsan, plato devam edecek.
Teknik Etki Nasıl Büyütülür?
Soyut kavramları bir kenara bırak. Staff ve Principal seviyelerine giden yolda somut olarak ne yapılıyor?
Teknik dokümanlar yaz
RFC (Request for Comments) ya da ADR (Architecture Decision Record) formatında yazılmış teknik belgeler etkini görünür ve kalıcı hale getirir. Bir karar toplantıda alınıp unutulur. Yazi haline getirilince hem savunulabilir hem izlenebilir olur. Bu belgeleri yazan kişi genellikle kararı da şekillendiren kişi.
Belirsizliği üstlen
Senior seviyesinde çoğunlukla sınırları çizilmiş, tanımlanmış problemleri çözüyorsun. Staff ve Principal seviyesinde ise "bu problemi kim çözecek, nasıl çözülecek?" sorusunu soran ve yanıtlayan sen oluyorsun. Belirsizlikten kaçmak yerine ona yönelmek, bu geçişin işareti.
Çarpan ol
Bir özelliği tek başına yazmak ile altı kişinin daha iyi özellik yazmasını sağlamak arasındaki fark - işte bu fark teknik liderliğin özü. Kod incelemelerinde öğretici geri bildirim, iç teknik konuşmalar, paylaşılan araç ve altyapı - bunlar bireysel katkından daha büyük etki yaratır.
Alanlar arası köprü kur
Organizasyon büyüdükçe ekipler arasında teknik uyumsuzluklar birikir. Bir API diğeriyle tutarsız çalışır, bir veri modeli başka bir takımın mimarisine ters düşer. Bu köprü problemlerini gören ve çözen mühendisler Staff beklentisini karşılıyor.
Proaktif teknik borç yönetimi
Teknik borcu konuşmak kolay, önceliklendirmek zor. Product ve iş birimiyle teknik borcun maliyetini savunabilmek - bunu büyüme maliyetiyle, gecikmeyle, müşteri etkisiyle ilişkilendirmek - Staff seviyesinin iş tarafıyla diyalogu.
Hangi Yol Sana Uygun?
Bu soruya "ikisi de" ya da "emin değilim" cevabı veriyorsan, birkaç işaret seti seni yönlendirebilir.
Yöneticiliğe yatkınsın eğer:
- Takım dinamiklerini, iletişim sorunlarını çözmeyi teknik problemleri çözmekten daha tatmin edici buluyorsan
- İnsanların büyümesini takip etmek, kariyer görüşmeleri yapmak sana anlamlı geliyorsa
- Koddan uzaklaşmak seni çok rahatsız etmiyorsa
- Organizasyonel etki teknik etkinlikten daha önemli geliyorsa
Teknik liderliğe yatkınsın eğer:
- Kodu bırakmak gerçekten istemediğin bir şeyse
- Mimari problemler seni uyutmuyorsa (iyi anlamda)
- İnsanları yönetmek yerine sistemleri büyütmek daha tatmin edici geliyorsa
- Teknik derinliği genişliğe tercih ediyorsan
İkisini de düşünüyorsan, şu soruyu sor: son 6 ayda en çok tatmin olduğun iş anları hangileriydi? Teknik mi yoksa insani boyutlu muydu?
Terfi Dosyasını Nasıl Kurarsın?
IC track'te yükselmek için beklemenin bir anlamı yok. Terfi, kanıt birikimiyle başlar.
Etki günlüğü tut. Her hafta bir cümleyle şunu yaz: "Bu hafta takımın, ürünün ya da şirketin ne şekilde değişti?" Altı ay sonra bu günlük, terfi görüşmesinde somut argümanların ham maddesi.
Terfi matrisini öğren. Şirketinin Staff ya da Principal beklentileri yazılı mı? Varsa oku ve mevcut durumunla karşılaştır. Yoksa - bu senin görüşme konuşman.
Yöneticinle somut konuş. "Daha fazla etki yapmak istiyorum" vague. "Şu üç mimari alanda liderlik almak istiyorum, bunlar Staff beklentisiyle örtüşüyor mu?" - bu somut.
Görünür ol. Etki yaratmak yeterli değil, o etkinin görünmesi de gerekiyor. Şirket içi konuşmalar, teknik belgeler, çapraz takım işbirlikleri - bunlar görünürlük yaratır.
Mid'den Senior'a geçiş sürecini de incelediysen, orada kurduğun kanıt alışkanlığı burada da geçerli. Fark: Senior'dan Staff'a geçişte bireysel çıktı değil, organizasyonel etki kanıtlanıyor.
Maaş Farkı Ne Kadar?
Türkiye yazılım piyasasında Staff ve Principal unvanlarının maaş bandı Senior'dan ortalama yüzde 35-60 daha yüksek. Yabancı şirketlerde ya da yurtdışı uzaktan pozisyonlarda bu fark daha da açılıyor.
Ama sayı kadar önemli olan nokta şu: IC track'te ilerlemek, yöneticilik yapmak istemeyenler için kariyer tavanını fiilen kaldırıyor. Yöneticiliğe geçmeden de benzer ya da daha yüksek toplam pakete ulaşmak mümkün.
Maaş aralığını hesaplamak için deneyim, şehir ve sektör bazında veriye bakabilirsin.
Sonuç
Senior sonrası kariyer ikiye ayrılıyor: insanları yönetmek ya da teknik etkini büyütmek. İkisi de meşru, ikisi de değerli - ama ikisi farklı beceri setleri gerektiriyor.
"Yöneticilik zorunlu" inancı yerine şunu sor: hangisinde daha iyi olacaksın, hangisinden daha çok tatmin alacaksın?
Yanıtın teknik liderlik ise - Staff ve Principal yolu Türkiye'de de var. Önce görünür olmayı beklemeden etkini biriktir, terfi dosyanı kur, yöneticinle somut konuş.
Kariyer kararını veri üzerinden almak istiyorsan, getsalary.dev üzerinde deneyim ve unvan bazında maaş dağılımını inceleyebilirsin.