Belajar Principal Engineer - Data-Driven Org Decisions

#Pendahuluan

Setelah di episode 14 kalian membangun program reliability — SLO, error budget, dan incident excellence — pada episode ini kita naik satu tingkat abstraksi: budaya keputusan berbasis data di seluruh organisasi. Reliability adalah satu domain; kini kita bicara mesin pengambilan keputusan org secara keseluruhan.

Mengapa ini scope principal? Karena data tanpa arsitektur metrik menghasilkan perang angka: tiap tim punya dashboard sendiri, definisi "aktif" beda-beda, dan rapat strategis dimenangkan oleh presenter paling percaya diri. Arsitektur metrik org — hierarki, definisi bersama, dan ritual eksperimen — adalah pekerjaan desain sistem seperti arsitektur software lainnya.

#Hierarki Metrik Org

Struktur yang membuat ratusan metrik bisa hidup damai:

Tiga prinsip operasional:

1. Definisi tunggal: satu kamus metrik resmi. "Pengguna aktif mingguan" harus punya satu rumus SQL untuk seluruh org — dua definisi berarti nol kepercayaan.
2. Arah, bukan angka mutlak: north star dipakai untuk membandingkan tren dan prioritas, bukan sebagai janji publik.
3. Guardrail setara dengan target: metrik yang tidak boleh rusak harus punya hak veto sama kuatnya dengan target pertumbuhan.

#Program Eksperimen

Keputusan berbasis data matang ketika org berhenti berdebat opini dan mulai menguji. Komponen minimum program eksperimen:

• Hypothesis format baku: "Jika [perubahan], maka [metrik input] naik X%, karena [mekanisme]."
• Power & durasi jujur: hitung dulu sample size; eksperimen yang dihentikan sebelum power cukup adalah noise generator.
• Guardrail otomatis: setiap eksperimen memantau guardrail (latency, error rate, keluhan); pelanggaran = rollback otomatis.
• Keputusan tertulis: hasil apa pun — termasuk gagal — masuk log eksperimen org. Eksperimen gagal yang terdokumentasi adalah aset; ia mencegah orang lain mengulang biayanya.

#Dashboard yang Dipercaya

Dashboard adalah UI dari arsitektur metrik ini. Standar minimal agar dipercaya:

1. Sumber tunggal: semua dashboard membaca dari model metrik yang sama (semantic layer / dbt metric atau setara), bukan query ad-hoc per halaman.
2. Segar dan diketahui umurnya: timestamp data terakhir update tampil jelas.
3. Dapat ditelusuri: klik angka → definisi → query → tabel sumber. Angka tanpa jejak akan ditantang di setiap rapat krisis.
4. Satu halaman exec: tren north star + input utama + guardrail, tanpa grafik hiasan.

Contoh query definisi yang dikontrol pusat (bukan ditulis ulang tiap tim):

-- Definisi resmi org: Weekly Active Account
-- Sumber: semantic layer metrics (JANGAN fork definisi ini)
SELECT
    date_trunc('week', event_ts)  AS week,
    count(DISTINCT account_id)     AS waa,
    count(DISTINCT CASE
        WHEN event_type = 'transaction_success'
        THEN account_id END)       AS waa_transacting
FROM events.fct_user_events
WHERE event_ts >= current_date - interval '90 days'
GROUP BY 1
ORDER BY 1 DESC;

Perhatikan komentar kerasnya: larangan fork definisi adalah bagian dari governance — warisan langsung episode 5.

#Goodhart's Law: Musuh Program Metrik

"Saat sebuah ukuran menjadi target, ia berhenti menjadi ukuran yang baik." Ini bukan ancaman teoretis — ia pasti datang begitu metrik masuk evaluasi kinerja. Pertahanannya:

Deteksi paling awal: ketika sebuah metrik membaik tapi north star dan guardrail tidak ikut membaik, anggap metrik itu sudah digaming sampai terbukti sebaliknya.

#Praktik: Metrics Program

Di workspace kalian:

1. Tulis draft hierarki metrik org: satu north star, 3-5 input, 3 guardrail.
2. Audit satu dashboard populer: temukan definisi yang berbeda dari kamus metrik (pasti ada).
3. Rancang satu eksperimen nyata lengkap: hipotesis, sample size, guardrail, rencana keputusan.
4. Draft protokol anti-Goodhart untuk metrik yang saat ini paling rawan digaming di org kalian.

#Penutup

Inti yang harus dibawa pulang:

• Hierarki metrik — north star, input, guardrail, diagnostik — dengan kamus definisi tunggal adalah arsitektur wajib.
• Budaya eksperimen: hipotesis baku, power jujur, guardrail otomatis, dan keputusan tertulis termasuk untuk kegagalan.
• Dashboard dipercaya karena sumber tunggal, kesegaran jelas, dan jejak dari angka ke query.
• Goodhart's law pasti datang; pertahanannya pairing guardrail, tren standar, dan larangan metrik diagnostik jadi KPI manusia.

Di episode 16 selanjutnya kita membahas cost & efficiency programs — memimpin optimasi biaya organisasi ala FinOps: unit economics (biaya per transaksi/pelanggan), alokasi biaya lintas tim, program quick wins vs perubahan struktural, dan cara membuat efisiensi jadi disiplin berkelanjutan bukan panik kuartalan. Sampai jumpa di episode 16!