- Kehidupan sehari-hari dan lintasan karier engineer sangat dipengaruhi oleh dari anggaran mana gaji mereka dibayarkan: penjualan/pemasaran, R&D, atau pemeliharaan
- Rekayasa yang dibiayai anggaran penjualan/pemasaran paling dekat dengan uang dan mudah diukur hasilnya, tetapi dapat berujung pada budaya stack ranking dan persaingan internal
- Anggaran R&D mempekerjakan engineer paling banyak di bawah organisasi produk, serta lebih menekankan nilai jangka panjang dan pembentukan aset selama lebih dari satu kuartal daripada eksperimen jangka pendek
- Anggaran pemeliharaan diperlakukan sebagai sasaran optimasi biaya; sysadmin, operasi sistem lama, sebagian platform engineering, dan pekerjaan alat internal bisa masuk ke sini
- Jika Anda tahu pekerjaan Anda termasuk anggaran yang mana, Anda bisa memasukkan perubahan yang sering dalam pekerjaan growth, investasi jangka panjang di R&D, dan rendahnya prioritas pemeliharaan ke dalam pertimbangan karier
Tiga anggaran membagi pekerjaan engineering
- Gaji rekayasa perangkat lunak pada dasarnya berasal dari salah satu dari tiga anggaran
- penjualan/pemasaran
- penelitian dan pengembangan
- pemeliharaan
- Sifat anggaran tersebut memengaruhi cara kerja sehari-hari engineer dan arah karier mereka
- Pembedaan ini bisa berguna saat memikirkan visi karier atau positioning
Anggaran penjualan/pemasaran: hasil langsung yang bisa diukur
- Rekayasa yang berada dalam organisasi growth relatif mudah dikuantifikasi hasilnya
- Cukup jelas pekerjaan seperti apa yang akan menaikkan angka
- Kategori ini mencakup peran seperti growth engineer, sales engineer, dan devrel
- membuat produk yang ada lebih mudah dijual
- membuat orang mengetahui fitur
- membantu pembeli mengadopsi alat ke dalam alur kerja mereka
- Yang diharapkan perusahaan adalah dampak langsung
- Kelebihannya adalah return on investment mudah dipahami, dan pekerjaan terhubung langsung ke pendapatan
- Karena mudah diukur, perbandingan antarkaryawan juga jadi mudah
- stack ranking antarkaryawan bisa muncul
- budaya persaingan internal bisa lebih kuat daripada budaya memecahkan masalah bersama
- Ritme kerja umumnya berpusat pada jangka pendek
- eksperimen berikutnya
- pelanggan berikutnya
- terus mengejar tren pemasaran berikutnya
- Perusahaan menilai nilainya berdasarkan kelipatan yang dihasilkan uang yang dimasukkan ke anggaran ini, dan dalam proses optimasi dapat muncul efek pintu putar
Anggaran R&D: aset yang menumpuk seiring waktu
- Penelitian dan pengembangan, yaitu R&D, adalah area yang mempekerjakan engineer paling banyak
- biasanya berada di bawah organisasi produk
- di perusahaan yang lebih besar bisa ada organisasi riset atau sains yang benar-benar terpisah
- Kategori ini mencakup peran seperti product engineer, researcher, dan architect
- membuat apa yang dijual perusahaan
- atau mengeksplorasi apa yang mungkin bisa dijual perusahaan jika berhasil berjalan baik
- Yang diharapkan perusahaan adalah pertumbuhan seiring waktu
- Lingkungannya relatif lebih tenang
- menyeimbangkan antara mempertahankan pengguna lama dan membuat fitur untuk menarik pengguna baru
- bisa condong ke growth dengan membuat fitur yang meningkatkan aktivasi setelah pendaftaran hingga benar-benar dipakai
- kadang juga condong ke riset saat mengeksplorasi lini produk baru
- Di perusahaan yang memiliki departemen riset yang matang, ada juga orang-orang yang menangani ide yang tidak akan menjadi produk selama beberapa tahun
- R&D pada praktiknya adalah bentuk dua anggaran yang berbeda tetapi digabungkan dalam satu kategori
- pengembangan dan riset itu berbeda
- tetapi kesamaannya adalah fokus pada hasil jangka panjang
- Jangka waktu terpendek yang diperhatikan adalah skala kuartalan
- Pekerjaan engineer dirancang menjadi aset yang memberikan nilai selama beberapa tahun ke depan
- eksperimen yang lebih pendek hanyalah batu loncatan dalam proses itu
- Pengukuran hasilnya memang sulit, tetapi perusahaan memandang pekerjaan ini sebagai investasi
- dengan asumsi bahwa semakin baik produknya, semakin baik pula penjualan dan retensinya
Anggaran pemeliharaan: biaya yang ingin ditekan
- Pemeliharaan pada umumnya selama ini diserap ke dalam pekerjaan pengembangan
- Yang diinginkan anggaran ini adalah optimasi biaya
- sysadmin, orang yang terus menjalankan sistem lama, dan kadang platform engineer masuk ke kategori ini
- Perusahaan melihat pekerjaan ini sebagai biaya murni dan ingin meminimalkannya
- Di banyak perusahaan, peran pemeliharaan tersebar di dalam pengembangan produk
- pekerjaan ini tidak dinilai penting
- tetapi ketika seseorang sudah cukup terganggu, akhirnya tetap akan ditangani
- Perusahaan kadang membungkus pemberian waktu kepada engineer untuk menangani NFR, yaitu non-functional requirements, seolah-olah itu manfaat istimewa
- misalnya situasi ketika setiap sprint diberi 2 hari untuk menangani hal-hal yang mengganggu
- Pembuatan alat internal juga bisa masuk ke kategori ini
- ada dashboard admin yang membuat perusahaan bisa berjalan
- tetapi sering kali tidak pernah mendapat prioritas yang cukup
Sinyal posisi anggaran terhadap keputusan karier
- Jenis anggaran tempat suatu pekerjaan berada menentukan pengalaman sehari-hari engineer
- Pekerjaan growth terukur dan sering berubah
- Pekerjaan riset lebih tenang tetapi hasilnya kabur
- Pekerjaan pengembangan dihargai dan terus menumpuk nilainya seiring waktu
- Pekerjaan pemeliharaan diperlakukan sebagai sesuatu yang bisa dipangkas kapan saja
1 komentar
Komentar Hacker News
Bukan hanya dari pos anggaran mana gaji tahunanmu berasal; memahami bagaimana organisasi menilai pengembangan software juga sangat memengaruhi karier
Jika perusahaannya adalah firma konsultansi yang menjual waktu pengembangan, yang dihargai adalah kemampuan membangun hubungan dengan klien dan kemampuan membuat software yang cukup baik dengan cepat; jika perusahaannya adalah perusahaan produk yang menjual produk software, yang dihargai adalah kemampuan membuat dan mengoperasikan software
Jika bisnisnya adalah bisnis lain yang sebagian melibatkan software atau dimungkinkan oleh software, yang dihargai adalah kemampuan mengirimkan dalam batas anggaran, tetapi sulit menjadi pemeran utama di panggung
Menariknya, pembagian ini cocok dengan tiga kategori yang disebut penulis: konsultansi sesuai dengan penjualan/pemasaran, produk dengan R&D, dan sisanya dengan pemeliharaan
Saat menjadi engineer senior di startup software, ada perlakuan seperti bintang, stock option, dan budaya kantor yang bisa diharapkan; ketika menjadi konsultan senior di perusahaan konsultansi IT, saya harus lebih mirip salesperson yang pandai memakai PowerPoint
Saya harus memaksimalkan jam yang bisa ditagihkan, dan tidak boleh menyelesaikan proyek terlalu cepat atau dengan kode seminimal mungkin
Kira-kira bisa ditebak saya sekarang ada di mana
Ini bukan sesuatu yang bisa dibeli sebagai produk siap pakai; biasanya bentuknya beberapa sistem yang sangat dikustomisasi lalu dipaksa saling terhubung, dan sering kali awalnya tidak dirancang untuk bekerja bersama
Cara tiap perusahaan juga berbeda
Saya menikmati pekerjaan ini, dan kuat dalam memikirkan keseluruhan sistem yang melintasi banyak departemen
Untuk menembus masalah, pengetahuan tentang politik internal juga diperlukan, dan tepat di titik itulah nilai saya muncul
Sebagai programmer saya juga cukup baik, tetapi tidak sampai menyamai keahlian orang yang menjadikan programming sebagai karier
Dalam dua kasus lainnya, kamu menjadi biaya yang harus diminimalkan atau dihilangkan
Hanya ketika membuat produk inti perusahaanlah kamu menjadi aset yang mendatangkan pendapatan
Saya juga pernah melakukan kesalahan itu, dipanggil rapat dan ditanya “bagaimana perkembangannya”, lalu segera diberi tahu “jangan jelaskan detailnya”
Bekerja di nomor 3 berarti membuat solusi yang membosankan dan mudah dilupakan, dan bisa saja menghasilkan solusi yang secara teknis masuk akal tetapi secara politik merupakan tindakan bunuh diri
Misalnya, jika bekerja di produsen hardware, jangankan menjadi pemeran utama, dihormati saja sulit
Tenaga software dianggap sebagai biaya, bahkan biaya yang sebisa mungkin tidak ingin dikeluarkan
Meski mengirimkan tepat waktu dengan biaya di bawah anggaran, kamu tidak akan menonjol; justru menghilang dari perhatian
Sulit memahami pernyataan bahwa dalam budaya teknologi modern, pemeliharaan selalu berada di urutan paling bawah, anggarannya dipotong, dan tidak pernah mendapat anggaran yang layak
Selama 20 tahun bekerja di berbagai perusahaan, saya terus mendengar pernyataan seperti itu, tetapi hampir tidak pernah setuju
Perusahaan memang menginginkan fitur baru untuk dibawa ke pasar, tetapi pada saat yang sama mereka juga ingin layanan berjalan dengan benar
Bahkan saat PHK atau pembekuan rekrutmen, saya melihat organisasi yang bersifat SRE lebih mampu bertahan dibanding organisasi riset dan pengembangan
Namun di satu perusahaan, budayanya berubah menjadi terus membuat hal baru dan tidak memberi penghargaan untuk mempertahankan yang sudah ada; akibatnya ada migrasi terus-menerus atas tool internal, penghentian yang berulang, dan migrasi yang setengah jadi
Setelah orang-orang yang membuat produk dipromosikan lalu pergi mengerjakan portofolio berikutnya, sesuatu yang tadinya baru dan berkilau pun segera terbengkalai, lalu tim baru membuat penggantinya lagi
Dalam 6 tahun, satu tool internal diganti empat kali dengan tool internal baru, dan pengguna tersebar di empat tool
Itu bisa saja disebut sekadar kegagalan eksekusi, tetapi budaya yang mengatakan bahwa bisnis tidak memandang pemeliharaan sebagai sesuatu yang bernilai sangat berbahaya dan berujung merusak diri sendiri
Misalkan setiap kali developer menambahkan fitur baru, ia memakai ruang disk senilai 1.000 dolar dan menghasilkan pendapatan baru 10.000 dolar
System administrator membeli file server besar, dan katakanlah satu server baru harganya 500.000 dolar
Dalam organisasi yang birokratis, system administrator menagih biaya ruang disk secara internal kepada developer, dan ketika file server baru dibutuhkan, uangnya sudah tersedia
Dalam organisasi yang dikelola dengan baik dan tidak terlalu birokratis, manajemen memahami bahwa tagihan 500.000 dolar itu memungkinkan proyek yang akan mengembalikan 5 juta dolar, lalu dengan senang hati membayarnya
Dalam organisasi yang dikelola buruk, manajemen panik karena 500.000 dolar dianggap mahal dan tidak terkait dengan proyek tertentu; system administrator kemudian meminta orang berikutnya yang membutuhkan ruang disk senilai 1.000 dolar untuk membayar 500.000 dolar, dan orang itu menolak
Akhirnya system administrator menolak permintaan tersebut dan membujuk developer untuk mengurangi retensi log dari 7 hari menjadi 3 hari; tanpa terasa, manajemen mulai mendengar umpan balik buruk tentang system administrator
Lingkungan yang dijelaskan justru tampak seperti kenyataan bahwa bisnis tidak memandang pemeliharaan sebagai sesuatu yang bernilai
Ungkapan “pemeliharaan berada di urutan paling bawah” lebih merupakan deskripsi tentang apa yang benar-benar terjadi, bukan resep bahwa memang harus begitu
Penulis memang tidak menganalisis mengapa demikian, atau apakah pendekatan lain lebih baik bagi bisnis, tetapi jika sesuatu yang berfungsi dengan benar dan berkualitas tinggi dianggap bernilai, tentu kita mengharapkan hasil yang berbeda
Namun jika hanya sangat sedikit perusahaan yang bertindak demikian, kemungkinan besar ada alasan terkait penyelarasan kepentingan
Sebab, pemeliharaan tidak bisa dijual kepada pelanggan; yang bisa dijual hanyalah fitur
Dari sisi developer pun, pemeliharaan adalah pekerjaan yang ingin dihindari
Sulit memasukkan pemeliharaan sebagai poin yang tampak berkilau di CV, dan semua orang ingin melihat capaian, proyek yang diluncurkan, serta teknologi modern
Menjaga layanan tetap berjalan pada level yang diminta pelanggan adalah prioritas tinggi bagi semua orang
Tidak ada perusahaan yang ingin memangkas SRE sampai pelanggan pergi karena outage
Namun SRE lebih dekat dengan operasi di perusahaan tradisional, yaitu fungsi yang tidak bisa dihindari jika ingin menyediakan layanan, dan berbeda dari pemeliharaan yang sebisa mungkin ditunda
Dari sudut pandang ini, pemeliharaan adalah hal-hal seperti mengurangi technical debt, memperbaiki tool internal, dan memperpendek waktu iterasi eksperimen; pekerjaan seperti ini menurut saya sering diremehkan dibanding dampaknya terhadap produk
Tulisan ini membahas yang kedua, dan mengatakan bahwa masuk ke kategori nomor 3 adalah bunuh diri karier
Jika Anda bukan tipe orang “naik jabatan atau keluar”, menghabiskan waktu di nomor 3 mungkin masih bisa dipertimbangkan
Tentu saja karena software mulai menua begitu dipakai, orang-orang yang merasa dirinya berada di nomor 2 pun sebenarnya mungkin menghabiskan sebagian besar waktunya di nomor 3 dan hanya sebagian sangat kecil di nomor 2
Namun anggaran dialokasikan setahun sekali, paling banyak beberapa kali, jadi jika pada saat itu Anda berada di tempat yang diklasifikasikan sebagai nomor 2, posisi Anda tetap lebih baik
“Sales/marketing” dan “riset dan pengembangan” adalah kategori yang bisa ditemukan dalam laporan tahunan perusahaan, tetapi pemeliharaan tidak muncul dengan cara seperti itu
Sebaiknya baca laporan keuangan perusahaan
Anda akan melihat pos-pos seperti “harga pokok penjualan” atau COGS, “biaya umum dan administrasi”, serta biaya satu kali seperti merger dan akuisisi; tiap pos memiliki dinamika yang berbeda dan bekerja secara berbeda pula di tiap perusahaan
Memahami struktur bisnis industri tempat Anda berada juga penting
Bahkan di thread ini, ada banyak kasus orang menilai sebuah perusahaan “tidak menghargai” software engineering, tetapi naif jika membandingkan perusahaan media sosial dengan gross margin 70% dengan perusahaan otomotif atau penerbangan di kisaran 15–20%
Wajar jika satu industri mampu merekrut lebih banyak engineer, membayar lebih tinggi, serta menyediakan lebih banyak merchandise dan benefit
Bahkan di perusahaan yang sama, sebagian lini produk dan fitur mendapat investasi jangka panjang, sementara sebagian lini produk memiliki margin lebih tinggi daripada yang lain
Jumlah uang yang bisa dibelanjakan untuk produk software sangat berbeda tergantung anggaran
Engineer perlu melihat keuangan perusahaan saat memikirkan pekerjaannya sendiri
Perusahaan bukan badan amal atau gereja, melainkan bisnis yang harus menyeimbangkan arus kas, pendapatan, strategi jangka panjang, dan biaya pengembangan produk
Tulisan ini juga bagus, tetapi tulisan patio11 juga menjelaskannya dengan baik melalui pembagian cost center dan profit center
Ia menjelaskan dengan meyakinkan mengapa Anda harus menempel pada profit center, dan jika belum membacanya, ada banyak isi bagus lainnya juga
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Aturan nomor 2 adalah mengambil peran di dalam profit center itu yang terhubung secara berkelanjutan dan dapat dipercaya dengan profitabilitas
Tidak harus berarti saya sendiri yang langsung menghasilkan uang, tetapi harus jelas bahwa jika saya berhenti bekerja, uang akan terdampak secara langsung
Sedikit menyimpang, tetapi saya membaca Serverless Handbook yang ditulis Swizec beberapa tahun lalu dan merasa itu sangat berguna; selama lama saya juga menikmati newsletter emailnya yang penuh pertimbangan dan insight
Ia berdiri kokoh di kubu “belajar sambil melakukan / belajar secara terbuka”, dan sangat baik dalam membagikan proses belajarnya
Saya sangat merekomendasikan untuk mengikuti atau berlangganan kepadanya
Secara historis, rekayasa perangkat lunak adalah bagian dari fungsi TI, dan TI berawal dari akuntansi
Sebelum mesin melakukannya, “computer” secara harfiah adalah pekerjaan seseorang
Hingga kini pun, di banyak bisnis, akuntansi masih menjadi pendorong utama perangkat lunak sekaligus sumber anggarannya
Dalam praktiknya ada empat kategori anggaran
Nomor 1 adalah riset dan pengembangan, yang biasanya mendapat perlakuan pajak khusus dan kredit pajak
Nomor 2 adalah penjualan/pemasaran, yang mencakup engineer pra-penjualan dan kadang pekerjaan implementasi
Nomor 3 adalah pemeliharaan, yaitu developer yang memperbaiki bug dan mengerjakan kode non-riset-dan-pengembangan yang biasanya tidak mendapat perlakuan pajak khusus atau kredit pajak
Nomor 4 adalah operasi pada layanan hosting, PaaS, dan SaaS, yang biasanya mencakup sebagian gaji software engineer
Memahami implikasi pajak berdasarkan dari anggaran mana uang berasal dan pekerjaan apa yang dilakukan sangatlah penting, dan akan menjadi jauh lebih rumit seiring bertambahnya skala
Saya rasa model pusat laba vs pusat biaya lebih baik
Idealnya semua departemen bertanggung jawab atas pendapatan dan biaya sekaligus
Jika tidak bisa diukur, itu masalah KPI
KPI bisa saja salah selaras karena terlalu berfokus pada biaya, tetapi itu tidak membuat departemen tersebut menjadi pusat biaya
Namun saya suka adanya tambahan pembedaan riset dan pengembangan
Tim yang berfokus pada pemeliharaan pun harus melakukan riset dan pengembangan untuk menurunkan biaya pemeliharaan, sama seperti tim penjualan yang baik melakukan riset dan pengembangan untuk meningkatkan laba penjualan
Keduanya memberi wawasan yang berbeda dan bisa saling melengkapi
Di perusahaan-perusahaan tempat saya bekerja, tidak ada gaji growth engineering yang berasal dari anggaran pemasaran
Tidak ada juga yang disebut “anggaran pemeliharaan” terpisah; semuanya hanya riset dan pengembangan/engineering
Ekspektasi bisa sangat berbeda tergantung tim atau peran, tetapi itu bukan soal anggaran, melainkan bergantung pada bagaimana perusahaan melacak tujuannya
Pilihannya adalah menghasilkan uang sekarang, menciptakan nilai jangka panjang, atau perlahan tenggelam bersama produk yang sudah ada