Belajar Staff Engineer - Working with Product & Business

#Pendahuluan

Setelah di episode 9 kita belajar menaikkan standar lewat design review dan rubrik, pada episode ini kita keluar dari wilayah teknis murni: working with product & business. Staff engineer adalah penerjemah dua arah — mengubah ambisi produk menjadi rencana teknis realistis, dan mengubah keterbatasan teknis menjadi trade-off yang bisa dipahami pengambil keputusan bisnis.

Skill ini menentukan seberapa besar pengaruh kalian: PM dan eksekutif tidak membaca diagram arsitektur mereka membaca angka revenue, biaya, risiko, dan tanggal. Engineer yang bisa berbicara dalam kedua bahasa menjadi mitra strategis; yang hanya bicara teknis menjadi sumber jawaban "tidak bisa".

#Empat Mata Uang Bisnis

Semua diskusi produk-bisnis pada akhirnya diperdagangkan dalam empat mata uang. Kuasai menerjemahkan usulan teknis ke dalam satuan ini:

Latihan praktis: setiap kali kalian akan mengatakan "ini secara teknis rumit", berhenti dan terjemahkan — "rumit" bukan mata uang. "Rumit" versi mata uang terdengar seperti: "fitur ini 3 pekan lebih lambat dari estimasi awam karena butuh konsistensi lintas dua database."

#Menjawab Pertanyaan Feasibility dengan Baik

Pertanyaan paling umum dari dunia produk: "bisa gak sih...?". Jawaban buruk: "bisa, tapi..." (membuka ekspektasi tanpa harga) atau langsung "nggak bisa" (menutup diskusi tanpa alasan). Jawaban level staff punya struktur:

1. Ya, dimungkinkan oleh fisika/perangkat lunak — hampir semua hal bisa; jangan menyembunyikan ini.
2. Harganya dalam mata uang bisnis — waktu, biaya, risiko, opportunity cost.
3. Alternatif yang lebih murah mendekati tujuan — sering ada jalan tengah yang mencapai 80% nilai dengan 20% biaya.

Contoh nyata: PM ingin "notifikasi realtime ke semua pengguna saat merchant update harga".

Bisa dilakukan. Harga mentahnya:
- Infra push notification fan-out untuk 2M user aktif:
  ±$8K/bulan + 5 pekan engineering.
- Risiko: lonjakan traffic saat merchant besar update katalog.
 
Alternatif yang mencapai mayoritas nilainya (estimasi 85%):
- Realtime hanya untuk item di keranjang/watchlist pengguna
  (±3% volume), biaya <$500/bulan, 1 pekan engineering.
Sisanya bisa polling halaman harga - sudah cukup bagi 90% sesi.
 
Rekomendasi saya: mulai dari alternatif, ukur engagement,
naikkan cakupan kalau data mendukung.

Perhatikan pola: tidak ada kata "tidak", semua opsi berharga, dan ada rekomendasi yang bisa ditindaklanjuti hari itu juga.

#Kolaborasi Rutin dengan PM

Hubungan produktif dengan PM dibangun lewat ritual ringan:

Dua sikap yang membuat kalian diundang kembali:

• Katakan apa yang mungkin, bukan hanya apa yang sulit — engineer yang selalu membuka opsi baru ("kalau datanya begini, malah bisa personalisasi") menjadi bagian dari proses kreatif produk, bukan gerbang tol.
• Simpan rekam jejak prediksi — ketika estimasi kalian terbukti akurat berulang kali, suara kalian di ruang planning bernilai premium.

#Praktik: Feasibility Memo

Untuk usulan besar, jawaban lisan tidak cukup — tulis memo singkat di ~/staff-lab/initiatives/feasibility-realtime.md:

# Feasibility Memo: Realtime Price Updates
Tanggal: 2026-08-16 · Untuk: PM Pricing · Status: Draft
 
## Usulan
Notifikasi realtime ke semua pengguna saat merchant update harga.
 
## Opsi
A. Fan-out penuh   : $8K/bln + 5 pekan eng; risiko traffic spike.
B. Realtime selektif: cart/watchlist saja (<$500/bln, 1 pekan);
   sisanya polling. Estimasi cakupan nilai 85%.
C. Tunda           : biaya reputasi vs kompetitor (perlu input PM).
 
## Analisis
Opsi B menangkap perilaku inti (pengguna peduli item yang mereka
pantau) dengan biaya 1/16. Data watchlist sudah ada di session
service - tidak perlu pipeline baru.
 
## Rekomendasi
Mulai B pada 12 September, evaluasi engagement 4 pekan,
lalu putuskan upgrade ke A dengan data nyata.
 
## Yang Saya Butuhkan dari PM
Konfirmasi target engagement minimum agar layak lanjut ke A.

Bagian yang saya butuhkan dari PM mengubah dokumen dari laporan menjadi percakapan — dan menempatkan kalian sebagai mitra, bukan penilai.

#Pitfall Umum Kolaborasi Produk-Teknis

• Menyembunyikan biaya teknis dalam "estimasi aman" — inflasi estimasi diam-diam merusak kepercayaan; tunjukkan komponennya secara transparan.
• Mengalah pada semua permintaan — staff yang selalu iya kehabisan kapasitas untuk pekerjaan leverage tinggi; belajar menolak dengan alternatif (episode 11 membahas lebih dalam).
• Bahasa teknis di ruang bisnis — istilah seperti idempotency atau CAP theorem harus diterjemahkan sebelum dipakai memutuskan.
• Terlambat tahu — kalau kalian pertama kali mendengar fitur besar saat grooming, sistem kolaborasi gagal; dorong discovery lebih awal.
• Menganggap bisnis musuh — PM yang menekan biasanya sedang merasakan tekanan pasar yang tak kalian lihat. Tanyakan konteksnya; sering kali ada informasi berharga di sana.

#Penutup

Inti yang harus dibawa pulang:

• Semua diskusi produk-bisnis diperdagangkan dalam revenue, biaya, risiko, kecepatan — terjemahkan usulan teknis ke mata uang itu.
• Jawab feasibility dengan struktur: ya-bisa, harganya, alternatif murah, rekomendasi.
• Ritual ringan (discovery, review backlog, post-launch) membangun rekam jejak prediksi yang membuat suara kalian bernilai premium.
• Feasibility memo dengan "yang saya butuhkan dari Anda" mengubah kalian dari penilai menjadi mitra.

Di episode 11 selanjutnya kita akan membahas conflict & decisions — kerangka pengambilan keputusan saat tim-tim tidak sepakat, cara disagree and commit yang sehat, dan praktik decision log yang membuat organisasi belajar dari setiap keputusan besar. Sampai jumpa di episode 11!