Performans değerlendirmen bir hafıza testidir

/ Yazı

Makine çevirisi. İngilizce aslını okuyun: Your performance review is a memory test →

Herhangi bir mühendislik yöneticisine en iyi mühendisinin kim olduğunu sorun. Cevap, soruyu bitirmenizi beklemeden gelir; tereddütsüz, “önce bir şeye bakayım” demeden. Bilirler. Hep bilmişlerdir.

Şimdi onlardan işi göstermelerini isteyin.

Bir hikaye alırsınız. Genellikle iyi bir hikaye: birinin gece 2’de hallettiği bir olay ya da bir çeyreğin önünü açan bir refactor. Almayacağınız şey ise bir sayı, bir karşılaştırma ya da yöneticinin odasında bulunmadığı dört mühendisin işine dair herhangi bir hesaptır. Bu güven, hatırlamanın üzerine kuruludur ve hatırlama, yakınlığın bir fonksiyonudur.

Tez şu: Mühendislik performansı hafızadan değerlendirilir, hafıza görünürlüğü değere tercih eder ve insanların gerçekten yapmasını istediğiniz iş, onları değerlendirdiğiniz şeye asla bağlanmayan bir roadmap’te yazılıdır. Bu iki belgenin, benimki de dahil olmak üzere gördüğüm neredeyse her şirkette birbiriyle hiçbir ilgisi yoktur.

Bu yüzden onları bağladık. Birleştirilen her pull request bir model tarafından okunur, bir önem derecesi atanır ve dokunduğu bileşenin roadmap’imizde ne kadar önemli olduğuyla çarpılır. Sonuç aylık bir leaderboard’dur ve bonus kararlarını besler. İşte bizimki.

Yedi geliştiriciyi puana göre sıralayan, 3530'dan 300'e kadar uzanan GitRank leaderboard'u.
Platform deposumuz için 30 günlük leaderboard, Ağustos 2026. Yedi geliştirici, aralarında toplam 10.415 puan.

Genel kabul gören görüş bunun ölçülemeyeceğidir ve genel kabul gören görüş bir omuz silktir

Bireysel çıktıyı ölçmenin standart pozisyonu, yapmamanız gerektiğidir, çünkü her vekil bir tuzaktır. Satır sayısı şişkinliği ödüllendirir. Commit sayısı bölmeyi ödüllendirir. Kapatılan ticket, önce küçük olanları kapanı ödüllendirir. Story point’ler, iş başlamadan önce yapılan bir pazarlıktır. İyi framework’ler bile bilinçli olarak takım seviyesindedir: DORA, teslimat pipeline’ı hakkında dört şey ölçer ve yazarlarının açıkça belirttiği gibi insanlar hakkında hiçbir şey söylemez.

Bunların hepsi doğrudur ve hiçbiri bir cevap değildir. Sıralama yine de olur, her yıl, zam zamanında, bir odada, hafızadan, o odadaki kişinin yanında oturduğu kişiye göre ağırlıklandırılarak. Ölçmeyi reddetmek, denetim izi ve itiraz hakkı olmayan bir sıralama satın alır.

Buna gürültülü mühendis primi diyelim: nasıl değerlendirildiğiniz ile nasıl performans gösterdiğiniz arasındaki fark, tamamen sizi değerlendiren kişiye olan uzaklığınızla açıklanır. Herhangi bir insandan, on beş kişinin teknik katkılarını bir yıl boyunca yalnızca fark ettikleri şeyleri kullanarak karşılaştırmasını isteyin; ortaya çıkan şey budur. Herhangi birimiz bunu üretiriz.

Bu prim, yaklaşık iki yıl öncesine kadar kaçınılmazdı, çünkü daha iyi bir cevap için gereken ham madde, kimsenin okumaya vakti olmadığı bir yığın diff’ti. Bu kısıt ortadan kalktı. Bir model, her ay deponuzdaki her diff’i, şu anda tahmin yürüttüğünüz toplantının maliyetinden daha ucuza okuyabilir. Okumak kolay kısım. Okumanın ne değerinde olduğuna karar vermek asıl sorundur ve bu teknik bir soru değildir.

Formülün tamamı tek satıra sığıyor

İşte tamamı, GitRank’teki puanlama yolundan:

final_score = is_eligible ? severity_base_points × component_multiplier : 0

Bunu blog için basitleştirmedim. Çalıştığı haliyle satırın kendisi; gizli regresyon yok, öğrenilmiş ağırlık yok, itibar terimi yok, kıdem ayarlaması yok. Önem derecesi çarpı önem, ya da sıfır.

Önem derecesi, bir kez belirlenen ve puanlanan herkesin görebildiği sabit bir merdivendir.

Önem derecesi yapılandırması: P0 Kritik 100 puan, P1 Yüksek 50 puan, P2 Orta 20 puan, P3 Düşük 5 puan.
Önem derecesi başına temel puanlar. Etiketi bir model atar; puan değerleri bizimdir.

Kritik bir düzeltme, yirmi düşük öncelikli düzeltmeye bedeldir. Bu oran bir politika beyanıdır ve bunu birinin kafasında bırakmak yerine yazıya döktük.

Önem, asıl önemli olan yarıdır. Her bileşen bir çarpan taşır ve çarpan, ürünün bu çeyrekte ihtiyacı olan şeydir.

Platform deposu için bileşen yapılandırması: önem seviyelerine sahip 20 bileşen. Chat 2x ile Kritik, Agents 1.5x ile Yüksek, API ve Authentication 1x ile Normal.
Yirmi bileşen, dört önem kademesi. Kritik 2.0x, Yüksek 1.5x, Normal 1.0x, Düşük 0.5x.

Chat 2.0x çünkü chat, ürünü üzerine bahse girdiğimiz şey. Authentication 1.0x çünkü çalışıyor ve sessizce çalışmaya devam etmesini istiyoruz. Bunlar ürün kararlarıdır ve çarpan tablosu, onların ödeme yapan bir alana yeniden yazıldığı yerdir.

Strateji belgesi ile zam girdisi aynı belge haline geldi. Asıl hamle bu. Model tesisat, leaderboard da bunun bir görselleştirmesi ve roadmap Ekim’de değişirse teşvik de Ekim’de değişir; on dört ay sonraki bir değerlendirme döngüsünde değil.

Bunu açıkça söyleyeyim, çünkü insanların atladığı kısım bu. Yerel olarak ve dürüstçe optimize eden kırk akıllı insan, şirketin istediğini söylediği şeye denk gelmeyen bir çeyreklik iş üretir. Bu resimde kimse tembel değildir, zor olan da budur. Orta yönetim büyük ölçüde bunu düzeltmek için vardır; stratejiyi masadan masaya sohbetle taşır ve her adımda doğruluğu kaybeder. Bir çarpan tablosu aynı yönlendirmeyi tek adımda yapar ve Ekim’de hâlâ Ocak’ta yazdığınız şeyi söyler.

Joi Ito bu farkı zaten adlandırmıştı. Jeff Howe ile 2016’da yazdıkları Whiplash’teki dokuz ilkeden biri itmek yerine çekmek (pull over push): her şeyi stokta tutmak yerine ihtiyacın olduğunda ağdan çekersin. Ito kaynakları anlatıyordu. Yön de aynı şekilde davranır. İten bir organizasyon stratejiyi yönetim katmanında stoklar ve sohbetlerde dağıtır; bu yüzden şirketin ucuna geç ve kayıplı ulaşır. Çeken bir organizasyon stratejiyi bir fiyat listesi olarak yayınlar ve insanların ihtiyaç duyduklarını almasına izin verir. Çarpan tablosu da fiyat listesidir.

Sohbetteki kritik bir düzeltme, API’deki kırk cilalama commit’ine bedel

İki yarıyı birleştirince fark ciddi. Sohbetteki bir P0, 100 taban çarpı 2.0’dan 200 puan eder. API’deki bir P3 ise 5 puan. Kırka bir. Bu, burada birleştirebileceğiniz en değerli pull request ile en değersizi arasındaki fark.

Bu oran bilerek şiddetli ve nazik teşviklerin asla başaramadığını yapıyor. Kimse haftasını %15’lik bir fark için yeniden düzenlemez. İnsanlar haftasını kesinlikle 40 katlık bir fark için yeniden düzenler.

6 Temmuz'dan 3 Ağustos'a kadar haftalık PR önem derecesini gösteren yığılmış çubuk grafik; 13 Temmuz haftası 1 P0, 50 P1, 111 P2 ve 26 P3 gösteriyor.
13 Temmuz 2026 haftası: 1 P0, 50 P1, 111 P2, 26 P3. 188 birleştirilmiş pull request.

Tek bir haftada 188 pull request. Bunların %59’u P2; her yerde normal bir mühendislik haftası böyle görünür. Şimdi ağırlıklandırın. Bu 111 P2, 2.220 puan eder. 50 P1 ise 2.500 puan. Yarısından az sayıdaki pull request, haftanın değerinin yarısından fazlasını taşıyor. Pull request’leri sayarsanız haftanın P2’lerle geçtiği sonucuna varırsınız. Ağırlıklandırırsanız hafta elli belirli iş parçasıyla ilgiliydi ve kimin yaptığını sayabilirsiniz.

İki kişi çıktının %58’iydi ve sıralamayı yanlış tahmin etmiştim

Yedi geliştirici, 10.415 puan. İlk sıradaki geliştirici bunların 3.530’una sahip; ekibin değer olarak ürettiği her şeyin %33,9’u. İlk ikisi birlikte %57,7’sini tutuyor.

Böyle bir yoğunlaşma genellikle ilk ikisinin en yüksek çarpanlı bileşenler üzerinde çalıştığı anlamına gelir; biz de tam olarak onlardan bunu istemiştik. Bu sayı değerin nereye düştüğünü anlatır ve diğer beş kişi hakkında bundan bir sonuç çıkarmam.

Sıralama tahminimi bozan şeydi.

Bileşen uzmanları paneli: Mulualem-E, 230 PR'ın 71'iyle Chat'in ve 148 PR'ın 86'sıyla Agents'ın birincil uzmanı. abrehamgezahegn Enterprise özelliklerinde önde.
Bileşen başına birincil katkıcı. Tek bir kişi en yoğun iki alanın da önde gelen uzmanı.

Mulualem-E, 2.0x çarpanlı bileşenimiz chat’in 230 pull request’inin 71’inde ve 1.5x çarpanlı bileşenimiz agents’ın 148’inin 86’sında birincil uzman. Bunu bana anlatıp liderlik tablosunda kimin zirvede olduğunu sorsaydınız, duraksamadan onu söylerdim. İkinci. Zirve, Mulualem-E’nin 12’sine karşı 31 P1 pull request ile tugberkayartextcortex’e gidiyor.

Önem derecesi karışımı, bileşen sahipliğini yendi. Ürünün en önemli alanına sahip olmak, o alanda tekrar tekrar yüksek etkili iş çıkarmakla aynı şey değilmiş; bunu yayınlayana kadar ücretlendirmemizin ikisinden hangisini ödüllendirdiğini size söyleyemezdim. Hangisini fark ettiysem onu ödüllendiriyordu. Bu, gürültücü mühendis primi; kendi şirketimde yakalandı. Sezgim doğru iki kişiyi ama yanlış sırayı bulmuştu ve ikramiye, işte o yanlış sıradan ibarettir.

Payments %45 hata düzeltmesi ve kimse bunu tartışmak zorunda kalmadı

Her pull request’i puanlamak, kaliteyi anekdottan tartışma alışkanlığını da bitiriyor.

Bileşen etkinliği tablosu: Chat 230 PR ve 57 hata, Agents 148 PR ve 57 hata, Diğer 81, Enterprise özellikleri 59, Presentation maker 58 ve 23 hata, Payments 44 ve 20 hata, ve beş bileşen daha.
En yoğun on bileşen, 6 Temmuz - 3 Ağustos 2026. 740 pull request, 230'u hata düzeltmesi.

En yoğun on bileşende 740 pull request; 230’u yeni iş değil, hata düzeltmesi. Sadece chat 230 pull request; çalışan bir 2.0x çarpanı böyle görünür. Sonra payments: 44 pull request, 20 hata; paraya dokunan bileşende %45 hata oranı.

Hata yoğunlukları halka grafiği: Chat 57, Agents 57, Presentation maker 23, Payments 20, Integrations 19.
Bileşene göre kritik hatalar. Chat ve agents 57'şer ile eşit.

Chat ve agents 57’şer hatayla eşit, ancak chat bunları 230 pull request’te, agents ise 148’de üretti. Aynı hata sayısı, birinin arkasında %55 daha fazla iş. Bu, agents hakkında hiçbir retrospektifin yüzeye çıkaramayacağı bir sinyal; çünkü kimse ikisinden de fark edecek kadar birleştirmemişti.

6 Temmuz'dan 3 Ağustos'a kadar hata düzeltmeleri ile özellik geliştirmeyi karşılaştıran alan grafiği; özellikler yaklaşık 140'a, hatalar yaklaşık 75'e yükseliyor.
Aynı beş haftada hata düzeltmeleri ile özellik geliştirme.

Hatalar ve özellikler birbirini götürmek yerine birlikte yükseliyor. Beş hafta, tek bir büyük projenin inişe geçmesinin üreteceği gürültünün tam içinde; o yüzden bu grafiği dönemin bir tanımı olarak görün, başka bir şey değil.

Elimde bir iyileşme rakamı yok ve elinde olan kimseye de güvenmemelisiniz

İddia etmek istediğim şey şu: Bu aylık yayını başlattığımızdan beri, iş, önemli olarak işaretlediğimiz bileşenlere kaydı, çünkü mühendisler skoru istiyor.

Buna bir yüzde koymuyorum. Bunu işin ortasında devreye aldık. Ne bir taban çizgisi ne de kontrol deposu vardı ve “kayma”nın ne anlama geleceğini önceden hiç kararlaştırmadık. Çarpanlar bu dönem içinde değişti. Personel sayısı da. Yayınlayacağım herhangi bir rakam, verileri gördükten sonra seçtiğim bir rakam olurdu ki bu da onu süsleme yapar.

Değişen şey tartışmanın kendisi. İnsanlar işlerinin takdir edilip edilmediğini sormayı bırakıp bir bileşenin neden 1.0x olarak derecelendirildiğini sormaya başladı. Bu, yapılması daha iyi olan bir tartışma ve tek başına bunun için para öderdim.

Bizim kendi aracımız da temiz değil ve en keskin kenarı şu: sıfır puan alan bir pull request, hangi uygunluk kriterinin onu kapattığını söylemiyor. Issue bağlantısını ya da testleri kaçırın ve önem derecesinden bağımsız olarak skor sıfır olur; en çok tartışacak kişiye, tartışacak en az şey verilir. Bunu listedeki her şeyden önce düzeltiyoruz.

Yol haritasına doğrultun, sonra cetveli insanlara verin

Bir organizasyon şemasından yetkiyi sıyırın ve altta kalan şey bir yönlendirme tablosudur. “Bu çeyrekte neyin önemli olduğunu” karar veren insanlardan dışarı taşır ve “kim ne yaptı”yı içeri geri getirir; ikisini de yavaşça ve her atlamada bozulmayla yapar. Kurumsal siyasetle ilgili sevmediğiniz her şey, o yönlendirmenin bir sıkıştırma artefaktıdır. Yöneticiler bu iş için mevcut olan tek donanımdı.

Artık tek mevcut donanım onlar değil. Her diff’i okuyan bir model, artı bir çarpan tablosu, dışa yönlendirmeyi tek atlamada ve içe yönlendirmeyi bir sorguda yapar. Bu, çekme organizasyonudur ve sınırları konusunda kesin olmak istiyorum. Hiçbir şey düzleşmez. Liderlik hâlâ çarpanları belirler, yani strateji hâlâ bir odada birkaç kişi tarafından kararlaştırılır ve değişen tek şey o odadan çıkış yolculuğudur. İnsanlara kalan şey, her zaman işin kendisi olan ama hiç zaman bulamayan kısımdır: çarpanların ne olması gerektiğine karar vermek ve bu kararların etkilediği insanlarla oturmak.

Siyaset kaybolmaz. Yer değiştirir. “Yöneticim çeyreğimi hatırlıyor mu”dan “yol haritası onu çekirdek olarak adlandırırken bileşenim neden 1.0x olarak derecelendirildi”ye taşınır ve bu ikinci tartışma, şirketin gerçek stratejisiyle ilgilidir; herkesin okuyabileceği bir tabloda, herkesin önünde yürütülür. Bu tartışmayı her ay yapmayı, mevcut tartışmayı yılda bir kez, özel olarak, on bir ayı hafızadan yeniden kuran biriyle yapmaktan tercih ederim.

Birisi bunu kötü yürütecek. Birisi duvara, uygunluk açıklamaları ve geçersiz kılma izi olmayan bir skor tablosu asacak ve alt dilimi işten çıkaracak ve bu, çarpanları seçen kişiye değil, modele yüklenecek.

O hâlde beni de aynı araçla ölçün. Bunun gibi bir şey yürütüyorsanız, çarpan tablosunu yayınlayın ki insanlar skorla değil stratejiyle tartışsın. Pull request başına dökümü yayınlayın ki sıfır alan herkes hangi kapının kendisine kapandığını görsün ve itiraz edebilsin. Geçersiz kılma günlüğünü yayınlayın, çünkü bir insanın elle değiştirdiği sayı, denetlemeye değer tek sayıdır. Birincisini yayınlıyoruz. Üçüncüsünü kötü yapıyoruz. İkincisini hiç yayınlamıyoruz ve bu, böyle bir şeyin bir yönetim aracı mı yoksa haksız olmanın daha hızlı bir yolu mu olduğuna karar veren şey.


GitRank gitrank.dev adresindedir ve CC BY-NC 4.0 lisanslıdır. Üretim hattındaki puanlama, 0.3 sıcaklıkta Claude Haiku 4.5 üzerinde çalışır. Yukarıdaki tüm rakamlar, 6 Temmuz ile 3 Ağustos 2026 arasında kendi platform depomuzdan gelmektedir; örneklem büyüklüğü bir şirket ve yedi geliştiricidir; bu, bizim bir tanımımızdır ve herhangi bir şeyin kıyaslaması değildir.