Pengalaman Enterprise

• Setelah bekerja selama 1 tahun di perusahaan besar, saya merasakan perbedaan yang sangat mencolok dibanding lingkungan startup, SME yang pernah saya jalani
• Ketika pelacakan pihak yang bertanggung jawab dan proses internal menjadi kompleks, hal-hal yang tidak menjadi masalah di organisasi kecil berubah menjadi persoalan yang mustahil diselesaikan
• Pemborosan sumber daya dan ketimpangan standar perekrutan menimbulkan masalah pada efisiensi organisasi dan motivasi kerja
• Konsep penting dalam organisasi seperti urgensi pekerjaan, pengelolaan keamanan berubah menjadi tindakan yang formal dan prosedural, berbeda dari makna sebenarnya
• Di tengah berbagai masalah, saya juga menemukan pengalaman positif seperti pengembangan kemampuan, pertumbuhan karier

---

Refleksi 1 Tahun Pengalaman Enterprise

Perbedaan antara perusahaan besar dan startup

• Menghabiskan tahun pertama di $ENTERPRISE membuat saya mengalami langsung perbedaan dengan startup dan SME (usaha kecil dan menengah) yang pernah saya jalani sebelumnya.
• Belakangan saya menyadari bahwa kurangnya pengalaman dalam pengembangan perangkat lunak internal bukanlah bahan kritik, melainkan justru sinyal positif.
• Saya merangkum hal-hal yang saya amati untuk memperkenalkan realitas lingkungan kerja di perusahaan besar.

Hal yang tidak bermasalah di perusahaan kecil berubah menjadi masalah besar di perusahaan besar

• Saat menyelesaikan error terkait tool, mengidentifikasi penanggung jawab atau orang yang menangani bisa memakan waktu sangat lama.
• Kurangnya berbagi informasi di dalam organisasi serta pergantian penanggung jawab menyebabkan inefisiensi dan pemborosan biaya.
• Solusi sementara adalah override pengaturan lokal, tetapi pada dasarnya ini adalah keterbatasan struktural organisasi.

Ketidakrasionalan dalam alokasi sumber daya

• Berbeda dengan pengalaman bekerja di perusahaan kecil dengan anggaran yang tidak memadai, di perusahaan besar pemborosan sumber daya yang berlebihan sering terjadi.
• Kegagalan proyek jangka pendek, penggunaan cloud yang tidak perlu, dan hal serupa berujung pada pemborosan finansial.
• Pengelolaan anggaran dan sumber daya yang tidak selaras dengan kebutuhan nyata menurunkan motivasi kerja.

Rekan kerja dan struktur perekrutan yang tidak konsisten

• Di startup, perekrutan berbasis kemampuan relatif mempertahankan standar yang konsisten.
• Di perusahaan besar, perekrutan dan restrukturisasi yang tidak berkaitan dengan kemampuan adalah hal yang umum.
• Muncul fenomena ketika posisi tertentu tidak berkaitan dengan kemampuan kerja, atau organisasi tetap berjalan terlepas dari kualitas laporan.

Penafsiran terhadap urgensi pekerjaan

• Di startup, urgensi yang jelas menjadi patokan, tetapi di perusahaan besar diperlukan penafsiran atas makna pekerjaan yang berlapis-lapis.
• Selain situasi yang benar-benar mendesak (misalnya gangguan layanan), urgensi formal juga sering muncul.
• Dalam prosedur seperti ini, dibutuhkan kemampuan untuk memahami prioritas kerja yang sebenarnya.

Pengelolaan keamanan yang terformalisasi

• Proses keamanan memainkan peran penting dalam organisasi, tetapi dalam praktiknya lebih berfokus pada pelaporan formal dibanding risiko nyata.
• Demi mencapai target angka atau metrik, pekerjaan keamanan yang maknanya sudah memudar menjadi hal yang lumrah sehari-hari.
• Ada pula inefisiensi dalam komunikasi antara engineer dan pihak yang bertanggung jawab atas keamanan.
• Ditekankan bahwa budaya di mana semua orang hanya mementingkan angka adalah sesuatu yang berbahaya.

Ketidakbermaknaan jabatan

• Jabatan yang tumpang tindih seperti "Head of Architecture" lazim ditemukan, dan perannya tidak jelas.

Budaya organisasi yang menganggap ketidakpastian sebagai kelemahan

• Di tengah perombakan organisasi skala besar dan restrukturisasi yang sering terjadi, para pemimpin menganggap ucapan "saya tidak tahu" sebagai hal yang tabu.
• Meski domainnya kompleks, dalam kepemimpinan hanya kecepatan respons dan rasa percaya diri yang diprioritaskan.
• Akibatnya, struktur yang membuat kesalahan masa lalu terus terulang menjadi semakin mengakar.

Tim engineering yang tersilo

• Masing-masing tim engineering (atau "kerajaan") memiliki standar dan budayanya sendiri.
• Hambatan antarbagian membesar, sehingga standardisasi maupun penyebaran best practice menjadi sulit.
• Otonomi tiap divisi menjadi faktor yang membatasi kolaborasi antartim.

Pengalaman positif

• Melalui partisipasi dalam komunitas engineer, saya mengalami perluasan perspektif terhadap pengembangan perangkat lunak.
• Ada kepuasan baru dalam hal pertumbuhan karier, kesempatan mentoring, pengalaman menangani skala penggunaan besar.
• Pendalaman keahlian, kolaborasi dengan rekan kerja yang beragam, serta pelatihan dan pengembangan kemampuan didorong secara aktif.
• Stabilitas seperti pembayaran gaji yang teratur dan jaminan peran kerja juga menjadi keunggulan.

Kesimpulan

• Terlepas dari sudut pandang yang kritis, nilai positif perusahaan besar tetap jelas.
• Ada niat untuk meninjau kembali perspektif yang telah berubah ini setelah waktu yang lama berlalu.

[GN⁺]

Komentar Hacker News

• Kita harus selalu mengingat Remy's Law of Enterprise Software (tautan terkait: https://thedailywtf.com/articles/graceful-depredations). Jika sebuah software disebut "enterprise", biasanya itu pertanda kurang bagus. Terlepas dari candaan itu, saya tertarik melihat poin-poin positif yang disebutkan di bagian akhir tulisan. Beberapa saya pahami, tetapi ada juga yang dalam praktiknya tampak hanya menambah lebih banyak masalah. Misalnya ada poin "ada peluang pengembangan karier yang nyata"; kalau pengembangan karier itu hanya berarti menghasilkan lebih banyak uang, menurut saya lebih baik bilang saja "bisa menghasilkan lebih banyak uang", tidak perlu diputar-putar. Kalau bukan itu maksudnya, saya jadi penasaran pengembangan karier itu sebenarnya apa, selain makin terbenam dalam inefisiensi dan masalah organisasi yang tadi sudah dibahas. Lalu soal "membangun software yang digunakan jutaan orang itu memuaskan", saya juga bertanya-tanya apakah itu tetap memuaskan jika software tersebut buruk atau merugikan penggunanya

  • Menanggapi pertanyaan apakah pengembangan karier hanya soal menghasilkan lebih banyak uang, kalau kita memikirkan hidup cukup lama pada akhirnya kita akan berhadapan dengan kenyataan bahwa kita hanya memegang peran kecil dalam sistem yang jauh lebih besar. Dari sana biasanya muncul pertanyaan-pertanyaan yang lebih dalam seperti, 'bisakah aku tetap adil dalam masyarakat yang tidak adil?', 'bagaimana caranya agar aku, dengan peran yang kecil, bisa memberi dampak positif bagi komunitas?' Tiap orang menanggapi pertanyaan ini secara berbeda. Ada yang bergerak aktif mencari peluang perubahan, sementara yang lain merasa tidak berdaya di dalam sistem dan memilih menoleh ke arah lain. Dalam kasus saya, saya punya keyakinan pada pekerjaan yang kami lakukan, dan pengembangan karier di perusahaan bukan sekadar soal uang, tetapi tentang bertambahnya tanggung jawab dan meningkatnya kemampuan untuk menciptakan perubahan. Dalam organisasi yang tidak efisien, pilihan yang saya miliki adalah meninggalkan perusahaan, tetap berada di posisi saat ini, atau masuk lebih dalam ke organisasi dan menciptakan perubahan positif. Untuk pertanyaan "apakah tetap memuaskan jika software yang digunakan itu buruk atau merugikan?", mungkin ada orang yang menjawab ya bahkan untuk pekerjaan yang merugikan, tetapi setidaknya saya bukan orang seperti itu dan saya percaya pekerjaan yang saya lakukan memberi fungsi sosial yang positif. Maksudnya adalah, "membangun software yang berdampak positif bagi masyarakat dan digunakan jutaan orang itu memuaskan"

  • Pengembangan karier di perusahaan besar berarti lebih dari sekadar uang. Misalnya, sering ada kesempatan untuk memimpin proyek berskala lebih besar, atau mengembangkan secara internal produk yang dulu mungkin hanya akan dibuat oleh satu startup. Pengalaman terlibat dalam berbagai proyek selama beberapa tahun, atau memimpin tim dengan skala lebih besar, juga relatif lebih mudah didapat di perusahaan besar. Dan kalau softwarenya buruk atau merugikan? Startup dan perusahaan kecil tidak otomatis lebih baik; itu tergantung kasusnya

  • Jika kamu bermimpi menjadi data scientist researcher, developer evangelist, atau peran semacam itu, kamu memerlukan organisasi yang bisa mendukung pekerjaan tersebut. Peran seperti microservices architect juga kurang cocok di organisasi kecil, tetapi akan disambut di perusahaan besar dengan lebih dari 3000 karyawan. Jalur engineering manager juga baru terasa bermakna jika kumpulan talentanya cukup besar, jadi memang ada peluang pengembangan karier yang datang dari skala organisasi. Memang ada software yang buruk atau berbahaya, tetapi apa yang kita kerjakan juga tidak harus berupa enterprise software, bahkan saya berharap bukan itu

  • Saya tidak menganggap enterprise software itu buruk secara inheren. Tentu saja software enterprise yang bagus sangat mungkin dibuat, dan mampu mewujudkannya sambil tetap memenuhi kebutuhan yang kompleks itu sendiri adalah kemampuan yang cukup hebat. Namun dalam praktiknya, jarang sekali ada penilaian terhadap seberapa besar organisasi benar-benar peduli pada pengalaman pengguna. Bahkan setelah lebih dari 7 tahun saya berada di $ENTERPRISE, saya hanya pernah bertemu pengguna secara langsung satu kali

  • Soal apakah tetap memuaskan walau softwarenya buruk atau merugikan, banyak engineer mungkin merasa puas hanya karena bekerja dalam skala besar, atau merasa tidak berdaya sehingga menganggap hal itu sama sekali bukan urusannya. Karena untuk benar-benar mendapatkan skala sebesar itu, kita pada akhirnya harus berada di perusahaan raksasa, dan dari sana kita tidak bisa menghindari pola seperti dark pattern yang berulang secara algoritmis, maksimalisasi keuntungan pemegang saham, dan struktur kapitalisme semacam itu

• Ada satu hal yang terlewat, yaitu ketika kepemimpinan baru masuk, mereka menyingkirkan orang-orang lama lalu mengisi posisi dengan orang mereka sendiri. Selain itu, nama tim berubah setiap tahun, tetapi pekerjaan sebenarnya tidak berubah; yang berubah hanya penambahan kata-kata seperti "Innovation", "Discovery", atau "Leadership" ke nama tim

  • Kalau nama tim akan sesering itu diganti, mending sekalian dipatok saja jadi sesuatu seperti ‘Pikachu’ dan dipakai terus. Kalau semua orang sadar bahwa nama itu tidak penting, mungkin perubahan nama bisa berhenti. Setiap kali nama berubah, terlalu banyak tenaga dan waktu terbuang untuk memperbarui dokumen dan mengumumkannya ke semua orang

  • Di organisasi kami ada library kode infrastruktur internal yang dibuat dengan Terraform CDK. Library itu otomatis membuat resource monitoring di Datadog dan Pagerduty. Suatu hari, argumen wajib bernama ‘team’ saya hapus saja karena pada praktiknya nilai itu seperti berubah setiap 7 bulan

  • Rival saya, setiap kali masuk ke perusahaan baru, pelan-pelan membawa seluruh mantan rekan kerjanya dari help desk dan tim developer lama. Alasannya adalah loyalitas. Meski hasilnya buruk, mereka tidak mengeluh dan tidak mengangkat masalah ke atasan. Kalau mendengar cerita dari mantan karyawan yang pernah bekerja di perusahaannya, polanya selalu sama

    1. Mendiagnosis masalah (mengatakan penyebabnya adalah tidak adanya CRM partner Microsoft yang baru)
    2. Menghabiskan uang atas nama solusi (berkat partner CRM itu dan Microsoft, ada perjalanan dinas ke Las Vegas tiga kali setahun)
    3. Implementasi CRM gagal (lalu mengklaim masalahnya karena cakupan proyek tidak cukup besar)
    4. Menyetel ulang lingkup proyek lagi (fasilitas makin banyak)
    5. Saat situasi hampir gagal lagi, pindah ke perusahaan baru dan meninggalkan masalah di tempat lama

  • Jika kata seperti ‘Excellence’ masuk ke nama proyek, biasanya saya langsung kurang percaya

• Sebagian besar isi tulisan utama ini juga berlaku untuk lembaga pemerintah. Hanya saja, tidak ada kerja akhir pekan, ada peluang pengembangan karier (teknis), dan ada dorongan untuk pengembangan kemampuan atau pelatihan; selain itu kurang lebih mirip

  • Penyebutan soal kesenangan awal dan manfaat finansial di bagian awal juga tampaknya tidak terlalu berlaku untuk lembaga pemerintah

• Tulisan yang sangat lucu dan menarik. Saya sudah sekitar 3 tahun bekerja di enterprise. Secara teknis saya memang berkembang, tetapi rasanya justru lebih banyak belajar tentang manusia, komunikasi, dan birokrasi. Saya juga sangat relate dengan komentar tentang anggaran dan mouse. Namun berkat stabilitas finansial dari $ENTERPRISE, saya cukup beli mouse sendiri saja. Mungkin ada seseorang yang mempermasalahkan mouse yang tidak disetujui itu... tetapi ya tinggal diabaikan saja, atau menganggap urgensi palsu soal persetujuan mouse itu tidak terlalu penting

• Saya benar-benar tidak tahan hidup dalam organisasi seperti ini. Bahkan kalau gajinya dinaikkan 3 kali lipat pun, dalam beberapa bulan saya pasti akan benar-benar hancur

  • Besaran kompensasi sebenarnya berbanding terbalik dengan jumlah pekerjaan yang sungguh perlu dilakukan

  • Harus minum obat psikiatri (Zoloft) dalam dosis sangat kuat supaya bisa bertahan

  • Kadang saya berpikir mungkin saya harus memprioritaskan uang, mengambil gaji tinggi di $ENTERPRISE, menabung sebanyak mungkin, lalu mengambil cuti panjang. Tapi proses wawancaranya terasa terlalu melelahkan, dan memikirkannya saja sudah membuat semangat saya hilang. Saat ini saya ada di $MIDSIZENOLONGERSTARTUP, dan tempat ini pun punya berbagai hal aneh yang dengan caranya sendiri juga menguras saya

• Saya juga bekerja di lingkungan serupa, dan tulisan ini terasa sangat akurat sampai menyakitkan. Saya mengira tugas saya adalah menyelesaikan masalah dan merilis software, tetapi dalam kenyataannya itu sama sekali bukan ‘prioritas nyata (revealed preferences, tautan terkait: https://en.wikipedia.org/wiki/Revealed_preference)’ dari organisasi. Seperti cerita penulis yang pindah dari perusahaan kecil ke perusahaan besar, saya penasaran apakah ada orang yang mengalami kebalikannya, yaitu pindah dari perusahaan besar ke perusahaan kecil. Saya juga ingin tahu bagaimana sebaiknya menonjolkan pengalaman enterprise saat wawancara dengan tim kecil

  • Menurut pengalaman saya, ini seperti kisah dua kota. Saya juga sudah lelah membuang waktu secara sia-sia di $ENTERPRISE, jadi sekarang saya bahkan rela melepas 20% gaji demi bisa berada di tempat yang kecil tetapi benar dan benar-benar menghasilkan sesuatu. Namun selama 3 tahun terakhir, walaupun saya berusaha menjelaskan apa yang saya pelajari tanpa nada negatif, para pendiri startup cenderung melihat latar belakang saya sebagai sesuatu yang agak memberatkan. Skill bertahan hidup yang diperlukan di hutan dan di kebun binatang terlalu berbeda, jadi reaksinya seperti, jangan-jangan kamu sudah terlalu lama hidup di kebun binatang. Sebaliknya, perusahaan besar juga ingin merekrut orang yang paham proses internal dan hierarki, jadi lulusan startup pun tidak mudah ketika melamar ke tempat seperti itu

  • Saya pernah pindah dari perusahaan besar ke perusahaan kecil, dan semakin besar ukuran perusahaan, semakin besar pula masalah yang harus diselesaikan berkaitan dengan manusia dan politik internal organisasi, bukan masalah teknis. Di perusahaan besar, kompensasi model golden handcuffs (tautan terkait: https://en.wikipedia.org/wiki/Golden_handcuffs) sering dipakai untuk menahan talent kunci, sehingga orang cenderung lebih lama menoleransi segala omong kosong organisasi sebelum akhirnya bersedia melepas kompensasi itu. Kalau kamu membingkainya sebagai, "saya ingin meninggalkan perusahaan besar dan benar-benar menciptakan perubahan nyata", tim kecil biasanya cukup bisa memahami cerita itu

• Perusahaan besar hanya peduli untuk secara konsisten menghasilkan keluaran versi mereka sendiri. Penetapan tujuan juga diputuskan karena berbagai alasan seperti pencapaian angka, prosedur regulasi, atau keputusan eksekutif. Ini adalah ranah yang sama sekali berbeda dari rasionalitas manusiawi seperti yang biasa kita bayangkan

• Menanggapi tulisan asli tentang "ada kerajaan-kerajaan lain juga", saya menambahkan lelucon bahwa selain Inggris (manual QA) dan Mesir (piramida software), ada juga Mongol (tiba-tiba melempar setumpuk requirement lalu menghilang), Spanyol (terlalu berusaha menyempurnakan semua aturan sampai justru menimbulkan banyak gesekan), Jepang (dimarahi eksekutif lalu melakukan petualangan yang merusak karier sendiri), dan Tiongkok (tersesat dalam labirin rapat dan komunikasi yang amat tertutup)

  • Saya sangat menikmati tulisan ini, terutama analogi perang melawan Mongol yang lucu. Secara historis pun, melawan Mongol memang bukan urusan mudah

• Ini tulisan dengan insight yang bagus, dan berhasil menyampaikan pentingnya office politics serta peran manajemen dengan sangat baik

• Saya sudah 18 bulan bekerja di $ENTERPRISE. Rasanya sakit karena terlalu relate dengan kenyataannya