Memahami model dampak staff engineer dari team ke multi-team ke org impact, cara kerja leverage melalui sistem keputusan dan orang yang kalian tumbuhkan, serta latihan menulis impact statement terukur untuk enam bulan ke depan

Setelah di episode 1 kita mengenal arketipe dan posisi staff di IC ladder, pada episode ini kita masuk ke konsep yang paling menentukan evaluasi kalian: impact model & scope. Saat komite promosi menilai kandidat staff, pertanyaannya bukan "seberapa pintar dia?" melainkan "dampaknya berhenti di mana?" — di satu tim, lintas beberapa tim, atau di seluruh organisasi.
Mengapa ini penting dipelajari sadar? Karena banyak engineer senior bekerja sangat keras namun scope dampaknya tidak pernah melebar: mereka membantu tim sendiri dengan sangat baik, lalu bertanya-tanya kenapa promosi staff tidak datang. Episode ini mengajarkan cara memperluas scope secara sengaja, bukan kebetulan.
Bayangkan scope sebagai tiga lapis konsentris. Setiap level naik, satuan analisis dan horizon waktu ikut bergeser:
| Lapis | Contoh Kontribusi | Bukti yang Diakui |
|---|---|---|
| Team | Merancang service inti, tech lead fitur besar | Delivery tepat, kualitas kode |
| Multi-team | Standar API bersama, migrasi lintas 3 tim, ADR yang diadopsi | Tim lain mengutip/memakai karya kalian |
| Org | Technical strategy area, program reliability, framework hiring | Kebijakan/program yang mengubah cara org bekerja |
Kunci praktisnya: dampak multi-team biasanya dimulai dari masalah yang sama-sama dirasakan. Temukan pekerjaan yang menyakitkan bagi tiga tim sekaligus — di sanalah peluang scope kalian.
Staff engineer punya empat tuas utama. Urutan tuas juga urutan leverage — dari paling kecil ke paling besar:
Pitfall klasik: terjebak di tuas 1 karena nyaman. Menulis kode memberi dopamin cepat dan hasil terlihat hari itu; menulis standar memberi hasil delapan bulan kemudian. Komponen keduanya wajar — tapi pastikan proporsinya condong ke tuas atas saat kalian mengejar staff.
Tip
Uji leverage sederhana: jika kalian cuti sebulan, apa yang tetap berjalan karena sistem, dokumen, dan orang yang pernah kalian bangun? Semakin banyak jawabannya, semakin tinggi leverage kalian.
Tiga istilah ini sering dicampur padahal berbeda:
Evaluasi staff-plus selalu duduk di lapisan impact. Latihan menaikkan tangga ini: setiap kali merinci pencapaian, tanyakan "lalu apa artinya?" sampai kalian menyentuh angka yang peduli bagi pemimpin organisasi.
Buka ~/staff-lab/portfolio/impact.md dan tulis impact statement menggunakan pola berikut:
Untuk [siapa yang terdampak],
saya [kontribusi konkret: sistem/keputusan/mentoring].
Sebelumnya [kondisi awal, dengan angka].
Setelahnya [perubahan terukur, dengan angka].
Artinya bagi organisasi: [dampak bisnis satu kalimat].
Contoh terisi:
Untuk 4 tim pembayaran dan settlement,
saya merancang skema idempotency-key bersama dan memandu adopsinya.
Sebelumnya duplikasi transaksi 0.7% per bulan (±$9K kerugian).
Setelahnya duplikasi turun ke 0.02% dalam satu kuartal.
Artinya bagi organisasi: kepercayaan merchant terjaga dan kerugian
duplikasi hilang.Perhatikan ciri statement kuat: ada penerima manfaat spesifik, angka sebelum-sesudah, dan satu kalimat arti bisnis. Jika kalian kesulitan mengisi angka, itu bukan alasan menyerah — justru sinyal bahwa mulai sekarang kalian harus mengukur pekerjaan kalian (kerangka metriknya kita bangun di episode 15).
Warning
Pitfall umum: menulis daftar aktivitas ("membuat 12 RFC, hadir di 5 komite") dan menyebutnya impact. Aktivitas adalah input. Komite promosi membaca perubahan dunia yang kalian buat, bukan kesibukan kalian.
Tidak semua masalah pantas kalian ambil. Gunakan filter tiga pertanyaan:
| Pertanyaan | Jika Ya |
|---|---|
| Apakah ini menyakiti lebih dari satu tim? | Peluang scope multi-team |
| Apakah orang lain bisa mengerjakannya tanpa saya? | Delegasikan, jadikan reviewer |
| Apakah solusinya akan diadopsi orang lain? | Prioritaskan — adopsi adalah bukti dampak |
Aturan praktis: alokasikan waktu kalian minimal 60% pada pekerjaan yang tak bisa dikerjakan orang lain, dan sisanya menjaga craft tetap tajam. Pekerjaan yang hanya bisa kalian kerjakan biasanya juga pekerjaan yang paling menggerakkan needle evaluasi kalian.
Inti yang harus dibawa pulang:
Di episode 3 selanjutnya kita akan membahas technical leadership — cara memimpin arah teknis tanpa otoritas formal, membangun trust yang menjadi bahan bakar influence, dan studi kasus leadership nyata dari sebuah inisiatif standardisasi. Sampai jumpa di episode 3!