Engineering tanpa ego: pelajaran dan wawasan
Pendahuluan
- Di industri teknologi, ego dan parokialisme (faksionalisme) menjadi faktor utama yang menghambat kerja tim
- Berbagi wawasan yang diperoleh dari memikirkan cara membuat tim engineering lebih efisien dan kolaboratif
Dilema pembagian tanggung jawab
- Bahkan jika hanya ada dua karyawan, pembagian pekerjaan tetap wajib dilakukan
- Namun cara pembagiannya dapat memberi dampak langsung maupun jangka panjang
- Banyak perusahaan tidak memikirkan masalah ini secara mendalam
Realitas ilmu komputer
- Banyak ilmuwan komputer baru belakangan menyadari bahwa mereka masuk ke bidang yang berkaitan dengan kerja abstrak matematis
- Guncangan awal ini membuat banyak orang sepanjang kariernya enggan menerapkan apa yang dipelajari ke bidang di luar komputer
- Jika lingkungan kerja dipikirkan sedalam pendekatan teknis, ada peluang untuk memperbaikinya
Penyakit organisasi dan pengalaman
- Bahkan perusahaan yang sukses pun sulit menghindari penyakit organisasi, dan dari sana ada hal yang bisa dipelajari
- Contoh startup tempat penulis menjalani awal karier:
- Meski perusahaan masih kecil dan berada di tahap awal, strukturnya sudah terlalu birokratis
- Menambahkan "middleware Python" berdasarkan teori keliru bahwa itu akan mempercepat permintaan web
- Hasilnya justru lebih banyak network hop dan performa menurun
- Untuk merilis satu fitur, dibutuhkan kolaborasi rumit antarbanyak peran
- Orang database menulis DDL dan mengembangkan stored procedure
- Developer Python mengerjakan middleware yang tidak efisien
- Developer PHP menulis kode frontend
- Karena struktur pembagian kerja ini, selama dua tahun tidak ada satu pun fitur baru yang berhasil dirilis
- Hasil akhirnya
- Karena struktur dan alur kerja yang tidak efisien, seluruh karyawan dipecat
- Bukan saya. Saya selamat karena banyak mengeluh
Masalah diferensiasi peran di perusahaan besar
- Latar belakang: bekerja di perusahaan produk B2B dengan lebih dari 1.000 karyawan
- Pada awalnya menerapkan struktur tim fungsional yang terbagi jelas antara Feature Teams dan tim layanan bersama (operasi, DBA, dll.)
- Awalnya tampak seperti struktur yang lazim
- Seiring waktu, peran menjadi terlalu terfragmentasi dan inefisiensi meningkat
- Menambahkan peran baru bernama "Release Manager" untuk mengelola rilis
- Alasan penambahan peran tidak jelas, dan struktur organisasi makin lama makin rumit
- Contoh masalah:
- Engineer frontend dibatasi hanya mengerjakan frontend, engineer backend hanya backend
- Pemisahan ini masih bisa bertahan, tetapi kebijakan bahwa tim keamanan menangani semua pekerjaan keamanan menimbulkan masalah serius
- Akibat: ketika peran disamakan dengan pekerjaan, efisiensi organisasi jadi terganggu
- Muncul kekurangan kolaborasi antar tim dan duplikasi pekerjaan
Portofolio produk yang tersebar dan ketiadaan struktur pengawasan
- Bekerja di perusahaan yang terutama mengembangkan aplikasi klien native
- Pada awalnya ada aplikasi klien andalan yang sukses, tetapi pada 2020-an proyek-proyek yang tersebar dan tidak konsisten berjalan paralel
- Masalah dalam pengelolaan portofolio produk
- Struktur pengawasan atas keseluruhan produk lemah
- Tidak ada koordinasi sama sekali antarpoduk dalam tech stack maupun pengambilan keputusan
- Tiap tim produk melapor langsung ke CEO secara terpisah, dan CEO tidak berupaya melakukan koordinasi
- Upaya membangun fungsi operasi bersama
- Kesulitan muncul karena grup operasi tidak terlibat dalam proses pengambilan keputusan arsitektur
- Tim operasi sibuk mengelola ratusan layanan yang dulu digunakan tim pengembang sehingga tidak punya waktu ikut serta dalam keputusan penting
- Ini dapat dilihat sebagai contoh khas inefisiensi organisasi
[Menggeneralisasi pola masalah organisasi]
Pola 1: Kebingungan antara peran dan pekerjaan
- Ada kecenderungan membuat deskripsi jabatan baru untuk pekerjaan baru
- Contoh: meski pekerjaan terkait AI bisa ditangani engineer yang ada, perusahaan malah membuat peran baru bernama AI engineer
- Ini memicu konflik dalam organisasi dan dapat melemahkan motivasi anggota tim yang sudah ada
- Pemisahan peran yang berlebihan seperti ini menimbulkan birokrasi yang tidak perlu
Pola 2: Distribusi yang tidak lengkap dari revolusi DevOps
- Banyak perusahaan mengklaim telah "menerapkan DevOps", tetapi pada kenyataannya pembagian kerja dan konflik tetap ada
- Batas tegas antara tim operasi dan tim pengembang, atau antara SRE dan tim pengembang, menghambat kolaborasi
- Tujuan asli DevOps adalah meruntuhkan batas melalui kolaborasi dan empati, tetapi dalam praktiknya hal ini jarang terwujud
Pola 3: Batas pembagian kerja yang kaku
- Memecah dan mengkhususkan pekerjaan mungkin tampak wajar bagi pemimpin
- Contoh: pekerjaan AI dikhususkan untuk pakar AI, pekerjaan operasi hanya untuk petugas operasi
- Tetapi struktur seperti ini menimbulkan bottleneck
- Engineer tambahan mencoba mempercepat laju dengan menciptakan pekerjaan baru, tetapi akibatnya waktu tunggu analisis meningkat secara nonlinier
- Ketika resource data scientist atau analisis mencapai batasnya, seluruh proses melambat
Pola 4: Struktur organisasi yang salah menciptakan pekerjaan tambahan
- Jika batas organisasi tidak jelas atau ditetapkan secara keliru, jumlah pekerjaan yang tidak perlu akan meningkat
- Contoh: tim keamanan menangani semua masalah keamanan dan muncullah antrean tiket keamanan
- Tim pengembang terus bekerja tanpa mempertimbangkan keamanan, sehingga pada akhirnya pekerjaan keamanan bertambah
- Ini mungkin diabaikan dalam jangka pendek, tetapi dalam jangka panjang berkembang menjadi masalah serius
Pola 5: Bias manusia yang kronis
- Ada kecenderungan melebih-lebihkan peran sendiri dan meremehkan peran orang lain
- Sebagian orang keliru menilai bahwa pekerjaan server "tidak teknis"
- Sebaliknya, cukup umum juga menganggap pekerjaan produk kurang teknis
- Sikap seperti ini melemahkan kepercayaan antar tim dan menghambat kolaborasi
- "Sosok dogmatis yang brilian" tidak memberi nilai nyata dari sudut pandang sistemik
- Pemimpin dan organisasi sering keliru menilai sikap seperti ini sebagai sesuatu yang "cerdas" atau "bernilai"
[Parokialisme dan ego]
- Parochialism dan ego adalah penyebab utama inefisiensi dalam organisasi
- Parokialisme: sikap enggan memasuki wilayah orang lain atau kurangnya rasa ingin tahu
- Ego: kebanggaan terhadap pekerjaan yang kadang berdampak positif, tetapi juga bisa muncul sebagai sikap menjaga wilayah atau meremehkan kemampuan orang lain
- Perilaku instingtif ini menyebabkan kurangnya empati dan menghambat kolaborasi
Contoh yang lebih baik: pengalaman di tim engineering yang sukses
- Di sebuah startup terdahulu, struktur "fiefdom" yang terpisah secara horizontal disederhanakan dan dirombak menjadi tim-tim yang lebih kecil
- Para pemimpin yang sungguh-sungguh menerapkan DevOps meruntuhkan hambatan dan mendorong kolaborasi
- Melalui sekitar dua tahun "penghancuran kreatif", semua anggota tim ikut terlibat dalam beragam pekerjaan
- Hasilnya, stabilitas infrastruktur dan kemampuan merilis software pulih kembali
- Setelah reorganisasi, tim engineering mendapatkan waktu dan otonomi
- Berdasarkan itu, mereka mendiskusikan bagaimana memanfaatkan kapasitas tambahan tim
Usulan 1: Refactoring besar-besaran (Proposition 1: Boil the Ocean)
- Sering kali tim menggunakan sumber daya luang untuk merombak total bagian-bagian yang mereka benci
- Namun ini adalah cara yang sudah pernah dicoba dan tidak populer
Usulan 2: Aktivitas "pamer diri" (Proposition 2: Dress Like Big Dorks)
- Menggunakan waktu senggang tim untuk membuat merchandise dan hal lain yang menonjolkan budaya tim
- Namun ini tidak cocok sebagai strategi utama
- Peristiwa penentu: error build dari desainer
- Suatu malam, seorang desainer merusak build dan tim harus memulihkannya
- Pada awalnya muncul pendapat bahwa peran antara desainer dan coder harus dibagi lebih jelas
- Namun seseorang di tim mengambil keputusan berani dengan langsung memberikan deployment key kepada desainer
- Hasilnya:
- Desainer ikut terlibat dalam pekerjaan kode dan tingkat kolaborasi meningkat
- Tim membangun monitoring, test suite, dan sebagainya untuk menciptakan lingkungan kerja yang aman
- Efisiensi kerja dan produktivitas meningkat drastis
Usulan 3: Memberdayakan tim lain (Proposition 3: Empower Everybody Else)
- Mengadopsi strategi memanfaatkan kapasitas luang tim untuk mendukung dan memberdayakan tim lain
- Berlaku untuk tim teknis maupun nonteknis
- Mendorong kolaborasi di seluruh organisasi dan berujung pada eksekusi yang efektif
Kemauan untuk mempraktikkan
- Setelah kasus desainer itu, mereka bekerja sama dengan berbagai grup dan mengalami keberhasilan serupa
- Mereka memanfaatkan waktu bebas dan kewenangan organisasional tim agar tiap tim bisa berkolaborasi secara efektif
- Eksekusi yang sukses dibangun di atas kolaborasi dan empati lintas perusahaan
[Bagaimana rasanya eksekusi yang sukses]
- Pakar vs. pemilik
- Tim memiliki pakar domain, tetapi tidak memiliki "pemilik" untuk tugas atau domain tertentu
- Contoh keamanan: alih-alih tim keamanan menangani semua masalah, seluruh tim bertanggung jawab atas keamanan dan tim keamanan berperan meningkatkan kemampuan anggota tim
- Model ini seharusnya diterapkan juga di bidang lain, tetapi kebanyakan tim gagal mewujudkannya
- Contoh kegagalan
- Engineer frontend dan backend dipisahkan secara ketat
- Kekurangan kolaborasi menimbulkan kompleksitas yang tidak perlu seperti GraphQL
- Pakar untuk peran tertentu memang diperlukan, tetapi membagi jabatan menjadi "frontend" dan "backend" itu tidak efisien
- Prinsip inti:
- "Pakar domain, bukan pemilik"
- Dorong para pakar untuk memiliki waktu membantu anggota tim lain di luar pekerjaan utama mereka
Mendorong kolaborasi proaktif
- Menyediakan waktu luang
- Berikan anggota tim waktu luang agar kerja sama tim secara keseluruhan tetap terjaga
- Jangan hanya menunggu kolaborasi terjadi secara alami, tetapi sengaja beri energi pada sistem
- Keamanan psikologis dan memperluas in-group
- Orang merasa aman secara psikologis untuk bereksperimen atau mempelajari hal baru di dalam kelompok tempat mereka merasa menjadi bagian
- Investasikan waktu dan sumber daya untuk memperluas "in-group" anggota tim
- Bootcamp: memberi kesempatan kolaborasi dengan memaksa orang bekerja di tim lain
- Hackathon: digunakan sebagai acara dengan efek serupa
Nilai tim yang disengaja
- Menetapkan filosofi dan prinsip tim
- Definisikan dengan jelas tujuan yang lebih tinggi dari berbagai aktivitas seperti code review, bootcamp, hackathon, dan lainnya
- Nyatakan bahwa elitisme adalah racun
- Bangun budaya di mana setiap orang "langsung menangani pekerjaan yang perlu dilakukan"
- Kepercayaan timbal balik dan ekspektasi perbaikan
- Tetapkan ekspektasi kuat bahwa ketika menangani hasil kerja orang lain, kita harus selalu meninggalkannya dalam keadaan yang lebih baik
- Budaya seperti ini mendorong anggota tim untuk mau berkolaborasi
Pemikiran penutup
- Masalah industri teknologi: elitisme dan kepemimpinan dogmatis
- Pemimpin dogmatis yang tidak memiliki kerendahan hati menghambat kolaborasi tim dan mendorong kekejaman yang tidak perlu
- Industri teknologi sering salah mengira pemimpin semacam itu sebagai sosok yang berguna, padahal itu fenomena yang parasitis dan merugikan
- Tidak seharusnya bersikap menghormati orang lain terasa radikal, tetapi kenyataannya memang begitu
- Kolaborasi membawa hasil yang lebih baik
- Kolaborasi memperbaiki hasil, dan hidup tanpa pemimpin yang dogmatis itu lebih baik
- Diperlukan upaya untuk menyingkirkan parokialisme dan ego
- Pentingnya pemberdayaan
- Agar anggota tim terdorong untuk penasaran dan berkolaborasi, dibutuhkan izin dan dukungan dari pemimpin
- Contoh: mengubah pekerjaan deployment agar ditangani langsung oleh developer, bukan SRE
- Pada awalnya ada kekhawatiran tentang kesalahan developer, tetapi sebagian besar developer berhasil menyelesaikan masalah sendiri
- Product engineer menunjukkan sikap ingin menangani masalah sendiri
- Memberikan slack pada sistem
- Program seperti bootcamp atau hackathon memerlukan komitmen berkelanjutan
- Program-program ini mudah hilang jika sistem tidak memiliki slack
- Kita tidak menjalankan komputer pada 100%, tetapi kita cenderung ingin memperlakukan diri kita sendiri seperti itu
- Pentingnya nilai dan penghargaan
- Pemimpin harus memberi penghargaan pada kolaborasi dan rasa ingin tahu lalu menanamkannya sebagai budaya tim
- CEO sering mencoba menghapus program positif seperti bootcamp dan hackathon, tetapi kurang berupaya menghapus program negatif seperti code review yang wajib
- Keyakinan keliru bahwa "rasa sakit" menghasilkan hasil harus ditinggalkan
- Rasa sakit bukan indikator pengganti yang baik untuk hasil, dan kolaborasi serta kepercayaan membawa kinerja yang lebih baik
7 komentar
> Untuk mendorong anggota tim agar berkolaborasi dengan rasa ingin tahu, dibutuhkan izin dan dukungan dari pemimpin.
Tampaknya penting untuk mendorong agar memiliki rasa ingin tahu terhadap area rekan satu tim, meski itu bukan bidangnya sendiri!
Kenyataannya...!
Sepertinya ini memang struktur yang mustahil di startup waejail yang tiap hari terus mendesak soal progres..
Semua praktisi di lapangan harus bisa terus mempertahankan ketertarikan awal mereka saat masuk kerja, tetapi dukungan untuk aspek seperti itu biasanya tidak ada atau kurang.
Semua yang dikatakannya memang benar sekali..
Tapi kenyataannya.................. T_T
Sepertinya ini tulisan yang sangat bagus!
Tulisan yang bagus.
Opini Hacker News
Ada pendapat bahwa menyingkirkan ego programmer dalam pengembangan perangkat lunak itu penting. Melihat produk perangkat lunak sebagai hasil kerja tim melalui kolaborasi adalah hal yang diinginkan.
Sebagai pelajaran dari karier di bidang pengembangan, disarankan untuk tidak menambahkan proses yang tidak perlu, menuntut rasa kepemilikan atas produk di semua peran, menghindari keputusan yang reaktif, dan mendorong kolaborasi antar tim.
Tim terbaik terdiri dari tim pizza yang memiliki seluruh stack dan para spesialis yang memberikan saran saat dibutuhkan.
Ada pendapat bahwa metafora olahraga tidak populer di bidang teknologi, tetapi dinamika tim olahraga mirip dengan tim bisnis yang baik.
Keberhasilan organisasi bergantung pada tiap anggotanya yang bertindak tanpa pamrih untuk memenuhi kebutuhan kelompok.
Ditekankan pentingnya penetapan nilai tim secara sengaja.
Saat bekerja di divisi growth, pada awalnya manajer meninjau dan menggabungkan semua commit, tetapi kemudian disadari bahwa ada wewenang untuk melakukan deploy ke production secara langsung.
Pakar domain lebih disukai daripada pemilik domain, dan spesialisasi yang terlalu eksplisit dapat menimbulkan masalah.