Belajar Staff Engineer - Conflict & Decisions

#Pendahuluan

Setelah di episode 10 kita belajar bermitra dengan produk dan bisnis lewat mata uang bisnis dan feasibility memo, pada episode ini kita hadapi momen paling sulit peran staff engineer: conflict & decisions. Ketika dua tim punya solusi berbeda untuk masalah yang sama, ketika lead yang dihormati menolak usulan kalian, atau saat keputusan harus diambil tanpa data lengkap — di sanalah kalian dibutuhkan.

Kabar baiknya: konflik teknis bukan penyakit; ia gejala bahwa organisasi peduli. Tugas kalian bukan menghilangkan konflik melainkan membuat proses keputusannya sehat — cepat, adil, terdokumentasi, dan bisa dipelajari.

#Klasifikasi Keputusan: Reversibilitas Dulu

Sebelum memperdebatkan keputusan apa pun, klasifikasikan dulu sifatnya:

Kesalahan klasik organisasi: memperlakukan semua keputusan sebagai one-way door — semuanya dirapat bertingkat — hingga velocity mati. Kesalahan kedua: memperlakukan one-way door sebagai two-way — migrasi besar diambil atas dasar "yakin saja". Staf engineer menjaga keseimbangan ini: mempercepat yang bisa dibalik, memperlambat yang tidak.

#Kerangka Memutuskan Saat Tim Tidak Sepakat

Alur yang saya pakai berulang kali:

Tiga prinsip yang membuat alur ini bekerja:

1. Pisahkan fakta dari nilai — banyak debat panjang ternyata dua orang memakai angka berbeda. Samakan dulu datanya; separuh konflik lenyap di situ.
2. Beri nama pemilik keputusan sejak awal — setiap diskusi butuh jawaban atas "siapa memutuskan jika kita buntu". Tanpa itu, buntu = tarik-menarik tenaga tanpa akhir.
3. Eskalasi adalah fitur, bukan kekalahan — membawa buntu ke pemilik keputusan (biasanya VP Eng atau komite arsitektur) dengan ringkasan netral kedua opsi adalah perilaku profesional.

#Disagree and Commit, dengan Benar

Prinsip Amazon ini sering disalahpahami sebagai "diam dan patuh". Versi sehatnya:

1. Disagree secara eksplisit dan tertulis — sampaikan keberatan terbaik kalian, lengkap dengan risiko yang kalian lihat. Ini bukan formalitas; ia memberi organisasi kesempatan mengoreksi diri jika kalian benar.
2. Commit sepenuhnya — setelah keputusan jatuh, eksekusi seperti itu keputusan kalian sendiri. Sabotase pasif ("aku sudah bilang") meracuni budaya lebih cepat daripada keputusan salah mana pun.
3. Revisit dengan syarat — keputusan boleh ditinjau ulang saat kondisi berubah (data baru, asumsi gugur), bukan saat ego belum puas.

Contoh nyata: kalian keberatan soal vendor message queue baru karena risiko lock-in; direksi tetap memilihnya. Commit artinya kalian menulis panduan migrasi yang aman dan mendesain abstraksi tipis agar keluar mudah — bukan menunggu vendor gagal untuk berkata "sudah kuduga".

#Menengahi Konflik Antar Tim

Saat kalian diminta menengahi (posisi natural staff engineer), gunakan protokol singkat:

1. Dengar tiap pihak sendirian dulu — pahami kepentingan asli di balik posisi. "Menolak Kafka" sering artinya "tim kami tak sanggop maintain infra baru".
2. Rumuskan ulang kepentingan bersama — tulis di depan semua: apa yang sama-sama kalian cegah (insiden, keterlambatan)? Konflik biasanya menyempit drastis setelah langkah ini.
3. Ubah posisi menjadi eksperimen — "kita uji opsi A di satu service selama 4 pekan dengan metrik X" mengubah perdebatan identitas menjadi pengumpulan data.
4. Putuskan dan dokumentasikan — keputusan + siapa memutuskan + alasan + kondisi revisit, dalam ADR.

Aturan emas fasilitator: kalian memutuskan proses, bukan isi — kecuali diminta eksplisit menjadi pemilik keputusan.

#Praktik: Decision Log

Organisasi yang belajar mencatat keputusannya. Buat ~/staff-lab/decisions/log.md:

# Decision Log - Area Platform
 
| ID  | Tanggal   | Keputusan                        | Pemutus | Status      |
|-----|-----------|----------------------------------|---------|-------------|
| D14 | 2026-06-02| MQ internal: pindah ke NATS      | VP Eng  | Implemented |
| D15 | 2026-07-11| Feature flag system: Unleash     | Arsitektur | Adopted |
| D16 | 2026-08-16| Realtime price update: opsi B    | PM+Staff | Evaluasi 09-12 |
 
Catatan D16: revisi jika engagement watchlist < 40% sesi.

Manfaat log ini melampaui dokumentasi:

• Onboarding cepat — engineer baru memahami kenapa sistem seperti ini dalam satu jam membaca, bukan tiga bulan bertanya.
• Anti relitigasi — keputusan yang sudah dicatat beserta alasannya tidak dibuka ulang tiap ada anggota baru.
• Pola pembelajaran — setiap enam bulan, baca ulang: jenis keputusan apa yang sering salah? Itu area pertumbuhan proses kalian.

#Pitfall Umum Konflik & Keputusan

• Konsensus palsu — semua diam lalu "setuju"; sebenarnya belum yakin. Uji dengan "siapa akan repot jika ini gagal? kalau tidak ada yang angkat tangan, keputusan ini belum benar-benar disepakati".
• Debate tanpa deadline — diskusi tanpa tanggal keputusan akan berlarut selamanya; selalu tetapkan "kita putuskan hari Jumat, apa pun datanya".
• Menjadikan keputusan tentang orang — begitu debat berubah menjadi siapa-yang-benar, kehilangan semua nilai informasinya. Panggil kembali fokus ke kriteria.
• Keputusan tanpa catatan alasan — enam bulan kemudian tak seorang pun ingat kenapa, dan organisasi membayar lagi harga yang sama untuk belajar ulang.
• Menghindari eskalasi terlalu lama — dua pekan buntu yang dieskalasi lebih murah daripada dua bulan yang "diselesaikan" dengan hubungan rusak.

#Penutup

Inti yang harus dibawa pulang:

• Klasifikasi keputusan dulu: two-way door diputus cepat, one-way door lewat RFC, keputusan berulang dikodifikasi jadi standar.
• Alur buntu: samakan fakta → pisahkan nilai vs preferensi → eksperimen kecil → eskalasi terstruktur → ADR.
• Disagree and commit yang sehat: keberatan tertulis, eksekusi penuh, revisit hanya saat kondisi berubah.
• Decision log mengubah keputusan organisasi menjadi aset pembelajaran yang anti-relitigasi.

Di episode 12 selanjutnya kita mulai fase baru dengan membahas complex systems delivery — cara mengelola deliverable sistem kompleks yang menyentuh banyak tim dan bulan-bulan eksekusi: koordinasi, integrasi bertahap, dan menjaga mutu sampai benar-benar produksi. Sampai jumpa di episode 12!