Pertama kali diterbitkan pada tahun 2016.
“Saya tidak bisa mengeluarkan kode apa pun dari semua pertemuan ini.” Bagaimana jika keluhan insinyur abadi ini memiliki penyebab yang terbalik? Menambah dan menghapus overhead organisasi relatif mudah dibandingkan dengan meningkatkan kapasitas organisasi untuk menerapkan kode. Bagaimana jika pertemuan dan peninjauan merupakan respons adaptif organisasi untuk menghindari penerapan yang berlebihan?
Chuck Rossi (ed: manajer rilis legendaris di Facebook awal hingga menengah) membuat pengamatan bahwa tampaknya ada sejumlah perubahan yang bisa ditangani Facebook dalam satu penerapan. Jika kita menginginkan lebih banyak perubahan, kita memerlukan lebih banyak penerapan. Hal ini menyebabkan peningkatan yang stabil dalam kecepatan penerapan selama lima tahun terakhir, dari penerapan mingguan menjadi harian menjadi tiga kali sehari penerapan kode PHP kami dan dari siklus enam hingga empat hingga dua minggu untuk penerapan aplikasi seluler kami. Peningkatan ini terutama didorong oleh tim teknisi rilis (saya adalah penggemarnya, tahukah Anda?)
Saat saya tertidur kemarin, saya memvisualisasikan grafik “perubahan per penerapan” berbentuk gigi gergaji dan saya tersadar bahwa mungkin overhead organisasi kami salah. “Perubahan per penerapan” sepertinya merupakan metrik yang tidak elastis. Hal ini mungkin untuk ditingkatkan, tetapi hanya dengan usaha keras seiring berjalannya waktu. Apa yang terjadi bila jumlah perubahan yang dihasilkan melebihi ambang batas saat ini? Perubahan per penerapan tidak berubah. Jumlah perubahan harus dikurangi.
Bagaimana? Dengan meningkatkan overhead—rapat, tinjauan, serah terima, overhead, dan pada akhirnya mematikan antusiasme dan inisiatif. Tidak ada seorangpun yang mau mengakui bahwa mereka melakukan hal tersebut dengan sengaja, namun mungkin respon yang muncul dari organisasi tersebut sudah optimal secara lokal—ubahlah hal yang paling mudah untuk diubah yang akan mengurangi tekanan.
Peningkatan biaya overhead memulai putaran umpan balik positif: lebih sedikit penyelesaian yang diselesaikan -> lebih banyak tekanan -> lebih banyak kesalahan -> lebih sedikit perubahan per penerapan -> lebih banyak overhead -> lebih sedikit penyelesaian. Upaya terisolasi untuk mengurangi overhead meningkatkan tekanan dan meningkatkan overhead.
Jika Anda ingin lebih banyak perubahan dilakukan, Anda perlu memperluas ujung selang, untuk meningkatkan kapasitas penerapan. Anda dapat melakukannya dengan cara yang sulit, yaitu dengan mengurangi siklus penerapan dan mengatasi kekacauan yang terjadi, atau dengan cara yang lebih sulit, dengan meningkatkan jumlah perubahan per penerapan (pengujian yang lebih baik, pemantauan yang lebih baik, isolasi antar elemen yang lebih baik, hubungan sosial yang lebih baik di tim). Tapi jangan mencoba mengurangi overhead. Hal ini pasti akan mengarah pada serangkaian pertemuan tentang cara mengurangi pertemuan. Setidaknya hal ini akan mencegah Anda mengirimkan terlalu banyak kode.
Esai ini adalah contoh dari Thinkie Reverse Causality. Ini adalah salah satu Thinkies yang paling menyenangkan untuk diterapkan karena ide-idenya tampak salah pada awalnya.
