Async-First Tidak Sama dengan Remote-First. Inilah Mengapa Itu Penting

Perusahaan remote-first memindahkan kantor mereka ke Zoom. Perusahaan async-first mendesain ulang cara keputusan dibuat. Keduanya bukan hal yang sama, dan kebingungan ini menjelaskan mengapa begitu banyak tim "remote-friendly" masih membawa sifat produktivitas terburuk dari kantor bersama: default sinkron, pengambilan keputusan ad hoc, dan fragmentasi kalender, hanya dengan kualitas audio yang lebih buruk dan komuter yang berakhir di meja rumah. Laporan Remote Work Tahunan GitLab telah mendokumentasikan kesenjangan ini selama bertahun-tahun, menemukan bahwa sebagian besar perusahaan yang mendeskripsikan diri sebagai "remote" tidak mendesain ulang komunikasi atau arsitektur keputusan mereka — mereka hanya memindahkan pola sinkron yang sama secara online.

Kebingungan ini penting karena dua model memiliki efek berlipat ganda yang sangat berbeda dari waktu ke waktu. Tim remote-first yang tidak pernah menjadi async-first akhirnya mencapai tembok skalabilitas: koordinasi menjadi lebih sulit seiring pertumbuhan headcount, zona waktu menciptakan gesekan daripada leverage, dan kalender dipenuhi rapat yang tidak akan ada jika keputusan dapat berjalan secara tertulis. Tim async-first berkembang secara berbeda. Konteks berjalan tanpa penulisnya. Pekerjaan terjadi di berbagai zona waktu daripada diblokir olehnya. Dan pekerjaan terfokus menjadi secara struktural mungkin dengan cara yang tidak pernah ada dalam budaya default sinkron.

Sebagian besar tim tidak pernah membuat perbedaan ini secara eksplisit. Mereka menjadi remote, mengadopsi Slack, membuat video opsional, dan menyebut diri mereka async. Mereka bukan.

Taksonomi Kesalahpahaman

Ada tiga hal yang secara konsisten dilakukan tim remote yang mereka kelirukan dengan pekerjaan async.

Menggunakan Slack daripada email. Beralih dari email ke Slack tidak mengubah model komunikasi. Ini biasanya mengintensifkan ekspektasi sinkron. Email memiliki jendela respons implisit yang diukur dalam jam; Slack memiliki jendela respons implisit yang diukur dalam menit. Ketika tim pindah ke Slack, mereka sering mendapatkan respons yang lebih cepat dan lebih sedikit email panjang, tetapi mereka juga mendapatkan budaya di mana "tidak ada" selama dua jam memicu kekhawatiran. Itu bukan async. Itu komunikasi sinkron di media yang lebih menimbulkan kecemasan.

Membuat video opsional. Menyebut rapat "async-friendly" karena kehadiran tidak wajib tidak membuatnya async. Rapat masih terjadi secara langsung. Keputusan masih dibuat secara sinkron. Orang-orang yang tidak ada melewatkan konteks dan akan membutuhkannya dirangkum kemudian, yang merupakan biaya, bukan manfaat. Membuat video opsional adalah manfaat fleksibilitas; itu bukan perubahan model operasi.

Menawarkan jam fleksibel. Membiarkan orang bekerja dari jam 7 pagi hingga jam 3 sore daripada jam 9 pagi hingga jam 5 sore adalah akomodasi jadwal. Ini menjadi async jika dan hanya jika pekerjaan itu sendiri tidak memerlukan koordinasi langsung pada waktu tertentu.

Pekerjaan async yang nyata terlihat berbeda. Ini berarti mode default untuk komunikasi adalah tertulis, permanen, dan lengkap secara kontekstual sehingga penerima dapat menindaklanjutinya tanpa percakapan tindak lanjut. Ini berarti keputusan memiliki pemilik yang terdokumentasi yang membuat mereka secara tertulis dengan input tertulis dari pemangku kepentingan, bukan dalam rapat. Ini berarti pertanyaan "bisakah kita hanya bergabung dalam panggilan selama lima menit?" diperlakukan sebagai upaya terakhir daripada jalur yang paling tidak resistensi.

Apa yang Sebenarnya Dibutuhkan Async-First

Tiga hal perlu benar sebelum async-first benar-benar memberikan keunggulan produktivitasnya.

Budaya keputusan tulisan-pertama. Setiap keputusan yang signifikan membutuhkan catatan tertulis yang dapat berdiri sendiri. Bukan hanya ringkasan setelah fakta, tetapi penalaran sebenarnya, opsi yang dipertimbangkan, dasar pemikiran pemilik, dan hasilnya. Ketika ini adalah norma, anggota tim baru dapat mengejar ketinggalan tentang proyek dengan membaca daripada menginterogasi rekan. Riset Doist tentang komunikasi async menemukan bahwa tim tulisan-pertama secara konsisten melaporkan otonomi yang lebih tinggi, lebih sedikit gangguan, dan hasil yang lebih kuat dalam tugas-tugas deep work daripada rekan mereka yang default sinkron. Anggota tim dalam zona waktu yang berbeda dapat membuat keputusan dengan konteks yang sama seperti seseorang di kantor yang sama.

Ini membutuhkan investasi. Menulis dokumen keputusan yang jelas membutuhkan waktu lebih lama daripada membuat keputusan secara verbal. Tetapi biayanya satu kali; manfaatnya bertambah setiap kali seseorang membutuhkan konteks tersebut. Panduan saluran komunikasi async menguraikan secara spesifik kapan harus menggunakan Slack, kapan harus menulis dokumen, dan kapan rapat benar-benar adalah pilihan yang tepat.

Rapat sebagai upaya terakhir. Dalam organisasi dengan default sinkron, rapat adalah cara konteks ditransmisikan. Dalam organisasi async-first, dokumentasi mentransmisikan konteks dan rapat terjadi ketika interaksi langsung menambahkan nilai spesifik yang tidak dapat diberikan oleh tulisan. Uji untuk setiap rapat berulang: jika semua peserta menulis pembaruan secara async dan membaca pembaruan satu sama lain, apakah rapat masih perlu terjadi? Jika jawaban jujurnya tidak, rapat tersebut ada karena organisasi belum membangun infrastruktur dokumentasi untuk menggantinya.

Konteks terdokumentasi yang berjalan tanpa penulisnya. Ini adalah persyaratan yang paling sulit dan paling konsekuensial. Dalam sebagian besar organisasi, konteks paling penting tentang proyek hidup di kepala pemimpin proyek. Apa yang telah dicoba, apa yang gagal, apa kendalanya, apa titik keputusan berikutnya: tidak ada yang ditulis dalam bentuk yang dapat ditemukan dan dibaca oleh seseorang yang tidak ada di ruangan.

Organisasi async-first memperlakukan konteks yang tidak terdokumentasi sebagai utang organisasi dan membayarnya secara terus-menerus, karena biaya dokumentasi hampir selalu lebih rendah dari biaya koordinasi yang dicegahnya.

Argumen Leverage Zona Waktu

Di sinilah async-first menjadi keunggulan kompetitif yang nyata daripada sekadar preferensi kenyamanan. Tim remote sinkron tidak menangkap keberagaman zona waktu; mereka dikenai penalti. Riset MIT Sloan Management Review tentang tim terdistribusi menemukan bahwa gesekan zona waktu adalah salah satu dari tiga hambatan kolaborasi teratas untuk organisasi global — dan bahwa itu diselesaikan oleh desain proses, bukan akomodasi penjadwalan.

Tim async-first menjalankan ini secara terbalik. Spread zona waktu enam jam tidak berarti koordinasi sulit; itu berarti pekerjaan terjadi dalam dua shift berurutan yang menyerahkan melalui dokumentasi. Insinyur di Lisbon menutup pekerjaan mereka pada jam 6 sore dan menulis dengan tepat di mana mereka tinggalkan, keputusan mana yang tertunda, dan apa yang perlu diketahui orang berikutnya. Insinyur di Austin mengambil dokumentasi tersebut pada jam 9 pagi dan melanjutkan dengan konteks penuh. Tidak diperlukan tumpang tindih sinkron, tidak ada rapat yang dijadwalkan di jam yang tidak nyaman, tidak ada pekerjaan yang diblokir oleh jadwal tidur seseorang.

Ini hanya berfungsi jika dokumentasinya benar-benar lengkap, yang kembali ke budaya keputusan tulisan-pertama. Ketika berhasil, tim dengan distribusi zona waktu sebenarnya mengirimkan lebih cepat daripada tim yang berlokasi bersama pada proyek yang kompleks, karena pekerjaan bergerak maju 16 jam sehari, bukan 8.

Kapan Async Gagal

Async-first memiliki mode kegagalan nyata, dan sebagian besar dari mereka berasal dari sumber yang sama: memperlakukan perubahan komunikasi sebagai cukup tanpa membangun infrastruktur pendukung.

Keputusan lambat yang menyamar sebagai proses async. Ketika otoritas keputusan tidak jelas dan proses untuk meningkatkan keputusan tidak terdokumentasi, "async" menjadi alasan untuk penundaan tanpa batas. Keputusan duduk dalam dokumen menunggu input pemangku kepentingan yang tidak ada yang tahu harus mereka berikan. Pemilik menunggu, pemangku kepentingan tidak tahu mereka adalah pemangku kepentingan, dan satu minggu berlalu. Itu bukan proses async. Itu kepemilikan yang tidak jelas yang mengenakan pakaian async. Pendekatan Indeks Drag Rapat dan pemetaan keputusan keduanya merupakan perbaikan yang relevan di sini.

Akuntabilitas rendah tanpa visibilitas. Dalam kantor sinkron, akuntabilitas sebagian dipertahankan melalui visibilitas sosial; orang dapat melihat satu sama lain bekerja. Dalam lingkungan async, lapisan visibilitas perlu dirancang secara eksplisit. Tim yang menjadi async tanpa membangun ritme check-in, log pekerjaan publik, atau dokumen status bersama sering menemukan bahwa performer rendah menghilang ke dalam ketiadaan pengawasan.

Rekan yang menghilang. Ketika "async" berarti "tidak ada yang diharapkan merespons dalam jendela waktu tertentu," tim kehilangan kemampuan untuk bergerak cepat pada keputusan yang sensitif waktu. Setiap tim async-first membutuhkan norma eksplisit tentang jendela respons: keputusan mendesak mendapat jendela respons 4 jam; keputusan rutin mendapat 24 jam; input non-mendesak mendapat 48 jam.

Daftar Periksa Kesiapan Async

Sebelum async-first memberikan keuntungan produktivitasnya, delapan kondisi organisasi perlu benar. Jujurlah tentang mana yang belum Anda miliki.

  1. Kepemilikan keputusan terdokumentasi. 20 keputusan paling umum dalam tim Anda memiliki pemilik yang jelas dan jalur eskalasi yang terdokumentasi.

  2. Konteks proyek tertulis dan dapat ditemukan. Proyek aktif memiliki dokumen yang menggambarkan keadaan saat ini, keputusan yang dibuat, pertanyaan terbuka, dan langkah berikutnya, dan dokumen tersebut dipertahankan.

  3. Norma respons eksplisit. Orang tahu apa artinya "mendesak," "rutin," dan "non-mendesak" dalam hal jendela respons yang diharapkan.

  4. Rapat memiliki bar yang jelas. Ada alasan yang diartikulasikan mengapa rapat diperlukan daripada pembaruan tertulis.

  5. Dokumentasi dipercaya. Ketika seseorang menulis keputusan dalam dokumen bersama, keputusan tersebut benar-benar ditindaklanjuti tanpa konfirmasi verbal.

  6. Karyawan baru dapat berorientasi dari dokumentasi. Anggota tim baru dapat memahami konteks dan riwayat proyek dengan membaca, bukan dengan menjadwalkan percakapan onboarding. Template rencana 30-60-90 adalah struktur yang berguna untuk membuat tonggak onboarding konkret dan terkait dengan konteks tertulis daripada serah terima verbal.

  7. Kinerja dinilai berdasarkan output. Manajer mengevaluasi hasil daripada responsivitas. Orang tidak dihukum karena tidak ada selama jam inti jika pekerjaan mereka selesai.

  8. Ada dokumen "cara kita membuat keputusan." Bukan pernyataan nilai generik. Dokumen spesifik yang menjelaskan, dengan contoh, bagaimana keputusan dibuat di berbagai tingkat dan dalam berbagai situasi.

Jika kurang dari lima dari ini benar, menjadi async-first akan underdeliver. Masalah koordinasi yang diselesaikan oleh rapat sinkron masih akan ada. Mereka hanya akan menjadi lebih lambat dan lebih samar daripada lebih berisik.

Satu Dokumen yang Dibutuhkan Setiap Tim Async-First

Sebagian besar panduan async-first merekomendasikan tooling yang baik, audit rapat, dan standar dokumentasi. Semua itu benar. Tetapi ada satu dokumen yang lebih penting dari semuanya: panduan operasi "cara kita membuat keputusan."

Dokumen ini menjawab pertanyaan yang, dalam budaya sinkron, dijawab secara langsung melalui hierarki dan tekanan sosial. Perjanjian operasi tim melayani fungsi yang terkait: itu adalah catatan tertulis tentang cara tim bekerja, tidak hanya cara tim memutuskan, dan menciptakan titik referensi bersama yang membuat norma implisit menjadi eksplisit. Keputusan apa yang dimiliki setiap orang? Tingkat keputusan apa yang memerlukan persetujuan tertulis dari beberapa pemangku kepentingan? Kapan keputusan dapat dibalik dan kapan tidak? Apa jalur eskalasi ketika seseorang tidak setuju dengan keputusan yang sudah dibuat?

Organisasi yang berhasil bertransisi ke async-first hampir selalu memiliki versi dokumen ini. Tidak perlu panjang. Perlu spesifik, jujur tentang area abu-abu, dan benar-benar dikonsultasikan ketika keputusan sedang dibuat.

Tanpanya, async-first kembali ke "tim remote yang banyak menggunakan Slack." Yang merupakan apa yang sudah dimiliki sebagian besar perusahaan remote.

Terkait: