@ahmetcantryk
Bir mühendis Senior seviyesinde iki yıl takılı kalabilir; kod kalitesi tartışmasız, teslimatlar zamanında, ama terfi bir türlü gelmez. Staff engineer'a geçişi tetikleyen şey genelde daha iyi kod değil, daha önce hiç yazmadığı bir belge türüdür: bir RFC, bir tasarım dokümanı, ekipler arası bir teknik strateji metni. Bu yazı o geçişin nasıl göründüğünü ve neden kod yazmaktan çok yazı yazmakla ilgili olduğunu anlatıyor.
Staff ne anlama gelir?
Staff engineer, raporu olmayan bir teknik liderlik rolüdür. Senior seviyesinde bireysel çıktınız için ücretlendirilirsiniz; Staff'ta ise etkinizin kaldıraç gücü (leverage) için ücretlendirilirsiniz — tek başınıza ne yazdığınız değil, bütün bir ekibi veya sistemi ne kadar iyileştirdiğiniz önem kazanır. Bu net bir zihniyet değişikliği gerektirir: artık "en iyi kodu ben mi yazdım" sorusu değil, "bu karar doğru mu ve ekip bu kararı uygulayabilecek mi" sorusu merkeze oturur.
2026 itibarıyla büyük teknoloji şirketlerinde Staff seviyesinin toplam ücret paketi 400 bin ile 800 bin dolar arasında değişiyor; farkın büyük kısmı hisse senedi ve prim bileşenlerinden geliyor, taban maaştan değil. jobsbyculture'ın 2026 Staff Engineer kariyer rehberi bu aralığı doğruluyor ve ekliyor: Staff, bireysel katkıcı (IC) çizgisinin bir uzantısı, yönetim çizgisine geçiş değil. Ama bu yazının odağı ücret değil — o kadar geniş bir aralığın arkasındaki sorumluluk farkı.
Dört Staff arketipi
Staff rolleri tek bir kalıba sığmaz. Pratikte dört arketip öne çıkıyor:
- Tech lead: Bir ekibin veya birkaç ekibin teknik yönünü belirler, günlük kararlara yakın durur.
- Mimar (architect): Sistemler arası tutarlılığı sağlar, uzun vadeli teknik borç ve platform kararlarına odaklanır.
- Çözücü (solver): Şirketin en zor, en belirsiz teknik problemlerine atanır; genelde kısa süreli ama yüksek etkili görevler alır.
- Sağ kol (right hand): Bir üst düzey lidere (CTO, VP Engineering) yakın çalışır, onun stratejik önceliklerini teknik gerçekliğe çevirir.
Hangi arketipe uyduğunuzu bilmek, kapsamınızı nasıl göstereceğinizi netleştirir. Bir mimar için kapsam kanıtı bir platform migrasyonu olabilirken, bir çözücü için kapsam kanıtı krizde çözdüğü tek bir zor problem olabilir. Arketipler birbirini dışlamaz; kariyeriniz boyunca birinden diğerine geçmeniz, hatta aynı anda ikisini harmanlamanız gayet normal.
Kapsamı nasıl gösterirsiniz
Staff kapsamı, ekipler arası kapsam demektir. Tek bir takımın sınırları içinde ne kadar mükemmel çalışırsanız çalışın, bu Senior seviyesinin tavanıdır. Kapsamı kanıtlamanın en güvenilir yolu, birden fazla ekibi etkileyen projelere gönüllü olmaktır: migrasyonlar, paylaşılan altyapı iyileştirmeleri, platform yatırımları. Staff mühendislerin değerini kanıtladığı yer tam olarak burasıdır — çünkü bu tür projeler doğası gereği net bir "sahip"e sahip değildir ve birinin adım atıp koordinasyonu üstlenmesi gerekir.
Görünürlük problemi: neden iyi mühendisler takılı kalır
StaffEng.com'un topladığı düzinelerce Staff mühendis röportajında tekrar eden bir tema var: terfi engelinin çoğu zaman teknik yetersizlikten değil, görünürlük eksikliğinden kaynaklandığı. Bir mühendis tek başına mükemmel iş çıkarabilir, ama bu iş organizasyonun geri kalanına görünmüyorsa terfi komitesi için "kanıt" oluşturmaz. Bu röportajların ortak bulgusu şu: Staff'a geçen mühendislerin neredeyse tamamı, bir noktada bilinçli olarak kendi işlerini görünür kılmanın bir yolunu bulmuş — bir dahili blog yazısı, bir sunum, bir RFC ya da düzenli bir durum güncellemesi.
Bu, kibirli bir "kendini pazarlama" tavsiyesi değil; kapsamınızı gösterecek bir kayıt bırakmamanın maliyeti terfi zamanı geldiğinde ortaya çıkıyor. Terfi komitesi genelde sizinle birebir çalışmamış insanlardan oluşur; onların elinde olan tek şey yazılı kayıtlardır. Bu yüzden görünürlük, iddia edilen bir şey değil, biriktirilen bir şeydir — her sprint sonunda kısa bir özet paylaşmak bile, aylar sonra terfi paketinizin omurgasını oluşturabilir.
Sponsorluk mentorluktan farklıdır
Mentorluk size tavsiye verir; sponsorluk sizin adınıza konuşur. Bir sponsor, siz odada değilken terfi tartışmasında adınızı öne çıkaran, kapsamınızı büyütecek projelere sizi öneren kişidir. Staff'a giden yolda ihtiyacınız olan şey daha fazla mentor değil, en az bir güçlü sponsordur — ve sponsorluk kazanılır, istenmez. Görünür, ekipler arası etkisi olan işler yaptığınızda sponsorlar kendiliğinden ortaya çıkar.
RFC/tasarım dokümanı alışkanlığı: en yüksek kaldıraçlı sinyal
Burada asıl mesele şu: Staff terfisi için tek bir en yüksek kaldıraçlı beceri varsa, o kod değil yazıdır. Karmaşık teknik fikirleri yazıyla net biçimde iletebilme yeteneği, Staff terfisinin en hafife alınan becerisidir. Staff'a ulaşan mühendisler, bir teknik vizyonu ekipleri hizalayacak, liderliği ikna edecek ve başkalarının uygulayabileceği bir yol haritası sunacak şekilde ifade edebilenlerdir.
Bu yüzden bugünden RFC'ler, tasarım dokümanları ve teknik strateji belgeleri yazmaya başlamak somut bir tavsiye. Bu sadece belge üretmek değil; mimari incelemelere liderlik etmek ve bazen uzun vadede sorun yaratacak yaklaşımlara "hayır" diyebilmek anlamına geliyor. RFC yazmanın kendisi ayrı bir beceri; nasıl bir şablon kullanacağınızı ve tartışmaları nasıl kapatacağınızı mühendislik RFC'si nasıl yazılır yazımızda ayrıntılı ele aldık.
Staff terfi sinyalleri: kontrol tablosu
Sinyal | Senior seviyesinde görünüm | Staff seviyesinde görünüm |
|---|---|---|
Kapsam | Tek ekip, net sınırlar | Birden fazla ekip, belirsiz sınırlar |
Yazılı iletişim | Kod yorumları, PR açıklamaları | RFC'ler, tasarım dokümanları, strateji notları |
Karar verme | Verilen görevi uygular | Hangi problemin çözüleceğine karar verir |
İlişki ağı | Doğrudan ekip arkadaşları | Skip-level, akran liderler, çapraz fonksiyon ortakları |
Terfi mekanizması | Performans değerlendirmesi | Sponsorluk + görünür kapsam kanıtı |
90 günlük terfi vakası oluşturma planı
Terfi vakası bir gecede oluşmaz ama 90 gün, somut bir başlangıç için yeterli:
- 1-30. gün: Ekipler arası etkisi olan, kimsenin sahiplenmediği bir problemi belirleyin. Bunun için bir RFC taslağı yazmaya başlayın.
- 31-60. gün: RFC'yi paydaşlarla paylaşın, geri bildirim toplayın, kararı belgeleyin. Paralelde en az bir potansiyel sponsorla düzenli check-in kurun.
- 61-90. gün: Kararı uygulamaya başlayın veya başkalarının uygulamasına liderlik edin. İlerlemeyi ve etkiyi ölçülebilir şekilde kayıt altına alın — terfi paketinizin ham malzemesi budur.
Benim gözlemim şu: Staff'a takılan mühendislerin çoğu teknik olarak yetersiz değil, görünür değil. Kod her zaman konuşur ama yeterince uzağa konuşmaz; yazı, sizin olmadığınız odalarda sizin adınıza konuşur.
Terfi vakanızı güçlendiren bir diğer unsur da, kapsam kanıtınızı maaş görüşmesinde kullanabilmenizdir; dokümante ettiğiniz etki metrikleri iki sürecin de ham malzemesidir. Bu bağlantıyı 2026'da yazılımcı maaş pazarlığı yazımızda daha ayrıntılı ele aldık.
Sıkça Sorulan Sorular
Staff engineer olmak için yönetici olmam gerekir mi?
Hayır. Staff, bireysel katkıcı (IC) yolunun bir uzantısıdır; raporlarınız olmaz. Etkiniz insanlar üzerinden değil, teknik kararlar ve kapsam üzerinden ölçülür.
RFC yazmak gerçekten terfi için bu kadar önemli mi?
Evet, çünkü RFC'ler kapsamınızı ve karar alma yeteneğinizi kayıt altına alan tek somut kanıttır. Sözlü tartışmalar unutulur; yazılı bir RFC, terfi komitesinin inceleyebileceği kalıcı bir sinyaldir.
Sponsor bulamıyorsam ne yapmalıyım?
Önce görünür olun. Ekipler arası etkisi olan bir problemi çözün ve bunu yazılı olarak paylaşın; sponsorlar genelde görünür işe kendiliğinden çekilir. Sponsorluk istemek yerine, sponsorluk almaya değer iş üretmeye odaklanın.
Staff seviyesine ne kadar sürede ulaşılır?
Değişken, ama tipik olarak Senior'dan sonra 2-4 yıl arası bir aralık görülüyor. Süre, kapsam gösteren projelere ne kadar erken gönüllü olduğunuza ve yazılı iletişim alışkanlığını ne kadar erken kurduğunuza bağlı. Daha fazla kariyer rehberi için kariyer ve üretkenlik kategorimize göz atabilirsiniz.
