Belajar Staff Engineer - Technical Leadership

#Pendahuluan

Setelah di episode 2 kita membangun impact model — scope, leverage, dan impact statement pertama kalian — pada episode ini kita masuk ke bahan bakarnya: technical leadership. Staff engineer hampir tidak pernah punya wewenang memerintah tim lain, tetapi diharapkan mengarahkan keputusan teknis lintas tim. Satu-satunya cara itu berhasil adalah leadership by influence: kemampuan membuat orang mengikuti arah kalian karena percaya, bukan karena disuruh.

Kita bedah anatomi direction setting, cara membangun trust secara sistematis, dan menutup dengan studi kasus nyata yang bisa kalian replikasi.

#Leadership Tanpa Otoritas: Aturan Dasarnya

Manajer memaksa lewat struktur (penugasan, evaluasi). Staff engineer meyakinkan lewat tiga hal:

1. Kompetensi terbukti — kalian pernah benar di masalah yang serupa; rekam jejak berbicara lebih keras dari slide.
2. Kejelasan — usulan kalian mudah dipahami: diagram jelas, trade-off eksplisit, langkah konkret.
3. Kepedulian pada pihak lain — orang mengikuti arah yang mereka yakini juga memikirkan kepentingan mereka.

Pola mental yang berguna: kalian bukan "pemberi jawaban", melainkan pembentuk kesepakatan. Keputusan lintas tim yang bertahan adalah yang dirasa dimiliki semua pihak — tugas kalian memfasilitasi sampai kesana.

#Direction Setting: Memberi Arah Teknis

Direction setting adalah kemampuan menjawab "ke mana area teknis kita harus bergerak dan mengapa" — lalu membuat organisasi bergerak ke sana. Praktiknya berlapis:

Urutan penulisan penting: prinsip tanpa rencana hanya slogan; rencana tanpa visi kehilangan momentum setelah milestone pertama. Kita dalami artefak strategy secara utuh di episode 6 — di sini fokusnya kebiasaan berpikir arah sebelum berpikir solusi.

#Membangun Trust Secara Sistematis

Trust bukan karisma — ia hasil akumulasi perilaku yang bisa dilatih:

• Tepati janji kecil — review yang kalian janjikan hari Kamis dikirim hari Kamis. Konsistensi halus mengalahkan gestur besar.
• Benar di saat mahal — satu analisis akurat saat insiden memberi kredit lebih dari sepuluh opini biasa.
• Transparan soal ketidakpastian — bilang "saya tidak yakin, mari kita validasi dengan data". Orang percaya pada yang jujur soal batas ilmunya.
• Bela kepentingan tim lain — saat rapat desain, suarakan dampak proposal terhadap tim yang tidak hadir. Ini membangun reputasi lintas tim lebih cepat dari apa pun.

#Teknik Influence Sehari-hari

Beberapa teknik konkret yang bisa langsung dipakai:

#Pre-wiring: Bicarakan Sebelum Diumumkan

Sebelum membawa proposal besar ke forum, ajak bicara 1-on-1 pemilik kepentingan utama. Masukkan masukan mereka ke draft. Saat forum datang, tidak ada yang terkejut — dan dua-tiga orang sudah menjadi sekutu. Rapat besar bukan tempat berdebat pertama; ia tempat meratifikasi kesepakatan.

#Framing: Jual Masalah Sebelum Solusi

Mulailah dari masalah yang dirasakan audiens, dengan angka. Bandingkan dua pembuka:

• Lemah: "Kita harus migrasi ke structured logging."
• Kuat: "Insiden bulan lalu butuh 4 jam karena log tidak bisa dicari lintas service; biayanya 40 person-jam. Structured logging memotong waktu pencarian rata-rata 60%."

Framing kedua membuat audiens sampai ke kesimpulan yang sama sebelum kalian menyebut solusi.

#Make It Easy to Say Yes

Turunkan biaya persetujuan: sediakan prototipe, estimasi effort per tim, dan jalur adopsi bertahap (pilot satu tim → evaluasi → rollout). Semakin kecil risiko yang dirasakan pihak lain, semakin cepat arah kalian diadopsi.

#Studi Kasus: Standardisasi Observability

Mari lihat pola lengkapnya dalam kasus nyata. Situasi: empat tim produk, tiap tim punya format log dan metrik sendiri, investigasi insiden selalu macet di batas antar service.

Langkah yang diambil seorang staff engineer:

1. Kumpulkan bukti — hitung waktu rata-rata investigasi insiden lintas service dari postmortem 6 bulan terakhir: 3,5 jam, mayoritas habis mencari data.
2. Pre-wire — bicara dengan lead keempat tim; temukan bahwa dua tim sebenarnya ingin beralih tapi tak ada yang memulai.
3. Rancang paved road — pilih satu stack observability, buat library wrapper, template dashboard, dan panduan migrasi 2 hari per service.
4. Pilot — satu tim migrasi duluan dalam satu sprint; dokumentasikan hasil: waktu investigasi turun ke 50 menit.
5. Ratifikasi — presentasikan hasil pilot di forum engineering; keempat tim setuju jadwal adopsi masing-masing.
6. Jaga momentum — tinjau adopsi tiap bulan, blokir jalan (kompatibilitas tooling), rayakan tim tercepat.

Total waktu: satu kuartal, tanpa satu pun perintah manajerial. Itulah bentuk technical leadership di level staff: arah yang benar, dibuktikan dengan pilot, diadopsi sukarela.

#Pitfall Umum Leadership Staff

• Menjual solusi tanpa membangun masalah — audiens menolak karena belum merasa sakitnya.
• Mengabaikan politik organisasi — bukan intrik, melainkan pemetaan siapa peduli apa. Proposal yang benar bisa gagal jika pemilik budget tidak pernah diajak.
• Influence one-shot — memenangkan satu debat lalu hilang enam bulan. Pengaruh dibangun dari kehadiran berkelanjutan.
• Menolak berkompromi — arah kalian tidak harus sempurna; versi 80% yang diadopsi semua orang mengalahkan versi 100% yang ditolak.

#Penutup

Inti yang harus dibawa pulang:

• Leadership staff = influence tanpa otoritas: kompetensi terbukti, kejelasan, dan kepedulian pada pihak lain.
• Direction setting bekerja berlapis: visi area, prinsip, lalu rencana konkret.
• Trust dibangun dari deposit kecil konsisten; pre-wiring dan framing masalah adalah teknik harian yang paling berdampak.
• Studi kasus standardisasi menunjukkan pola: bukti → pre-wire → paved road → pilot → ratifikasi → momentum.

Di episode 4 selanjutnya kita akan membahas architecture ownership — cara mengambil kepemilikan atas arsitektur lintas tim, kerangka menganalisa trade-off, dan praktik menulis ADR yang benar-benar dipakai organisasi. Sampai jumpa di episode 4!