Belajar Principal Engineer - Org-Wide Technical Strategy

#Pendahuluan

Setelah di episode 3 kalian merumuskan technical vision — destinasi tiga sampai lima tahun organisasi — pada episode ini kita turunkan satu lapis: org-wide technical strategy. Jika vision menjawab "ke mana", strategy menjawab pertanyaan yang jauh lebih sulit: "lewat jalur mana, dengan urutan apa, dan apa yang sengaja kita korbankan?"

Mengapa ini pekerjaan principal, bukan CTO? Karena strategy teknis yang benar lahir dari pemahaman mendalam tentang sistem nyata — di mana utangnya, mana tim yang mampu, komponen apa yang sebenarnya komoditas. Eksekutif punya konteks bisnis penuh tetapi tidak melihat detail sistem; kalian melihat keduanya. Itulah nilai unik posisi ini.

#Keputusan Strategis Lintas Domain

Strategy org hampir selalu tersusun dari kombinasi keputusan berulang ini:

Jenis Keputusan	Pertanyaan Inti	Risiko Salah
Konsolidasi vs Otonomi	Berapa banyak standar tunggal untuk semua tim?	Terlalu ketat: inovasi mati; terlalu longgar: fragmentasi mahal
Build vs Buy vs Partner	Apa yang membedakan kita dan apa yang komoditas?	Build komoditas: boros talenta terbaik
Modernisasi vs Bertahan	Sistem mana layak ditulis ulang?	Rewrite besar-besaran gagal 70%+
Sentralisasi Data	Data lake tunggal atau mesh domain?	Bottleneck tim data atau silo permanen

Tidak ada jawaban universal — strategy adalah pemilihan posisi yang cocok dengan konteks org kalian hari ini, bukan dengan best practice perusahaan lain.

#Kerangka Memilih: Diferensiasi vs Komoditas

Uji paling berguna untuk keputusan build/buy:

Kalangkan setiap kapabilitas dengan pertanyaan: apakah pelanggan membayar lebih karena kita melakukan ini berbeda?
Jawab "ya" → build dan investasikan talenta terbaik (ini diferensiasi).
Jawab "tidak" → buy/adopt open-source, dan curahkan energi ke integrasinya.

Kesalahan klasik org teknologi: membangun sendiri hal komoditas (sistem ticketing, CI tooling) karena menyenangkan bagi engineer, sementara diferensiasi aslinya kurang terawat.

#Long-Horizon Decisions

Keputusan strategis punya ciri yang membedakannya dari keputusan arsitektur biasa:

Mahal untuk dibalik — migrasi identitas org-wide tidak bisa di-rollback seperti deployment.
Efeknya bertahun-tahun — biaya dan manfaatnya melebihi siklus anggaran.
Mengubah opsi masa depan — beberapa keputusan membuka pintu, yang lain menguncinya.

Untuk keputusan seperti ini, gunakan dua alat berpikir:

Real options thinking: pilih jalur yang mempertahankan opsi berharga selama mungkin. Contoh: abstraksi penyimpanan sederhana lebih murah daripada langsung terikat vendor, jika belum yakin skala akan datang.
Reversibility audit: untuk setiap opsi, tulis eksplisit —berapa biaya membaliknya, siapa yang harus setuju, berapa lama. Opsi yang "bisa dibalik secara teori" tetap irreversibel kalau pembalikannya butuh persetujuan lima direktur.

Tip

Saat dua opsi tampak setara, pilih yang lebih mudah dibalik atau yang lebih murah dicoba sebagian. Pilot dua bulan pada lima service memberi informasi yang tidak bisa diberikan dokumen sebagus apa pun.

#Trade-off Standardisasi vs Otonomi

Ini tension abadi strategy org-wide, dan principal adalah penyeimbangnya:

Spektrum kontrol - contoh pemetaan

WAJIB (org-wide, tidak bisa deviasi)
└── Identitas & authn, keamanan dasar, kontrak logging/observability
 
STANDAR + PAVED ROAD (deviasi boleh, tanggung biayanya)
└── Framework app, database utama, pipeline deploy, IDP
 
BEBAS (tim memilih sendiri)
└── Library internal, struktur repo, pola desain modul

Prinsip penentuannya: semakin lintas batas tim sebuah keputusan, semakin tinggi di spektrum ia harus dipaku. Authn menyentuh semua tim → wajib. Struktur folder repo hanya menyentuh satu tim → bebas.

#Templat Strategy Doc Satu Halaman

Eksekutif tidak membaca sepuluh halaman. Format satu halaman ini yang kita pakai:

vision/strategy-[domain].md

# Strategy: [Domain] - [Periode]
 
## Keputusan Utama
Satu paragraf: apa yang kita putuskan dan mengapa sekarang.
 
## Konteks Bisnis & Teknis
Angka yang memicu: biaya, insiden, velocity, keluhan pelanggan.
 
## Opsi yang Dipertimbangkan
Opsi A / B / C - pro, kontra, biaya balik jika salah.
 
## Pilihan & Alasan
Opsi terpilih + trade-off yang disadari dan diterima.
 
## Rencana Bertahap
Gelombang 1 (pilot) / Gelombang 2 (perluasan) / Gelombang 3 (standar).
 
## Metrik & Kill Switch
Metrik sukses per gelombang; kondisi eksplisit saat kita berhenti.
 
## Yang Kita Korbankan
Apa yang sengaja TIDAK dilakukan periode ini.

Bagian Kill Switch adalah bentuk kejujuran paling bernilai: kalian menyetel kondisi kegagalan sebelum emosi tim sudah terlanjur terikat pada proyek.

#Praktik: Tulis Strategy Doc

Di workspace kalian:

Pilih satu tension nyata di org kalian (contoh: empat sistem antrian pesan berbeda).
Isi templat satu halaman di atas — batasi diri maksimal 600 kata.
Uji dengan dua pembaca: satu eksekutif (apakah keputusan dan alasannya jelas dalam lima menit?) dan satu staff engineer (apakah realita teknisnya akurat?).
Simpan di vision/strategy-[domain].md — dokumen ini akan menjadi bahan latihan governance di episode berikutnya.

Warning

Strategy tanpa daftar pengorbanan akan runtuh di rapat budget: orang akan bertanya "kalau semua ini penting, mana yang kita turunkan?" Jawab harus sudah tertulis, bukan diimprovisasi.

#Penutup

Inti yang harus dibawa pulang:

Strategy = pemilihan posisi pada tension lintas domain: konsolidasi vs otonomi, build vs buy, modernisasi vs bertahan.
Pisahkan diferensiasi (build) dari komoditas (bel/adopsi); kesalahan umum adalah kebalikannya.
Keputusan long-horizon dinilai dengan reversibility: pilih opsi yang mempertahankan opsi masa depan.
Strategy doc satu halaman dengan metrik dan kill switch eksplisit — plus daftar apa yang dikorbankan.

Di episode 5 selanjutnya kita membahas architecture governance — cara menjaga standar dan keputusan tetap hidup tanpa menjadi birokrasi: desain Architecture Review Board, tier review ringan, paved roads, dan anti-pattern governance ala polisi lalu lintas. Sampai jumpa di episode 5!