Ekonomi Tim Perangkat Lunak: Mengapa Sebagian Besar Organisasi Engineering ‘Buta’ Secara Finansial

• Sebagian besar organisasi engineering beroperasi tanpa memahami biaya dan penciptaan nilai pada level tim secara kuantitatif, dan hal ini berujung pada inefisiensi finansial
• Biaya tahunan tim beranggotakan 8 orang sekitar €1,04 juta (€87 ribu per bulan, €4.000 per hari), sehingga setiap keputusan seperti pengembangan fitur atau penundaan perbaikan memiliki dampak moneter yang jelas
• Baik tim platform internal maupun tim produk yang menghadap pelanggan dapat menghitung titik impas dan tolok ukur penciptaan nilai 3~5x, tetapi hanya sedikit organisasi yang benar-benar melacaknya
• Budaya suku bunga rendah dan berorientasi pertumbuhan selama 20 tahun terakhir melemahkan disiplin finansial, mengubah organisasi besar dan codebase kompleks menjadi liabilitas, bukan aset
• Munculnya LLM menyingkap inefisiensi struktural ini, dan organisasi yang mengukur biaya, nilai, dan profitabilitas per tim secara kuantitatif akan memperoleh keunggulan kompetitif jangka panjang

---

Ekonomi Tim Perangkat Lunak: Mengapa Sebagian Besar Organisasi Engineering ‘Buta’ Secara Finansial

• Menganalisis struktur biaya pengembangan perangkat lunak dan kelayakan ekonomi pada level tim secara angka, serta menunjukkan bahwa sebagian besar organisasi beroperasi tanpa menyadari data ini
• Untuk tim beranggotakan 8 orang, biayanya sekitar €1,04 juta per tahun (€87 ribu per bulan), setara dengan sekitar €4.000 per hari
• Baik tim platform internal maupun tim produk yang menghadap pelanggan dapat menghitung jumlah penciptaan nilai yang dibutuhkan untuk melampaui break-even, tetapi hampir tidak ada organisasi yang benar-benar melacaknya
• Lingkungan suku bunga rendah dan budaya berorientasi pertumbuhan selama 20 tahun terakhir melemahkan disiplin finansial dan membuat organisasi engineering besar serta codebase kompleks disalahartikan sebagai ‘aset’
• Kemunculan LLM (large language model) menyingkap inefisiensi struktural ini, dan organisasi yang mengukur biaya serta penciptaan nilai tiap tim dengan jelas akan meraih keunggulan kompetitif

Struktur Biaya Tim yang Nyata

• Di Eropa Barat, total biaya tahunan per software engineer berada di kisaran €120.000~€150.000, dengan rata-rata €130.000
  • Termasuk gaji, iuran jaminan sosial, pensiun, perangkat, biaya manajemen, ruang kantor, dan lain-lain
• Total biaya tahunan tim beranggotakan 8 orang adalah €1.040.000, atau €86.667 per bulan dan €4.000 per hari
• Bahkan sebagian besar engineer dan manajer tidak mengetahui angka ini, sehingga kesadaran biaya tidak tercermin dalam proses penentuan prioritas
• Setiap keputusan seperti pengembangan fitur, penundaan perbaikan, atau pembangunan ulang platform membawa biaya moneter yang jelas
  • Contoh: pengembangan fitur selama 3 minggu untuk 2% pengguna adalah keputusan senilai sekitar €60.000

Menghitung Break-Even untuk Tim Platform Internal

• Misalkan tim platform beranggotakan 8 orang mendukung 100 engineer
  • Biaya bulanan €87.000, sehingga perlu menciptakan nilai setara untuk menutupinya
• Biaya bulanan per engineer adalah €10.800 (€65 per jam)
  • Untuk 100 orang, break-even tercapai jika menghemat 1.340 jam per bulan (3 jam per minggu per orang)
• Selain penghematan waktu sederhana, pengurangan insiden/gangguan juga dapat langsung melindungi pendapatan
• Namun, sebagian besar tim tidak mengukur angka-angka ini atau memasukkannya ke pengambilan keputusan
• Standar kesehatan finansial yang realistis adalah penciptaan nilai 3~5x (€260 ribu~€430 ribu per bulan)
  • Harus memperhitungkan biaya pemeliharaan/penggantian sistem dan tingkat kegagalan (50~70%)
  • Yang dibutuhkan bukan sekadar ‘break-even’, melainkan profitabilitas yang berkelanjutan

Logika yang Sama untuk Tim Produk yang Menghadap Pelanggan

• Tim beranggotakan 8 orang yang menghadap pelanggan juga memiliki struktur biaya €87.000 per bulan
  • Jika pendapatan per pengguna per bulan adalah €50, maka break-even membutuhkan nilai setara 1.740 pengguna, dan standar 3~5x membutuhkan nilai setara 5.000~8.700 pengguna
• Peningkatan churn adalah tuas yang paling langsung
  • Contoh: dari 50 ribu pengguna, churn bulanan 2% (1.000 orang, kerugian €50.000) → jika penyebabnya dihilangkan, sebagian besar break-even dapat tertutup
• Peningkatan activation rate juga penting
  • Dari 10 ribu pengguna baru per bulan, hanya 30% yang aktif → jika naik 5 poin persentase, ada tambahan 500 konversi, setara €25.000 pendapatan tambahan
• Kenaikan conversion rate memberi efek yang sama
  • Dari 20 ribu pengguna trial, jika konversi naik dari 4% ke 4,5%, ada tambahan 100 pengguna berbayar, setara €5.000 pendapatan tambahan
• Perbaikan kecil pada beberapa metrik dapat terakumulasi menjadi dampak finansial besar, tetapi sebagian besar tim tidak mengukur kaitan antara metrik ini dan hasil finansial

Mengapa Pengukuran Finansial Tidak Dilakukan

• Banyak tim hanya melacak velocity, jumlah tiket, jumlah fitur, NPS, CSAT sebagai metrik aktivitas atau sentimen
  • Ini bukan pengganti metrik finansial, melainkan kategori yang sama sekali berbeda
• Meskipun metrik aktivitas membaik, kinerja finansial bisa memburuk
  • Jumlah fitur meningkat → bisa jadi fitur yang salah
  • Engagement naik → pengguna yang benar-benar berkontribusi ke pendapatan justru bisa menurun
• Metrik ini dipilih karena mudah diukur, dilaporkan, dan dipoles sebagai kinerja
  • Metrik finansial bisa mengungkap kebenaran yang tidak nyaman
• Sebagian besar organisasi tidak secara sengaja membangun budaya pengukuran finansial yang transparan

Latar Belakang 20 Tahun Terakhir

• 2002~2011: suku bunga rendah, tetapi penghindaran risiko oleh investor masih menjaga disiplin finansial
• 2011~2022: kombinasi suku bunga nol, pulihnya selera risiko, dan logika pertumbuhan SaaS
  • Selama 11 tahun, perusahaan dimaafkan atas lonjakan jumlah pegawai, efisiensi rendah, dan prioritas yang salah selama pertumbuhan tetap tinggi
• Generasi pemimpin yang terbentuk pada masa ini tumbuh dalam lingkungan yang tidak menuntut hasil finansial
  • Karena itu, bahkan setelah biaya modal naik sejak 2022, perilaku mereka tidak otomatis menyesuaikan

Liabilitas Organisasi Engineering yang Disalahartikan sebagai ‘Aset’

• Codebase besar dan organisasi engineering secara tradisional dianggap sebagai aset (asset)
  • Seperti akumulasi business logic, fondasi teknis, dan kemampuan organisasi
• Kenyataannya, ini adalah struktur liabilitas (liability) tempat beban pemeliharaan, biaya koordinasi, dan keterlambatan pengambilan keputusan terus menumpuk
  • Kompleksitas yang meningkat menurunkan produktivitas, menaikkan biaya, dan menahan pertumbuhan pendapatan
• Di masa lalu, lingkungan suku bunga rendah menutupi liabilitas ini

• Realitas yang Disingkap LLM

  • Developer Nathan Cavaglione menggunakan agen LLM untuk mereplikasi 95% fitur inti Slack hanya dalam 14 hari
  • Slack dibangun oleh ribuan engineer selama lebih dari 10 tahun, dengan investasi bernilai miliaran euro
  • Nathan menyelesaikan produk serupa dalam waktu singkat tanpa kompleksitas organisasi, arsitektur lama, atau biaya koordinasi
  • Ini menunjukkan bahwa asumsi lama bahwa skala, kompleksitas, dan akumulasi code dalam organisasi besar adalah keunggulan kompetitif tidak lagi berlaku
  • Masalah maintainability pada code hasil LLM memang ada, tetapi dalam lingkungan agent-to-agent, pendekatan itu lebih unggul dalam biaya dan kecepatan dibanding pemeliharaan oleh manusia

Syarat Organisasi yang Akan Unggul ke Depan

• Inti daya saing adalah kemampuan analitis, bukan teknologi semata
  • Organisasi yang memahami dengan jelas biaya, nilai, dan ambang profitabilitas tiap tim akan unggul secara struktural
• Organisasi seperti ini dapat:
  • Membuat keputusan Build vs Buy berdasarkan ekonomi yang nyata
  • Mengidentifikasi tim yang berada di bawah batas profitabilitas
  • Mengukur hilangnya nilai akibat keterlambatan untuk menyesuaikan prioritas
• Saat ini, sebagian besar organisasi belum memiliki infrastruktur pengukuran, aliran data, dan kebiasaan yang diperlukan
  • Proses membangunnya tidak nyaman, tetapi wajib dilakukan
  • Organisasi bisa menemukan bahwa tim telah menghabiskan satu kuartal penuh untuk pekerjaan yang tidak punya kaitan finansial
• Di masa lalu, suku bunga rendah dan logika pertumbuhan menoleransi hal ini, tetapi dalam lingkungan biaya pengembangan yang turun drastis karena AI dan investor yang menuntut hasil finansial, kondisi itu tidak berkelanjutan
• Organisasi yang memiliki kebiasaan untuk secara jelas menanyakan dan mengukur ekonomi pada level tim akan mengumpulkan keunggulan kompetitif berbentuk compounding seiring waktu

[GN⁺]

Komentar Hacker News

• Inti tulisan ini adalah bahwa pemrograman itu sendiri bukan bagian yang sulit, melainkan mencari tahu apa yang harus diprogram itulah bagian yang benar-benar sulit
  Dalam praktiknya, sebagian besar pekerjaan adalah menjelajahi ruang masalah dengan terlebih dulu membuat hal yang salah lalu menggantinya berulang kali
  Pemrograman sering kali bukan hasil akhir, melainkan lebih merupakan sarana untuk memperjelas definisi masalah

  • Menurut saya ini tidak selalu benar. Ada proyek yang sudah jelas apa yang harus dibuat, tetapi tingkat kesulitan rekayasanya sendiri sangat tinggi
    Jika hanya menggabungkan framework mungkin mudah, tetapi di lingkungan yang menangani sistem kompleks, pemrograman itu sendiri benar-benar sulit
  • Banyak perangkat lunak justru tidak menciptakan nilai, malah menguranginya
    Saya sering melihat permintaan sederhana berkembang menjadi sistem raksasa. Namun seperti Google, jika berinvestasi secara cerdas pada infrastruktur, itu juga bisa menjadi keunggulan kompetitif
  • Konsep ini juga ada di area selain engineering. Seperti ungkapan di internet, “kalau mengunggah jawaban yang salah, jawaban yang benar akan datang lebih cepat”, percobaan yang salah kadang justru memberi wawasan yang lebih baik
    Namun pendekatan seperti ini sering terlihat tidak produktif, atau mudah disalahpahami sebagai “orang yang mengatakan hal yang salah”
  • Mungkin pemrograman bukan hal yang paling sulit, tetapi kita juga tidak boleh lupa bahwa ini tetap bukan pekerjaan yang mudah
  • Ini mungkin benar untuk developer junior, tetapi engineer berpengalaman sudah tahu cara membangun dengan efisien
    Banyak developer keliru mengira proyek mereka istimewa, padahal sering kali cukup menyalin desain yang sudah teruji

• Seperti yang dikatakan tulisan itu, kekhawatiran bahwa kode yang dihasilkan cepat akan sulit dikelola memang masuk akal, tetapi dianggap kurang penting selama tidak dipelihara manusia
  Namun menurut saya logika itu juga bisa diterapkan pada “LLM agile coach”. LLM sudah bisa memberi sebagian besar insight dengan biaya jauh lebih murah
  Pada akhirnya manusia mungkin bisa santai di tepi kolam

  • Jika AGI menggantikan pekerjaan saya, saya tetap akan menangani verifikasi dan tanggung jawab. Jika lapisan manajemen hilang, mungkin justru akan lebih damai
  • Belakangan ini kebanyakan tulisan tentang LLM terasa seperti ditulis oleh LLM. Materi pelatihan yang dijual pun sepertinya bisa digantikan dengan satu baris prompt
  • Sekarang kita hidup di masa ketika biaya belajar nyaris nol, dan instruktur hanya berperan memaksa proses belajar

• Saya tidak setuju dengan klaim bahwa “meski codebase berantakan, kalau memasukkan banyak agen semuanya akan beres”
  Dalam praktiknya, banyak kode yang dari luar tampak sempurna tetapi secara internal cacat secara struktural seperti bangunan dari busa
  Kode seperti ini lama-lama tidak bisa dikembangkan lagi dan akhirnya mengeras seperti batu bata

  • Jika ada desain arsitektur dan guardrail yang memadai, agen juga bisa bekerja dengan baik. Jika tidak, pengawasan teliti dari manusia itu wajib
  • Kalau agen menulis kode yang terlalu “cerdas”, lalu siapa yang akan menangani debugging?
  • Ungkapan “seni menopang beban” benar-benar mengesankan
  • Manajemen yang percaya AI akan menyelesaikan semuanya adalah kesalahpahaman yang berbahaya. Ini tidak bisa diselesaikan hanya dengan computing power
  • Kalau masalah seperti ini muncul, bukankah itu berarti ada yang kurang dari sistem pengujiannya sendiri?

• Saya juga punya pengalaman dua proyek buatan AI gagal total
  Menambah lebih banyak agen pun tidak membawa kemajuan, dan hasil yang dibuat kebanyakan mengarah ke arah yang salah

  • Saya juga punya pengalaman serupa. Saya menghapus lebih dari 40 ribu baris kode. Kode buatan AI hampir selalu memakai abstraksi yang salah
  • Ini terasa seperti semacam fenomena Mythical Machine Month. Menambah mesin alih-alih manusia juga tidak menaikkan produktivitas
  • Saat berurusan dengan AI, saya sering melihat pola yang mirip dengan kegagalan perhatian pada manusia. Pada akhirnya ini soal konteks dan fokus
  • Kepemilikan kode tetap berada pada manusia. Fakta bahwa AI yang membuatnya tidak menghapus tanggung jawab itu
  • Cara AI terjebak dalam utang teknis tidak jauh berbeda dari manusia. Hanya saja ada potensi sebagai alat yang mempermudah rewrite

• Saya setuju dengan klaim bahwa “pengembangan perangkat lunak adalah aktivitas yang padat modal”, tetapi konteksnya berbeda di tiap industri
  Perusahaan listrik atau pabrikan punya biaya pemeliharaan infrastruktur fisik yang jauh lebih besar daripada IT
  Namun karena kontrak SaaS makin banyak, semakin banyak perusahaan yang bertanya-tanya apakah mempekerjakan developer LLM lebih ekonomis

  • Bahkan di lembaga publik seperti otoritas transportasi, mulai muncul kesadaran bahwa pengeluaran SaaS sudah berlebihan. Pada akhirnya, jika manajemen menyadarinya, banyak kontrak yang tidak perlu akan dibereskan
  • Tetapi SaaS tidak akan hilang sepenuhnya. Dibutuhkan struktur yang bisa menangani akuntabilitas dan risiko hukum
  • Biaya pembangunan pabrik farmasi bisa mencapai miliaran dolar. Di industri seperti ini, biaya perangkat lunak nyaris tidak berarti

• Saya membaca tulisan ini dengan tertarik, lalu kehilangan kepercayaan pada contoh tiruan Slack
  Itu adalah klaim yang sama sekali tidak memahami skala, stabilitas, dan fungsionalitas Slack yang sebenarnya

  • Slack bukan produk yang bisa sekadar disalin. Itu adalah hasil dari banyak trial and error dan akumulasi insting produk
  • Begitu melihat istilah “tiruan 95%”, kepercayaan saya langsung runtuh
  • Mahasiswa pun bisa membuat klon Twitter, tetapi pesaing sesungguhnya bukanlah kodenya melainkan pasar dan ekosistem
  • Saya juga bisa membuat klon Slack dalam 2 minggu, tetapi hanya untuk mengimplementasikan fitur legal hold dengan benar saja bisa butuh beberapa bulan
    Untuk produk enterprise, ratusan fitur detail seperti ini wajib ada. Menyalin secara sederhana bukanlah kompetisi
  • Membuat Slack bukan sekadar menulis kode, melainkan proses menemukan apa yang harus dibuat

• Tulisan yang hanya melempar banyak angka dan grafik terlihat seperti tulisan dari orang yang ingin menang debat
  Seperti kata Rory Sutherland, “Finance People” terobsesi pada kepastian dan prediktabilitas
  Tetapi dunia tidak sesederhana itu

  • Perhitungan yang presisi membantu memecah masalah sebagai efek samping. Namun pada akhirnya yang menaklukkan pasar adalah pemahaman masalah yang mendalam dan visi
  • Matematikanya tidak cocok dengan kenyataan. Keberhasilan produk tidak bisa diprediksi, dan investasi itu sendiri adalah perjudian
  • Kebenaran selalu ada di suatu titik di tengah. Diperlukan keseimbangan antara angka dan insting
  • Tim yang memiliki alat ukur dan metrik yang tepat akan memberi hasil lebih baik dalam jangka panjang
  • Meski begitu, setidaknya harus ada hipotesis tentang bagaimana sebuah fitur akan memengaruhi pendapatan agar bisnis bisa berkelanjutan

• Lebih dari detail tulisannya, saya setuju dengan gagasan tentang budaya engineering yang tidak memikirkan nilai dibanding biaya
  Dalam rapat atau saat menangani insiden, sering kali diambil tindakan berlebihan tanpa menimbang efektivitas dibanding biaya
  Hal yang sama berlaku untuk utang teknis: tanpa mengetahui biayanya, kita tidak bisa membuat pilihan yang bertanggung jawab

  • Pemborosan yang lebih besar daripada rapat adalah proyek atau fitur yang salah. Mereka terus membawa beban pemeliharaan dan kompleksitas tanpa akhir

• Perhitungan sederhana bahwa “tim platform harus membuktikan nilainya lewat penghematan waktu” itu salah
  Tim platform tidak sekadar menghemat waktu, tetapi juga mengurangi risiko bisnis dan menjamin kualitas inti

  • Alasan keberadaan tim platform adalah untuk memusatkan upaya yang berulang dan menjaga pemisahan antara keamanan dan operasi
    Ini bukan sekadar logika ekonomi, melainkan soal infrastruktur organisasi yang esensial

• Pada akhirnya, yang penting adalah apakah tim benar-benar peduli pada produknya
  Hanya tim yang menganggap produk itu sendiri lebih penting daripada karier jangka pendek yang bisa melampaui metrik atau teknik manajemen dan menghasilkan pencapaian nyata
  Namun ada proyek yang sejak awal memiliki struktur yang sulit untuk dicintai, sehingga batas produktivitasnya jelas