Belajar Principal Engineer - Technical Vision

#Pendahuluan

Setelah di episode 2 kalian mendefinisikan scope — kepemilikan arsitektur, platform, dan AI di level organisasi — pada episode ini kita isi kepemilikan pertama itu dengan artefak paling fundamental: technical vision.

Mengapa org butuh vision? Karena tanpa arah yang tertulis, setiap tim mengoptimalkan masalah lokalnya masing-masing. Tim A memilih framework favoritnya, tim B menulis sistem auth sendiri, dan tiga tahun kemudian org membayar mahal untuk konsolidasi. Vision adalah jawaban atas pertanyaan "ke mana kita menuju?" yang cukup jelas sehingga seribu keputusan harian bisa mengarah ke sana tanpa kalian hadir di setiap rapat.

#Vision vs Strategy vs Roadmap

Tiga istilah ini sering dicampur; pisahkan dengan tegas:

Artefak	Menjawab	Horizon	Contoh Kalimat
Vision	Ke mana kita menuju?	3-5 tahun	"Semua layanan internal menyediakan API standar yang bisa dikomposisi"
Strategy	Lewat jalur mana?	12-18 bulan	"Konsolidasi dari 4 sistem auth ke satu platform identitas"
Roadmap	Urutan apa, kapan?	2-4 kuartal	"Q1: audit & pilih target; Q2: migrasi 5 service perintis"

Analogi pelayaran: vision adalah destinasi, strategy adalah rute, roadmap adalah jadwal pelabuhan. Principal yang melompat langsung ke roadmap tanpa dua lapisan di atasnya akan terus-menerus mengubah jadwal setiap kali ada badai kecil.

Note

Vision yang baik tidak boleh bisa dicapai dalam satu kuartal. Jika seluruh visi kalian bisa diselesaikan tim biasa dalam enam bulan, itu bukan vision — itu backlog.

#Sumber Bahan Vision

Vision bukan karangan bebas. Empat input wajib sebelum kalian menulis:

Strategi bisnis — baca rencana tahunan perusahaan. Jika bisnis bergerak ke enterprise, konsekuensi teknisnya auditability dan multi-tenancy, bukan fitur cepat.
Realita sistem saat ini — inventaris jujur: berapa banyak teknologi duplikat, di mana utang teknis paling mahal.
Tren industri yang relevan — AI, platform engineering, regulasi. Filter keras: tren hanya masuk vision jika ia mengubah asumsi bisnis kalian.
Naluri engineer terbaik kalian — wawancara singkat 8-10 orang lintas tim: apa yang paling menghambat mereka?

Input keempat punya efek samping berharga: orang yang diwawancarai merasa memiliki visi tersebut — dan visi tanpa pemilik akan mati diam-diam.

#Anatomi Vision Doc

Format yang saya pakai dan kembangkan sepanjang series:

vision/tech-vision.md

# Technical Vision [Org] - 2026-2029
 
## Prinsip Utama (3-5 prinsip)
Contoh: "API-first", "Buy sebelum build untuk komoditas",
"Safety default-on".
 
## Dunia Target (narasi 1 halaman)
Gambaran hari kerja engineer & pengguna di 2029 jika visi tercapai.
Konkrit, spesifik pada konteks org kita, hindari buzzword.
 
## Pilar Strategis (3-5 pilar)
Pilar 1: Platform tunggal - satu IDP, golden paths untuk semua stack.
Pilar 2: Identitas terpusat - satu authn/authz org-wide.
Pilar 3: AI-augmented delivery - evals & tooling standar.
 
## Apa yang Kita Tinggalkan
Teknologi/pola yang TIDAK akan kita investasikan lagi + alasan +
rencana exit.
 
## Cara Kita Tahu Sedang Benar
Metrik utama & target: deployment frequency, cost per transaksi,
time-to-market fitur baru.
 
## Batas Waktu & Review
Review tiap 6 bulan; pemilik: Principal Engineer [nama].

Bagian Apa yang Kita Tinggalkan adalah penanda paling jelas antara vision serius dan poster motivasi. Visi selalu berarti berkata tidak pada sesuatu — tuliskan secara eksplisit apa yang kalian tinggalkan.

#Menciptakan Alignment Sebelum Rilis

Kesalahan fatal principal baru: menulis visi sendirian selama sebulan, lalu mengumumkannya. Hasilnya hampir pasti ditolak — bukan karena isinya salah, tapi karena orang tidak suka diberi keputusan, mereka ingin dilibatkan. Proses yang bekerja:

100%

Detail tahap paling menentukan — pre-alignment 1:1: sebelum forum apa pun, temui setiap lead tim secara privat, tunjukkan draft, dan tanyakan satu pertanyaan: "bagian mana yang membuat tim kalian gagal jika visi ini dijalankan?". Revisi draft berdasarkan jawabannya. Saat visi masuk forum publik, mayoritas orang sudah melihat idenya dan namanya (kontribusi mereka) ada di dalamnya.

Important

Aturan praktis alignment: saat visi dipresentasikan resmi, tidak boleh ada argumen baru. Semua perdebatan besar sudah terjadi di ruang kecil. Forum publik adalah tempat konfirmasi, bukan tempat kejutan.

#Praktik: Tulis Vision Doc Pertama

Untuk workspace kalian:

Ambil satu domain dari scope statement episode 2 (misal platform).
Kumpulkan empat input di atas — batasi riset maksimal dua minggu; visi yang sempurna terlambat sama saja dengan tidak ada.
Tulis draft mengikuti anatomi di atas, maksimal dua halaman.
Jalankan siklus pre-alignment dengan minimal tiga orang: satu manajer, satu staff engineer, satu PM.
Simpan versi bertanggal di vision/ — di episode 27 kalian akan mengevaluasi ulangnya sebagai latihan refleksi.

#Menjaga Vision Tetap Hidup

Vision yang dirilis lalu dilupakan lebih buruk daripada tidak punya visi — org belajar bahwa dokumen strategis di sini cuma hiasan. Tiga mekanisme agar tetap hidup:

Referensi rutin — setiap RFC besar diminta menyebut pilar vision mana yang didukungnya.
Review semesteran — cek metrik "Cara Kita Tahu Sedang Benar"; revisi tanpa rasa bersalah jika dunia berubah.
Cerita progres — tiap kuartal, publikasikan satu halaman "kemajuan menuju visi" dengan angka. Momentum dibangun dari bukti, bukan pengulangan slogan.

#Penutup

Inti yang harus dibawa pulang:

Vision menjawab ke mana, strategy lewat jalur apa, roadmap urutan kapan — jangan campur.
Bahan visi datang dari strategi bisnis, realita sistem, tren terfilter, dan naluri engineer terbaik.
Anatomi vision doc: prinsip, dunia target, pilar, apa yang ditinggalkan, metrik keberhasilan.
Alignment dibangun lewat 1:1 sebelum forum publik; visi dirawat lewat referensi rutin dan review semesteran.

Di episode 4 selanjutnya kita turunkan visi menjadi org-wide technical strategy — keputusan lintas domain berhorizon panjang: konsolidasi, build vs buy, dan trade-off antara standardisasi dan otonomi tim, beserta templat strategy doc satu halaman. Sampai jumpa di episode 4!