Minggu lalu, satu artikel di Hacker News dapat 266 poin dan bikin saya berhenti ngunyah nasi goreng Rp 35.000 di depan laptop jam 9:15 malam. Judulnya simpel: "Every layer of review makes you 10x slower." Penulisnya Avery Pennarun — CTO Tailscale, perusahaan VPN mesh yang valuasinya sudah di atas $1.5 miliar.

Dan isinya... jujur, rasanya seperti seseorang menuliskan semua frustrasi yang pernah saya rasakan selama 8 tahun kerja di dunia digital, tapi dengan data.

Aturan 10x yang Bikin Sakit Kepala

Premisnya begini. Setiap kali kamu menambah satu lapisan persetujuan (approval) dalam proses kerja, waktu penyelesaian — bukan effort, tapi wall clock time — naik 10 kali lipat. Bukan 2x. Bukan 3x. Sepuluh kali.

Pennarun kasih contoh yang langsung ngena:

  • Coding bug fix sendiri: 30 menit
  • + code review dari rekan sebelah: 300 menit (5 jam, setengah hari)
  • + approval design doc dari tim arsitek: 50 jam (sekitar 1 minggu)
  • + masuk kalender tim lain: 500 jam (12 minggu, satu kuartal fiskal)
  • + level eksekutif: 10 kuartal (2.5 tahun)

Saya baca ini dan langsung teringat pengalaman Mas Andi — partner saya di satu proyek pemerintahan tahun lalu. Dia submit perubahan kecil di landing page UMKM. Cuma ganti wording CTA dari "Daftar Sekarang" jadi "Mulai Gratis." Perubahan itu butuh:

  1. Review dari lead developer (2 hari nunggu dia selesai sprint)
  2. Approval project manager (3 hari karena PM lagi di luar kota)
  3. Persetujuan dari pihak kementerian (2 minggu karena "harus dibahas di rapat koordinasi")
  4. Rapat koordinasinya sendiri (mundur 3 minggu karena jadwal pejabat bentrok)

Total: hampir 2 bulan untuk ganti 2 kata di tombol. Saya bukan mengada-ada. Mas Andi masih simpan thread WhatsApp-nya.

Kenapa AI Tidak Bisa Menyelesaikan Ini

Bagian paling menarik dari artikel Pennarun adalah argumennya soal AI. Semua orang bilang AI bakal bikin development 10x lebih cepat. Dan secara teknis, benar — Claude bisa coding bug fix dalam 3 menit, bukan 30 menit.

Tapi masalahnya bukan di coding-nya. Masalahnya di menunggu.

Kalau proses review-nya masih sama, AI cuma menghemat 27 menit dari siklus yang total memakan 5 jam. Atau lebih buruk: AI menghasilkan monstrosity code yang lebih besar, yang butuh review lebih lama, yang butuh design doc karena reviewer tidak percaya kode yang tidak ditulis manusia. Dan sekarang proyek yang "selesai 2 jam pakai AI" tetap memakan satu minggu.

Bu Sari — klien Wardigi yang mengelola toko online dengan 14 karyawan — pernah cerita hal serupa. Tim dev-nya pakai Cursor untuk bikin fitur baru. Fiturnya selesai dalam 4 jam — pengalaman yang mirip dengan apa yang kami dokumentasikan di 100 jam realita vibecoding. Tapi QA butuh 3 hari (karena 1 QA untuk 4 developer), approval dari Bu Sari sendiri butuh 5 hari (karena dia mau test di HP-nya tapi HPnya sedang di-service), dan deployment akhirnya jadi 2 minggu setelah coding selesai.

"Saya bayar developer biar cepat," katanya lewat voice note jam 8:30 malam. "Ternyata yang lambat itu saya sendiri."

Minimal Bu Sari sadar. Kebanyakan pemilik bisnis tidak.

Solusi: Kurangi Lapisan, Bukan Tambah Kecepatan

Pennarun menyimpulkan sesuatu yang kontra-intuitif: satu-satunya cara sustainable untuk lebih cepat adalah mengurangi jumlah review. Bukan bikin review-nya lebih cepat. Bukan pakai AI untuk skip review. Tapi benar-benar menghilangkan lapisan yang tidak perlu.

Ini bukan berarti tanpa kontrol. Ini soal memilih mana yang perlu dikontrol.

1. Klasifikasi Keputusan: Reversible vs Irreversible

Jeff Bezos mempopulerkan konsep ini di Amazon — "Type 1" (irreversible, butuh deliberasi) vs "Type 2" (reversible, langsung jalan). Ganti wording di tombol? Type 2, langsung deploy. Ganti arsitektur database? Type 1, perlu review mendalam.

Masalah kebanyakan bisnis digital Indonesia: semua keputusan diperlakukan seperti Type 1. Ganti warna header butuh approval CEO. Ubah copy email marketing butuh rapat. Tambah field di form butuh sign-off 3 departemen.

Pak Deni — head of engineering di startup fintech yang pernah konsultasi ke kami — menerapkan klasifikasi ini dan hasilnya: cycle time deploy turun dari rata-rata 11 hari jadi 2.8 hari dalam 3 bulan pertama. Bukan karena developer-nya lebih cepat coding. Karena 70% perubahan yang sebelumnya butuh 3 approval sekarang cukup 0.

2. Berikan Ownership, Bukan Approval Gate

Daripada: Developer → Lead → PM → Owner → Deploy

Coba: Developer (owns frontend changes, deploy sendiri) + Lead (hanya review arsitektur besar) + PM (hanya tracking, tidak blocking)

Ini membutuhkan trust. Dan trust membutuhkan kompetensi yang dibuktikan dari waktu ke waktu. Tapi tanpa langkah pertama — memberikan ownership — trust tidak pernah terbentuk dan bisnis selamanya terjebak di birokrasi internal.

3. Async Review dengan Deadline Otomatis

Salah satu trik yang saya pelajari dari tim engineering GitLab: jika code review tidak selesai dalam 24 jam, PR boleh di-merge dengan flag. Reviewer tetap bisa kasih feedback setelahnya, tapi proses tidak terblok.

Ini radikal? Ya. Tapi alternatifnya adalah PR yang mengantri 5 hari karena reviewer lagi sibuk sprint lain, lalu ketika akhirnya di-review, context-nya sudah basi dan butuh rewrite. Saya pernah lihat ini terjadi 4 kali di satu kuartal di klien yang sama.

4. Batasi Jumlah "Approval Required" Secara Organisasi

Buat aturan eksplisit: tidak ada proses yang boleh punya lebih dari 2 lapisan approval. Titik. Jika ada yang butuh lebih, itu tanda bahwa proses itu perlu di-redesign, bukan ditambah gatekeeper.

Di sisi tooling, Chrome DevTools yang sekarang bisa dikendalikan AI bisa membantu mempercepat debugging tanpa menambah lapisan review. Dan Spotify terkenal dengan model "squad" mereka — tim kecil yang punya autonomi penuh atas area tanggung jawabnya. Hasilnya: fitur baru bisa live dalam hitungan hari, bukan bulan. Mereka bukan tidak punya standar. Mereka punya standar yang ditegakkan di awal (hiring, onboarding, automated testing) sehingga tidak perlu dicek ulang di setiap tahap.

Konteks Indonesia: Kenapa Ini Lebih Penting di Sini

Di Silicon Valley, lapisan birokrasi menambah minggu ke timeline. Di Indonesia, lapisan birokrasi menambah bulan. Karena faktor tambahan:

  • Budaya sungkan: Bawahan enggan menagih approval ke atasan, jadi timeline molor tanpa ada yang speak up
  • Multi-tasking berlebihan: Satu orang jadi bottleneck di 5 proyek sekaligus karena "yang bisa approve cuma Pak X"
  • Meeting sebagai default: Keputusan yang bisa diselesaikan lewat chat 5 menit dijadwalkan sebagai rapat 1 jam minggu depan
  • Fear of blame: Kalau approve dan hasilnya jelek, yang kena yang approve. Jadi lebih aman tidak approve — alias diam dan tunggu

Kombinasi semua ini dengan aturan 10x Pennarun, dan kamu mengerti kenapa proyek digital di Indonesia sering molor 3-6x dari estimasi awal. Bukan karena developer-nya lambat. Karena organisasinya lambat.

Langkah Pertama yang Bisa Dilakukan Besok

Tidak perlu overhaul organisasi. Mulai dari sini:

  1. Audit approval chain: Ambil satu proyek yang sedang jalan. Hitung berapa lapisan approval dari "ide" sampai "live." Tulis di papan tulis. Lihat mana yang sebenarnya tidak perlu.
  2. Tunjuk satu orang decision maker per area: Frontend? Satu orang punya final say. Copy marketing? Satu orang. Jangan komite.
  3. Set SLA untuk setiap approval: "Review harus selesai dalam 24 jam kerja. Lewat dari itu = auto-approved." Kedengarannya menakutkan. Tapi lebih menakutkan lagi kalau proyek Rp 200 juta molor 3 bulan karena nunggu approval yang akhirnya cuma "ok, lanjut."

Seperti kata Pennarun: kamu tidak bisa mengalahkan latency dengan brute force. Satu-satunya cara adalah mengurangi jumlah hop.

Seperti yang kami buktikan di studi kasus small web untuk bisnis Indonesia, kecepatan eksekusi sering kali lebih menentukan dari kompleksitas fitur. Dan di dunia bisnis digital yang bergerak secepat ini, setiap hop yang kamu hilangkan bukan cuma menghemat waktu — tapi menghemat peluang yang hilang selama kamu menunggu.

Sumber: Avery Pennarun (CTO Tailscale), GitLab Engineering Handbook, Spotify Engineering. Butuh bantuan audit proses bisnis digital Anda? Hubungi Wardigi.