Kariyer merdiveni şablonu

Yazılım mühendisi kariyer merdiveni şablonu

Junior’dan Principal’a beş seviye; kodu yayına almaktan ekibi geliştirmeye kadar altı yetkinlik.

Ücretsiz plan · Kredi kartı gerekmez

Bu kariyer merdiveni yaklaşık 20–200 kişilik ürün şirketleri için yazıldı: mühendisler özellikleri baştan sona kendileri geliştirip yayına alır, ekipler küçüktür ve İK’da kimse bir iş mimarisi hazırlamaz. Kariyerinin başındaki birinden tüm şirketin teknik yönünü belirleyen birine kadar beş seviye tanımlar. En üst seviyesi olan Principal Mühendis bir uzman seviyesidir; mühendisleri yönetmek ayrı bir kariyer merdiveninde, Engineering Manager merdiveninde ele alınır.

Her seviye deneyim yılıyla değil, kişinin ne yaptığıyla tanımlanır. Tek bir beklentinin nasıl büyüdüğünü görmek için yetkinlik matrisinin bir satırını soldan sağa okuyun; bir seviyede beklenen her şeyi bir arada görmek için o seviyenin bölümünü okuyun. Bir sonraki seviyenin ne anlama geldiğini açıklamak, öz değerlendirmeleri ve check-in’leri yapılandırmak ve terfi gerekçelerini ekipler arasında karşılaştırılabilir kılmak için kullanın.

Bunu bir başlangıç noktası olarak görün. Kariyer merdivenini ekibinizle paylaşmadan önce seviyeleri kendi unvanlarınıza göre yeniden adlandırın, şirketinize uymayan yetkinlikleri birleştirin ya da çıkarın ve beklentileri kendi cümlelerinizle yeniden yazın.

Bir bakışta seviyeler

Junior Mühendis
Kod tabanını öğrenir ve net tanımlanmış görevleri yönlendirme alarak tamamlar.
Kapsam
Ürünün tek bir alanındaki tekil görevler; bunları genellikle daha deneyimli biri parçalara ayırır.
Mühendis
Özellikleri bağımsız olarak teslim eder ve ekibin güvenilir bir üyesidir.
Kapsam
Tek bir ekibin alanındaki küçük ve orta ölçekli özellikler; kısa bir tasarım notundan canlı ortama kadar.
Senior Mühendis
Daha büyük işlere liderlik eder ve çevresindeki ekibin çıtasını yükseltir.
Kapsam
Birden fazla servisi ya da birden fazla kişiyi kapsayan projeler ve bir ekibin teknik kararları.
Staff Mühendis
Ekip sınırlarını aşan sorunları çözer ve tek bir ekibin ötesindeki teknik kararlara yön verir.
Kapsam
Birden fazla ekip ya da bütün bir ürün alanı; hiçbir ekibin sahiplenmediği sorunlar dahil.
Principal Mühendis
Şirketin teknik yönünü belirler ve uzun vadeli teknik sağlığından sorumludur.
Kapsam
Tüm mühendislik organizasyonu ve şirketin önümüzdeki birkaç yıllık teknik stratejisi.

Yetkinlik matrisi

Her satır bir yetkinlik, her sütun bir seviyedir. Beklentinin nasıl büyüdüğünü görmek için bir satırı soldan sağa okuyun.

Her yetkinlik ne anlama gelir

Geliştirme ve teslim: Gereksinimleri çalışan, bakımı kolay yazılıma dönüştürmek ve kullanıcılara ulaştırmak.
Sistem tasarımı: Ürün büyüdükçe ayakta kalacak yapıları, arayüzleri ve ödünleşimleri seçmek.
Kalite ve güvenilirlik: Ürünü doğru çalışır, gözlemlenebilir ve erişilebilir tutmak ve arızalardan ders çıkarmak.
İş birliği ve iletişim: Diğer mühendislerle, ürün ve tasarım ekipleriyle ve şirketin geri kalanıyla etkili biçimde çalışmak.
Sahiplik ve ürün etkisi: İşin neden önemli olduğunu anlamak ve yalnızca görevlerin değil, sonuçların sorumluluğunu almak.
Mentorluk ve ekip gelişimi: Başkalarının gelişmesine yardım etmek ve ekibi içindeki herhangi bir kişiden daha güçlü kılmak.

Yazılım Mühendisi: yetkinlik ve seviyeye göre beklentiler
Yetkinlik	Junior Mühendis	Mühendis	Senior Mühendis	Staff Mühendis	Principal Mühendis
Geliştirme ve teslim	Kapsamı net görevleri okunabilir kod ve testlerle tamamlar, günlerce değil birkaç saat takıldıktan sonra yardım ister ve birleştirmeden önce inceleme yorumlarını ele alır.	Bir özelliği sürekli yönlendirmeye ihtiyaç duymadan kısa bir tasarım notundan canlı ortama taşır, incelemesi kolay pull request’lere böler ve tanıdık işler için gerçekçi tahminler verir.	Birden fazla servisi ya da katkıda bulunanı kapsayan projeleri teslim eder, işi faydalı bir parça erkenden yayına çıkacak şekilde sıralar ve riskleri ekibi engellemeden önce ortadan kaldırır.	Ekipler arası teslimin önündeki engelleri kaldırır: ortak bağımlılıkları çözer, birden fazla ekibin ihtiyaç duyduğu araçları geliştirir ya da geçişleri yürütür ve çok ekipli projeleri yolunda tutar.	Tüm organizasyonun yazılımı nasıl yayına aldığını şekillendirir — sürüm pratikleri, platform seçimleri, derleme ve dağıtım araçları — böylece her ekip daha hızlı ve daha güvenli teslim eder.
Sistem tasarımı	Kod tabanındaki mevcut kalıpları izler ve değiştirdiği kodun neden bu şekilde yapılandırıldığını açıklayabilir.	Mevcut bir servisin içindeki bileşenleri tasarlar, basit olmayan değişiklikler için kısa bir tasarım notu yazar ve bir seçenekte karar kılmadan önce en az iki seçeneği karşılaştırır.	Birden fazla servisi kapsayan özelliklerin tasarımına liderlik eder, ödünleşimleri başkalarının incelemesi için yazıya döker ve diğer mühendislerin tasarımlarını yapıcı biçimde inceler.	Ekip sınırlarını aşan mimariyi tanımlar — ortak veri modelleri, servis sözleşmeleri, geliştirme ya da satın alma kararları — ve sistemin önümüzdeki bir iki yılda nasıl değişmesi gerektiğini öngörür.	Şirketin teknik stratejisinin sahibidir: hangi teknolojilere yatırım yapılacağını, hangilerinin bırakılacağını ve mimarinin birkaç yıl içinde işle birlikte nasıl evrileceğini belirler.
Kalite ve güvenilirlik	Kendi değişiklikleri için test yazar, sürümden önce işini kontrol eder ve dokunduğu koddaki hataları düzeltir.	Geliştirdiği özellikler için izleme ve uyarılar ekler, nöbet (on-call) rotasyonunda yer alır ve rutin olayları runbook’a göre yönetir.	Ekibin sistemlerindeki olaylara müdahaleyi yönetir, suçlamasız olay sonrası analizler (post-mortem) yazar ve takip aksiyonlarının gerçekten tamamlandığından emin olur.	Sistemler arası güvenilirlik ve güvenlik risklerini bulur, test stratejisi ve hizmet seviyesi hedefleri gibi standartları belirler ve düzeltmeleri ekipler genelinde hayata geçirir.	Güvenilirlik, güvenlik ve kalitenin şirket için ne anlama geldiğini tanımlar, bunları yönetim ekibiyle birlikte hıza karşı dengeler ve en zor olaylarda son eskalasyon noktasıdır.
İş birliği ve iletişim	İlerlemesini ve önündeki engelleri açıkça paylaşır, bir gereksinim belirsiz olduğunda net sorular sorar.	Gereksinimleri netleştirmek için doğrudan ürün ve tasarım ekipleriyle çalışır, teknik kısıtları sade bir dille açıklar ve inceleyenlerin kolayca takip edebileceği pull request açıklamaları yazar.	Planlamada ekibi temsil eder, kapsamı ve ödünleşimleri ürün ekibiyle müzakere eder ve mühendislik dışındaki kişilerin de anlayacağı belgeler yazar.	Birden fazla ekibi ve fonksiyonu bir teknik plan etrafında hizalar, ekipler arasındaki anlaşmazlıkları çözer ve teknik riski yönetime anlatır.	Şirket düzeyindeki kararlarda güvenilen bir sestir, iş stratejisini teknik yöne ve teknik yönü iş diline çevirir ve gerektiğinde mühendisliği müşterilere, iş ortaklarına ya da yatırımcılara karşı temsil eder.
Sahiplik ve ürün etkisi	Görevlerinin amacını anlar, yayına aldığı şeyin kullanıcılar için çalıştığını kontrol eder ve çalışana kadar takipte kalır.	Bir özelliği lansmandan sonra da sahiplenir: kullanımını ve hatalarını izler, ters gideni düzeltir ve öğrendiklerine dayanarak iyileştirmeler önerir.	Ürünün bir alanını uçtan uca sahiplenir, kullanıcılara fayda sağlamayan gereksinimleri sorgular ve ekibin hedeflerini ilerleten işler önerir.	Bir ürün alanında en büyük etkiyi yaratacak sorunları — hiçbir ekibin üstlenmediği sorunlar dahil — bulur ve çözülmelerini sağlar.	Mühendislik yatırımını şirket sonuçlarına bağlar ve büyük bahislerin lehinde ya da aleyhinde teknik ve iş etkilerine dayanarak görüş savunur.
Mentorluk ve ekip gelişimi	Geri bildirim ister ve buna göre hareket eder; öğrendiklerini yazıya döker ki bir sonraki yeni gelen işe daha kolay başlasın.	Özenli kod incelemeleri yapar, yeni ekip arkadaşlarının uyum sürecine yardım eder ve kodun yabancı olduğu kısımlarında junior mühendislerle eşli çalışır.	Bir iki mühendise bilinçli olarak mentorluk yapar, bir sonraki seviyeye ulaşmalarına yardım eden geri bildirimler verir ve işe alım mülakatlarında yer alır.	Ekipler genelinde senior mühendisleri yetiştirir, mülakat sürecini ve mühendislik pratiklerini şekillendirir ve başkalarının tavsiye için başvurduğu biridir.	Şirketin teknik kültürünü — kararların nasıl alındığını ve bilginin nasıl paylaşıldığını — inşa eder ve yeni nesil staff mühendisleri yetiştirir.

Tüm seviyeleri görmek için tabloyu yana kaydırın.

CSV olarak indirin Excel, Google Sheets ya da Numbers ile açılır.

Junior Mühendis: beklentiler

Kod tabanını öğrenir ve net tanımlanmış görevleri yönlendirme alarak tamamlar. Ürünün tek bir alanındaki tekil görevler; bunları genellikle daha deneyimli biri parçalara ayırır.

Geliştirme ve teslim: Kapsamı net görevleri okunabilir kod ve testlerle tamamlar, günlerce değil birkaç saat takıldıktan sonra yardım ister ve birleştirmeden önce inceleme yorumlarını ele alır.
Sistem tasarımı: Kod tabanındaki mevcut kalıpları izler ve değiştirdiği kodun neden bu şekilde yapılandırıldığını açıklayabilir.
Kalite ve güvenilirlik: Kendi değişiklikleri için test yazar, sürümden önce işini kontrol eder ve dokunduğu koddaki hataları düzeltir.
İş birliği ve iletişim: İlerlemesini ve önündeki engelleri açıkça paylaşır, bir gereksinim belirsiz olduğunda net sorular sorar.
Sahiplik ve ürün etkisi: Görevlerinin amacını anlar, yayına aldığı şeyin kullanıcılar için çalıştığını kontrol eder ve çalışana kadar takipte kalır.
Mentorluk ve ekip gelişimi: Geri bildirim ister ve buna göre hareket eder; öğrendiklerini yazıya döker ki bir sonraki yeni gelen işe daha kolay başlasın.

Mühendis: beklentiler

Özellikleri bağımsız olarak teslim eder ve ekibin güvenilir bir üyesidir. Tek bir ekibin alanındaki küçük ve orta ölçekli özellikler; kısa bir tasarım notundan canlı ortama kadar.

Geliştirme ve teslim: Bir özelliği sürekli yönlendirmeye ihtiyaç duymadan kısa bir tasarım notundan canlı ortama taşır, incelemesi kolay pull request’lere böler ve tanıdık işler için gerçekçi tahminler verir.
Sistem tasarımı: Mevcut bir servisin içindeki bileşenleri tasarlar, basit olmayan değişiklikler için kısa bir tasarım notu yazar ve bir seçenekte karar kılmadan önce en az iki seçeneği karşılaştırır.
Kalite ve güvenilirlik: Geliştirdiği özellikler için izleme ve uyarılar ekler, nöbet (on-call) rotasyonunda yer alır ve rutin olayları runbook’a göre yönetir.
İş birliği ve iletişim: Gereksinimleri netleştirmek için doğrudan ürün ve tasarım ekipleriyle çalışır, teknik kısıtları sade bir dille açıklar ve inceleyenlerin kolayca takip edebileceği pull request açıklamaları yazar.
Sahiplik ve ürün etkisi: Bir özelliği lansmandan sonra da sahiplenir: kullanımını ve hatalarını izler, ters gideni düzeltir ve öğrendiklerine dayanarak iyileştirmeler önerir.
Mentorluk ve ekip gelişimi: Özenli kod incelemeleri yapar, yeni ekip arkadaşlarının uyum sürecine yardım eder ve kodun yabancı olduğu kısımlarında junior mühendislerle eşli çalışır.

Senior Mühendis: beklentiler

Daha büyük işlere liderlik eder ve çevresindeki ekibin çıtasını yükseltir. Birden fazla servisi ya da birden fazla kişiyi kapsayan projeler ve bir ekibin teknik kararları.

Geliştirme ve teslim: Birden fazla servisi ya da katkıda bulunanı kapsayan projeleri teslim eder, işi faydalı bir parça erkenden yayına çıkacak şekilde sıralar ve riskleri ekibi engellemeden önce ortadan kaldırır.
Sistem tasarımı: Birden fazla servisi kapsayan özelliklerin tasarımına liderlik eder, ödünleşimleri başkalarının incelemesi için yazıya döker ve diğer mühendislerin tasarımlarını yapıcı biçimde inceler.
Kalite ve güvenilirlik: Ekibin sistemlerindeki olaylara müdahaleyi yönetir, suçlamasız olay sonrası analizler (post-mortem) yazar ve takip aksiyonlarının gerçekten tamamlandığından emin olur.
İş birliği ve iletişim: Planlamada ekibi temsil eder, kapsamı ve ödünleşimleri ürün ekibiyle müzakere eder ve mühendislik dışındaki kişilerin de anlayacağı belgeler yazar.
Sahiplik ve ürün etkisi: Ürünün bir alanını uçtan uca sahiplenir, kullanıcılara fayda sağlamayan gereksinimleri sorgular ve ekibin hedeflerini ilerleten işler önerir.
Mentorluk ve ekip gelişimi: Bir iki mühendise bilinçli olarak mentorluk yapar, bir sonraki seviyeye ulaşmalarına yardım eden geri bildirimler verir ve işe alım mülakatlarında yer alır.

Staff Mühendis: beklentiler

Ekip sınırlarını aşan sorunları çözer ve tek bir ekibin ötesindeki teknik kararlara yön verir. Birden fazla ekip ya da bütün bir ürün alanı; hiçbir ekibin sahiplenmediği sorunlar dahil.

Geliştirme ve teslim: Ekipler arası teslimin önündeki engelleri kaldırır: ortak bağımlılıkları çözer, birden fazla ekibin ihtiyaç duyduğu araçları geliştirir ya da geçişleri yürütür ve çok ekipli projeleri yolunda tutar.
Sistem tasarımı: Ekip sınırlarını aşan mimariyi tanımlar — ortak veri modelleri, servis sözleşmeleri, geliştirme ya da satın alma kararları — ve sistemin önümüzdeki bir iki yılda nasıl değişmesi gerektiğini öngörür.
Kalite ve güvenilirlik: Sistemler arası güvenilirlik ve güvenlik risklerini bulur, test stratejisi ve hizmet seviyesi hedefleri gibi standartları belirler ve düzeltmeleri ekipler genelinde hayata geçirir.
İş birliği ve iletişim: Birden fazla ekibi ve fonksiyonu bir teknik plan etrafında hizalar, ekipler arasındaki anlaşmazlıkları çözer ve teknik riski yönetime anlatır.
Sahiplik ve ürün etkisi: Bir ürün alanında en büyük etkiyi yaratacak sorunları — hiçbir ekibin üstlenmediği sorunlar dahil — bulur ve çözülmelerini sağlar.
Mentorluk ve ekip gelişimi: Ekipler genelinde senior mühendisleri yetiştirir, mülakat sürecini ve mühendislik pratiklerini şekillendirir ve başkalarının tavsiye için başvurduğu biridir.

Principal Mühendis: beklentiler

Şirketin teknik yönünü belirler ve uzun vadeli teknik sağlığından sorumludur. Tüm mühendislik organizasyonu ve şirketin önümüzdeki birkaç yıllık teknik stratejisi.

Geliştirme ve teslim: Tüm organizasyonun yazılımı nasıl yayına aldığını şekillendirir — sürüm pratikleri, platform seçimleri, derleme ve dağıtım araçları — böylece her ekip daha hızlı ve daha güvenli teslim eder.
Sistem tasarımı: Şirketin teknik stratejisinin sahibidir: hangi teknolojilere yatırım yapılacağını, hangilerinin bırakılacağını ve mimarinin birkaç yıl içinde işle birlikte nasıl evrileceğini belirler.
Kalite ve güvenilirlik: Güvenilirlik, güvenlik ve kalitenin şirket için ne anlama geldiğini tanımlar, bunları yönetim ekibiyle birlikte hıza karşı dengeler ve en zor olaylarda son eskalasyon noktasıdır.
İş birliği ve iletişim: Şirket düzeyindeki kararlarda güvenilen bir sestir, iş stratejisini teknik yöne ve teknik yönü iş diline çevirir ve gerektiğinde mühendisliği müşterilere, iş ortaklarına ya da yatırımcılara karşı temsil eder.
Sahiplik ve ürün etkisi: Mühendislik yatırımını şirket sonuçlarına bağlar ve büyük bahislerin lehinde ya da aleyhinde teknik ve iş etkilerine dayanarak görüş savunur.
Mentorluk ve ekip gelişimi: Şirketin teknik kültürünü — kararların nasıl alındığını ve bilginin nasıl paylaşıldığını — inşa eder ve yeni nesil staff mühendisleri yetiştirir.

Bu merdiven nasıl uyarlanır

Seviyeleri unvanlarınızla eşleştirin
Unvanlarınız Developer I, II ve III ise seviyeleri yeniden adlandırın, ancak kapsamdaki her gerçek adım için bir seviye bırakın. 100’den az mühendisi olan şirketlerin çoğunun henüz Principal seviyesine ihtiyacı yoktur: biri bu işi fiilen yapana kadar bu seviyeyi dışarıda bırakın.
Beş ila yedi yetkinlikte kalın
Yediden fazlası olursa kimse okumaz; dörtten azı olursa birbirinden çok farklı kişiler aynı görünür. Her zaman birlikte puanladığınız yetkinlikleri birleştirin; yeni bir yetkinliği yalnızca gerçek bir kararı değiştirecekse ekleyin.
Beklentileri gözlemlenebilir davranışlarla yazın
Her hücre için bir yöneticinin son altı aydan bir örnek gösterip gösteremeyeceğini sorun. “Güçlü” ya da “derin” gibi kelimeleri kişinin gerçekte yaptığı şeyle değiştirin; örneğin “ekibin servislerindeki olaylara müdahaleyi yönetir”.
Yayımlamadan önce gerçek kişiler üzerinde deneyin
İki üç yöneticiden ekip üyelerini taslak üzerinde konumlandırmalarını isteyin. Anlaşamadıkları her yerde ifade belirsizdir: düzeltin, kariyer merdivenini yayımlayın ve altı ay sonra yeniden gözden geçirmek üzere anlaşın.

SSS

Bu merdiven hakkında sorular

Bir yazılım mühendisi kariyer merdiveninde kaç seviye olmalı?

20–200 kişilik bir şirket için dört ila altı seviye tipiktir. Daha az seviyede terfiler seyrek ve çok büyük adımlar olur; daha fazlasında iki seviye arasındaki fark tarif edilemeyecek kadar küçülür. Bu şablon beş seviye kullanır: Junior Mühendis, Mühendis, Senior, Staff ve Principal.

Mühendislerin gelişmek için yönetici olması gerekir mi?

Hayır. Bu, uzmanlık yolu için bir kariyer merdivenidir: Staff ve Principal mühendislerin kapsamı ve etkisi insan yönetmeden büyür. Bunu Engineering Manager kariyer merdiveniyle birlikte kullanın; böylece yöneticiliğe geçmek bir terfi değil, kariyer yolu değişikliği olur.

Mühendislerin terfi kararlarında kariyer merdivenini nasıl kullanırız?

Bir sonraki seviyede çalışabilecek kişileri değil, zaten tutarlı biçimde o seviyede çalışan kişileri terfi ettirin. Kişiden ve yöneticisinden hedef seviyenin her yetkinliği için somut örnekler toplamalarını isteyin ve kararlar ekipler arasında tutarlı kalsın diye her vakayı aynı matrisle karşılaştırın.

Kariyer merdiveni check-in’lere ve birebir görüşmelere nasıl yerleşir?

Onu düzenli check-in’lerin gündemi olarak kullanın: kişi kendini mevcut seviyesine göre değerlendirir, yönetici de aynısını yapar ve ikisi arasındaki farklar önümüzdeki aylar için birkaç somut gelişim görevine dönüşür.

Yazılım mühendisi kariyer merdivenini ne sıklıkla güncellemeliyiz?

Yılda bir iki kez ve şirketin yapısı her değiştiğinde — örneğin bir platform ekibi kurduğunuzda ya da Staff mühendis almaya başladığınızda — gözden geçirin. Değerlendirmelerin sürekli takıldığı bir hücreyi her seferinde yeniden yazın.

Bu kariyer merdivenini LadderKit’te kurun — ücretsiz

Seviyelerini ve becerilerini ekibiniz için kurun, check-in’lerde kişileri bunlara göre değerlendirin ve terfi kararlarını tutarlı tutun.

Ücretsiz başlayın Canlı demoyu görün Kayıt gerekmez