Gw hire 5 PM dalam waktu 6 bulan karena takut kehilangan momentum product. Hasilnya? Dalam dua minggu setelah orang terakhir onboard, tim design nolak 3 kali deliverable dan 3 dari 5 PM baru itu kabur membawa portofolio klien kompetitor.
Retensi ambruk 60%. Bukan karena gaji gak kompetitif—kita berani bayar di atas market rata-rata Jakarta. Bukan juga karena skill jelek; dua dari mereka ex-PM unicorn. Masalahnya adalah model "manajemen tim" kita saat itu sebenernya cuma nama gedenya supervisi 24 jam.
Hari ini gw bakal share bedah kasusnya. Tanpa jargon konsultan. Cuma pengalaman brutal ngerasain gimana hirarki yang salah bisa ngebunuh produktivitas, dan gimana kita balikin fokus tim lewat perubahan radikal ke otonomi pekerja berbasis OKR.
Kecanduan Growth yang Mengorbankan Struktur
Q3 tahun lalu, roadmap product kita full. Delivery melambat drastis karena bottleneck approval. Sebagai founder, instinct pertama gw tuh sama: "Kita butuh bandwidth. Gercep hire."
Proses recruiting dipencet maksimal. Lewat LinkedIn Ads, referral, sampai headhunter. Dalam 6 bulan, kita berhasil bring in 5 PM dengan background beda-beda. Mulai dari yang strong di B2B SaaS sampe yang hobi main di marketplace.
Logika di kepala gw sederhana: lebih banyak kapten berarti lebih cepat sampai tujuan. Anjir, salah total.
Akibat langsung? Gridlock. Tiap PM punya "zona" sendiri yang tumpang tindih karena mereka nggak dibolehkan ambil keputusan autonomi. Design terus direvisi karena feedback datangnya dari 4 arah berbeda. Dev sibuk jawab pertanyaan status update, bukan coding. Client mulai nanya, "Kenapa sprint 3 belum kelar? Padahal budget udah cair."
Yang ngeselin, gw nyalahin tim dulu. Gw kira mereka kurang proaktif. Padahal realitanya, struktur kerja kita gak designed buat scale. Kita lagi main SimCity level hardcore tapi pakai aturan main permainan monopoli.
Dalam konteks hiring startup, kesalahan paling umum bukannya salah pilih kandidat. Kesalahan utamanya adalah menambahkan headcount di tengah chaos tanpa memperbaiki sistem sebelumnya. Tambahan orang cuma nambah noise.
Paradoks Kontrol: Makin Dideket, Makin Ngeblock
Setelah PM ke-3 resign dalam waktu sebulan, gw sadar ini bukan masalah person. Ini masalah pola interaksi.
Gw mulai cek log komunikasi. Selama satu minggu, gw realize fakta memprihatinkan:
- Gw send 45 pesan di Slack channel development cuma buat nanya progress.
- Gw approve 12 revisi brief yang sebenernya udah jelas dari meeting standup.
- Average response time decision gw naik jadi 6 jam karena gw terlalu focus di operasional harian.
Contoh nyata: Case Rina (nama samaran), PM senior kita. Dia punya insight kuat soal feature checkout flow yang ternyata drop conversion-nya 15%. Plan dia rapi, test data udah siap.
Tapi kebiasaan gw nge-cek detail bikin dia males nge-push. Dia kasih draft proposal ke gw, gw minta adjust wording di paragraf kedua. Dia sabar nunggu 2 hari buat revisi. Waktu 2 hari itu artinya: deadline terlewat, developer idle, dan client marah-marah.
Nah, pas gw tanya kenapa dia gak langsung jalan aja, jawabannya dingin, "Sok mau nunggu konfirmasi boss biar aman."
Ini adalah kematian otonomi pekerja. Ketika founder suka intervensi detail, talent top tier bakal mati matanya. Mereka datang buat build sesuatu, bukan buat jadi anak administrasi yang menunggu izin buka kotak pensil.
Kita merasa sedang "manajemen tim" yang disiplin, padahal kita lagi melakukan micromanagement yang ngeblock kalender sendiri dan tim.
Turnaround: Nyetop Hirarki, Masukin OKR Output
Titik balik datang pas gw duduk bareng 3 PM yang bertahan di akhir Q3. Ruang meeting kosong, gw suruh mereka meletakkan HP. Gw bilang:
> "Gw minta maaf. Selama ini gw ngedefinisikan kesuksesan lo berdasarkan seberapa sering lo update gw, bukan seberapa value hasil kerjanya. Mulai besok, gaya kerjanya ganti. Gw stop nanya progress harian. Gue cuma peduli result."
Wajah mereka lega. Jelas banget.
Langkah pertamanya: Stopping all hiring. Pause dulu. Fokus retain talent yang ada dan fix workflow.
Kita implementasikan framework OKR berbasis output. Bukan output sembarangan, tapi output yang terukur terhadap goal bisnis.
Bedanya tipis tapi krusial:
- Activity-based: PM dites dari berapa meeting yang dijalanin, berapa tiket yang ditutup. Ini racun.
- Output-based: PM dites dari fitur yang ship, improvement metric yang dicapai, atau reduction friction yang terjadi.
Kita set OKR triwulanan bersama-sama. Rina dapat goal: "Reduce cart abandonment sebesar 10% di mobile web." Jalanannya dia yang tentuin. Mau A/B testing? Gapapa. Mau refactor codebase checkout? Gas. Gw cuma ikut review di milestone key results.
Di sini peran SatuTim masuk secara natural. Sekarang kita gak lagi debat via WhatsApp. Kita pake fitur Goal di SatuTim buat track OKR ini. Transparan. Real-time. Dan yang paling penting: Founder gak perlu nge-refresh chat buat liat progress. Semua data ada di situ.
Hasilnya selama 3 bulan pasca-pivot?
- Retensi stabil. Tidak ada resignation. Malah ada 2 calon PM yang mau join setelah liat budaya kerja kita yang jauh lebih santuy tapi focused.
- Miss-rate deadline turun dari 40% ke 12%.
- Cycle time development berkurang sekitar 18% karena dev gak lagi nunggu clarification berputar-putar.
Rules of Engagement: Menjaga Otonomi Tetap Hidup
Ganti metode aja gak cukup kalau mindset founder-nya gak berubah. Banyak founder yang udah janji "nggak bakal micromanage" tapi otomatis kembali nge-DM PM pas ada isu kecil.
Ini beberapa aturan main yang gw enforce di tim sekarang supaya otonomi gak jadi ilusi doang:
1. Scope Jelas, Otonomi Aman
Masalah terbesar pembunuh otonomi itu scope creep. Kalau brief berubah setiap hari, PM gak mungkin bisa fokus eksekusi. Di SatuTim, kita sekarang paksa fitur Brief yang wajib connect ke task. Kalau ada perubahan scope, harus via change request formal. Ini bikin PR-an antar department selesai lebih cepet.2. Decision Log > Meeting Status
Gw ganti semua meeting status update jadi async discussion. PM tinggal update di kolom progress SatuTim. Kalau ada blocker, baru call. Hemat minimal 4 jam meeting per orang per minggu. Bandiin deh, 4 jam itu berharga banget buat deep work.3. Fail Fast, Learn Faster
Gw nunjukin ke tim kalo gw mendukung eksperimen yang gagal asalkan belajarnya bisa dipanen. Pas Rina coba approach baru di UI search dan conversion malah turun 2%, gw gak marah. Gwe malah bahas kenapa hypotesisnya meleset. Sikap ini bikin tim berani ambil risiko cerdas, bukan defensif.Kesimpulan Gw (Yang Bukan Kesimpulan)
Hire 5 PM dalam 6 bulan itu pelajaran mahal buat gw. Biayanya bukan cuma uang recruitment atau gaji bulanan, tapi waktu 3 bulan buat bersih-bersih kekacauan dan potensi kehilangan talent bagus lainnya.
Pesan utamanya simpel: Otonomi pekerja itu bukan bonus. Itu infrastruktur. Kalau lo mau tim lo perform tinggi di startup yang serba gesit, lo harus bangun sistem yang memungkinkan mereka mengambil keputusan tanpa selalu nengok belakang.
Jangan biarkan insting kontrol founder ngebunuh kecepatan tim. Trust, tapi verify via data, bukan via hover over keyboard.
Kalau lo lagi di fase expansion dan merasa tim makin lambat meskipun headcount naik, coba cek dulu: Apakah lo lagi menambah kapasitas, atau cuma menambah rapat?
Coba minggu ini: Cek log chat lo sama PM utama. Berapa persen yang jadi follow-up request status vs diskusi solusi strategis? Kalau status占 dominan, mungkin sudah waktunya lo mundur selangkah dan biarkan mereka mengemudi.