Belajar Staff Engineer - Cross-Team Collaboration

#Pendahuluan

Setelah di episode 4 kita menguasai architecture ownership — trade-off, ADR, dan review arsitektur — pada episode ini kita hadapi kenyataan sosial dari semua keputusan itu: cross-team collaboration. Arsitektur sebagus apa pun akan gagal jika tim-tim pelaksananya tidak selaras. Di level staff, sebagian besar proyek gagal bukan karena teknologi, melainkan karena dependency yang tidak dikelola dan asumsi yang tidak pernah diselaraskan.

Kita bedahkan cara memetakan dependency, merancang kontrak antar tim, menetapkan cadence komunikasi, lalu menyusun alignment plan untuk satu inisiatif nyata.

#Mengapa Kerja Lintas Tim Berat

Empat penyebab utama — kenali agar bisa dicegah:

1. Incentive mismatch — tiap tim dinilai atas targetnya sendiri; pekerjaan untuk inisiatif bersama adalah "hambatan" bagi target mereka.
2. Dependency tersembunyi — tim A baru tahu butuh API dari tim B saat integration test, dua minggu sebelum deadline.
3. Komunikasi berubah mahal — biaya koordinasi naik kuadratik seiring jumlah tim (n tim punya n×(n−1)/2 jalur komunikasi).
4. Kepemilikan kabur — tidak jelas siapa memutuskan apa; keputusan kecil pun butuh rapat panjang.

Staff engineer tidak menghilangkan kompleksitas ini — mustahil — tetapi membuatnya terkelola dan terlihat.

#Memetakan Dependency Antar Tim

Langkah pertama alignment: gambar peta ketergantungan secara eksplisit. Jangan andalkan ingatan kolektif.

Dari peta seperti ini, baca tiga sinyal:

• Bottleneck — service yang ditunggu banyak tim (di atas: Payments Gateway) harus diprioritaskan dan dijaga jadwalnya.
• Rantai kritis — urutan dependency terpanjang menentukan waktu minimum inisiatif; optimalkan di situ.
• Siklus — dependency bolak-balik (A butuh B, B butuh A) adalah desain buruk yang wajib diputus sebelum eksekusi.

Simpan petanya di ~/staff-lab/initiatives/nama-inisiatif/dependency-map.md — ia akan sering kalian tunjuk saat menjelaskan risiko ke manajemen.

#Kontrak Interface Antar Tim

Dependency yang paling aman adalah yang dikontrak. Kontrak bisa berupa API spec, skema event, atau SLA layanan internal. Prinsip-prinsipnya:

• Definisikan sebelum dibangun — kontrak v0 (endpoint, payload, error case) disetujui kedua tim sebelum implementasi paralel dimulai.
• Versioning sejak awal — /v1/... hari pertama; breaking change = versi baru + masa deprekasi, bukan perubahan diam-diam.
• Consumer-driven contract test — tim pemakai menyumbang test yang mendefinisikan perilaku yang mereka andalkan; pelanggaran kontrak tertangkap di CI, bukan produksi.
• Mock-first — sediakan stub/mock agar tim pemakai tak terblokir menunggu implementasi selesai.

#Cadence Komunikasi dan RACI

Alignment butuh ritme, bukan rapat dadakan. Format minimal untuk inisiatif lintas tim:

Untuk kejelasan kepemilikan, pakai RACI ringkas:

Keputusan / Deliverable          Responsible   Accountable   Consulted     Informed
Desain Payments Gateway          Tim Payments  Staff (saya)  Tim Fraud     Semua tim
Skema event order                Tim Cart      Tim Cart      Tim Fraud     Analytics
Jadwal cutover                   PM Program    VP Eng        Semua lead    Org

Aturan emas: satu Accountable per baris. Dua accountable sama artinya dengan nol.

#Praktik: Menyusun Alignment Plan

Sekarang rangkai menjadi dokumen kerja. Buat initiatives/checkout/alignment.md:

# Alignment Plan: Migrasi Checkout Baru
 
## Tujuan Bersama (satu kalimat, disetujui semua lead)
Checkout baru menurunkan drop-off 15% tanpa menaikkan latensi p95.
 
## Tim & Kepentingan
- Cart: ingin migrasi cepat (target Q4 revenue).
- Identity: khawatir beban session service (baru stabil).
- Fraud: butuh akses sinyal sebelum payment authorization.
 
## Dependency & Mitigasi
1. Session service scale-up -> load test minggu-1, kapasitas +40%.
2. Skema event fraud -> dikontrak v0 minggu-1, mock tersedia.
3. Payments Gateway rollout bertahap -> flag per merchant cohort.
 
## Keputusan Terbuka (pemilik + deadline)
- Retensi log audit: Tim Payments, 22 Agustus.
- Strategi rollback: Staff (saya), 25 Agustus.
 
## Ritme Komunikasi
Status tulisan tiap Senin; sync dua pekanan 30 menit;
escalation path: staff engineer -> lead terkait -> VP Eng.

Perhatikan bagian Kepentingan: alignment plan yang hanya memuat jadwal adalah gantt chart biasa. Nilainya ada pada pengakuan jujur bahwa tiap tim punya insentif berbeda — dan mitigasi yang menghormati keduanya.

#Pitfall Umum Kolaborasi Lintas Tim

• Alignment sekali lalu lupa — rencana yang tidak direvisi tiap dua minggu cepat basi; perlakukan sebagai dokumen hidup.
• Escalation dianggap kekalahan — eskalasi tepat waktu itu profesional; yang merusak adalah eskalasi mendadak tanpa konteks.
• Semua diundang ke semua rapat — undang pengambil keputusan; sisanya cukup status tulisan.
• Kontras target disembunyikan — jika target tim A bertabrakan dengan inisiatif, bawa ke sponsor program lebih awal; jangan tunggu deadline bentrok.

#Penutup

Inti yang harus dibawa pulang:

• Kegagalan lintas tim umumnya soal incentive mismatch, dependency tersembunyi, biaya komunikasi, dan kepemilikan kabur — kelola semuanya secara eksplisit.
• Petakan dependency; cari bottleneck, rantai kritis, dan siklus sebelum eksekusi.
• Kontrak interface (API/event/SLA) dengan versioning dan consumer-driven tests membuat dependency aman.
• Alignment plan hidup: tujuan bersama, kepentingan jujur, mitigasi, keputusan terbuka dengan pemilik, dan ritme komunikasi.

Di episode 6 selanjutnya kita akan membahas technical strategy — cara menulis strategi teknis dan roadmap area yang benar-benar mengarahkan prioritas organisasi, bukan sekadar daftar keinginan. Sampai jumpa di episode 6!