Memandang Seperti Perusahaan Software

• Inti dari "Seeing Like A State" karya James C. Scott adalah bahwa organisasi berupaya meningkatkan "keterbacaan (legibility)" sistem agar semuanya bisa diukur dan dilaporkan
• Namun pada praktiknya, "pekerjaan yang tidak terbaca" yang tidak bisa dilacak atau diprediksi justru bersifat esensial, dan jika hanya menekankan keterbacaan, efisiensi malah bisa menurun
• Khususnya perusahaan besar membuat pekerjaan menjadi terbaca melalui proses seperti perencanaan kuartalan, OKR, dan Jira, tetapi secara paradoks hal ini menurunkan efisiensi, sehingga perusahaan kecil bisa 20 kali lebih efisien daripada perusahaan besar
• Organisasi mengizinkan area sementara yang tidak terbaca seperti "tim tiger" untuk menangani situasi darurat, dan kolaborasi informal melalui backchannel antarininyur memainkan peran yang sama pentingnya dengan proses resmi
• Keberhasilan perusahaan teknologi bergantung pada menjaga keseimbangan antara proses yang terbaca dan praktik kerja yang tidak terbaca, karena organisasi tidak dapat berfungsi dengan baik jika hanya mengandalkan salah satunya

---

Pendahuluan: ide inti dari “Seeing Like A State”

• Inti buku "Seeing Like A State" karya James C. Scott dapat diringkas menjadi tiga poin berikut
  • Organisasi modern mengubah sistem ke bentuk yang memaksimalkan "keterbacaan (legibility)", sehingga setiap bagian bisa dikendalikan agar dapat diukur dan dilaporkan
  • Namun organisasi-organisasi ini bergantung pada pekerjaan "tidak terbaca (illegible)" dalam skala besar. Artinya, ada banyak pekerjaan penting yang tidak bisa dilacak atau direncanakan
  • Meningkatkan keterbacaan sering kali menghambat efisiensi, tetapi manfaat lain di luar itu seperti kontrol, perencanaan, dan transparansi dianggap jauh lebih besar
• Keterbacaan berarti pekerjaan yang dapat diprediksi, output-nya bisa dilacak, dan tidak bergantung pada sumber daya manusia tertentu. Contohnya: manajemen jadwal, OKR, Jira, dan sebagainya
• Ketidakterbacaan berarti pekerjaan yang improvisasional atau berbasis pengetahuan tacit, yaitu kolaborasi, perubahan mendadak, atau pekerjaan yang bergantung pada relasi antarmanusia yang tidak bisa didokumentasikan atau diformalkan

Contoh “melihat seperti negara (Seeing like a state)”

• Scott menggunakan contoh "hutan yang tertata rapi" di Jerman abad ke-19 untuk menjelaskan upaya organisasi mengendalikan dan menstandarkan demi efisiensi
  • Dengan mengelola agar semua pohon di hutan bisa dipahami sekaligus, ada harapan efisiensi perencanaan, transaksi, dan distribusi sumber daya akan meningkat
  • Pada kenyataannya, keragaman hutan dan peran tumbuhan bawah justru diabaikan, sehingga produktivitas menurun dan hutan menjadi rentan terhadap penyakit serta parasit
• Dengan kata lain, mereka mengejar efisiensi sekaligus transparansi, tetapi pengejaran keterbacaan yang berlebihan malah menghasilkan dampak yang menghambat efisiensi

Keterbacaan dan ketidakterbacaan di perusahaan software

• Perusahaan software juga demikian; tim kecil atau individu bisa lebih efisien
  • Di kalangan software engineer, hampir sudah menjadi pengetahuan umum bahwa seorang engineer tunggal bisa lebih efisien saat bekerja sendiri daripada saat bekerja sebagai bagian dari tim
  • Pekerjaan yang digerakkan engineer berjalan jauh lebih cepat daripada pekerjaan yang diarahkan dari atas, karena tidak perlu menerjemahkannya ke bentuk yang bermakna atau berkomunikasi aktif ke segala arah
• Alasan perusahaan software kecil jauh lebih unggul dalam mengirimkan software dibanding perusahaan besar adalah karena meski perusahaan besar menaruh engineer 10 kali lebih banyak, itu tidak jadi masalah jika perusahaan kecil 20 kali lebih efisien
• Di perusahaan besar, berbagai prosedur dan alat diperkenalkan untuk membuat pekerjaan engineer menjadi "terbaca"
  • Ini menguntungkan untuk perencanaan, pengukuran, dan pelaporan, tetapi bisa menurunkan produktivitas software yang sebenarnya
• Perusahaan kecil bisa langsung merespons masalah atau cepat menerima perubahan (kemampuan yang tidak terbaca)
• Alasan perusahaan besar mempertahankan prosedur rumit alih-alih efisiensi ini terkait dengan kontrak enterprise besar. Pelanggan besar menuntut prediktabilitas dan keandalan dari vendor mereka
• Untuk bekerja sama dengan pelanggan seperti ini, perencanaan jangka panjang, komitmen fitur, dan dokumentasi progres adalah bentuk keterbacaan yang esensial
• Proses itu dipertahankan karena nilai yang diberikan keterbacaan (dalam ukuran dolar) lebih besar daripada kemampuan memproduksi software dengan lebih efisien

Nilai praktis keterbacaan yang diprioritaskan perusahaan besar

• Di perusahaan software besar, keterbacaan berarti
  • Bahkan engineer individual dapat mengetahui semua proyek yang sedang berjalan saat ini
  • Dapat segera menghasilkan daftar proyek yang diselesaikan pada kuartal sebelumnya
  • Dapat merencanakan pekerjaan setidaknya satu kuartal ke depan (atau lebih lama)
  • Dalam keadaan darurat dapat mengerahkan seluruh sumber daya departemen untuk langsung menangani pekerjaan mendesak
• Di luar kemampuan merespons secara fleksibel dan seketika, perusahaan software kecil hampir tidak dapat memenuhi persyaratan ini
• Perusahaan besar unggul dalam pencatatan, klasifikasi, dan perencanaan jangka panjang, tetapi daya tanggap cepat (mengerahkan sumber daya organisasi secara instan) justru bisa melemah
• Pengamanan keterbacaan seperti ini terutama memainkan peran penting dalam kepercayaan dengan pelanggan enterprise, kontrak, dan kerja sama jangka panjang

Asumsi untuk memastikan keterbacaan dan batasannya

• Dalam mendorong keterbacaan, perusahaan besar membuat asumsi sederhana berikut
  • Mengasumsikan semua engineer pada level yang sama berkinerja kurang lebih sama
  • Mengasumsikan tidak ada kehilangan produktivitas saat engineer dipindah atau direorganisasi
  • Mengasumsikan jika jumlah engineer dalam tim sama, tingkat produktivitas akan tetap terjaga seiring waktu
  • Mengasumsikan proyek dapat diestimasi sebelumnya dengan rentang galat tertentu
• Namun dalam kenyataannya
  • Bahkan pada level yang sama, perbedaan kemampuan sangat besar, dan spesialisasi serta minat dapat menciptakan perbedaan besar dalam produktivitas proyek
  • Ukuran tim dan produktivitas hanya memiliki korelasi yang lemah
  • Estimasi proyek nyaris seperti ilusi, dan dalam praktiknya cara kerja kadang justru diubah agar sesuai dengan jadwal estimasi
• Meski begitu, asumsi-asumsi ini tetap berguna untuk komunikasi internal perusahaan, kesepakatan dengan perusahaan besar di luar, dan perencanaan bisnis

Area ketidakterbacaan yang diizinkan sementara

• Di perusahaan besar, proses untuk menciptakan keterbacaan menyebabkan penundaan yang serius
  • Ide produk → tahap perencanaan organisasi produk → tinjauan teknis organisasi engineering → negosiasi alokasi tim antara VP dan senior manager → masuk ke backlog perencanaan tim → backlog tiket tim → masuk sprint → pekerjaan nyata dimulai
• Struktur ini sama sekali tidak kompatibel dengan pekerjaan yang harus dilakukan segera
• Untuk mengatasi masalah ini, organisasi mengizinkan area sementara yang tidak terbaca seperti "tim virtual", "strike team", dan "tim tiger"
  • Terdiri dari engineer terpilih yang dipercaya organisasi
  • Sering kali tidak diberi manajer sama sekali, dan proyek dijalankan oleh engineer yang sangat senior
  • Diberi misi yang longgar dan pada dasarnya diizinkan melakukan apa pun untuk mencapai tujuan
• Ini adalah kompromi yang cerdas antara ketidakterbacaan total dan keterbacaan total
• Proses resmi dilewati, tetapi area ini tidak berjalan permanen dan hanya dipertahankan sementara
• Bahkan ketidakterbacaan yang diizinkan hidup berdampingan secara canggung dengan organisasi lainnya, dan engineer lain bisa iri atau menganggapnya berbahaya karena melihat kebebasan bekerja tanpa beban proses

Area ketidakterbacaan yang permanen dan tidak diizinkan

• Cara resmi bagi engineer di tim A untuk meminta pekerjaan ke tim B adalah membuat isu di backlog "perencanaan", melewati proses 12 langkah, lalu menunggu sampai masuk sprint, yang bisa memakan waktu beberapa minggu hingga beberapa bulan
• Solusi resminya adalah tim A harus mengantisipasi pekerjaan tim B dalam proses perencanaan, tetapi ini tidak masuk akal karena mustahil memperkirakan semua perubahan berbulan-bulan sebelum menulis kodenya
• Solusi nyata adalah backchannel yang tidak terbaca
  • Engineer tim A meminta ke engineer tim B, "bisakah Anda melakukan perubahan satu baris ini?"
  • Engineer tim B langsung mengerjakannya, dan membuat tiket menjadi opsional
  • Karena bergantung pada hubungan interpersonal antarininyur, hal ini menjadi tidak terbaca
• Backchannel ada terus-menerus di semua level perusahaan
  • Backchannel lintas tim antar-engineer, backchannel di dalam tim, antar-manajer, dan antar-product manager
  • Ketika pertanyaan diajukan di ruang resmi, sering kali jawabannya sudah lebih dulu dilatih dan ditinjau secara pribadi dengan pihak yang akan menjawab
• Backchannel bisa membawa dampak buruk, dan kadang dipakai untuk menguntungkan diri sendiri dengan mengorbankan engineer yang naif

Sosiopat, yang clueless, dan pecundang

• "Gervais Principle" dari Venkatesh Rao membagi organisasi ke dalam tiga kelompok
  • "Sosiopat" di puncak menggunakan aturan organisasi secara sinis demi kepentingan mereka sendiri
  • "Yang clueless" di manajemen menengah memercayai aturan resmi organisasi dan tidak menyadari bahwa ada permainan yang lebih dalam sedang berlangsung di atasnya
  • "Pecundang (losers)" di bawah menyadari permainan itu sedang berlangsung, tetapi tidak ingin ikut bermain
• Kategori-kategori ini dapat dibaca dari sudut pandang keterbacaan
  • Sosiopat dan pecundang sama-sama terlibat dalam dunia organisasi yang tidak terbaca
  • "Yang clueless" hanya terlibat pada proses yang terbaca, dan saat ingin promosi mereka akan melihat job ladder resmi lalu merencanakan bagaimana mewujudkan tiap nilai pada level berikutnya
• Menyebut mereka "yang clueless" terlalu sinis
  • Proses yang terbaca tetap sangat penting dan mencakup bagian besar dari apa yang dilakukan organisasi
  • Memperbaiki proses resmi tetap merupakan pekerjaan dengan leverage yang sangat tinggi
• Memikirkan orang-orang lewat kategori ini membantu memahami bahwa area konflik yang sering muncul di perusahaan software berasal dari gesekan antarkelompok ini

Pemikiran akhir

• Penting untuk mengenali dan memanfaatkan dunia ketidakterbacaan di dalam organisasi
• Saya telah banyak menulis tentang mengenali dan menggunakan ketidakterbacaan di perusahaan teknologi
  • Melanggar aturan resmi yang terbaca kadang merupakan hal yang benar
  • Product manager dapat menyalahgunakan saluran yang tidak terbaca sehingga perlu mewaspadai mereka menarik pekerjaan dari engineer yang naif
  • Engineer yang kompeten perlu mengerjakan "side bets" di luar proses perencanaan normal
  • Promosi ke level Staff ke atas hampir tidak ada hubungannya dengan job ladder resmi
• Nasihat tentang proses yang tidak terbaca termasuk "nasihat berbahaya"
  • Jika Anda secara terbuka mengumumkan bahwa pekerjaan diselesaikan melalui backchannel alih-alih proses resmi, Anda akan dihukum oleh organisasi
  • Anda tetap dihukum bahkan jika rantai manajemen sebenarnya ingin Anda melakukannya
• Banyak umpan balik negatif mengatakan bahwa proses resmi tidak boleh pernah dilewati, tetapi penulis menganggap pandangan ini naif
• Semua organisasi memiliki sisi yang terbaca dan sisi yang tidak terbaca
  • Sisi yang terbaca penting pada skala tertentu ke atas, dan memungkinkan perencanaan jangka panjang serta koordinasi dengan organisasi besar lain
  • Sisi yang tidak terbaca sama pentingnya: memungkinkan pekerjaan ber-efisiensi tinggi, menyediakan katup pengaman untuk proses yang tidak cocok dengan situasi saat ini, dan memenuhi kebutuhan alami manusia akan gosip serta konsensus lunak

[GN⁺]

Opini Hacker News

• Saya setuju dengan sebagian besar isinya, tetapi saya ingin mempersoalkan anggapan bahwa kepemimpinan secara otomatis menganggap legibility cukup berharga untuk membayar semua biayanya. Jika CEO harus memerhatikan setiap detail pekerjaan (misalnya paralelisasi unit test), itu seperti otak yang harus sadar setiap kali menggerakkan satu jari, sehingga akhirnya tidak bisa melakukan apa pun. Secara realistis, CEO, yaitu kepala sebuah perusahaan, hanya bisa mengendalikan sekitar 7% dari keseluruhan. Sisanya diisi oleh masing-masing karyawan; dirinya hanyalah otak, bukan seluruh tubuh. Namun para pemimpin mudah salah paham dan mengira dirinya yang paling penting, lalu hal-hal yang kekurangan waktu atau keahlian untuk mereka pahami (misalnya perbedaan antara engineer hebat lulusan MIT dan engineer rata-rata lulusan bootcamp) cenderung dilewati begitu saja. Bahkan saat membicarakan keberhasilan Google, ada kecenderungan memberikan pujian hanya kepada dua pendiri atau CEO, alih-alih kepada puluhan praktisi hebat

  • Saya rasa contoh “otak sadar setiap kali bernapas” agak merupakan straw man. CEO yang kompeten akan tahu bahwa mereka tidak perlu turun tangan langsung mengurusi pengelolaan unit test di tim pengembang. Dalam praktiknya, tingkat legibility yang dituju perusahaan berada pada rentang yang jauh lebih masuk akal

• Sebagian di sini benar, tetapi bukankah ini agak terlalu ekstrem. Saya bekerja di perusahaan berukuran sekitar 5000 orang (bukan kecil, tapi juga bukan sekelas Amazon). Sebagian besar aturan punya alasan yang cukup baik. Misalnya, perlunya 2 code reviewer itu untuk mencegah kesalahan. Memang tidak sering ada penolakan review, tetapi kalau deploy dilakukan tanpa review, insiden pasti akan lebih sering terjadi. Aturan seperti ini memaksa orang untuk tetap mengecek. Tentu, suatu hari akan ada situasi ketika aturan harus dilanggar (misalnya mayoritas anggota tim mendadak absen karena sedang menangani insiden). Dalam kasus seperti itu, masuk akal memberi pengecualian sesuai maksud aturan tersebut. Tapi kalau sebuah tempat hanya dipenuhi aturan birokratis murni yang tidak bisa dipahami (tipe orang yang memaksakan proses versinya sendiri sambil hanya berteriak “caramu salah”), orang akan memilih pergi. Jika lingkungan lebih mementingkan proses atau ego pribadi daripada kemajuan dan hasil nyata, pindah kerja adalah jawabannya

• Setelah TDD, godaan untuk berpikir “kalau tidak bisa diuji, berarti belum benar-benar diimplementasikan” menjadi makin kuat. Untuk menjelaskan ini, kata legibility terasa sangat tepat. Di Tritium, kami punya ratusan unit test, tetapi baru saat benar-benar membuat blog muncul bug kualitatif yang tidak tertangkap oleh unit test (dan memang sulit diverifikasi lewat test) — lihat https://tritium.legal/blog/eat. Mungkin ini juga alasan pengembangan game indie cukup tahan terhadap logika pasar. Developer game memakai produknya sendiri (Food-dogging) dan menghasilkan peningkatan kualitatif. Mereka tidak membutuhkan permukaan legibility yang berlebihan seperti software perusahaan besar. Intinya, kita butuh metrik kualitatif dan kuantitatif sekaligus

  • Test, khususnya unit test, rentan terhadap “efek lampu jalan”. Semakin sepele atau kurang penting suatu bagian, biasanya semakin mudah diuji, sehingga yang akhirnya diuji hanya hal-hal yang mudah. Jika organisasi terlalu terobsesi pada metrik yang mudah diukur seperti line coverage, ada risiko verifikasi yang benar-benar bermakna (dan sulit) justru terlewat. Penilaian kualitatif seperti review dari engineer berpengalaman juga penting

  • Pengembangan game punya feedback loop yang jauh lebih pendek dibanding bidang software lain. Misalnya, jika terjadi memory leak, masalahnya langsung terlihat ratusan kali per detik. Kode yang lambat juga langsung terasa lewat stutter visual, sehingga mendorong orang memikirkan performa sampai ke konsistensi cache, apakah memakai GC, dan sebagainya

  • Saya suka TDD, tetapi pada akhirnya pengujian manual juga mutlak perlu. Kalau tidak diuji langsung, masalah tak terduga sering muncul. Terutama hal-hal seperti kemudahan penggunaan, itu jauh lebih jelas saat benar-benar dipakai

• Saya senang membaca tulisan Sean, dan tulisan kali ini juga sangat saya rasakan di seluruh ranah produk. Misalnya sekitar setahun lalu, beberapa product owner dan engineer berusaha membuat sesuatu yang juga berguna bagi tim lain. Pada saat itu, secara struktural tidak realistis untuk mendapat persetujuan lewat saluran resmi (legible channel), jadi kami menjalankannya dalam bentuk tidak resmi (illegible channel) dengan dasar kepercayaan dan saling menghormati. Ini didorong secara grassroots, dan justru dengan cepat menyebar dari mulut ke mulut di dalam perusahaan hingga mendapat traction. Pada akhirnya, sekarang manajemen memanfaatkan kasus ini seolah-olah kisah sukses mereka sendiri, tetapi ketika semuanya dibalik menjadi prosedur resmi (legible channel) dan pembenaran dibuat belakangan, prosesnya cukup menyakitkan. Meski begitu, karena risiko gagal turun drastis, semuanya terasa lebih mudah. Ini salah satu proyek paling memuaskan dan paling menyenangkan yang saya kerjakan dalam beberapa tahun terakhir

• Semakin lama hidup bekerja di perusahaan dan terpapar office politics, semakin terasa mirip dengan geopolitics atau diplomasi. Kalau diteruskan lagi, saya juga melihat paralel dengan hubungan sosial dan hubungan romantis. Mungkin ini karena kecenderungan saya yang agak matematis dan suka membuat model abstrak

  • Politik justru topik favorit saya. Saya senang membaca buku, majalah, dan berbagai materi, dan sejujurnya office politics juga tidak terlalu mengganggu saya. Intinya pada akhirnya manusia akan bertindak seperti manusia. Setiap individu (dan organisasi juga) punya apa yang diinginkan (hasrat) dan apa yang ditakuti (ketakutan), dan proses menyeimbangkan keduanya itu sendiri cukup menyenangkan. Rasanya seperti memecahkan masalah engineering, hanya saja requirement-nya adalah “manusia”. Proses memecahkan masalah seperti ini sendiri menarik bagi saya

  • Saya baru belakangan ini menyadari hal seperti ini. Awalnya saya memandang diplomasi sebagai hasil dari sistem kompleks yang dibentuk oleh ratusan diplomat, tetapi pada dasarnya ini cuma hubungan antarmanusia di antara segelintir orang berkuasa. Pendekatannya bahkan bisa mirip dengan hal-hal yang terjadi di taman kanak-kanak

  • Ini fenomena yang secara naluriah terasa alami. Kesamaannya justru lebih jelas antara perusahaan besar dan pemerintah daripada dengan hubungan sosial (seperti percintaan). Perusahaan biasanya jauh lebih autocratic atau feudal. Memang ada banyak perbedaan, tetapi semakin besar skalanya, semakin mirip dengan pemerintah. Salah satunya adalah fakta bahwa keduanya menjadi birokrasi yang makin maju

  • Wiki game theory

  • Melihat bahwa cukup banyak politikus modern memulai dari pekerjaan kantoran biasa, fenomena ini juga tidak terlalu aneh

• Saya bekerja di bidang keamanan TI, dan di sini situasi seperti ini bahkan lebih terasa. Saat kami harus menerima “permintaan yang tidak membantu metrik langsung tim kami”, saya penasaran apakah ada alternatif selain metode tidak resmi (back channel). Kalau ada yang tahu, saya ingin mendengarnya

  • Anda bisa saling menukar apa yang diinginkan dengan menempatkan engineer tim Anda ke pekerjaan atau item roadmap yang diinginkan tim lawan

• Tulisan yang bagus, tetapi saya ingin menyebut satu hal yang selalu tidak dibahas. Tulisan ini agak mengecewakan karena menggambarkan software engineer (SWE) hanya sebagai daun pada pohon, semacam pekerja di jalur perakitan. Namun, seperti juga muncul di bagian “Legible assumptions”, engineer pada kenyataannya juga menjalankan “peran manajerial” dengan memperluas keterhubungan dalam struktur organisasi lewat “kode”. Masalahnya pada dasarnya serupa, hanya objek penerapannya yang berbeda

  • Untuk naik level IC seperti Senior Engineer, peran manajer sungguhan pun pada praktiknya diharapkan. Tidak cukup hanya jago menulis kode. Anda juga dituntut berperan sebagai manajer proyek, arsitek, pemimpin tim, sekaligus pembujuk, dan perlu meninggalkan dasar pembenaran dalam bentuk dokumen

• Adakah yang setuju dengan bagian tulisan yang berbunyi, “Mengapa perusahaan kecil tidak memerlukannya, tetapi perusahaan software besar justru sangat memerlukan kemampuan ini? Ini bukan bidang saya, tetapi mungkin karena proyek untuk perusahaan besar”? Saya ingin mendengar pendapat

  • Menurut saya, ini bukan soal deal perusahaan besar, melainkan soal “arus informasi dalam skala besar (communication at scale)” di dalam organisasi. Organisasi dengan m karyawan bisa dianalogikan sebagai matriks komunikasi m*m. Saat jumlah orang sedikit, hampir semua sel bernilai 1 (komunikasi erat), tetapi semakin besar skalanya, kebanyakan berubah menjadi 0 (terputus) atau 0.5 (komunikasi informal). Padahal informasi pada akhirnya adalah perusahaan itu sendiri. Karena itu, struktur yang membuat manajer dan proses resmi bertanggung jawab atas “arus” informasi menjadi mutlak perlu. Perencanaan, promosi, review, dan sebagainya semuanya dilakukan untuk memastikan legibility ini

  • Saya menangani proyek perusahaan besar di perusahaan kecil, tetapi deal tetap bisa terjadi tanpa menuntut legibility internal yang ketat. Di depan pelanggan, legibility dalam manajemen proyek memang diperlukan, tetapi itu tidak berarti mereka ikut campur rinci sampai ke cara pengembangan internal. Kesimpulannya, alasan perusahaan besar terobsesi pada legibility adalah karena mereka memang sudah menjadi perusahaan besar, atau sedang ingin menjadi perusahaan besar

  • Saya sudah lama berada di bidang pencitraan medis, dan sebagian besar pelaku bisnis sebenarnya tidak benar-benar memahami bahwa mereka berada di industri layanan/solusi TI. Kemampuan layanan TI-lah yang justru menjadi faktor keberhasilan nyata. Jauh lebih besar daripada diagnosis itu sendiri adalah kontribusi tenaga non-radiologi yang berusaha meningkatkan usability dan efisiensi platform

  • Seberapa pun besarnya organisasi, mereka selalu harus siap menghadapi audit internal dan eksternal berkali-kali. Auditor cenderung ingin melihat sebanyak mungkin dokumen proses. Misalnya, dalam kasus ini, dalam skenario terburuk auditor bahkan bisa “memecat” kliennya

  • Bagian itu (karena deal perusahaan besar) tetap terasa agak janggal bagi saya. Sebagai orang yang berasal dari startup dan sekarang menjadi manajer menengah di perusahaan menengah, saya melihat bahwa semakin besar skala organisasi, semakin dibutuhkan struktur minimum yang memberi tahu cara menjalankan pekerjaan. Seberapa pun orang tidak suka proses, setelah melewati Dunbar’s Number, empati dan komunikasi informal saja punya batas. Contoh ekstremnya mungkin Steam, tetapi di sana pun hanya tipe talenta tertentu yang terseleksi, dan politik internalnya sangat berat

• Bahkan pilihan kata legibility sendiri menarik. Rasanya seperti dikotomi antara proses formal dan informal. Saat perusahaan masih kecil, cara informal bekerja dengan baik, tetapi setelah melewati ambang tertentu, aturan dan proses formal tak bisa dihindari. Dalam jangka panjang, aturan memunculkan kekakuan dan gagal mengikuti perubahan. Lama-lama orang menjadi terobsesi pada proses itu sendiri, bukan tujuan. Tidak mudah keluar dari rutinitas seperti ini dan tetap mempertahankan hal baru. Di perusahaan orang sering berkata uang itu seperti darah, tetapi sebenarnya jarang sekali uang menjadi akar motivasi. Uang memang syarat perlu, tetapi menurut saya bukan alasan keberadaan itu sendiri

• Ini selalu soal keseimbangan. Saya sudah 25 tahun menjadi engineering manager dan bekerja di perusahaan yang sangat berorientasi proses. Itu memang membuat frustrasi, tetapi juga punya kelebihan karena berhasil secara konsisten menghasilkan hardware kelas dunia (bukan software). Dokumentasi dan semacamnya memang perlu, tetapi kalau terlalu ketat, proyek bisa membeku. Communication overhead adalah masalah paling serius. Itulah sebabnya tim kecil yang kompeten dan sudah lama bekerja bersama bisa menghasilkan produktivitas luar biasa, dan tribal knowledge benar-benar menjadi akselerator yang sangat penting. Saya menulis Concrete Galoshes untuk membahas unsur struktural dan kekakuan seperti ini. Pelajaran terbesarnya adalah “jangan memakaikan pakaian yang sama ke semua proyek”. Tiap proyek memerlukan struktur dan overhead yang berbeda

  • Communication overhead memang masalah yang sesungguhnya. Jika anggota tim ditambah, kebutuhan komunikasi di dalam tim meningkat secara eksponensial, dan hal yang sama berlaku saat jumlah tim di seluruh organisasi bertambah. Rahasia menjadi tim yang sangat efisien adalah kepercayaan dan saling memahami. Seiring waktu, orang saling mengenali kekuatan dan kelemahan masing-masing, lalu membangun kepercayaan antartim. Akan ideal jika tribal knowledge yang terakumulasi seperti ini diturunkan dengan baik lewat dokumentasi, mentoring, presentasi, dan sebagainya