Belajar Staff Engineer - Technical Vision & Roadmap

#Pendahuluan

Setelah di episode 23 kita merancang hiring loop dan menjaga bar, pada episode ini kita naik ke artefak arah terbesar dalam peran staff engineer: technical vision & roadmap. Episode 6 memberi kalian strategy area (6-18 bulan); vision adalah lapisan di atasnya — gambaran ke mana organisasi bergerak dalam 3-5 tahun dan prinsip apa yang mengarahkan setiap keputusan di sepanjang jalan.

Vision sering diremehkan sebagai poster motivasi. Versi yang benar bekerja keras: ia memutuskan debat hari ini ("apakah kita build X?"), menyejukkan panik mingguan ("apakah kita tertinggal dari tren Y?"), dan membuat ribuan keputusan kecil tim bisa mandiri tanpa bertanya. Kita bangun itu secara konkret.

#Anatomi Vision yang Bekerja

Vision teknis yang berguna punya empat komponen:

#1. North Star: Keadaan Akhir yang Bisa Dibayangkan

Satu-dua kalimat tentang dunia ketika visi tercapai — spesifik cukup untuk membayangkan, terbuka cukup untuk tak cepat usang.

• Lemah: "Menjadi engineering world-class." (tidak bisa dibayangkan; tidak bisa dibantah)
• Kuat: "Setiap layanan bisa dideploy independen berapa kali sehari oleh timnya sendiri, dengan risiko insiden yang dibayar dari error budget — bukan dari keberanian."

Versi kuat langsung memberi bahasa evaluasi: apakah pekerjaan ini mendekatkan kita ke keadaan itu atau tidak?

#2. Prinsip Pemandu

Lima-tujuh aturan keputusan yang menurunkan debat berulang menjadi penerapan aturan:

P1 Buy dulu untuk non-inti; build hanya pembeda kompetitif.
P2 Setiap domain memiliki datanya; akses via kontrak, bukan DB langsung.
P3 Default paved road; keluar jalur = exception tercatat + pemilik.
P4 Reliability dibayar dari error budget, bukan dari semangat.
P5 Biaya adalah metrik first-class - setiap desain besar
   menyertakan estimasi cost-per-request.

Uji kualitas prinsip: ia harus bisa mengubah keputusan nyata. Prinsip yang tak pernah dipakai memutuskan apa pun adalah hiasan — kurangi daftarnya sampai semua terpakai.

#3. Three Horizons Roadmap

Kerangka klasik untuk mengelola waktu secara bersamaan:

Nilai utamanya bukan angka pastinya, melainkan dialog alokasi: organisasi yang tak punya H2/H3 eksplisit akan menghabiskan 100% kapasitasnya memadamkan H1 selamanya — lalu kaget ketika intinya sendiri usang. Sebaliknya, organisasi yang cinta H3 tanpa disiplin H1 mati sebelum masa depan datang.

#4. Anti-Vision: Apa yang TIDAK Kita Jadikan

Daftar eksplisit hal yang sengaja tidak dituju: "kami tidak akan rewrite monolit big-bang", "kami tidak akan maintain dua stack frontend". Anti-vision melindungi fokus lebih efektif daripada visi — karena ia menjawab godaan yang benar-benar datang.

#Struktur Vision Doc

Susun dokumen di ~/staff-lab/vision/platform-2029.md:

# Technical Vision 2029: Platform sebagai Produk Internal
 
Status: Draft v0.3 · Pemilik: [nama] · Reviewer: leads + VP Eng
Terakhir diverifikasi: 2026-08-16
 
## North Star
Pada 2029, setiap domain dapat mengirim perubahan produksi
secara independen beberapa kali sehari lewat golden path,
dengan reliability dikelola via SLO dan biaya sebagai
metrik first-class di setiap keputusan arsitektur.
 
## Kenapa Sekarang (diagnosis singkat)
14 tim saling menunggu rilis bersama (lead time 9 hari);
insiden lintas domain 2x/bulan; biaya cloud naik 30%/tahun
tanpa visibilitas. Tanpa perubahan arah, pertumbuhan tim
menambah koordinasi, bukan output.
 
## Prinsip Pemandu
[P1-P5 seperti contoh di atas]
 
## Three Horizons
H1 (2026): golden path deployment; konsolidasi skema user;
           program SLO 11 layanan.
H2 (2027): platform data domain-owned; self-service analytics;
           FinOps otomatis per domain.
H3 (2028+): evaluasi multi-cell residency penuh; arsitektur
           AI-native untuk workflow internal.
 
## Anti-Vision
Tidak ada rewrite monolit big-bang; tidak ada dual-stack
frontend; tidak ada migrasi infra tanpa business case.
 
## Cara Mengukur Visi Ini Hidup
Review enam-bulanan publik; setiap RFC besar wajib merujuk
prinsip yang relevan; scorecard H1 dilaporkan tiap kuartal.

Perhatikan bagian Cara Mengukur Visi Ini Hidup — inilah yang membedakan dokumen kerja dari poster. Visi tanpa ritual review akan basi dalam satu reorganisasi.

#Menyusun Visi Secara Partisipatif

Visi yang ditulis sendirian lalu diumumkan akan ditolak diam-diam. Proses yang berhasil:

1. Wawancara input — bicara 30 menit dengan tiap lead dan beberapa IC senior: apa yang paling menghambat mereka? Apa yang mereka harapkan ada tahun depan?
2. Draft dari pola — tulis draft pertama dari pola keluhan-harapan tersebut; visi yang menjawab nyeri nyata diadopsi, visi yang mengimpor tren tidak.
3. Workshop kritik — sesi 90 menit dengan lead: serang draft ini. Catat keberatan; ubah atau jawab eksplisit di dokumen.
4. Ratifikasi — persetujuan resmi manajemen (pola episode 6); tanpa ratifikasi, visi tak bisa melindungi fokus saat tekanan datang.
5. Publikasi & referensi — dokumen hidup di tempat yang diketahui semua orang; tiap RFC/ADR besar merujuk prinsip yang dipakainya.

Proses ini juga alasan politik yang sah: orang mendukung apa yang ikut mereka bentuk.

#Menjaga Visi Tetap Hidup

Tiga ritual ringan:

• Review enam bulanan — asumsi mana yang berubah? Revisi versi terbuka dengan changelog; visi boleh berubah, asal perubahannya terlihat.
• Referensi wajib di keputusan besar — "ADR-034 memilih opsi B sesuai prinsip P2" membuat prinsip terlatih dalam praktik, bukan hafalan.
• Scorecard H1 kuartalan — kemajuan horizon terdekat dilaporkan seperti OKR; H2/H3 dievaluasi tahunan saja agar tak mengganggu eksekusi.

#Pitfall Umum Menyusun Visi

• Visi buzzword — "AI-first, cloud-native, platform-driven" tanpa implikasi keputusan; uji dengan pertanyaan "apa yang TIDAK kita kerjakan karena visi ini?"
• Terlalu banyak north star — lima arah sama artinya dengan nol arah; satu-dua kalimat, tegas.
• Horizon tanpa alokasi — H3 indah tapi 0% kapasitas = teater strategi; alokasikan eksplisit meski kecil.
• Ditulis sekali, tidak pernah disentuh — visi 2024 yang belum direvisi di 2026 adalah artefak sejarah, bukan arah.
• Mengganti visi tiap kepemimpinan baru — stabilitas arah adalah nilainya; revisi ya, ganti-ganti tidak.

#Penutup

Inti yang harus dibawa pulang:

• Vision yang bekerja = north star terbayangkan + prinsip yang dipakai memutuskan + three horizons dengan alokasi + anti-vision pelindung fokus.
• Susun partisipatif: wawancara → draft dari pola nyeri nyata → workshop kritik → ratifikasi → referensi rutin.
• Ukur hidup-matinya: RFC merujuk prinsip, scorecard H1 kuartalan, review enam bulanan dengan changelog.
• Visi tanpa implikasi ke pekerjaan bulan ini hanyalah poster — tambahkan H1 yang konkret.

Di episode 25 selanjutnya kita akan membahas writing & communication — cara membangun pengaruh lewat tulisan: proses menulis dokumen teknis yang efektif, budaya RFC, presentasi yang mengubah keputusan, dan memulai technical blog yang benar-benar berkembang. Sampai jumpa di episode 25!