Tahun lalu kita keluarkan budget buat nyewa tiga project manager. Tiga. Dalam hitungan bulan, dua di antaranya resign atau kita suruh pergi. Bukan karena skill teknis mereka jelek — justru resume mereka nge-gass banget. Tapi pas masuk ke operasional nyata, pola interaksi mereka di Slack dan Jira ngasih sinyal bahaya yang gak pernah tertulis di jobdesc.

Di mana jobdesc biasanya bohong?

Rekrutmen PM itu kayak hunting. Lo cari yang bisa handle timeline, budget, stakeholder, dan risk mitigation. Perfect on paper. Realitanya, yang bikin tim collapse bukan lack of technical skill. Itu lack of cultural alignment — terutama soal budaya kerja startup yang butuh delegasi, bukan otoritas.

PM pertama kita tipe "keeper". Ngerasa kalau dia lepas kendali, project bakal meledak. Hasilnya? Every decision kecil harus dikasih cap dari dia dulu. Junior dev nunggu approval buat nentuin struktur cache Redis. Designer harus nanya "boleh gak pake warna ini?" padahal brief udah clear. Gw inget banget kasus kemarin, satu bug critical malah ditunda 2 hari cuma karena PM nya lagi meeting dengan klien lain dan gak mau ganggu. Di satu sisi, lo dapet stability semu. Di sisi lain, throughput tim ancur karena semua arus informasi harus lewat satu choke point.

Yang kedua lebih halus. Dia ahli komunikasi, rapat kelar tepat waktu, follow-up rapi. Tapi dia gak paham manajemen peran di konteks agile scaling. Jadi dia jadi "project secretary" — collect info, forward ke tech lead, update client. Tim ngerasa aman, tapi sebenarnya cuma ada one-way communication loop. Nggak ada siapa-siapa yang merasa owned, cuma ada yang menunggu instruksi. Kalau gw bandingin sama workflow sebelumnya, hasilnya sama aja: task gantung numpuk, deadline tekor, dan orang-orang mulai mager ngerjain karena mikirnya "toilet doang kok repot-repot."

Kasus nyata: requirement yang hidup sendiri

Sinyal paling kenceng itu muncul pas sprint planning. PM baru kita biasa langsung naruh ticket di backlog dengan deskripsi setengah-setengah. Alasannya simpel: "biar fleksibel aja, nanti dieksekusi baru disesuaikan." Masalahnya, fleksibilitas tanpa guardrail itu resep disaster.

Dulu gw pernah liat kasus client agency, brief diubah 4 kali dalam sebulan. PM nya gak pernah nge-block waktu buat requirement gathering yang matang. Akibatnya, dev spent 60% harinya ngebenerin logika yang sebenernya salah dari awal. Result? Burnout rate naik drastis, turnover naik, dan client pun kesel karena deliverable gak konsisten. Di SatuTim kita pakai fitur Brief biar requirement gak ngeblur sejak hari pertama. Gak perlu tools mahal, cukup discipline. PM yang bener bakal nolak perubahan mendadak tanpa change request log. Lo gak butuh PM yang siap nge-yes semua request. Lo butuh yang berani bilang "gatau dulu, kita break down flow-nya."

Mengamati pergeseran mindset: covert micromanager vs facilitator

Bulan pertama kali kita onboard tim baru, gw gak liat deliverable dulu. Gw buka tab Slack dan Jira selama 14 hari nonstop. Tujuannya simpel: trace bagaimana dia distribute ownership.

Pola si covert micromanager gampang dikenali dari prefix message-nya. "Btw Raka, please revisi X." "Dian, note ya fitur Y harus selesai Jumat." Kalau lo counting, setiap pesan mengandung implicit directive disguised as reminder. Di Jira, dia cenderung assign task sendiri, even buat component yang udah masuk scope dev senior. Dia mikir "biar cepet kelar", tapi aslinya lagi membunuh autonomy.

Facilitator beda approach. Message-nya berbentuk pertanyaan atau context-sharing. "Raka, ada blockers di integrasi API nih. Gimana kira-kira path terbaik?" "Team design, brief sudah final, boleh langsung sprint mulai besok." Di Jira, dia jarang move cards secara manual. Dia ngeremind deadline via comment, trus leave it. Hasil observasi bulan pertama: tim fasilitator ngeremix workflow sendiri tanpa perlu dia nge-block kalender buat meeting koreksi. Waktu produktif yang balik ke tim? Minimal 3 jam per orang per minggu.

Beneran loh, perbedaan ini gak muncul saat interview. Muncul pas pressure naik dan timeline mepet. Di situ sifat asli management style keluar. Kamu bisa liat langsung dari cara mereka nge-handle escalasi: mau ngarahin ulang sistem, atau mau ngambek nyalahin eksekutor?

Trauma founder yang jadi racun delegasi

Ini bagian yang sering dielakkan. Banyak founder atau agency owner yang secara sadar maupun tidak, sengaja hire "keeper" atau "secretary" karena mereka sendiri gak siap lepas kendali. Gw jujur, 2 tahun lalu gw pernah jatuh ke lubang ini. Project klien lagi panas, client nagih tiap hari. Alih-alih percaya sama PM yang udah gw training, gw ikut campur detail teknis lewat grup chat. Hasilnya? PM nya jadi pasif, nungguin gw approve segala hal. Tim dev bingung siapa atasan benernya. Gw nge-hire orang keempat cuma buat nutup luka ego gw sendiri.

Delegasi bukan berarti disappear. Tapi lo harus tau bedanya antara guiding dan hijacking. Kalau lo masih ngerasa nyaman jadi "final approver" untuk hampir setiap commit, berarti proses rekrutmen lo lagi cari double, bukan solusi. Startup tumbuh karena speed of execution, bukan karena jumlah meeting approval. Kalau lo ngeblock kalender tim buat ngecek status tiap sore, lo gak bangun sistem. Lo lagi maintain anxiety.

KPI yang salah bikin kita kehilangan PM bagus

Ini kontroversial tapi fakta pahit: mayoritas company masih mengukur success PM dari jumlah ticket closed, SLA tercapai, atau laporan status harian. Metric itu vanity. Ngebantu lo sleep well at night, tapi ngeblind lo sama root cause friction.

Kalau lo tanya tim dev, "Seberapa cepat kalian bisa jalan tanpa perlu approve beruntun?", jawabannya bakal kasih gambaran akurat tentang health of role ini. Success sebenar seorang PM di startup bukan soal dia closing 200 ticket sebulan. Itu tanggung jawab tech lead dan QA. Tugas PM adalah remove dependency, align expectation, dan bikin pathway biar eksekusi mengalir tanpa bottleneck.

Jadi kita ganti frame KPI. Sekarang tracking-nya:

  • Mean time to decision (seberapa lama request butuh approval dari PM sebelum dieksekusi)
  • Self-resolution rate (berapa persen issue di channel yang diselesaikan oleh sub-team tanpa escalate ke PM)
  • Dependency mapping accuracy (apakah PM nemuin blocker sebelum sprint dimulai, atau malah jadi reporter setelah telat)

Angka ini gak glamor. Gak cocok dipamerin di LinkedIn. Tapi dia nyambung langsung ke velocity tim. Gw pribadi gak setuju kalau kita tetap pakai vanity metric karena bias founder yang takut kehilangan control. Sebelum kita ganti metrik, gw pernah liat team yang productivity-nya drop 40% cuma karena PM nya sibuk ngetik laporan Excel alih-alih nge-clear blocking tickets.

Apa yang bertahan di hire ketiga?

Kita stop browsing job portal selama 3 minggu setelah gantikan PM terakhir. Alih-alih cari "yang paling berpengalaman", kita cari "yang paling sadar akan batas kontrol". Interview-nya diganti dengan simulation-based assessment. Case study: kamu dapet timeline 2 minggu, 5 stakeholder konflik, resource terbatas. Bagaimana prioritaskan dan delegate?

Yang lolos bukan yang ngenum detail teknis. Yang lolos yang nawarin framework, bukan instructions. Dia tahu kapan harus hadir, kapan harus disappear.

Pas masuk kerja, kita kasih rule of thumb: "Kalau lo perlu nge-follow-up lebih dari 3x untuk satu decision, berarti proses lo rusak, bukan orangnya males." Dari sana, kita bangun feedback loop mingguan via diskusi async di SatuTim. Nggak ada laporan status wajib. Gantiinnya dengan progress snapshot + blockage tag. Hasilnya? Communication overhead turun drastis. Dan yang paling penting, junior mulai berani ambil keputusan.

Pengalaman gw bilang: rekrutmen PM yang gagal biasanya bukan karena gap skill. Tapi gap trust. Founder atau agency owner masih merasa nyaman jadi "final approver" karena trauma project kemarin yang banting setir. Padahal, delegasi itu bukan kehilangan control. Itu transfer capability.

Coba audit channel lo malam ini

Kalau standup atau check-in tim lo masih jadi ritual nunggu approval beruntun, coba tanya diri sendiri: lo lagi build system, atau lagi maintain ego?

Coba minggu ini: audit 50 chat terakhir di channel project. Hitung berapa persen yang berisi instruction vs context/question. Kalau instruction doimin, jangan salahkan tim. Ubah dulu cara lo mendefinisikan manajemen peran.

Kalau lo pengen eksplor mekanisme async decision-tracking yang ngebantu PM fokus ke blocking removal, di SatuTim ada workspace routing buat align stakeholder tanpa meetings pile-up. Coba jalanin selama 14 hari. Report balik, berapa menit yang lo dapet kembali tiap minggunya?

Kalau standup tim lo lebih dari 20 menit, biasanya symptom dari masalah apa? Share di diskusi bawah.