Metrik EM: Kecepatan Pengiriman, Kualitas, Retensi Karyawan, Perekrutan

Pertama kali saya masuk ke QBR dengan grafik story point, VP saya membiarkan saya berbicara sekitar sembilan puluh detik sebelum berkata, "Camellia, berapa atrisi yang disesalkan Anda? Dan frekuensi deploy Anda? Lupakan poinnya."

Saya tidak memiliki satu pun angka itu. Saya memiliki grafik batang berwarna indah tentang kecepatan pengiriman per sprint dan slide berjudul "Throughput Q3 +18%." Tidak ada yang bertahan menghadapi pertanyaan tersebut. Ia tidak kasar. Ia jujur. Lapisan eksekutif mendanai hasil. Saya membawa aktivitas. Kami tidak berbicara dalam bahasa yang sama, dan percakapan anggaran yang mengikutinya hangat seperti yang bisa Anda bayangkan.

Rapat itu mengubah cara saya menjalankan dasbor. Panduan ini adalah dasbor yang ingin saya miliki: enam metrik, rentang angka nyata, diagnosis yang disebutkan, satu slide QBR. Tidak lebih, karena lebih itulah cara hukum Goodhart memakan Anda.

Mengapa hasil mengalahkan throughput

Metrik throughput (story point, tiket ditutup, baris kode, jam yang dicatat) mengukur aktivitas. Aktivitas adalah apa yang dilakukan tim Anda. Hasil adalah apa yang didapat perusahaan. Lapisan eksekutif mendanai hasil: kecepatan pengiriman, keandalan, ketahanan tim, throughput perekrutan. Jika Anda tidak bisa menerjemahkan pekerjaan tim Anda ke dalam empat kategori tersebut, Anda akan terpotong dari percakapan headcount, dan Anda tidak akan melihatnya datang sampai pembekuan penawaran mendarat di kotak masuk Anda.

Ada alasan kedua. Metrik throughput mudah dimanipulasi tanpa ada yang bermaksud demikian. Beri tahu tim bahwa Anda mengukur tiket yang ditutup dan dalam satu kuartal Anda akan mendapat tiket yang lebih kecil. Beri tahu mereka bahwa Anda mengukur story point dan dalam dua kuartal Anda akan mendapat inflasi yang membuat bankir sentral pun tersipu. Metrik hasil lebih sulit untuk dimanipulasi karena terikat pada kenyataan. Deploy itu terjadi atau tidak, engineer itu bertahan atau pergi, penawaran itu diterima atau ditolak.

Jadi: enam metrik. Empat untuk pengiriman dan keandalan, dua untuk kesehatan tim. Itulah set-nya.

Frekuensi deploy

Seberapa sering kode tim Anda mencapai produksi? Harian, mingguan, bulanan, atau lebih jarang. Ini adalah metrik DORA pertama dan sinyal terbersih tentang apakah alur pengiriman Anda benar-benar sebuah alur atau serangkaian pintu terkunci dengan kunci manual.

Tingkat target per kematangan tim:

Sebagian besar tim produk harus berada di Tinggi. Jika Anda berada di Menengah dan pekerjaan membenarkannya (industri yang diatur, siklus QA panjang), katakan demikian di slide. Jika Anda berada di Rendah dan Anda adalah tim SaaS, itu adalah temuan, bukan angka.

Lead time untuk perubahan

Waktu dari commit ke produksi. Ini adalah metrik DORA kedua dan yang memberi tahu Anda di mana letak hambatan sesungguhnya. Jam, hari, atau minggu.

Saat Anda mengukur ini dan memecahnya, Anda biasanya menemukan salah satu dari tiga pelaku: tinjauan kode (PR duduk terbuka selama dua hari menunggu senior yang sedang rapat), CI (rangkaian tes membutuhkan 47 menit dan flakes sekali dari lima), atau deploy gate (persetujuan manual yang ada di kalender seseorang). Pilih yang terpanjang dan perbaiki. Jangan mencoba memperbaiki ketiganya sekaligus.

Rentang sehat berdasarkan jenis tim:

• Tim produk, aplikasi web: di bawah 24 jam, idealnya di bawah 8.
• Tim platform, infra: di bawah 48 jam.
• Tim mobile: 3-7 hari, dibatasi oleh review app store.

Jika lead time Anda dua minggu dan frekuensi deploy Anda harian, ada yang secara matematis salah. Anda mungkin men-deploy sebagian besar perubahan sepele sementara yang besar membusuk, atau Anda salah menghitung. Selidiki sebelum Anda menampilkan slidenya.

Tingkat kegagalan perubahan

Persentase deploy yang menyebabkan rollback, hotfix, atau insiden produksi. Metrik DORA ketiga. Rentang target adalah 0-15%, dengan tim sehat berada di 5-10%.

Dua hal yang perlu diperhatikan. Pertama, tingkat kegagalan perubahan nol adalah tanda peringatan, bukan kebanggaan. Biasanya berarti tim Anda terlalu banyak melakukan pengujian, deploy terlalu jarang, atau menghitung insiden terlalu sedikit. Kedua, metrik ini memiliki lantai alami. Perangkat lunak itu sulit, manusia men-ship bug, dan tingkat 2% adalah noise, bukan sinyal penurunan. Jangan mengejar persen terakhir dengan mengorbankan kecepatan pengiriman.

Ketika tingkat kegagalan perubahan melampaui 15%, diagnosisnya hampir selalu salah satu dari: cakupan pengujian yang tidak memadai pada jalur kritis, proses rilis yang mengelompokkan terlalu banyak (sehingga kegagalan menjadi kusut), atau rekrutan baru yang men-ship ke produksi sebelum mereka memahami radius dampak. Sebutkan yang mana. Jangan merata-ratakannya.

MTTR

Mean time to restore. Ketika ada yang rusak di produksi, berapa lama sampai berfungsi lagi? Jam, bukan hari. Ini adalah metrik DORA keempat dan yang paling terkait dengan kebersihan on-call.

MTTR yang baik adalah di bawah 4 jam untuk produk SaaS. Di bawah 1 jam untuk tim elite. Triknya adalah MTTR sebenarnya bukan tentang seberapa cepat Anda bisa menulis perbaikan. Ini tentang seberapa cepat Anda bisa mendeteksi, mendiagnosis, dan men-deploy. Sebagian besar MTTR lambat yang saya debug berasal dari salah satu dari tiga tempat: alerting yang tidak menyala (sehingga tim mengetahui pemadaman dari pelanggan), runbook yang tidak ada (sehingga engineer on-call harus mencari tahu dari awal), atau alur deploy yang membutuhkan 90 menit (sehingga bahkan setelah perbaikan ditulis, Anda menunggu).

Jika MTTR merangkak naik, lihat beban on-call. Engineer on-call yang kelelahan kerja adalah engineer on-call yang lambat. Ini adalah metrik di mana frekuensi deploy, tingkat kegagalan perubahan, dan kesehatan tim saling bersentuhan.

Atrisi yang disesalkan 12 bulan

Metrik kesehatan tim pertama dari dua, dan yang paling dipedulikan VP Anda.

Atrisi yang disesalkan hanya menghitung orang yang ingin Anda pertahankan. Jika low performer pergi, itu tidak menyesalkan. Jika engineer mid-level yang stabil yang tidak pernah membuat gelombang pergi dan Anda hanya mengangkat bahu, itu tidak menyesalkan. Jika IC senior, tech lead, atau junior bertrajectory tinggi pergi, itu menyesalkan. Jujurlah pada diri sendiri ketika Anda melabelinya. Manajer cenderung secara retroaktif memutuskan bahwa semua yang pergi "tidak cocok," itulah cara Anda berakhir dengan 0% atrisi yang disesalkan dan tim yang setengah sudah pergi.

Baseline industri untuk teknologi, 2026:

• Sehat: 8-12% tahunan.
• Zona pengamatan: 13-15%.
• Darurat: di atas 15%.
• Darurat lima alarm: di atas 20%.

Lacak pada basis 12 bulan bergulir, bukan per kuartal kalender. Angka kuartalan terlalu bising pada tim kecil. Jika Anda memiliki delapan engineer dan satu kepergian yang disesalkan di Q2, itu 12,5%: baik pada basis bergulir, menakutkan pada grafik kuartalan.

Tingkat penerimaan tawaran perekrutan ditambah waktu adaptasi

Metrik kesehatan tim kedua, dan yang memberi tahu Anda apakah tim Anda bisa tumbuh.

Dua sub-metrik, satu baris slide. Tingkat penerimaan tawaran: dari penawaran yang Anda perpanjang kuartal lalu, berapa persen yang diterima? Target adalah 70% atau lebih tinggi. Di bawah 60% berarti penawaran Anda tidak kompetitif (biasanya kompensasi, kadang jabatan, sesekali cerita).

Waktu adaptasi: dari tanggal mulai hingga PR non-sepele pertama yang di-merge ke produksi, berapa hari? Target di bawah 30. Jika rata-rata rekrutan baru Anda membutuhkan 60 hari untuk men-ship sesuatu yang nyata, orientasi karyawan Anda rusak atau codebase Anda seperti labirin. Bagaimanapun, itu adalah temuan.

Kedua angka bersama-sama menceritakan kisah perekrutan. Tingkat penerimaan tinggi, ramp cepat: mesin perekrutan bekerja. Tingkat penerimaan tinggi, ramp lambat: Anda menjual dengan baik, Anda orientasi dengan buruk. Tingkat penerimaan rendah, ramp cepat: ketika orang bergabung mereka berkembang, tapi Anda tidak bisa menutup. Tingkat penerimaan rendah, ramp lambat: mesinnya rusak di kedua ujungnya.

NPS Engineering

Survei denyut kuartalan, satu pertanyaan: "Apakah Anda akan merekomendasikan tim ini kepada engineer lain?" Skala nol hingga sepuluh. Kurangi detractor (0-6) dari promoter (9-10), abaikan passive (7-8). Hasilnya antara -100 dan +100.

Tim engineering yang sehat mendapat skor 30-50. Di atas 50 sangat baik. Di bawah 20 adalah peringatan. Negatif adalah kebakaran yang sudah dimulai; Anda belum melihat asapnya.

Jalankan di minggu yang sama setiap kuartal. Anonim. Selalu sertakan satu tindak lanjut open-ended: "Apa satu hal yang akan meningkatkan skor Anda satu poin?" Baca setiap respons. Angkanya adalah headlinenya; komentarnya adalah diagnosisnya.

Diagnostik "kecepatan pengiriman tinggi tapi turnover tinggi"

Inilah arketipe yang mengejutkan sebagian besar EM. Frekuensi deploy tinggi. Tingkat kegagalan perubahan rendah. Lead time sangat baik. MTTR solid. Berdasarkan empat metrik DORA, tim ini men-ship seperti juara.

Dan atrisi yang disesalkan meningkat. NPS Engineering turun. Orang yang ingin Anda pertahankan pergi.

Tim men-ship dalam perjalanannya keluar dari perusahaan.

Saya pernah mengalami ini sekali. Kami melakukan 60 deploy per bulan, tingkat kegagalan perubahan 4%, MTTR di bawah 90 menit, dan saya kehilangan tiga engineer dalam satu kuartal, dua di antaranya senior. Dasbor metrik berbohong dengan kelalaian. Kebenarannya muncul dalam wawancara keluar: "Saya lelah." "Saya belum berkembang dalam 18 bulan." "Teman saya di pesaing mendapat 30% lebih untuk pekerjaan yang sama."

Biasanya ada tiga penyebab, dan sering kali saling menumpuk:

1. Kelelahan kerja. Kecepatan pengiriman tinggi bisa dipertahankan selama satu kuartal, kadang dua. Lebih dari itu, Anda meminjam dari masa depan tim.
2. Kesenjangan gaji. Pasar bergerak, band Anda tidak, dan senior Anda mengetahuinya karena mereka mendapat pesan LinkedIn setiap hari Selasa.
3. Tidak ada jalur pertumbuhan. Orang-orang bertahan ketika mereka belajar. Begitu codebase terasa kecil, mereka mencari yang lebih besar.

Sebutkan penyebabnya di slide. Jangan merata-ratakannya menjadi "orang-orang pergi, kami akan mengerjakan keterlibatan." Kalimat itu tidak pernah menyelamatkan tim.

Metrik semu yang harus berhenti dilaporkan

Hukum Goodhart: ketika sebuah ukuran menjadi target, ia berhenti menjadi ukuran yang baik. Setiap metrik dalam daftar ini, termasuk enam di atas, rentan. Tapi empat ini cukup rentan sehingga Anda harus melepasnya sepenuhnya:

• Story point yang diselesaikan. Inflasi dijamin. Men-ship story yang lebih kecil diframe sebagai yang lebih besar. Tidak memberi tahu Anda apa yang mencapai produksi.
• Tiket yang ditutup. Masalah yang sama, papan skor yang berbeda. Mendorong tiket untuk bertambah banyak.
• Baris kode. Ukuran pengetikan, bukan rekayasa. Menghukum penghapusan, yang biasanya PR terbaik.
• Jam yang dicatat. Mengukur kehadiran, bukan output. Menghukum orang tua dan memberi penghargaan kepada pesan Slack larut malam yang performatif.

Ganti mereka. Story point dan tiket menjadi frekuensi deploy dan lead time. Baris kode menjadi tingkat kegagalan perubahan. Jam yang dicatat menjadi NPS Engineering, karena jika tim Anda sehat dan men-ship, Anda tidak perlu menghitung jam.

Slide QBR

Satu slide, enam baris metrik, tiga kolom: saat ini, target, panah tren. Tambahkan satu kalimat diagnosis per baris. Itulah formatnya.

Contoh tata letak:

Enam baris. Enam diagnosis. Tanpa story point. Tanpa grafik kecepatan pengiriman tersembunyi di lampiran. Jika suatu angka buruk, katakan terus terang dan sebutkan apa yang Anda lakukan. VP mempercayai EM yang menyebutkan masalah lebih cepat dari yang VP akan temukan sendiri. Mereka tidak mempercayai EM yang menyembunyikannya.

Apa yang harus diminta kepada VP Anda

Tutup QBR dengan pertanyaan, bukan tur kemenangan. Tanyakan dua dari enam metrik mana yang paling penting bagi perusahaan kuartal ini, dan rentang target seperti apa yang akan dianggap sebagai kemenangan.

Mencoba mengoptimalkan keenamnya sekaligus adalah cara Anda tidak mendapatkan apa-apa. Tim yang mengerjakan kecepatan pengiriman tidak juga mengerjakan throughput perekrutan, dan tim yang mengerjakan perekrutan akan mengalami hit sementara pada lead time sementara senior mewawancarai kandidat alih-alih meninjau PR. Pilih dua. Dapatkan keselarasan pada targetnya. Ajukan pertanyaan yang sama kuartal berikutnya.

Jika VP Anda mengatakan "semua enam," dorong kembali dengan lembut. Katakan: "Jika saya harus kurang berinvestasi dalam dua di antaranya kuartal ini untuk benar-benar berinvestasi dalam dua lainnya, mana dua yang harus saya deprioritaskan?" Pertanyaan itu hampir selalu mendapat jawaban nyata, karena itu memaksa trade-off ke terbuka.

Inilah versi QBR yang seharusnya saya masuki pertama kali. Enam metrik. Angka nyata. Diagnosis yang disebutkan. Satu slide. Grafik story point tetap tersimpan di laci tempatnya berada.

Pelajari Lebih Lanjut

• Kadens 1:1 yang Benar-Benar Bekerja
• Menjalankan Rotasi On-Call tanpa Membakar Tim
• Tinjauan Kinerja untuk Engineer tanpa Teater
• Merekrut Senior Engineer di Pasar yang Ketat
• Companion JD: Staff Software Engineer