Tiga minggu lalu, gw kehilangan dua hari penuh cuma buat nyari siapa final approver perubahan compliance module di produk kami. Padahal tim udah 48 orang, semua kerja remote-first, dan kita pikir sistem operasinya udah rapi. Beneran loh. Satu keputusan sederhana butuh 4 hari lari-larian chat di Slack karena gak jelas siapa R, siapa A, dan dimana brief asli-nya disimpan.
Dari 10 Jadi 50: Benci Sama Kata “Kita Ngetes Dulu"
Banyak founder ngira scaling dari 10 ke 50 itu cuma soal hiring manager baru atau beli Jira Enterprise. Nyatanya, musuh utamanya bukan budget atau tooling. Itu masalah informasi yang mulai terfragmentasi pas lo masuk fase regional expansion. Di basis operasi kami di Makassar, kita awalnya cuman ada 8 dev, 2 PM, sama 1 QA. Semua duduk bareng, segala keputusan turun langsung via grup WhatsApp kantor. Masuk ke angka 20, grup WA mulai jadi malfungsi total. Notifikasi 300+ pesan/hari bikin developer context-switching terus-menerus. Dan di situ lah awal dari decision latency yang naik gila-gilaan.
Pas kita ambil keputusan resmi pindah ke struktur organisasi remote, banyak yang mikir “terus tinggal set tools aja”. Keliru besar. Tools cuma amplifier. Kalau proses informasinya berantakan, remote malah bikin gap makin lebar. Kita pernah coba adopsi Asana dulu, hasilnya task nyebar tapi status update-nya masih nunggu sync manual tiap Jumat. Tim compliance sering ketinggalan update feature terbaru karena gak dapet notification otomatis dari tim product. Result? Mereka review dikit lebih lambat, deadline release molor. Kita perlu reset fundamental: bagaimana info mengalir tanpa harus selalu bertemu secara sinkron.
Arsitektur Dokumentasi Hidup (Bukan Wiki Mati)
Salah satu kesalahan klasik saat manajemen operasional startup skala menengah adalah menganggap Confluence atau Notion sebagai tempat penyimpanan akhir. Tempat itu harusnya jadi sumber kebenaran tunggal (single source of truth), tapi kenyataannya sering jadi kuburan dokumen yang gak di-review ulang sejak Q2 tahun lalu.
Kita ubah strateginya jadi living documentation architecture. Gak usah pake istilah akademis, intinya simpel: setiap requirement wajib punya halaman induk yang link-nya disebarin, bukan di-cp-paste di channel general. Contoh konkretnya: fitur kalkulasi bunga dinamis. Gak cukup cuma nulis user story di Jira. Kita bikin satu halaman di SatuTim Brief yang isinya: context bisnis, spec teknis, mockup terakhir, status legal sign-off, dan log perubahan versi. Setiap kali ada update, edit di sana. Chat di channel hanya numpang lewat. Hasilnya? Developer gak perlu nanya “yang mana ya yang terbaru?” lagi. Designer gak perlu download attachment 3x. Dan waktu hilang karena misalign berkurang drastis.
Yang ngeselin sebelumnya, hampir 40% waktu sprint planning habis buat klarifikasi konteks dasar. Setelah arsitektur docs ini jalan 3 bulan, rata-rata preparation time per feature turun jadi 2 jam. Angka ini keliatan kecil, tapi kalau dikali 15 fitur per quarter di tim 40-an orang, artinya kita nyelamatin ratusan jam kerja produktif yang tadinya bakar di rapat.
RACI Matrix yang Gak Cuma Hiasan Spreadsheet
Balik ke kasus gw tadi di pembukaan: cari final approver butuh 4 hari. Itu karena scaling tim remote biasanya bikin hierarki approval jadi kabur. Siapa yang tanda tangan? Tech lead? Product VP? Compliance Head? Atau tiga-dua-duanya sekaligus?
Kita implementasikan RACI matrix, tapi dengan aturan main yang keras. Gak usah template Excel standar yang akhirnya jadi PR-an team ops buat diisi doang. Kita bikin versi berbasis workflow-triggered. Setiap project card otomatis attach RACI tag berdasarkan kategori. Kalau feature baru, R=PM, A=CTO, C=Dev Lead, I=QA & Compliance. Kalau change request minor, R=Senior Dev, A=Tech Lead, C=Product, I=SRE. Simpel. Transparan. Gada ruang buat interpretasi.
Yang penting banget: kolom "Accountable" cuma boleh satu orang per item. Jangan pernah bagi 2 accountable. Itu resep disaster. Dulu kita sempat jatuh di lubang itu pas ekspansi ke cabang Surabaya. Dua PM masing-masing merasa bertanggung jawab atas approval UI kit, hasilnya desain dibatalkan dua kali karena masing-masing minta revisi beda arah. Pas kita tegasin cuma satu A, timeline balik normal dalam 2 sprint. RACI di sini bukan alat birokrasi, tapi pemutus kebuntuan. Dan kalau mau jujur, ini yang paling susah dieksekusi karena founder kadang suka ngeset “aku yang approve akhir” di semuanya. Berani delegasi authority itu mahal harganya, tapi jauh lebih cheap daripada firefighting tiap Sabtu pagi.
KPI yang Sebenarnya Penting: Decision Latency & Dependency Count
Kebanyakan tim ukur produktivitas dari velocity Jira atau jumlah ticket closed. Itu metrik vanity kalau lo lagi ngerjain fintech indonesia yang butuh akurasi tinggi dan lintas departemen. Coba ganti fokus ke dua metric ini:
Pertama, decision latency. Berapa lama dari “request diajukan” sampai “final go/no-go”? Kita taruh timer di setiap card yang butuh approval external. Target maksimal 24 jam untuk standard request, 4 jam untuk urgent patch. Kalau melampaui batas, otomatis flagged sebagai blocked. Di praktik nyata, metrik ini memaksa stakeholder buat responsif. Gak bisa nunda-nunda lagi sambil bilang “maaf baru baca notif”.
Kedua, cross-team dependency count. Seberapa sering tim lo nunggu tim lain sebelum bisa move forward? Setiap blokade antar tim = friction cost. Kita track ini via label blocked-by-[team] di task tracker. Tiap standup mingguan, kita liat chart dependency. Kalau jumlah dependency count naik terus, artinya ada masalah struktur, bukan masalah effort individu. Solusinya seringkali de-silo-kan workflow atau kasih dedicated liaison role buat bridging gap tersebut.
Data kuartal lalu menunjukkan dependency count tim engineering kita turun 65% setelah RACI dan living docs aktif. Decision latency berkisar di 18 jam (dari baseline 3.5 hari). Angka ini yang bener-bener ngasih sinyal sehat ke investor dan internal stakeholder. Deployment frequency naik, rollback rate turun. Karena nobody lagi harus menebak siapa yang harus dimintai konfirmasi.
Realita Lapangan: Kenapa Teori Sering Gagal Eksekusi
Ngomong-ngomong soal eksekusi, gw bakal jujur. Implementasi ini gak mulus. Awal Q3, banyak senior staff yang resisten karena merasa dikontrol berlebihan. “Gw mah kerjain aja, nanti juga selesai.” Mereka gak paham bahwa di skala 50+, “kerjain aja” justru bikin silo information. Perlawanan alami. Solusinya? Gw gak paksa lewat memo HR. Gw tunjuk 3 influencer informal di tiap departemen (biasanya senior engineer atau veteran designer), ajak mereka co-build sistem ini. Mereka yang pertama adaptasi, kemudian naturalize ke temen-temennya. Budaya berubah dari atas bawah, atau dari pinggir ke tengah. Pinggir ke tengah jauh lebih sustainable.
Plus, kita sempetin sesi ops retro bulanan khusus bahas breakdown komunikasi. Bukan retrospektif product biasa, tapi murni bedah workflow. Mana yang bikin mager nulis doc? Apakah formatnya terlalu ribet? Apakah approval cascade-nya berbelit? Feedback dikumpul, dipivot. Iterasi cepat. Startup yang survive itu yang berani nyesuaian pola operasi sesuai beban aktual, bukan gaya perusahaan korporat yang kaku dan lambat.
Coba minggu ini: audit satu project yang sering macet di approval. Cek berapa lama decision latency-nya, tandai siapa sebenarnya Accountable-nya, dan pastikan semua context tersedia di satu halaman publik. Kalau lo nemuin celah yang bikin tim lo rugi waktu, itu titik start terbaik buat struktur organisasi remote yang sehat.
Kalau standup atau sync routine tim lo masih sering muter-muter tanpa keputusan jelas, biasanya symptom dari masalah apa?