Kemarin gw liat data attrition Q2 tim kita. Empat dari enam PM yang gw hire barengan di bulan Januari udah clear desk sebelum masuk hari ketujuh puluh lima. Bukan karena mereka junior, bukan karena gaji gak kompetitif, tapi sama satu hal: mereka tenggelam di konteks proyek yang sebenernya udah ada, cuma gak pernah diterjemahkan ke bahasa baru.

Yang paling ngeselin, gw baru sadar setelah sesi debrief ke-3. Gw pikir loang kerjaan yang lebar itu peluang buat grow fast. Faktanya, tanpa sistem, kamu malah ngebakar biaya rekrutmen, ngerusak timeline delivery, dan bikin sisa tim yang bertahan jadi stress tambahan pas harus nerusin PR-an yang ditinggalin.

Kenapa Skill Bukan Masalah Utamanya

Banyak startup founder tips yang bilang kalau masalah retention di posisi strategis itu soal cultural fit atau compensation benchmark. Bener sih, sampai titik tertentu. Tapi pas gw duduk sama 4 orang PM yang resign itu — satu per satu, sambil ngopi di pantry — narasinya berulang: “Gw kerjanya banyak, tapi gak tau ini bagian dari project besar apa, siapa stakeholdernya, dan deliverable minggu depan harus kelar secepat apa.”

Mereka bisa manage Jira, ngeruntuhin WBS, sampe present ke client pake fasih. Tapi begitu masuk hari ke-14, mereka mulai mikir dua kali sebelum approve scope change. Alasannya simpel: takut salah kasih janji karena gak punya peta utuh. Tanpa knowledge transfer yang terstruktur, tiap PM ulang pelajari proyek dari nol. Ulangi meeting intro, ulangin baca dokumentasi lama, ulangin nego deadline yang sebenernya udah dikunci bulan lalu.

Di agensi atau startup skala menengah, ini mah bunyi diam-diam. Kerjanya kelar, client happy, tapi burnout naik 30% dalam dua bulan. Gw pribadi gak setuju kalau solusi terakhir selalu “hire yang senior banget”. Senioritas gak otomatis paham konteks bisnis lo, kecuali lo punya mekanisme buat narik garis merah antara pengalaman lampau dan realitas operasional sekarang.

Kita Coba Perbaiki: First Deliverable Roadmap

Bulan ke-3, gw putusin buat pause dulu pipeline hiring. Daripada nyiapin ruang kerja baru dan nunggu orang ketiga masuk ke lubang yang sama, gw fokus ke infrastruktur kontekstualnya dulu. Langkah pertamanya gak pake jargon HR. Gw bikin apa yang gw sebut first deliverable roadmap.

Intinya sederhana: setiap PM baru wajib nemuin deliverable pertama dalam 14 hari kerja pertama. Bukan learn semua tool, bukan hafal org chart, tapi langsung nunjukin hasil kecil yang measurable. Misalnya: refine backlog sprint berikutnya, klarifikasi ambigu di client brief, atau set up dashboard tracking bug yang selama ini manual.

Kenapa metode ini jalan? Karena otak butuh anchor. Tanpa milestone awal, PM baru terus处在 state “nonton dan tanya”, yang secara perlahan bikin rasa percaya diri turun. Pas mereka dapet satu win konkret di minggu kedua, dinamika shift jadi “ikutin ritme tim”. Gw liat sendiri di kasus Budi, ex-PM dari startup logistik. Hari ke-9 dia deliver cleaned-up user story map buat module pembayaran. Client gak notice bedanya, tapi internal alignment naik drastis. Task gantung yang sebelumnya numpuk di kolaborasi cross-functional tiba-tiba cair.

Project Intake Template yang Gak Bikin Mata Berdarah

Buat support first deliverable, kita perlu wadah buat muatin konteks itu. Kebanyakan company pake form intake yang panjangnya kayak novel. Gak bakal dibaca, apalagi dikejar deadline. Kita potong jadi tiga blok wajib: Business Context, Current Friction, Immediate Next Step.

Di SatuTim kita pakai fitur Brief biar requirement gak ngeblur dan semua orang baca dokumen yang sama. Blok pertama isinya: kenapa project ini lahir, siapa payer-nya, apa KPI sukses yang udah disepakati. Gak boleh kosong. Kalau client belum define KPI, PM harus catet “pending” plus nama stakeholder yang wajib diundang ke discovery call.

Blok kedua adalah current friction. Ini bagian yang paling sering dilewatkan. Apa yang lagi macet? Bug kritis di staging? Tim design lagi bottleneck approval? Client marah karena response time lambat? Catet fakta, bukan opini. Gw selalu ingetin tim: “Kalau lo nulis ‘client kurang jelas’, ganti jadi ‘brief versi 3 belum sign-off oleh Head of Product’”. Spesifikitas itu senjata utama buat menghindari blame game.

Blok ketiga immediate next step. Ini jembatan antara onboarding experience dan real execution. Contoh: Minggu 1-2, mapping existing assets. Minggu 3, scheduling stakeholder sync. Minggu 4, proposal fix untuk top 3 blocker. Template ini simple, tapi paksa PM baru mikirin langkah strategis sejak hari pertama. Dan yang paling penting, dokumen ini hidup. Gak disimpan di folder Google Drive yang terlupakan, tapi di-platform diskusi yang bisa dikomentari, di-update, dan ditag ke owner-nya.

Weekly Checkpoint vs Shadowing Buta

Setelah intake template standar, kita butuh rhythm buat memastikan knowledge transfer gak numpuk jadi tugas menggantung. Kami meninggalkan konsep shadowing tradisional yang biasanya berubah jadi “temenin temenin aja, nanti juga paham”. Cara itu boros waktu senior, dan bikin junior makin ragu ngomong.

Sebagai gantinya, kita terapkan weekly checkpoint berdurasi 30 menit ketat. Jadwal tetap, agenda rigid, dan hasilnya harus artefak nyata. Tiap Jumat jam 3 sore, PM baru, tech lead, dan account manager (kalau relevant) duduk bareng atau join async discussion. Tiga pertanyaan wajib dijawab:

  1. Apa yang lo kira-kira harus kelarin minggu ini berdasarkan intake template?
  2. Blocking factor apa yang muncul, dan siapa yang harus lo tag buat bantu clear?
  3. Adakah misalignment antara ekspektasi client dan kapasitas tim internal?
Gw personally gak suka kalau meeting berubah jadi sekadar status update. Status update itu buat Slack thread atau kolom progress di tracker. Meeting itu buat decision dan escalation. Dengan format ini, kita potong noise. Lo gak perlu cerita tentang cuaca atau drama klien yang sebenernya udah diselesaikan dev team bulan lalu. Fokus ke gap.

Hasilnya terukur. Dalam kuartal pertama pake sistem ini, rata-rata waktu rampung onboarding turun dari 45 hari jadi 21 hari. Exit interview data menunjukkan keluhan utama “tidak memahami prioritas” hilang total. Yang tersisa cuma feedback teknis yang gampang di-handle, misalnya “butuh access lebih cepat ke repo codebase”. Masalah akses itu gampang di-fix, beda dengan masalah konteks yang butuh berbulan-bulan buat rebuilt.

Apa yang Bisa Lo Copas Besok Pagi

Kalau lo lagi di posisi ngebangun tim di tengah pertumbuhan eksponensial, jangan buru-buru nge-spam interview loop. Rekrutmen massal tanpa fondasi kontekstual itu bom waktu. Coba tarik napas, evaluasi flow onboarding experience yang sekarang berjalan. Tanyakan ke tim senior: berapa menit wasted per minggu menjelaskan hal yang sama ke orang baru? Kalau jawabannya lebih dari 30 menit, lo butuh standardisasi, bukan lebih banyak tenaga.

Implementasi first deliverable roadmap dan checkpoint mingguan ini gak butuh software mahal. Cukup disiplin eksekusi dan mentalitas yang mau berhenti nge-guess. Mulai dari template intake sederhana, tentukan aturan main meeting, dan pastikan setiap PM baru punya satu tujuan kecil yang terukur di dua minggu pertama. Konsistensi di detail kecil ini yang akhirnya ngeblock churn rate di posisi kunci.

Gw nulis ini bukan karena kita sempurna. Masih ada gap di handover antar-dept yang kadang bikin PR-an molor. Tapi arah sudah jelas: konteks harus didahulukan sebelum kompetensi. Skill bisa dilatih. Context yang hilang butuh waktu lama buat balik ke titik semula.

Coba minggu ini: audit satu project intake yang sedang jalan. Potong jadi tiga blok (context, friction, next step). Kirim ke PM baru lo, dan schedule checkpoint 30 menit Jumat depan. Lihat apakah kecepatan keputusan naik atau justru nge-block kalender lo lebih banyak. Kalau lo lagi struggle sama angka resignation di bawah 60 hari, symptom utamanya biasanya bukan gaji — tapi berapa lama mereka butuh waktu buat merasa “pilot” beneran. Ceritakan di komen, atau coba async debrief di SatuTim Discussion dulu sebelum lo ambil keputusan hiring berikutnya.