Kemarin gw liat dashboard activity tracker. Satu senior dev ngetik 4500 baris code hari itu. Gw awalnya seneng, anggap dia gercep banget. Trus gw buka Git log-nya. Ternyata dia cuma ngidupin linter dan format code doang sambil dengerin podcast.

Beneran loh. 4500 baris whitespace.

Kasus begini udah tiga kali gw temuin. Orang yang "top performer" di tracker, tapi delivery rate minus karena bug fatal, dan selalu nunda pull request biar keliatan "lagi deep work". Yang ngeselin: dia pinter banget mainin algoritma lo.

Kalau lo masih andal ke track jam kerja atau mouse movement buat ngukur disiplin, lo gak lagi management. Lo lagi ngasih bonus buat aktor. Dan yang lebih parahnya, lo lagi ngebunuh psychological safety tim lo tanpa disadarin.

Kali aja lo kira tracking itu bikin disiplin

Kebanyakan founder dan agency owner beli software tracking karena lo merasa gelisah. "Gue kontrol, gue tenang." Tapi pengalaman gw, kontrol berlebihan itu justru memicu reaksi evolusi liar di tim. Lo bikin environment dimana orang takut dikira tidak produktif, dan efeknya? Tim mulai ngelakuin work-around.

Dulu waktu gw ngurus project agency besar, client minta report detail tiap jam. Hasilnya? Kami punya 3 junior dev yang bikin script auto-send Slack message berisi status "Sedang coding feature X" setiap 15 menit. Gak perlu nyentuh keyboard, cukup biarkan timer jalan.

Code quality ancur. Deadline melempem karena mereka sibuk memastikan mereka "aktif" di mata client, bukan memperbaiki architecture.

Ini paradoks yang umum. Tracking yang terlalu agresif bikin tim fokus pada proses, bukan outcome. Mereka berhenti berinovasi karena inovasi itu ribet dan kadang terlihat seperti "mager" di awal. Lo pengen hindari micromanagement, tapi lo paksa tim masuk ke dalam kotak yang sama lewat data palsu.

Solusinya bukan memperhalus software tracking. Solusinya adalah ganti metrik. Kita harus ukur hasil kerja tim yang nyata, bukan jejak digital yang bisa dimanipulasi. Di SatuTim kita sebenernya punya fitur log waktu, tapi tim internal gw jarang pakai itu sebagai penentu performa. Kita pakai pendekatan lain.

1. Velocity per Deliverable (Bukan burrito points doang)

Banyak PM ngerti konsep Velocity di Agile. Tapi sering terjebak pada angka Story Points saja. Angka SP itu manipulatif kalau gak dibarengi dengan konteks kompleksitas dan kualitas.

Cara gw ngukur ini: Velocity = Jumlah Deliverable Final Approved × Bobot Kompleksitas / Waktu Spend.

Misal, tim dev lo ada 5 orang. Lo pantau velocity per person per sprint. Kalau velocity naik, bagus. Tapi jangan lupa ngecek rasio bug. Kalau velocity naik drastis tapi production error juga naik, artinya dia lagi nge-gass ngerjain item simpel dan menghindari item risky. Itu tanda bahaya, bukan pencapaian.

Contoh konkret bulan lalu: Tim gw ngerjain fitur payment gateway. Ada satu engineer, sebut aja Alex. Velocity-nya konsisten tinggi. Tapi pas review, setiap kali gw lihat log committers-nya, Alex selalu commit di tengah malem dan PR-nya selalu ditolak reviewer karena typo naming convention.

Alex lagi ngerjain tugas yang gampang-gampang aja. Dia menghindari tugas integrasi API yang butuh riset mendalam karena dikhawatirkan velocity-nya turun. Hasil kerja tim jadi timpang. Feature dasar lancar, tapi infrastructure-nya rapuh.

Gunakan velocity untuk identifikasi apakah tim lo sedang "bermain aman" atau benar-benar delivering value yang sulit. Kalau velocity stabil tapi quality score turun, itu alarm merah.

2. Rasio Revision-to-Final: Detektor Kualitas Tersembunyi

Rasio ini simpel tapi brutal. Hitung berapa kali sebuah task perlu direvisi sebelum diterima sebagai final by client atau internal stakeholder.

Rasio rendah = orang paham brief, komunikasi bagus, atau skill solid. Rasio tinggi = ada kebocoran di mana saja. Bisa jadi tim gak baca brief dengan seksama, atau tim ragu mengambil keputusan dan submit hasil mentah buat didiskusikan ulang.

Di dunia agency, ini metric paling penting buat ngelindungin margin profit. Setiap revisi non-scope adalah pembocoran uang.

Kasus klien kemarin: Designer A ambil project rebranding logo. Hasil akhir revisi 2 kali. Designer B ambil job serupa, revisi 8 kali, akhirnya desainnya mirip banget sama Designer A. Siapa yang lebih efisien? Secara jam kerja mungkin Designer B lebih lama, tapi resource consumption-nya jauh lebih boros.

Tapi hati-hati, jangan langsung jebloskan designer B sebagai buruk. Rasio revisi tinggi bisa jadi indikator masalah proses, bukan talenta. Mungkin brief dari client memang ambigu, atau mungkin tim internal kurang tegas nunjukin arah di awal.

Gunakan metrik ini untuk diagnose. Kalau satu orang terus-menerus punya rasio tinggi sementara rekan sejawatnya rendah, itu mungkin soal kemampuan teknis atau attention to detail. Tapi kalau semua orang rasionya tinggi, masalahnya ada di fase briefing atau handover. Jangan salahkan orang dulu, cek alurnya.

Dengan memantau rasio ini, lo bakal tahu siapa yang bisa dilepas tanggung jawab (low risk) dan siapa yang perlu didampingi agar gak wasting time.

3. Time-to-First-Value: Dari Masuk sampai Jadi Manfaat

Metrik ketiga ini sering luput dari perhatian founder yang terobsesi jam kerja. Time-to-First-Value (TTFV) ngukur seberapa cepat seseorang memberikan kontribusi nyata setelah memulai tugas.

Bandingkan dua scenario:
Person A masuk kerja jam 9, ngetik sampe jam 4 sore, output-nya cuma email konfirmasi ke vendor.
Person B masuk jam 10, tapi jam 11 sudah kirim draft strategi konten yang langsung dipakai klien untuk generate leads.

Si B menghasilkan value lebih cepat meskipun "masuknya" telat. Kalau lo based on track jam kerja, lo mungkin marahin si B. Padahal bisnis lo untung karena si B.

TTFV membantu lo menemukan "flow state" tim lo. Orang yang produktif biasanya butuh waktu warming up. Kalau lo paksa mereka masuk jam 8 pagi tapi hasilnya nihil sampai jam 10, itu waste of money.

Gw pribadi suka mengukur TTFV di project async. Di SatuTim, kita sering pakai fitur Discussions buat kolaborasi tanpa meeting panjang. Hasilnya? TTFV tim gw naik signifikan. Kenapa? Karena mereka gak kehilangan context switching gara-gara standup meeting. Kontribusi pertama muncul lebih cepet.

Untuk implementasi, lo bisa hitung durasi dari assignment dibuat di tool management (seperti SatuTim Board) sampai pertama kalinya ada output valid (code merged, design uploaded, atau copy dikirim). Target nya bukan minimum absolut, tapi trend. Kalau tren TTFV menurun dalam 2 sprint, berarti lo berhasil ngebantu tim lo fokus lebih cepat.

Cara Validasi: Apakah Sistem Monitoring Lo Toxic?

Berani bilang bahwa sistem monitoring lo itu toxic itu langkah berat. Tapi gw punya cara validasi sederhana yang bisa lo lakuin minggu depan. Gak perlu survey karyawan yang nanti jawabannya dipaksakan demi jabatan.

Lakukan eksperimen selama 2 sprint.

Matikan total alat tracking jam kerja atau activity monitor untuk periode ini. Ganti sepenuhnya dengan 3 metrik di atas: Velocity per Deliverable, Rasio Revision-to-Final, dan Time-to-First-Value.

Catat datanya. Apa yang terjadi?

Jika metrik baru ini menunjukkan peningkatan atau setidaknya stabilitas, sementara moral tim membaik dan lo merasa beban mental lo turun karena gak perlu ngereview log aktivitas yang membosankan, maka selamat! Lo baru sadar sistem lama lo itu bungkam tim lo.

Biasanya, setelah transisi ke outcome-based metrics, akan ada beberapa anggota tim yang performance-nya turun tajam. Itu wajar. Orang yang biasa "bertingkah" di tracker gak bisa bertahan kalau datanya diganti bukti nyata. Biarkan mereka keluar atau berikan coaching intensif.

Yang lebih menarik, sering kali justru middle-tier employees yang bangkit. Orang-orang yang sebelumnya takut tampil beda karena takut dianggap lamban di tracker, sekarang berani ambil tantangan lebih besar karena yang dinilai adalah hasilnya.

Ini soal mindset shift dari control menuju trust-with-accountability. Trust gak berarti lepas tangan. Trust berarti lo percaya tim lo punya insting profesional, dan lo hanya perlu menyediakan scoreboard yang adil.

> Cobain minggu ini: pilih satu project kecil, ganti tracking ke 3 metrik ini. Libatkan tim lo dalam definisi metrik-nya supaya mereka accept. Lihat apa yang berubah.
>
> Kalau lo punya pertanyaan soal cara nerapin Time-to-First-Value tanpa bikin tim feeling diawasi, leave a comment di bawah. Kita diskusin.
>
> Atau langsung coba log flow yang lebih sehat di SatuTim Discussion. Mulai dari sinergitas async, bukan sekadar input jam.