Cara Mengelola Tim Engineering Async-First
Panduan praktis mengelola tim engineering async-first: dari norma komunikasi hingga ritual pengambilan keputusan yang benar-benar bertahan.
By Ellis Keane · 2026-04-06
Ketika Telegraf Mengakhiri Briefing Harian
Pada tahun 1844, Samuel Morse mengirimkan pesan telegraf pertama antara Washington dan Baltimore, dan dalam satu dekade, bisnis-bisnis yang mengandalkan briefing kurir harian mulai beroperasi secara berbeda. Bukan karena mereka ingin menjadi "telegraf-first" (tidak ada yang mengatakannya), tetapi karena kendalanya telah berubah. Informasi bisa melaju lebih cepat dari seekor kuda, sehingga ritual-ritual yang dibangun di sekitar kuda perlahan-lahan menjadi tidak perlu.
Paralelnya dengan mengelola tim engineering async-first terasa langsung dan tak nyaman. Kita punya Slack, Linear, GitHub, Notion, dan sekitar tujuh alat lain yang memindahkan informasi dengan kecepatan webhook – namun sebagian besar tim masih mengatur hari mereka di sekitar ritual sinkron yang dirancang untuk era ketika orang harus berada di ruangan yang sama untuk berbagi konteks: standup harian di mana semua orang membacakan tiket Jira mereka kepada manajer yang sudah membuka papan yang sama di monitor kedua; "sinkronisasi cepat" yang berjalan 45 menit karena tiga orang berbagi layar secara berurutan sementara semua orang memeriksa ponsel mereka.
Bagi tim engineering kecil seperti kami – empat orang di tiga zona waktu – menyadari bahwa kendalanya telah berubah adalah bagian yang mudah. Membangun ulang ritualnya membutuhkan waktu lebih lama.
Seperti Apa Tim Engineering Async-First Sebenarnya
Engineering async-first berarti mode komunikasi default tim Anda adalah asinkron. Keputusan ditulis. Status terlihat tanpa harus bertanya. Konteks didokumentasikan di tempat yang bisa orang temukan sesuai jadwal mereka sendiri. Rapat masih terjadi, tetapi itu adalah pengecualian yang Anda pilih untuk diikuti, bukan standar yang harus Anda tolak.
Bukan berarti tidak ada yang pernah berbicara secara real time – itu akan absurd dan, jujur saja, sedikit menyepikan. Tinjauan desain, resolusi konflik, sesi brainstorming, dan diskusi arsitektur yang bernuansa di mana Anda perlu membaca bahasa tubuh dan menggambar di papan tulis semuanya tetap sinkron, dan itu tidak masalah. Yang membedakan adalah mode mana yang Anda pilih pertama kali ketika perlu mengomunikasikan sesuatu – dan untuk sebagian besar hal dalam tim engineering, jawabannya harus menuliskannya daripada menjadwalkan panggilan, karena komentar Linear yang ditulis dengan baik pada pukul 14.00 di Jakarta masih terbaca sempurna pada pukul 9.00 di Amsterdam keesokan paginya.
Async-first tidak berarti async-only. Artinya default Anda adalah asinkron, dan Anda memilih komunikasi sinkron secara sengaja ketika situasinya memang memerlukan itu.
Empat Pilar (yang Terdengar Jelas Sampai Anda Mencobanya)
Selama setahun terakhir, kami membangun Sugarbug sebagai tim empat orang yang tersebar di Pantai Timur AS dan Eropa. Yang benar-benar membuat tim engineering async-first kami berjalan bukan alat atau kebijakannya – melainkan kebiasaannya. Berikut empat kebiasaan yang bertahan.
1. Tulis Keputusan di Tempat Terjadinya
Hampir tidak ada yang melakukan ini secara konsisten. Sebuah keputusan dibuat dalam utas Slack. Seseorang berkata "oke, kita pakai opsi B." Dan kemudian... tinggal di sana. Dalam utas yang secara praktis tidak dapat ditemukan dalam tiga minggu.
Solusinya bukan log keputusan (yah, bukan yang utama). Solusinya adalah norma: siapa pun yang membuat keputusan akhir menulis ringkasan satu kalimat tentang apa yang diputuskan dan mengapa, di alat tempat pekerjaan dilakukan. Jika Anda memutuskan untuk mengubah format respons API, ringkasan tersebut masuk ke issue Linear atau deskripsi PR GitHub, bukan ke utas Slack atau transkrip rapat yang tidak akan dilihat siapa pun.
Kami mempelajarinya dengan cara yang mahal: sebuah PR tergeletak di tinjauan selama tiga hari karena peninjau tidak tahu bahwa kami sudah memutuskan menggunakan server-side rendering untuk halaman tersebut – keputusan itu terkubur dalam utas Slack dari minggu sebelumnya, dan tidak ada yang menuliskannya ke dalam issue. Peninjau meninggalkan enam komentar tentang trade-off client-side hydration yang sudah diselesaikan, penulisnya frustrasi, dan kami kehilangan hampir seminggu untuk percakapan yang seharusnya memakan waktu sepuluh detik jika konteks tersebut sudah terlampir pada pekerjaan sejak awal.
Setelah itu, kami berhenti mencoba mempertahankan dokumen keputusan terpisah (yang telah berjalan selama sekitar dua minggu sebelum menjadi satu lagi hal yang tidak diperbarui siapa pun) dan mulai menuliskan keputusan langsung ke dalam issue. Sepuluh detik usaha, dan keputusan itu bertahan karena terlampir pada pekerjaan, tidak mengambang di meta-dokumen yang tidak diperiksa siapa pun.
2. Buat Status Terlihat, Bukan Dilaporkan
Bagi tim kami, rapat pembaruan status adalah ritual sinkron yang paling mahal – setiap orang menceritakan apa yang dilakukan kemarin dan apa yang dilakukan hari ini sementara semua orang setengah mendengarkan sambil menunggu giliran mereka. Dalam tim async-first, status harus menjadi sesuatu yang bisa Anda lihat, bukan sesuatu yang harus seseorang ceritakan kepada Anda.
Ini berarti alat manajemen proyek Anda harus benar-benar mencerminkan realitas. Jika issue Linear berada di "Sedang Berjalan," itu karena seseorang benar-benar sedang mengerjakannya sekarang, bukan karena mereka memindahkannya ke sana pada Senin dan tidak menyentuhnya sejak itu. PR GitHub harus memiliki judul deskriptif dan issue yang tertaut. File Figma harus memiliki penamaan yang jelas yang memberi tahu Anda apa yang sedang dalam proses dibandingkan yang sudah disetujui.
Yang Membuat Status Terlihat
- PR tertaut ke issue – Siapa pun dapat melihat kode mana yang sesuai dengan tugas mana
- Penamaan branch yang jelas –
feat/user-onboarding-flow lebih informatif dari fix-stuff
- Status issue yang diperbarui – Pindahkan tiket saat pekerjaan benar-benar bergerak, bukan saat standup
- Ringkasan mingguan tertulis – Satu orang menulis digest, semua membacanya secara asinkron
Yang Membuat Status Tidak Terlihat
- Pembaruan hanya lisan – Informasi menghilang begitu rapat selesai
- Rapat status sebagai catatan resmi – Jika tidak dikatakan saat standup, itu tidak terjadi
- Papan yang sudah basi – Papan Kanban yang tidak disentuh sejak Senin
- Konteks terkunci di DM – Dua orang tahu, semua orang lain menebak
3. Tentukan Jendela Respons, Bukan Waktu Respons
Salah satu kekhawatiran yang lebih halus tentang komunikasi asinkron adalah penantian terbuka. Anda mengirim pesan, dan Anda tidak tahu apakah akan mendapat respons dalam dua puluh menit atau besok siang. Ketidakpastiannya lebih buruk dari penundaan yang sebenarnya.
Solusinya bukan menuntut respons lebih cepat (itu hanya menciptakan kembali budaya sinkron dengan langkah tambahan). Solusinya adalah menetapkan ekspektasi eksplisit tentang jendela respons untuk berbagai jenis komunikasi. Bagi tim kami, kira-kira seperti ini:
- Pesan Slack di saluran publik: Dalam 4 jam kerja
- Tinjauan PR: Dalam satu hari kerja
- Komentar issue Linear: Dalam satu hari kerja
- DM bertanda urgen: Dalam 1 jam selama jam kerja
- Yang lainnya: Dalam 2 hari kerja
Jendela spesifiknya kurang penting dari fakta bahwa itu ada dan semua orang sudah menyetujuinya. Begitu ritmenya eksplisit, kecemasan "apakah mereka sudah melihat ini?" memudar, dan orang-orang berhenti mengirim ping tindak lanjut setelah tiga puluh menit diam.
4. Lindungi Waktu Sinkron untuk yang Benar-benar Membutuhkannya
Sesuatu yang tidak kami duga: rapat yang kami pertahankan menjadi jauh lebih baik. Ketika rapat adalah pengecualian dan bukan standar, orang-orang datang dengan persiapan dan keterlibatan penuh karena mereka tahu ini adalah satu-satunya jendela untuk menyelesaikan sesuatu bersama.
Kami mempertahankan tiga jenis rapat sinkron:
- Sinkronisasi tim mingguan (maks. 30 menit) – Bukan pembaruan status, melainkan hambatan, masalah lintas tim, dan percakapan "apakah ada yang lain berpikir keputusan arsitektur ini akan bermasalah?"
- Tinjauan desain – Beberapa hal benar-benar membutuhkan umpan balik visual sinkron
- Sesi pair programming – Ketika dua orang buntu, membicarakannya bersama masih lebih cepat daripada bolak-balik asinkron
Segala sesuatu yang dulunya rapat berubah menjadi proposal tertulis, video Loom, atau utas komentar pada issue yang relevan. Kalender kami berubah dari tampak seperti permainan Tetris menjadi sesuatu yang benar-benar bisa dikelola oleh seorang manusia – yang, ternyata, adalah inti dari memiliki kalender.
stat: "3 rapat/minggu" headline: "Turun dari 12" source: "Kalender nyata tim kami setelah beralih ke async-first"
Bagian yang Tidak Ada yang Memperingatkan Anda
Bagian sulit dari async-first bukan norma komunikasi atau pengaturan alat. Melainkan penyesuaian emosional. Ketika kami menghapus standup harian, salah satu insinyur kami menyebutkan merasa "anehnya bersalah" karena memulai kerja mendalam pada pukul 10 pagi tanpa terlebih dahulu check-in dengan seseorang. Yang lain mengatakan keheningan di Slack sebelum tengah hari terasa seolah tidak ada yang bekerja, meskipun GitHub menunjukkan commit masuk setiap jam.
Inilah bagian sifat manusiawi dari masalah ini, dan tidak ada solusi tingkat sistem. Yang membantu kami adalah membicarakannya secara terbuka. Kami membahas fakta bahwa async bisa terasa menyepikan kadang-kadang, dan tidak apa-apa untuk melakukan panggilan hanya karena Anda ingin berbicara dengan manusia tentang masalah yang sedang Anda pecahkan. Normanya bukan "jangan pernah menelepon" – melainkan "jangan minta panggilan untuk hal-hal yang tidak membutuhkannya."
Beberapa orang di tim memang lebih suka interaksi sinkron yang lebih banyak, dan mengakomodasi itu bukan kegagalan filosofi async-first – ini adalah pengakuan bahwa preferensi komunikasi bersifat personal, dan kepatuhan kaku pada satu mode adalah disfungsinya sendiri.
Bagian sulitnya bukan menyiapkan alur kerja asinkron. Melainkan menjadi nyaman dengan keheningan di antara pesan, dan mempercayai bahwa rekan satu tim Anda sedang bekerja meskipun Anda tidak dapat melihat mereka melakukannya. attribution: Ellis Keane
Membuatnya Bertahan: 30 Hari Pertama
Jika Anda mengalihkan tim yang sudah ada ke model tim engineering async-first, bulan pertama adalah saat ini berakar atau diam-diam runtuh kembali menjadi "ayo kita panggilan cepat saja." Berikut yang berhasil bagi kami sebagai garis waktu kasar:
Minggu 1: Tuliskan norma komunikasi. Secara harfiah – dokumen satu halaman yang mengatakan "inilah cara kami berkomunikasi, inilah jendela respons yang diharapkan, inilah yang membenarkan rapat." Bagikan, diskusikan secara sinkron (ya, ironinya), dan dapatkan persetujuan.
Minggu 2: Batalkan atau konversi tiga rapat berulang. Pilih yang paling jelas merupakan pembaruan status tersamar dan ganti dengan format tertulis. Jangan batalkan semuanya sekaligus – orang membutuhkan jalur bertahap, bukan tebing.
Minggu 3: Audit kebersihan alat Anda. Apakah issue Linear benar-benar diperbarui? Apakah deskripsi PR berguna? Apakah keputusan ditulis di tempat pekerjaan dilakukan? Jika tidak, inilah minggunya untuk menegakkan norma tersebut. Tunjuk seseorang sebagai "champion async" yang dengan lembut mengingatkan orang-orang ketika keputusan dibuat secara lisan tetapi tidak ditulis.
Minggu 4: Retrospektif (asinkron, tentu saja). Kirimkan formulir sederhana: "Apa yang berhasil? Apa yang tidak? Apa yang Anda rindukan?" Jawabannya akan mengejutkan Anda – beberapa orang akan menyukai ketenangannya, yang lain akan kesulitan. Sesuaikan norma berdasarkan umpan balik nyata, bukan teori.
- [x] Tulis dokumen norma komunikasi
- [x] Tentukan jendela respons untuk setiap saluran
- [ ] Batalkan atau konversi 3 rapat status
- [ ] Audit kebersihan alat (issue, PR, dokumen keputusan)
- [ ] Tunjuk champion async untuk transisi
- [ ] Jalankan retrospektif asinkron setelah 30 hari
- [ ] Sesuaikan norma berdasarkan umpan balik tim
Kapan Async-First adalah Pilihan yang Salah
Async-first tidak cocok dalam beberapa situasi umum. Jika tim Anda terdiri dari tiga orang yang duduk di kantor yang sama, komunikasi sinkron mungkin sudah cukup dan beban memformalkan norma asinkron akan memecahkan masalah yang tidak Anda miliki. Demikian pula, jika tim Anda sedang dalam krisis nyata – produksi down, peluncuran penting sudah dekat, atau Anda sedang mengubah arah produk – itu adalah wilayah sinkron, dan berpura-pura sebaliknya akan menjadi dogmatis bukan praktis.
Async-first paling baik untuk tim yang tersebar di berbagai zona waktu, tim yang lebih besar dari sekitar lima orang (di mana ledakan kombinatorial koordinasi sinkron mulai menyakitkan), dan tim yang lebih suka mengirimkan kode daripada menceritakan apa yang mereka kirimkan dalam rapat tentang apa yang mereka kirimkan. Jika itu adalah Anda, investasi dalam norma asinkron terbayar dalam bulan pertama, terutama dalam jam engineering yang dipulihkan yang dulunya menghilang ke dalam kompleks industri rapat.
Telegraf tidak menghilangkan percakapan tatap muka – hanya membuat perjalanan kurir harian tidak perlu. Itulah yang dilakukan async-first untuk tim engineering: ia memensiunkan ritual yang hanya ada karena alat belum sempat menyusul, dan melindungi percakapan yang benar-benar penting.
Pertanyaan yang Sering Diajukan
Q: Bagaimana menangani tinjauan kode dalam tim engineering async-first? A: Tetapkan SLA tinjauan yang eksplisit (kami menggunakan satu hari kerja) dan buat deskripsi PR melakukan pekerjaan berat – jelaskan bukan hanya apa yang berubah tetapi mengapa, tautkan issue yang relevan, dan tandai apa pun yang harus difokuskan oleh peninjau. Pola kegagalan tinjauan asinkron terbesar adalah PR yang tergeletak selama tiga hari karena peninjau memerlukan konteks yang hanya ada di kepala seseorang. Tuliskan – atau bayar nanti.
Q: Apakah Sugarbug membantu alur kerja async-first? A: Ini membantu masalah spesifik konteks yang terfragmentasi di berbagai alat – keputusan di Slack, tugas di Linear, komentar desain di Figma. Sugarbug menghubungkan sinyal tersebut sehingga status terlihat tanpa harus ada yang menceritakannya dalam rapat. Ini bukan satu-satunya cara memecahkan masalah tersebut (Anda juga bisa sangat disiplin dalam menautkan semuanya secara manual), tetapi kami membangunnya karena kami bosan dengan versi manualnya.
Q: Apa kesalahan terbesar tim ketika beralih ke async-first? A: Memperlakukannya sebagai perubahan kebijakan alih-alih perubahan kebiasaan. Anda bisa menulis dokumen "norma komunikasi" yang indah, tetapi jika orang-orang tidak benar-benar memperbarui issue Linear mereka atau menulis keputusan ke dalam PR, Anda hanya menghapus rapat tanpa mengganti aliran informasi. Norma-norma harus menjadi memori otot, yang membutuhkan sekitar sebulan dorongan lembut yang konsisten.
Q: Bagaimana menangani masalah produksi mendesak dalam tim async-first? A: Anda tidak menanganinya secara asinkron – itulah inti dari "async-first, bukan async-only." Tentukan jalur eskalasi yang jelas: saluran Slack khusus atau PagerDuty untuk keadaan darurat nyata, dengan pemahaman bahwa yang lainnya mengikuti jendela respons normal. Perbedaan utamanya adalah antara "mendesak" (produksi down) dan "saya ingin jawaban sekarang" (yang biasanya adalah ketidaksabaran, bukan urgensi).
Q: Bisakah Sugarbug sepenuhnya menggantikan rapat standup? A: Ini dapat menggantikan bagian pengumpulan informasi – ritual "apa yang dilakukan semua orang kemarin?" – karena konteks tersebut sudah mengalir melalui GitHub, Linear, dan Slack. Yang tidak bisa digantikan adalah bagian koneksi manusia, itulah mengapa kami masih mempertahankan sinkronisasi mingguan singkat untuk percakapan yang mendapat manfaat dari berada di ruangan (virtual) yang sama.
Dapatkan intelijen sinyal langsung ke kotak masuk Anda.