Memuji Insinyur yang "Biasa"

• “Insinyur 10x” terdengar masuk akal secara intuitif, tetapi sangat sulit mengukur produktivitas secara objektif, dan juga keliru jika memandangnya sebagai sifat pribadi yang tetap
• Kepemilikan dan hasil nyata dari perangkat lunak ditentukan oleh kolaborasi dan kapabilitas pada tingkat tim engineering
• Organisasi yang benar-benar unggul bukan hanya yang berisi orang-orang luar biasa, melainkan yang menciptakan lingkungan agar insinyur biasa bisa terus-menerus menghasilkan hasil yang baik
• Sistem harus dirancang dengan mempertimbangkan bahwa orang biasa bisa berbuat salah atau kelelahan, dan fokusnya harus pada membangun “tim 10x”
  • Desain sistem perangkat lunak dan budayanya harus didasarkan pada karakteristik, keberagaman, dan potensi pertumbuhan dari “orang biasa”
• Pada akhirnya, metrik inti produktivitas adalah dampak bisnis, dan yang penting bukan merekrut “talenta terbaik”, melainkan menyusun tim dengan orang yang tepat

---

Memuji Insinyur yang “Biasa”

• Tulisan ini menjelaskan kritik terhadap konsep “insinyur 10x” dan pentingnya organisasi tempat insinyur biasa dapat menghasilkan performa tim yang luar biasa

Mitos “Insinyur 10x” dan Keterbatasannya

• Semua orang pernah bertemu insinyur luar biasa yang terasa seperti penyihir dalam perjalanan kariernya
• Dari situlah lahir konsep “insinyur 10x”, tetapi konsep ini lemah dari sisi dasar bukti dan juga dapat memperkuat bias
• Menetapkan satu ukuran tunggal untuk produktivitas nyaris mustahil
  • Kombinasi variabel seperti tech stack yang digunakan, domain, tahap pengembangan, kondisi pasar, pengalaman, dan lainnya tidak terbatas
  • Seseorang bisa menjadi insinyur 10x di bidang tertentu, tetapi di sebagian besar area lain ia bisa saja biasa-biasa saja atau bahkan di bawah rata-rata
• Seseorang yang dulu merupakan DBRE yang hebat pun, seiring waktu, bisa menjadi biasa saja di bidang itu
• Pada akhirnya, tidak ada seorang pun yang bisa selalu 10 kali lebih unggul di semua bidang

Kepemilikan Perangkat Lunak yang Berpusat pada Tim

• Perangkat lunak dimiliki dan dikelola oleh tim, bukan ditangani sebagai tanggung jawab pribadi
• Pengiriman perangkat lunak, maintenance, perbaikan, ekspansi, refactoring, dan seluruh proses lainnya berlangsung pada tingkat tim
• Sistem yang dimiliki satu orang akan menjadi single point of failure (SPOF) ketika orang itu cuti atau pindah kerja, sehingga menjadi kerentanan bagi organisasi
• Di startup, pada tahap awal kepemilikan individu mungkin tak terhindarkan, tetapi ketika organisasi bertumbuh hal ini harus diubah menjadi kepemilikan tim
• Tugas utama pemimpin engineering harus berfokus pada membangun tim berkinerja tinggi, dan yang penting bukan “insinyur 10x” melainkan menciptakan tim 10x

Syarat Organisasi Berkinerja Tinggi yang Sesungguhnya

• Banyak perusahaan lebih suka membangun tim dari alumni FAANG, lulusan kampus elite, dan Staff Engineer
• Namun organisasi yang benar-benar baik adalah tempat insinyur biasa dapat secara stabil menghasilkan dampak yang nyata
• Keunggulan yang lebih besar bukanlah organisasi yang hanya bisa menghasilkan performa lewat orang-orang “terbaik”, melainkan organisasi yang membangun sistem agar developer biasa pun bisa tumbuh secara proaktif dan memberi dampak positif pada produk serta bisnis
• Justru organisasi seperti inilah yang melahirkan lebih banyak insinyur kelas dunia

Mendefinisikan Ulang Arti “Biasa”

• Industri perangkat lunak dipenuhi pola pikir berpusat pada elite seperti “10% teratas” atau “top .1%”
• Namun penting untuk mengakui bahwa sebagian besar engineer adalah orang biasa yang tumbuh melalui beragam pengalaman dan latihan
• Tidak ada yang terlahir sebagai “insinyur hebat”
• Insinyur hebat itu dibentuk — siapa pun bisa menjadi luar biasa melalui pembelajaran dan pengalaman

Merancang Sistem untuk Orang Biasa

• Saat merekrut, wajar untuk melihat kekuatan yang menonjol, tetapi saat merancang sistem kita harus mempertimbangkan kenyataan bahwa orang akan membuat kesalahan secara biasa, kelelahan, dan mengandalkan kebiasaan
• Engineer pada umumnya dipengaruhi oleh bias kognitif, kelelahan, dan naik-turun emosi
• Jika sistem dirancang bukan untuk segelintir orang cerdas melainkan dari sudut pandang insinyur biasa, maka kemampuan kreatif talenta unggul dapat difokuskan pada produk itu sendiri

Cara Membangun “Tim 10x”

• Perkecil semaksimal mungkin jarak antara menulis kode dan melakukan deploy
  • Siklus deploy yang cepat mengurangi beban kognitif, serta memungkinkan eksperimen dan feedback yang lebih cepat
  • Semakin lambat deploy, semakin banyak perubahan menumpuk sekaligus, sehingga pelacakan masalah dan rollback menjadi lebih sulit
• Permudah pemulihan dari kesalahan dan rollback
  • Developer harus bisa men-deploy kodenya sendiri dan, ketika menemukan masalah, memulihkannya dengan cepat
• Buat tindakan yang benar menjadi mudah, dan tindakan yang salah menjadi sulit
  • Bekerja sama dengan designer dan platform engineer untuk membangun guardrail dan sistem self-service
• Berinvestasi aktif pada alat observability dan instrumentasi
  • Memvisualisasikan perilaku kode yang nyata agar semua engineer dapat dengan mudah memahami sistem dan melakukan debugging
• Investasikan resource engineering pada tools internal dan peningkatan produktivitas
  • Sistem seperti ini memerlukan ownership tersendiri dan harus menjadi prioritas di seluruh perusahaan
• Bangun budaya yang inklusif
  • Lingkungan tempat siapa pun bisa bertanya, membuat kesalahan, dan bereksplorasi
  • Tim dengan latar belakang, skill, dan senioritas yang beragam lebih tangguh dan lebih kuat menghadapi perubahan
• Susun tim yang mencampurkan engineer dari semua level
  • Struktur di mana junior hingga senior saling belajar, saling mengajar, dan tumbuh bersama
  • Sistem seperti ini juga bisa digunakan kembali untuk onboarding karyawan baru, perpindahan antar tim, dan sebagainya

Ukuran Produktivitas yang Sebenarnya: "Dampak Bisnis"

• Pada akhirnya, ukuran produktivitas dalam software engineering adalah dampak bisnis
• Esensinya bukan menulis banyak kode, melainkan memecahkan masalah dan menciptakan nilai
• Dalam praktiknya, yang benar-benar menggerakkan industri bukan engineer Staff+, melainkan engineer senior dan mid-level
  • Merekalah yang membentuk fondasi organisasi dan terus mendorong bisnis maju
  • Jika hanya level Staff+ yang bisa menghasilkan dampak, itu adalah tanda ada masalah dalam organisasi

Organisasi yang Melahirkan Insinyur Kelas Dunia

• Organisasi yang benar-benar baik adalah tempat siapa pun bisa memberi dampak, meskipun bukan engineer yang luar biasa
• Organisasi terbaik tidak harus secara khusus merekrut talenta kelas dunia, tetapi justru secara alami melahirkan paling banyak insinyur kelas dunia
• Talenta berkumpul di tempat engineer dapat fokus pada pemecahan masalah, pertumbuhan, dan dampak, dan pengalaman “bekerja dengan bahagia sambil terus berkembang” itu sendiri menciptakan siklus yang baik
• Pemimpin harus berperan menghubungkan kemampuan pribadi talenta unggul dengan pertumbuhan organisasi secara keseluruhan dan nilai bagi pelanggan, tanpa bergantung pada kemampuan individu semata

Merekrut “Orang yang Tepat”, Bukan “Talenta Terbaik”

• Industri cenderung hanya mencari yang “terbaik”, tetapi yang benar-benar penting adalah sistem dan lingkungan
• Dibanding “talenta terbaik”, menemukan orang yang cocok untuk tim dan organisasi adalah keunggulan yang lebih besar
• Daripada menyusun tim dari orang yang tanpa kelemahan, lebih efisien membangun tim dengan talenta yang tepat yang memiliki kekuatan khas dan dapat memperkuat keberagaman serta harmoni organisasi
• Tim yang inklusif dan beragam secara nyata menghasilkan kinerja, pertumbuhan, dan kesuksesan jangka panjang
• Tempat di mana semua orang menikmati pekerjaan, bertumbuh, dan menghasilkan hasil yang bermakna adalah organisasi kelas dunia yang sesungguhnya, dan dalam budaya tempat orang bisa belajar bahkan dari kegagalan atau kesalahan, engineer maupun organisasi sama-sama berkembang
• Organisasi seperti inilah yang mampu menarik generasi engineer berikutnya sekaligus menjadi lingkungan tempat talenta yang sudah hebat pun ingin bertahan

[GN⁺]

Komentar Hacker News

• Saya setuju dengan gagasan bahwa unit minimum kepemilikan perangkat lunak dan delivery adalah tim engineering, tetapi saya juga merasa ada yang disayangkan. Struktur seperti ini bersinggungan dengan budaya yang menjadikan engineer sebagai warga kelas dua dibanding manajer atau divisi produk. Kita hanya bertanggung jawab atas delivery, tetapi tidak bisa secara mandiri mengambil keputusan yang benar-benar berarti di luar lingkup tim yang sangat kecil. Di tim terbaik, rentang diskresinya bisa mencapai berbulan-bulan, bahkan bertahun-tahun, tetapi di kebanyakan tim itu menyusut menjadi beberapa hari atau beberapa minggu. Padahal, struktur di mana engineer memiliki kepemilikan yang nyata dan sistem bisa bertahan lama tanpa rusak atau menjadi berisiko sangat mungkin diwujudkan. Kuncinya adalah menyediakan slack, mendorong pekerjaan berkualitas, dan memberi kebebasan yang cukup agar siapa pun di tim bisa dengan fleksibel berpindah tugas. Sambil masing-masing memegang ownership dan membuat keputusan jangka panjang, orang-orang tetap bisa berkolaborasi secara ad hoc dan berbagi pengetahuan implisit, sehingga situasi ketika seseorang tiba-tiba masuk untuk membantu atau bahkan mengambil alih sepenuhnya menjadi sesuatu yang alami. Dari pengalaman nyata, tim seperti ini memang lebih sering melakukan rewrite dibanding tim biasa, tetapi secara keseluruhan jauh lebih produktif. Melakukan rewrite sistem secara bertahap dalam potongan-potongan kecil sangat efektif baik untuk evolusi desain maupun akumulasi pengetahuan dan kemampuan dalam organisasi. Dari luar mungkin terlihat seperti pemborosan, tetapi itu adalah slack yang penting untuk membuat organisasi secara keseluruhan tetap luwes dan tangguh. Bahkan saya makin yakin bahwa banyak proses top-down di organisasi yang katanya ingin mengurangi pemborosan, justru sebenarnya menghilangkan slack yang penting

  • Orang di luar engineering sering kali tidak bisa langsung menilai keputusan jangka panjang yang dibuat engineer, dan tidak tahu penghargaan seperti apa yang seharusnya diberikan. Ini bahkan tetap berlaku begitu kita keluar dari tim engineering yang sama. Mereka tidak punya kemampuan untuk menilai langsung apakah pekerjaan jangka panjang yang punya nilai internal itu benar-benar bernilai atau tidak. Jika Anda percaya diri dengan pengambilan keputusan jangka panjang dan penggunaan slack time, tidak masalah bila Anda dibayar berdasarkan delivery. Pada akhirnya pekerjaan jangka panjang itu akan kembali sebagai hasil yang lebih baik

  • Saya pikir rewrite perangkat lunak memainkan peran penting dalam proses pengembangan. ‘Agile’ yang sesungguhnya adalah pendekatan yang tidak terlalu terikat pada arsitektur pertama, membuat prototipe dengan cepat, dan tetap lentur terhadap perubahan requirement. Menulis kode mirip dengan menulis teks: jauh lebih efisien untuk tetap menulis dulu walau draf pertama masih kasar, lalu memperbaikinya di versi kedua. Tujuan draf pertama bukan membuat sesuatu yang bagus, melainkan cepat membuat sesuatu, menjelajahi domain masalah, dan menemukan edge case. Cara kerja seperti ini tidak terlalu diterima oleh manajemen. Begitu mereka melihat prototipe yang berfungsi, mereka hanya berkata “langsung rilis saja”, dan tidak memberi waktu untuk rewrite. Kalau ada solusi, saya rasa organisasi perlu dibuat lebih datar dan ownership kode benar-benar dikembalikan ke engineer. Struktur yang ideal adalah engineer dan product owner mengambil keputusan bersama secara demokratis

  • Dulu saya juga menganggap ‘ownership individu’ itu penting, dan sampai sekarang saya tetap percaya engineer bisa memilikinya, tetapi saya juga mengakui bahwa pada praktiknya banyak engineer tidak menginginkannya. Kebanyakan engineer oke jika ownership ada di tingkat tim, tetapi tidak terlalu tertarik pada ownership di tingkat individu. Ini hanya pekerjaan untuk mencari nafkah. Jika itu diserahkan ke individu, mudah muncul ketidakpercayaan dalam tim atau anggota yang tidak punya kecenderungan kepemimpinan jadi tersisih, dan akhirnya tercipta situasi di mana tidak ada seorang pun yang benar-benar punya diskresi nyata. Struktur yang memberi ownership dan diskresi di tingkat tim jauh lebih sederhana dan efektif. Ini juga dimungkinkan oleh dinamika yang hadir karena ada team lead atau manajer. Jika kepemilikan perangkat lunak diberikan per individu, terlalu banyak risiko gagal karena perubahan personel, stabilitas, karier, dan variabel lainnya. Sehat apa pun organisasinya, masalah besar dan kecil tetap akan selalu ada, dan dalam struktur seperti ini jalur menuju kegagalan menjadi yang paling pendek. Kalau dibayangkan seperti gearbox, akan lebih mudah dipahami. Jika hanya ada satu gigi dan itu rusak, Anda tidak bisa jalan; jika ada banyak gigi, mungkin tidak nyaman, tetapi ketika satu rusak Anda tetap bisa terus bergerak

  • Saya benar-benar berpikir ownership individu yang substansial itu mungkin. Bahkan menurut saya, itu satu-satunya cara untuk benar-benar ‘produktif’. Tetapi ini bukan inti persoalannya. Individu memang tidak tergantikan, tetapi anggota tim sampai batas tertentu bisa saling menggantikan tergantung strukturnya. Semakin besar organisasi, semakin mereka menginginkan prediktabilitas di tingkat tim, dan untuk itu diperlukan kemampuan saling menggantikan antaranggota, yaitu redundancy. Dalam engineering juga begitu: reliability atau ketahanan membutuhkan redundancy, dan efisiensi adalah trade-off dari mengurangi redundancy

  • Kami bekerja dalam struktur yang hanya membuat kami bertanggung jawab pada 'delivery', dan ownership pada akhirnya hanya menambah beban tanpa imbalan yang nyata. Pekerjaan pun terbatas pada sekadar menempelkan fitur ke halaman. Jika ada tanggung jawab tambahan, seharusnya ada kompensasi tambahan juga. Manajer atau eksekutif mendapat kompensasi lebih besar sesuai jumlah orang yang mereka tanggung; developer pun seharusnya begitu

• Saya yakin tim terbaik adalah tim yang punya budaya yang membuat engineer biasa bisa menghasilkan kinerja luar biasa. Dibanding apa yang sering disebut sebagai ‘kualitas engineering’ atau rekrutmen talenta, budaya, kepercayaan, sistem, dan proses jauh lebih penting. Ada ungkapan, “siapa pun bisa membangun organisasi yang punya engineer terbaik,” tetapi kenyataannya hanya sangat sedikit organisasi yang benar-benar berhasil membuat tim seperti itu. Hampir semuanya adalah perusahaan trading atau organisasi riset/khusus. Saya benar-benar heran kenapa hampir tidak ada yang bisa melakukannya. Pada akhirnya, bahkan konsep “produktivitas” sendiri pun tidak jelas artinya apa. Ada juga sistem evaluasi yang pada dasarnya menilai kemampuan seseorang untuk menahan dan menerobos dysfunction dalam organisasi, tetapi menurut saya itu bukan makna sejati dari ‘top engineer’

  • Pasokan engineer yang benar-benar hebat memang terbatas, sehingga perusahaan yang lebih besar pada akhirnya akan merebut talenta yang sama dengan menawarkan pekerjaan yang lebih menarik atau gaji lebih tinggi

  • Masalah uang yang disebut orang lain memang besar, tetapi ‘waktu’ juga sangat besar. Perusahaan tidak punya kelonggaran untuk menunggu sampai talenta “unicorn” yang sempurna muncul, dan akhirnya terpaksa mengisi posisi dengan orang yang bisa direkrut segera. Di beberapa perusahaan, khususnya bidang seperti quantitative finance, satu super engineer yang sekaligus menguasai system programming, matematika, dan pasar keuangan bisa menghasilkan nilai jauh lebih besar daripada tim yang terdiri dari tiga spesialis. Tetapi mencari orang seperti itu memakan waktu terlalu lama. Bahkan kalau hanya melihat web development, developer ‘full-stack’ sungguhan yang benar-benar paham secara luas mulai dari network protocol, system admin, distributed systems, database, sampai frontend, jumlahnya sangat sedikit. Hanya organisasi yang punya cukup waktu dan biaya yang bisa mengumpulkan talenta seperti ini untuk membuat produk terbaik. Tentu, apakah produknya benar-benar membutuhkan kualitas setinggi itu adalah pertanyaan terpisah

  • Pada dasarnya, pasokan “engineer terbaik” di seluruh dunia sangat terbatas. Jika Anda bisa membayar gaji level 10% teratas, dan mengumpulkan serta mempertahankan talenta sekelas itu, ya berarti berhasil. Sebenarnya ini bukan sesuatu yang bisa dibuat oleh ‘siapa saja’; dibutuhkan kepemimpinan yang mampu merancang sistem sosioteknis yang berfokus pada pembelajaran dan pertumbuhan. Itu sendiri sudah merupakan pekerjaan yang luar biasa

  • Masalah terbesarnya adalah kebanyakan eksekutif level satu dan dua tidak terlalu hebat. Mereka kurang mampu menciptakan dan mempertahankan lingkungan yang produktif. Solusi mendasarnya pada akhirnya adalah memberi ‘uang’ lebih banyak. Jika uangnya besar, kebanyakan kondisi sulit bisa ditoleransi

  • Terlepas dari persoalan anggaran, engineer yang benar-benar hebat justru mungkin tidak selalu baik untuk teamwork. Kecerdasan luar biasa kadang malah menjadi penghalang bagi kompromi yang diperlukan atau pekerjaan membosankan tetapi penting

• Saya sangat tidak setuju dengan klaim bahwa “dampak bisnis adalah satu-satunya metrik produktivitas.” Sudut pandang seperti ini menggeser perhatian ke perubahan yang bisa diukur dan hasil jangka pendek, lalu melewatkan nilai sejati dari engineer berpengalaman. Keahlian sejati justru tampak ketika seseorang mencegah landmine yang nyaris merusak proyek atau perusahaan. Tetapi ‘risiko yang hilang’ seperti ini sulit diukur, dan hampir mustahil dijelaskan dengan cara yang terdengar biasa saja

  • “Impact” tidak harus dilihat dari sudut pandang jangka pendek. Orang yang memberi dampak terbesar pada organisasi bergerak dengan perspektif jangka panjang

  • Saya sengaja membicarakan ‘produktivitas’ atau ‘impact’ sebagai istilah yang kabur. Misalnya seperti, “kalau dilihat secara keseluruhan, X benar-benar bekerja dengan sangat baik.” Hal seperti ini sulit dikuantifikasi maupun dirumuskan dengan jelas, tetapi memang dalam organisasi yang kompleks dan kreatif, wawasan dan penilaian manusia lebih penting. Upaya untuk selalu memaksa manajemen menjadi serba terukur pada dasarnya rabun jangka pendek

  • Saya tidak setuju kalau nilai engineer hanya diukur dari manajemen proyek atau penghindaran risiko, tetapi saya juga tidak nyaman jika semuanya direduksi menjadi ‘dampak bisnis’. Ada banyak hal di dunia yang bermakna bagi individu, umat manusia, dan dunia tanpa kaitan dengan uang. Engineer yang paling saya hormati bukan tokoh mitologis Silicon Valley pasca-2001, melainkan John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, seseorang yang membangun saluran air Romawi dan piramida Mesir, atau para astronom Babilonia-Mesoamerika. Apakah mereka meninggalkan dampak bisnis? Walaupun Tesla pernah memberi keuntungan pada Westinghouse, itu tidak menjelaskan pencapaiannya. Bahkan dalam urusan bisnis, dia biasa saja. Hal yang sama juga berlaku pada raksasa industri komputasi modern. Kesuksesan besar Nvidia atau Geoff Hinton juga sebagian dibantu oleh ‘keberuntungan’, yaitu ledakan data ketika internet menjadi sarana iklan. Ada banyak kasus ketika orang yang benar-benar hebat justru tersisih dan menghilang. Tokoh besar AI seperti Doug Lenat pun pada akhirnya bisa tidak terangkat oleh arus sejarah. Dalam banyak kasus, keberhasilan tidak ada hubungannya dengan usaha pribadi

  • Anda harus memilih antara membangun sistem yang efisien, atau sistem yang meminimalkan kemungkinan bencana. Bencana apa yang benar-benar berhasil dicegah pun sulit dibuktikan, dan dampak negatif itu sendiri adalah ‘kejadian yang tidak terjadi’, jadi sulit pula ditunjukkan sebagai hasil

  • Perusahaan harus berusaha sebaik mungkin untuk lebih mengkuantifikasi risiko dari ‘hal-hal yang belum diketahui’

• Untungnya, sejauh ini saya sudah bekerja di beberapa tim yang hebat, dan sekarang juga memimpin tim seperti itu. Berbeda dengan artikel tersebut, justru tim seperti ini sering kali lebih sulit dikelola oleh organisasi. Organisasi besar cenderung fokus pada standardisasi, sehingga engineer hebat malah sering tidak bisa menunjukkan kemampuannya dan kehilangan motivasi. Saya tidak setuju dengan pandangan pesimistis bahwa tidak semua orang bisa dibentuk menjadi engineer hebat. Faktanya, dengan investasi yang konsisten, orang bisa dibina menjadi engineer yang sangat baik, dan dalam jangka panjang manfaat dari memiliki kumpulan talenta unggul yang lebih besar cukup untuk melampaui biaya investasi itu

• Hanya karena sesuatu tidak bisa diukur secara efektif, bukan berarti hal itu tidak ada. Produktivitas individual, yaitu hasil kerja seseorang, jelas ada. Mungkin hanya saja produktivitas di tingkat grup lebih mudah diukur. “Dampak bisnis” justru jauh lebih sewenang-wenang, dan dengan metrik seperti itu akan sulit mempertahankan talenta yang benar-benar produktif. Menilai keahlian khusus sangat sulit kecuali jika Anda punya pengalaman yang setara; Anda bisa memberi saran, tetapi apakah lawan bicara punya kelapangan intelektual untuk menerimanya adalah hal lain. Bagaimana kita tahu apakah saya seorang jenius, atau cuma orang yang terlalu percaya diri

  • Masalahnya bukan bahwa produktivitas tidak bisa ‘diukur’, tetapi bahkan secara abstrak pun tidak bisa ‘didefinisikan’. Sekalipun Anda mengukur seberapa besar kontribusi seseorang dibandingkan replacement, itu tetap tidak menjelaskan secara pasti bagaimana hasil itu terbentuk. Pada kenyataannya, pengaruh individu ditentukan oleh konteks dan organisasi secara keseluruhan. Bahkan kalau mencoba membuat definisi yang lebih langsung, jawaban benarnya akan sangat berbeda-beda tergantung organisasi dan situasi. Ini layak dipikirkan, tetapi saya juga meragukan apakah standar ‘engineer Top 1%’ itu sendiri benar-benar bermakna

  • Jenius sejati bisa menjelaskan hasil kerjanya dengan mudah sambil tetap menjaga etiket. Jadi saya rasa perbedaannya tetap bisa dibedakan dengan cukup jelas

• Saya suka kalimat, “organisasi terbaik adalah yang membuat engineer normal bisa melakukan pekerjaan hebat.” Tidak semua anggota tim harus superstar. Yang benar-benar penting adalah seberapa baik dukungan yang diberikan agar developer rata-rata bisa menunjukkan kemampuan yang cukup bagus dan bisa diandalkan

  • Semua engineer hebat pada awalnya hanyalah engineer yang baik. Organisasi yang sehat membantu anggotanya menempuh jalur pertumbuhan itu

• Prinsip “membuat hal yang benar menjadi mudah, dan hal yang salah menjadi sulit” terasa seperti slogan inti semua tim platform yang pernah saya temui. Tujuannya adalah merancang sistem sehingga ‘jawaban yang benar’ untuk masalah yang dihadapi engineer otomatis terlihat jelas dan mudah diimplementasikan. Jika sistem dibangun dengan reliability dan kemudahan pengelolaan, lalu secara alami menumbuhkan ‘otot’ pengembangan ke arah itu, seluruh organisasi akan diuntungkan. Kebenaran ini akan tetap berlaku ke depan

  • Kebetulan Charity Majors pernah menulis esai yang sangat bagus tentang hal ini. Mulailah dengan membentuk komite kecil yang terdiri dari senior engineer tepercaya untuk membuat daftar rekomendasi komponen dasar yang akan dipakai layanan baru. Inilah yang menjadi ‘golden path’. Organisasi hanya memberi dukungan penuh pada komponen golden path, dan menyediakan semua fondasi seperti upgrade, patch, backup, deployment, environment, on-call, dan seterusnya. Tidak wajib dipakai, tetapi jika memilih sesuatu di luar golden path, Anda sendiri yang harus menanggung semuanya

• Setiap kali berbagai bahasa/framework seperti golang, python, COBOL, lisp, perl, React, brainfuck, dan sebagainya disebut, saya sudah lama merasa ada kecenderungan mengira React sebagai keseluruhan ekosistem frontend. Padahal dunia frontend di luar React juga sangat beragam, tetapi orang-orang tampaknya menganggap React adalah segalanya

• Di perusahaan kami, kami selalu lebih memilih merekrut engineer rata-rata yang sikapnya baik. Orang yang kualifikasinya bagus tetapi sikapnya buruk pandai membangun citra, sehingga mudah mendapat kepercayaan dari atasan, lalu setelah itu menjadi nyaris tak tersentuh. Begitu orang seperti ini menetap, orang di sekitarnya sulit mengangkat masalah meski merasa dirugikan. Atasan pun mudah mengabaikan data yang tidak sesuai dengan persepsinya. Jauh lebih mudah bersandar pada persepsi daripada pada data objektif

• Saya benar-benar setuju dengan gagasan bahwa “siapa pun bisa membangun organisasi yang dipenuhi engineer hebat, dan fokus pada kemampuan individu justru mengaburkan peran nyata seorang pemimpin. Membangun sistem yang memungkinkan engineer yang kurang terampil tetap bisa mengerahkan kemampuannya dan menghasilkan hasil adalah keunggulan kompetitif yang luar biasa.” Saya memang bukan engineer 10x, tetapi dari pengalaman saya belakangan ini, ketika tim punya banyak orang yang pengalaman dan kemampuannya kurang, saya sendirilah yang akhirnya menangani tiket-tiket kompleks. Jika pola ini berulang, pada akhirnya saya yang mengerjakan sebagian besar pekerjaan, dan peran itu terasa melelahkan sekaligus tidak adil. Terus terang, saya merasa SRE yang baik seharusnya punya sedikit sifat malas juga, jadi saya sangat ingin rekan setim membantu berbagi pekerjaan. Karena itu, saya bekerja sangat keras selama beberapa minggu untuk memperkenalkan berbagai abstraksi pada bagian yang paling kompleks (saya terutama menangani IAC; pola serupa juga berlaku di software). Hasilnya, engineer yang kemampuan atau pengalamannya relatif lebih rendah pun bisa mengambil sebagian peran saya, dan waktu saya jadi bisa dipakai untuk masalah yang lebih menarik. Ini pertama kalinya saya mencoba hal seperti itu tanpa ada yang menyuruh. Sebaliknya, tanpa struktur seperti ini, jika seseorang bertindak seperti pahlawan sendirian, seluruh tim hanya akan tertatih-tatih di belakang sambil membereskan kesalahan, dan akhirnya tim itu menjadi sangat tidak efisien sama sekali