Gw liat timeline sprint kemarin. Deadline client tanggal 15, tapi tim QA butuh 3 hari full buat validasi. Alhasil? Dev kerja lembur, design nge-rework, dan PM nyari cara nge-patch scope tanpa bikin client marah. Yang muncul cuma satu pertanyaan di grup Slack: "ini kita targetin kelar atau beneran?"

Itu bukan masalah eksekusi. Itu masalah sistem penjadulan tujuan lo.

OKR vs KPI Bukan Soal Framework, Tapi Soal Fase Bisnis

Kalau lo punya tim 10 orang yang lagi handle 3 project paralel, gw gak bakal suruh lo pilih salah satu framework doang. Kebanyakan founder pake OKR karena denger istilahnya keren di podcast, tapi ujungnya malah jadi checklist baru yang nggak pernah di-review. Sebaliknya, KPI sering dipaksain ke proyek yang belum jelas arah pasarnya, sampai akhirnya tim kejar angka sambil nguburin kualitas produk.

Di SatuTim kita coba pola lain: gantung keduanya di dashboard yang beda, tapi kasih porsi sesuai fase project.

Project baru? OKR buat maintain rasa kepo sama arah yang bener. Routine ops? KPI operasional biar gak ada jam yang terbuang buat guessing game.

Kasus Nyata: Client Mau Launch Jumat, Quality Minta Tes Senin-Kamis

Bulan lalu tim gw deal sama client e-commerce yang mau flash sale weekend. Brief awal: fitur checkout diperbarui dalam 5 hari. Tim dev langsung nge-set target kelar ala OKR-style: Objective "Checkout seamless", Key Result "Reduce cart abandonment by 15%". Tapi pas masuk Day 3, QA nemuin bug minor yang bisa nge-corrupt payment gateway.

Kalau sistem lo cuma pegang KPI operasional ("95% task selesai tepat waktu"), jawabannya jelas: skip test suite, release Jumat, hope for the best. Hasilnya? Client seneng sementara, tapi week berikutnya sudah turun tiket support 4x lipat. Tim gw kelebat.

Kalau kita pegang OKR murni? Bisa jadi tim mager nge-release karena takut miss key result. Solusinya? Gabung dua-duanya dengan aturan main yang tegas: OKR ngatur "mengapa" kita ngerjain ini, KPI ngatur "berapa cepat" prosesnya jalan. Untuk kasus flash sale itu, kita geser fokus dari "fix semua bug" ke "zero critical bugs on launch". Kita tetep set KPI harian buat velocity, tapi kalau critical bug muncul, OKR override otomatis. Nggak perlu meeting darurat. Cukup update di status thread.

Kapan OKR Baper, Kapan KPI Membunuh Kreativitas

Banyak agensi terjebak nge-pack OKR jadi KPI terselubung. Gw sebut ini OKR kaku. Objectivenya udah fixed, key resultsnya diukur mingguan, review-an cuma buat nge-checklist. Hasilnya? Tim belajar main aman. Nggak ada eksperimen. Nggak ada yang berani usul approach baru karena takut ngedrop angka.

OKR untuk agency itu hidup kalau lo pakenya buat eksperimen. Misal: "Uji pendekatan video short-form sebagai lead magnet utama." Key result-nya bukan "tambah 100 leads", tapi "validasi CTR >8% dari 3 variasi kreatif". Angka di situ bukan target final, itu kompas. Kalau hasilnya nol, lo masih dapet insight berharga. Nggak perlu ganti seluruh tim cuma karena satu KR green.

Sebaliknya, KPI operasional tuh penting banget buat bagian yang sifatnya rekurensi. Client reporting, server uptime, turnaround time brief, SLA response. Ini area di mana fleksibilitas justru berbahaya. Lo mau tim lo paham bahwa di sini, konsistensi ngalahin inovasi. Makanya kita bagi 70% waktu tim buat execute KPI rutin, sisanya 30% buat dorong eksperimen. Rasio ini berubah kalau bisnis lo lagi scale-up atau survival mode. Phase matters.

Manajemen Tujuan Tim yang Gak Bikin Meeting Jadi Kuburan

Sistem apa pun akan jadi beban kalau lo ubah jadi ritual bulanan yang panjang. Gw pernah ikut review OKR tim agensi lain — 90 menit, 12 orang, presentasi slide, debate soal metrik. Ujung-ujungnya cuma numpuk PR-an di kepala masing-masing.

Cara kita jalankan async first. Tiap Minggu pagi, tiap member update progress di kolom khusus. Nggak perlu narasi 2 halaman. Cukup 3 baris: progress, blockir, next step. Kalau ada anomaly di KPI operasional, sistem auto-flag. Kalau OKR lagi off-track, kita diskusi di standup 10 menit atau skip standup sama sekali. Fokusnya bukan nge-justify, tapi nge-cut noise.

One truth: pengukuran yang terlalu detail justru ngebunuh konteks. Lo nge-track berapa kali PM follow-up client? Itu noise. Lo nge-track berapa lama rata-rata brief waiting time sebelum dev mulai kerjakan? Itu signal. Bedakan antara activity tracking dan outcome tracking. Activity bikin burnout. Outcome bikin kejelasan.

Jangan Pilih Salah Satu, Pakai Mereka Sesuai Peran

Gw pribadi kurang suka debat "mana yang lebih baik". Pertanyaan yang lebih realistis: "Kondisi tim lo sekarang butuh stabilitas atau arah?" Kalau tim lo masih banyak project ad-hoc dan klien sering nge-gass revise, KPI operasional bakal menyelamatkan lo dari chaos. Tapi kalau lo lagi bangun service line baru atau mau diversifikasi portfolio, OKR untuk agency adalah satu-satunya cara preventif supaya tim gak terjebak ngerjain project lama terus-menerus.

Coba skenario ini: pisah goal berdasarkan tipe kerja. Operational unit (delivery, support, account management) pegang balanced scorecard mini: KPI speed + KPI quality. Creative/explore unit pegang OKR dengan KR yang flexible dan milestone-based. Link keduanya via weekly sync 30 menit, bukan daily meeting panjang. Lo bakal lihat perubahan drastis di energy level tim. Nggak ada lagi yang nge-block kalender cuma buat report progress.

Warning Signs Kalau Sistem Penjadulan Lo Sedang Sakit

Tanda pertama: tim lo mulai nge-gloss over masalah. Angka di spreadsheet hijau semua, tapi client complaint naik. Tanda kedua: kamu harus nge-follow-up berkali-kali demi dapat update, padahal kanvannya udah clear. Tanda ketiga: standup meeting durasinya >20 menit dan ujung-ujungnya jadi ruang curhat atau saling tuding scope creep.

Kalau lo nemu minimal dua dari tiga hal ini, cek dulu sistem manajemen tujuan tim lo. Biasanya akar masalahnya bukan karena tim lo malas, tapi karena metrik yang dipakai nggak nyambung ke reality lapangan. OKR yang dipaksa jadi KPI bikin tim takut gagal. KPI yang dipaksa jadi OKR bikin tim kehilangan sense of ownership. Keduanya bisa diperbaiki tanpa ganti tools. Cukup luruskan hierarki: outcome > output, context > control.

Coba minggu ini: audit tiga project aktif di tim lo. Tandai mana yang butuh kestabilan (KPI operasional) dan mana yang butuh eksplorasi (OKR). Lihat apakah target di sana masih mengukur kecepatan atau mengukur arah. Kalau lo merasa frame-nya udah cocok, coba implementasikan async update di SatuTim Discussion—tanpa push meeting ulang.

Kalau lo nemu red flag yang sama seperti poin di atas, biasanya itu symptom dari masalah apa di workflow delivery lo?