Apa yang Anda lakukan ketika diminta bergerak lebih cepat tetapi tidak diberi tambahan orang?

Question

Accepted Answer

Menambah orang pun jarang membuat tim lebih cepat dalam jangka pendek, jadi pertanyaan sebenarnya adalah: ke mana *waktu tim sebenarnya pergi*, dan apa yang bisa saya ubah soal itu? Saya memperlakukan "bergerak lebih cepat" sebagai dorongan untuk menemukan leverage, bukan tuntutan untuk bekerja lebih lama.

## Di mana saya mencari kecepatan

- **Pangkas cakupan, bukan kualitas.** Cara tercepat untuk merilis lebih cepat adalah membangun lebih sedikit. Saya bekerja dengan PM untuk memprioritaskan dengan tegas dan menemukan versi terkecil yang memberikan nilai. Kebanyakan fitur adalah 80% nilai dalam 20% pekerjaan.
- **Hilangkan friksi dan waktu tunggu.** Sering kali bottleneck-nya bukan kecepatan koding — melainkan CI yang lambat, test yang flaky, deploy yang menyakitkan, review yang lambat, atau menunggu persetujuan. Memperbaiki build 30 menit atau perputaran review dua hari memberi velocity nyata secara cuma-cuma.
- **Kurangi work-in-progress.** Tim yang menjuggle sepuluh hal tidak menyelesaikan apa pun. Fokus pada lebih sedikit item paralel merilis sesuatu lebih cepat.
- **Otomatiskan yang repetitif.** Testing manual, rilis manual, setup environment manual — investasi sekali, hemat selamanya.
- **Bayar debt yang secara aktif memperlambat Anda.** Bukan semuanya; cukup bagian yang membuat tim tersandung setiap hari.
- **Lindungi waktu fokus.** Lebih sedikit rapat dan interupsi bisa jadi kemenangan lebih besar daripada perkakas apa pun.

## Bagaimana saya merespons permintaannya

Saya tidak sekadar berkata "mustahil" atau diam-diam menerimanya. Saya merespons dengan sebuah **trade-off**: "Kita bisa mencapai tanggal itu jika kita memangkas fitur A dan B, atau menerima risiko lebih tinggi pada testing. Ini yang saya rekomendasikan." Ini menjadikan kecepatan sebuah keputusan bersama yang sadar alih-alih taruhan kualitas yang senyap.

## Jebakan yang harus dihindari

- **Mewajibkan lembur.** Itu membeli sprint singkat dan membayarnya kembali dengan burnout, bug, dan atrisi.
- **Melewati test dan review diam-diam.** Kecepatan hari ini, outage bulan depan.
- **Mengatakan ya pada tanggalnya tanpa mengubah apa pun** — itu sekadar berharap, dan harapan menggagalkan tenggat.

## Mengapa ini penting

Kecepatan yang berkelanjutan datang dari menghilangkan pemborosan, bukan dari memeras orang. Seorang Tech Lead yang merespons tekanan dengan trade-off yang jelas dan perbaikan proses membangun tim yang benar-benar cepat dan tahan lama — alih-alih tim yang berlari kencang, ambruk, dan kehilangan engineer terbaiknya.