Gw mecat 3 dari 6 project manager yang gw rekrut dalam satu sprint. Bukan karena mereka kurang kerja keras — tapi justru terlalu banyak bergerak di jalur yang sama persis. Skala tim gw naik dari 7 jadi 24 orang, dan gw pikir solusi simpelnya cuma satu: tambah headcount PM buat jaga timeline klien. Alasannya terdengar logis banget waktu itu. Hasilnya? Ngeselin.
Ketika Logika "Tambah Headcount = Tambah Kapasitas" Gagal Total
Jujur, keputusan hiring project manager barengan itu bukan hasil nekat doang. Itu hasil panik yang dikemas rapi di spreadsheet. Q3 tahun lalu, pipeline klien baru masuk gila-gilaan. Tiga project enterprise, dua retainer bulanan, plus maintenance legacy system. Tiap PM di tim udah nge-block kalender sampai malam hari. Deadline mulai kebanting, status report jadi kopi darat async yang gak dibaca siapa-siapa.
Gw tarik kesimpulan salah: "Kita butuh lebih banyak tangan yang ngatur jalan." Padahal, masalah utamanya bukan jumlah tangan. Masalahnya adalah cara tangan-tangan itu nyatu. Kita langsung onboardin enam PM baru. Tanpa briefing panjang lebar, cukup channel Slack #pm-sync dan Jira board yang dipindah-pindah. Dalam sepuluh hari, chaos-nya nyata.
Yang pertama hilang adalah role clarity startup. Tiap PM merasa wajib 'nge-claim' stakeholder kunci. Client A punya dua PM yang follow-up beda waktu. Client B dapet brief yang sama dikirim via email dan WhatsApp sama PM berbeda. Frontend team kaget tiap kali ada request perubahan UI tanpa context jelas, karena tiga PM lagi aktif 'ngegass' approve mockup di Slack thread yang berbeda. Duplikasi tugas bukan cuma soal wasted time, tapi juga burnout. Designer gw nangis karena harus revisi empat kali layout tombol cuma beda versi guideline dari PM yang beda mindset.
Approval War & Silo yang Diam-diam Bunuh Timeline
Konflik approval di frontend jadi gejala terminal-nya. Awalnya gw kira ini urusan teknis atau skill gap. Ternyata ini murni masalah struktur. Tanpa framework decision-making yang disepakati, setiap PM otomatis jadi CEO mini-nya masing-masing project. Ada yang strict waterfall, ada yang agile purist, ada yang mager mikir dokumentasi tapi over-responsive di chat grup.
Tim gw sendiri mulai pecah jadi pulau-pulau kecil. Tim QA malah jadi gatekeeper tidak resmi karena bingung harus testing fitur versi mana. Marketing campaign buat client enterprise tertunda dua minggu karena content copywriter menunggu sign-off dari PM yang lagi cuti. Padahal deadline sudah fix sejak Kickoff. Sales mulai marah karena janji ke client bertabrakan sama realitas internal.
Gw coba meeting darurat. Tiga jam. Hasilnya: sama. Masing-masing mempertahankan area kerjanya. Sampai akhirnya salah satu klien besar hampir cancel kontrak karena missed milestone. Waktunya mepet banget. Kita harus turun ke akar masalah, bukan cuma tutupi bocorannya dengan lembur paksa.
The Silent Tax: Async Friction & Meeting Debt
Yang sering kita remehkan pas scale-up bukan konflik terbuka, tapi friction diam-diam di inbox. Setiap PM yang nyebrang jurisdiction berarti menambah satu layer notifikasi, satu request clarification, dan satu potensi miss-read konteks. Di kasus gw, rata-rata developer kehilangan 1,5 jam per minggu cuma buat jawab pertanyaan berulang tentang status deliverable yang sebenarnya udah fixed di tiket.
Gw nge-track selama sebulan. Hasilnya mencengangkan: 40% komunikasi internal antar-tech team terjadi lewat direct message, bukan di ticket atau kanal project. Artinya, knowledge-nya散落 (scattered). Waktu Dev Lead nanya ke Junior, junior-nya harus buka 4 chat berbeda sebelum nemu jawaban yang valid. It’s exhausting. Dan yang paling parah, kalau dev resign, semua context ikut pergi.
Solusi anti-friction sederhana: hentikan ad-hoc sync. Ganti dengan async update harian di platform yang memaksa format spesifik. Gw alihkan semua progress check-in ke SatuTim Discussion. Tiap PM wajib isi tiga baris: yesterday, today, block. Gak boleh narasi panjang, gak boleh luapan emosi. Cuma fakta. Akibatnya? Channel Slack #dev-talk berkurang drastis. Developer bisa deep work tanpa notifPM yang terus bunyi. Founder bias gw dulu bilang "kan lebih cepat langsung chat aja" ternyata keliru. Chat memang cepat, tapi tracing-nya nol. Dokumentasi async mahal di awal, murah di maintenance.
Operasi Darurat: Role Audit & Template RACI Versi Kami
Gw panggil semua PM plus lead dev dan lead design. Bukan buat ngerjain mereka, tapi buat audit peran. Gw taruh whiteboard, tulis nama tiga project besar yang hampir gagal, lalu tanya: "Siapa yang berhak approve final UI? Siapa yang nerima change request? Siapa yang lock timeline ke client?"
Jawaban acak-acakan. Nah di titik ini, gw kenalin revisi sederhana dari template RACI yang biasa dipakai konsultan. Tapi versi kami gak pake istilah korporat berat. Gw bikin tabel kolaborasi simpel:
- Responsible: yang eksekusi (biasanya designer, dev, atau developer)
- Accountable: yang tanda tangan final (cuma satu orang per deliverable, bukan tim PM)
- Consulted: yang perlu diajak diskusi sebelum keputusan (tech lead, product owner)
- Informed: yang cuma butuh tahu (sales, finance, client contact person)
Efeknya kayak pindah lantai mobil. Dalam lima hari, approval turnaround time turun dari rata-rata tiga hari jadi delapan jam. Frontend team berhenti revisi hal sepele. Client satisfaction score naik drastis karena feedback loop jadi linear, bukan spiral. Tiga klien besar kita selamat dari penalty clause. Yang paling parah, budaya saling tunggu-nunggu hilang. Orang mulai nge-push progress, bukan nunggu izin.
Post-Mortem: Siapa yang Bertahan & Kenapa Gw Salah Estimasi
Dari enam PM yang gw bring in, cuma dua yang lulus filter RACI + async discipline. Keduanya bukan yang paling senior, tapi paling disiplin nge-lock scope. Satunya bahkan pernah gw suruh drop dua project retainer demi fokus delivery satu enterprise deal. Awal-awal dia protes halus, "Founder, kan budget engagement kita bakal turun." Gw jawab, "Turun revenue, naik margin profit. Pilih mana?" Dia pilih profit. Dua bulan kemudian, project itu finish on-time dan dapat bonus retention dari client.
Gw pribadi gak setuju sama budaya agensi yang nge-hold semua PM di posisi generalis sambil berharap mereka bisa multitask flawless. Itu ilusi. Yang bertahan cuma yang mau specialize. Gw ubah title internal jadi Delivery Lead, Stakeholder Lead, dan Technical Coordinator. Judul doang? Mungkin. Tapi psychology matter. Orang mulai paham boundary-nya sendiri. Tinggalin ego "gw yang paling tau semua phase".
Yang keluar? Dua yang masih ngegandemin old habits. Mereka gak salah secara teknis, cuma gak cocok sama sistem transparansi tinggi. Gw gak nyalahin. Agensi scale-up butuh matching temperament, bukan cuma checklist skill. Gw tanggung biaya severance-nya, plus kasih reference letter jujur: "Kerennya dia di client-facing, tapi kurang nyaman di structured async track record."
Lessons Learned Agensi: Flat Structure vs Birokrasi Terbawa
Banyak founder ngerasa struktur tim flat itu anti-birokrasi. Benar, tapi flat bukan berarti tanpa batas. Flat structure works ketika komunikasi channel-nya disengaja, bukan asal terbentuk. Pas kita scale up ke dua puluh orang lebih, natural instinct manusia mau ambil alih kontrol. Tanpanya, chaos pasti terjadi. Tapi reaksi panik lewat rapid hiring justru bikin birokrasi terselubung.
Solusinya bukan balik ke hierarki kaku, tapi bikin micro-boundaries. Jangan biarkan title "Project Manager" jadi seragam blanket permission untuk campur semua phase project. Specialize them. Punya PM yang fokus di delivery, ada yang dedicated di stakeholder management, ada yang technical coordinator. Gw ubah title internal aja dulu sebagai psychological anchor, sebelum ganti HRIS atau rewrite job description formal.
Pengalaman ini jadi lessons learned agensi paling mahal buat gw. Biaya overhead enam PM baru ternyata tiga kali lipat dari denda keterlambatan project. Waktu yang terbuang buat sinkronisasi manual jauh lebih destruktif daripada biaya software manajemen. Dan yang paling nyesek: trust erosion. Tim engineering mulai ragu kalau PM-nya berubah-ubah arah. Sales mulai takut janji deadline karena internally nobody owns it anymore.
Kalau lo lagi mempertimbangkan tambahan headcount management pas scale-up, stop dulu sebentar. Cek dulu apakah bottleneck-nya memang kapasitas eksekusi, atau cuma noise dari overlapping authority. Coba minggu ini: mapping deliverable terakhir tim lo ke kolom Accountable di spreadsheet. Lihat berapa kali nama yang sama muncul. Kalau lebih dari dua, lo lagi bakar budget demi ilusi kontrol.
Pertanyaan gw buat lo: setelah lo audit role clarity startup di tim lo, posisi mana yang selama ini sering jadi double-owner antar tim? Cerita di komentar, mungkin kita bisa swap template RACI versi kita.