Makna Sebenarnya dari 'Done' di Perusahaan Big Tech

• Di big tech, benar-benar menyelesaikan pekerjaan berarti merampungkannya sampai pada kondisi yang memuaskan perusahaan, lalu pergi, di dalam sistem yang bisa terus diperbaiki tanpa batas
• Engineer yang kompeten tetapi kurang punya inisiatif akan terus mengulang perbaikan-perbaikan kecil dan akhirnya melewatkan hasil nyata
• Agar diakui sebagai orang yang benar-benar bekerja, kita harus menyerahkan hasil yang jelas dan terlihat kepada para pengambil keputusan
• Kita harus selalu memeriksa apakah pekerjaan yang kita lakukan disajikan dalam bentuk yang bisa dibaca dan dievaluasi oleh manajer tingkat atas
• Tidak semua pekerjaan bisa dirapikan sampai tuntas; pada titik tertentu, kemampuan untuk "mendeklarasikan kemenangan lalu pergi" menjadi kompetensi inti

---

'Pekerjaan' memiliki sifat yang tidak bisa benar-benar dituntaskan

• Berbeda dari soal matematika atau tugas sekolah, pekerjaan di dunia nyata adalah sistem terbuka yang dapat diperbaiki tanpa batas
• Pengembangan layanan seperti menanam pohon; setelah itu pun tetap merupakan proses yang membutuhkan perawatan berkelanjutan

Engineer kompeten yang terjebak

• Engineer yang menangani semuanya sendiri dan hanya mengulang perbaikan kecil secara terus-menerus mungkin merasa dirinya sedang menghasilkan sesuatu
• Namun dari sudut pandang manajemen atas, hal itu bisa dinilai sebagai tidak adanya "penciptaan nilai yang terlihat bagi perusahaan"
• Akibatnya, ia bisa disalahpahami sebagai orang sibuk yang tidak menghasilkan capaian

Makna sebenarnya dari ‘menyelesaikan’

• Membawa pekerjaan sampai ke titik yang memuaskan perusahaan (pengambil keputusan), lalu beralih ke hal berikutnya
• Alih-alih terus melakukan refactoring atau mengulang perbaikan kecil, kita perlu membuat daftar hasil yang jelas
• Ketegasan untuk menyatakan "sudah selesai" lalu beralih ke pekerjaan berikutnya itu penting

Menjamin ‘keterbacaan’ pekerjaan

• Proyek yang sudah diketahui atau diminta oleh manajer, atau respons terhadap insiden besar, memiliki keterbacaan yang tinggi
• Pada dasarnya, sebagian besar pekerjaan teknis bagi manajer hanyalah noise teknis yang sulit dinilai
• Karena itu, kita harus menyesuaikannya agar terbaca, misalnya dengan membuat hasil terlihat secara kasatmata atau menekankan dampak finansialnya

‘Menyelesaikan’ sebagai konsep sosial

• Secara filosofis, konsep 'selesai' juga merupakan konstruksi sosial, tetapi dalam kenyataan ia memiliki daya yang sangat nyata
• Jika ini diabaikan, kita bisa tidak mendapat penilaian yang layak, dan pada akhirnya bahkan bisa dipecat

Ringkasan

• Bekerja bukan berarti sudah menyelesaikannya
• Sebagian besar pekerjaan tidak benar-benar bisa selesai dan dapat terus berlanjut
• Kita harus menjadi taktisi yang berorientasi pada hasil, bukan tukang kebun
• Standar untuk mengatakan "selesai" adalah kepuasan perusahaan/manajer
• "Deklarasikan kemenangan → pergi → lanjut ke pekerjaan berikutnya" adalah strategi kuncinya

[aer0700]

Tampaknya kemampuan penting juga adalah memilih pekerjaan yang cukup layak untuk dinyatakan selesai (Done).

[elbanic]

Membatasi ruang lingkup disebut scoping. Kemampuan untuk melakukan scoping dengan baik agar bisa menang itulah yang menjadi keahlian.

[bakyeono]

Hanshin vs. Soha

[doolayer]

Hasil yang terlihat dan terukur, bukan sekadar detail

[GN⁺]

Opini Hacker News

• Saya tidak sepenuhnya menolak argumen tulisan ini, tetapi berdasarkan pengalaman bekerja di big tech, berbagai startup, dan perusahaan unicorn, rasanya ini bukan nasihat yang terlalu praktis. Selama 10 tahun terakhir, pekerjaan developer menjadi terlalu terspesialisasi sehingga terlepas dari kebutuhan pengambil keputusan dan pelanggan. Fenomena ini muncul karena Product Manager berada di tengah antara engineer dan bagian lain perusahaan. Saya selalu ingin menghasilkan dampak yang bernilai, tetapi untuk benar-benar melakukannya saya harus menanggung stres terus-menerus. Kontribusi saya pasti disesuaikan setelah melewati ego orang yang berbicara dengan para pengambil keputusan. Satu-satunya saat saya benar-benar merasa berprestasi dalam 5 tahun terakhir adalah ketika saya mengambil peran sementara sebagai Product Manager selama 9 bulan. Pada masa itu, tim kami berhasil menyelesaikan tiga proyek yang sebelumnya sudah beberapa kali gagal dikerjakan tim lain. Rahasianya adalah berbicara langsung dengan para pemangku kepentingan untuk memahami kebutuhan mereka, bukan memaksakan cara saya sendiri. Jadi ke depan saya mungkin akan terus hanya memberikan apa yang diminta, disalahkan untuk bug, dan tidak mendapat pengakuan atas fitur. Setidaknya kompensasinya lumayan. Saya masih terus mencari tempat di mana saya bisa benar-benar berkontribusi

  • Bagian “kompensasinya lumayan” ini yang paling melekat buat saya. Saat bekerja di big tech, saya punya pandangan pribadi bahwa kondisi “mandek” juga tidak terlalu buruk. Misalnya, kalau di Google atau MS Anda menerima gaji $300.000 dan selama 10 tahun hanya menangani proyek yang membosankan, pengalaman itu tetap akan dihargai di mana pun. Dulu saya yang ambisius mungkin akan kesal dengan itu, tetapi kalau memang punya sifat seperti itu biasanya Anda akan pindah ke perusahaan yang lebih kecil. Semakin bertambah usia, perhatian bergeser dari perusahaan ke keluarga dan teman. Kalau seseorang memberi tahu saya bahwa saya tidak akan dipromosikan, saya akan menjawab, “Memangnya kenapa?” Saya menghasilkan cukup uang untuk keluarga saya dan tetap menjaga work-life balance. Sejujurnya, bagian terbaik dari perusahaan adalah gajinya dan bagaimana itu membuat sisa hidup menjadi lebih baik
  • Saya pernah mengalami bahwa peran Product Manager di dunia nyata, tidak seperti penjelasan idealnya, justru terjebak di tengah dan gagal mewakili kedua sisi dengan baik. Akibatnya saya jadi mengembangkan kemampuan product management sendiri, dan skill itu sangat berguna untuk menghindari kerja sia-sia. Karena itu saya jadi bertanya-tanya apakah bagi engineer senior, product management juga seharusnya menjadi kompetensi wajib
  • Hal lain yang perlu dipikirkan adalah bahwa jika terus seperti ini, Anda sedang berjalan menuju burnout
  • Saya sadar bahwa komunikasi adalah skillset terbaik di organisasi mana pun. Penugasan sementara selama 9 bulan saja tidak cukup untuk memahami nilainya sepenuhnya. Tulisan ini sendiri terbaca seperti orang yang, sama seperti engineer lain, sedang sangat kesal dan menganggap dirinya lebih pintar daripada orang lain di organisasi. Padahal sering kali tidak demikian, dan mindset seperti ini buruk untuk kolaborasi
  • Di balik setiap web application yang berjalan baik, selalu ada seseorang yang seperti tukang kebun
  • Saya penasaran kenapa Anda tidak terus menjadi Product Manager
  • Ini sangat bergantung pada perusahaan. Ada banyak tempat di mana pengaruh engineer lebih besar. Bahkan di big tech pun ada contoh yang tidak memisahkan engineer dari pelanggan
  • Apakah maksudnya Product Manager harus dipecat?
  • Saya juga pernah menjalankan peran Product Manager, yaitu menjadi penengah antara engineer dan perusahaan, dan benar bahwa kontribusi saya juga difilter oleh ego saya sendiri, tetapi dari yang Anda ceritakan terdengar seperti itu justru sangat memuaskan… tampaknya memang pekerjaan yang cukup memuaskan

• Saya punya keberatan mendasar terhadap menjadikan memuaskan orang yang berkuasa sebagai satu-satunya ukuran keberhasilan. Memang kita terikat dalam struktur status yang absurd, tetapi menurut saya mengganti tiket di Jira menjadi “done” atau menghilangkan warning compiler bukanlah segalanya. Tidak ada orang yang berkata, “Saya tidak menyesal karena selama 40 tahun saya selalu memuaskan atasan saya”

  • Saya sudah bekerja 30 dari 40 tahun, dan jelas ada nilai dalam memuaskan atasan saya dan atasan dari atasan saya. Meski sudut pandang sinis bukanlah seluruh hidup, mengetahui sudut pandang sinis ini berarti lebih dekat pada kebenaran
  • Sebenarnya saya rasa “memuaskan atasan dan atasan dari atasan” memang definisi dari pekerjaan. Anda melakukan apa yang diminta seseorang dan dibayar untuk itu

• Secara umum saya setuju, tetapi saya ingin menambahkan satu hal: untuk memahami apa yang diinginkan manajer, Anda perlu memahami struktur bisnis perusahaan. Anda harus mencari tahu sendiri bagaimana perusahaan menghasilkan uang dan apa yang dianggap bernilai. Saat bekerja di tempat yang sejalan dengan nilai perusahaan, kompensasi lebih tinggi dan kepuasan juga lebih besar. Penting untuk bertemu langsung dengan pelanggan, sales, marketing, dan kalau bisa juga para eksekutif. Bahkan jika Anda hanya menangani sistem internal, yang penting adalah memahami nilai atau perlindungan apa yang diberikan sistem itu. Jika departemen tempat Anda berada tidak menciptakan nilai yang jelas, Anda perlu mempertimbangkan pindah ke tim yang bernilai. Bekerja tidak selaras dengan kebutuhan perusahaan selalu menjadi kesalahan besar

  • Saya rasa tidak masalah jika Anda memandang diri Anda sebagai tukang kayu. Development adalah mengimplementasikan sesuai spesifikasi, tetapi ketika spesifikasi itu tidak masuk akal atau mustahil, Anda harus menunjukkannya secara langsung. Kalau pihak bisnis tidak bisa menjelaskan pekerjaan mereka dengan jelas, berarti mereka sendiri juga tidak memahaminya. Lagi pula, jika developer memang harus memahami bisnis juga, maka harus ada kompensasi untuk itu. Ada opportunity cost juga, karena waktu itu bisa dipakai untuk berkembang lebih jauh secara teknis
  • Sering kali asumsi bahwa “manajer benar-benar akan memahami dan peduli pada bisnis” sejak awal memang tidak berlaku

• Penulis mengatakan bahwa “perlu menghasilkan hasil yang terlihat oleh para pengambil keputusan,” dan saya bisa memahami mindset “bisnis” orang ini. Banyak developer kesulitan karena tidak tahu bagaimana menjelaskan manfaat bisnis dari pekerjaan mereka sendiri. Refactoring juga termasuk di sini. Perbaikan kode mungkin tampak tidak berarti sama sekali dalam jangka pendek, tetapi tergantung situasinya, itu bisa menghasilkan manfaat besar bagi organisasi. Intinya, Anda harus memikirkan bagaimana menghubungkan pekerjaan Anda dengan pendapatan atau penghematan organisasi, dan juga bagaimana mengomunikasikannya

  • Developer harus belajar bahasa bisnis, lalu membingkai masalah dengan cara yang dipahami dan dipedulikan oleh orang bisnis. Jika melihat sebagian besar keputusan bisnis, pada akhirnya itu soal biaya vs manfaat. Bahkan banyak pebisnis yang benar-benar memperlakukan software sebagai biaya. Artinya, berbeda dari anggapan yang terasa wajar bagi developer seperti “bukankah software adalah pusat penciptaan pendapatan,” pihak bisnis sebenarnya tidak peduli pada software itu sendiri. Kalau mereka bisa menjualnya gratis, semua biaya jadi 0 dan marginnya tak terbatas—itulah isi hati para pebisnis. Sales adalah ranah yang ditentukan oleh suasana, relasi, bahkan suap, lebih daripada rasionalitas. Meski terdengar tidak rasional, ini tetap harus dipahami

• Saya jadi bertanya, “Apakah mindset di atas ini alasan banyak engineer tidak peduli pada kualitas kode, testing, dokumentasi, dan sebagainya?” Kalau yang diperhatikan hanya kepuasan langsung para petinggi, siapa yang mau bersusah payah menulis kode yang bisa dipelihara dalam jangka panjang? Kita mungkin tidak butuh kualitas di atas spesifikasi, tetapi bahkan investasi minimum pun bisa menghemat miliaran

  • Semakin banyak orang yang tidak peduli pada craftsmanship dan kualitas. Suara “saya hanya bekerja sesuai gaji saya” terdengar di mana-mana. Dulu ada rasa bahwa pekerjaan harus dilakukan dengan sungguh-sungguh terlepas dari gaji, tetapi sekarang itu tampaknya banyak menghilang
  • Semua orang punya alasan mengapa mereka menjalankan perannya masing-masing. Seperti di lokasi produksi film, engineer juga bisa punya tujuan yang berbeda-beda. Jika engineer dicegah untuk menghidupkan passion mereka, yang tersisa adalah orang-orang yang hanya bergerak demi uang. Risikonya besar
  • Saya rasa tidak ada orang yang sengaja menulis kode buruk. Ketika sikap tidak peduli atau burnout muncul di lingkungan yang tidak berulang kali memberi penghargaan pada usaha tambahan, tak seorang pun akan mengeluarkan usaha ekstra. Dan banyak developer juga pada dasarnya kurang kompeten. Ini bukan profesi yang sangat kompetitif seperti aktuaris, jadi siapa pun dengan latar belakang apa pun bisa masuk, dan sejak awal pun sulit untuk menjadi benar-benar mampu
  • Banyak Product Manager hanya menginginkan kecepatan. Kita menginginkan testing dan dokumentasi, tetapi CFO menganggap pekerjaan tambahan seperti itu tidak perlu karena “itu bukan fitur”
  • Engineer tidak diasumsikan akan bertahan lama di perusahaan, jadi mereka tidak merasa harus menanggung tanggung jawab masa depan. Jika terus pindah kerja, mereka tidak pernah mengalami sendiri masalah dari kode yang mereka buat di tempat sebelumnya, jadi mereka tidak belajar dari kegagalan dan terus mengulanginya. Saya sudah hampir 20 tahun di perusahaan yang sama, dan saya terus melihat kesalahan yang sama berulang. Saya juga lelah dengan perubahan yang hanya mengganti tampilan luar sambil membiarkan masalah esensial tetap ada. Kalau bukan memperbaiki masalah yang sebenarnya, perubahan tidak ada artinya. Tujuan saya adalah menyelesaikan masalah yang nyata

• Saya sudah sering mengalami realitas dan masalah ini, dan meski saya memahaminya, saya tetap keberatan. Banyak proyek dimulai lalu tim dibubarkan dengan seruan “selesai, done!” Namun produknya masih punya isu, masih perlu fitur tambahan, dan perusahaan terus berubah. Pada akhirnya yang menumpuk hanyalah technical debt karena pengelolaan yang buruk. Manajer baru datang, membuat ulang proyek lama, dan mengulangi kesalahan yang sama. Cara ini tidak efisien. Jika dijelaskan dengan analogi AC, menjaga suhu tetap stabil lebih efisien daripada terus mematikannya lalu menurunkannya lagi. Faktanya, tools manajemen yang saya buat tidak menarik perhatian manajemen, tetapi dibutuhkan oleh lebih dari 500 pengguna internal. Tanpa investasi waktu besar untuk maintenance, yang penting adalah terus menjaga kepercayaannya. Jika dibiarkan, ia akan terpecah dan keandalannya hilang. Hanya dengan beberapa menit saja, konsistensi bisa tetap terjaga

  • Analogi AC itu sebenarnya keliru secara termodinamika. Mematikannya lalu mendinginkannya lagi justru lebih efisien

• Saya punya perasaan campur aduk dalam banyak hal. Jelas bahwa untuk visibility dan promosi, tulisan ini benar, tetapi pada kenyataannya ini adalah nasihat yang berpusat pada manajer: cukup memuaskan atasan. Namun bagaimana jika tidak ada arahan yang jelas dan prioritas terus berubah? Menjadi sulit untuk menghasilkan hasil yang berarti, dan hubungan manajer-bawahan berubah total menjadi struktur “yes-man”. Hasil seperti ini tidak bagus

  • Jawabannya sederhana. Jika Anda merasa bekerja di bawah atasan bodoh, berhentilah. Penderitaannya hanya sementara, dan pada akhirnya keadaan akan membaik. Jauh lebih baik daripada membuang waktu menjelaskan pekerjaan saya kepada orang bodoh
  • Sebaliknya, jika bekerja dengan manajer yang benar-benar baik, “memuaskan manajer” saja bisa dengan cepat membantu perkembangan karier maupun hasil kerja Anda

• "unagentic engineer" berarti engineer yang tidak punya inisiatif. Jika engineer bekerja dengan cara seperti ini, hal itu bisa berujung pada inefisiensi dan masalah serius seperti biaya cloud berlebihan, insiden keamanan, keluhan pelanggan, dan sebagainya. Contoh pekerjaan yang tidak pernah benar-benar selesai adalah security patch, perbaikan kesalahan, optimisasi biaya, dan menangani feedback pelanggan. Jika perusahaan tidak memahami nilai ini, jawabannya adalah pindah kerja

  • Itulah tepatnya inti tulisan ini. Ada organisasi yang berpusat pada realitas dan ada yang berpusat pada status. Organisasi yang berpusat pada realitas cenderung rasional dalam jangka panjang, sedangkan organisasi yang berpusat pada status hanya bertujuan memuaskan atasan. Hierarki adalah segalanya, lebih penting daripada kualitas produk atau hubungan dengan pelanggan. Organisasi seperti ini tidak harus runtuh, tetapi pada akhirnya bisa kolaps dalam sekejap
  • “Unagentic” berarti karyawan yang tidak memiliki agency. Kita berharap mereka menunjukkan inisiatif sendiri, tetapi kenyataannya ini bisa menjadi jebakan di mana eksistensi developer itu sendiri menjadi tidak terlihat
  • Tidak harus selalu seperti ini, tetapi jika para eksekutif tidak peduli, pada dasarnya budaya semacam ini akan terbentuk. Misalnya, saya menikmati fokus pada detail desain antarmuka. Namun perhatian seperti itu hanya dihargai jika organisasi mengakuinya sebagai nilai. Di banyak tempat, itu bahkan tidak diperhatikan
  • “unagentic engineer” berarti tipe orang yang kurang punya kecenderungan untuk mengambil keputusan dan memimpin secara sukarela, dan hanya membiarkan dirinya mengikuti arus
  • Maksudnya engineer yang tidak otonom, yaitu yang punya kewenangan penilaian yang rendah
  • Bukan “high agency”, yaitu orang yang mungkin terlihat pintar dan kompeten tetapi selalu menunggu instruksi dan tidak bisa memimpin dirinya sendiri

• Saya sangat membenci buzzword seperti "alignment". Meski begitu, pada dasarnya ini memang konsep yang penting. Idealnya, saya, manajer saya, dan eksekutif di atasnya harus sepakat soal pekerjaan mana yang paling penting. Kalau tidak begitu, dari sudut pandang anggota organisasi tempat saya berada, itu adalah masalah. Entah itu hal yang benar atau adil atau tidak, kita tetap harus hidup menyesuaikannya. Pada akhirnya, alasan kita dibayar adalah untuk melakukan apa yang diperintahkan dari atas. Hanya segelintir orang yang punya privilese untuk memengaruhi orang di atas mereka. Itulah yang disebut "managing up"

• Tulisan aslinya berguna, tetapi rasanya ada beberapa hal yang lebih penting yang terlewat:

  • Bekerja di tim yang tepat lebih penting daripada mengerjakan hal yang tepat
  • PM dan manajer yang baik lebih penting daripada pekerjaan yang baik
  • Struktur pelaporan yang baik lebih penting daripada nilai hasil kerja
  • Pekerjaan yang selaras dengan tujuan kepemimpinan jauh lebih dihargai daripada dukungan terhadap operasi bisnis yang sebenarnya
  • Anda harus selalu siap mengerjakan semuanya sendiri, dan politik perusahaan besar selalu disertai disinsentif terhadap kolaborasi

[heal9179]

Pendapat-pendapat di sini justru lebih tepat mengenai inti persoalannya.

[roxie]

Iya juga wkwk