Belajar Engineering Manager - Team Metrics & DORA

#Pendahuluan

Setelah di episode 12 kita membangun tangga karir yang adil, sekarang kita lengkapi toolkit EM dengan mata: metrik tim.

Mengapa metrik penting? Karena tanpa data, diskusi kinerja tim jatuh ke anekdot dan impressi — orang paling vokal menang, bukan fakta. Dan dengan data yang salah, kondisinya lebih buruk lagi: tim dioptimalkan untuk angka yang tidak berkaitan dengan nilai (jumlah commit, story points per sprint) hingga perilaku menyimpang secara rasional. Episode ini memberi kalian set metrik yang terbukti secara riset, plus aturan main pemakaiannya.

#Empat Metrik DORA

Riset multi-tahun yang dipublikasikan dalam buku Accelerate (Forsgren, Humble, Kim) dan laporan tahunan State of DevOps menemukan empat metrik yang berkorelasi kuat dengan kinerja organisasi — dikenal sebagai DORA metrics:

Kekuatan empat ini adalah pasangan keseimbangannya: frequency dan lead time mengukur kecepatan, CFR dan MTTR mengukur stabilitas. Optimalkan satu sisi dengan mengorbankan sisi lain (ship cepat tapi sering rusak; stabil tapi lambat) langsung terlihat di angka — itulah kenapa melihat keempatnya bersama-sama wajib.

Benchmark referensi dari laporan State of DevOps (angka bergerak tiap tahun; gunakan sebagai orde besar, bukan target absolut):

Catatan jujur: mayoritas tim enterprise Indonesia berada di rentang medium — dan itu tidak apa-apa. Nilai DORA bukan pada membandingkan diri dengan elite Silicon Valley, melainkan pada tren kalian sendiri kuartal ke kuartal: arah panah lebih penting daripada posisi titik.

#Metrik Pendukung di Antara DORA

DORA menjawab "seberapa baik pipeline delivery", tetapi EM butuh radar tambahan untuk akar masalahnya:

Review turnaround   : median waktu PR menunggu review pertama
                      -> naik = kapasitas review bermasalah (ep. 8)
PR size             : median diff baris per PR
                      -> naik = disiplin pemecahan task turun (ep. 9)
Flaky test ratio    : % test run yang gagal non-deterministik
                      -> naik = trust CI tergerus, orang skip test (ep. 9)
Incident MTTR       : deteksi -> resolusi per severitas
                      -> tren naik = runbook/on-call butuh investasi
Onboarding time     : hari sampai first production commit
                      -> naik = kompleksitas codebase/dokumentasi busuk
Error budget burn   : laju pemakaian error budget SLO
                      -> cepat = tekanan ship melebihi stabilitas

Semua metrik ini punya sifat yang sama: ia mengukur sistem, bukan individu. Median review turnaround naik bukan berarti reviewer jahat — bisa jadi alokasi debt terpotong, bisa jadi PR raksasa jadi tren. Metrik adalah asap; EM bertugas mencari api.

#Anti-Pattern: Weaponizing Metrics

Aturan main nomor satu, dan tidak bisa dinegosiasikan: metrik tim tidak pernah menjadi dasar penilaian individual. Begitu angka DORA masuk review performa pribadi, Goodhart's Law menyala penuh — "ketika sebuah ukuran menjadi target, ia berhenti menjadi ukuran yang baik". Contoh deformasi yang nyata:

• Target deploy frequency tinggi → engineer memecah rilis kosong demi angka.
• Story points dijadikan KPI personal → inflation points (task 3 poin jadi 8).
• Review time dipaksa super cepat → approval tanpa dibaca ("LGTM" refleks).
• Incident count dijadikan ukuran buruk → insiden disembunyikan, postmortem mati.

Bentuk perlindungan yang praktis: tampilkan dashboard metrik agregat per tim, bukan leaderboard per orang; bicarakan metrik di retro sebagai bahan perbaikan proses; dan pisahkan total antara data operasional (metrik) dengan data evaluatif (performance review yang berbasis dampak konkret, episode 4 dan 12).

#Membangun Dashboard Tim

Implementasi praktis tidak perlu mahal. Opsi bertingkat:

1. Level minimum: query manual ke API tracker + CI (GitHub/GitLab API) sekali sebulan ke spreadsheet. Cukup untuk melihat tren.
2. Level menengah: tool siap pakai (Linear Insights, Jira dashboards, plugin four-keys open-source dari Google).
3. Level matang: pipeline event build/deploy ke warehouse + dashboard BI, terintegrasi alert anomali.

Apa pun toolnya, desain dashboard yang sehat memuat:

dashboard: "payments-platform-health"
prinsip:
  audience: "tim + EM; diekspos agregat ke leadership"
  window_default: "90 hari rolling"      # tren, bukan snapshot mingguan
metrics:
  - dora_deployment_frequency
  - dora_lead_time_changes
  - dora_change_failure_rate
  - dora_mttr_failed_deployment
  - support: [review_turnaround, pr_size_median, flaky_ratio]
ritual:
  - "Senin pagi 15 menit: EM scan tren (ep. 9 radar)"
  - "Retro biweekly: 10 menit bedah 1-2 metrik yang bergerak"
alert:
  - "CFR naik >5 poin dalam 30 hari -> bahas di architecture forum"
  - "Lead time naik 2 minggu berturut -> cek kapasitas & WIP"

Perhatikan bagian ritual — metrik tanpa ritual hanyalah pajak visual. Dua slot kecil itu (scan Senin, bedah retro) yang mengubah dashboard dari dekorasi menjadi mesin perbaikan.

#Menyampaikan Metrik ke Leadership

Terakhir, terjemahan ke atas: executive tidak butuh grafik lead time mentah; mereka butuh narasi risiko dan keputusan. Format satu slide yang efektif:

• Tren 90 hari dua-tiga metrik utama dengan panah arah.
• Satu kalimat interpretasi: "lead time naik 30% sejak scope kuartal digandakan".
• Satu permintaan konkret: "butuh keputusan: kurangi scope 20% atau terima risiko kualitas Q4".

Metrik adalah alat negosiasi kapasitas kalian (episode 8) yang kini bersuara data — jauh lebih kuat daripada "tim kami kelebihan beban" tanpa angka.

#Penutup

Inti yang harus dibawa pulang:

• DORA empat metrik: deployment frequency, lead time, change failure rate, MTTR — kecepatan dan stabilitas dibaca bersama, tren kalian sendiri lebih penting daripada benchmark elite.
• Metrik pendukung (review turnaround, PR size, flaky ratio, onboarding time) menunjuk akar masalah di balik angka DORA.
• Metrik mengukur sistem, bukan individu — melarang keras pemakaian individual sebagai KPI karena Goodhart's Law akan mendistorsi perilaku.
• Dashboard sehat punya audience, window tren, dan ritual pemakaian; tanpa ritual ia hanya pajak visual.
• Ke atas: terjemahkan metrik menjadi narasi risiko plus satu permintaan keputusan.

Di episode 14 selanjutnya kita bahas realitas kerja modern: Remote & Distributed Teams — prinsip async-first, dokumentasi sebagai infrastruktur trust, mengelola zona waktu dan overlap hours, meeting hygiene tim remote, serta cara membangun kohesi tanpa kantoran. Sampai jumpa!