Dari Software Engineer ke Kepala IT: Apa yang Berubah

Waktu masih jadi software engineer, ukuran keberhasilan saya jelas: fitur jalan, bug ketutup, kode di-review, deploy lancar. Begitu naik jadi Kepala IT, definisi "kerjaan beres" itu berubah total. Saya masih menulis kode — bahkan masih sering masuk ke bagian backend Laravel atau ngoprek container Docker — tapi porsi waktu saya sekarang lebih banyak habis untuk hal yang dulu nyaris tidak saya pikirkan: keputusan prioritas, komunikasi lintas tim, dan menjaga sistem tetap hidup, bukan cuma tetap benar.

Dari "kode yang benar" ke "sistem yang bisa dipercaya"

Sebagai engineer, unit kerja saya adalah pull request. Selesai satu PR, pindah ke tiket berikutnya. Sebagai Kepala IT, unit kerja saya jadi jauh lebih kabur: uptime layanan, kepatuhan terhadap kebijakan keamanan, sampai apakah tim support bisa menjelaskan insiden ke pengguna tanpa panik. Kode yang rapi tetap penting, tapi dia cuma salah satu variabel dari sistem yang lebih besar — infrastruktur, proses deploy, backup, sampai siapa yang pegang akses apa.

Perubahan sudut pandang ini yang paling terasa: dulu saya bertanya "apakah fitur ini bekerja dengan benar?", sekarang saya lebih sering bertanya "kalau ini rusak jam 2 pagi, siapa yang tahu, dan apakah kita bisa pulih tanpa drama?" Pertanyaan kedua itu jarang punya jawaban di dokumentasi teknis mana pun — jawabannya ada di proses, bukan di kode.

Mengelola orang itu keterampilan lain, bukan kode dengan variabel manusia

Salah satu jebakan yang saya alami di awal transisi adalah mencoba "men-debug" orang seperti men-debug sistem: cari akar masalah, kasih solusi, selesai. Nyatanya, motivasi, beban kerja, dan komunikasi tim tidak sesederhana itu. Sebagai ilustrasi, satu keputusan teknis yang menurut saya "jelas benar secara arsitektur" bisa gagal dieksekusi kalau tim yang menjalankannya tidak paham kenapa, atau merasa tidak dilibatkan sejak awal. Yang berubah dari sisi saya: lebih banyak waktu dihabiskan menjelaskan konteks dan alasan, bukan cuma memberi instruksi teknis. Itu skill yang tidak diajarkan di kursus pemrograman mana pun, dan awalnya terasa tidak efisien — padahal justru itu yang bikin keputusan teknis benar-benar jalan di lapangan.

Prioritas jadi kerja utama, bukan gangguan

Dulu, rapat prioritas terasa seperti interupsi dari "kerja beneran" (menulis kode). Sekarang saya sadar, menentukan prioritas justru adalah kerja utamanya. Sumber daya tim IT — waktu, orang, budget infrastruktur — selalu terbatas, dan hampir semua permintaan terasa penting bagi yang memintanya. Tugas saya bukan lagi mengerjakan semuanya dengan cepat, tapi memutuskan mana yang benar-benar perlu dikerjakan sekarang, mana yang bisa menunggu, dan berani bilang "belum" tanpa terdengar defensif.

Ini juga mengubah cara saya menilai risiko. Sebagai engineer, saya cenderung fokus ke risiko teknis: race condition, query lambat, edge case yang belum ditangani. Sebagai Kepala IT, saya harus menimbang risiko operasional dan risiko bisnis di level yang sama — misalnya, mengganti komponen infrastruktur yang secara teknis "lebih baik" tapi berisiko mengganggu operasional harian, sering kali bukan keputusan yang tepat meski secara kode itu peningkatan nyata.

Yang tidak berubah

Latar belakang sebagai engineer tetap jadi modal utama. Saya masih bisa membaca kode tim, ikut turun tangan saat insiden, dan tahu kapan sebuah estimasi waktu dari developer masuk akal atau tidak. Bedanya, sekarang kemampuan itu jadi alat bantu untuk mengambil keputusan yang lebih luas, bukan lagi satu-satunya pekerjaan saya.

Kalau ada satu hal yang saya bawa dari transisi ini: jangan tinggalkan kemampuan teknis begitu naik ke peran manajerial, tapi juga jangan berharap kemampuan teknis saja cukup untuk membuat keputusan yang baik. Keduanya perlu jalan bersamaan.