Kolaborasi Itu Tidak Berguna

• Pepatah “kalau pergi sendiri lebih cepat, kalau bersama bisa lebih jauh” bisa menghancurkan startup
• Kolaborasi yang efisien seharusnya hanya sebatas bantuan navigasi saat mengemudi, tetapi kebanyakan perusahaan justru mengalami perlambatan karena terlalu banyak umpan balik dan pembagian peran
• Di bawah nilai “Andalah pengemudinya (You're the Driver)”, PostHog menekankan otonomi dan rasa kepemilikan yang tinggi serta meminimalkan kolaborasi yang tidak perlu
• Penyebab kolaborasi berlebihan dianalisis sebagai keinginan untuk membantu, budaya yang terlalu inklusif, permintaan umpan balik yang tidak jelas, kebiasaan berlebihan mengatakan ‘let’s discuss’, dan penghindaran tanggung jawab
• Solusinya adalah pendekatan praktis berupa memprioritaskan rilis segera, memperjelas penanggung jawab, meminta umpan balik hanya dari orang yang diperlukan, memberi umpan balik setelah peluncuran, dan segera menghentikan kolaborasi yang tidak perlu

---

Jebakan kolaborasi

• Ungkapan "kalau ingin cepat, pergi sendiri; kalau ingin jauh, pergi bersama" perlahan membunuh perusahaan
  • Ini adalah jebakan yang membenarkan kolaborasi berlebihan
  • Kolaborasi yang berguna hanya sebatas panduan arah saat berkendara atau pemberian informasi sekitar
• Namun sebagian besar organisasi justru terjebak dalam kolaborasi tidak efisien seperti bergantian memegang setir
• Umpan balik yang tepat membantu kita mencapai tujuan lebih cepat, tetapi umpan balik berlebihan memperlambat laju dan meningkatkan risiko tidak pernah sampai ke tempat yang dituju

Paradoks umpan balik: pandai memberi umpan balik berarti tahu kapan tidak perlu memberikannya

• Seiring pertumbuhan PostHog, kolaborasi yang tidak menambah nilai atau nilainya terlalu kecil dibanding waktu yang dihabiskan juga meningkat
  • Dalam rapat seluruh perusahaan baru-baru ini, topik yang dibahas adalah "kolaborasi itu buruk"
• "Andalah pengemudinya (You're the driver)" adalah nilai inti PostHog: "mempekerjakan orang hebat dan tidak menghalangi mereka"
  • Tidak ada tenggat waktu, koordinasi seminimal mungkin, dan manajer tidak memberi perintah
• Sebagai gantinya, dibutuhkan rasa kepemilikan yang sangat tinggi dan kemampuan menyelesaikan banyak hal sendirian
  • Marketer melakukan deploy kode, staf sales menjawab pertanyaan teknis tanpa cadangan, dan product engineer bekerja di seluruh stack
• Hampir selalu ada orang yang lebih ahli daripada Anda, jadi godaan untuk berkolaborasi itu kuat, tetapi kolaborasi memaksa pengemudi melambat dan menjelaskan latar belakang, konteks, serta alur pikirnya
• Kecenderungan ini muncul lewat beberapa ungkapan utama
  • "Saya penasaran bagaimana pendapat X"
  • "Saya ingin mendengar pendapat Y"
  • "Kita harus mengerjakannya bersama Z"
• Ini kadang menghasilkan wawasan yang berharga, tetapi selalu memperlambat pengemudi
• Hal itu mengikis motivasi, kepercayaan diri, dan efisiensi pengemudi, lalu pada akhirnya menurunkan jumlah rilis

Jika kolaborasi itu buruk, mengapa orang tetap melakukannya

• Semua orang ikut menyumbang penyebabnya
• Orang ingin membantu: ketika seseorang mem-posting pekerjaan yang sedang berjalan di Slack, budaya umpan balik membuat orang lain merasa mereka harus memberi masukan
• Sebaliknya, mereka juga merasa meminta umpan balik dari orang tertentu itu kurang inklusif, sehingga tidak melakukannya meskipun sebenarnya akan lebih membantu
• Mereka tidak cukup spesifik soal jenis umpan balik yang dibutuhkan: ini membuka ruang bagi kolaborasi untuk menyusup. Diskusi tentang membangun fitur tertentu bisa meluas menjadi evaluasi ulang seluruh roadmap produk
• Saat seseorang mengajukan ide bagus, reaksi default bukan "kerjakan itu", melainkan "ayo kita diskusikan"
  • Buktinya, frasa "let's discuss" dipakai tanpa henti di Slack
  • Ini menggeser fokus dari eksekusi ke diskusi
• Orang terlalu sibuk untuk mengeksekusi, atau malas, sehingga mereka hanya ingin membicarakannya
  • PR → issue/RFC → Slack (sekarang sebagian besar berhenti di sini) → "ayo kita diskusikan"
• Tidak jelas siapa pemiliknya (atau tidak ada yang benar-benar ingin memiliki hal yang sedang dibahas)
• Memang menjengkelkan, tetapi kadang satu orang memang tidak bisa shipping dari awal sampai akhir dengan kualitas yang cukup tinggi, dan tidak selalu bisa sekadar shipping lalu mengiterasi
  • Kode yang rusak bisa diperbaiki, tetapi newsletter tidak bisa dikirim ulang

Cara menghancurkan kolaborasi (dan melaju lebih cepat serta lebih jauh)

• Jika kolaborasi dianggap musuh, bagaimana cara mengalahkannya
• Default-nya adalah eksekusi lebih dulu: Pull request > Issue > pesan Slack
• Saat kolaborasi mulai berlebihan, tarik batas dengan jelas: “kamu pengemudinya, putuskan sendiri”
• Untuk umpan balik, tag orang tertentu dan jelaskan secara spesifik apa yang Anda butuhkan, jangan melemparnya begitu saja secara samar
• Dibanding review sebelum rilis, mereka lebih memilih memberi umpan balik setelah rilis (sebelum iterasi berikutnya): umpan balik di awal bisa berubah menjadi proses persetujuan semu
• Pemimpin harus menahan diri untuk tidak terlalu banyak memberi umpan balik dan mempertahankan sikap ‘langsung saja dikerjakan (you can just do stuff)’
• Setiap orang adalah ‘kapten yang terinformasi (informed captain)’
  • Mereka boleh mendengarkan umpan balik, tetapi keputusan tetap mereka ambil sendiri

Kesimpulan

• Tidak semua kolaborasi bisa dicabut sampai ke akar, dan sebagian memang berguna (newsletter ini diedit oleh Ian dan Andy)
• Namun secara default perlu ada upaya untuk mengurangi kolaborasi
• Jika Anda tidak secara aktif mencoba menguranginya, besar kemungkinan Anda sebenarnya sudah terlalu banyak berkolaborasi
• Karena kolaborasi pada dasarnya memperlambat laju,
  semakin sedikit berkolaborasi, semakin jauh dan semakin cepat Anda bisa melaju

• Ditulis oleh Charles Cook, yang membenci air berkarbonasi karena (gelembung itu terlalu kolaboratif)