2026-02-22 · 12 min · Engineering Leadership · Bahasa Indonesiawritten in Indonesian

Membangun Developer Berlandaskan Kasih

Dimas Sanjaya

Ada satu pertanyaan yang jarang ditanyakan di interview engineering lead: "Bagaimana kamu merespons ketika tim kamu melakukan kesalahan?"

Bukan pertanyaan teknis. Bukan tentang system design. Bukan tentang bagaimana kamu handle incident P0 di production. Tapi tentang sesuatu yang jauh lebih fundamental — bagaimana kamu memperlakukan manusia di balik kode itu.

Saya pernah ada di titik di mana seorang developer push konfigurasi yang salah ke production. Bukan typo kecil — ini mengakibatkan service down selama hampir 2 jam di jam sibuk. Sebagai lead, ada dua pilihan yang sangat mudah: menyalahkan dia di depan tim, atau diam dan biarkan semua orang tahu itu "bukan salah saya." Kedua opsi itu terasa natural. Kedua opsi itu juga sama-sama merusak.

Yang saya pilih waktu itu — dan yang terus saya pelajari untuk konsisten lakukan — berakar dari sesuatu yang saya yakini jauh sebelum saya jadi engineering lead. Sesuatu yang saya pelajari bukan dari buku Software Engineering at Google, tapi dari prinsip yang jauh lebih tua: kasih.

Kasih Bukan Perasaan — Kasih Adalah Keputusan

Kata "kasih" di Indonesia sering terdengar terlalu lembut untuk konteks profesional. Terlalu rohani. Terlalu abstrak. Tapi justru di situlah kesalahpahaman dimulai.

Dalam tradisi Kristen, kata yang diterjemahkan menjadi "kasih" berasal dari bahasa Yunani agapē — dan ini bukan soal perasaan hangat atau sentimen. Agapē adalah tindakan yang disengaja untuk mendahulukan kepentingan orang lain, bahkan ketika itu tidak menguntungkan diri sendiri. Paulus menulis di 1 Korintus 13: kasih itu sabar, kasih itu murah hati, tidak mencari keuntungan diri sendiri, tidak menyimpan kesalahan orang lain.

Sekarang coba ganti kata "kasih" dengan "leadership" di kalimat itu.

Leadership itu sabar. Leadership itu murah hati. Leadership tidak mencari keuntungan diri sendiri. Leadership tidak menyimpan kesalahan orang lain.

Tiba-tiba terdengar seperti deskripsi engineering lead yang ideal, bukan?

Ini bukan kebetulan. Robert K. Greenleaf, pencetus konsep servant leadership di tahun 1970, mendefinisikan pemimpin sejati sebagai seseorang yang melayani terlebih dahulu, baru kemudian memilih untuk memimpin. Pertanyaan ujinya tajam: "Apakah orang-orang yang kamu layani bertumbuh? Apakah mereka menjadi lebih bijak, lebih bebas, lebih mandiri — dan apakah mereka sendiri kemudian menjadi pelayan?"

Google — ya, perusahaan teknologi Google — menuliskan hal yang hampir identik di buku Software Engineering at Google: bahwa obat untuk penyakit "manajemen" adalah penerapan servant leadership secara liberal. Framework kepemimpinan engineering mereka dibangun di atas tiga pilar: Humility, Respect, dan Trust (HRT). Pemimpin engineering, menurut Google, seharusnya berfungsi seperti butler — memastikan tim punya semua yang mereka butuhkan untuk berhasil, bukan menjadi pusat perhatian.

Ketika prinsip yang ditulis Paulus 2000 tahun lalu dan framework yang dibangun Google dari data ribuan tim engineering sampai di kesimpulan yang sama — itu bukan kebetulan. Itu sinyal.

Empat Tipe Developer — Dan Cermin untuk Diri Sendiri

Selama bertahun-tahun memimpin tim engineering, saya mengamati satu pola yang konsisten. Bukan soal skill teknis — dua developer dengan kemampuan coding yang identik bisa punya dampak yang sangat berbeda terhadap tim. Perbedaannya ada di karakter, khususnya di bagaimana mereka merespons kesalahan.

Saya membaginya jadi empat tipe. Dan sebelum Anda membaca ini sebagai penghakiman terhadap orang lain — saya minta Anda membacanya sebagai cermin. Karena saya sendiri pernah ada di setiap level ini.

1. Developer Biasa — "Itu bukan salah saya."

Ini developer yang ketika production error terjadi, refleks pertamanya adalah self-preservation. Log dicek bukan untuk mencari root cause, tapi untuk membuktikan bahwa bukan kode dia yang bermasalah. Kalau ternyata memang kodenya — diam. Kalau ditanya, defleksi. "Spek-nya memang tidak jelas." "QA harusnya catch ini." "Itu kan environment-nya yang beda."

Secara teknis, bisa jadi dia benar. Mungkin memang spek-nya ambigu. Mungkin QA memang miss. Tapi yang terjadi di level yang lebih dalam adalah sesuatu yang merusak: penolakan untuk mengakui bahwa dirinya bagian dari masalah.

Riset Amy Edmondson tentang psychological safety di Harvard menemukan hal yang kontra-intuitif: tim dengan performa terbaik justru melaporkan lebih banyak kesalahan, bukan lebih sedikit. Bukan karena mereka lebih ceroboh — tapi karena mereka merasa aman untuk jujur. Ketika satu orang di tim secara konsisten menolak mengakui kesalahan, efeknya menjalar. Orang lain belajar bahwa vulnerability itu tidak aman. Error mulai disembunyikan. Bug di-fix diam-diam tanpa postmortem. Tim kehilangan kemampuan belajar.

Developer Biasa bukan developer yang buruk secara teknis. Tapi dia menciptakan culture debt — hutang budaya yang bunganya dibayar seluruh tim.

2. Developer Gentleman — "Saya yang salah, maaf."

Naik satu level. Developer ini, ketika terbukti kodenya yang menyebabkan masalah, mengakui dan meminta maaf. Langsung. Tanpa berbelit-belit. Tanpa "maaf tapi..."

Ini terdengar basic, tapi di industri yang penuh ego dan imposter syndrome secara bersamaan, kemampuan mengatakan "saya yang salah" dengan tulus itu langka dan mahal. Ini membutuhkan sesuatu yang Jocko Willink sebut extreme ownership — keberanian untuk mengambil tanggung jawab penuh atas hasil, bukan hanya effort.

Developer Gentleman membangun sesuatu yang tidak terlihat di Jira board atau sprint velocity: trust. Penelitian dari Frontiers in Psychology (2022) yang menganalisis 53 studi independen dengan 16.534 subjek menemukan korelasi 0.62 antara humble leadership dan affective trust. Artinya, kerendahan hati — yang manifestasinya paling sederhana adalah mengakui kesalahan — adalah prediktor terkuat kedua dari kepercayaan tim, setelah competence itu sendiri.

Tapi Developer Gentleman punya batasan. Dia mengakui kesalahan ketika jelas itu salahnya. Ketika situasinya ambigu? Ketika tidak jelas siapa yang salah? Di situlah tipe berikutnya muncul.

3. Developer Bijak — "Saya tidak tahu siapa yang salah, tapi izinkan saya minta maaf duluan."

Ini level yang mulai tidak masuk akal secara logika konvensional.

Production incident terjadi. Root cause analysis belum selesai. Bisa jadi kodenya, bisa jadi infrastruktur, bisa jadi requirement yang berubah tanpa tertulis. Belum ada yang tahu. Dan di tengah ketidakjelasan itu, Developer Bijak melangkah maju: "Saya belum tahu persis masalahnya di mana, tapi saya mau minta maaf kalau ada bagian dari kerjaan saya yang berkontribusi ke situasi ini. Mari kita cari tahu bareng."

Kenapa ini bijak dan bukan bodoh?

Karena dia memahami sesuatu yang mendalam: meminta maaf bukan pengakuan bersalah — tapi deklarasi bahwa hubungan lebih penting daripada ego. Dalam konteks Kristen, ini tercermin di sikap Kristus sendiri yang menanggung beban yang bukan beban-Nya, bukan karena Dia bersalah, tapi karena kasih mendahulukan orang lain.

Secara psikologis, inilah yang menciptakan psychological safety paling efektif. Ketika seseorang di tim — apalagi yang senior — berani meminta maaf di situasi ambigu, itu mengirim sinyal: "di tim ini, kebenaran lebih penting daripada siapa yang benar." Google Project Aristotle menemukan bahwa psychological safety adalah faktor nomor satu — di atas dependability, structure, meaning, dan impact — yang membedakan tim biasa dari tim luar biasa.

Developer Bijak juga memahami prinsip yang diajarkan Etsy dalam blameless postmortem culture mereka: ketika engineer merasa aman memberikan detail tentang kesalahan, mereka bukan hanya bersedia dimintai pertanggungjawaban — mereka justru antusias membantu seluruh organisasi menghindari kesalahan yang sama. Accountability dan forgiveness bukan berlawanan. Keduanya saling membutuhkan.

4. Developer Ideal — "Saya tahu saya benar, tapi saya tetap mau minta maaf."

Ini level yang paling sulit diterima akal. Dan jujur — ini level yang saya masih terus pelajari.

Bayangkan skenario ini: Anda lead sebuah tim. Anda sudah memberikan guideline yang jelas tentang proses deployment. Seorang developer mengabaikan guideline itu, deploy langsung tanpa melalui staging, dan production down. Root cause jelas: bukan Anda. Secara teknis, secara prosedural, Anda benar. Anda bahkan punya bukti tertulis — Slack message, documentation, meeting notes.

Developer Ideal — atau mungkin lebih tepat, Lead Ideal — tetap maju dan berkata: "Ini terjadi di tim saya. Saya minta maaf. Saya yang akan memastikan ini tidak terulang."

Gila? Mungkin. Tapi Jim Collins menemukan pola identik ini di riset Good to Great-nya: dari 1.435 perusahaan Fortune 500, semua 11 perusahaan yang berhasil melompat dari "good" ke "great" dipimpin oleh apa yang Collins sebut Level 5 Leaders. Ciri khas mereka: window-and-mirror asymmetry. Ketika sukses, mereka melihat keluar jendela — memuji tim dan faktor eksternal. Ketika gagal, mereka melihat ke cermin — mengambil tanggung jawab pribadi.

Dalam tradisi Kristen, ini bukan konsep asing. Yesus membasuh kaki murid-murid-Nya di Yohanes 13 — tugas yang begitu rendah sehingga bahkan pelayan Yahudi menolak melakukannya. Yang paling tinggi melakukan pekerjaan yang paling rendah. Bukan karena dipaksa, bukan karena tidak punya kuasa — justru karena punya kuasa penuh dan memilih untuk melayani.

Anda tidak harus jadi lead untuk mempraktikkan ini. Seorang developer yang melihat rekan kerjanya struggle dengan bug dan memilih untuk pair programming alih-alih berkata "itu bukan task saya" — itu sudah manifestasi dari prinsip yang sama. Seorang junior yang berani bilang ke tim "saya yang akan investigate ini, meskipun saya tidak yakin itu kode saya" — itu Developer Ideal dalam bentuk paling awal.

Intinya bukan di posisi. Intinya di pilihan untuk menanggung lebih dari yang seharusnya, demi kebaikan tim.

Yang Paling Sulit: Mengubah Diri Sendiri Dulu

Sekarang, setelah membaca empat tipe itu, mungkin ada dorongan kuat untuk langsung mencocokkan nama-nama rekan kerja Anda ke masing-masing tipe. "Oh, si A itu pasti Tipe 1. Si B lumayan, Tipe 2 lah."

Berhenti di situ.

Karena prinsip paling penting dari seluruh artikel ini bukan tentang menilai orang lain — tapi tentang menilai diri sendiri terlebih dahulu.

Yesus mengajarkan ini dengan metafora yang sangat tajam di Matius 7:3-5: mengapa kamu melihat selumbar di mata saudaramu, tapi tidak menyadari balok di matamu sendiri? Perintahnya jelas — keluarkan dulu balok dari matamu, baru kamu bisa melihat dengan jernih untuk menolong orang lain.

Ini bukan nasihat pasif. Ini adalah arsitektur perubahan.

Stephen Covey, di buku 7 Habits of Highly Effective People, menstrukturkan hal yang sama menjadi framework: tiga kebiasaan pertama — Be Proactive, Begin with the End in Mind, Put First Things First — semuanya tentang Private Victory. Kemenangan atas diri sendiri. Baru setelah itu, seseorang bisa bergerak ke Public Victory — mempengaruhi dan memimpin orang lain.

Covey juga memperkenalkan Circle of Influence vs Circle of Concern. Orang-orang reaktif menghabiskan energi di lingkaran concern — mengkritik atasan, mengeluh soal kebijakan perusahaan, frustasi dengan developer lain yang "tidak mau berubah." Energi itu tidak menghasilkan apa-apa selain kelelahan dan sinisme. Orang-orang proaktif memfokuskan energi di lingkaran influence — hal-hal yang bisa mereka kontrol, yaitu diri mereka sendiri. Dan ironisnya, semakin mereka fokus ke lingkaran influence, semakin lingkaran itu membesar.

Filsuf Stoic Epictetus mengajarkan model kematangan tiga tahap yang brutal dalam kesederhanaannya: Orang yang tidak terdidik menyalahkan orang lain. Orang yang mulai terdidik menyalahkan diri sendiri. Orang yang sudah terdidik sepenuhnya tidak menyalahkan siapapun.

Marcus Aurelius menulis: "Bersikap toleran kepada orang lain, dan bersikap ketat kepada diri sendiri."

Saya menuliskan ini bukan dari posisi sudah sempurna — justru sebaliknya. Saya menulis ini karena saya tahu betapa sulitnya. Ada hari-hari di mana saya ingin langsung menegur developer yang mengabaikan code review guideline untuk kesekian kalinya. Ada momen di mana saya ingin forward Slack message sebagai "bukti" bahwa saya sudah peringatkan. Tapi setiap kali dorongan itu muncul, saya belajar untuk berhenti dan bertanya: "Apa yang bisa saya lakukan berbeda sebagai lead sehingga ini tidak terjadi?"

Mungkin guideline saya kurang jelas. Mungkin saya tidak cukup sering melakukan one-on-one. Mungkin saya terlalu mengandalkan dokumentasi tertulis untuk hal yang seharusnya disampaikan lewat conversation. Mungkin ada tekanan dari tim yang tidak saya lihat.

Selalu ada balok di mata sendiri yang bisa dikeluarkan terlebih dahulu.

Kenapa Ini Penting Secara Bisnis (Bukan Hanya Secara Moral)

Mungkin Anda berpikir: "Ini semua bagus untuk khotbah Minggu, tapi apa relevansinya dengan delivery, sprint velocity, dan business metrics?"

Data menjawab dengan cukup keras.

Ron Westrum mengklasifikasikan budaya organisasi menjadi tiga tipe: patologis (menembak si pembawa kabar buruk), birokratis (mengabaikan si pembawa kabar buruk), dan generatif (melatih si pembawa kabar buruk). Budaya generatif adalah budaya di mana kasih — dalam bentuk trust, safety, dan accountability — menjadi fondasi operasional, bukan sekadar nilai di dinding kantor.

Kasih — dalam bentuk humble leadership, psychological safety, dan blameless accountability — bukan soft skill. Ini adalah retention strategy dengan dampak finansial langsung.

Satya Nadella membuktikan ini di skala besar ketika mengubah budaya Microsoft dari know-it-all menjadi learn-it-all pada 2014. Dia mengubah evaluasi performa dari kompetisi individual menjadi seberapa banyak seseorang membantu timnya. Hasilnya: market value bergerak dari $300 miliar ke lebih dari $2.5 triliun. Edsger Dijkstra, penerima Turing Award, sudah mengartikulasikan ini sejak 1972 dalam kuliah yang berjudul "The Humble Programmer" — programmer yang kompeten adalah programmer yang sadar sepenuhnya akan keterbatasan otaknya sendiri, sehingga mendekati setiap tugas dengan kerendahan hati.

Perubahan Dimulai dari Satu Orang

Saya tidak menulis artikel ini untuk mengubah industri. Saya menulisnya karena saya percaya pada satu hal: kita tidak bisa mengubah orang lain, tapi kita bisa mengubah diri kita sendiri — dan perubahan itu menular.

Riset tentang social contagion dalam organisasi menunjukkan bahwa perilaku pemimpin secara literal ditiru oleh tim melalui mekanisme mirror neuron di otak. Ketika seorang lead secara konsisten menunjukkan kerendahan hati — mengakui ketika dia tidak tahu jawaban, meminta maaf ketika salah, memberi credit ke tim ketika berhasil — perilaku itu menyebar. Owens & Hekman (2016) menemukan bahwa leader humility menciptakan collective humility, yang kemudian menghasilkan performa tim yang lebih tinggi.

Anda tidak butuh persetujuan manajemen untuk mulai. Anda tidak butuh initiative resmi dari HR. Anda hanya butuh keputusan pribadi untuk:

Ini tidak mudah. Ini bukan satu kali keputusan lalu selesai — ini adalah disiplin harian yang kadang terasa bertentangan dengan setiap insting self-preservation yang kita punya.

Tapi setiap kali saya melihat developer yang tadinya takut bicara di standup mulai dengan percaya diri share blocker-nya — karena dia tahu tim-nya aman — saya tahu ini worth it. Setiap kali postmortem berubah dari sesi saling tunjuk menjadi diskusi kolaboratif tentang "bagaimana kita improve bareng" — saya tahu ini bukan teori kosong.

Kasih — yang sabar, yang murah hati, yang tidak mencari keuntungan diri sendiri, yang tidak menyimpan kesalahan orang lain — ternyata bukan hanya prinsip rohani. Ini adalah strategi engineering leadership yang paling under-rated dan paling powerful yang pernah saya praktikkan.

Dan itu dimulai bukan dari tim. Bukan dari organisasi. Bukan dari industri.

Dimulai dari cermin.

"Kasih itu sabar; kasih itu murah hati; ia tidak cemburu. Ia tidak memegahkan diri dan tidak sombong. Ia tidak melakukan yang tidak sopan dan tidak mencari keuntungan diri sendiri. Ia tidak pemarah dan tidak menyimpan kesalahan orang lain." — 1 Korintus 13:4-5

Saya percaya bahwa perubahan terbesar di tim engineering dimulai bukan dari kode, tapi dari hati. Bagaimana pengalaman Anda memimpin dengan kasih?