Belajar Engineering Manager - Delivery Management

#Pendahuluan

Setelah enam episode membahas fondasi dan people management, kita masuk pilar kedua: delivery — kemampuan tim mengirim nilai secara konsisten dan dapat diprediksi.

Mengapa prediktabilitas penting, bukan sekadar kecepatan? Karena seluruh organisasi membuat rencana di atas asumsi kapan pekerjaan engineering selesai: marketing meluncurkan kampanye, sales menjanjikan fitur ke klien, finance memperkirakan revenue. Delivery yang kacau membuat semua rencana itu runtuh — dan kepercayaan stakeholder, begitu hilang, hanya kembali lewat deretan bulan konsisten. Tugas EM bukan memaksa tim lebih cepat, melainkan membangun sistem delivery yang dapat dipercaya.

#Hierarki Planning

Planning engineering tersusun berlapis, horizon makin pendek, presisi makin tinggi:

Prinsip pentingnya: presisi janji harus proporsional dengan horizon. Janji fitur spesifik "tanggal 14 pukul 10 pagi" untuk pekerjaan tiga kuartal ke depan adalah janji yang pasti pecah; sebaliknya, roadmap yang vagu untuk sprint minggu ini adalah kelalaian. Kesalahan klasik stakeholder (dan EM junior) adalah menuntut presisi sprint untuk hal-hal roadmap — kalian yang wajib mendidik perbedaan ini.

#Prioritisasi: Framework RICE dan WSJF

Ketika permintaan melebihi kapasitas (selalu), kalian butuh kerangka yang membuat keputusan bisa dibela. Yang paling umum dipakai: RICE.

RICE = (Reach x Impact x Confidence) / Effort
 
Reach      : jumlah user/percakapan yang tersentuh per kuartal
Impact     : 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
Confidence : 1.0 = penuh, 0.8 = tinggi, 0.5 = tebakan
Effort     : person-bulan (semakin besar semakin menurunkan skor)

Contoh penerapan pada empat permintaan riil:

Nilai framework ini bukan angkanya (yang mudah dimanipulasi), melainkan bahasa bersamanya: saat PM menuntut refactor diprioritaskan, diskusi berubah dari tarik-menarik volume suara menjadi debat tentang asumsi Reach dan Confidence. Alternatif populer lain adalah WSJF (Weighted Shortest Job First) dari SAFe — cost of delay dibagi durasi — yang unggul saat faktor ketergantungan tim lain kuat. Pakai satu saja secara konsisten; berganti framework tiap kuartal lebih buruk daripada framework biasa.

#Commitment yang Jujur

Commitment adalah kontrak reputasi tim. Tiga jenis janji yang harus kalian pisahkan tegas saat bicara dengan stakeholder:

• Commitment: tanggal pasti, scope pasti — hanya untuk pekerjaan yang benar-benar terdefinisi dan berisiko rendah.
• Forecast: perkiraan berbasis kapasitas, dengan rentang ("kemungkinan besar akhir Februari, paling lambat awal Maret") — default untuk mayoritas proyek.
• Aspirasi: arah tanpa tanggal — untuk eksplorasi dan hal yang belum terestimasi.

Aturan estimasi yang menyelamatkan karir: sampaikan rentang dengan confidence, bukan titik tunggal. "Delapan minggu" yang ternyata dua belas menghancurkan trust; "enam sampai sembilan minggu, confidence 80%" yang selesai di sembilan tetap dianggap profesional. Dan ingat hukum yang sudah kalian rasakan sebagai IC: estimasi pertama engineer biasanya mencakup happy path saja. Dorong buffer untuk integrasi, review, testing, dan unknowns — atau gunakan teknik pemecahan task hingga tiap potong di bawah tiga hari, yang secara statistik jauh lebih akurat daripada satu estimasi besar.

#Saat Estimasi Meleset: Manajemen Scope

Meleset itu pasti; yang membedakan tim dewasa dan tim kacau adalah seberapa cepat meleset itu dikomunikasikan dan bagaimana scope dikoreksi. Alur standarnya:

Tiga catatan di atas diagram tersebut. Kurangi scope dulu: MVP yang tepat waktu hampir selalu lebih baik daripada versi lengkap yang terlambat — ajukan pertanyaan "mana 20% dari ini yang menghasilkan 80% nilainya?". Tambah orang bukan solusi cepat: hukum Brooks (The Mythical Man-Month) tetap berlaku — orang baru butuh ramp-up sehingga dua-tiga minggu pertama justru memperlambat. Geser tanggal sebagai opsi terakhir: bukan karena tabu, melainkan karena biasanya masih ada scope yang bisa dipangkas tanpa merusak nilai.

#Status Report Tanpa Kejutan

Format status mingguan yang efektif hanya butuh empat blok:

# Status - Tim Payments - Minggu 34/2026
 
## Ringkas (TL;DR)
On track untuk rilis 1 September; satu risiko aktif di integrasi KYC.
 
## Progres vs rencana
- Checkout v2: 80% (sesuai rencana)
- Migrasi ledger: 60% (di depan jadwal 1 minggu)
 
## Risiko & issue
- [MED] Integrasi KYC vendor: response API tidak stabil -> mit: fallback
  polling; dampak maksimal 2 hari. Owner: Dewi. Review: Rabu.
 
## Butuh keputusan/bantuan
- Approval akses sandbox vendor KYC (menunggu legal sejak Senin).

Disiplin yang menyertainya: kirim secara rutin walau tidak ada kabar, gunakan status risiko yang konsisten (LOW/MED/HIGH dengan definisi dampak), dan naikkan risiko saat probabilitasnya mulai, bukan saat sudah pasti meledak. Prinsip no surprise bekerja dua arah: stakeholder tidak boleh dikejutkan oleh kegagalan, dan tim kalian tidak boleh dikejutkan oleh perubahan prioritas dadakan — keduanya dilarang dengan mekanisme yang sama: komunikasi rutin.

#Penutup

Inti yang harus dibawa pulang:

• Planning berlapis: roadmap kasar, quarterly sedang, sprint presisi — presisi janji proporsional dengan horizon.
• RICE (atau WSJF) mengubah perdebatan prioritas menjadi diskusi asumsi; sertakan debt dan compliance dalam persaingan kapasitas.
• Pisahkan commitment, forecast, dan aspirasi; sampaikan estimasi sebagai rentang ber-confidence.
• Saat meleset: kurangi scope dulu, tambah orang dengan hati-hati, geser tanggal terakhir — komunikasikan cepat.
• Status report empat blok, dikirim rutin, risiko dinaikkan dini — no surprise untuk kedua arah.

Di episode 8 selanjutnya kita bahas fondasi di balik semua planning itu: Resource & Capacity Planning — menghitung kapasitas riil tim dengan focus factor, alokasi feature vs debt vs support, menguji feasibility roadmap, dan kapan hiring benar-benar menjadi jawaban. Sampai jumpa!