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)

[shakespeares]

Bekerja bersama memang benar.
Kalau orang itu tidak ada (meninggal, sakit, cuti), apa Anda tidak menanggapi klien?

[carnoxen]

Saya bekerja di perusahaan yang sangat kecil sampai-sampai satu-satunya karyawan hanyalah saya. Jadi saya menangani maintenance sendiri dan mengembangkan sendiri.... Karena sudah terlalu lama seperti ini, saya juga merasa ingin bekerja bersama orang lain. Bekerja sendirian terlalu sepi...

[jjpark78]

Tulisan ini terasa terlalu provokatif.
Mungkinkah penulisnya terlalu menonjolkan kepribadian dirinya sehingga tidak bisa berbaur dengan baik dengan orang lain?

Untuk membuat satu fitur,
biasanya peran seperti desainer, perencana, manajer proyek, frontend, backend, QA, dan lain-lain memang pasti dibutuhkan.

[coremaker]

Tampaknya ia membuat klaim yang berlebihan untuk menonjolkan masalah yang ia rasakan.
Kolaborasi tentu bukan berarti dilakukan dengan cara seperti agora.

Namun, dua hal ini memang jelas bermasalah: terlalu sering melontarkan ‘let’s discuss’ dan menghindari tanggung jawab.
Tetapi dalam banyak kasus, itu terjadi karena memang tidak ada pemimpin atau penanggung jawab yang punya insight.

Untuk hal seperti inilah orang melakukan riset, mengembangkan orang, merekrut, atau membeli solusi.
Kalau tim hanya dibentuk dari anggota yang penurut, itu juga bisa makin memicu masalah tersebut.
Menurut saya, ini tampaknya bukan masalah yang disebabkan oleh kolaborasi atau bekerja sendirian.

[xguru]

Harap diingat bahwa Posthog memang selalu menulis artikel dengan pilihan kata yang kuat seperti ini.
Karena nadanya terlalu keras, kadang ada tulisan yang terasa sedikit melenceng dari topiknya.
(Air berkarbonasi itu enak sekali!!!)

[t7vonn]

Air berkarbonasi itu bukannya landasan peluncur highball ya? ahem

[GN⁺]

Komentar Hacker News

• Ada saran bahwa setiap kali kolaborasi terjadi, bilang saja, “Kebanyakan orang, X adalah driver-nya jadi biarkan dia yang memutuskan”
  Tapi kalau manajer bilang “kamu saja yang putuskan” lalu tidak datang ke rapat, dan belakangan berkata “kalau saya yang mengerjakan hasilnya akan beda” sambil meminta revisi, karyawan jadi memilih pergi

  • Salah satu alasan saya meninggalkan Apple adalah hal seperti ini
    Manajer dari manajer saya selalu bicara seperti itu, tapi begitu saya mengajukan PR, ujung-ujungnya dia meminta redesign total
    Akhirnya saya jadi takut pada pekerjaan itu sendiri, karena tahu proyek apa pun pada akhirnya harus ditulis ulang dari nol
  • Ada akibat yang lebih buruk juga
    Kalau atasan terlalu sering membalikkan keputusan, anggota tim sengaja akan melempar semua keputusan ke atasan
    Pada akhirnya atasan akan mati lemas oleh hasrat untuk mengontrol dirinya sendiri
  • Saran ini tampaknya bertentangan dengan prinsip “beri umpan balik setelah rilis”
    Tapi dalam konteks “manajer jangan mengarahkan secara detail”, ini tetap konsisten
  • Di tempat kerja lama, ungkapan “what about…” menjadi kata pemicu
    Karena setelah itu biasanya datang penyesuaian piksel tanpa akhir, revisi layout, dan usulan rework seluruh stack
  • Menanggapi ucapan “cara yang bagus untuk kehilangan karyawan”, ada yang bercanda menjawab, “cara yang bagus, ya? harus saya catat”

• Menurut saya inti masalahnya bukan kolaborasi, melainkan struktur pengambilan keputusan
  Umpan balik adalah kesempatan untuk belajar, tetapi jika tidak jelas siapa yang membuat keputusan akhir, laju kerja akan melambat
  Untuk keputusan yang cepat, pengambil keputusan harus jelas, dan kita perlu menyadari bahwa sebagian besar keputusan bisa dibalik

  • Ini wawasan utamanya
    Kalau kolaborasi berkurang, kesempatan belajar juga ikut berkurang
    Pengambil keputusan harus ditetapkan dengan jelas, tetapi tetap harus mendengarkan umpan balik
    Selain itu, keputusan yang bisa dibalik sebaiknya diambil dengan cepat
    Orang bilang kolaborasi memperlambat kerja, padahal sebenarnya proses itu meningkatkan kualitas
  • Kalau umpan balik diberikan dengan niat baik, itu bagus, tetapi di beberapa perusahaan umpan balik berubah menjadi permainan kekuasaan
    Sebagian orang menentang hanya demi menentang, dan akhirnya mencoba merebut kepemilikan atas ide
  • Jika orang nonteknis memegang keputusan akhir, makin banyak rapat justru makin mengarah ke “desain ala komite”
    Bahkan jika pengambil keputusan akhir sudah jelas, kalau pendiriannya lemah hasilnya tetap mengalir ke konsensus mayoritas
  • Saya juga pernah punya rekan yang membajak review PR demi selera pribadinya
    Begitu dia memberi “request changes”, semua orang harus mengikutinya, dan akhirnya kualitas kode malah menurun
    Menurut saya jauh lebih baik merekrut orang yang bagus lalu mendelegasikan wewenang keputusan
  • Pemimpin yang baik bukanlah orang yang memutuskan semuanya sendiri, melainkan orang yang menambah jumlah keputusan yang bisa diambil secara mandiri
    Dia harus memberi arah, prioritas, dan framework agar tim bisa menilai sendiri

• Saya tidak setuju dengan kebencian terhadap air soda dari penulisnya, tapi senang isu kolaborasi dibahas secara terbuka
  Di beberapa perusahaan, saya pernah menghabiskan waktu 3 kali lebih lama di code review karena komentar gaya yang remeh daripada untuk implementasi yang sebenarnya
  Posisi saya adalah, “kalau memang tidak suka, perbaiki sendiri lalu beri tahu saya”
  Dia juga membagikan video terkait

  • Kalau formatter dimasukkan ke build pipeline, masalah gaya akan selesai otomatis
    Sudah terlalu terlambat kalau baru dibahas saat tahap code review
  • Sebagian besar perusahaan memakai formatter otomatis, jadi masalah seperti ini biasanya ada di level penamaan atau struktur kode
    Yang jadi masalah adalah orang yang tidak menyesuaikan diri dengan gaya kode di sekitarnya
  • Mencari-cari kesalahan kecil di PR bukanlah kolaborasi
    Itu harus diselesaikan dengan linter atau budaya tim
  • Soal “mana komentar yang remeh dan mana yang penting untuk menjaga kebersihan kode” pada akhirnya memang harus ditentukan oleh tim
  • Fitur bukan aset, melainkan utang
    Fitur yang dibuat sendirian tanpa kolaborasi menjadi risiko besar saat pemeliharaan
    Jika sistem meledak ketika saya tidak ada, itu menunjukkan bahwa absennya kolaborasi memang masalahnya

• Penulis menekankan bias untuk bertindak, tetapi jika kolaborasi disingkirkan akan muncul silo dan rasa terlalu percaya diri
  Budaya Slack seperti “Saya mau melakukan X, ada keberatan kuat?” terbukti efektif

  • Kekuatan pendekatan ini ada pada cara framing-nya sehingga orang bisa menjawab “ya/tidak”
    Karena itu, pekerjaan benar-benar bergerak maju

• Dulu saya pernah mewawancarai tim-tim saat menulis buku terkait GitHub, dan beberapa tim mengunggah PR kosong sebelum mulai menulis kode untuk mendapatkan persetujuan desain
  Itu bukan kolaborasi saat pengerjaan berlangsung, melainkan kolaborasi pada tahap perencanaan
  Kalau ada tulisan dan komunikasi yang baik, kolaborasi bisa cepat dan efektif
  Di era AI, kemampuan seperti ini akan jadi makin penting

  • Makin bertambah usia, saya sadar bahwa visibilitas lebih penting daripada hasil semata
    Kalau tidak ada rapat dan tidak ada berbagi informasi, kontribusi kita tidak terlihat
    Jika kita mencegah masalah, tidak ada yang tahu, sehingga ada juga budaya yang sengaja “membiarkan masalah terjadi”
  • Tim kami juga mengadakan rapat lebih dulu untuk perubahan penting, dan berkat itu pemborosan waktu berkurang drastis
  • Sebenarnya cara seperti ini mirip dengan asal-usul SCRUM
  • Tapi saya tipe orang yang baru bisa melihat strukturnya setelah benar-benar menulis kode
    Sulit membayangkan implementasi hanya dari perencanaan
  • Pada akhirnya itu tidak jauh berbeda dari dokumen desain

• Seperti kalimat terakhir di tulisan itu, “kolaborasi yang baik itu memang ada”
  Judulnya clickbait, tetapi PostHog memang dikenal dengan gaya seperti ini

  • Bahkan ada yang bercanda bahwa clickbait itu sendiri adalah hasil dari driver pemberani yang menulisnya dengan cepat
  • Mengemas ulang konsep yang sudah akrab dengan cara baru itu berguna
    Itu membuat orang melihat meme “kolaborasi” dengan lebih kritis
  • Inti masalahnya adalah desain ala komite

• Tulisan ini adalah eksperimen pemikiran yang keliru
  Masalahnya bukan kolaborasi, melainkan ketiadaan wewenang pengambilan keputusan
  Harus ada satu orang yang membuat keputusan dengan jelas, dan makin jauh wewenang itu didorong ke bawah, makin cepat geraknya

  • Setuju. Tanpa pengambil keputusan, semuanya berhenti
    Tulisan seperti ini punya racun berupa memelintir bahasa hingga membuat konsep yang dibutuhkan jadi tak bernilai
  • Tapi ini bukan cuma soal keputusan
    Budaya yang langsung berkata “tanya Bob saja” setiap kali seseorang buntu juga bermasalah
    Dalam jangka pendek memang cepat, tetapi dalam jangka panjang menyebabkan hilangnya kesempatan belajar dan kelebihan beban kerja

• Saya suka ketika rekan kerja tertarik pada pekerjaan saya
  “Terserah kamu saja” pada dasarnya berarti “saya tidak peduli”
  Masalahnya bukan kolaborasi, melainkan kolaborasi yang tidak efisien

  • Tulisannya memang sengaja dibuat sebagai hot take, tetapi rapat dengan lebih dari 3~4 orang hampir selalu buang waktu
    PR punya hasil konkret sehingga diskusinya jadi lebih jelas

• Saya merasa kolaborasi paling efektif saat melibatkan dua orang
  Dua orang bisa memahami codebase bersama dan saling mereview PR
  Tapi begitu jadi tiga orang atau lebih, kompleksitas kombinatorial meledak
  Karena itu saya ingin merancang proyek dengan struktur tim beranggotakan 2 orang

  • Ini pada dasarnya adalah konsep Amazon Two-Pizza Team
    tautan referensi

• Seperti analogi di tulisan itu, balap F1 adalah olahraga yang sangat kolaboratif dalam bentuk yang ekstrem
  Pembalap terus berkomunikasi dengan pelatih sepanjang balapan
  Saya penasaran apakah ada contoh seperti ini di software

  • Pair programming adalah contohnya
  • Atau tim lintas fungsi
  • Atau GitHub Copilot

[slowandsnow]

Komentar-komentarnya aneh. Kalau melihat ringkasan tulisannya, maksudnya bukan bekerja sendirian atau tidak membutuhkan anggota tim, melainkan mengurangi kolaborasi yang berlebihan di antara anggota tim.

[t7vonn]

Saya setuju.

[guarder]

Sepertinya ini hasil gabungan antara judul yang sengaja memancing perhatian dan pembaca yang tidak membacanya dengan saksama.

[ndrgrd]

Bukan cuma tulisan seperti ini, bahkan di YouTube pun banyak orang yang berkomentar hanya setelah melihat judulnya saja.

[joone]

Saat memulai sesuatu yang baru, demi bermain terlalu aman, kita bisa jadi berlebihan meminta review dari orang-orang sekitar. Padahal, orang atau tim di sekitar belum tentu benar-benar memahami topik tersebut sehingga sulit juga memberi umpan balik yang bagus. Pada akhirnya, sepertinya maksudnya adalah lebih hemat waktu jika kita terlebih dahulu membuat sesuatu, lalu meskipun arahnya mungkin salah, setelah itu menerima umpan balik yang konkret dan mengerjakannya kembali.