Belajar Principal Engineer - Multi-Year Roadmap

#Pendahuluan

Setelah di episode 11 kalian membangun pipeline manusia — mentorship dan sponsorship yang mengubah talenta potensial menjadi pemimpin teknis — pada episode ini kita kembali ke artefak strategis: multi-year technical roadmap, urutan kerja multi-tahun yang menerjemahkan strategy (episode 4) menjadi rangkaian eksekusi.

Mengapa roadmap layak satu episode penuh? Karena kebanyakan roadmap teknis mati dalam satu kuartal: terlalu ambisius, saling menunggu dependensi, atau rapuh terhadap perubahan prioritas bisnis. Roadmap yang baik bukan janji tanggal, melainkan sistem urutan yang tetap masuk akal bahkan ketika isinya berubah.

#Model Horizon: H1-H2-H3

Kerangka paling tahan banting untuk roadmap multi-tahun membagi pekerjaan per sifat ketidakpastiannya:

Aturan komunikasinya keras: jangan pernah memberi tanggal untuk H3. Eksekutif yang diberi tanggal tahun depan akan menguncinya; begitu dunia berubah, roadmap kalian dianggap bohong. H3 dikomunikasikan sebagai arah investasi, bukan jadwal.

Perhatikan panah balik dari H1 ke roadmap: hasil gelombang berjalan adalah input utama penataan ulang — roadmap adalah loop, bukan dokumen sekali tulis.

#Manajemen Dependensi

Dependensi antar inisiatif adalah penyebab kematian nomor satu roadmap. Kelola dengan dua alat:

#1. Peta Dependensi Eksplisit

[Identitas terpusat] ← WAJIB dulu oleh:
├── [Migrasi auth semua service]
└── [Portal developer single sign-on]
 
[Platform observability] ← paralel aman dengan:
├── [Konsolidasi message queue]
└── [Program AI tooling]

Aturan praktis: jika dua inisiatif menyentuh sistem sama, mereka tidak boleh direncanakan independen. Satu harus maju duluan — dan pilihan "mana dulu" adalah keputusan strategis, bukan kebetulan kalender.

#2. Sequencing Berbasis Nilai-Opsi

Saat ragu urutan, prioritaskan pekerjaan yang:

• Membuka nilai langsung dan mempermudah inisiatif lain (platform identitas adalah contoh klasik);
• Menghilangkan risiko terbesar lebih awal (uji integrasi vendor sebelum migrasi massal);
• Menghasilkan informasi termahal (pilot yang menjawab "apakah pendekatan ini bekerja").

#Kapasitas Realistis

Roadmap org hampir selalu overcommit karena lupa tiga pengurang kapasitas:

Konsekuensinya brutal namun jujur: dari 100% kapasitas engineer, hanya sekitar 50-60% yang tersedia untuk roadmap. Principal yang menyusun roadmap dengan asumsi 100% sedang merancang kegagalan dengan jadwal.

#Templat Roadmap Doc

Format ringkas yang tetap hidup:

# Technical Roadmap [Org] - [Tahun]
 
## Tema Strategis (dari vision)
Tema 1 / Tema 2 / Tema 3.
 
## H1 - Komitmen Kuartal Ini
Inisiatif · Pemilik · Tim-bulan · Metrik keluar · Status.
 
## H2 - Urutan & Dependensi
Urutan indikatif 2-4 kuartal + peta dependensi + kondisi
yang mengubah urutan.
 
## H3 - Arah Investasi
Tema tahun depan + hipotesis + apa yang akan kita pelajari
di H1/H2 untuk memvalidasinya.
 
## Menu Tidak Dikerjakan
Eksplisit + alasan + kondisi membuka kembali diskusinya.
 
## Ritual Re-Prioritisasi
Setiap kuartal: cek metrik H1, geser H2, uji ulang asumsi H3.
Pemilik agenda: principal.

Bagian Menu Tidak Dikerjakan adalah warisan episode 4 — roadmap tanpa daftar penolakan akan terus ditambah tanpa pernah dikurangi.

#Saat Prioritas Bisnis Berubah

Ia pasti berubah. Roadmap tangguh punya protokol perubahan:

1. Bedakan geseran vs pembatalan: pergeseran urutan murah; pembatalan inisiatif berjalan mahal — hitung sunk cost secara jujur lalu putuskan cepat.
2. Lindungi inisiatif fondasi: identitas dan observability tidak boleh jadi korban pertama setiap kuartal; tandai sebagai non-negotiable bersama sponsor.
3. Komunikasikan trade-off, bukan keluhan: "prioritas baru X memakan 12 tim-bulan; konsekuensinya program Y mundur satu kuartal — konfirmasi pilihan ini."
4. Update roadmap dalam seminggu — roadmap yang basi lebih merusak kepercayaan daripada roadmap yang berubah.

#Praktik

Di workspace kalian:

1. Susun roadmap satu halaman dengan templat di atas untuk domain scope kalian.
2. Gambar peta dependensi inisiatif utama — temukan minimal satu urutan yang salah saat ini.
3. Hitung kapasitas riil org kalian (100% minus on-call/meeting/utang) dan cocokkan dengan menu roadmap.
4. Tetapkan ritual re-prioritisasi kuartalan di kalender kalian sendiri.

#Penutup

Inti yang harus dibawa pulang:

• Roadmap multi-tahun = model H1-H2-H3: komit, urutan, tema — dan jangan pernah memberi tanggal untuk H3.
• Dependensi dikelola eksplisit; urutan berbasis nilai-opsi: fondasi dulu, risiko besar diuji awal.
• Kapasitas riil hanya 50-60% — roadmap yang mengabaikannya adalah jadwal kegagalan.
• Roadmap hidup lewat ritual re-prioritisasi kuartalan dan protokol perubahan yang menjaga inisiatif fondasi.

Di episode 13 selanjutnya kita membahas org efficiency & velocity — cara mendiagnosis throughput organisasi dengan DORA dan value stream mapping, menemukan bottleneck sistemik (bukan sekadar tim lambat), serta menyusun velocity plan yang meningkatkan kecepatan org tanpa membakar orang-orangnya. Sampai jumpa di episode 13!