Kemarin gw liat dashboard alokasi resource tim dev masih hijau penuh di angka 92%. Padahal request dari tim ops menumpuk 3 hari tanpa disentuh, dan tiap kali gw tanya, jawabannya selalu sama: "Gw lagi nyari slot kosong, boss."

Beneran loh. Tim jaga lahan masing-masing biar rating performa aman, sementara project kritis nungguin karena "kapasitas udah full". Yang ngeselin: kita pikir angka 90% itu tanda eksekusi kelas dunia. Padahal di lapangan, itu cuma indikator bahwa tidak ada lagi ruang buat napas, improvisasi, atau bantuan spontan. Dan startup yang nggak punya buffer hampir selalu mati di momen pertama terjadi perubahan demand.

Ilusi 'penuh' itu cuma rekayasa statistik

Target utilisasi 85-90% terdengar ideal di spreadsheet. Ideal karena secara teori industri manufacturing, mesin yang idle itu pemborosan. Tapi tim kreatif dan knowledge worker bukan mesin. Kalau lo paksa standar pabrik ke manajemen kapasitas tim, lo dapet dua hal: padamnya kreativitas dan lahirnya permainan statistik.

Gw pernah liat lead engineer di startup fintech ngelaporin utilisasi konsisten 88-90% selama 6 bulan. Kelihatannya flawless. Tapi setelah gw audit log commit dan PR merge, ternyata 40% dari jam tercatat dipakai untuk refactoring internal, dokumentasi ulang, dan meeting persiapan yang nggak pernah jadi action item. Dia nggak bermaksud jahat. Sistem nya reward dia untuk kelihatan sibuk. Semakin tinggi persentase, semakin selamat dia dari pertanyaan HR dan operasional.

Yang terjadi kemudian adalah fenomena ghost work. Task dipadatkan, estimasi dibengkakin, dan overhead collaboration dihindari. Kenapa? Karena kalau lo bantu rekan lintas divisi, utilisasimu turun. Kalau lo naik turun konteks, utilisasimu drop. Makanya setiap departemen jadi fortress. Brief dari marketing ditahan sampai "deadline internal" dekat. Review-an desain ditunda karena "masih nyerektask prioritas A". Padahal prioritas A itu cuma tugas rutin yang bisa diselesaikan setengah kecepatan normal.

Ketika alokasi resource jadi perang dingin

Masalah klasik agency dan startup scale-up: alokasi resource dikunci di awal sprint atau bahkan di awal quarter. Tim Dev dikasih kuota 120 jam/minggu. Tim QA 80 jam. Tim Support 100 jam. Angka-angka ini ditaruh di Excel, dipantau mingguan, dan jadi bahan standup yang membosankan.

Hasilnya? Tim yang underperform secara metrik akan dipaksa nge-gass task filler. Mereka ngedraft spec yang nggak ada budgetnya, bikin tool internal yang belum jelas problem statement-nya, atau sekadar standby meeting biar terlihat occupied. Di sisi lain, tim yang kebanjiran request terpaksa melakukan context switching brutal. Switching satu kali aja bisa makan 23 menit buat balik ke state-of-mind sebelumnya. Kalau sehari swap 6 kali, itu 2,3 jam hilang. Dan laporan utilisasi tetap hijau di 94% karena jam logging nggak membedakan deep work dan frantic firefighting.

Ini kontroversial tapi optimalkan kesibukan individu itu otomatis ngecetak friksi baru dan kill agility startup. Kita mau organisasi yang gesit nyesuaikan arah, atau mau birokrasi yang efisien ngejar target jam?

Biaya tersembunyi dari 'kesibukan' individu

Mari kita bedah apa yang sebenarnya terjadi ketika kita mengukur aktivitas bukan hasil. Metrik produktivitas berbasis jam atau utilisasi menciptakan ekonomi internal yang toxik. Lo gak sadar, tapi sudah membentuk insentif terselubung:

  • Hindari overlap: Nggak ada yang mau gabungin effort karena takut duplikasi counted twice atau malah bikin utilisasi temannya minus. Kolaborasi jadi transactional, harus ada exchange value atau approval manager.
  • Queue mentality: Tugas disimpan dulu di backlog pribadi sampai ada slot longgar. Daripada langsung handling, lebih aman simpan dan claim "sedang menunggu ketersediaan resource". Akibatnya cycle time memanjang drastis.
  • Blame shifting: Kalau project delay, jawabannya selalu sama: "tunggu antrian tim X". Padahal jika dilihat alur flow-nya, delay terjadi karena handoff point yang nggak jelas ownership-nya. Tapi karena KPI tim startup fokus pada personal capacity, nobody merasa bertanggung jawab atas systemic bottleneck.
Gw pribadi gak setuju kalau kita cuma replace satu metrik bodoh dengan metrik bodoh lainnya. Banyak founder langsung lari ke tracking layar aktif, keystroke, atau screenshot tools. Itu jalan buntu. Masalah utamanya bukan di monitoring, tapi di definition of done. Selama kita nggak kasih definisi jelas tentang apa yang dianggap "value delivered", tim akan terus mengoptimalkan hal yang salah.

Mengukur kegiatan bukan aliran

Flow efficiency adalah konsep yang sering dilupakan saat diskusi alokasi resource. Bedanya sederhana: activity efficiency = berapa lama kamu bekerja. Flow efficiency = berapa lama work-nya bergerak dari masuk sampai keluar tanpa stuck.

Rumus flow efficiency itu simpel: (active work time / total cycle time) x 100. Di banyak tim yang terjebak di utilisasi tinggi, angka ini biasanya di bawah 15%. Artinya, 85% waktu task cuma nunggu approved, direview, di-test, atau pindah tangan. Tidak ada yang sedang mengerjakan sesuatu.

Ketika lo nge-push utilisasi ke 90%, lo secara tidak sengaja mematikan flow. Kenapa? Karena lo menghapus slack. Slack itu bukan kemewahan, itu shock absorber. Tanpa ruang kosong di kalender atau bandwidth mental, satu request mendadak dari klien atau bug production langsung meruntuhkan seluruh rantai delivery. Tim jadi defensive. Fokus bergeser dari "selesaiin problem user" ke "jaga angka di dashboard".

Ganti utilisasi sama throughput & flow efficiency

Jadi gimana caranya escape dari jerat ini tanpa bikin panik tim atau menurunkan revenue? Jawabannya: alihkan taruhan pengukuran.

Start dengan throughput. Berapa unit value yang benar-benar shipped per periode? Bisa berupa feature release, closed support ticket, approved creative batch, atau deployed microservice. Throughput memaksa tim berpikir tentang outcome, bukan input. Jika throughput naik, artinya kolaborasi berjalan lancar. Jika throughput turun, segera cek bottleneck, bukan siapa yang paling rajin nge-log jam.

Lalu pasang meteran flow efficiency. Target sehat untuk knowledge work di atas 20-25%. Kalau di bawah itu, jangan salahkan individu. Salahkan proses handoff, unclear acceptance criteria, atau approval chains yang terlalu panjang. Gw sarankan pakai cycle time trend sebagai leading indicator. Jika curve-nya naik terus 2 sprint berturut-turut, berarti ada masalah struktural, bukan masalah motivasi.

Cara nerapin tanpa bikin panik tim

Transition ini memang gak bisa doi-inline. Tim butuh clarity soal ekspektasi baru. Langkah yang gw lakuin di tim gw:

  1. Kill weekly utilisation reports. Ganti dengan bi-weekly throughput review. Tampilkan jumlah item yang benar-benar moving forward vs stuck.
  2. Implement shared backlog visibility. Pakai platform yang bikin status task realtime accessible, bukan locked di email thread atau DM. Di SatuTim kita pakai fitur Discussion buat async update progress, biar nggak ada lagi task gantung yang cuma nungguin "slot kosong" di kalender orang lain.
  3. Reward blocking removal. Orang yang sukses nyelesain hambatan lintas tim dapat recognition lebih tinggi daripada orang yang cuma ngerjain task solo sesuai JD. Ini rewiring budaya pelan-pelan.
  4. Tetapkan SLA internal antar-departemen. Misalnya, design feedback maksimal 24 jam setelah request, QA handoff turnaround 1 hari kerja. Ini bikin alokasi resource jadi dinamis, berdasarkan critical path, bukan bucket statis.
Perlu gw tekankan: mengganti metrik ini bukan berarti kita minta tim santai atau kerja seperlunya. Justru sebaliknya. Ketika beban administrasi berkurang dan fokus dialihin ke flow, orang bisa masuk deep work state lebih konsisten. Gak perlu lagi pura-pura busy demi survival career di dalam company.

Memecah silo departemen itu efek samping, bukan target terpisah

Banyak founder nyoba bikin workshop cross-functional, retreat bonding, atau chat group gabungan berharap silo hancur sendiri. Biasanya gagal dalam 6 minggu. Kenapa? Karena culture follows incentive. Selama KPI tim startup masih reward individual capacity filling, orang bakal selalu pilih jalur aman: jaga domain sendiri, minimalisir risiko, hindari keterlibatan ambigu.

Kalau lo ubah measurement menjadi throughput + flow, silo pecah sendiri. Logikanya gini: kalau lewat-nya project ke tim support tertahan 3 hari karena admin pending, maka overall throughput semua tim turun. Termasuk dev dan design. Ketika penurunan throughput kena di muka masing-masing, mereka otomatis cari solusi bersama. Nggak perlu diinstruksin. Sistemnya yang nudging.

Gw liat contoh nyata di client agensi digital 2 tahun lalu. Dulu mereka punya masalah chronic: dev bilang ops overload, ops bilang dev lambat deliver asset, design bilang dev salah interpretasi mockup. Masing-masing nyalahin di after-party atau channel general. Pas kami gantiin KPI bulanan jadi "cycle time per campaign" dan "unblocked rate", dinamika berubah dalam 3 sprints. Tim mulai saling share template, bikin checklist pre-handoff, dan bahkan scheduling sync 15 menit di tengah pekan secara voluntary. Bukan karena management nagih, tapi karena flow yang lancar langsung impact ke bonus quarterly mereka.

Kalau lo masih pegang erat pada metrik produktivitas berbasis kehadiran atau log jam, lo bakal dapet tim yang pandai berakting. Tapi kalau lo taruh taruhan di cycle time dan unblocked rate, perilaku kolaborasi muncul sendiri. Tanpa drama, tanpa forced fun, tanpa meeting ekstra.

Coba minggu ini: ambil satu project yang kemarin miss deadline karena antrean silo. Cek berapa hari sebenarnya waktu kerjanya versus waktu tunggu di queue. Kalau angka wait time-nya di atas 60%, lo tau kenapa tim lo selalu kelelahan padahal outputnya stagnan. Mau gantiin metriknya sekarang, atau masih mau lanjut timer meeting buat debat siapa yang lebih rajin nge-log jam?