Kemarin gw liat founder startup tech di Bogor ngeluh timnya udah 22 orang tapi masih sama aja—bug numpuk, design revision nggak jelas, dan setiap krisis harus dia sendiri yang jadi pemadam kebakaran. Padahal bulan lalu dia baru habis budget 40 juta buat retreat “build stronger bonds” di Puncak.
Dinding 15–20 Orang itu Real
Banyak founder maen kata-kata, bilang “culture eats strategy for breakfast”. Beneran sih, tapi cuma berlaku sampe titik tertentu. Di angka 12–15 orang, lo bisa kenal semua nama, tau siapa yang gampang kesel, dan vibe kantor emang ngaruh banget ke output. Tapi pas headcount tembus 20, mekanisme sosial mulai macet. Chat Slack yang dulu cuma perlu @mention sekarang jadi thread 47 balasan. Bug yang tadinya tinggal tag Jira, sekarang nyebur grup WhatsApp sambil mention “@semua pls fix ini urgent”. Yang ngeselin: kita sering nyalahin “kurangnya komitmen tim”, padahal sebenernya lo cuma lupa pasang rel kereta sebelum naik Kereta Cepat.
Di SatuTim kita nemuin pola yang sama berulang kali. Tim agensi yang dulu kerja santai pake “trust issue”, tiba-tiba drop client retention rate pas mereka scale ke 25 konsultan. Bukan karena timnya jadi mager atau kurang loyal. Tapi karena referensi pengetahuan (tribal knowledge) nggak tersimpan. Orang A resign bawa konteks 3 tahun. Orang B gabung, ketemu brief kosong, default action-nya nanya ke grup. Ulangi tiga kali dalam sebulan = deadline meleset. Scaling proses bukan soal tambah headcount, tapi soal bagaimana informasi tetap mengalir walau orang bergantian keluar-masuk.
SOP Bukan Penjara, Cuma Memory Eksternal
Istilah SOP biasanya bikin tim IT atau kreatif langsung meringis. Kita dikondisikan mikir SOP itu dokumen PDF 40 halaman yang disimpan di Google Drive folder /Archive/2021_Q3. Padahal definisi asli SOP cuma satu hal: protokol baku yang mengurangi variasi keputusan saat menghadapi masalah yang sering muncul.
Ambil contoh bug tracking. Di tim yang gak punya SOP startup yang rapi, developer biasanya kasih komentar di ticket: “udah gw cek, apparently fixed”. QA review, ketemu lagi, buka ticket lama, comment lagi: “masih nge-bug di prod nih min”. Berputar. Kalau lo terapkan SOP minimal triage level (P0/P1/P2), deskripsi error wajib pakai template spesifik (steps to reproduce, expected vs actual, env screenshot), dan SLA response time, diskusi jadi terpotong. Lo nggak perlu debat apakah ini urgent atau nggak. Sistem yang nentuin. Waktu saving per ticket? Sekitar 12–15 menit. Kalikan sama 80 ticket bulanan. Itu dua hari kerja yang kembali ke tim.
Kasusnya begini: klien e-commerce gw kemarin minta revisi layout checkout tanpa clear reason. Designer langsung panik, ulang desain selama 3 hari. Gw tarik mundur, suruh isi form quick feedback: “tolong sebutin spesifik bagian mana yang gagal convert, kasih screenshot analytics, dan timeline target launch”. Client reply dalam 2 jam dengan data heatmaps. Revisi selesai dalam sehari. Itu bukan salah designer. Itu salah lo yang males mikirin gatekeeping. Approval desain pun butuh aturan main yang sama: checklist sign-off (typography, color hex, breakpoint mobile/desktop), timeline feedback maksimal 48 jam, dan versi final ditandai ‘LOCKED’. Revisi random bakal turun drastis. Gw pernah kasus client kemarin, brief diubah 4 kali karena gak ada checkpoint formal. Akibatnya timeline geser 11 hari.
Eskalasi Krisis vs Cult Leader Syndrome
Nah, ini kontroversial tapi gw must share: cari “cult leader” itu luxury expense yang cuma works di startup fase product-market fit yang stable. Tim butuh figur karismatik yang bisa memotivasi, mengambil keputusan intuitif, dan jadi father/mother figure. Problem-nya: manusia rata-rata cuma bisa fokus intens pada 3–4 project sekaligus. Pas tim tumbuh, kaskade keputusan malah jadi bottleneck.
Gw inget kasus startup fintech lokal, tim 30 orang. Founder suka menyebut diri mereka sebagai family. Hasilnya? Setiap kali ada outage payment gateway, semua mata nengok ke CEO. Tidak ada yang mau ambil risiko approve rollback tanpa izin. downtime 4 jam. Revenue loss estimasi 80 juta. Jika sebelumnya ada SOP eskalasi krisis yang jelas—who owns incident command, channel communication yang dedicated (misalnya #incident-response di SatuTim Discussion, bukan broadcast channel), dan decision tree sederhana (jika P0 > 15 menit, auto-trigger maintenance mode), waktu response turun jadi 9 menit.
Company culture vs standard operating procedure bukan lawan main. Mereka complement. Culture yang sehat bikin tim ga takut report bad news. SOP yang galak bikin bad news itu ditangani tanpa drama. Lo butuh keduanya, tapi prioritasnya beda tergantung scale. Di fase 0–15 orang, investasi pertama masuk ke hiring person who aligns dengan value. Di fase 15+, investasi masuk ke dokumentasi alur kerja.
Anti-Pattern: SOP yang Dimandatkan Sebelum Siap
Gw sering lihat founder nekat push SOP ke seluruh departemen pas headcount baru 18. Hasilnya? Compliance theater. Tim pura-pura patuh, tapi workarounds hidup subur di balik layar. Ini anti-pattern paling umum: memaksakan prosedur birokratis sebelum masalahnya benar-benar masif.
Coba perhatikan kasus platform SaaS B2B yang gw konsultasiin tahun lalu. CEO-nya maksa semua dev wajib isi timesheet detail + daily standup text log. Awalnya dikira produktif. Dua minggu kemudian, developer senior kabur. Alasannya simpel: “gw datang kerja, bukan mengisi kuisioner Excel.” Tim sisanya mulai submit log generik biar kelar tugas. Produk justru lambat rilis karena focus shifted dari coding ke administrasi.
SOP yang matang lahir dari friction, bukan dari PowerPoint. Kalau lo paksa top-down tanpa context lapangan, lo cuma bikin layer bureaucracy baru yang gak ngapa-ngapain. Solusinya? Pilot kecil-kecilan dulu. Pilih satu workflow yang paling sering bikin PR-an. Misal: handoff dari sales ke delivery, atau QA gate sebelum staging deploy. Izinkan tim yang kena dampak langsung menyusun draf SOP-nya. Biarkan mereka yang ngerasa sakit jadi arsitek solusinya. Gw personally lebih percaya SOP yang lahir dari kompromi internal daripada yang dijatuhkan dari atas. Kalau tim lo protes, artinya lo lagi ngebangun benteng, bukan jalan tol.
Async-First vs Sync Overload di Tim >20
Pas tim lo tembus angka 20, meeting lo bakal otomatis nge-gass. Status update, alignment, brainstroming—tumbukan jadwal bikin kalender jadi labirin. Banyak founder nangis karena “kalau async, apa ga lost contact?”. Benar juga kalau lo cuma pindahin rapat ke chat. Tapi async yang bener itu bedanya kayak siang sama malam.
Di SatuTim, kita coba ganti ritual status meeting jadi written check-in harian via fitur Discussions. Aturan mainnya simpel: tiap member post progress terbaru, blockir utama, dan butuh bantuan. Maksimal 3 paragraf. No video call. No screen sharing. Hasilnya? Tim engineering yang tadinya habiskan 45 menit tiap pagi buat standup, sekarang baca update sembari minum kopi. Yang butuh respons cepat langsung ping. Sisanya lanjut kerja. Efisiensi waktu meningkat 60%, dan yang lebih penting: kualitas diskusi naik. Karena ditulis, orang gak bisa asal omong. Mereka harus mikir twice sebelum submit.
Sync jangan dihapus total. Pake buat decision-making berat, creative brainstorming, atau conflict resolution. Tapi untuk informasi passing? Async menang telak. Tim 25 orang butuh bandwidth, bukan room. Kalau lo masih adakan weekly sync 2 jam cuma buat “update progress”, coba audit dulu. Biasanya 80% materi itu bisa diselesaikan lewat dokumentasi terpusat. Ganti meeting tersebut dengan async review cycle. Lo bakal nemuin bahwa tim lo ternyata lebih produktif ketika didiamkan.
Coba minggu ini: ganti ritual meeting status update jadi async check-in via SatuTim Task. Lihat berapa menit yang lo dapet balik, dan berapa banyak “tadi kan udah dibahas” yang hilang. Kalau lo sekarang punya tim di kisaran 18–25 orang, dan merasa operasi berjalan seperti roda yang terus berputar tanpa maju—coba audit satu SOP critical milik lo. Apakah benar-benar mengurangi friction, atau cuma jadi hiasan slide deck investor?
Kalau standup tim lo lebih dari 20 menit, biasanya symptom dari masalah apa? Process gap, atau cuma kebiasaan buruk yang belum dibantai?