Belajar Principal Engineer - Leading Complex Initiatives

#Pendahuluan

Setelah di episode 5 kalian merancang governance — ARB, tier review, dan paved roads yang menjaga keputusan harian tetap selaras — pada episode ini kita naik ke pekerjaan yang paling terlihat dari peran principal: memimpin inisiatif kompleks. Migrasi monolit, pembangunan platform, atau peluncuran program AI org-wide.

Mengapa ini penting? Karena inisiatif besar adalah tempat karir principal dibuktikan atau diragukan. Org menilai principal bukan dari dokumen terbaiknya, melainkan dari satu pertanyaan: "apakah hal besar yang ia pimpin benar-benar selesai dan mengubah angka?" Inisiatif yang mati di 90% justru lebih buruk daripada tidak dimulai — org membayar penuh dan menua tanpa hasil.

#Anatomi Inisiatif Besar

Inisiatif 0→1 melewati empat fase; kegagalan hampir selalu bisa dilacak ke fase yang dilewati:

100%

Fase	Pertanyaan Kunci	Kegagalan Tipikal
Framing	Masalah apa, seberapa mahal jika dibiarkan?	Solusi mencari masalah
Sponsorship	Siapa eksekutif yang akan mempertaruhkan kredibilitasnya?	Sponsor pasif yang hanya "setuju"
Eksekusi	Gelombang mana dulu, metrik apa per gelombang?	Big bang sekali jalan
Landing	Siapa pemilik permanennya setelah ini?	Inisiatif tak pernah lepas dari inisiator

#Framing: Mulai dari Masalah, Bukan Solusi

Framing yang kuat selalu berbentuk: masalah nyata + biaya status quo + ukuran keberhasilan. Bandingkan:

Lemah: "Kita perlu migrasi ke Kubernetes karena industri sudah begitu."
Kuat: "Deployment kami butuh 45 menit dengan change failure rate 18%; biaya insiden terkait rilis tahun lalu 2.400 jam engineer. Target: lead time di bawah 10 menit, failure rate di bawah 5%, diukur tiap bulan."

Versi kedua bisa dibantah, diuji, dan dipertanggungjawabkan — itulah gunanya. Angkanya tidak harus sempurna; ia harus cukup jujur untuk diperdebatkan.

Tip

Sebelum framing final, tulis "memo mundur": bayangkan inisiatif gagal dua tahun lagi, lalu tulis tiga alasan paling mungkin kegagalannya. Setiap alasan harus punya jawaban di blueprint kalian. Ini versi murah dari pra-mortem yang terbukti menyelamatkan banyak program.

#Sponsorship: Bedakan Setuju dan Memiliki

Sponsor yang setuju akan membiarkan kalian bekerja; sponsor yang memiliki inisiatif akan membelanya di rapat budget saat musim sulit. Cara mengubah yang pertama menjadi kedua:

Ajak calon sponsor membentuk framing, bukan hanya mereviewnya.
Buat mereka menyampaikan sendiri bagian cerita bisnis di forum exec.
Sepakati eksplisit kondisi berhenti (kill switch) bersama — orang menjaga investasi yang ia bantu rancang batas risikonya.

Tanpa sponsor seperti ini, inisiatif kalian hidup selama goodwill ada — biasanya sampai kuartal fiskal berikutnya.

#Blueprint Inisiatif

Artefak utama kalian selama fase awal adalah blueprint dua halaman:

initiatives/blueprint-[nama].md

# Blueprint: [Nama Inisiatif]
 
## Masalah & Biaya Status Quo
Angka: jam engineer hilang, insiden, keluhan pelanggan.
 
## Hasil Akhir yang Diinginkan
Keadaan akhir yang konkret + metrik target + tanggal evaluasi.
 
## Sponsor & Pemangku
Sponsor: [nama, komitmen eksplisit]. Terdampak: tim + cara dilibatkan.
 
## Gelombang Eksekusi
Gelombang 1 (pilot, 4-8 minggu): scope sempit, tim sukarela,
metrik bukti.
Gelombang 2: perluasan + kurva belajar terdokumentasi.
Gelombang 3: standar default untuk semua tim.
 
## Risiko Utama & Mitigasi
Top 3 risiko, termasuk risiko manusia (kelelahan, resistensi).
 
## Kill Switch
Kondisi eksplisit berhenti/berbalik arah + siapa memutuskan.
 
## Rencana Landing
Pemilik permanen, handover docs, kriteria "selesai".

Perhatikan bahwa blueprint ini memaksa keputusan yang sering ditunda: siapa pemiliknya setelah selesai, dan kapan proyek boleh dihentikan.

#Eksekusi Bertahap: Pelajaran dari Migrasi Besar

Aturan eksekusi inisiatif besar hampir selalu sama — jangan pernah big bang:

Gelombang 1 = pilot dengan tim sukarela. Tujuannya bukan hasil bisnis, melainkan bukti dan pola migrasi yang bisa direplikasi.
Dokumentasikan playbook dari gelombang pertama: langkah, jebakan, estimasi riil. Playbook inilah yang membuat gelombang berikutnya 3-5x lebih cepat.
Ukur per gelombang dan publikasikan angkanya — momentum inisiatif bergantung pada bukti yang terlihat.
Rencanakan co-existence: sistem lama dan baru akan hidup berdampingan berbulan-bulan; desain jalurnya sejak awal, jangan biarkan jadi improvisasi.

Warning

Fase paling berbahaya adalah 90%: sistem lama tinggal sedikit penggunanya, motivasi tim surut, dan dorongan untuk "selesai saja nanti" datang dari semua arah. Antisipasi dengan aturan eksplisit sejak blueprint: inisiativ dinyatakan selesai hanya ketika sistem lama benar-benar dimatikan — bukan ketika fitur barunya jadi.

#Landing: Lepaskan Inisiatif

Inisiatif yang sukses tetap gagal sebagai kepemimpinan kalau tidak bisa lepas dari tangan inisiatornya. Tiga langkah landing:

Tunjuk pemilik permanen — biasanya tim platform/domain yang relevan; libatkan mereka sejak gelombang 1 agar tidak asing.
Handover tertulis — arsitektur keputusan, playbook operasi, dan utang yang sengaja ditunda.
Catat dampak di portofolio — angka sebelum/sesudah, biaya, dan pelajaran. Episode 25 kita pakai untuk urusan legacy, episode 27 untuk karir.

#Penutup

Inti yang harus dibawa pulang:

Inisiatif besar punya empat fase — framing, sponsorship, eksekusi bertahap, landing — dan kegagalan lahir dari fase yang dilewati.
Framing kuat = masalah + biaya status quo + ukuran keberhasilan; uji dengan memo mundur.
Sponsor yang memiliki inisiatif dibentuk lewat keterlibatan merancang framing dan kill switch.
Tidak pernah big bang; pilot → playbook → perluasan → default. Selesai = sistem lama dimatikan, bukan fitur baru jadi.

Di episode 7 selanjutnya kita membahas platform & ecosystem strategy — cara berpikir seperti pemilik produk untuk internal developer platform: golden paths, metrik DX, build vs buy komponen platform, dan cara memastikan platform kalian diadopsi bukan diabaikan. Sampai jumpa di episode 7!