Belajar Staff Engineer - Writing & Communication

#Pendahuluan

Setelah di episode 24 kita merangkai vision dan roadmap organisasi, pada episode ini kita dalami keahlian tunggal yang paling sering disebut sebagai pembeda staff engineer efektif: writing & communication. Hampir semua skill series ini — ADR, strategy doc, alignment plan, briefing eksekutif, scorecard — adalah tulisan. Kualitas tulisan kalian adalah batas atas pengaruh kalian.

Kabar baiknya: menulis baik adalah keterampilan mekanis yang bisa dilatih, bukan bakat. Episode ini memberi sistemnya — dari proses draf sampai budaya RFC dan technical blog.

#Menulis untuk Keputusan, Bukan untuk Arsip

Dokumen teknis gagal karena ditulis untuk "mencatat", padahal pembacanya datang untuk memutuskan atau bertindak. Tiga prinsip dasar:

1. Satu dokumen, satu pertanyaan — sebelum menulis, tulis di bagian atas: "dokumen ini ada untuk menjawab/memutuskan apa?" Kalau jawabannya "berbagai hal", pecah.
2. BLUF selalu — kesimpulan/permintaan di paragraf pertama (pola episode 22); detail dan kronologi menyusul bagi yang ingin menggali.
3. Tulis untuk pembaca sibuk — asumsikan pembaca punya 5 menit. Struktur yang selamat uji ini: ringkasan → konteks minimal → analisis → rekomendasi → lampiran.

Uji cepat sebelum kirim: baca hanya judul + kalimat pertama tiap paragraf. Apakah alur argumennya sudah terasa? Itulah yang dibaca mayoritas pembaca sungguhan.

#Proses Menulis yang Bertahan Deadline

Menulis lambat biasanya karena mencoba berpikir dan merapikan bersamaan. Pisahkan tiga fase:

FASE 1 - Kerangka kasar (15 menit)
   Daftar poin mentah tanpa kalimat bagus; urutkan alurnya.
FASE 2 - Draf jelek lengkap (satu duduk)
   Isi semua bagian; larangan revisi. Draf jelek bisa
   diperbaiki; halaman kosong tidak.
FASE 3 - Penyuntingan keras (waktu terpisah, ideal besoknya)
   Potong 20% panjang; perjelas ask; hapus kata lembut
   ("mungkin agak", "sepertinya") yang mengaburkan klaim.

Fase 3 punya checklist singkat: setiap klaim punya angka atau contoh? Setiap istilah teknis jelas bagi pembaca target? Ask-nya eksplisit (siapa harus melakukan apa)? Panjangnya bisa dipotong lagi?

#Budaya RFC yang Sehat

RFC (Request for Comments) adalah infrastruktur komunikasi organisasi asynchronous — dan kalian, sebagai staff engineer, adalah penjaga mutunya. Elemen budaya yang sehat:

1. Template ringkas — problem, proposal, opsi alternatif, dampak, ask (fondasi episode 4). Template panjang = RFC kosong formalitas.
2. Jendela komentar tertentu (misal 5 hari kerja) — deadline menciptakan kepastian; tanpa itu diskusi menggantung.
3. Status publik — proposed → in-review → accepted/superseded; siapa pun bisa melihat nasib usulan apa pun.
4. Keputusan tertulis meski verbal — rapat boleh memutuskan, tapi hasilnya ditulis balik ke RFC; memori rapat busuk dalam seminggu.

Peran spesifik kalian: menjadi contoh RFC berkualitas tinggi dan reviewer yang menegakkan standar komentar (bloker vs saran, episode 9) — termasuk pada diri sendiri.

#Presentasi yang Mengubah Keputusan

Rapat dan demo tetap diperlukan — tapi desainlah untuk keputusan:

• Buka dengan ask — "di akhir sesi ini saya butuh keputusan X atau arahan Y". Ruangan langsung tahu tujuannya.
• Slide = titik pijakan, bukan naskah — angka besar, diagram, tabel trade-off; narasi hidup di mulut kalian.
• Antisipasi tiga keberatan teratas — bawa jawabannya secara proaktif; keberatan yang dijawab duluan membuat ruangan maju.
• Tutup dengan rekapan keputusan — ulangi apa yang diputuskan, siapa mengerjakan apa, kapan; lalu tulis di kanal resmi hari itu juga.

Untuk demo teknis: tunjukkan jalur bahagia maksimal dua menit, lalu langsung ke bagian menarik — failure mode, recovery, atau angka performa. Audiens engineer percaya pada yang berani menunjukkan retaknya.

#Memulai Technical Blog yang Bertahan

Blog internal maupun publik adalah pengganda karir (argumennya di episode 22). Yang membedakan blog yang hidup vs mati bukan bakat — melainkan sistem:

1. Inbox ide permanen — catat setiap masalah yang kalian debug lebih dari satu jam, keputusan yang diperdebatkan, tooling yang menyelamatkan waktu. Ide berasal dari kerja nyata, bukan dari kosong.
2. Format pendek dulu — post 800 kata yang terbit mengalahkan esai 3000 kata yang abadi di draft. Ritme mingguan/bulanan yang konsisten menang atas ledakan lalu hilang.
3. Struktur post teknik yang terbukti: masalah nyata (dengan gejala) → investigasi (termasuk jalan buntu!) → akar masalah → solusi → pelajaran umum. Jalan buntu adalah bagian paling bernilai — ia yang tak ada di dokumentasi resmi mana pun.
4. Review sebelum publish internal — untuk post publik, cek aturan disclosure organisasi; untuk data produksi, anonimkan angka sensitif.
5. Ukur yang penting — bukan page view, melainkan: apakah ada orang lain yang mengutip/menyelesaikan masalah serupa karena tulisan kalian?

Contoh backlog ide dari pekerjaan sebulan:

- Debug retry storm saat failover MQ (4 jam investigasi,
  temuan: idempotency key salah scope) -> layak tulis.
- Kenapa kami pilih NATS over Kafka (debat 3 RFC) ->
  tulis SETELAH 6 bulan data pemakaian.
- Script provisioning hari-1 onboarding -> template post.
- [jangan]: opini tren framework baru tanpa pengalaman pakai.

Perhatikan item ketiga: aturan mainnya tulis dari pengalaman yang sudah dibayar mahal, bukan opini gratis. Itu filter yang menjaga mutu dan melindungi kredibilitas.

#Pitfall Umum Komunikasi Staff Engineer

• Tulisan panjang sebagai ganti berpikir — dokumen 12 halaman sering menandakan argumen belum selesai dipadatkan; potong sampai tersisa inti yang bisa dipertanggungjawabkan.
• Jargon sebagai zirah — istilah rumit yang menyembunyikan klaim tipis; jika tak bisa dijelaskan sederhana, pemahamannya belum utuh.
• Komunikasi one-way — mengumumkan tanpa jalur tanggapan menghasilkan kepatuhan permukaan; sediakan dan jawab pertanyaan secara publik.
• Menulis hanya saat diminta — staff engineer yang baik mendokumentasikan keputusan proaktif; yang bereaktif dikenal sebagai sumber dokumen saat audit saja.
• Menghindari menulis karena "bukan penulis" — tulisan adalah craft engineering seperti lainnya: sistem, latihan, feedback loop. Mulai jelek, membaik konsisten.

#Penutup

Inti yang dibawa pulang:

• Tulis untuk keputusan: satu dokumen satu pertanyaan, BLUF, dan struktur yang lolos uji lima-menit.
• Proses tiga fase — kerangka, draf jelek, penyuntingan keras — memutus belenggu sempurna-paragraf-pertama.
• Budaya RFC sehat: template ringkas, jendela komentar, status publik, dan keputusan yang selalu ditulis balik.
• Presentasi dirancang untuk keputusan; blog bertahan lewat inbox ide dari kerja nyata dan format yang terbit konsisten.

Di episode 26 kita masuk fase terakhir dengan membahas ekosistem & tren modern 2026 — posisi IC track di pasar kerja, kenapa kombinasi AI & platform experience paling dicari, dinamika kompensasi staff-plus, dan cara menyeimbangkan jalur staff vs manager. Sampai jumpa di episode 26!