Setiap hari, saya berganti topi setidaknya tiga kali.
Pagi hari, saya adalah software engineer yang sedang debugging API klien. Siang, saya adalah Co-Founder/CEO Picaloid yang harus mikirin roadmap produk dan ngobrol sama tim. Sore atau malam, saya adalah pemilik Nugraha Jaya Farm yang harus mastiin pakan, kandang, dan operasional harian berjalan tanpa saya harus hadir secara fisik setiap saat.
Tiga dunia ini punya ritme, urgensi, dan jenis stres yang sangat berbeda. Kalau saya treat ketiganya dengan cara yang sama — buka semua chat, balas semua notifikasi, kerjain apapun yang "kelihatan urgent" duluan — saya akan habis sebelum jam makan siang, dan tidak satupun dari ketiganya benar-benar maju.
Tulisan ini bukan tentang "cara jadi produktif super manusia". Ini lebih ke catatan jujur tentang sistem yang saya pakai sekarang — sebagian besar lahir dari kesalahan, bukan dari teori manajemen waktu yang saya baca duluan.
---
Masalah Sebenarnya Bukan Jumlah Proyek
Waktu masih punya satu-dua klien, masalahnya sederhana: kerjakan, deliver, repeat.
Begitu jumlah "topi" bertambah, masalah utamanya bukan volume kerjaan — tapi biaya pindah konteks (context switching cost).
Setiap kali saya loncat dari "mikir arsitektur backend klien A" ke "diskusi pricing Picaloid" ke "WhatsApp dari kandang soal stok pakan", otak saya butuh waktu untuk "boot up" ulang ke konteks itu. Kalau ini terjadi 15 kali sehari, saya bisa merasa "sibuk seharian" tapi di akhir hari tidak ada satupun hal besar yang benar-benar selesai.
Jadi sistem yang saya bangun sebenarnya punya satu tujuan utama: mengurangi jumlah perpindahan konteks, bukan menambah jumlah jam kerja.
---
Lapisan 1: Membagi Waktu Berdasarkan Jenis Energi, Bukan Jenis Klien
Saya berhenti membuat jadwal berdasarkan "klien A jam 9, klien B jam 11, Picaloid jam 2". Itu cuma memindahkan masalah context switching ke kalender.
Sekarang saya membagi hari berdasarkan jenis kerja, lalu mengelompokkan semua hal sejenis dari berbagai "topi" ke dalam blok yang sama:
Efeknya signifikan: ketika pagi saya "mode deep work", saya tidak peduli itu kerjaan klien mana atau bahkan kerjaan Picaloid — yang penting jenis fokusnya sama. Otak saya cuma perlu masuk ke satu "mode", bukan berganti-ganti antara "mode teknis" dan "mode bisnis" setiap 30 menit.
Untuk hal-hal yang sifatnya tidak bisa ditunda (server klien down, ada masalah kesehatan ternak), tentu aturan ini saya langgar. Tapi itu pengecualian, bukan default — dan justru karena saya jarang melanggarnya, ketika saya melanggar, semua orang tahu itu serius.
---
Lapisan 2: Sistem per Klien, Bukan Sistem per "Saya"
Bagian ini lebih teknis, dan ini yang sering ditanyakan sesama freelancer: "gimana cara lo nggak lupa-lupa progress tiap klien?"
Jawabannya: saya tidak mengandalkan ingatan saya sama sekali. Setiap klien punya "rumah" sendiri yang isinya selalu sama formatnya:
Onboarding klien baru jadi proses yang sudah hampir template: kickoff call singkat untuk align ekspektasi, lalu saya buatkan ketiga "rumah" itu dalam 1-2 hari pertama. Setelah itu, hampir semua interaksi rutin terjadi di dalam sistem ini, bukan di kepala saya.
Soal Scope Creep
Scope creep adalah pembunuh diam-diam untuk siapapun yang pegang banyak proyek. Satu permintaan kecil "tambahin dikit ya" yang kelihatan remeh, kalau terjadi di 4 proyek sekaligus, itu sama dengan satu proyek tambahan yang tidak dibayar.
Cara saya menanganinya bukan dengan menolak — tapi dengan membuat semuanya terlihat. Setiap permintaan tambahan, sekecil apapun, masuk ke board sebagai task baru dengan estimasi. Klien melihat sendiri bagaimana itu mempengaruhi timeline. Sebagian besar percakapan "tapi ini kan kecil doang" selesai sendiri begitu ada visualisasi dampaknya — tanpa saya perlu berdebat.
Retainer vs Proyek
Untuk klien yang butuh dukungan jangka panjang (maintenance, on-call, improvement bertahap), saya jauh lebih suka skema retainer dibanding per-proyek. Bukan cuma soal pendapatan yang lebih predictable, tapi karena retainer secara alami membatasi berapa banyak "konteks aktif" yang harus saya pegang dalam satu waktu — jumlah jam sudah disepakati di awal, jadi saya bisa alokasikan slot tetap di kalender tanpa negosiasi ulang setiap minggu.
---
Lapisan 3: Apa yang Diajarkan Peternakan ke Saya soal Mengelola Proyek Software
Ini bagian yang paling tidak terduga buat saya sendiri.
Nugraha Jaya Farm dimulai jauh dari dunia software — tapi justru karena sangat berbeda, ia memaksa saya melihat pola yang sama dari sudut yang lain.
Di farm, saya tidak bisa hadir setiap saat untuk memutuskan hal-hal kecil — kapan kasih pakan, kapan bersihkan kandang, apa yang harus dilakukan kalau ada anomali kecil. Kalau semua keputusan harus menunggu saya, operasionalnya akan berhenti setiap kali saya sibuk dengan klien.
Solusinya bukan "kerja lebih keras", tapi membuat SOP — aturan yang jelas, sehingga keputusan rutin bisa diambil tanpa saya, dan hanya hal-hal yang benar-benar di luar pola yang dieskalasi ke saya.
Begitu saya sadar itu, saya sadar saya melakukan kesalahan yang sama di proyek-proyek klien: terlalu sering jadi satu-satunya orang yang tahu "kenapa kita pilih pendekatan ini" atau "di mana letak file konfigurasi X". Dokumen "context dump" yang saya sebut di Lapisan 2 itu sebenarnya adalah SOP versi software — supaya proyek tetap bisa berjalan (oleh saya sendiri di masa depan, atau oleh siapapun yang membantu) tanpa bergantung pada ingatan saya hari ini.
Sebaliknya, kebiasaan dari dunia software — menulis semuanya, membuat checklist, automasi hal repetitif — sekarang juga saya terapkan di farm. Laporan harian, misalnya, tidak lagi lewat chat panjang yang gampang hilang, tapi lewat form sederhana yang hasilnya otomatis terangkum.
---
Sistem Ini Tidak Sempurna — dan Memang Tidak Harus
Saya masih sering kebobolan. Ada minggu di mana satu klien butuh perhatian ekstra, dan otomatis dua "topi" lainnya kebagian sisa energi yang lebih sedikit. Ada hari di mana blok pagi saya hancur karena ada emergency dari farm.
Yang saya pelajari: tujuannya bukan membuat sistem yang anti-gagal, tapi membuat sistem di mana kegagalan kecil tidak menular ke mana-mana. Kalau satu hari berantakan, sistemnya cukup kuat untuk "menyerap" itu tanpa membuat hari berikutnya ikut berantakan.
Kalau kamu juga sedang menyeimbangkan banyak komitmen — entah itu beberapa klien, side project, atau hal-hal di luar dunia kerja — mungkin pertanyaan yang lebih berguna bukan "bagaimana saya bisa mengerjakan semuanya", tapi: konteks mana yang sebenarnya bisa digabung, dan keputusan rutin mana yang sebenarnya tidak butuh saya?
Jawaban dari dua pertanyaan itu, buat saya, lebih berharga daripada aplikasi to-do list manapun.