2026'da Yüksek Performanslı Mühendislik Ekipleri Kurmak

İstanbul merkezli bir fintek scale-up'ında kıdemli bir backend mühendisi, iki haftalık ihbar süresiyle istifasını verir. Liderlik ekibinden hiç kimse onunla yapılmış yazılı bir kariyer görüşmesine, son performans döneminden kalma bir değerlendirme kartına (scorecard) ya da beklediği "Staff Engineer" terfisinin neden gelmediğine dair somut bir gerekçeye işaret edemez. İlan aynı öğleden sonra yayına girer ve işe alım uzmanı size dürüstçe söyler: bu piyasada benzer bir kıdemli mühendisi kapatmak 10-14 hafta sürer. Yerine gelen kişi dört ay sonra bile hâlâ tam verime ulaşamamıştır. Bu bir varsayım değil — işe alımı, işe alıştırmayı (onboarding), performans yönetimini ve elde tutmayı "iyi insanlar bulduktan sonra kendiliğinden olan şeyler" gibi ele alan, bunun yerine tanımlı girdileri, kontrol noktaları ve bilinen başarısızlık modları olan bir sistem olarak görmeyen her mühendislik organizasyonunun varsayılan sonucudur.

2026'da yüksek performanslı mühendislik ekipleri kurmak, üç yıl öncesine göre daha zor — daha kolay değil. Uzaktan ve hibrit çalışma, birçok şirketin süreç yerine sessizce güvendiği gayri resmi düzeltme mekanizmalarını — koridor sohbetlerini, "havadan" gerçekleşen işe alıştırmayı, birinin motivasyonunu kaybettiğini "hisseden" yöneticiyi — ortadan kaldırdı. Yapay zeka destekli kodlama araçları ise yetersiz ya da motivasyonu düşmüş bir çalışanın makul görünen bir pull request üretme hızını ciddi biçimde sıkıştırdı; bu da mülakat sürecinizin ve kod inceleme kültürünüzün artık daha az değil, daha çok ağırlık taşıdığı anlamına geliyor. Ve bunu yanlış yapmanın maliyeti soyut değil: kıdemli seviyede yanlış bir işe alım, beklenmedik bir ayrılış ya da kimsenin güvenmediği bir değerlendirme dönemi, doğrudan altı haneli maliyetlere ve yavaşlayan bir yol haritasına dönüşür.

Bu yazı, büyüyen ekiplerle sürekli kan kaybeden ekipler arasındaki farkı yaratan insan pratiklerini ele alıyor: işe alım, işe alıştırma, performans yönetimi, elde tutma ekonomisi, psikolojik güvenlik ve yapay zeka araçlarının güçlü bir mühendislik organizasyonu kurma işini nasıl değiştirdiği — ve nasıl değiştirmediği. Bu yazı kasıtlı olarak ekip topolojisini, raporlama hatlarını ya da bir ekibi ne zaman bölmeniz gerektiğine dair kişi sayısı eşiklerini kapsamıyor; bu konu, tamamlayıcı yazımız olan Mühendislik Ekibini 10'dan 50'ye Ölçeklendirme'nin konusu ve ilgili olduğu yerlerde oraya yönlendireceğiz.

Öne Çıkan Noktalar

Bağımsız değerlendirme kartlarıyla yürütülen yapılandırılmış mülakat süreçleri, "hissiyat" temelli mülakatlardan üstündür. Schmidt ve Hunter'ın 1998'de Psychological Bulletin'de yayımlanan meta-analizi, yapılandırılmış mülakatların iş performansını 0,51 geçerlilik katsayısıyla öngördüğünü (yapılandırılmamış mülakatlarda 0,38), work-sample testlerinin ise 0,54 ile incelenen yöntemler arasında en güçlü tekil öngörücülerden biri olduğunu ortaya koydu.
"Kültür uyumu" (culture fit) sıklıkla önyargıyı meşrulaştıran bir mekanizmadır — mülakatı yapan kişiye benzeyen adayları filtreler. Bunun yerine, teknik yetkinliklerle aynı titizlikte puanlanan, değer temelli ve yapılandırılmış "kültüre katkı" (culture add) kriterlerini kullanın.
Yazılı bir 30/60/90 günlük onboarding planı, bir mühendisin ilk çeyreğinde yapabileceğiniz en yüksek getirili elde tutma yatırımıdır — erken dönem gönüllü işten ayrılmaların çoğunun kökeninde ücret değil, kafa karıştırıcı ya da hiç var olmayan bir alışma süreci vardır.
Orta veya kıdemli bir mühendisi kaybedip yerine yenisini bulmak, boşta geçen süre, verime ulaşma süresi ve bilgi aktarım kaybı hesaba katıldığında genellikle o mühendisin yıllık maaşının %45-65'ine mal olur — çoğu zaman bir elde tutma zammının maliyetinden fazlasına.
Amy Edmondson tarafından tanımlanan ve Google'ın Project Aristotle araştırmasıyla büyük ölçekte doğrulanan psikolojik güvenlik, ekip etkinliğinin en güçlü öngörücülerinden biridir. Bu, bazı ekiplerde tesadüfen bulunan bir özellik değil, bilinçli olarak inşa edilen bir liderlik davranışıdır.
DORA metrikleri (dağıtım sıklığı, değişiklik için teslim süresi, değişiklik başarısızlık oranı, hizmeti geri yükleme süresi) sistem sağlığını ölçer. Bunları bireysel performans değerlendirmelerinde kullanmak, tam olarak bu metriklerin önlemek için tasarlandığı oyunlaştırma davranışını üretir.

İşe Alım: Yapılandırılmış Mülakat Süreçleri, Gerçek Work-Sample Testleri ve "Kültür Uyumu" Tuzağını Ortadan Kaldırmak

Süreci hissiyat üzerine değil, değerlendirme kartı üzerine kurun

"Kendinizden bahsedin" ile başlayan, serbest akan bir teknik sohbetle devam eden ve "genel izlenim" temelli bir değerlendirmeyle biten yapılandırılmamış bir mülakat hızlı hissettirir ama aslında yazı-tura atmaktan farksızdır. Schmidt ve Hunter'ın personel seçimi üzerine 85 yıllık araştırmayı gözden geçiren dönüm noktası niteliğindeki meta-analizi bu konudaki en çok atıf alan kanıttır: her adayın aynı önceden belirlenmiş sorulara yanıt verdiği ve tanımlı kriterlere göre puanlandığı yapılandırılmış mülakatlar, yapılandırılmamış mülakatlara kıyasla öngörü gücünü neredeyse ikiye katlar (0,51'e karşı 0,38). Orta/kıdemli bir mühendislik pozisyonu için pratik bir süreç:

İşe alım uzmanı ön görüşmesi (30 dk) — lojistik, motivasyon, maaş beklentisi uyumu.
Teknik ön eleme (45-60 dk) — işle bağlantısız bir "leetcode" bulmacası değil, rubriğe göre puanlanan tek bir yapılandırılmış problem.
Work-sample egzersizi — aşağıya bakın.
Yüz yüze/sanal mülakat turu (3 aşama, toplam ~3,5 saat) — sistem tasarımı tartışması, gerçek (temizlenmiş) kod üzerinde kod inceleme/hata ayıklama egzersizi ve "kültüre katkı" görüşmesi.
Değerlendirme toplantısı — her mülakatçı, grup tartışmasından önce bağımsız yazılı bir değerlendirme kartı sunar; böylece kıdemli seslerin odayı yönlendirmesi engellenir.

Adayın zamanına saygı duyan work-sample testleri

Work-sample testi elinizdeki en güçlü öngörücülerden biridir (Schmidt ve Hunter'a göre 0,54 geçerlilik), ama çoğu şirket bunu şirketin zamanını korumak için adayın zamanı pahasına tasarlar.

	Kötü take-home	İyi take-home
Kapsam	"Auth, testler, CI ve deployment içeren tam bir CRUD uygulaması yapın — ne kadar sürerse sürsün."	Verilen küçük bir servisi (150-300 satır) yeni bir durumu ele alacak şekilde genişletmeyi isteyen, ~2 saatlik sınırlı bir egzersiz, artı yazılı bir trade-off açıklaması.
Zaman maliyeti	Sınırsız — adaylar 8-20 saat harcadığını bildiriyor; ücretsiz	2 saatle sınırlı, önceden belirtilmiş; ücretsiz uygun değilse sabit bir ücret (2.500-4.000 TL civarı) ödenir
Gerçekçilik	İşin gerçek doğasından kopuk, jenerik bir uygulama	Ekibin gerçek teknoloji yığınına ve rolün gerçekten karşılaşacağı hata/özellik sınıfına yakın
Değerlendirme	Öznel "kodu beğendim mi" hissi	Yayınlanmış bir rubriğe göre puanlanır: doğruluk, muhakeme, iletişim
Geri bildirim	Yok — aday sonucu hiç öğrenmez	Adayın kararlarını açıkladığı 30 dakikalık canlı bir sunum — asıl olarak nasıl düşündüğünü burada öğrenirsiniz

Take-home testiniz, işin kendisinin adayın zamanı için ödediğinden daha uzun sürüyorsa, en iyi mühendisleri değil, işsiz olanları ve rakip teklifi bulunmayanları seçiyorsunuz demektir.

Önyargıyı azaltan değerlendirme kartları

Değerlendirme kartı (scorecard), her mülakatçının yazılı kanıtla birlikte bağımsız olarak 1-4 arası puanladığı, tartışmadan önce sunulan paylaşılan bir rubriktir — genellikle sistem düşüncesi, hata ayıklama, iletişim, sahiplenme gibi 4-6 yetkinlik içerir. Bu iki şeyi sağlar: mülakatçıları bir izlenim yerine somut bir örnekle puanı gerekçelendirmeye zorlar ve fikir ayrılığını erken ortaya çıkarır — ki bu, sahte bir fikir birliğinden çok daha kullanışlıdır.

"Kültür uyumu" tuzağı — ve yerine ne kullanılmalı

"Bu kişiyle bira içer miydim?" bir işe alım kriteri değildir; benzerliğin bir vekilidir, ve benzerlik performansla ilişkili değildir. Yaygın uygulandığı haliyle "kültür uyumu", mülakatçıyla aynı geçmişi, iletişim tarzını ya da sosyal referansları paylaşmayan adayları eler — homojen ekiplerin homojen kalmasının nedeni budur. Ayrıca bir rubriği olmadığı için sonradan itiraz etmek ya da denetlemek neredeyse imkânsızdır.

Bunun yerine kültüre katkı (culture add) kullanın: teknik becerilerle aynı kanıt temelli rubrikte puanlanan, küçük ve açık, değer temelli kriterler (örneğin "doğrudan ve yazılı geri bildirim verir", "'bilmiyorum' demekte rahattır", "odada olmayan kullanıcıları savunur"). Fark önemlidir: kültür uyumu "bu kişi bize benziyor mu" diye sorar; kültüre katkı ise "bu kişi bize eksik olan bir şeyi katıyor mu" diye sorar — mülakattaki somut davranışsal kanıta göre puanlanır, değerlendirme toplantısındaki bir hisse göre değil.

Uzaktan ve Dağıtık Ekipler için Gerçek Bir 30/60/90 Günlük Plan

Rastgele bir onboarding — "işte Slack daveti, takılırsan buddy'ine yaz" — erken dönem işten ayrılmaların önemli bir kısmının asıl kaynağıdır: yeni çalışan üç hafta boyunca gerçek bir iş çıkaramaz, ekibin dağınık olduğu sonucuna varır ve deneme süresi bitmeden işe alım uzmanlarının aramalarına çıkmaya başlar. Somut kilometre taşları olan yazılı bir plan bunu düzeltir.

Aşama	Hedef	Somut eylemler	Başarı sinyali
1-30. günler (Temel)	Ortam, bağlam, ilk gerçek katkı	Erişim ve geliştirme ortamı, ilk günden önce script'lenmiş kurulumla hazırlanır (wiki sayfası değil); adı belirlenmiş bir buddy atanır; bir nöbet (on-call) vardiyasını gözlemci olarak izler; 5. güne kadar küçük ama gerçek bir PR gönderir; mimari, deploy süreci ve ekip normlarını kapsayan yazılı bir onboarding kontrol listesini tamamlar	2. hafta sonunda ilk PR production'a merge edilir; onboarding kontrol listesi yönetici ve buddy tarafından onaylanır
31-60. günler (Katkı)	Küçük bir kapsamda bağımsız sahiplenme	Bir özelliği veya hata düzeltme alanını uçtan uca sahiplenir; sadece inceleme almakla kalmaz, takım arkadaşlarının PR'larını aktif olarak inceler; canlı bir RFC'ye yorum veya bölüm katkısında bulunur; yöneticiyle check-in toplantısından önce paylaşılan, rol beklentilerine göre yazılı 60 günlük öz değerlendirme	Tanımlı bir kapsamda elini tutmadan iş çıkarır; inceleme yorumları bağımsız teknik yargı gösterir
61-90. günler (Sahiplenme)	Tam entegrasyon, resmi kalibrasyon	Küçük bir projeyi yönetir veya bir on-call rotasyonunu bağımsız üstlenir; ekip forumunda teknik bir çalışma sunar; işe alımda kullanılan aynı değerlendirme kartına göre 90 günlük resmi değerlendirme, açık bir geçti/uzatıldı/işaretlendi kararıyla	Yönetici ve bir üst yönetici, sürprizsiz, yazılı olarak bir sonuçta anlaşır

Planın kendisinden daha önemli iki uygulama detayı var: erişimin ilk günden önce sağlanması (VPN bilgilerini bekleyerek ilk gününü geçiren bir yeni çalışan, şirketin nasıl işlediği hakkında zaten bir şey öğrenmiştir) ve yönetici olmayan, adı belirli bir buddy atanması — yeni çalışanlar "aptalca" sorularını, performans değerlendirmesini imzalayacak kişiye sormaktansa akranlarına çok daha rahat sorarlar.

Asenkron İletişim ve Yazı-Öncelikli Kültür

Yazı-öncelikli (written-first) varsayılanları hiç kurmamış dağıtık ekipler, kurumsal hafızalarını Slack thread'lerine dayandırmakla sonuçlanır; bu da her kararın, biri bağlamı aramak için geri dönüp hiçbir şey bulamadığında yeniden tartışılması anlamına gelir. Bunu düzelten somut pratikler:

Karar dokümanları (decision docs): onu üreten konuşmadan daha uzun ömürlü olacak her karar için tek sayfalık bir şablon (bağlam, değerlendirilen seçenekler, karar, sahip, tarih); bir chat thread'inde değil, aranabilir bir yerde saklanır.
Etki alanı geniş olan her şey için RFC'ler: mimari değişiklikler, API sözleşmeleri, birden fazla ekibi etkileyen her şey hafif bir RFC alır — problem tanımı, önerilen yaklaşım, değerlendirilen alternatifler ve son tarihli açık bir yorum talebi. Junior mühendislerin gerçek etki kazandığı yer burasıdır: iyi gerekçelendirilmiş bir RFC yorumu, unvandan bağımsız olarak sayılır.
Belgelenmiş toplantı varsayılanları: 24 saat önceden dağıtılmış yazılı gündem olmadan toplantı yapılmaz; her tekrarlayan toplantının belirtilmiş bir amacı ve "gündem yoksa iptal et" varsayılan kuralı vardır; bir toplantıda alınan kararlar 24 saat içinde yazıya dökülür, yoksa alınmamış sayılır.
"Her an ulaşılabilir olma" beklentisi yerine yanıt süresi normları: neyin senkron olduğunu (olaylar/incident'lar, önceden anlaşılmış pairing) ve neyin asenkron olduğunu (çoğu kod incelemesi, çoğu planlama) ve her biri için geçerli yanıt süresini (örneğin bir ekip şartında) açıkça belirtin — dağıtık çalışmayı farklı saat dilimlerinde gerçekten sürdürülebilir kılan şey, herhangi bir araç seçiminden çok budur.

Performans Yönetimi, Kariyer Basamakları ve Kalibrasyon

İnsanların gerçekten kullandığı bir kariyer basamağı

Kullanılabilir bir IC (bireysel katkıcı) basamağı (Mühendis II → Kıdemli (Senior) → Staff → Principal), her seviyeyi az sayıda boyutta — teknik kapsam, sahiplenme, mentorluk, organizasyonel etki — sıfatlarla değil, somut ve gözlemlenebilir davranışlarla tanımlar. "Staff mühendisler birden fazla ekip genelinde teknik kararlara yön verir ve belirsiz problemlerde yargıları aranır" kullanılabilir bir ifadedir; "Staff mühendisler güçlü liderlik gösterir" değildir.

Kalibrasyon toplantıları gerçekte nasıl işler

Kalibrasyon, yalnızca yöneticinin verdiği puanlamanın iki başarısızlık modunu yakalamak için vardır: enflasyon (her yönetici zor bir konuşmadan kaçınmak için kendi ekibini cömertçe puanlar) ve tutarsızlık (aynı performans, hangi yöneticinin yazdığına göre farklı puan alır). İşleyen bir kalibrasyon toplantısı şöyle yürür:

Her yönetici, toplantı öncesinde yazılı kanıtla birlikte önerilen puanları sunar — kanıt yoksa puan tartışılmaz.
Çapraz fonksiyonlu bir grup (akran yöneticiler, bir üst yönetici, bazen İK kolaylaştırıcı olarak) aykırı değerleri inceler: alışılmadık derecede yüksek veya düşük puanları ve kanıtın puana kıyasla zayıf göründüğü durumları.
Grup zorunlu bir dağılım empoze etmez (zorunlu çan eğrisi yok — bu mekanizma GE ve Microsoft'ta "stack ranking" (zorunlu sıralama) sistemini çökerten ve önlemesi gereken iç rekabeti ve manipülasyonu tam da yaratan şeydi). Kalibrasyon, kanıtlanabilir tutarsızlığı düzeltir, "gelişmesi gerekiyor" puanlarının hedef bir yüzdesini değil.
Nihai puanlar ve herhangi bir değişikliğin gerekçesi belgelenir ve çalışana kendi yöneticisi tarafından iletilir — kalibrasyon, bir çalışanın puanının değiştiğini ilk kez öğrendiği an olmamalıdır.

Elde Tutma Ekonomisi: Orta/Kıdemli Bir Mühendisi Kaybetmenin Gerçek Maliyeti

SHRM'nin sıkça atıf alan araştırması, bir çalışanı değiştirmenin tam yüklü maliyetini yıllık maaşının %50-200'ü aralığına yerleştiriyor; uzmanlaşmış ve kıdemli roller aralığın üst ucunda. Aşağıda, yıllık brüt maaşı 1.800.000 TL (aylık 150.000 TL) olan, İstanbul'da bir scale-up'ta çalışan kıdemli bir backend mühendisi için aşağıdan yukarıya kurulmuş bir hesaplama var — böylece rakamın nereden geldiğini körü körüne kabul etmek yerine gerçekten görebilirsiniz.

Maliyet kalemi	Dayanak	Tahmini maliyet (TL)
İşe alım ve kaynak bulma	İK/işe alım ekibi zamanı, ilan ve LinkedIn Recruiter payı	90.000
Mülakat panelinin zamanı	4 mülakatçı × 4 saat (ön eleme, tur, değerlendirme) × 900 TL/saat yüklü ücret	14.400
İşe alım yöneticisi genel giderleri	Kaynak bulma görüşmeleri, teklif müzakeresi, evrak işleri	12.000
Elde tutma/imza teşviki	Rekabetçi kıdemli roller için piyasada tipik	40.000
Boş pozisyon maliyeti	Kıdemli mühendis için ortalama işe alım süresi ~10 hafta × haftalık yüklü maliyet (41.500 TL), ekibin absorbe ettiği iş için %50 iskonto	207.500
Verime ulaşma süresi	4 ay × ~%50 verimlilik açığı × aylık yüklü maliyet (180.000 TL)	360.000
Bilgi aktarım yükü	2,5 takım arkadaşı × haftada 5 saat × 6 hafta, bağlamı özümseme ve yeni kişiye mentorluk, saatlik 800 TL yüklü ücretle	60.000
Toplam		≈ 783.900 TL

Bu, ayrılan mühendisin yıllık maaşının yaklaşık %43,5'ine denk gelir — SHRM'nin %50-200 aralığının alt sınırında, çünkü bu hesaplama boş pozisyon maliyetini ekip tarafından absorbe edilen iş için %50 iskontolamış durumda. Hesaba katılmayan, ölçmesi daha zor etkiler var: ayrılışın kalan ekibin motivasyonuna etkisi, basitçe kayan yol haritası kalemleri ve bir ayrılışın ikinci bir ayrılışı tetikleme riski (iyi belgelenmiş bir "işten ayrılma bulaşıcılığı" örüntüsü, ancak büyüklüğü için atıf verebileceğimiz tek ve net bir rakam yok).

Elde tutmaya yatırım yapmanın aritmetik gerekçesi doğrudan buradan çıkıyor: 100.000-150.000 TL'lik bir elde tutma zammı, hak edilmiş ama bir değerlendirme dönemi yüzünden gecikmiş bir terfi ya da samimi bir kariyer konuşması, bu seviyedeki bir rol için her seferinde 783.900 TL'den daha ucuzdur.

Psikolojik Güvenlik Bir Elde Tutma Aracıdır, Duvardaki Poster Değil

Amy Edmondson'ın Administrative Science Quarterly'de yayımlanan 1999 tarihli "Psychological Safety and Learning Behavior in Work Teams" başlıklı çalışması, ekip psikolojik güvenliğini "ekip üyeleri arasında paylaşılan, ekibin kişilerarası risk almak için güvenli olduğuna dair bir inanç" olarak tanımlar — yani bir hata itiraf etmek, bariz görünebilecek bir soru sormak ya da kıdemli bir meslektaşın tasarımına, cezalandırılma veya küçük düşürülme korkusu olmadan itiraz etme güveni. Araştırması sezgiye aykırı bir sonuç ortaya koydu: yüksek performanslı ekipler daha az değil, daha fazla hata bildirdi — çünkü bunları gizlemek yerine erken ortaya çıkaracak kadar güvendeydiler.

Google'ın 2012-2016 yılları arasında kendi şirketi içindeki yaklaşık 180 ekibi, 250'den fazla özellik üzerinden inceleyen Project Aristotle araştırma girişimi, en iyi ekiplerini neyin ayırdığını bulmayı amaçlıyordu — cevabın ekip bileşimiyle (kıdem, kişilik karışımı, demografi) ilgili olacağını bekliyordu. Bunun yerine, psikolojik güvenlik, güvenilirlik, netlik ve yapı, anlam ve etki gibi -önemli ama daha az belirleyici olan- diğer faktörlerin önünde, ekip etkinliğinin en güçlü tekil öngörücüsü olarak öne çıktı.

Mühendislikte bu, somut ve gözlemlenebilir davranışlarda kendini gösterir: bir mühendis riskli bir deploy'u production'ı bozduktan sonra değil, öncesinde işaret eder; kod incelemesinde junior bir mühendisin engelleyici endişesi kıdem yüzünden görmezden gelinmek yerine ele alınır; postmortem'ler sadece isim olarak değil, gerçekten suçlayıcı değildir — organizasyon bir sonraki sprintte kiminle pair yapmaktan kaçınacağını sessizce not etmek yerine bir süreci değiştirir. Bu, bir değerler posteriyle değil, liderlik davranışıyla inşa edilir — bir yöneticinin, biri ekibin önünde ilk kez bir hatayı itiraf ettiğinde nasıl tepki verdiği, sonraki yirmi seferin normunu belirler.

Yapay Zeka Destekli İş Akışları: Gerçek Kazanç ve İnceleme Borcu

2026 itibarıyla çoğu mühendislik ekibi günlük iş akışında bir yapay zeka destekli kodlama aracı kullanıyor ve nerede gerçekten fayda sağladığı, nerede sessizce borç biriktirdiği konusunda dürüst olmak, araç seçiminden daha önemli.

Gerçekten fayda sağladığı yerler:

Boilerplate ve iskelet kod — config dosyaları, CRUD endpoint'leri, test fixture'ları, migration script'leri
Spesifikasyonun kendisinin zor düşünme işini yaptığı, iyi tanımlanmış dar kapsamlı görevlerin ilk taslak implementasyonları
Mevcut kod yolları için test üretimi, özellikle bir insanın yorgunluktan atlayacağı edge case'ler
Onboarding veya olay müdahalesi sırasında yabancı kodun özetlenmesi veya açıklanması

İnceleme borcu yarattığı yerler:

Kod "temiz göründüğü" için yeşil CI ve rutin bir insan onayıyla merge edilen PR'lar — bu araçların optimize edildiği tam olarak budur: doğru olsun ya da olmasın, makul görünen kod üretmek
Güvenlikle ilgili kodun (auth, girdi doğrulama, deserialization, secret yönetimi), "yapay zeka yazdı" güveni yanlış bir rahatlık yarattığı için, insan tarafından yazılmış bir değişikliğin göreceği aynı titizlik olmadan üretilip merge edilmesi
Hacim arttığı için incelemecilerin PR başına daha az zaman harcaması — yüksek riskli kodun ihtiyaç duyduğunun tam tersi
Bir değişikliği kimin yazdığı ile kimin gerçekten neden çalıştığını açıklayabildiği arasında büyüyen bir boşluk — sabah 2'deki bir olay sırasında gerçek bir risk

Politika düzeltmesi araçları yasaklamak değil, çizgiyi korumak: değişikliği kim veya ne yazmış olursa olsun aynı inceleme standardı uygulanır, PR yazarları (insan ya da yapay zeka destekli) incelemede değişikliği açıklayabilmelidir ve güvenlik açısından hassas yollar, herhangi bir yapay zeka destekli implementasyon başlamadan önce zorunlu insan tasarım incelemesinden geçer.

DORA Metriklerini Silahlaştırmadan Ekip Sağlığını Ölçmek

DORA'nın dört anahtar metriği — dağıtım sıklığı, değişiklik için teslim süresi, değişiklik başarısızlık oranı ve hizmeti geri yükleme süresi — yazılım teslim performansının mevcut en güvenilir ve yaygın kullanılan ölçütleridir ve açıkça sistem ve ekip düzeyinde metriklerdir. DORA'nın kendi rehberliği bu konuda nettir: bunları bireysel geliştiricilere uygulamak ters teşvikler yaratır — mühendisler dağıtım sayısını şişirmek için PR'ları parçalara böler, değişiklik başarısızlık oranını korumak için riskli ama gerekli refactor'lardan kaçınır ya da kişisel bir rakamı tutturmak için test ve inceleme yükünü sessizce takım arkadaşlarına iter. Ekip veya sistem düzeyinde kullanıldığında ise aynı metrikler, teslim hattında darboğazın nerede olduğunu -insanlarda değil- tespit etmek için gerçekten faydalıdır.

Teslim hızının aksine spesifik olarak ekip sağlığı için, DORA'yı küçük bir insan merkezli sinyal setiyle eşleştirin: kısa bir çeyreklik nabız anketi (yıllık değil — çeyreklik sıklık, biri istifa etmeden önce bir sorunu yakalamak için yeterlidir), üzülünen işten ayrılma oranı (regretted attrition — istenmeyen ayrılışların çalışan sayısına oranı, zaman içinde takip edilir), iç transfer oranı (insanların şirketten ayrılmadan hareket edebildiğinin sağlıklı bir işareti) ve yeni işe alınanlar için ilk merge edilen PR'a kadar geçen süre, bir onboarding sağlık kontrolü olarak. Bunların hiçbiri de bireysel bir performans değerlendirmesine girmemeli — bunlar, tıpkı DORA gibi, sistemin teşhis araçlarıdır.

Karşı Senaryo: Bu Pratikler Ne Zaman Aşırıya Kaçar

Yukarıdaki her pratik her aşamada maliyetini karşılamaz. Beş kişilik bir ekibe kurumsal düzeyde bir süreç uygulamak kendi başına bir başarısızlık modudur.

Take-home testleri ve çapraz fonksiyonlu kalibrasyon komiteleri içeren beş aşamalı yapılandırılmış mülakat süreçleri, ikinci veya üçüncü mühendisini işe alan 5-10 kişilik bir startup için aşırıdır. Kurucuyla yapılan bir pairing oturumu artı değer temelli kriterler üzerine odaklı bir sohbet, işe alım süresine üç hafta ekleyen ağır bir süreçten -yetenek için hızla rekabet ederken- daha iyi öngörü sağlar.
Resmi kariyer basamakları, birden fazla mühendislik yöneticiniz olmadan ya da yaklaşık 15-20 mühendisten önce genellikle vaktinden önce gelir. Bunun altında roller hâlâ gerçek zamanlı olarak icat ediliyordur; katı, belgelenmiş bir basamak, gerçeklik dokümandan saptığı an -ki sapacaktır- yanlış bir kesinlik ve kızgınlık yaratır.
Ekipler arası kalibrasyon komiteleri, yaklaşık 20-25 mühendisin altında haklı çıkarılamayacak bir koordinasyon yükü ekler. Bir yöneticinin yargısı artı bir üst yöneticinin sağlık kontrolü yeterlidir; kalibrasyonun düzeltmeyi amaçladığı tutarsızlık, ancak yeterli sayıda yönetici yeterli sayıda insanı puanladığında ve sapma görünür hale geldiğinde ortaya çıkar.
Her karar için zorunlu yazılı RFC'ler, tek bir Slack kanalında oturan altı kişilik bir ekibi yardımcı olduğundan daha fazla yavaşlatır. RFC disiplinini, kararlar kaybolmaya başladığında ya da farklı saat dilimlerine dağıldığınız anda getirin — öncesinde değil. (Bu geçişi tipik olarak tetikleyen organizasyonel eşikler için Mühendislik Ekibini 10'dan 50'ye Ölçeklendirme yazımıza bakın.)

Dördünde de örüntü aynı: bir sürecin çalıştırılmasının getirdiği yük, onun olmamasının koordinasyon maliyetini aştığında hak edilmiş olur. Bu eşiğin altında, o süreç sadece bir gösteridir.

Tekrar Tekrar Gördüğümüz Anti-Kalıplar

Her rol için, gerçekte ihtiyaç duyulan spesifik yetkinlikler yerine efsanevi bir "10x mühendis" arayarak mülakat yapmak
Adaylara ücretsiz olarak 8+ saat harcatan take-home testleri; bu, yeteneği değil işsizliği filtreler
Değerlendirme toplantısında "kültür uyumu"nun güçlü bir teknik değerlendirme kartını geçersiz kılmasına izin vermek
Belgelenmiş bir onboarding planının olmaması — yeni çalışanın ilk ayı "o gün kim müsaitse onunla gölge takip" şeklinde geçer
Gerçek değerlendirme konuşmalarında kimsenin başvurmadığı bir wiki sayfasında yaşayan bir kariyer basamağı
Ara dönem yazılı geri bildirim olmadan sadece yıllık performans değerlendirmeleri; bu yüzden yıllık değerlendirme, yöneticinin aylar önce gündeme getirmesi gereken sürprizlerle dolu olur
Deploy sıklığını veya PR sayısını bireysel mühendisleri birbirine karşı sıralamak için kullanmak
Psikolojik güvenliği her sprint'te modellenen bir liderlik davranışı yerine bir değerler posteri egzersizi olarak ele almak
"Muhtemelen sorun yok" diyerek yapay zeka destekli PR'ları daha hafif bir inceleme standardıyla merge etmek
Bir mühendisi kaybetmek, içeride "ücretle mi ilgiliydi" diye tartışmak ve bu soruyu gerçekten yanıtlayacak yapılandırılmış bir çıkış mülakatı programını hiç kurmamak

Sıkça Sorulan Sorular

Kıdemli bir yazılım mühendisini kaybetmenin ve yenisini bulmanın maliyeti nedir? SHRM'nin sıkça atıf alan %50-200 yıllık maaş aralığını referans alarak yapılan aşağıdan yukarıya bir hesaplama (işe alım, panel zamanı, boş pozisyon maliyeti, verime ulaşma süresi, bilgi aktarım yükü), genellikle temel maaşın %45-65'ine denk gelir — çoğu zaman bir elde tutma zammının maliyetinden fazlasına.

İyi bir take-home coding test nasıl olmalı? Yaklaşık 2 saatle sınırlı, ekibin gerçek işine yakın kapsamlı, yayınlanmış bir rubriğe göre değerlendirilen ve adayın muhakemesini açıkladığı canlı bir sunumla devam eden bir test — açık uçlu, ücretsiz, çok günlük bir proje değil.

Mühendis işe alımında "kültür uyumu" tuzağı nedir? "Kültür uyumu", mülakatçıya benzeyen adayları filtreleyen, rubriği olmayan öznel bir kriterdir. Bunun yerine, teknik yetkinliklerle aynı kanıt temelli rubrikte puanlanan, değer temelli ve yapılandırılmış "kültüre katkı" kriterleri kullanılmalıdır.

Psikolojik güvenlik nedir ve ekip performansını nasıl etkiler? Amy Edmondson'ın araştırmasına göre, ekibin kişilerarası risk almak için güvenli olduğuna dair paylaşılan bir inançtır — hata itiraf etmek, soru sormak, kıdemli meslektaşlara cezalandırılma korkusu olmadan itiraz etmek. Google'ın Project Aristotle araştırması, incelediği ekipler arasında bunu ekip etkinliğinin en güçlü tekil öngörücüsü olarak buldu.

DORA metrikleri bireysel performans değerlendirmesinde kullanılmalı mı? Hayır. DORA'nın dört anahtar metriği sistem ve ekip düzeyinde teslim metrikleridir; bunları bireysel performans değerlendirmelerine uygulamak, teslimi iyileştirmek yerine oyunlaştırmayı (PR'ları parçalara bölme, gerekli ama riskli refactor'lardan kaçınma gibi) teşvik eder.

Uzaktan çalışan mühendisler için 30/60/90 günlük oryantasyon planı nasıl hazırlanır? Yazılı bir 30/60/90 günlük planla: ortam ve erişim ilk günden önce hazırlanır, adı belirli bir buddy atanır, ilk hafta içinde gerçek bir ilk PR gönderilir, 60. güne kadar sahiplenme büyür ve 90. günde işe alımda kullanılan aynı değerlendirme kartına göre resmi, kalibre edilmiş bir değerlendirme yapılır.

İlgili Yazılar

Monolitten Mikroservislere Geçiş Rehberi — mühendislik ekibinizin doğru şekilde yürütmek için güçlü bir teknik yargıya ihtiyaç duyacağı mimari kararlar için
Mühendislik Ekibini 10'dan 50'ye Ölçeklendirme — bu yazının organizasyonel yapı ve ekip topolojisi konusundaki tamamlayıcısı
Yönetilen BT Hizmetleri vs Şirket İçi Mühendislik — bu yeteneği ne zaman içeride kuracağınıza, ne zaman dışarıdan destekle tamamlayacağınıza karar vermek için

D-Elite ile Çalışın

D-Elite Solutions, Türkiye ve Kanada'daki teknoloji ve düzenlemeye tabi sektörlerdeki scale-up'ların mühendislik liderlerine işe alım sistemleri, onboarding tasarımı ve elde tutma ekonomisi konusunda danışmanlık veriyor — bu, sunum teorisine değil, bu fonksiyonları bizzat yürütmüş olmamıza dayanan bir çalışma. Mühendislik organizasyonunuz beklemediğiniz insanları kaybediyorsa ya da işe alım süreçleriniz tutarsız sonuçlar üretiyorsa, ücretsiz danışmanlık görüşmesi ayırtın — mevcut mülakat sürecinizi, onboarding planınızı ve işten ayrılma verilerinizi birlikte gözden geçirelim; yükümlülük yok, satış konuşması yok.

htmljson { "@context": "https://schema.org", "@type": "FAQPage", "inLanguage": "tr", "mainEntity": [ { "@type": "Question", "name": "Kıdemli bir yazılım mühendisini kaybetmenin ve yenisini bulmanın maliyeti nedir?", "acceptedAnswer": { "@type": "Answer", "text": "SHRM'nin sıkça atıf alan %50-200 yıllık maaş aralığını referans alarak yapılan aşağıdan yukarıya bir hesaplama, genellikle temel maaşın %45-65'ine denk gelir, çoğu zaman bir elde tutma zammının maliyetinden fazlasına." } }, { "@type": "Question", "name": "İyi bir take-home coding test nasıl olmalı?", "acceptedAnswer": { "@type": "Answer", "text": "Yaklaşık 2 saatle sınırlı, ekibin gerçek işine yakın kapsamlı, yayınlanmış bir rubriğe göre değerlendirilen ve adayın muhakemesini açıkladığı canlı bir sunumla devam eden bir test, açık uçlu ve ücretsiz çok günlük bir proje değil." } }, { "@type": "Question", "name": "Mühendis işe alımında kültür uyumu tuzağı nedir?", "acceptedAnswer": { "@type": "Answer", "text": "Kültür uyumu, mülakatçıya benzeyen adayları filtreleyen, rubriği olmayan öznel bir kriterdir. Bunun yerine, teknik yetkinliklerle aynı kanıt temelli rubrikte puanlanan, değer temelli ve yapılandırılmış kültüre katkı kriterleri kullanılmalıdır." } }, { "@type": "Question", "name": "Psikolojik güvenlik nedir ve ekip performansını nasıl etkiler?", "acceptedAnswer": { "@type": "Answer", "text": "Amy Edmondson'ın araştırmasına göre, ekibin kişilerarası risk almak için güvenli olduğuna dair paylaşılan bir inançtır. Google'ın Project Aristotle araştırması bunu ekip etkinliğinin en güçlü tekil öngörücüsü olarak bulmuştur." } }, { "@type": "Question", "name": "DORA metrikleri bireysel performans değerlendirmesinde kullanılmalı mı?", "acceptedAnswer": { "@type": "Answer", "text": "Hayır. DORA'nın dört anahtar metriği sistem ve ekip düzeyinde teslim metrikleridir; bunları bireysel performans değerlendirmelerine uygulamak, teslimi iyileştirmek yerine oyunlaştırmayı teşvik eder." } }, { "@type": "Question", "name": "Uzaktan çalışan mühendisler için 30/60/90 günlük oryantasyon planı nasıl hazırlanır?", "acceptedAnswer": { "@type": "Answer", "text": "Yazılı bir 30/60/90 günlük planla: ortam ve erişim ilk günden önce hazırlanır, adı belirli bir buddy atanır, ilk hafta içinde gerçek bir ilk PR gönderilir, 60. güne kadar sahiplenme büyür ve 90. günde işe alımda kullanılan aynı değerlendirme kartına göre resmi bir değerlendirme yapılır." } } ] }