Belajar Staff Engineer - Technical Strategy

#Pendahuluan

Setelah di episode 5 kita belajar menyelaraskan tim lewat peta dependency, kontrak interface, dan alignment plan, pada episode ini kita naik satu tingkat artefak: technical strategy. Alignment plan menyatukan tim untuk satu inisiatif; strategi menjawab pertanyaan lebih besar — ke mana area teknis kita harus bergerak dalam setahun, apa yang kita pilih untuk tidak kerjakan, dan mengapa.

Mengapa skill ini menentukan? Karena tanpa strategi tertulis, prioritas organisasi ditentukan oleh suara paling keras atau kepanikan minggu terakhir. Strategi adalah cara staff engineer memberi arah yang bertahan lebih lama dari rapat mana pun.

#Strategy vs Vision vs Roadmap

Tiga istilah ini sering tertukar. Posisi dan fungsinya:

Strategi tanpa visi mudah tersesat saat konteks berubah; visi tanpa strategi hanya poster di dinding; keduanya tanpa roadmap tidak pernah menyentuh backlog siapa pun. Staff engineer biasanya memiliki strategi area; vision org-wide adalah topik episode 24.

#Kerangka Diagnosis → Panduan → Bets

Kerangka paling berguna (diadaptasi dari Richard Rumelt) memecah strategi menjadi tiga bagian:

#1. Diagnosis: Kenyataan yang Menentukan

Satu-dua paragraf tentang masalah struktural utama area kalian, dengan bukti. Bukan daftar keluhan, melainkan satu penyebab akar yang kalau diselesaikan membuka banyak hal. Contoh: "Kecepatan rilis kita dibatasi oleh 14 skema database yang saling digantung; semua inisiatif lain mengantre di baliknya."

#2. Panduan (Guiding Policy): Pendekatan Umum

Aturan main untuk menghadapi diagnosis tersebut — batu pagar yang membuat keputusan harian lebih mudah. Contoh: "Prioritaskan pekerjaan yang memutus coupling data; fitur baru boleh jalan jika tak menambah coupling."

#3. Bets: Taruhan Konkret Terpilih

Daftar 2-4 taruhan besar dengan hasil terukur dan tanggal evaluasi. Kata "bet" disengaja: strategi jujur mengakui ketidakpastian. Tiap bet punya format ringkas:

Bet 2 : Event-driven integration antar domain
Kenapa: memutus coupling skema (akar diagnosis)
Hasil : 3 domain berkomunikasi via event kontrak v1
Ukur : lead time integrasi baru turun dari 6 pekan ke 1 pekan
Evaluasi: akhir Q2 - lanjut, pivot, atau stop

Bagian evaluasi dengan opsi stop adalah ciri strategi dewasa — taruhan boleh kalah, asal kekalahan terdeteksi cepat dan murah.

#Praktik: Tech Strategy Doc Satu Halaman

Buat ~/staff-lab/strategy/area-platform.md dengan templat ini:

# Technical Strategy: Platform Data (H2 2026)
 
Author: [nama] · Status: Draft · Reviewer: [3 lead + VP Eng]
 
## Diagnosis
Delivery dibatasi coupling skema database lintas 14 layanan;
lead time integrasi rata-rata 6 pekan; 40% insiden berasal dari
migrasi schema yang merembet ke layanan lain.
 
## Panduan
1. Utamakan pemutusan coupling data atas fitur baru.
2. Setiap domain memiliki skema miliknya; akses hanya via API/event.
3. Migrasi bertahap per domain, bukan big-bang rewrite.
 
## Bets
1. Contract-first API gateway data -> pilot domain billing (Q3).
2. Event-driven integration -> 3 domain on contract v1 (Q4).
3. Schema ownership program -> 14 layanan terpetakan & dimiliki (Q3).
 
## Yang Tidak Kami Kerjakan
Rewrite monolit, ganti ORM, multi-region (ditunda ke 2027).
 
## Metrik Sukses
Lead time integrasi 6 -> 1 pekan; insiden akibat migrasi turun 60%;
adopsi gateway 8 dari 14 layanan.

Bagian Yang Tidak Kami Kerjakan sama pentingnya dengan bets — ia yang melindungi fokus tim dari proyek sampingan yang menggoda.

#Menghidupkan Strategi: Dari Dokumen ke Prioritas

Strategi yang mati di Google Docs adalah pitfall nomor satu. Tiga mekanisme agar ia bekerja:

1. Ratifikasi resmi — presentasikan ke lead dan manajemen, minta persetujuan eksplisit. Strategi yang diratifikasi bisa dipertahankan saat ada tekanan melenceng; draft tidak bisa.
2. Kaitkan ke planning cycle — tiap bet harus muncul sebagai item di perencanaan kuartalan tim-tim terkait. Kalau tidak ada ruang kapasitas, itu bukan strategi — hanya harapan.
3. Review berkala — tinjau tiap enam pekan: metrik bet bergerak? Asumsi masih benar? Revisi terbuka, versi tercatat.

Saat tekanan datang ("tolong kerjakan ini juga"), strategi memberi kalian bahasa penolakan yang sopan dan berwibawa: "Ini di luar bets kami kuartal ini — mari bicara apa yang kita tunda sebagai gantinya."

#Kesalahan Umum Menulis Strategi

• Wish list, bukan pilihan — daftar semua hal bagus tanpa trade-off bukan strategi; strategi selalu berarti memilih dan menolak.
• Diagnosis dangkal — "teknologi kita usang" bukan diagnosis; cari penyebab struktural dengan angka.
• Terlalu banyak bets — lima bets berarti tidak ada prioritas; organisasi hanya sanggup mengejar dua-tiga arah besar sekaligus.
• Bahasa abstrak — "memperkuat kolaborasi" tidak bisa dievaluasi. Ganti dengan angka dan tanggal.
• Tidak ada pemilik — strategi tanpa nama yang mempertahankannya akan dikalahkan oleh deadline pertama yang mendesak.

#Penutup

Inti yang harus dibawa pulang:

• Bedakan vision (ke mana), strategy (jalur dan kenapa), roadmap (urutan) — staff engineer menulis strategi area.
• Gunakan kerangka diagnosis → panduan → bets: akar masalah dengan bukti, aturan main, lalu 2-4 taruhan terukur dengan titik evaluasi.
• Sertakan "yang tidak kami kerjakan"; fokus adalah inti strategi.
• Hidupkan lewat ratifikasi, kaitan ke planning cycle, dan review enam-pekanan — strategi tanpa mekanisme hanyalah dokumen.

Di episode 7 selanjutnya kita akan membahas initiative design & execution — cara merancang inisiatif besar dari breakdown, milestone, success metrics, sampai mengeksekusinya tanpa kehabisan tenaga di tengah jalan. Sampai jumpa di episode 7!