Belajar Principal Engineer - Org Efficiency & Velocity

#Pendahuluan

Setelah di episode 12 kalian menyusun multi-year roadmap dengan horizon dan kapasitas yang jujur — pada episode ini kita garap mesinnya: velocity organisasi. Sebaik apa roadmap kalian jika throughput org sendiri setengah dari yang seharusnya?

Mengapa ini scope principal? Karena bottleneck organisasi hampir selalu lintas tim — antrean review, environment yang rebutan, proses rilis manual, keputusan yang menunggu mingguan. Tim individual tidak bisa memperbaikinya; hanya orang yang melihat seluruh aliran kerja yang bisa. Dan perbaikan velocity adalah salah satu cara paling terukur principal mengubah angka bisnis.

#DORA: Detektor, Bukan Target

Empat metrik DORA adalah titik mulai diagnosis:

Dua aturan pakai penting:

1. DORA adalah termometer, bukan target OKR. Begitu angka jadi target, tim akan gaming-nya (rilis kosong, insiden tak dicatat). Gunakan untuk menemukan di mana menyelidik.
2. Baca berpasangan: deployment frequency tinggi + failure rate tinggi = masalah quality gate; keduanya rendah = masalah pipeline dan otonomi.

#Value Stream Mapping

Metrik memberi tahu apa; value stream mapping menjelaskan mengapa. Ambil satu fitur representatif, petakan waktunya:

Desain & keputusan      3 hari  (2 hari menunggu forum desain)
Implementasi           4 hari
Menunggu code review   5 hari  ← bottleneck terbesar
Menunggu environment    3 hari  ← konflik resource antar tim
QA manual              4 hari
Menunggu jadwal rilis   7 hari  ← rilis bulanan terkunci
-----------------------------------------------
Total                  26 hari (kerja aktif hanya 8)

Pola yang hampir selalu muncul: waktu tunggu mendominasi waktu kerja — di contoh ini 18 dari 26 hari. Org bukan lambat karena engineer-nya lambat; ia lambat karena antreannya panjang. Ini reframing penting saat bicara dengan eksekutif: masalahnya sistem, bukan orang.

#Katalog Bottleneck Sistemik

Setelah puluhan mapping, polanya berulang. Katalog ini bisa kalian pakai langsung:

Perhatikan bahwa tiga dari enam intervensi bertumpu pada mekanisme yang sudah kalian bangun di episode 5 (governance ringan) dan episode 7 (platform). Velocity bukan proyek terpisah — ia buah dari sistem-sistem itu.

#Velocity Plan

Untuk inisiatif perbaikan, susun rencana eksplisit:

# Velocity Plan [Org] - [Kuartal]
 
## Baseline (dari VSM & DORA)
Lead time p50/p90, deploy freq, FR rate, top 3 antrean + durasi.
 
## Intervensi Terpilih (maksimal 3)
1. SLA review 24 jam kerja - pemilik: EM lintas tim.
2. Ephemeral env untuk service X,Y - pemilik: platform.
3. Release train mingguan - pemilik: principal (saya).
 
## Metrik Sukses & Tanggal Evaluasi
Lead time p90: 21 hari -> 10 hari dalam 2 kuartal.
 
## Yang Tidak Kita Sentuh Sekarang
(anti-overload: satu perubahan proses per area)
 
## Risiko Manusia
Beban on-call naik saat transisi - kompensasi eksplisit.

Baris Yang Tidak Kita Sentuh Sekarang bukan formalitas: perubahan proses menumpuk membuat org lumpuh sesaat dan semua metrik turun bersama-sama, lalu program dibatalkan prematur.

#Jangan Membakar Engineer

Velocity yang dicapai lewat jam lembur bukan velocity — ia pinjaman dengan bunga burnout. Tiga penjaga keberlanjutan:

1. Ukur beban bersama output: survey kelelahan + on-call hours naik = perlambat program, bukan dorong lebih keras.
2. Kecepatan datang dari menghilangkan pekerjaan, bukan memadatkannya: otomasi dan penghapusan langkah adalah satu-satunya sumber velocity sehat.
3. Rayakan penghapusan: "kami menghapus 400 jam kerja manual per bulan" harus sama prestisiusnya dengan fitur baru.

#Praktik

Di workspace kalian:

1. Ambil baseline DORA org/tim kalian (atau estimasi dari data rilis).
2. Jalankan satu value stream mapping mini seperti contoh di atas.
3. Tulis velocity plan maksimal tiga intervensi dengan metrik dan tanggal evaluasi.
4. Presentasikan satu halaman ke VP: fokus pada waktu tunggu, bukan kecepatan individu.

#Penutup

Inti yang harus dibawa pulang:

• DORA adalah detektor lokasi masalah, bukan target; bacakan berpasangan.
• Value stream mapping biasanya menunjukkan waktu tunggu mendominasi — masalah sistem, bukan orang.
• Katalog bottleneck sistemik + intervensi yang sebagian besar sudah kalian bangun via governance dan platform.
• Velocity plan maksimal tiga intervensi, dengan anti-overload dan penjaga keberlanjutan manusia.

Di episode 14 selanjutnya kita membahas reliability at scale — membangun program reliability organisasi: SLO dan error budget lintas tim, incident excellence dari severity sampai postmortem blameless, dan cara membuat reliability jadi properti sistem yang dikelola, bukan harapan. Sampai jumpa di episode 14!