Menyeimbangkan Coding Langsung dengan Tanggung Jawab Kepemimpinan IT

Salah satu pertanyaan yang paling sering saya dapat dari developer yang baru naik jadi lead atau Kepala IT adalah: "apakah saya masih boleh coding?" Jawabannya iya, tapi caranya harus berubah. Begitu tanggung jawab bertambah — rapat vendor, keputusan arsitektur, urusan kepatuhan data, sampai memastikan sistem di fasilitas kesehatan tetap jalan 24 jam — waktu untuk duduk tenang dan menulis kode jadi barang langka. Kalau tidak disiplin, ujungnya salah satu dari dua ekstrem: tenggelam lagi jadi individual contributor sampai lupa tugas manajerial, atau berhenti total dari kode sampai kehilangan rasa terhadap sistem yang dipimpin. Keduanya sama-sama merugikan tim.

Kenapa tetap hands-on itu penting

Sebagai pemimpin tim teknis, kredibilitas saya sebagian besar datang dari pemahaman nyata terhadap sistem, bukan dari slide roadmap. Kalau saya tidak pernah lagi menyentuh Laravel, Docker, atau alur deployment, lama-lama estimasi yang saya berikan ke atasan jadi tidak realistis, dan saran teknis ke tim jadi basi. Coding langsung juga cara paling jujur untuk merasakan pain point yang dialami tim — misalnya, seberapa menyebalkan proses migrasi database di staging, atau seberapa lambat build Docker image kalau layer-nya tidak dioptimalkan. Pengalaman tangan pertama itu tidak tergantikan oleh laporan status.

Strategi memilih "di mana" harus hands-on

Karena waktu terbatas, saya tidak lagi coding sembarang task. Saya memilah berdasarkan dampak dan risiko, bukan berdasarkan mana yang paling menyenangkan dikerjakan. Beberapa pola yang saya pakai:

Ambil bagian yang berisiko tinggi atau butuh keputusan arsitektur — misalnya merancang skema autentikasi baru, atau menyusun struktur queue job untuk proses yang melibatkan data sensitif.
Turun tangan saat ada masalah yang butuh eskalasi cepat, seperti debugging produksi yang macet, tapi setelah selesai saya tulis catatan singkat supaya tim bisa menanganinya sendiri lain kali.
Sisakan slot kecil rutin — daripada menunggu "waktu luang" yang tidak pernah datang, saya blok jam tertentu, misalnya dua sampai tiga jam beberapa kali seminggu, khusus untuk kode, dan memperlakukannya seserius rapat penting.
Hindari menjadi bottleneck: kalau sebuah task hanya bisa selesai kalau saya yang mengerjakan, itu tanda saya perlu mendelegasikan lebih agresif, bukan makin banyak coding sendiri.

Delegasi bukan berarti lepas tangan

Bagian tersulit dari peran ini adalah membedakan antara delegasi yang sehat dan pelarian dari tanggung jawab. Saya tetap review code, terutama pada bagian yang menyentuh keamanan atau integrasi dengan sistem eksternal semacam LLM/AI yang kami pakai untuk membantu proses coding klinis. Review ini bukan sekadar formalitas — di situlah saya menjaga standar teknis tanpa harus menulis semua barisnya sendiri. Saya juga membiasakan diri menuliskan keputusan teknis dalam bentuk dokumen pendek, semacam catatan desain, supaya tim tidak bergantung pada saya untuk konteks yang sebetulnya bisa didokumentasikan.

Menjaga ritme, bukan sekali jalan

Keseimbangan ini bukan sesuatu yang dicapai sekali lalu selesai. Setiap kuartal saya mengevaluasi ulang: apakah waktu coding saya masih dipakai untuk hal yang benar-benar berdampak, atau justru jadi pelarian dari tugas manajerial yang lebih tidak nyaman, seperti percakapan performa atau perencanaan anggaran? Kejujuran pada diri sendiri soal ini penting, karena coding sering terasa lebih "produktif" padahal belum tentu itu yang paling dibutuhkan tim saat itu.

Takeaway

Tetap hands-on sebagai pemimpin teknis bukan soal seberapa banyak baris kode yang ditulis, tapi soal memilih momen yang tepat untuk turun tangan: risiko tinggi, kebutuhan mendesak, dan ruang belajar untuk tim. Selebihnya, percayakan pada proses delegasi dan dokumentasi yang baik, supaya sistem tetap sehat meskipun Anda tidak selalu ada di depan editor.