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

Kariyer seviyesi sistemleri şirketten şirkete o kadar farklı ki unvanlar karşılaştırılabilir olmaktan çıkıyor. Amazon’da Senior L6, Google’da Senior L5; 40 kişilik bir startup’taki Staff unvanı da Meta’daki Staff’ın taşıdığı scope’u nadiren taşıyor. Güvenilir karşılaştırma birimi scope, özerklik ve impact; numara ve etiket yalnızca her şirketin sonucu kaydetme biçimi. Eşdeğer seviyeni yanlış okumanın bir bedeli var: yeni bir rolde daha düşük bir banda razı olursun ya da bir yılı yanlış işin terfi dosyasını hazırlamakla geçirirsin.

Amazon, Google, Meta, Microsoft, Spotify ve Zalando’yu bu ortak çerçeveye oturtmak, ardından gelen kararları da netleştiriyor: Staff için zorlamak mı yoksa Senior’ı varış noktası saymak mı, IC ile management ayrımının gerçekte ne zaman geldiği ve yalnızca feature work’ü olan bir ekipte Staff-level scope’un nasıl bulunacağı.

Seviye Yapıları#

Çoğu büyük tech şirketi individual contributor’lar için 5-7 seviye kullanıyor, ancak her biri farklı isimlendiriyor ve numaralandırıyor. Büyük merdivenler birbirine şöyle oturuyor:

Ş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

Her basamakta unvanlar ve tipik deneyim:

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 bilinçli olarak atlıyor, L4→L5→L6→L7→L8→L10 şeklinde ilerliyor

**Meta E10 istisnai derecede nadir

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

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.

Pratik Seviye Beklentileri#

Seviye numarası bir mühendisin merdivende nerede durduğunu söyler. Numaranın arkasındaki işi tanımak, numaranın kendisini okumaktan daha kolay.

Entry ve Mid-Level (L3-L5)#

Entry seviyesinde tek bir service veya feature area içindeki bireysel componentler senin sorumluluğunda. Specification’lar detaylı geliyor, tech lead sen implement etmeye başlamadan önce yaklaşımını review ediyor ve çıkan iş yakın ekibini etkiliyor. Task şöyle görünüyor: “Kullanıcı dashboard’undaki pagination bug’ını düzelt, sonuçları filtrelediğinde sayfa sayacı yanlış gösteriliyor.” Bug report’u, çevresindeki kodu ve genellikle nereye bakman gerektiğine dair bir ipucunu birlikte alıyorsun.

Mid-level bunu frontend ile backend’i kapsayan, kimi zaman birden fazla service’e dokunan complete feature’lara genişletiyor. Artık teknik specification’ı kendin yazıyorsun, product ve design ile aranda tech lead olmadan konuşuyorsun ve diğer mühendisler senin API’lerine bağlanmaya başlıyor. Notification tercihleri sistemi işin nereye kaydığını gösteriyor. Talep sana sonuç olarak geliyor: kullanıcılar hangi alert’i hangi kanaldan alacağını seçebilsin. Data model, API design ve error handling ise senin kararların olarak geri dönüyor; notifications service ekibiyle birlikte çözüyorsun.

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.

Bu değişimi en net gösteren alan güvenilirlik çalışmaları. Bir servisi %99.5’ten %99.9 uptime’a taşımak failure mode analiziyle başlıyor, monitoring, circuit breaker ve alerting ile bitiyor. Arada “done”ın ne demek olduğuna ve başarının nasıl ölçüleceğine sen karar veriyorsun, sonra birden fazla ekibi bu tanıma göre deploy etmeye ikna ediyorsun.

Staff Level (L7/E6/L6)#

Staff inisiyatifleri organizasyonları kesiyor ve quarter’lar boyunca sürüyor; kimse sana specification vermiyor, neyin build edileceğini sen tanımlıyorsun. Seçtiğin mimari şirketin geri kalanının neyi build edebileceğini açıyor ya da kısıtlıyor. Leadership beklentisinin scope ile birlikte gelmesinin sebebi de bu: birden fazla ekip için technical lead, o ekiplerin izlediği standartların sahibi, hiring stratejisinde ve ekip yapısında söz sahibi.

Global genişleme için multi-region data replication bu inisiyatiflerden biri. İlk karar active-active mi active-passive mi ve bu karar consistency ile conflict resolution sorularını peşinden sürüklüyor. Ardından gelen RFC büyük ölçüde infrastructure ve product ekipleri arasında consensus kurmanın aracı. Implementation ise 2-3 quarter boyunca 5+ ekip üzerinden yürüyor.

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

Staff’ın üstünde ufuk tüm şirketin multi-year mimarisine açılıyor. Tam bağımsızlıkla çalışıyor, organizasyonel priority’leri belirliyor, teknik kısıt ve fırsatlar üzerinden product roadmap’lerini şekillendiriyorsun. Bu seviyedeki kararlar 500+ mühendise, çoğu zaman open source ya da standartlar üzerinden harici topluluklara kadar ulaşıyor; teknik vizyon da genelde şirket dışında görünür oluyor: konferanslar, paper’lar ya da kodun kendisi.

Bu işin hiçbir parçası bir quarter’a sığmıyor. Bir şirketin monolith’ten microservices’e geçişi, service extraction boundary’lerinin bir kez doğru çizilmesini ve executive tarafın imzaladığı bir migration stratejisini gerektiriyor. Tüm engineering organizasyonunun koordinasyonu 2-3 yıl sürüyor ve arkasında şirket standardı olacak pattern’ler bırakıyor.

Terminal Level’lar#

Çoğu şirket, bir mühendisin kariyerinin geri kalanını geçirmesinin beklendiği seviyeler tasarlıyor. Bunlara “terminal level” deniyor.

• Google: L5 (Senior) terminal; altındaki seviyelerde terfi bekleniyor
• 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 on yıl ya da daha uzun süre geçiriyor ve başarılı, etkili kariyerler kuruyor. Merdiven zaten bunu barındıracak şekilde kurulmuş. Meta, E5’i herkesin ulaşması beklenen seviye olarak görüyor ve görece az mühendis bunun ötesine geç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. “Seviye atlamalısın yoksa durgunlaşıyorsun” baskısı çoğu zaman kişinin kendi kendine yüklediği bir baskı ya da bu sistemlerin nasıl çalıştığını yanlış okumanın sonucu. Kariyerinden ne istediğini tanı: Senior seviyesinde derin teknik uzmanlık, Staff seviyesindeki cross-organizational politikalardan daha tatmin edici olabilir.

Terfi Beklentileri ve Timeline#

Tüm büyük tech şirketleri potansiyele değil, gösterilen performansa göre terfi veriyor. Terfi gelmeden önce 6-12 ay boyunca bir üst seviyede zaten çalışıyor olman gerekiyor.

Hedef Senior ise Senior-level scope şimdi başlamalı ve bir değerlendirme döngüsünün görebileceği kadar sürmeli.

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 geçiş bir öncekinden daha uzun sürüyor; çıta her basamakta bir öncekinden daha hızlı yükseliyor.

Staff-Level Scope#

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

Staff mühendisler scope’un kendilerine verilmesini beklemiyor; ya buluyor ya da kendileri yaratıyorlar. Sayılan işin üç işareti var: bir Senior’ın tek başına çözemeyeceği karmaşıklık, birden fazla ekibe ya da organizasyona uzanan etki ve quarter’larla ölçülen bir yol haritası.

Bu çıtayı aşan project’ler şirketten şirkete birbirine benziyor:

• 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

Kendi ekibinde bunlardan hiçbiri yoksa scope genelde bir adım ötede duruyor. Infrastructure ve platform ekiplerinin domain bilgisi isteyen cross-cutting inisiyatifleri oluyor; bunlardan birini kendi product alanında, diğer ekiplerle koordine ederek yürütmek gerçek Staff işidir. İkinci yol guild’ler ve working group’lar: bir teknik domain’de GraphQL standartlarını ya da security pratiklerini oturtmak, organizasyon şemasının sana vermediği scope’u yaratıyor.

Staff Engineer Archetypes#

Tüm Staff mühendisler aynı tür işi yapmıyor. Will Larson’ın StaffEng görüşmeleri, şirketten şirkete tekrar eden dört archetype tanımlıyor.

Tech Lead, karmaşık project’lerin yaklaşımı ve execution’ı konusunda bir ya da iki ekibe rehberlik ediyor: checkout ekibinin teknik roadmap’ini üstlenmek, mimari kararları almak, design’ları review etmek, kalite çizgisini korumak. Hem en yaygın hem de en erişilebilir archetype, çünkü bu scope product ekiplerinin içinde zaten var. Architect ise tüm şirkette bir teknik domain’in sahibi: API design, data storage, infrastructure pattern’leri. Tanıdık hali şirketin GraphQL API stratejisinin chief architect’i olmak: pattern’leri oturtmak, implementation’ları review etmek, 50+ service’te tutarlılığı korumak. Bu rol, codebase yeterince karmaşık ve olgun hale gelip tutarlılık kendiliğinden sürmemeye başlayınca ortaya çıkıyor.

Diğer ikisi daha dar. Solver, senior dikkati gerektiren yüksek öncelikli problemlere paraşütle iniyor; bu da bireysel ownership’e değer veren Amazon gibi şirketlere uyuyor. Revenue’yi etkileyen kritik bir performance bottleneck Solver’a gidiyor, o da işi root cause’dan koordineli çözüme kadar taşıyor. Right Hand executive kapasiteyi genişletiyor: CTO’nun teknik partner’ı olarak company-wide inisiyatifleri yürütüyor ve teknik bakışı executive kararlarına taşıyor. Bu rol nadir ve yalnızca yüzlerce mühendisi olan organizasyonlarda anlamlı.

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?

IC track’te dikkatin teknolojide kalıyor: mimari, derin teknik iş, code review, teknik rehberlik. Staff+ seviyesinde toplantı yükü burada da artıyor ama çoğu teknik; büyümen kendi execution’ını yakından takip ettiği için kontrolün büyük kısmı sende kalıyor. Management track’te konu insanlara ve organizasyonun sağlığına kayıyor; gün 1:1’ler, hiring, performance review’ları, ekip planlaması ve kariyer görüşmeleriyle doluyor. Leverage delegasyondan geliyor, takvim parçalanıyor ve büyümen ekibin büyüme fırsatı bulmasına bağlanıyor.

Compensation Gerçeği#

İyi yapılandırılmış tech şirketlerinde Staff Engineer ile Engineering Manager aynı seviyede ve aynı compensation band’lerinde oturuyor. Karşıya geçmek yatay bir adım.

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

Karar ve Geri Dönüş#

Seni içine çeken şey derin teknik problemlerse cevap IC track; insanların büyümesini izlemekse management. İkisi de daha güçlü çekmiyorsa, Tech Lead rolü her ikisinden bir parça taşıyor ve soruyu daha fazla düşünmekten daha hızlı yanıtlıyor.

Karar ayrıca geri döndürülebilir. Mühendisler Staff → EM → Sr Staff → Director → Principal Engineer yolunu izliyor ve iki yönlü trafiği destekleyen şirketler daha güçlü yetenekleri elde tutuyor. Bazıları management’a geçişi bir kıdem eşiğine, genelde Senior ve üzerine bağlıyor; gerekçe, bir manager’ın ekibin kararlarını değerlendirebilecek ve mühendislere inandırıcı biçimde mentorluk yapabilecek kadar teknik yargıya ihtiyaç duyması.

Management Track Seviye Eşleştirmeleri#

İlgi çoğunlukla IC seviyelerine gitse de management track’in de şirketler arasında eşleşen kendi hiyerarşisi var. Bunu bilmek, management’ı düşünüyorsan ya da kendi manager’ının bu haritada nerede durduğunu merak ediyorsan işine yarıyor.

Ş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 basamakları IC merdivenine nasıl oturuyor:

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

Her seviyede iki track, compensation ve organizasyonel etki açısından birbirine denk olacak şekilde tasarlanıyor. Amazon’da bir L7 Principal Engineer, M2 Sr Manager’a yakın impact beklentileri taşıyor; yalnızca yöntem değişiyor. Merdivenin ortası manager’ların manager yönetmeye başladığı yer; bir Director’ın 30-80 mühendisi, Principal Engineer’ın teknik strateji talebiyle aynı ölçekte organizasyonel strateji istiyor.

Management Seviye Eşikleri#

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 Pozisyon Kriterleri#

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 bütçe israfı ve unvan enflasyonu yaratır. Çok geç oluşturmak ise elde tutma sorununa dönüşür: büyüme yolu sunan şirketlere giden senior mühendisleri kaybedersin.

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

Önce organizasyonel işaretler geliyor: sahibi olmadan biriken cross-team teknik borç, ekipler arasında birbirinden uzaklaşan teknik kararlar, silolar halinde yürüyen mimari tartışmalar, net teknik liderlik olmadan ilerleyen karmaşık inisiyatifler ve “Staff” unvanı için başka şirketlere giden Senior mühendisler.

Büyüklük ve proje şekli bu işaretleri genelde doğruluyor. 3-5 ekibe yayılmış 30-50 mühendis civarında cross-team karmaşıklık, birden fazla product alanının mimari tutarlılık istemesine ve multi-quarter inisiyatiflerin birbirine rapor etmeyen ekipleri kesmesine yetiyor. Birden fazla product ekibine hizmet eden infrastructure veya platform işi de aynı yöne işaret ediyor.

Principal Ne Zaman Gerçek Bir Seviye Olur#

Principal engineer’lar, bazı problemlerin sahipliğini üstlenmek için Staff engineer’ların yeterince kıdemli kalmadığı noktada ortaya çıkıyor: sahibi olmayan multi-year teknik stratejiler, tüm şirkete uzanan mimari kararlar, standart body’leri ya da open source’ta harici teknik temsiliyet, satın almalar ve büyük ortaklıklar için teknik due diligence, bir de mentorship ile kalibrasyona ihtiyaç duyan Staff engineer’lar.

Bu tablo genelde 200 mühendis ve mimari koordinasyon isteyen on ekip sınırının ötesinde, ya da birden fazla business unit aynı teknik altyapıyı paylaştığında oluşuyor. Company-wide platform migration’ları, multi-year infrastructure yatırımları ve product roadmap’lerini yeniden şekillendiren teknik stratejiler bu seviyeyi hak eden project’ler. 200 mühendis altındaki çoğu şirkette bunların hiçbiri yok.

Ş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

Unvandan önce scope’u tanımla. Sahibini bekleyen multi-team, multi-quarter bir problem yoksa genişletilmiş scope’a sahip bir Senior mühendis daha ucuz cevap; basamak da organizasyon oraya büyüyene kadar bekleyebilir. Karşılığı olmayan bir unvan kendi zararını yaratıyor: çevresindeki kimse, en başta da benzer işi yapan Senior’lar, etiketin neden orada olduğunu anlamıyor. Organizasyon büyüdükçe merdiveni yeniden değerlendir.

Şirket Büyüklüğüne Göre Seviyeler#

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

200 mühendisin altında üç ya da dört seviye yetiyor: junior/mid, senior, nadiren bir iki Staff mühendis, sonra CTO ya da VP Engineering. Sekiz basamağı haklı çıkaracak organizasyonel karmaşıklık yok; yine de bölmek sadece ezberlenecek isim ekliyor.

200 ile 1000 mühendis arasında karmaşıklık kendiliğinden geliyor. Beş altı seviye (entry, mid, senior, staff, principal, ardından CTO/VP/Distinguished) gerçekten koordinasyon isteyen ekiplere ve gerçekten var olan cross-organizational scope’a oturuyor. 1000 mühendisin ötesinde FAANG biçimindeki yedi sekiz basamaklı tam merdiven, Distinguished ve Fellow dahil, hakkını veriyor.

Hata tek yönde işliyor: 30 mühendisi olan bir startup’ın Google’ın L3-L10 sistemini benimsemesi. Seviyeleri organizasyon oraya büyüdükçe ekle.

Avrupa vs ABD Tech Şirketleri#

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)
• Aynı seviyede daha küçük equity paketleri
• Yasalarla zorunlu kılınan daha güçlü benefit’ler (healthcare, pension, vacation)

Zalando’nun C ve SC Bantları#

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 Portföyü#

Terfi zamanı geldiğinde impact’inin kanıtına, bir komitenin hızlıca okuyabileceği biçimde ihtiyacın var.

Dosyada Ne Var#

On ile on beş sayfalık bir doküman, üç dört case study ve her birinde daha önce taşımadığın bir scope. Her case study için: teknik problem ve neden önemli olduğu, senin sahiplendiğin parça ve kimlerle çalıştığın, mimari ile arkasındaki trade-off’lar, ölçülmüş sonuç ve etrafında görünen liderlik (mentorship, cross-team etki, başka ekiplerin benimsediği standartlar).

Dosyayı taşıyan somut sayılar:

• “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”

Bunların belirsiz akrabaları taşımıyor. “Sistemi daha hızlı yaptım” ne kadar sorusunu davet ediyor, “güvenilirliği iyileştirdim” hangi metrik sorusunu, “ekibe liderlik ettim” hangi kararlar ve ne sonuç sorusunu.

Kendi ağzından söyleyemeyeceğin kısmı referanslar kapatıyor. Cross-team inisiyatiflerde birlikte çalıştığın Staff mühendislere, mentorluk yaptığın mühendislere, yakın çalıştığın product manager’lara ve standartlarını benimseyen ekiplere sor. Onları somut bir noktaya yönlendir: “Observability iyileştirmelerinin ekibinizin incident response time’ını nasıl etkilediğini paylaşabilir misiniz?”

Kaydı Güncel Tutmak#

Kazanımları olurken yaz ki terfi dönemi kazı çalışmasına dönüşmesin: aylık güncellenen bir “wins” dokümanı, ekip toplantılarında paylaşılan project sonuçları, engineering all-hands’te sunulan teknik iş, iz bırakan dokümantasyon ve internal tech talk’lar. Terfi komiteleri kanıta bakarak karar veriyor ve hiç duymadıkları bir impact’i tartamıyorlar.

Tekrar Eden Hatalar#

Bazıları mühendislere, bazıları çalıştıkları şirketlere ait ve ikisi birbirini besliyor.

Unvan için optimize etmek. Gerçek Staff-level scope olmadan Staff unvanı için başka bir şirkete atlamak, daha ilk aylarda performans sorununa dönüşüyor. Etiket teklifi cazip göstermeden önce rolün hangi cross-organizational işi taşıdığını oku.

İlginç işi etkili işe tercih etmek. Terfi komiteleri business impact’i teknik karmaşıklığın üzerinde tutuyor; dolayısıyla teknik olarak sarıcı ama etki alanı dar iş zayıf bir dosya kuruyor.

Fazla basamak. 10+ seviyeli merdivenler ilerlemeyi kutu işaretlemeye çeviriyor ve her terfi olduğundan küçük hissettiriyor. Çoğu organizasyon için 5-7 seviye işe yarıyor.

Framework’ü scorecard’a çevirmek. Mühendisler “10 item’ın hepsini yaptım, terfim nerede?” diye geldiğinde merdiven artık bir sohbet rehberi olmaktan çıkmış demektir. Maddeler o sohbete ortak bir dil vermek için var; yöneticine götürülecek daha işe yarar konu, bir üst seviyenin scope’unun hangi parçasını şu an taşıdığın.

Eşleştirmenin Sınırları#

Yukarıdaki tablolar, merdivenini kalibre edecek büyüklükteki şirketlerde güvenilir çalışıyor; levels.fyi ve progression.fyi bir maaş görüşmesi ya da terfi dosyası için savunulabilir bir başlangıç sayısı veriyor. İki yerde bozuluyorlar. Yaklaşık 200 mühendisin altında unvanlar kalibrasyondan çok işe alım baskısını takip ediyor, dolayısıyla 60 kişilik bir şirketten gelen Staff teklifi yalnızca ilan metnindeki scope’a bakılarak değerlendirilmeli. Unvanı ücretten bilinçli olarak ayıran Spotify Steps ya da Zalando’nun C/SC bantları gibi çerçeveler de sorumluluk hakkında bilgi verir, ücret hakkında neredeyse hiçbir şey söylemez.

Bu hafta başlanmaya değer tek alışkanlık: bu çeyrekte sahiplendiğin scope’u, trade-off’lar hâlâ tazeyken yaz. Terfi komiteleri bir üst seviyede çoktan teslim edilmiş işin kanıtına bakarak karar veriyor ve o kanıtı bir yıl sonra yeniden kurmak zor.

Kaynaklar#

• Levels.fyi Standart SWE Seviye Çerçevesi (yeni sekmede açılır) - Yüzlerce şirketten derlenen topluluk verisine dayalı seviye tanımları; yukarıdaki tablolarda kullanılan şirketler arası eşleştirmenin kaynağı.
• Levels.fyi Maaş ve Kariyer Verileri (yeni sekmede açılır) - Şirket, seviye ve lokasyona göre kullanıcı katkılı ücret verisi; ABD ve Avrupa maaş aralıklarının dayandığı veri seti.
• progression.fyi - Açık Kaynak Kariyer Çerçeveleri (yeni sekmede açılır) - Kamuya açık mühendislik kariyer merdivenlerinin derlemesi; şirketlerin her seviyeyi nasıl tanımladığını karşılaştırmak için kullanışlı.
• StaffEng: Staff Engineer Archetypes (yeni sekmede açılır) - Will Larson’ın dört Staff archetype’ı (Tech Lead, Architect, Solver, Right Hand) ve her birinin günlük işleyişini anlatan görüşmeler.
• DORA Accelerate State of DevOps Report 2024 (yeni sekmede açılır) - Yüksek performanslı mühendislik organizasyonlarını ayrıştıran uygulamalar üzerine yıllık araştırma; Staff ve üzeri mühendislerden yürütmesi beklenen ekipler arası pratikler dahil.
• Psikolojik Güvenlik Nedir? - Harvard Business Review (yeni sekmede açılır) - Amy Edmondson, ekiplerin risk almasını ve konuşmasını sağlayan koşulları anlatıyor; Staff ve üzeri seviyedeki liderlik beklentisinin çekirdeği.
• Drive - Daniel Pink (yeni sekmede açılır) - Pink’in otonomi-ustalık-amaç modeli; IC ve management yollarını karşılaştırırken faydalı bir arka plan.