Perusahaan teknologi menghadapi kontradiksi yang membingungkan: pekerjaan paling efisien mereka terjadi dalam tim kecil atau di luar jam kerja, namun mereka terus menambahkan lapisan birokrasi yang memperlambat segalanya. Analisis terbaru yang mengacu pada karya James C. Scott berjudul Seeing Like a State mengungkap mengapa kegilaan yang tampak ini sebenarnya masuk akal secara bisnis.
Konsep ini berpusat pada keterbacaan - membuat pekerjaan dapat diprediksi, diukur, dan dilacak melalui proses formal. Meskipun pendekatan ini mengurangi efisiensi rekayasa mentah, hal ini menciptakan sesuatu yang lebih berharga bagi perusahaan besar: kemampuan untuk merencanakan ke depan, berkoordinasi dengan organisasi lain, dan yang terpenting, memenangkan kontrak enterprise yang menguntungkan.
Biaya Tersembunyi dari Birokrasi
Insinyur perangkat lunak sering bercanda tentang mengambil cuti untuk benar-benar menyelesaikan pekerjaan, atau lebih produktif bekerja sendirian daripada dalam tim. Ini bukan sekadar humor tempat kerja - ini mencerminkan kerugian efisiensi nyata yang terjadi ketika perusahaan memprioritaskan proses daripada kecepatan. Startup kecil dapat mengungguli raksasa teknologi dengan sepuluh kali lebih banyak insinyur hanya karena mereka menghindari overhead dari sistem perencanaan, pelaporan, dan koordinasi formal.
Namun, menganggap proses-proses ini sebagai pemborosan murni mengabaikan tujuan strategis mereka. Pelanggan enterprise besar menuntut prediktabilitas dan komitmen jangka panjang yang hanya dapat diberikan oleh organisasi yang sangat terstruktur. Startup mungkin membangun fitur lebih cepat, tetapi tidak dapat secara kredibel berjanji untuk memberikan fungsionalitas spesifik selama timeline 18 bulan sambil mempertahankan laporan kemajuan yang detail.
Perbedaan Utama Antara Perusahaan Teknologi Kecil dan Besar:
| Aspek | Perusahaan Kecil | Perusahaan Besar |
|---|---|---|
| Kecepatan Keputusan | Jam hingga hari | Minggu hingga bulan |
| Beban Proses | Proses formal yang minimal | Perencanaan dan pelaporan yang ekstensif |
| Efisiensi Tim | Produktivitas individu yang tinggi | Efisiensi per orang yang lebih rendah |
| Penjualan Enterprise | Kemampuan terbatas | Komitmen jangka panjang yang terstruktur |
| Komunikasi | Saluran informal langsung | Sistem hierarkis formal |
| Perencanaan Proyek | Fleksibel dan reaktif | Siklus perencanaan kuartalan |
Pelanggan Enterprise Mendorong Persyaratan Proses
Pendorong sebenarnya di balik birokrasi perusahaan bukanlah kontrol internal - tetapi tuntutan pelanggan eksternal. Kesepakatan enterprise, yang dapat bernilai jutaan dolar Amerika, mengharuskan vendor untuk menunjukkan keandalan melalui proses formal. Pelanggan ini perlu melihat dokumen perencanaan kuartalan, sistem pelacakan kemajuan, dan struktur akuntabilitas yang jelas sebelum menandatangani kontrak besar.
Ini menciptakan loop umpan balik di mana perusahaan teknologi yang sukses menjadi lebih berat proses seiring pertumbuhan mereka. Pelanggan paling menguntungkan secara aktif memilih vendor yang dapat berbicara dalam bahasa mereka tentang manajemen proyek formal dan pelaporan detail. Perusahaan yang menolak transformasi ini sering menemukan diri mereka terkunci dari segmen pasar yang paling menguntungkan.
Pemberontakan yang Disahkan dan Jaringan Informal
Meskipun menekankan proses formal, perusahaan teknologi yang sukses mempertahankan katup pelarian untuk pekerjaan mendesak. Tim harimau atau tim serbu menerima izin sementara untuk melewati prosedur normal ketika menghadapi masalah kritis. Kelompok-kelompok ini beroperasi dengan pengawasan minimal dan dapat menyelesaikan masalah dalam hitungan hari yang mungkin memerlukan waktu berbulan-bulan melalui saluran reguler.
Lebih umum lagi, insinyur mengandalkan saluran belakang informal - hubungan langsung dengan rekan di tim lain yang dapat membuat perubahan cepat tanpa melalui sistem permintaan resmi. Seorang insinyur mungkin meminta insinyur lain untuk perubahan kode satu baris yang sederhana, melewati proses perencanaan formal selama berminggu-minggu. Hubungan-hubungan ini sangat penting untuk operasi sehari-hari tetapi tetap tidak terlihat oleh sistem pelacakan resmi.
Cara sebenarnya untuk mengatasi masalah ini adalah saluran belakang yang tidak terbaca. Seorang insinyur di tim A menghubungi seorang insinyur di tim B dan bertanya: 'hei, bisakah kamu membuat perubahan satu baris ini untukku?'. Insinyur di tim B kemudian melakukannya segera, mungkin membuat dalih, mungkin tidak.
Alur Kerja Proyek Perusahaan Besar pada Umumnya:
- Tahap pembuatan ide produk
- Tahap perencanaan organisasi produk
- Tinjauan arsitektur engineering
- Negosiasi penugasan tim
- Breakdown teknis dan estimasi
- Perencanaan sprint dan pembuatan tiket
- Implementasi oleh engineer individu
- Proses tinjauan legal dan desain
- Prosedur deployment kepada pelanggan
Catatan: Proses ini dapat memakan waktu berminggu-minggu hingga berbulan-bulan sebelum coding yang sebenarnya dimulai
Keseimbangan Antara Kontrol dan Efisiensi
Tantangan bagi perusahaan teknologi besar terletak pada mempertahankan proses formal untuk kredibilitas eksternal dan jaringan informal untuk efisiensi internal. Terlalu banyak proses menghambat inovasi dan membuat frustrasi insinyur berbakat. Terlalu sedikit proses membuat tidak mungkin untuk mengoordinasikan proyek besar atau memuaskan pelanggan enterprise.
Organisasi yang paling sukses mengenali dualitas ini dan secara aktif mengelola kedua sistem. Mereka berinvestasi dalam alat perencanaan dan pelaporan formal sambil diam-diam mentolerir jaringan informal yang membuat pekerjaan sehari-hari menjadi mungkin. Ini memerlukan manajemen budaya yang hati-hati - mendorong pelanggaran aturan ketika diperlukan sambil mempertahankan struktur yang cukup untuk berfungsi dalam skala besar.
Memahami keseimbangan ini membantu menjelaskan banyak perilaku perusahaan yang tampaknya tidak rasional. Perusahaan tidak hanya birokratis demi birokrasi - mereka membuat trade-off yang diperhitungkan antara efisiensi internal dan peluang pasar eksternal. Miliaran dolar Amerika yang tersedia di pasar enterprise membenarkan biaya overhead dari proses formal, bahkan ketika proses tersebut memperlambat tim rekayasa individual.
Referensi: Seeing like a software company