Fenomena kontradiktif sedang terjadi di ruang rapat banyak perusahaan teknologi: manajer memuji-muji konsep "ownership mindset" atau pola pikir kepemilikan, tetapi langsung berubah sikap ketika engineer benar-benar menunjukkannya. Alih-alih disambut, engineer yang mempertanyakan keputusan arsitektur atau memperingatkan risiko kegagalan sistem justru dicap sebagai pribadi yang sulit diajak kerja sama.
Ketidakselarasan ini menciptakan lingkungan kerja yang beracun bagi pengembangan perangkat lunak jangka panjang. Seorang engineer yang menyuarakan kekhawatiran bahwa sebuah fitur akan merusak basis data saat terjadi penulisan bersamaan (concurrent writes) kerap direspons dengan perintah singkat: "bangun saja sesuai permintaan saya." Padahal, peringatan itulah inti dari tanggung jawab terhadap produk.
Akar masalah dari fenomena ini bukanlah sekadar miskomunikasi biasa. Faktor utamanya terletak pada struktur insentif di dalam organisasi. Manajer merasakan dampak keterlambatan rilis hari ini, sementara potensi pemadaman sistem (outage) baru akan terjadi beberapa bulan kemudian, biasanya di bawah pencapaian kinerja (KPI) manajer lain.
Karena rasa sakit akibat penundaan ada di ruang rapat saat itu juga, wajar jika manajer mengoptimalkan keputusan untuk menghindari rasa tidak nyaman tersebut. Hierarki yang kaku terasa seperti efisiensi bagi mereka yang berada di puncaknya. Ketika keputusan senior digugat, hal itu tidak lagi dirasakan sebagai evaluasi teknis, melainkan sebagai bentuk ketidakhormatan.
Dalam benak manajer, kepatuhan sering kali disalahartikan sebagai kemajuan. Jawaban "ya, saya akan membangunnya" dari engineer memberikan ilusi pergerakan tim yang cepat. Sebaliknya, kalimat "kita harus memikirkan ulang model datanya" terasa seperti gesekan yang mengganggu. Padahal, kurangnya gesekan justru berarti kegagalan yang lebih senyap.
Di Indonesia, budaya "ship fast" atau rilis cepat sangat melekat pada ekosistem startup, terutama pada perusahaan yang berada di fase pertumbuhan agresif. Tekanan untuk meluncurkan fitur baru setiap sprint sering kali mengorbankan kualitas fondasi sistem. Engineer yang tidak pernah mempertanyakan brief dianggap sebagai "team player" sejati, sementara mereka yang kritis dianggap menghambat bisnis.
Dampaknya mulai terlihat dalam bentuk akumulasi utang teknis (technical debt) yang dibiarkan tumbuh diam-diam. Di banyak tim lokal, orang-orang cerdas mulai memilih untuk diam, memperbarui profil LinkedIn mereka, dan mencari tempat kerja yang lebih menghargai masukan teknis. Istilah "team player" perlahan berubah menjadi kode bagi mereka yang tidak berani mempertanyakan keputusan buruk.
Alih-alih membangun produk yang tangguh, perusahaan membeli kecepatan jangka pendek dengan harga kekacauan jangka menengah. Ketika sistem akhirnya runtuh, retrospektif dilakukan, semua setuju bahwa seharusnya ada yang bersuara lebih awal, namun tidak ada yang bertanya mengapa suara itu dibungkam sejak awal.
Seorang praktisi engineering yang mengamati budaya ini menekankan bahwa engineer yang hanya menurut tanpa reserve sebenarnya tidak sedang menunjukkan kepemilikan. "Mereka mengoptimalkan persetujuan dan meminimalkan konfrontasi. Itu bukan kepemilikan, melainkan pemindahan tanggung jawab. Saat sistem rusak, mereka punya alasan sempurna: saya membangun persis seperti spesifikasi," ujarnya.
Kepemilikan yang sesungguhnya, menurut perspektif tersebut, hadir melalui langkah konkret. Kekhawatiran harus disampaikan sejak fase desain, bukan tiga minggu setelah implementasi dimulai. Alasan teknis harus didasarkan pada data, bukan sekadar firasat. Misalnya, prediksi bahwa query N+1 akan gagal saat mencapai 10.000 pengguna jauh lebih berbobot daripada sekadar merasa 'ada yang aneh'. "Jika seorang engineer tidak bisa menjelaskan mode kegagalan sistem, tolak argumennya. Jika bisa, dengarkan. Berikan alternatif, bukan sekadar kata tidak," tambahnya.
Untuk mengubah arah, perusahaan teknologi perlu berhenti memperlakukan "ownership" sebagai sifat kepribadian pasif. Pemisahan antara diskusi desain dan implementasi menjadi kunci. Tim harus diberikan ruang untuk berpikir keras sebelum komitmen sprint ditetapkan. Mendorong pendapat kritis harus dihargai secara terbuka, terutama jika kekhawatiran tersebut akhirnya terbukti benar di kemudian hari.
Ke depannya, normalisasi perbedaan pendapat akan menjadi pembeda antara tim teknologi yang resilien dan yang rapuh. Jika manajemen benar-benar menginginkan produk yang bertahan dari skala pengguna 10 kali lipat, mereka harus berhenti menghukum engineer yang menjadi alarm peringatan dini. Kepemilikan bukan tentang menurut pada segalanya, melainkan menjaga nasib produk bersama.