- Seperti penelitian yang menyebut bahwa selama Perang Dunia II hanya 15~20% prajurit yang benar-benar menembak, sebagian besar hasil nyata dalam organisasi sebenarnya dihasilkan oleh segelintir orang
- Industri teknologi mengajukan "kolaborasi" sebagai solusi untuk masalah ini, tetapi pada praktiknya yang bertambah hanya alat koordinasi kerja sementara output hampir tidak muncul, dan struktur ini pun mengakar
- Semakin besar kelompok, biaya komunikasi dan biaya koordinasi meledak, dan fenomena difusi tanggung jawab di mana rapat melahirkan rapat terus berulang
- Transparansi dikacaukan dengan kemajuan, dan visibilitas dikacaukan dengan akuntabilitas, sehingga budaya kolaborasi berfungsi sebagai mekanisme yang mengencerkan tanggung jawab individu
- Pekerjaan yang benar-benar kompleks dan berkualitas tinggi pada umumnya dikerjakan oleh individu atau kelompok kecil dengan wewenang dan tanggung jawab yang jelas, sementara kolaborasi hanya berfungsi sebagai bahasa untuk membungkusnya
- Yang benar-benar dibutuhkan bukanlah infrastruktur kolaborasi, melainkan penilaian mandiri dan tanggung jawab pribadi (ownership), dan organisasi perlu beralih ke arah yang mempercayai hal itu
Ilusi yang Disebut Kolaborasi
- Kolaborasi (collaboration) sering dianggap sebagai simbol produktivitas dalam organisasi modern, padahal dalam kenyataannya ia bekerja sebagai struktur penghindaran tanggung jawab dan inefisiensi
- Menurut penelitian S.L.A. Marshall pada Perang Dunia II, hanya 15~20% prajurit yang benar-benar melepaskan tembakan dalam pertempuran
- Mirip dengan pola yang ditemukan IBM pada 1960-an bahwa “80% penggunaan berasal dari 20% fitur”, segelintir anggota menghasilkan sebagian besar hasil
- Sisanya hanya memberi “dukungan struktural (structural support)”, dan ketimpangan upaya dalam organisasi terus berulang
- Untuk menyelesaikan masalah ini, industri teknologi kemudian mengikuti konsep ‘kolaborasi’ nyaris seperti sebuah keyakinan
- Banyak alat kolaborasi seperti Notion, ClickUp, Slack, Jira, Monday, Teams bermunculan, tetapi yang meningkat adalah activity ketimbang output
- Transparansi dan visibilitas disalahartikan sebagai kemajuan atau tanggung jawab, dan “termasuk dalam thread” disamakan dengan “memiliki hasilnya”
- Akibatnya, kolaborasi berubah menjadi simulasi partisipasi alih-alih hasil nyata
- Difusi tanggung jawab (diffusion of responsibility) adalah fenomena yang sudah lama diamati
- Pada 1913, efek Ringelmann menunjukkan bahwa semakin besar ukuran kelompok, semakin menurun proporsi usaha individu
- Melalui kasus IBM System/360 pada 1975, Frederick Brooks merumuskan hukum bahwa menambah orang ke proyek yang terlambat justru membuatnya makin terlambat
- Semakin banyak orang, biaya komunikasi dan biaya koordinasi meningkat secara eksponensial, memunculkan lingkaran setan rapat yang melahirkan rapat
- Industri kolaborasi telah menggelontorkan sumber daya besar untuk menutupi masalah struktural ini, tetapi pekerjaan berkualitas tinggi yang sesungguhnya tetap dikerjakan oleh segelintir individu atau tim kecil
- Dostoevsky menulis The Brothers Karamazov sendirian, dan Apollo Guidance Computer dikembangkan oleh tim kecil MIT di bawah sistem tanggung jawab yang jelas
- Pencapaian sejati lahir dari wewenang yang jelas dan tanggung jawab pribadi, sementara kolaborasi hanya berfungsi sebagai bahasa untuk membungkus hasil tersebut
- Sebaliknya, organisasi modern hanya membangun infrastruktur kolaborasi yang rumit untuk social management, sementara pekerjaan nyata terdorong ke belakang
- Kepemilikan nyata (ownership) ada ketika individu mengambil keputusan sendiri dan menanggung akibatnya
- Namun, dalam lingkungan di mana kolaborasi telah menjadi norma budaya, keputusan sepihak dianggap sebagai tindakan yang tidak kooperatif
- Ideologi kolaborasi membuat tanggung jawab dan inisiatif terasa seperti tindakan antisosial, dan ini melemahkan mekanisme inti produksi
- Rapat, dokumen, retrospective, kickoff, dan sejenisnya terus berulang tanpa akhir, tetapi yang tersisa hanya “kelebihan koordinasi” yang tidak terhubung ke eksekusi nyata
Perlunya Kembali ke Tanggung Jawab Individu
- Sebagian besar proyek telah berubah menjadi struktur waktu koordinasi > waktu eksekusi, dan ketika gagal, solusinya selalu berujung pada “lebih banyak kolaborasi”
- Namun pertanyaan yang sebenarnya adalah, “apa yang sebenarnya sedang kita bangun, dan siapa yang bertanggung jawab atas itu?”
- Untuk pekerjaan apa pun, harus ada satu penanggung jawab akhir, meskipun struktur kolaboratif menyamarkan keberadaannya
- Diperlukan pemulihan kepercayaan pada individu
- Tidak semua tanggung jawab harus diawasi oleh seluruh organisasi
- Alih-alih manajemen berlebihan dan budaya yang berpusat pada metrik, individu perlu mengelola pekerjaannya sendiri dan dinilai berdasarkan hasil
- Saat gagal, dibutuhkan struktur yang secara jelas mengaitkan tanggung jawab itu kepada individu
- Kita perlu meninggalkan ilusi upaya kolektif dan kembali ke lingkungan yang dapat mengidentifikasi siapa yang benar-benar bertindak
- Kembali ke struktur sederhana di mana setiap orang mengelola tugasnya sendiri dan dinilai dari hasilnya
- Ketika kita melepaskan fiksi hangat namun mahal bernama “kolaborasi”, kita bisa melihat dengan jelas siapa yang benar-benar menarik pelatuk
20 komentar
Ini tampaknya seperti tulisan panjang yang pada dasarnya cuma menyatakan, "Saya tidak bisa berkolaborasi." Memang bukan berarti dalam organisasi besar konsep kolaborasi tidak pernah menjadi penghambat, tetapi bahkan itu pun merupakan fenomena yang muncul karena kolaborasinya tidak berjalan dengan baik, bukan masalah pada kolaborasi itu sendiri.
Sepertinya kepribadian penulisnya memang agak kurang baik.
Wkwkwkwkwkwkwkwk aduh saya sampai ngakak pecah wkwkwk
"Selama Perang Dunia II, hanya 15~20% prajurit yang benar-benar melepaskan tembakan"
Sejumlah studi lanjutan dan makalah yang secara langsung membantah serta menganalisis klaim Marshall tentang "tingkat penembakan 15~20%" telah cukup banyak dibahas dalam bidang sejarah militer. Sejak 1980-an, berbagai sejarawan dan pakar militer menelusuri catatan penelitian Marshall, dan sampai pada kesimpulan bahwa angka tersebut pada dasarnya direkayasa atau sangat dibesar-besarkan.
Robert Engen (2010) menganalisis survei terhadap para perwira infanteri Kanada pada Perang Dunia II, beserta catatan tempur mereka, yang bertempur dalam kondisi serupa dengan militer AS. Ia menunjukkan bahwa tingkat penembakan aktual pasukan Kanada jauh lebih tinggi daripada 15~20% yang diklaim Marshall, dan membantah bahwa klaim Marshall merupakan kesalahan generalisasi serius yang tidak dapat diterapkan pada seluruh Sekutu Barat.
Karena sejak bagian pertama rasanya sudah ada yang aneh, saya cari-cari dan sepertinya ini fakta yang salah diketahui. Begitu juga dengan yang dibicarakan di komentar Hacker News di bawah.
Opini Hacker News
Dari pengalaman lebih dari 30 tahun bekerja di bidang ini, yang saya lihat adalah "tanggal deadline" selalu dianggap lebih penting daripada hasil akhirnya
Padahal pada praktiknya, memenuhi tanggal itu hampir mustahil, tetapi organisasi tetap menjadikannya satu-satunya metrik
Fakta bahwa pengembangan perangkat lunak pada dasarnya adalah aktivitas yang tidak dapat diprediksi hampir tidak pernah dipertimbangkan
Saat Agile Manifesto pertama kali muncul, sempat ada harapan, tetapi segera berubah menjadi gaya manajemen yang menuntut, "katakan dengan tepat berapa lama tiap tahap akan memakan waktu"
Sedikit terlambat masih bisa dimaafkan, tetapi kalau minta uang tambahan, Anda akan dibenci selamanya
Agile hanya berjalan baik ketika ada Product Owner yang baik yang telah mengamankan anggaran yang memadai dan wewenang pengambilan keputusan
Tim mengirimkan sebanyak yang memungkinkan dalam periode yang ada, lalu mengurangi fitur saat deadline makin dekat
Ini adalah cara yang menjamin pengiriman itu sendiri, bukan isi hasilnya
Jika tanggal memang sepenting itu, bukankah pendekatan seperti ini layak dicoba?
Semakin kecil organisasinya, semakin besar kemungkinan ada pemangku kepentingan yang nyata, tetapi di organisasi besar hasil dan karier terpisah
Saya bekerja di bidang hardware, dan saya mendefinisikan target akhir tahun saya sebagai "siap didemokan dengan kode yang saya tulis sendiri"
Katanya "butuh beberapa minggu", tetapi kenyataannya selesai dalam 30 detik
Rasanya penulis berbicara terlalu keras
Mungkin ada trauma karena pernah bekerja di tim dengan kolaborasi yang kacau
Tetapi tim yang dikelola dengan baik jelas ada, dan kelompok bisa menghasilkan capaian yang lebih besar daripada individu
Piramida, Linux kernel, dan AWS juga tidak dibuat sendirian
Semakin besar tim, semakin besar pula overhead komunikasi, dan banyak di antaranya berasal dari kebutuhan manajemen akan visibilitas
Tim yang baik berkomunikasi dengan baik secara internal, tetapi manajemen juga tetap membutuhkan tingkat visibilitas tertentu
Pada akhirnya, kombinasi tim yang baik + manajer yang baik itu wajib
Kebanyakan organisasi tidak pandai berkolaborasi, tetapi menutupi kegagalan itu dengan kata kolaborasi
Namun, klaim bahwa "hanya tim kecil yang benar-benar bekerja" terasa berlebihan
Kasus seperti pembangunan piramida lebih mirip rantai komando yang ketat daripada kolaborasi dalam arti modern
Program komputer Apollo dibuat oleh tim kecil, tetapi untuk pergi ke bulan dibutuhkan kerja sama yang jauh lebih besar
Bukti bahwa kolaborasi benar-benar efektif itu terlalu banyak
Sendirian Anda tidak bisa membuat game besar seperti Assassin’s Creed, dan lewat komite Anda tidak bisa membuat game seperti Stardew Valley
Itu adalah jenis kemampuan yang berbeda
Saya juga bisa berempati dengan pengalaman penulis
Setelah di-PHK dari startup, saya pindah ke perusahaan besar, dan pada awalnya kerja timnya nyambung sehingga hasilnya bagus
Tetapi kemudian muncul coach Agile dan mulai mendorong agendanya sendiri dengan dalih "kolaborasi"
Selama 8 bulan, yang ada hanya workshop tak berguna dan perebutan wewenang, dan akhirnya tim yang kompeten malah terseret oleh tim yang tidak berdaya
Masalahnya adalah budaya yang tidak memecat orang yang tidak kompeten
Kolaborasi yang nyata hanya mungkin ketika orang menurunkan ego, mau mendengar, dan bekerja bersama
Bekerja sendirian memang memungkinkan Anda menyelesaikan lebih banyak hal, tetapi ada risiko salah mendefinisikan masalah
Kolaborasi mencegah itu lewat beragam sudut pandang
Orang yang tidak bekerja malah mengganggu orang yang bekerja
Baru-baru ini saya membaca paper McEntire berjudul "The Organizational Physics of Multi-Agent AI" dan itu menarik
Bahkan agen AI pun mereproduksi inefisiensi politik organisasi manusia apa adanya
Pada akhirnya, jika organisasinya buruk, yang dilakukan hanya "kerja tentang kerja" (
work about work)Tim kecil yang bertanggung jawab jauh lebih menyenangkan, tetapi sulit direplikasi
Saya juga membahas tema ini di tulisan blog saya Where to Cut
Saya merasa orkestrasi hanya benar-benar berjalan ketika peran dan struktur jelas
Jika orang diganti atau tim dipindahkan, akan muncul biaya perpindahan konteks dan kohesi tim pun rusak
Saat membaca aslinya saya benar-benar tidak paham ia ingin mengatakan apa
Budaya yang tidak memberi pengakuan kepada orang yang menghasilkan kinerja merusak organisasi
20% orang yang memikul beban lebih besar itu sebenarnya hanya ingin diakui
Jika itu tidak diberikan, perusahaan akan cepat kosong
Saya tidak tertarik pada pujian dari orang yang bahkan tidak tahu apa yang saya kerjakan
Tulisan ini bisa diperluas melampaui organisasi menjadi makna sosial dari "hak cipta dan agensi"
Pekerjaan yang kompleks dan berkualitas tinggi pada akhirnya lahir dari rasa tanggung jawab yang jelas pada tim kecil atau individu
Seperti Dostoevsky atau tim komputer Apollo
Sebaliknya, utopia kolaborasi di mana "semua orang berkontribusi tetapi tidak ada yang dihargai" jauh dari kenyataan
Manusia memiliki motivasi yang lebih kuat terhadap karya kreatif yang membawa namanya sendiri
Rantai pasok yang kompleks itu sendiri adalah bentuk kolaborasi lain
Saya meragukan klaim bahwa "80% tentara tidak menembakkan senjata", jadi saya cari tahu dan ternyata itu adalah data yang sudah lama dibantah
Bahkan paper tahun 2011 juga mengatakan dasarnya lemah
Jika melihat rasio tooth-to-tail militer AS, personel tempur nyata hanya sekitar 4~10%
Jadi bisa jadi penyebabnya adalah kekacauan angka
Tetapi disebutkan bahwa tingkat PTSD juga ikut naik
Secara keseluruhan, tulisan ini terasa seperti upaya incoherent yang memaksa contoh tentara ke model pekerja kantoran
Tetapi ada kabar baik untuk penulisnya — Anda juga bisa menjadi kreator individual
Seperti Notch atau pengembang Stardew Valley
Daripada mengeluh, buat saja sesuatu sendiri
Fakta bahwa 80% tidak menembak tetap terasa menarik
Penulis sama sekali tidak mempertimbangkan desain insentif terhadap kinerja
Seperti kata Munger, "lihat insentifnya, maka Anda akan tahu hasilnya"
Yang lebih penting daripada sulitnya kolaborasi adalah membangun struktur yang memberi imbalan kepada yang berprestasi dan menghukum penumpang gratis
Itu pun tidak besar
Jika itu mungkin, kita pasti sudah hidup di utopia sekarang juga
Selain fakta bahwa dasar argumen pada baris pertama saja sudah berbeda dari kenyataan, mengaitkan persoalan menembakkan senjata dalam perang (bisa membunuh orang, tingkat pelatihan para prajurit saat perang... dan berbagai masalah lain bercampur di dalamnya) dengan masalah kolaborasi dalam pengembangan sejak awal juga terasa aneh. Apakah ini tulisan yang membuktikan bahwa pembukaan sebuah tulisan itu penting...
Melihat tanggapannya, sepertinya memang banyak orang yang benar-benar hidup dalam kesalahpahaman seperti yang tertulis di postingan ini.
Bahkan jika
1 + 1 = 1.1, seproduktif apa pun seseorang yang bekerja sendiri, ia tetap tidak bisa menghasilkan keluaran yang lebih besar daripada 1.000 orang yang tidak efisien.Karena pengembangan perangkat lunak memiliki sisi keahlian kerajinan tangan, tetapi juga memiliki sisi produk yang diproduksi di pabrik.
Segelintir orang pintar merapikannya dengan baik sehingga orang-orang bodoh pun bisa mengerti dan bisa bergerak dengan efektif. Orang-orang bodoh itu salah paham, mengira mereka sedang berkolaborasi wkwk
Memang benar kolaborasi pada umumnya gagal, tetapi semua hal hebat, termasuk lahirnya kehidupan, lahir dari kolaborasi.
Kecuali kalau kamu benar-benar jenius kelas dewa, sehebat apa pun kamu tetap tidak bisa bekerja sendirian. Bahkan kalau 80% sisanya cuma berperan sebagai pemandu sorak, selama ada di sampingmu memberi dukungan, itu tetap setara setengah porsi kerja, lalu para andalan mengerjakan porsi 2~3 orang dan begitulah perusahaan berjalan. Kalau kerja sendirian, kamu juga tidak akan merasakan diakui, dan karena kesepian, tidak akan sanggup bertahan.
Saya sangat setuju.
Terutama ketika yang terus bertambah justru aktivitas di alat kolaborasi demi visibilitas dan transparansi, bukan hasil kerjanya...
Melihat para planner yang meninggalkan segala macam catatan hanya untuk mengurangi tanggung jawab mereka sendiri, sebagai developer rasanya cuma bikin sadar akan kenyataan pahit.
Sepertinya seperti siswa SMA yang baru pertama kali menyadari kepura-puraan orang dewasa lalu mulai marah. Entah kenapa, rasanya penulisnya bakal menyukai Holden Caulfield dari The Catcher in the Rye...
Tergantung skala proyek, memang bisa saja ada satu orang yang memimpin secara aktif dan itu lebih penting daripada kontribusi seluruh tim.... tapi tergantung skalanya, mungkin juga tidak begitu.
Bukankah ini intinya..
Itu hukum dua pizza.
Kolaborasi itu tidak berguna
Rasanya seperti pernah melihat judul yang sama sebelumnya...
Sepertinya bahkan materi yang disajikan di baris pertama pun belum diverifikasi.
Semakin besar sebuah organisasi, rasanya semakin benar apa yang dikatakan pembicara ini.
Semakin kecil sebuah organisasi, rasanya arah yang dibicarakan pembicara ini sudah memang seperti itu wkwk
Saya pikir ini tulisan yang cukup realistis dan berwawasan tentang cara memaksimalkan man power individu di titik saat ini, ketika AI TOOLs menjadi kenyataan. Ke depannya, semua hal akan makin menuntut bobot yang lebih ringan dan kecepatan yang lebih tinggi, jadi pola kolaborasi lama dengan cara pikir usang yang selama ini dijalankan kemungkinan akan di-reset. Namun, untuk pengembangan solusi tingkat enterprise, kolaborasi tetap wajib.