Mengapa engineer senior membiarkan proyek buruk berjalan begitu saja

• Engineer senior lebih menekankan ‘tindakan yang efektif’ daripada ‘kebenaran’, sehingga tidak berusaha menghentikan semua proyek yang salah
• ‘Proyek buruk’ mencakup masalah teknis, politis, dan UX, dan sering kali bergantung pada penilaian subjektif
• Pengaruh harus dikelola seperti rekening bank, karena terlalu sering menentang bisa mengikis kepercayaan dan membuat seseorang jatuh ke kondisi ‘bangkrut secara politis’
• Keputusan untuk ikut campur ditentukan oleh jarak proyek, dampaknya pada tim, dan besarnya kerugian bagi perusahaan secara keseluruhan
• Daripada mencoba menyelesaikan semua masalah, kita perlu memilih momen intervensi secara strategis, sementara sisanya dihadapi dengan observasi dan persiapan

---

Definisi dan contoh proyek buruk

• ‘Proyek buruk’ muncul dalam berbagai bentuk seperti memecahkan masalah yang tidak perlu, desain yang rumit, dan motivasi politik
  • Dari sisi UX, ini bisa berupa upaya menyelesaikan masalah yang sebenarnya tidak ada atau merusak alur yang sudah berjalan
  • Secara teknis, contohnya adalah kompleksitas berlebihan, pemilihan library yang keliru, dan arsitektur yang tidak efisien
  • Secara politis, ini bisa berupa proyek demi promosi atau sekadar mengikuti tren
• Baik buruknya sebuah proyek adalah penilaian subjektif yang baru terlihat seiring waktu, sehingga pada tahap awal sering tidak jelas
• Salah satu contoh di Google adalah proyek ketika tim platform berusaha menyerahkan alur pengguna inti ke tim lain, yang akhirnya gagal karena alasan politik
  • Secara teknis proyek itu sangat baik, tetapi dibatalkan dua tahun kemudian karena masalah kewenangan antarorganisasi
  • Pelajarannya: “politik dan ketepatan dalam mendefinisikan masalah sama pentingnya dengan kesempurnaan teknis”

Mengapa tidak mungkin menghentikan semua proyek buruk

• Perusahaan software memiliki bias kuat terhadap ‘bergerak cepat’, sehingga menyuarakan kekhawatiran sering dianggap memperlambat laju
  • Karena itu, jika tidak dipandang sebagai masalah besar, keberatan kemungkinan besar akan diabaikan
• Penolakan yang berulang dapat membuat seseorang dicap sebagai sosok negatif, sementara kegagalan yang berhasil dicegah jarang mendapat pengakuan
• Keberatan juga bisa memengaruhi promosi orang lain atau proyek milik eksekutif senior, sehingga ada risiko politik
• Perhatian yang bisa ditanggung seorang engineer terbatas, dan jika ikut campur dalam semua masalah, ia bisa menjadi sinis

Mengelola pengaruh seperti ‘rekening bank’

• Pengaruh adalah aset yang dikumpulkan lewat hasil kerja dan kolaborasi, lalu ditarik setiap kali kita menentang sesuatu
  • Cek $5: catatan kecil setingkat code review
  • Cek $500: sanggahan terhadap keputusan arsitektur atau jadwal
  • Cek $50,000: upaya menghentikan proyek level eksekutif
• Jika terus-menerus ikut campur dalam masalah kecil, kita akan kehilangan kapasitas untuk merespons isu besar
• Saat pengaruh habis, seseorang bisa jatuh ke kondisi ‘bangkrut secara politis’, misalnya tidak lagi diundang ke rapat atau pendapatnya diabaikan

Kriteria untuk menentukan kapan harus ikut campur

• Verifikasi keahlian: pastikan penilaian kita benar-benar memiliki dasar yang cukup
• Sadari batas ucapan: menyampaikan pendapat bukanlah ‘perintah’, melainkan ‘berbagi sudut pandang’
• Tiga faktor penilaian
  • Kedekatan (Proximity): semakin dekat dengan tim sendiri, semakin rendah biaya intervensi
  • Dampak pada tim (Team Impact): jika kegagalan diperkirakan merugikan tim secara langsung, nilai intervensinya lebih tinggi
  • Skala perusahaan (Company Scale): jika kegagalan berdampak besar pada organisasi secara keseluruhan, intervensi menjadi perlu

Cara merespons proyek buruk

• Intervensi langsung: meminta proyek dihentikan atau menyerahkan dokumen kekhawatiran yang tegas
  • Membutuhkan keyakinan dan kesiapan menanggung risiko
• Intervensi parsial: mengarahkan desain ke jalur yang lebih baik atau mendorong solusi yang lebih tepat
  • Jika dilakukan dengan sikap kolaboratif, kita bisa dipandang sebagai orang yang membantu
• Tidak ikut campur: ketika inersia politik atau keterbatasan pengaruh membuat intervensi tidak sepadan
  • Jika tim terkait, perlu menyiapkan langkah antisipasi seperti mengurangi dependensi atau membangun alternatif
  • Jika tidak terkait, amati dengan tenang dan bagikan pendapat hanya secara internal
• Mengelola tim: sampaikan realitas kepada anggota tim secara jujur, tetapi singkirkan detail politik yang tidak perlu

Kesimpulan

• Intinya adalah kesadaran bahwa “kebenaran dan efektivitas itu berbeda”
• Di perusahaan besar, politik dan konteks sering lebih menentukan daripada logika, dan tidak semua kesalahan bisa diperbaiki
• Kita perlu menggunakan pengaruh dan kepercayaan secara strategis agar fokus pada momen yang benar-benar bisa menghasilkan perubahan nyata
• Dalam situasi lainnya, berbagi dengan rekan, bersiap, dan belajar lewat observasi
• Meski tidak bisa menyelesaikan semuanya dengan sempurna, pendekatan ini lebih berkelanjutan

[GN⁺]

Komentar Hacker News

• Jadi teringat seorang manajer dulu pernah berkata, “kadang kita harus membiarkan orang gagal”
  Terlalu banyak energi yang habis untuk terus menopang orang-orang tertentu. Saya berharap suatu saat mereka bisa berenang sendiri, tetapi kadang usaha itu memang lebih tepat dipakai di tempat lain
  Ada proyek yang berjalan tanpa keterlibatan saya, dan proyek itu mustahil berhasil tanpa pengetahuan yang saya miliki. Tim itu sangat buruk sampai-sampai mereka mencampur pertanyaan ke dalam pekerjaan seolah itu bagian dari alur kerja
  Selain itu, ketika saya tahu manajemen meremehkan tim saya dan malah memuji mereka, saya benar-benar merasa terhina. Implementasi mereka mengerikan

  • Saya sering berkata, “kadang kita harus membiarkan manajer gagal”
    Beberapa manajer tidak suka diberi tahu bahwa idenya tidak akan berhasil. Kalau dibantah, kita justru dijadikan penyebab kegagalan
    Jadi saya tetap menjalankan pekerjaannya, tetapi sering membagikan perkembangannya kepada mereka. Dengan begitu mereka bisa melihat sendiri kegagalan yang sudah diperkirakan, dan itu memisahkan saya dari kegagalan tersebut
  • Kalau eksekutif gagal, mereka tidak saling menyalahkan. Sebagai gantinya mereka memanggil konsultan lalu memecat engineer senior
  • Saya pernah mendengar ungkapan, “orang harus mengumpulkan datanya sendiri.” Pada akhirnya, orang memang belajar setelah mengalaminya langsung
  • Saya rasa kegagalan seseorang dan kegagalan proyek itu berbeda
    Kegagalan individu biayanya lebih kecil dan bersifat mendidik. Kadang pendekatan mereka justru berhasil, sehingga organisasi memperoleh aset pengetahuan baru
  • Membiarkan orang belajar sendiri itu berisiko. Kita harus percaya bahwa mereka punya kesadaran diri dan tidak bergantung pada dukungan kita
    Mereka bisa saja gagal dan tetap tidak belajar. Tetapi kalau kita sudah melakukan yang terbaik, setidaknya kita masih punya ketenangan hati nurani

• “Buruk”-nya sebuah proyek itu subjektif selama sebagian besar siklus hidupnya
  Pernah ada orang luar yang menentang sebuah proyek dan berusaha menghentikannya, tetapi proyek itu akhirnya dirilis dan sukses, dan kredibilitas mereka pun runtuh
  Kita harus hati-hati dalam memakai reputasi kita

  • Saya juga pernah mengalami hal serupa. Itu pertama kalinya saya melihat keegoisan yang begitu terang-terangan dalam organisasi yang seharusnya dibangun untuk kolaborasi
    Saya tahu dunia tidak selalu penuh sinar matahari dan pelangi, tetapi waktu itu saya benar-benar kecewa

• Seperti ungkapan “bukan monyet saya, bukan sirkus saya”, saya tidak ikut campur dalam hal-hal yang bukan tanggung jawab saya
  Bahkan saat bekerja sebagai arsitek, saya tidak memberi nasihat yang tidak perlu tentang UI atau logika bisnis yang bukan wilayah saya
  Untuk hal-hal yang diputuskan manajer di atas saya, saya hanya mengikutinya. Saat bekerja sebagai konsultan pun saya memegang prinsip yang sama
  Saya hanya campur tangan dengan hati-hati di bidang keahlian saya sendiri. Itu pun hanya jika ada persetujuan C-suite

• Nasihat ini cukup tepat untuk perusahaan kecil dan menengah. Tetapi di perusahaan besar, menyampaikan penolakan terhadap proyek hampir tidak ada gunanya
  Kalau berhasil, kita terlihat bodoh, dan kalau gagal pun tidak akan diingat
  ROI yang sebenarnya muncul saat kita menawarkan solusi setelah kegagalan. Orang suka pada “pemecah masalah”
  Dulu saya pernah mengusulkan automated E2E testing dan ditolak, tetapi ketika masalah meledak kemudian, saya mengeluarkan framework itu dan diperlakukan seperti pahlawan

  • Makin naik posisi di perusahaan, makin besar tanggung jawab atas kesalahan orang lain dan makin kecil imbalannya
    Rasanya justru lebih bijak hidup tanpa stres di level jabatan yang lebih rendah
  • Di startup, beberapa engineer yang berkata “ini tidak masuk akal” bisa mencegah bencana
    Sebaliknya, perusahaan besar membuang waktu bertahun-tahun dan jutaan dolar karena politik

• Saya ada di kubu “jangan abaikan masalah”
  Kalau kita berada di posisi yang bisa membantu, kita tetap harus mengusulkan pendekatan lain, meski diam-diam. Tidak perlu bereaksi emosional

  • Syarat “berada di posisi yang bisa membantu” itulah kuncinya
    Di organisasi kecil, ide bagus mudah diterapkan, tetapi di organisasi besar risiko politik jauh lebih besar
    Kemungkinan benar-benar bisa membantu lebih kecil daripada kemungkinan kehilangan reputasi. Karena itu penting memilih pertarungan
  • Di organisasi kecil, turun tangan sejak awal mungkin memang kewajiban
    Tetapi di organisasi besar, mengubah proyek yang sudah berjalan butuh waktu dan energi yang sangat besar
  • Ungkapan “biarkan saja proyek buruk” bisa menyesatkan
    Kenyataannya, sering kali kita memang tidak bisa mengendalikan proyek itu. Judul yang lebih akurat adalah “kita tidak tahu kenapa tim lain melakukannya seperti itu”
  • Kalau saya sudah tahu akan gagal, saya meninggalkan pendapat saya dalam dokumen lalu selesai
    Profesionalisme berarti berbicara saat memang perlu bicara. Tetapi dari pengalaman saya, hampir tidak pernah ada yang berubah
  • Kalau tahu, sampaikan saja, lalu setelah itu jangan menanggung beban emosional. Kalau nasihat kita diabaikan, itu bukan masalah kita lagi

• Saya sedang benar-benar melihat situasi seperti ini sekarang
  Pemilik bisnis memilih platform low-code karena biaya dan kecepatan, tetapi akhirnya butuh kustomisasi besar-besaran yang levelnya seperti hacking
  Tim saya melakukan deploy beberapa kali sehari dengan TypeScript, sedangkan tim itu deploy sebulan sekali dan melakukan hal-hal aneh dengan curl

• Nasihat ini sangat bagus dalam realitas politik big tech, tetapi pada akhirnya terasa seperti pasifisme korporat
  Di lingkungan lain, tidak ada kemewahan untuk membakar uang dan motivasi begitu saja
  (Meski begitu, Lalit merangkum dinamika organisasi yang rumit dengan baik dalam tulisan singkat)

  • Saya belum pernah bekerja di big tech, tetapi saya melihat gejala yang sama di organisasi kecil
    Orang yang terus-menerus mencari-cari kesalahan pada akhirnya dicap sebagai orang negatif
    Inti nasihatnya pada akhirnya adalah simpan energi untuk momen yang benar-benar penting. Tidak semua masalah menentukan hidup-matinya perusahaan
  • Pasifisme bukan berarti tidak bertindak. Justru itu tindakan politik yang paling aktif dan efektif

• Engineer tidak punya wewenang untuk “membiarkan” proyek yang buruk secara politik itu gagal
  Itu adalah tanggung jawab manajemen. Engineer cukup memberi nasihat teknis
  Namun kita tetap perlu memahami dinamika seperti ini agar karier kita tidak terkena dampaknya
  Perebutan wilayah antara tim produk dan tim platform terjadi karena tidak adanya kepemimpinan yang jelas
  Kalau penasaran kenapa hal seperti ini sering terjadi, tulisan tentang Google ini layak dibaca

• Pola pikir seperti ini umum di organisasi besar, khususnya instansi pemerintah
  Biayanya ditanggung departemen lain, dan kekuasaan diukur dari jumlah orang yang dikelola
  Untuk mencegah nekrosis organisasi seperti ini, pemimpin harus membangun sistem pengukuran dan pencegahan yang jelas

  • Manusia secara naluriah menyukai orang yang positif dan tidak menyukai orang yang negatif
    Modal politik tidak akan hilang hanya karena kita mengabaikannya

• Ini analogi yang bagus
  Kalau kita membangun kepemimpinan dan kepercayaan, akan tercipta ruang untuk berkata “Anda salah”
  Tetapi alasan pemimpin tidak selalu percaya pada engineer adalah karena kadang engineer memang salah
  Engineer sangat hebat dalam menemukan cacat, tetapi lemah dalam memahami konteks bisnis
  Karena itu, bahkan untuk “ide yang terlihat bodoh” pun kita harus memahami konteksnya dulu sebelum menilai
  Ketika kita bisa membedakan ide yang benar-benar harus dimatikan dari ide yang sekadar punya cacat, kita akan memperoleh kepercayaan di dalam organisasi