Leader Tidak Ngurus atau Tidak Paham Teknis?!

Belakangan, kalimat "Leader itu nggak perlu ngurusin hal teknis" semakin sering saya dengar, terutama di perusahaan yang sedang gencar melakukan digitalisasi. Di permukaan, pernyataan ini terdengar logis. Seorang pemimpin memang seharusnya fokus pada arah, strategi, dan pengembangan orang—bukan bergelut dengan detail operasional atau teknis.

Tapi ada yang mengusik ketika kalimat itu diucapkan oleh orang yang memang tidak punya pemahaman teknis sama sekali, lalu menjadikannya tameng. Seolah-olah ketidaktahuan adalah sebuah hak prerogatif jabatan.

Ada perbedaan mendasar antara tidak mengurus dan tidak paham. Perbedaan inilah yang ingin saya uraikan di sini, karena dampaknya—langsung maupun tidak—akan dirasakan oleh tim.

Doktrin yang Disalahpahami

Gagasan bahwa pemimpin cukup mengurus "gambaran besar" sebenarnya lahir dari kebutuhan akan spesialisasi. Organisasi yang tumbuh besar memecah pekerjaan ke dalam fungsi-fungsi spesifik. Direktur Keuangan tidak perlu membuat jurnal akuntansi setiap hari. Kepala Pemasaran tidak harus bisa mendesain sendiri materi promosi.

Prinsip ini masuk akal. Namun, persoalan muncul ketika ia direduksi menjadi: "Kalau saya tidak perlu mengerjakan, berarti saya tidak perlu paham."

Pahami bedanya: saya tidak harus terjun langsung memperbaiki proses administrasi HR atau payroll di akhir bulan, tapi saya perlu tahu bagaimana alurnya, di mana titik rawan selisihnya, dan apa yang membuat proses itu bisa memakan waktu tiga hari. Saya tidak harus bisa menulis kode program, tapi saya perlu memahami sistem seperti apa yang menjadi tulang punggung operasional.

Di banyak tempat, batas antara "tidak mengeksekusi" dan "tidak memahami" ini sengaja dikaburkan. Biasanya, oleh mereka yang memang tidak punya pemahaman, dan lebih memilih berlindung di balik jabatan.

Tameng yang Rapi

Pola yang kerap saya lihat: setiap kali ada diskusi yang mulai menyentuh detail, seorang leader akan menghindar dengan kalimat, "Itu ranah teknis, saya tidak perlu ikut campur." Ketika timnya tersendat, respons yang muncul adalah, "Coba cari solusinya sendiri, itu kan tugas kalian."

Secara delegasi, kalimat itu benar. Tapi ada beda rasa antara ucapan seorang leader yang memahami substansi dengan yang sama sekali buta konteks.

Leader yang paham akan berkata, "Coba cari solusinya," tapi bisa disertai diskusi: "Apa opsi yang sudah kita coba? Apakah bottleneck-nya di sistem atau di proses manual? Kenapa kita tidak coba pendekatan B dulu?"

Leader yang tidak paham hanya bisa bertanya, "Kira-kira kapan selesainya?" —dan tim hanya bisa menarik napas panjang.

Ujian Sesungguhnya: Ketika Masalah Menghantam

Mari kita lihat dua potret yang kontras dari dunia administrasi HR dan payroll—area yang mungkin terlihat "biasa saja", sampai ada sesuatu yang bermasalah di dalamnya.

Potret pertama. Sebuah tim HR sedang menghadapi kekacauan di hari penggajian. Puluhan karyawan melapor bahwa nominal gaji yang mereka terima tidak sesuai. Ada yang selisih, ada yang komponen lemburnya hilang, ada yang potongan BPJS-nya berubah tiba-tiba. Staf HR dan payroll kelabakan memeriksa satu per satu. Mereka menduga masalahnya berasal dari integrasi antara sistem absensi dan modul payroll yang tidak sinkron setelah pembaruan.

Mereka melapor ke kepala divisi—sebut saja Mbak N. Ia mendengarkan, tapi hanya sekilas. Ia tidak paham bagaimana data dari fingerprint berpindah ke sistem payroll, tidak mengerti istilah "mapping komponen gaji", dan tidak tahu apa artinya ketika sistem menghitung lembur dengan formula yang tidak sesuai aturan baru. Yang bisa ia lakukan hanyalah menekan: "Pokoknya harus beres hari ini juga. Karyawan sudah komplain ke mana-mana. Saya tidak mau tahu caranya."

Tim bekerja dalam kepanikan. Mereka tidak hanya menyelesaikan masalah, tapi juga harus menanggung beban emosional dari atasan yang tidak memberi arahan, hanya tekanan.

Potret kedua. Masalah yang sama, dengan kepala divisi yang berbeda—sebut saja Mas F. Mas F tidak pernah sekalipun ikut duduk mengoperasikan software payroll, dan ia tidak akan bisa memperbaiki formula perhitungan di sistem. Tapi begitu tim menjelaskan dugaannya—bahwa data absensi tidak tersinkron dengan benar setelah patch sistem—Mas F paham. Ia tahu bahwa alur penggajian bergantung pada tiga modul: data kehadiran, komponen gaji, dan rekening karyawan. Ia bisa bertanya: "Apakah ini mempengaruhi semua karyawan atau hanya yang shift? Apakah kita punya backup data absensi sebelum patch kemarin? Kalau kita hitung manual dulu untuk yang terdampak, berapa orang maksimal yang bisa kita selesaikan hari ini?"

Mas F tidak memegang kalkulator, tidak membuka aplikasi payroll. Tapi pertanyaannya membingkai masalah, membantu tim berpikir sistematis, dan yang paling penting: membuat mereka merasa tidak sendirian.

Bedanya jelas. Di potret pertama, leader adalah beban tambahan di saat krisis. Di potret kedua, leader adalah penjernih. Ia paham medan yang dihadapi timnya, meski ia bukan operator.

Memahami Bukan Berarti Mengeksekusi

Sampai di sini, perlu saya tegaskan lagi: yang saya bicarakan adalah pemahaman, bukan keterlibatan langsung. Tidak ada yang menuntut seorang manajer HR harus bisa mengkonfigurasi formula pajak di sistem payroll. Tidak ada yang mewajibkan seorang kepala unit IT bisa menulis baris kode production-ready. Bukan itu intinya.

Intinya adalah literasi terhadap domain yang dipimpin. Sebut saja literasi operasional untuk konteks HR, literasi proses untuk administrasi, atau literasi teknis untuk teknologi. Tanpa ini, seorang leader sejatinya kehilangan kemampuan dasarnya: mengambil keputusan yang berdasar. Bagaimana mungkin Anda memutuskan sesuatu yang Anda tidak mengerti?

Ada konsep yang disebut technical empathy di dunia rekayasa perangkat lunak, tapi sejujurnya ini relevan di banyak bidang. Empati ini lahir dari pemahaman: paham mengapa suatu proses butuh waktu, paham seperti apa rasanya dikejar tenggat dengan data yang kacau, paham mengapa perubahan kecil di hulu bisa menimbulkan efek besar di hilir. Tanpa bekal pemahaman, empati hanya akan menjadi basa-basi, "Semangat ya, semua pasti bisa." —yang sering kali terasa hambar.

Apa yang Sebenarnya Dirasakan Tim

Ketika seorang leader tidak paham teknis—dalam arti luas: teknis sebagai penguasaan atas proses kerja timnya—dampaknya tidak cuma muncul saat krisis. Ada kerusakan struktural yang menumpuk diam-diam:

1. Ekspektasi yang tidak realistis. Di konteks HR, contohnya: meminta laporan penggajian selesai dua jam setelah periode tutup, tanpa memahami bahwa rekonsiliasi membutuhkan pengecekan silang dari banyak sumber—absensi, lembur, BPJS, pinjaman karyawan. Di konteks lain: meminta revisi sistem selesai besok pagi, tanpa sadar bahwa ada ketergantungan pada pihak ketiga.
2. Prioritas yang kacau. Tanpa pemahaman, leader sulit membedakan mana pekerjaan yang bersifat kritis dan mana yang sekadar "baik untuk dilakukan". Akibatnya, tim sering dibebani tugas-tugas yang tidak strategis hanya karena terdengar bagus di rapat.
3. Hilangnya respek. Profesional di bidang apa pun—entah staf HR, engineer, desainer, atau analis—punya radar yang tajam untuk mendeteksi apakah atasannya paham atau sekadar menggertak. Begitu respek terkikis, kepercayaan ikut lenyap. Dan tim yang tidak percaya pada pemimpinnya hanya akan bekerja untuk menggugurkan kewajiban, bukan untuk misi bersama.
4. Kerapuhan dalam menilai bakat. Bagaimana Anda bisa menilai apakah seorang kandidat spesialis payroll itu mumpuni, jika Anda sendiri tidak tahu proses payroll yang sehat seperti apa? Bagaimana Anda bisa menilai kualitas seorang programmer, jika Anda tidak bisa membedakan solusi elegan dari yang sekadar "asal jalan"?

Lalu, Seperti Apa Pemahaman yang Cukup Itu?

Saya tidak hendak membuat daftar tuntutan agar semua pemimpin tiba-tiba belajar coding atau mengambil kursus payroll. Tapi ada ambang batas minimum yang membedakan leader yang melek dengan yang buta terhadap pekerjaan timnya:

• Memahami alur kerja utama. Tidak perlu detail sampai bisa mengoperasikan tools, tapi tahu tahapan-tahapan kunci dan di mana letak potensi masalah. Misalnya: tahu bahwa penggajian melibatkan input dari absensi, ada proses validasi, dan ada kewajiban pelaporan ke BPJS dan pajak.
• Mengetahui metrik atau indikator kesehatan. Untuk HR, paham arti payroll accuracy rate, SLA penyelesaian kasus, atau tingkat kepatuhan regulasi. Untuk IT, paham apa itu uptime, bug rate, atau lead time.
• Mengenal istilah dan konsep inti. Bukan untuk pamer, tapi agar bisa mengikuti diskusi tim tanpa menjadi penonton pasif.
• Bertanya untuk belajar, bukan untuk menguji. Ada perbedaan besar antara "Coba jelaskan, saya ingin paham," dengan "Kenapa sih kok lama sekali?" Yang pertama membangun hubungan, yang kedua membangun tembok.

Saya pernah bertemu seorang pimpinan HR yang tidak bisa mengoperasikan modul payroll di sistem, tetapi selalu menyempatkan duduk bersama stafnya setiap kali ada perubahan regulasi. Ia bertanya, ia mencatat, dan ia tidak malu terlihat bodoh. Justru karena itu, ia pelan-pelan mengerti. Dan ketika masalah muncul—entah itu selisih gaji atau pelaporan pajak yang mendadak—ia bisa hadir sebagai penenang, bukan pemicu panik.

Penutup

Menjadi pemimpin di era yang semakin mengandalkan pengetahuan spesifik adalah pilihan sadar. Ketika seseorang memilih memimpin tim yang pekerjaannya tidak sepenuhnya ia kuasai, maka ada satu tanggung jawab yang melekat: belajar. Menolak belajar dengan dalih "saya tidak perlu mengurus teknis" bukanlah pembagian kerja yang sehat, melainkan bentuk pengabaian tanggung jawab yang dibungkus kata-kata profesional.

Saya percaya, di titik-titik krisis—saat masalah benar-benar menghantam—semua topeng akan terlepas. Yang tersisa hanya dua kemungkinan: membantu tim menyelesaikan masalah lewat pemahaman, atau berdiri kebingungan di pinggir sambil terus bergumam, "Itu bukan tugas saya." Mana yang akan Anda pilih?

Tulisan ini ditulis dari perspektif seorang praktisi HR yang juga terlibat dalam pengembangan sistem. Jika Anda punya pengalaman serupa atau perspektif yang berbeda, saya terbuka untuk berdiskusi.