Belajar Staff Engineer - Data & Metrics for Decisions

#Pendahuluan

Setelah di episode 14 kita membangun program reliability dengan SLO dan error budget, pada episode ini kita generalisasi skill di baliknya: data & metrics for decisions. Hampir semua argumen staff engineer bertumpu pada angka — angka yang dipercaya. Engineer yang datanya benar bisa mengarahkan organisasi mana pun; engineer dengan opini tajam tapi tanpa data akan kalah oleh slide siapa pun yang membawa grafik.

Kita bedah cara memilih metrik yang jujur, jebakan psikologisnya, dan cara merangkai metrik menjadi framework yang mendukung keputusan nyata — bukan sekadar dashboard dekoratif.

#Anatomi Metrik yang Berguna

Empat dimensi yang perlu dipahami sebelum memakai metrik apa pun:

#Leading vs Lagging

• Lagging — hasil akhir yang terlambat muncul: revenue, churn, jumlah insiden tahunan. Bagus untuk evaluasi, buruk untuk navigasi (kalian sudah menabrak saat tahu).
• Leading — sinyal awal yang memprediksi hasil: lead time deployment, coverage error handling, adopsi golden path. Bagus untuk mengarahkan pekerjaan hari ini.

Program kalian butuh keduanya: leading untuk kemudi harian, lagging untuk pembuktian dampak.

#Absolute vs Relative

"Latensi p95 420 ms" sendirian tidak bermakna. 420 ms dibanding 380 ms bulan lalu, atau vs target SLO 300 ms — barulah bercerita. Selalu sertakan pembanding: tren waktu, baseline, target, atau benchmark kompetitor.

#Proxy Metrics

Metrik pengganti ketika metrik sesungguhnya sulit diukur ("kepuasan developer" → time-to-first-deploy). Proxy sah asal dua syarat terpenuhi: ada alasan kausal yang masuk akal, dan kalian sadar ia proxy — uji ulang berkala apakah hubungannya masih berlaku.

#Vanity Metrics

Angka yang selalu naik dan membuat senang tanpa bisa ditindaklanjuti: total sign-up kumulatif, jumlah baris kode, jumlah PR. Ciri pembedanya: tidak ada keputusan yang berubah karena angka itu. Buang dari rapat keputusan.

#Goodhart's Law dan Cara Melawannya

Hukum Goodhart: ketika sebuah ukuran menjadi target, ia berhenti menjadi ukuran yang baik. Contoh klasik engineering:

| Metrik Dijadikan Target | Perilaku Merusak yang Muncul | |------| | Jumlah bug ditutup | Bug dilaporkan sebagai banyak tiket kecil; duplikasi | | Coverage test 100% | Test tanpa assertion demi centang coverage | | Velocity sprint naik | Estimasi digelembungkan; story dipecah kosong | | Deploy frequency | Deploy kosong berkali-kali dalam sehari |

Strategi melawan:

1. Pasangkan metrik dengan counter-metric — deploy frequency ↑ dipasangkan change failure rate ↓; coverage dipasangkan mutation score atau insiden regresi.
2. Gunakan metrik untuk belajar, bukan hukuman — begitu angka jadi alat KPI personal, integritasnya mati.
3. Rotasi dan audit definisi — tinjau tiap enam bulan: apakah metrik ini masih menjawab pertanyaan yang kita pedulikan?

#Kerangka Metrik untuk Inisiatif

Untuk setiap inisiatif besar (episode 7), rangkai metrik dalam tiga lapis:

LAPIS 1 - Input/aktivitas (apakah kami bekerja?)
  - Layanan on golden path / total layanan
  - Persentase pipeline template terpakai
 
LAPIS 2 - Output/proses (apakah sistem membaik?)
  - Lead time rilis: 9 hari -> target 1 hari
  - Change failure rate: 30% -> target < 10%
  - MTTR rollback manual -> otomatis
 
LAPIS 3 - Outcome/bisnis (apakah bernilai?)
  - Kapasitas rilis fitur naik tanpa tambah headcount
  - Biaya insiden (person-jam x rate) turun 60%
  - Survey kepercayaan tim terhadap rilis (1-5)

Aturan penyusunannya:

• Tiap lapis menjawab pertanyaan beda; laporan eksekutif cukup lapis 3, laporan operasional hidup di lapis 2.
• Definisikan rumus dan sumber data secara tertulis — "lead time" punya lima makna di lima tim; kalibrasi dulu sebelum membandingkan.
• Tetapkan baseline sebelum intervensi; tanpa baseline, klaim dampak nanti hanya retorika.

#Berargumen dengan Data Tanpa Menjadi Tyrant

Data yang kuat tetap butuh penyampaian yang tepat:

1. Satu grafik utama per keputusan — pilih visualisasi yang langsung menunjukkan kesimpulan; sisanya lampiran.
2. Sebutkan ketidakpastian secara jujur — "estimasi ±20%, sampel 6 pekan" meningkatkan kredibilitas, bukan menurunkan. Angka presisi palsu lebih cepat runtuh saat digali.
3. Bedakan korelasi dan sebab — "tim yang pakai golden path jarang gagal deploy" belum tentu sebab-akibat (mungkin tim itu saja yang disiplin); uji dengan kontrol atau setidaknya akui batasnya.
4. Beri ruang data melawan kalian — minta eksplisit: "angka apa yang akan mengubah rekomendasi saya?" Ini melatih intelektual honesty dan melindungi kalian dari confirmation bias.

Contoh paragraf argumen yang matang:

Sejak golden path fase 1 (12 Juni), lead time billing turun
dari 9 ke 2 hari (dashboard DORA, sumber CI). Change failure
rate stabil di 8% (sebelumnya 28%) - jadi percepatan tidak
membayar dengan mutu. Catatan jujur: sampel masih 1 tim;
rekomendasi rollout ke 3 tim berikutnya adalah uji replikasi,
bukan konfirmasi. Saya akan mundur dari rekomendasi jika CFR
melewati 15% pada dua tim pertama fase rollout.

Paragraf seperti ini jarang dibantah — karena sudah membantah dirinya lebih dulu dengan jujur.

#Praktik: Metrics Framework Organisasi

Selain per-inisiatif, staff engineer sering merapikan metrik lintas area. Susun ~/staff-lab/metrics/framework.md:

# Metrics Framework - Area Platform
 
## Prinsip
1. Setiap metrik punya: definisi rumus, sumber data, pemilik,
   frekuensi review, counter-metric pasangan.
2. Metrik untuk keputusan, bukan dekorasi laporan.
3. Tidak ada metrik individu sebagai KPI personal.
 
## Katalog inti (contoh entri)
METRIK : Lead time change
RUMUS : median(waktu merge->deploy produksi) per layanan
SUMBER: pipeline CI + registry events
PASANGAN: change failure rate (jaga <= 10%)
REVIEW : bulanan di forum engineering
 
## Ritual
- Scorecard bulanan otomatis (no manual spreadsheet).
- Enam-bulanan: audit definisi + retire metrik mati.

Bagian retire metrik mati penting: katalog metrik yang hanya bertambah akan menjadi rawa dashboard yang tak seorang pun baca.

#Pitfall Umum Menggunakan Metrik

• Mengukur yang mudah, bukan yang penting — LOC mudah dihitung, nilainya nyaris nol; usahakan selalu naik ke metrik outcome meski lebih susah.
• Dashboard tanpa keputusan — setiap panel harus punya jawaban atas "keputusan apa yang berubah jika angka ini bergerak?"
• Membandingkan antar tim tanpa konteks — velocity tim A vs B memicu game, bukan perbaikan; bandingkan tim dengan dirinya di masa lalu.
• Baseline hilang — intervensi dimulai sebelum baseline direkam; klaim dampak selamanya lemah.
• Angka tanpa cerita — data memberi apa, narasi memberi kenapa dan bagaimana; kalian dipekerjakan untuk menyatukan keduanya.

#Penutup

Inti yang harus dibawa pulang:

• Rangkai leading (kemudi) dan lagging (pembuktian), selalu dengan pembanding relatif dan proxy yang diakui jujur.
• Lawan Goodhart dengan counter-metric, aturan pakai non-hukuman, dan audit berkala definisi.
• Framework tiga lapis — input, output, outcome — dengan rumus dan sumber tertulis serta baseline sebelum intervensi.
• Argumen data terkuat menyebut ketidakpastian dan kondisi di mana kalian akan mundur.

Di episode 16 selanjutnya kita akan membahas scaling engineering practices — cara menskalakan standar kode, proses review, dan developer experience ke puluhan tim tanpa menjadi birokrasi yang membunuh otonomi. Sampai jumpa di episode 16!