Karyawan Operasional Pertama Anda (dan Kenapa Bukan Developer Lagi)

Begitu pertumbuhan mulai terasa menyakitkan, instingnya hampir selalu sama: rekrut developer lagi. Pesanan mulai tercecer, laporan makan waktu terlalu lama untuk disusun, serah terima ke pelanggan berantakan, dan founder langsung menyimpulkan solusinya adalah menambah kapasitas engineering. Sebagian besar waktu, itu diagnosis yang keliru. Yang macet bukan kodenya, tapi tidak ada yang benar-benar memegang bagaimana bisnis ini berjalan sehari-hari. Yang dibutuhkan lebih dulu adalah karyawan operasional pertama, bukan tambahan headcount di tim engineering.

Saya sudah menyaksikan kesalahan ini terjadi berulang pada beberapa klien, dan polanya selalu sama. Founder merekrut developer untuk "bikin sistem yang membereskan ini," developer-nya membangun sesuatu yang secara teknis benar, tapi kekacauan di baliknya tetap bertahan karena tidak ada yang pernah memetakan atau memegang proses yang seharusnya diwakili oleh software itu. Alatnya berubah. Kekacauannya tidak.

Pola yang terus saya temui

Sebuah perusahaan distribusi yang pernah kami tangani mengalami persis cerita ini sebelum kami masuk. Tim sales menutup deal lebih cepat daripada kemampuan fulfillment memprosesnya, jadi langkah pertama founder adalah merekrut developer untuk membangun aplikasi order management custom. Delapan minggu dan anggaran yang tidak kecil kemudian, aplikasinya berjalan baik-baik saja, dan pesanan tetap tercecer, hanya sekarang dengan tampilan yang lebih rapi. Masalah sebenarnya adalah tiga orang berbeda menyentuh setiap pesanan, tidak satu pun dari mereka tahu siapa yang bertanggung jawab meng-update status, dan tidak ada satu orang pun yang benar-benar memegang sebuah pesanan dari "dikonfirmasi" sampai "terkirim." Developer tidak bisa membereskan itu. Itu masalah operasional yang mengenakan kostum software.

Ini yang perlu diwaspadai: kalau jenis kegagalan yang sama terus berulang di berbagai tool, dari spreadsheet, lalu shared drive, lalu aplikasi berbayar, berarti tool-nya memang bukan kendala sejak awal. Kendalanya adalah tidak ada yang memegang proses itu dari ujung ke ujung.

Itu masalah operasional yang mengenakan kostum software.

Ervandra Halim, konsultan teknis yang fokus pada operasional

Apa Sebenarnya yang Dipegang Karyawan Operasional Pertama?

Karyawan operasional pertama memegang empat hal yang selama ini dipegang sendiri oleh founder, biasanya kurang baik, dan sudah terlalu lama: proses, tool, serah terima, dan kerapian data. Peran ini bukan project manager yang sekadar mencatat task, dan bukan admin yang mengetik data, tapi orang dengan otoritas nyata untuk membenahi cara kerja bisnis berjalan. Rinciannya sebagai berikut:

Proses. Mendokumentasikan bagaimana pekerjaan sebenarnya mengalir hari ini, bukan bagaimana seharusnya mengalir di atas kertas, lalu membenahi langkah-langkah yang tidak layak dipertahankan. Disiplin ini sama dengan yang dibahas di pemetaan proses sebelum otomatisasi: Anda tidak bisa memegang proses yang belum pernah Anda petakan.
Tool. Menentukan sistem mana yang jadi sumber kebenaran untuk apa, mematikan spreadsheet bayangan yang pasti muncul lagi dan lagi, dan memastikan tool yang sudah dimiliki tim benar-benar dipakai secara konsisten, bukan setengah-setengah.
Serah terima. Menunjuk secara eksplisit siapa yang memegang setiap tahap alur kerja, dan apa arti "selesai" sebelum berpindah ke orang berikutnya. Sebagian besar kekacauan operasional di UKM yang sedang tumbuh bukan soal tool yang hilang, tapi serah terima yang tidak pernah didefinisikan, sehingga semua orang diam-diam mencari jalan memutar.
Kerapian data. Menjaga satu sumber kebenaran tetap cukup bersih untuk dipercaya, yang jadi makin penting begitu Anda mulai menambahkan AI atau otomatisasi di atasnya. Kami pernah membahas kenapa kualitas data harus dibereskan sebelum adopsi AI, dan logika yang sama berlaku untuk laporan atau dashboard apa pun yang diandalkan tim Anda.

Perhatikan, tidak satu pun dari ini membutuhkan satu baris kode. Yang dibutuhkan adalah seseorang dengan otoritas dan daya tahan untuk masuk ke realita operasional bisnis dan membenahinya secara terus-menerus, bukan sebagai proyek sekali jalan.

Bagaimana Anda Tahu Butuh Peran Ini Sebelum Menambah Engineer?

Tanda-tanda butuh karyawan operasional pertama sebelum menambah engineer muncul sebagai daftar cek yang jujur, bukan sekadar perasaan bahwa pertumbuhan terasa berantakan. Cek daftar berikut sebelum membuka lowongan developer, dan hitung berapa banyak yang benar-benar menggambarkan bisnis Anda sekarang:

Anda sudah membangun ulang atau mengganti tool internal yang sama lebih dari sekali dalam setahun terakhir, dan keluhan yang mendasarinya tidak berubah.
Orang-orang terbaik Anda menghabiskan jam-jam berharga setiap minggu untuk merekonsiliasi data secara manual antar sistem yang seharusnya sudah saling terhubung.
Tidak ada yang bisa menjawab dalam satu kalimat siapa yang memegang sebuah pesanan pelanggan (atau klaim, pengiriman, approval) dari awal sampai selesai.
Karyawan baru butuh berminggu-minggu memahami "bagaimana sebenarnya cara kerja di sini" karena tidak ada yang tertulis.
Founder masih menjadi manajer operasional de facto, secara pribadi menyetujui hal-hal atau mengejar update status yang seharusnya sudah berjalan rutin.

Kalau dua atau lebih dari poin ini benar, rekrutan berikutnya yang benar-benar akan mengubah keadaan adalah seseorang yang memegang operasional, bukan seseorang yang membuat aplikasi baru lagi. Developer bagus untuk menyelesaikan masalah teknis yang jelas batasannya. Mereka tidak secara alami memutuskan proses mana yang layak dipertahankan sejak awal, dan kalau Anda memaksa mereka melakukannya, biasanya hasilnya justru mengotomatisasi alur kerja yang rusak, bukan membenahinya.

Bagaimana ROI-nya Berbeda dari Rekrutan Developer?

ROI seorang developer biasanya terlihat jelas dan spesifik: sebuah fitur rilis, sebuah tugas manual hilang, sebuah sistem live. ROI karyawan operasional pertama lebih senyap, ia berlipat ganda selama berbulan-bulan alih-alih muncul dalam satu rilis tunggal, itulah sebabnya kedua rekrutan ini seharusnya dinilai dengan garis waktu yang berbeda. Kisaran yang jujur yang biasa saya lihat: karyawan operasional yang kompeten biasanya mengembalikan sekitar 5 sampai 15 jam waktu founder atau staf senior per minggu dalam kuartal pertama, hanya dengan memegang serah terima dan menghilangkan langkah-langkah yang redundan, sebelum ada tool baru yang dibeli. Angka ini terus bertambah seiring backlog proses terbenahi, karena setiap serah terima yang dibenahi menghilangkan sumber gesekan yang berulang, bukan sekadar tugas satu kali.

Hal yang lebih sulit diukur, tapi sering justru yang paling berharga, adalah berkurangnya kesalahan. Lebih sedikit pesanan yang hilang, lebih sedikit data pelanggan duplikat, lebih sedikit percakapan "tunggu, siapa yang menyetujui ini." Ini jarang muncul sebagai satu baris di laporan keuangan, tapi biasanya inilah yang sebenarnya menggerus uang bisnis, bukan fitur yang hilang.

Cara menyusun perannya

Jangan rekrut peran ini dengan jabatan "operations manager" yang samar dan berharap perannya mendefinisikan diri sendiri. Susun seperti Anda menyusun rekrutan mana pun yang benar-benar penting:

Pilih dua atau tiga alur kerja yang saat ini paling menyakitkan (order sampai pengiriman, lead sampai jadi pelanggan, permintaan sampai approval) dan jadikan itu mandat eksplisit 90 hari pertama, bukan "perbaiki operasional secara umum."
Beri otoritas nyata untuk mengubah proses, bukan sekadar mendokumentasikannya. Karyawan operasional tanpa otoritas untuk menghapus sebuah langkah atau memindahkan kepemilikan hanya akan jadi pencatat notulen yang mahal.
Definisikan apa yang mereka pegang versus apa yang mereka eskalasikan. Kepemilikan data dan alur kerja, ya. Keputusan arsitektur teknis, tidak, itu tetap milik siapa pun yang memimpin engineering atau technical partner Anda.
Tetapkan checkpoint 90 hari dengan hasil yang spesifik dan terukur, bukan "rasanya sudah lebih lancar." Sebuah proses yang sudah dipetakan, sumber kebenaran yang sudah dikonsolidasikan, sebuah serah terima yang sudah didefinisikan ulang dan benar-benar dipakai.

Ini juga momen yang tepat untuk jujur soal apakah Anda memang butuh developer sekarang, atau developer itu sebenarnya hanya menutupi peran yang belum pernah Anda beri nama. Disiplin yang sama dengan memilih antara merekrut developer atau outsourcing berlaku di sini: cocokkan rekrutan dengan kendala sebenarnya, bukan dengan insting bahwa "lebih teknis" selalu berarti "lebih mampu."

Ringkasan praktis

Sebelum membuka lowongan developer karena pertumbuhan mulai terasa berantakan, tanyakan dulu apa yang sebenarnya rusak: fitur yang hilang, atau tidak ada yang memegang proses tempat fitur itu akan berjalan? Sebagian besar waktu, untuk bisnis dengan kira-kira 15 sampai 100 karyawan, jawabannya yang kedua, dan karyawan operasional pertama akan membereskan lebih banyak kekacauan dibanding engineer tambahan, dengan biaya lebih rendah dan lebih cepat. Kalau Anda belum yakin mana yang benar-benar dibutuhkan bisnis Anda sekarang, itu layak didiskusikan singkat sebelum Anda memutuskan salah satunya, hubungi lewat /partner.

Pertanyaan yang sering diajukan

Apakah karyawan operasional pertama itu sama saja dengan project manager?

Tidak sama. Project manager mencatat task di dalam struktur yang sudah ada, sementara karyawan operasional pertama punya otoritas untuk mengubah struktur itu sendiri, menghapus langkah yang tidak perlu, dan memindahkan kepemilikan sebuah serah terima. Tanpa otoritas untuk mengubah proses, bukan sekadar mendokumentasikannya, peran ini hanya jadi pencatat notulen yang mahal, bukan orang yang benar-benar membereskan kekacauan.

Apa yang sebaiknya dieskalasikan karyawan operasional, bukan diputuskan sendiri?

Keputusan arsitektur teknis tetap menjadi milik siapa pun yang memimpin engineering atau technical partner Anda, bukan karyawan operasional. Kepemilikan mereka mencakup alur kerja dan data, menentukan sistem mana yang jadi sumber kebenaran, mendefinisikan ulang serah terima, dan menjaga data tetap rapi; begitu sebuah keputusan menyentuh arsitektur sistem atau cara software dibangun, itu harus dieskalasikan, bukan diputuskan sendiri.

Bagaimana cara membedakan masalah operasional dari sekadar masalah tool yang kurang bagus?

Tandanya adalah kegagalan yang sama terus berulang di berbagai tool berturut-turut: spreadsheet, lalu shared drive, lalu aplikasi berbayar, semuanya gagal dengan cara yang sama. Kalau pola ini muncul, tool-nya memang bukan kendala sejak awal, tidak ada yang memegang proses dari ujung ke ujung, dan membeli atau membangun sistem baru hanya akan memindahkan kekacauan yang sama ke tampilan yang lebih rapi.

Apakah merekrut karyawan operasional pertama berarti Anda tidak perlu lagi merekrut developer?

Belum tentu, intinya adalah mengecek apakah rekrutan developer itu sebenarnya hanya menutupi peran yang belum pernah Anda beri nama. Sebagian bisnis memang butuh keduanya; yang penting adalah mencocokkan rekrutan dengan kendala sebenarnya. Kalau tidak ada yang memegang proses, membenahi itu dulu sering menghilangkan tekanan yang membuat rekrutan developer terasa mendesak, dan memperjelas pekerjaan teknis apa, kalau ada, yang benar-benar masih dibutuhkan.