Tech Şirketlerinde Kariyer Seviyeleri - Entry'den Distinguished Engineer'a

Özet

Tech şirketlerindeki kariyer seviyeleri, özellikle şirket değiştirirken veya terfi planlarken mühendisleri sıklıkla kafasını karıştırıyor. Bu rehber, Amazon, Google, Meta, Microsoft, Spotify ve Zalando’daki kariyer seviyelerini inceliyor, eşdeğer seviyeleri eşleştiriyor ve her seviyenin scope, özerklik ve impact açısından ne anlama geldiğini açıklıyor. Terfilerde gezinme, Staff-level iş bulma ve kariyer yolu hakkında bilinçli kararlar verme konusunda pratik içgörüler paylaşacağım.

Seviye Karmaşası Problemi

Mühendislerle kariyer ilerlemesi hakkında konuştuğumda aynı sorular geliyor: “Amazon’da L6’yım - Google’da hangi level olurdum?” veya “Bir sonraki seviyede çalışmak tam olarak ne demek?” Bunlar basit sorular değil. Bir şirketteki Senior Engineer, başka bir şirkette Mid-Level olarak görüşme yapabilir, daha az yetenekli oldukları için değil, şirketler seviyeleri farklı kalibre ettiği için.

Kariyer kararları verirken karmaşa daha da artıyor. Staff için mi zorlamalısın yoksa Senior’da kalmak geçerli bir seçenek mi? IC vs Management karar noktası ne zaman gelir? Ekibinde sadece feature work varken Staff-level scope’u nasıl bulursun?

Bu sistemleri anlamak, terfi peşinde olsan, şirket değiştirsen veya uzun vadeli kariyer yolu kararları verirken kariyerinde stratejik olarak gezinmene yardımcı oluyor.

Büyük Şirketler Seviyeleri Nasıl Yapılandırıyor

Standart Framework

Çoğu büyük tech şirketi individual contributor’lar için 5-7 seviye kullanıyor, ancak farklı şekilde isimlendiriyor ve numaralandırıyorlar. Büyük şirketlerin birbirine nasıl eşlendiği:

Şirkete Göre Seviye İsimleri:

Seviye	Amazon	Google	Meta	Microsoft
Entry	L4	L3	E3	59-60
Mid-Level	L5	L4	E4	61-62
Senior	L6	L5	E5	63-64
Staff	L7	L6	E6	65-67
Sr Staff	L8	L7	E7	68-69
Principal	L10*	L8	E8	70+

*Amazon L9’u atlıyor

Seviye Eşleştirme Tablosu

Deneyim	Amazon	Google	Meta	Microsoft	Tipik Yıl
Entry	L4 (SDE I)	L3 (SWE II)	E3 (SWE II)	59-60 (SDE I)	0-2 yıl
Mid-Level	L5 (SDE II)	L4 (SWE III)	E4 (SWE III)	61-62 (SDE II)	2-5 yıl
Senior	L6 (Senior)	L5 (Senior)	E5 (Senior)	63-64 (Senior)	5-8 yıl
Staff	L7 (Principal)	L6 (Staff)	E6 (Staff)	65-67 (Principal)	8-12 yıl
Sr Staff	L8 (Sr Principal)	L7 (Sr Staff)	E7 (Sr Staff)	68-69 (Partner)	12-15 yıl
Principal	L10 (Distinguished)*	L8 (Principal)	E8 (Principal)	70+ (Distinguished)	15+ yıl
Distinguished	-	L9 (Distinguished)	E9 (Distinguished)	-	20+ yıl
Fellow	-	L10 (Google Fellow)	E10 (Fellow)**	-	Nadir
Sr Fellow	-	L11 (Sr Google Fellow)	-	-	Son Derece Nadir

*Amazon L9’u deliberately atlıyor, L4→L5→L6→L7→L8→L10 şeklinde ilerliyor

**Meta E10 istisnai derecede nadir - şirket genelinde 5’ten az kişi

Önemli Not: Bu eşleştirmeler yaklaşıktır. Şirketler farklı kalibre eder ve gerçek seviyeniz görüşmelerde gösterdiğin scope ve impact’e bağlıdır, sadece mevcut unvanına değil.

Spotify’ın Alternatifi: Steps Framework

Spotify, hiyerarşik seviyeler yerine impact’e odaklanan “Steps” framework’ü ile farklı bir yaklaşım benimsiyor:

1. Individual Step: Yakın ekibindeki impact
2. Squad/Chapter Step: Birden fazla squad veya teknik domain’deki impact
3. Tribe/Guild Step: Daha büyük organizasyonel birimlerdeki impact
4. Technology/Company Step: Tüm şirket veya endüstri çapında impact

Temel fark: Step’ler private kalıyor ve compensation band’leri step’ler arasında overlap edebiliyor. Bu, title takıntısını azaltıyor ve gerçek katkıya odaklanıyor. Squad Step’teki bir mühendis, impact’i haklı kılıyorsa Tribe Step’tekinden daha fazla kazanabilir.

Her Seviye Pratikte Ne Anlama Geliyor

Seviye numaralarını anlamak bir şey; pratikte ne anlama geldiklerini anlamak başka bir şey. Scope, özerklik ve impact’teki gerçek farkları açıklayacağım.

Entry Level (L4/E3/L3)

Scope: Tek bir service veya feature area içindeki bireysel componentler.

Özerklik: Detaylı specification’lar alırsın ve yakın mentorship ile çalışırsın. Tech lead’in veya senior engineer’ın implement etmeye başlamadan önce yaklaşımını review eder.

Impact: İşin tek bir feature veya component’i etkiler, yakın ekibini etkiler.

Örnek Task: “Kullanıcı dashboard’undaki pagination bug’ını düzelt, sonuçları filtrelediğinde sayfa sayacı yanlış gösteriliyor.”

Bug report’u, mevcut kod context’i ve genellikle nereye bakman gerektiği konusunda spesifik rehberlik alırsın. Odağın iyi tanımlanmış task’ları execute etmek ve codebase’i öğrenmek.

Mid-Level (L5/E4/L4)

Scope: Frontend ve backend’i kapsayan, bazen birden fazla service’e dokunan complete feature’lar.

Özerklik: Teknik specification’ları bağımsız olarak oluşturursun ve PM/design ile sürekli gözetim olmadan collaborate ediyorsun. Feature alanında implementation kararları alırsın.

Impact: Birden fazla ekibi etkileyen cross-functional feature’lar. Diğer mühendisler senin API’lerine veya componentlerine depend eder.

Örnek Task: “Kullanıcıların hangi alert’leri alacaklarını ve hangi kanallardan alacaklarını özelleştirmelerine izin veren notification tercihleri sistemini oluştur.”

Product ile requirement’ları anlamak için çalışırsın, API’yi tasarlarsın, hem frontend hem backend implement edersin ve notifications service ekibi ile koordine olursun. Data model’ler, API design ve error handling hakkında kararlar alırsın.

Senior Level (L6/E5/L5)

Scope: Birden fazla service ve ekibi etkileyen sistem çapında iyileştirmeler. Teknik borç azaltma, güvenilirlik iyileştirmeleri veya mimari değişiklikler.

Özerklik: Problem alanlarını tanımlarsın, çözümler önerirsin ve minimal yönlendirme ile implementation’ı drive edersin. Alanın için teknik standartları belirlersin.

Impact: Tüm engineering ekiplerini etkileyen organizasyonel impact. Kararların diğer mühendislerin sistemleri nasıl build ettiklerini etkiler.

Leadership: 2-3 mühendise mentorship yaparsın ve hiring’e katılırsın. Diğer ekiplerden design’ları review edersin ve mimari rehberlik sağlarsın.

Örnek Task: “Service güvenilirliğini %99.5’ten %99.9 uptime’a iyileştir.”

Mevcut sistemi analiz edersin, failure mode’larını identify edersin, monitoring iyileştirmeleri önerirsin, circuit breaker’lar implement edersin, alerting kurarsın ve değişiklikleri deploy etmek için birden fazla ekiple koordine olursun. “Done”ın ne anlama geldiğini tanımlarsın ve başarıyı ölçersin.

Staff Level (L7/E6/L6)

Scope: Birden fazla ekibi ve quarter’ı kapsayan cross-organizational teknik inisiyatifler.

Özerklik: Büyük inisiyatifler için teknik direction belirlersin. Kimse sana specification vermiyor - neyin build edilmesi gerektiğini sen tanımlıyorsun.

Impact: 50+ mühendisi etkileyen company-wide infrastructure. Mimari kararların organizasyonun neyi build edebileceğini enable eder veya kısıtlar.

Leadership: Birden fazla ekip için technical lead. Teknik standartlar ve best practice’leri establish edersin. Hiring stratejisini ve ekip yapısını influence edersin.

Örnek Task: “Global genişlemeyi desteklemek için multi-region data replication stratejisini tasarla ve implement et.”

Option’ları değerlendirirsin (active-active vs active-passive, consistency requirement’ları, conflict resolution), RFC oluşturursun, infrastructure ve product ekiplerinde consensus build edersin, 2-3 quarter boyunca 5+ ekip arasında implementation’ı koordine edersin ve başarılı rollout’u ensure edersin.

Principal ve Ötesi (L8+/E7+/L7+)

Scope: Tüm şirketin mimarisini etkileyen multi-year stratejik teknik direction.

Özerklik: Tam bağımsızlık. Organizasyonel priority’leri belirlersin ve teknik constraint’ler ve fırsatlara göre product roadmap’lerini influence edersin.

Impact: Endüstri seviyesinde etki. Kararların 500+ mühendisi ve muhtemelen open source veya standard’lar aracılığıyla harici topluluklarını etkiler.

Leadership: Organizasyon için teknik vizyon. Conference’lar, paper’lar veya open source katkıları aracılığıyla harici thought leadership.

Örnek Task: “Şirketin monolith’ten microservices mimarisine geçişini tanımla.”

Mevcut monolith’i analiz edersin, service extraction için boundary’leri identify edersin, migration stratejisi oluşturursun, executive leadership ile consensus build edersin, 2-3 yıl boyunca tüm engineering organizasyonunda implementation’ı koordine edersin ve şirket standardı haline gelen pattern’leri establish edersin.

Terminal Level’ları Anlamak

Birçok mühendis şunu fark etmiyor: çoğu şirket, tüm kariyer boyunca kalman beklenen spesifik seviyeler tasarlıyor. Bunlara “terminal level” deniyor.

• Google: L4 veya L5 (Senior) terminal
• Meta: E5 (Senior), herkesin ulaşması gereken “core level”
• Amazon: L6 (Senior SDE), çoğu mühendis burada plateau yapar

Google’da, birçok mühendis L5’te 10-20 yıl geçiriyor ve başarılı, etkili kariyerlere sahip oluyor. Bu tasarım gereği, başarısızlık değil. Meta açıkça E5’in herkesin sonunda ulaşması gereken yer olduğunu belirtiyor - sadece yaklaşık %15’i E6’ya geçiyor.

Gerçeklik: Tahminlere göre kabaca %10 mühendis Staff seviyesine ulaşıyor ve yaklaşık %1-2’si Principal veya ötesine ulaşıyor, ancak kesin yüzdeler şirkete göre değişiyor.

Tüm kariyerin boyunca Senior’da kalmak tamamen geçerli ve başarılı bir yol. Endüstrinin, Staff mühendislerden çok daha fazla mükemmel Senior mühendise ihtiyacı var. Güçlü Senior’lardan oluşan bir ekip, bir Staff mühendis ve vasat Senior’lardan oluşan bir ekipten daha fazlasını başarabilir.

“Seviye atlamalısın yoksa durgunlaşıyorsun” baskısı genellikle self-imposed veya bu sistemlerin nasıl çalıştığını yanlış anlamaktan geliyor. Kariyerinden ne istediğini tanı: Senior seviyesinde derin teknik uzmanlık, Staff seviyesindeki cross-organizational politikalardan daha tatmin edici olabilir.

Terfi Beklentileri ve Timeline

Lagging Indicator Prensibi

Tüm büyük tech şirketleri, potansiyele değil, gösterilen performansa göre terfi veriyor. Terfiden önce 6-12 ay boyunca bir sonraki seviyede zaten çalışıyor olman gerekiyor. Bunu anlamak kritik: terfi, gelecekte neyi başarabileceğini değil, zaten neyi başardığını tanıyor.

Bu demek oluyor ki Senior’a terfi etmek istiyorsan, şimdi Senior-level scope almaya ve Senior-level impact göstermeye başlamalısın, sonra terfi döngüsünün bunu tanıması için yeterince sürdürmelisin.

Tipik Terfi Timeline’ları

L4 → L5 (Entry’den Mid-Level’a)

• Amazon: High performer’lar için 9 ay ile 2 yıl
• Google: Ortalama 2+ yıl
• Ana değişim: Rehberliğe ihtiyaç duymaktan bağımsız çalışmaya

L5 → L6 (Mid’den Senior’a)

• Amazon: Tipik 2-4 yıl
• Google: Ortalama 3+ yıl
• Ana değişim: Execute etmekten lead etmeye. Birçok mühendis bunu en zor mental transition olarak tanımlıyor.

L6 → L7 (Senior’dan Staff’a)

• Amazon: Harici L7 hiring genellikle internal L6 → L7 terfiden daha kolay
• Google: Ortalama 4+ yıl, gösterilebilir Staff-level scope gerekiyor
• Ana değişim: Reactive problem-solving’den proactive problem-finding’e

Her transition progressively daha uzun sürüyor. Bu intentional - scope ve impact requirement’ları exponentially artıyor, linearly değil.

Staff-Level Scope Bulma

Staff peşindeki Senior mühendislerden en yaygın şikayet: “Ekibimde Staff-level iş yok.”

Bu konuda düşünme şeklimi değiştiren içgörü: Staff mühendisler scope’un assign edilmesini beklemiyorlar. Buluyorlar veya yaratıyorlar.

Staff-Level Scope Olarak Neler Nitelendiriliyor

Staff-level işi tanımlayan üç özellik:

1. Complexity: Senior mühendislerin tek başına çözemediği problemler
2. Impact: Birden fazla ekibi veya organizasyonu etkiler
3. Timeline: Birçok mühendisi içeren multi-quarter roadmap

Pratik Stratejiler

Yakın ekibinde cross-organizational project’ler yoksa:

Organization-wide teknik problemlere bak:

• Tüm mühendisleri etkileyen build system iyileştirmeleri
• Birden fazla ekibe hizmet eden observability infrastructure
• Serviceler arası API standardizasyonu
• Developer productivity tooling
• Migration project’leri (database’ler, cloud platformları, framework’ler)

Platform/infrastructure ekipleri ile ortaklık kur:

Product feature’lar üzerinde çalışsan bile, infrastructure ekiplerinin genellikle cross-cutting inisiyatifleri var ve domain expertise’e ihtiyaçları var. Product alanında yeni infrastructure’ın adoption’ını drive etmek için gönüllü ol ve diğer product ekipleri ile koordine ol.

Guild’ler veya working group’larda teknik inisiyatiflere liderlik et:

Birçok şirketin spesifik teknik domain’ler için guild’leri (Spotify) veya working group’ları var. Burada inisiyatiflere liderlik etmek - GraphQL standartlarını veya security best practice’lerini establish etmek gibi - Staff-level scope yaratır.

Yaygın Staff-Level Project’ler:

Ekiplerle çalışırken, bu project’lerin sürekli olarak Staff-level scope olarak tanındığını gördüm:

• Migration project’leri: 20 service’i REST’ten GraphQL’e taşımak
• Developer productivity: CI/CD pipeline time’ını 45 dakikadan 10 dakikaya düşürmek
• System reliability: Distributed tracing ve SLO monitoring implement etmek
• Teknik standartlar: 50+ mühendis tarafından benimsenen API design guideline’ları oluşturmak
• Cross-team debt reduction: Legacy authentication sisteminin deprecation’ını koordine etmek

Staff Engineer Archetypes

Tüm Staff mühendisler aynı tür işi yapmıyorlar. Farklı şirketlerde çalışırken, dört farklı archetype gözlemledim:

Tech Lead

Scope: Karmaşık project’lerin yaklaşımı ve execution’ı konusunda 1-2 ekibe rehberlik eder

Yaygınlık: En yaygın Staff archetype - healthy Staff oranlarına sahip şirketlerde yaklaşık 8 mühendis başına 1

Örnek: Checkout ekibinin teknik roadmap’ine liderlik etmek, mimari kararlar almak, design’ları review etmek ve engineering kalitesini ensure etmek

Bu, en erişilebilir Staff yolu çünkü scope product ekipleri içinde mevcut.

Architect

Scope: Tüm şirkette spesifik teknik domain’e sahip (API design, data storage, infrastructure pattern’leri)

Yaygınlık: Karmaşık, olgun codebase’lere sahip şirketlerde ortaya çıkar

Örnek: Şirketin GraphQL API stratejisi için chief architect, pattern’leri establish etmek, implementation’ları review etmek ve 50+ service’te tutarlılığı maintain etmek

Solver

Scope: Senior attention gerektiren high-priority, karmaşık problemlere parachuted in

Yaygınlık: Individual ownership’i değer veren şirketlerde daha yaygın (Amazon gibi)

Örnek: Revenue’yi etkileyen kritik performance bottleneck’i düzeltmek için getirilir, root cause’u araştırır, çözüm önerir, implementation’ı koordine eder

Right Hand

Scope: Büyük organizasyonlarda executive capacity’yi extend eder (CTO’nun teknik partner’ı)

Yaygınlık: Nadir - sadece yüzlerce mühendisi olan şirketlerde mantıklı

Örnek: CTO adına company-wide inisiyatifleri execute etmek, executive kararlarında teknik perspektifi temsil etmek

Bu archetype’ları anlamak, hangi Staff yolunun güçlü yönlerine ve ilgi alanlarına uygun olduğunu identify etmene yardımcı oluyor.

IC vs Management Kararı

Senior level (L6/E5) civarında, mühendisler yaygın bir karar noktası ile karşılaşıyorlar: Staff track’te individual contributor olarak mı devam edilmeli, yoksa engineering management’a mı geçilmeli?

Temel Fark

Staff Engineer (IC Track):

• Ana odak: Teknoloji ve teknik sistemler
• Günlük: Derin teknik iş, mimari design, code review’lar, teknik rehberlik
• Leverage: Teknoloji ve influence aracılığıyla scale
• Meeting yükü: Staff+ seviyesinde yüksek, ama çoğunlukla teknik tartışmalar
• Kariyer kontrolü: Yüksek - büyümen doğrudan teknik execution’ına bağlı

Engineering Manager (EM Track):

• Ana odak: İnsanlar ve organizational health
• Günlük: 1:1’ler, hiring, performance review’ları, ekip planlama, kariyer development
• Leverage: İnsanlar ve delegation aracılığıyla scale
• Meeting yükü: Calendar fragmentation ile çok yüksek
• Kariyer kontrolü: Düşük - büyümen ekip büyüme fırsatlarına bağlı

Compensation Gerçeği

İyi yapılandırılmış tech şirketlerinde, Staff Engineer ve Engineering Manager aynı seviyede, identik compensation band’leri ile oturuyor. Bu bir lateral move, terfi değil.

Biri sana “kariyerinde ilerlemek için manager ol” diyorsa, bu engineering ladder design’ları hakkında bir red flag.

Karar Verme

Bu seçimi navigate eden mühendislerle çalışırken, en yararlı görünen framework:

• Derin teknik problemleri çözmeyi seviyorsun → IC track
• İnsanların büyümesine ve başarılı olmasına yardım etmeyi seviyorsun → Management track
• Emin değilsin → Önce Tech Lead rolünü dene (hybrid sorumluluklar)
• Unutma: Karar reversible

Birçok mühendis kariyerlerinde track’ler arasında birden fazla kez geçiş yapıyor. Staff → EM → Sr Staff → Director → Principal Engineer yolunu izleyen insanlar gördüm. Bu esnekliği destekleyen şirketler daha güçlü yetenekleri retain ediyor.

Management için Prerequisite’ler

Bazı şirketlerin management’a geçişe izin vermeden önce Staff seviyesine ulaşmayı gerektirdiği söyleniyor. Mantık: manager’ların ekiplerini etkili bir şekilde desteklemek için güçlü teknik yargıya ihtiyaçları var. Bu, manager’ların teknik kararları değerlendirebilmesini ve mühendislere credibly mentorship yapabilmesini ensure ediyor.

Management Track Seviye Eşleştirmeleri

IC seviyeleri çoğu ilgiyi çekerken, management track’in de şirketler arasında eşleşen kendi hiyerarşisi var. Bunu anlamak, management düşünüyorsan veya manager’ının daha geniş landskapte nerede oturduğunu bilmek istiyorsan yardımcı oluyor.

Şirketler Arası Management Seviyeleri

Şirkete Göre Management Ünvanları:

Seviye	Amazon	Google	Meta	Microsoft
Manager	M1	M1	M1	M1
Sr Manager	M2	M2	M2	Principal Mgr
Director	Director	Director	Director	Director
Sr Director	Sr Director	Sr Director	Sr Director	Partner
VP	VP	VP	VP	VP/CVP
SVP	SVP	SVP	SVP	EVP

Management Seviye Eşleştirme Tablosu

Seviye	Amazon	Google	Meta	Microsoft	IC Eşdeğeri	Tipik Scope
Manager	M1 (L6)	M1 (L6)	M1 (E6)	M1 (65-67)	Staff	5-10 mühendis
Sr Manager	M2 (L7)	M2 (L7)	M2 (E7)	M2 (68-69)	Sr Staff	15-30 mühendis
Director	Director (L8)	Director (L8)	Director (E8)	Director (70+)	Principal	30-80 mühendis
Sr Director	Sr Director	Sr Director	Sr Director	Partner	Distinguished	80-200 mühendis
VP	VP	VP	VP	VP/CVP	Fellow	200-1000+ mühendis
SVP	SVP	SVP	SVP	EVP	-	Organization-wide

Önemli İçgörü: Her seviyede, IC ve management track’leri compensation ve organizational influence açısından eşdeğer olacak şekilde tasarlanmıştır. Amazon’da bir L7 Principal Engineer, M2 Sr Manager ile benzer impact beklentilerine sahip - sadece bu impact’i farklı yollarla achieve ediyorlar.

Scope Progression’ı

Engineering Manager (M1):

• 5-10 mühendisten oluşan tek bir ekibi manage eder
• Ekip execution’ından ve bireysel kariyer büyümesinden sorumlu
• Biraz teknik involvement ile first-line people management
• IC eşdeğeri: Aynı ekip için technical direction’a liderlik eden Staff Engineer

Senior Manager (M2):

• Birden fazla ekibi veya 15-30 mühendisten oluşan daha büyük bir ekibi manage eder
• Bir product alanına veya teknik domain’e sahip
• Daha büyük inisiyatifler için ekipler arası koordinasyon
• IC eşdeğeri: Cross-team teknik influence’a sahip Senior Staff Engineer

Director:

• Manager’ları manage eder (2-4 direct report manager)
• 30-80 mühendis için organizational strateji sahibi
• Multi-quarter roadmap’leri ve organizational health’i drive eder
• IC eşdeğeri: Birden fazla ekip için technical direction belirleyen Principal Engineer

Senior Director:

• Director’ları ve büyük organizasyonları manage eder (80-200 mühendis)
• Organizational vizyon ve uzun vadeli strateji belirler
• Şirket priority’leri konusunda executive leadership ile partner olur
• IC eşdeğeri: Company-wide teknik influence’a sahip Distinguished Engineer

VP of Engineering:

• Tüm bir engineering organizasyonuna sahip (200-1000+ mühendis)
• Şirket direction’ını influence eden executive team üyesi
• Engineering kültürü, hiring stratejisi ve teknik mükemmellikten sorumlu
• IC eşdeğeri: Fellow-level mühendisler (bu seviyede çok nadir)

Management Seviyeleri Ne Zaman Ortaya Çıkar

Tüm şirketlerin her management seviyesine ihtiyacı yok. Her seviye tipik olarak ne zaman gerekli hale gelir:

Seviye	Şirket Büyüklüğü	Neden Ortaya Çıkar
Engineering Manager	15+ mühendis	İlk ekipler dedicated people leadership’e ihtiyaç duyar
Senior Manager	50+ mühendis	Birden fazla ekip koordinasyona ihtiyaç duyar
Director	100+ mühendis	Manager’lar management ve organizational stratejiye ihtiyaç duyar
Senior Director	300+ mühendis	Karmaşık organizational yapılar senior leadership’e ihtiyaç duyar
VP	500+ mühendis	Engineering için executive temsiliyeti
SVP	2000+ mühendis	Birden fazla VP koordinasyona ihtiyaç duyar

Staff ve Principal Pozisyonları Ne Zaman Oluşturulmalı

Engineering leader’lardan en yaygın sorulardan biri: “Şirketimizde Staff/Principal pozisyonlarını ne zaman oluşturmalıyız?”

Bu rolleri çok erken oluşturmak budget israfı ve title inflation yaratır. Çok geç oluşturmak, büyüme yolu gören senior mühendisler şirketlerden ayrıldığı için retention problemlerine yol açar.

Staff Engineer’lara İhtiyacın Olduğunun Sinyalleri

Organizational sinyaller:

• Cross-team teknik borç sahibi olmadan birikiyor
• Teknik kararlar ekipler arası tutarsız
• Senior mühendisler “Staff” title’ları için başka yerlere gidiyor
• Karmaşık teknik inisiyatifler net teknik leadership’ten yoksun
• Mimari tartışmalar koordinasyon olmadan silolar halinde gerçekleşiyor

Büyüklük sinyalleri:

• 30-50+ mühendis tipik olarak yeterli cross-team complexity yaratır
• 3-5+ engineering ekibi teknik koordinasyona ihtiyaç duyar
• Birden fazla product alanı mimari tutarlılığa ihtiyaç duyar

Proje sinyalleri:

• Birden fazla ekibi kapsayan multi-quarter teknik inisiyatifler
• Birden fazla product ekibine hizmet eden infrastructure veya platform işi
• Organizasyon genelinde ihtiyaç duyulan teknik standartlar

Staff Engineer Eşiği

Önerilen oranlar:

• Küçük şirketler (30-100 mühendis): 15-25 mühendis başına 1 Staff
• Orta şirketler (100-500 mühendis): 10-15 mühendis başına 1 Staff
• Büyük şirketler (500+ mühendis): 8-12 mühendis başına 1 Staff

Principal Engineer’lara İhtiyacın Olduğunun Sinyalleri

Principal engineer’lar, Staff engineer’ların belirli problemlere sahip olmak için yeterince senior olmadığı zaman ortaya çıkar:

Organizational sinyaller:

• Multi-year teknik stratejiler ownership’ten yoksun
• Mimari kararlar tüm şirketi etkiliyor
• Harici teknik temsiliyet gerekli (standart body’leri, open source)
• Satın almalar veya major partnership’ler için teknik due diligence
• Staff engineer’lar mentorship ve calibration’a ihtiyaç duyuyor

Büyüklük sinyalleri:

• 200+ mühendis tipik olarak Principal-level scope yaratır
• Mimari koordinasyona ihtiyaç duyan 10+ engineering ekibi
• Shared teknik infrastructure’a sahip birden fazla business unit

Proje sinyalleri:

• Company-wide platform migration’ları (monolith’ten microservices’e)
• Multi-year infrastructure yatırımları
• Product roadmap’lerini etkileyen teknik stratejiler

Principal Engineer Eşiği

200 mühendis altındaki çoğu şirketin Principal engineer’lara ihtiyacı yok. İşte bir framework:

Şirket Büyüklüğü	Staff Engineer’lar	Principal Engineer’lar	Distinguished
30-100	1-3	0	0
100-300	4-10	0-1	0
300-1000	15-40	2-5	0-1
1000+	50+	10+	1-3

Yaygın Hatalar

Rolleri çok erken oluşturmak:

• Principal-level scope olmayan 50 kişilik startup’ta Principal Engineer hire etmek
• Mühendis sıkılır veya gereksiz complexity yaratır

Rolleri çok geç oluşturmak:

• Büyüme isteyen ama yol göremeyen Senior mühendisleri kaybetmek
• Cross-team problemlere sahip olan kimse olmadığı için teknik borç biriktirmek

Scope’u net tanımlamamak:

• Staff-level beklentileri olmayan Staff title’ı confüzyon yaratır
• Mühendisler neden birinin “Staff” olduğunu merak eder oysa Senior’larla aynı işi yapıyorlar

One-size-fits-all yaklaşımı:

• FAANG oranlarını startup context’ine uygulamak
• 200 kişilik şirkette Distinguished Engineer rolü oluşturmak

Doğru Yaklaşım

1. Önce scope’u tanımla: Hangi cross-organizational problemlerin ownership’e ihtiyacı var?
2. Scope’un var olup olmadığını kontrol et: Gerçekten multi-team, multi-quarter iş var mı?
3. Alternatifleri düşün: Senior engineer genişletilmiş scope ile bunu üstlenebilir mi?
4. Gerektiğinde rolü oluştur: Preemptively seviyeler yaratma
5. Yıllık olarak review et: Organizasyon büyüdükçe, ladder’ı yeniden değerlendir

Amaç FAANG’in seviye yapısını match etmek değil - organizational complexity’ne uyan ve mühendisler için anlamlı büyüme sağlayan bir ladder yaratmak.

Şirket Büyüklüğü Considerations

Google’da (150,000+ çalışan) işe yarayan kariyer ladder’ları 50 kişilik bir startup’ta mantıklı olmuyor.

Küçük Şirketler (200 Mühendis Altında)

Önerilen seviyeler: Toplamda 3-4 seviye

• Junior/Mid-Level Engineer
• Senior Engineer
• Staff Engineer (nadir - belki 1-2 kişi)
• CTO/VP Engineering

Neden: 8 seviyeyi haklı çıkaracak organizasyonel complexity’ye sahip değilsin. Artificial subdivision’lar olmadan net progression’a odaklan.

Orta Ölçekli Şirketler (200-1000 Mühendis)

Önerilen seviyeler: 5-6 seviye

• Entry (L3/L4 equivalent)
• Mid-Level (L5 equivalent)
• Senior (L6 equivalent)
• Staff (L7 equivalent)
• Principal (L8 equivalent)
• CTO/VP/Distinguished

Neden: Organizasyonel complexity ortaya çıkıyor. Birden fazla ekip koordinasyona ihtiyaç duyuyor. Staff+ mühendisler için cross-organizational scope mevcut.

Büyük Şirketler (1000+ Mühendis)

Önerilen seviyeler: 7-8 seviye

FAANG şirketlerine benzer tam ladder burada mantıklı. Distinguished Engineer ve Fellow rolleri için yeterli organizasyonel complexity’ye sahipsin.

FAANG Ladder’ları Copy-Paste Yapma

Gördüğüm en büyük hata: 30 mühendisi olan startup’ların Google’ın L3-L10 sistemini benimsemesi. Seviyeler organizasyonel complexity ile eşleşmeli. Büyüdükçe seviye ekle, preemptively yaratma.

Avrupa vs ABD Tech Şirketleri

Compensation Farkları

ABD ve Avrupa tech rolleri arasındaki compensation farkı önemli:

ABD Tech Hub’ları - FAANG/Top-tier (Senior Engineer seviyesi):

• San Francisco/Seattle: Top şirketlerde $350K -$500K total comp
• Önemli equity component (total comp’un %40-60’ı)
• Not: FAANG/top-tier şirketler dışında ortalama ABD Senior comp daha düşük

Avrupa Tech Hub’ları (Senior Engineer seviyesi):

• Londra: £125K - £150K (~$160K -$190K)
• Berlin: €90K - €120K (~$95K -$130K)
• Amsterdam: €85K - €110K (~$90K -$115K)

Avrupa şirketleri tipik olarak sunuyor:

• Düşük base maaşlar (ABD’den %30-40 daha az)
• Daha az equity (equity compensation’da %25 azalma)
• Yasalarla zorunlu kılınan daha güçlü benefit’ler (healthcare, pension, vacation)

Avrupa Şirket Örnekleri: Zalando

Avrupa’nın en büyük fashion platformu Zalando, C (Contributor) ve SC (Senior Contributor) seviyelerini kullanıyor:

• C4-C6: €62K - €78K (Mid-level mühendisler)
• C7: ~€100K (Engineering Manager entry level)
• SC1: €135K - €175K (Senior/Staff equivalent)

FAANG seviyelerine kıyasla:

• Zalando C6 ≈ Amazon L5 (scope’ta, compensation’da değil)
• Zalando SC1 ≈ Amazon L6/Google L5 (Senior level)

Avrupa şirketleri farklı boyutlarda compete ediyor:

• Work-life balance (30+ gün tatil standard)
• İş güvenliği ve işçi korumaları
• Şehir yaşam kalitesi ve yaşam maliyeti
• Daha az intense performance kültürü

Terfi Portfolio’nu Oluşturma

Terfi zamanı geldiğinde, impact’inin kanıtına ihtiyacın var. İşe yarayan:

Doküman Yapısı

Scope genişlemesini gösteren 3-4 major case study ile 10-15 sayfalık bir doküman oluştur:

Her case study için:

1. Problem context: Hangi teknik problem vardı, neden önemliydi
2. Rolün: Hangi spesifik scope’a sahiptin, kimlerle collaborate ettin
3. Teknik çözüm: Mimari, key kararlar, trade-off’lar
4. Ölçülebilir impact: Quantified outcome’lar (latency iyileştirmesi, cost reduction, reliability gain’leri)
5. Leadership yönleri: Mentorship, cross-team influence, teknik standartlar

Impact’i Quantify Etme

Concrete metric’ler kullan:

• “API latency’yi p95’te 450ms’den 120ms’ye düşürdüm”
• “Deployment time’ı 45 dakikadan 12 dakikaya düşürdüm, günde 3 kat daha fazla deployment sağladım”
• “Service uptime’ı %99.5’ten %99.9’a iyileştirdim, yıllık $200K revenue kaybını elimine ettim”
• “3 mühendise mentorship yaptım, 2’si 18 ay içinde Senior’a terfi etti”

Belirsiz claim’lerden kaçın:

• “Sistemi daha hızlı yaptım” → Ne kadar daha hızlı?
• “Güvenilirliği iyileştirdim” → Hangi spesifik metric’ler iyileşti?
• “Ekibe liderlik ettim” → Hangi kararları aldın? Hangi sonuçlar ortaya çıktı?

Peer Testimonial Toplama

Collaborate ettiğin farklı ekiplerdeki mühendislere ulaş:

• Cross-team inisiyatiflerde partner olduğun Staff mühendisler
• Mentorship yaptığın mühendisler
• Yakından çalıştığın Product manager’lar
• Teknik standartlarını benimseyen diğer ekiplerdeki mühendisler

Onlardan spesifik impact’ten bahsetmelerini iste: “Observability iyileştirmelerinin ekibinizin incident response time’ını nasıl etkilediğini paylaşabilir misiniz?”

Self-Advocacy

Win’lerini yıl boyunca dokümante et, terfi döngülerinde scramble etme:

• Aylık olarak update edilen bir “wins” dokümanı tut
• Project outcome’ları ekip toplantılarında paylaş
• Engineering all-hands’te teknik işi present et
• Teknik blog post’ları veya dokümantasyon yaz
• Internal tech talk’lar ver

Self-advocacy övünmek değil. Terfi komiteleri kararları desteklemek için veriye ihtiyaç duyuyor. Impact’ini bilmiyorlarsa, sana yardım edemezler.

Yaygın Kariyer Tuzakları

Bireysel Hatalar

Scope’un assign edilmesini beklemek

Birçok Senior mühendis “ekibimde Staff-level iş yok” diyor ve bekliyor. Staff mühendisler scope yaratıyorlar - cross-organizational problemleri identify ediyorlar ve çözümleri drive ediyorlar.

Büyüme yerine title için optimize etmek

Gerçek Staff-level scope olmadan Staff title’ı için başka bir şirkete atlamak performance problem’larına yol açıyor. Rolün gerçek cross-organizational işe sahip olduğundan emin ol.

Visibility oluşturmamak

Kimsenin bilmediği harika iş terfiye yol açmaz. Win’lerini tech talk’lar, dokümantasyon, demo’lar ve design doc’ları aracılığıyla paylaş.

İş context’ini görmezden gelmek

Teknik olarak ilginç ama düşük impact’li işin peşinden gitmek terfi ettirmez. Terfiler sadece teknik complexity’yi değil, business impact’i ödüllendiriyor.

Organizasyonel Hatalar

Çok fazla seviye

10+ seviyeli şirketler progression’ı checkbox’ları işaretlemek gibi hissettiriyor. Her terfi anlamsız hissettiriyor. Çoğu organizasyon için 5-7 seviye işe yarıyor.

FAANG ladder’ları copy-paste yapmak

Küçük şirketlerin Google’ın 8 seviyeli sistemini benimsemesi artificial complexity yaratıyor. Ladder’ını organizational büyüklüğüne göre scale et.

Potansiyele göre terfi vermek

Mühendisleri yapabileceklerine göre (gösterdiklerine değil) terfi ettirmek performance problem’larına yol açıyor. “Lagging indicator” terfi kullan - sadece bir sonraki seviyede zaten çalışırken terfi et.

Framework’ü checklist olarak kullanmak

Mühendisler “10 item’ın hepsini yaptım, terfim nerede?” dediğinde, framework’ün conversation guide yerine scorecard haline gelmiş oldu. Seviyeler checkbox completion yerine scope ve impact’e odaklanmalı.

Önemli Çıkarımlar

Kariyer büyümesini planlayan mühendisler için:

1. Seviyeni endüstri standartlarına eşleştir - levels.fyi ve progression.fyi kullanarak nerede durduğunu anla
2. Terminal level’lar geçerli kariyer hedefleri - Senior’da (L5/E5/L6) 20 yıl kalmak tamamen reasonable
3. Terfiler gösterilen performansı tanıyor - terfiden önce 6-12 ay bir sonraki seviyede çalışıyor olmalısın
4. Staff seviyesinde kendi scope’unu yarat - assign edilmesini bekleme
5. IC vs Management reversible - her iki track de eşit compensation ve kariyer tatmini sunuyor

Kariyer büyümesini destekleyen engineering manager’lar için:

1. Seviyeleri consistent kalibre et - ekipler arası level inflation’ı önlemek için
2. Staff-level scope yarat - organizasyonun cross-team project’leri yoksa
3. Ladder’ı checklist olarak kullanma - scope ve impact’e odaklan
4. Dual ladder’ları eşit destekle - IC ve Management track’leri eşit saygıyı hak ediyor
5. Terfi süreci hakkında şeffaf ol - net beklentiler politikaları azaltıyor

Sistem tasarlayan engineering leader’lar için:

1. Ladder’ı şirket büyüklüğüne göre scale et - 50 mühendis için 8 seviye yaratma
2. Framework’ünü yayınla - şeffaflık güven oluşturur ve aligned adayları çeker
3. Compensation overlap’ine izin ver - düşük seviyelerdeki high performer’lar yüksek seviyelerdeki underperformer’lardan fazla kazanmalı
4. Progression fırsatlarını dengele - seviyeler çok fazla step olmadan anlamlı progression sağlamalı

Kariyer seviyelerini anlamak, teknik kariyer kararlarını stratejik olarak navigate etmene yardımcı oluyor. Staff peşinde olsan, Senior’da kalsan veya management’a geçsen, her yolun ne gerektirdiğini bil ve kariyerinden ne istediğine göre bilinçli seç.