Kita Pas Naik Jadi 12 Orang, Dugaan Gw Salah Total
Tiga bulan lalu, tim gw melemahkan diri sendiri bukan karena client drop atau budget habis. Kita tumbuh jadi 12 orang, tapi alih-alih production value naik, output malah macet di fase review. Gw ngetap timer meeting standup — 18 menit buat 7 orang. Dan masih ada yang nyamperin meja sambil tanya, "btw ini copy-nya siapa ya harus approve?" padahal deadline kemarin sore.
Yang ngeselin sih bukan kekacauannya. Yang ngeselin adalah timing deteksinya. Gw butuh sebulan penuh buat ngeliat kalau akar masalahnya bukan talent issue, tapi manajemen role ambiguity yang gw anggap sepele pas onboard.
Kenapa JD Kaku Gagal di Agensi Kreatif
Pertama kali kita sadar ada gesekan, instinct gw otomatis ngeluarin template HRD. Gw bikin deskripsi kerja tim agensi standar: siapa handling apa, siapa report ke siapa, apa deliverable masing-masing. Hasilnya? Tim design pada grogi, copywriter merasa dikasih mickey mouse contract, dan klien gak peduli sama sekali soal struktur internal kita.
Agensi kreatif itu kayak band cover lagu orang lain. Setiap person punya style, setiap project butuh penyesuaian instrumen. Kalau lo paksa mereka masuk kotak JD kaku, dua hal terjadi: pertama, senior dev/designer bakal skip bagian yang "bukan tugasnya" even kalau itu critical path. Kedua, junior staff nge-block kalender alias mager ngerjain sesuatu yang overlap, takut dianggap sotoy atau overstep.
Gw udah coba 3 cara sebelumnya — mulai dari weekly sync intensif, sampe bikin SOP dokumentasi 20 halaman. Semua mati di tengah jalan karena tim kreatif males baca PDF. Yang akhirnya nyambung cuma contoh konkret plus batasan eksplisit di setiap project kickoff.
Gw pribadi gak setuju kalau kejelasan sistem harus diukur dari ketebalan dokumen onboarding. Di dunia yang move cepat, yang jalan cuma satu: kejelasan peran tim startup harus lahir dari konteks project, bukan dari katalog jabatan. Job title itu branding luar. Responsibility matrix itu mesin penggerak dalam. Lo bisa punya Chief Creative Officer yang nggak tahu detail eksekusi, atau junior executor yang sebenarnya jadi bottleneck utama. Angka bicara lebih jujur daripada kartu nama.
Draw the Line, Tapi Tetep Ruang Gerak
Kami coba ubah pendekatan dari "siapa tanggung jawab pasti apa" jadi "di fase ini, siapa yang nge-draft, siapa yang nge-review, siapa yang finalize". Itu intinya. Kayak light RACI versi startup, gak perlu matriks Excel 12 kolom. Cukup pakai tabel sederhana di docs internal:
- Phase Discovery: PM nge-draft brief, Research nge-validasi, Client approve.
- Phase Execution: Design nge-draft layout, Copy isi copywriting, PM cross-check flow.
- Phase Review: Lead fungsi sign-off, PM submit ke client.
Rework Rate Drop 40% dalam 2 Sprint: Bukti Nyata
Perubahan ini gak instan terasa sehari. Butuh minimal dua sprint (kita pake durasi 10 hari) buat tim adaptasi rhythm-nya. Tapi metriknya mulai stabil di akhir sprint ke-2. Rework rate turun 40%. Bukan karena kami jadi lebih jago ngebug atau ngecek spelling. Ini murni soal elimination of friction.
Data dari log commit & version history project gw nunjukin kalau rata-rata revisi per asset turun dari 2.8 jadi 1.6. Jumlah waktu spent di channel general buat klarifikasi status tugas turun hampir 60%. Simple stuff. Tapi sering banget lupaan di fase ekspansi.
Yang paling gw suka dari approach ini: gak perlu approval HR atau rapat full-team buat validasi. Playbook internal per fungsi cukup di-sync di awal quarter. Lo tinggal update kalau scope project berubah drastis. Flexibel, gak kaku, tapi tetap punya anchor.
Async Check-in Ganti Ritual Meeting Harian
Di SatuTim kita biasanya ngerekam habit ini lewat fitur Discussions. Gw ganti ritual standup verbal jadi async thread tiap pagi. Tiap member nge-post progress, block, dan next-step sesuai RACI mereka. Gak ada yang butuh presentasi panjang lebar. Yang penting readable, traceable, dan actionable.
Contoh konkretnya begini. Minggu lalu, task hero banner e-commerce macet karena copy belum masuk. Dulu, ini bakal rame di group WA: "guys banner udah siap, kapan copynya?", "sudah kirim Slack", "iya tapi folder nya dimana?". Sekarang, designer tinggal leave comment di ticket: "Layout finalized, waiting copy input untuk headline variant A/B. Blocker: menunggu approval headline dari PM." PM langsung reply: "Approved variant A. Deadline 14.00." Selesai. 3 menit. Gak ada context-switching, gak ada noise.
Playbook-nya jangan ditaruh di Google Drive selamanya. Taruh di sidebar tool project management atau pinned di workspace komunikasi utama. Update tiap kali ada new hire atau scope shift besar. Kalau cuma dipublish dan lupa dibaca, artinya lo masih main-asap.
Kalau lo mau coba shift yang sama, jangan mulai dari perbaikan dokumen. Mulai dari pemetaan bottleneck. Ambil satu project yang baru aja gagal atau hampir miss deadline. Trace ulang: di titik mana tim lo muter-muter? Biasanya lo bakal nemuin 2-3 peran yang tumpang tindih secara diam-diam. Tarik garis batasnya. Tulis di shared drive. Implementasikan 2 sprint. Lihat datanya.
Anti-Pattern: Light RACI Bukan Surat Perintah
Banyak founder atau lead yang salah kaprah pas implement. Mereka mikir light RACI berarti bikin checklist yang harus dicentang sebelum langkah berikutnya boleh dilakukan. Hasilnya? Proses jadi kaku, turnaround melambat, dan orang-orang mulai nge-workaround dengan keluar dari platform cuma buat ngegas.
Gw pernah alami ini di tahun kedua. Waktu itu gw terlalu detailin field "approval required" di setiap subtask. Tiba-tiba, designer mikir dua kali antes maenin palet warna karena takut dianggap overstep PM. Tim engineering jadi takut deploy hotfix tanpa email konfirmasi. Padahal seharusnya matriks ini cuma alat align, bukan alat control. Solusinya? Gw cabut semua field mandatory kecuali sign-off phase-level. Sisanya kasih space buat kolaborasi lateral. Hasilnya? Velocity balik normal, bahkan naik 15% karena orang berhenti mikir "boleh gak ya gue kerjain ini" dan mulai fokus "bagaimana gue solve ini".
Kuncinya simple: light RACI harus bisa dibaca dalam 10 detik. Kalau lo butuh zoom in dan highlight, lo terlalu banyak nulis.
Menangani Resistensi Senior Tanpa Drama HR
Scale up selalu ketabrak ego, khususnya sama member yang udah lama jalanin sistem chaos dan ternyata cukup berhasil. Mereka biasa bilang, "Dulu kita kerjain semaleman kelar, sekarang dikasih matriks? Ribet amat sih." Suara-suara kayak gini bisa bikin lo goyah, apalagi kalau timing lagi genting.
Gw pernah hampir drop because of ini. Client enterprise minta rapid prototype, deadline 3 hari. Tim senior desain nawarin cara "semalam ngebut doang, esoknya rapihin". Logic-nya valid secara teknis, tapi gak valid secara operasional. Gw ingetin pelan-pelan: "Gue paham lo mahir ngegas. Tapi gue lagi build sistem buat tim 20 orang bulan depan, bukan buat sprint ini doang. Kalau lo ngebut tanpa record trail, siapa yang bakal nerusin pas gue cuti?"
Responnya dingin selama 2 hari. Trus malemnya dia DM gw: "Oke, gue coba ikut matrix. Tapi kalau besok hasilnya kurang oke, gue gabut dulu." Besoknya? Outputnya malah lebih konsisten karena dia fokus ke visual, sementara PM focus ke alignment client. Dia realize kalau matriks ini gak ngebajak skill dia, cuma ngebuang overhead mental yang gak perlu.
Tips gw: jangan debat prinsip di grup. Call 1-on-1. Acknowledge track record mereka. Tawarkan pilot project kecil. Biarkan data yang ngomong, bukan ego lo.
Pertanyaan Buat Lo yang Lagi Scaling
Kalau tim lo sekarang udah di atas 15 orang, apakah lo masih rely sama "saling ngerti" antar-dev, atau udah ada sistem eksplisit buat manage handover? Coba minggu ini: buka satu ticket terakhir yang molor. Tag semua orang yang terlibat. Cek siapa yang actually hold the decision vs siapa yang cuma nunggu instruksi. Beda hasil? Berarti manajemen role ambiguity masih aktif ngerusak velocity lo. Update playbook-nya. Jangan tunggu QBR.