# Menguasai Budaya Kerja Remote di Tim Global

> Sepuluh zona waktu, tujuh tahun, satu aturan: kalau tidak ditulis, berarti tidak pernah terjadi. Panduan lapangan untuk async-first.
>
> 2024-03-12 — y7.hk

## Lebih dari Sekadar Zoom Call

Kerja remote bukan sekadar memindahkan rapat kantor ke Zoom. Kerja remote sejati sangat bergantung pada komunikasi asinkron dan dokumentasi yang ketat.

Saat bekerja lintas zona waktu, asumsikan setiap pertanyaan yang kamu ajukan mungkin baru dijawab 12 jam kemudian. Batasan ini memaksa kamu menulis issue lebih baik, RFC lebih jelas, dan pull request lebih lengkap.

Saya menghabiskan tujuh tahun membangun produk dengan orang-orang yang jarang saya temui langsung — melintasi 10+ zona waktu: dari tim crypto multisig yang terbagi antara Eropa dan Asia, sampai operasi solo saya sekarang menjalankan situs ini dan beberapa bot Telegram dari Asia Tenggara. Selama itu saya tinggal di 67 negara — dengan kata lain: saya sudah menguji kerja remote dalam hampir semua kondisi, termasuk koneksi secepat dial-up di dalam van di Kirgistan.

Ini yang benar-benar berhasil.

## Async-First Adalah Disiplin, Bukan Alat

Semua orang bilang mereka "async". Lalu kamu lihat Slack mereka — dinding ping "tanya cepat" dan thread yang tak selesai. Async-first berarti sesuatu yang lebih ketat:

- **Setiap keputusan menghasilkan artefak tertulis.** Aturan di tim saya: keputusan harus dicatat dalam 24 jam — di issue tracker, RFC, atau dokumen proyek. Kalau tidak ditulis, berarti tidak terjadi.
- **Default ke channel, bukan DM.** Direct message adalah tempat konteks mati. Bertanyalah di channel publik supaya jawabannya bisa dicari orang berikutnya.
- **Ekspektasi waktu respons eksplisit.** Milik kami: hari kerja yang sama untuk blocker, 24–48 jam untuk sisanya. Tidak ada yang diharapkan online. Ini menghapus teater kecemasan titik hijau dan "cuma ngecek".

Aturan 24 jam terdengar birokratis — sampai pertama kalinya anggota baru menemukan RFC tiga bulan lalu yang menjelaskan persis mengapa keputusan dibuat. Saat itulah aturan ini balik modal, biasanya dalam bulan pertama.

## Menulis Issue yang Benar-Benar Bisa Dieksekusi

Saat rekan setim bangun 12 jam setelah kamu tidur, issue yang samar menghabiskan satu hari penuh. Jadi saya menulis setiap issue seolah penerima tidak bisa menghubungi saya:

- **Konteks dalam dua kalimat.** Apa yang rusak atau apa yang kita bangun dan kenapa sekarang.
- **Reproduksi atau referensi.** Link, potongan log, screenshot, produk kompetitor yang sudah menyelesaikannya.
- **Definisi selesai.** Bukan "buat lebih cepat" — tapi "p95 build time di bawah 90 detik di CI".
- **Non-goal eksplisit.** Baris paling diremehkan. "Jangan refactor parser di PR ini" menghemat lebih banyak siklus review daripada linter mana pun.

RFC mendapat perlakuan sama: masalah, batasan, dua atau tiga opsi dengan tradeoff nyata, rekomendasi, dan deadline komentar. Kalau tidak ada yang keberatan sampai deadline, rekomendasi berlaku. Tidak perlu meeting.

## Strategi Zona Waktu: Rangkul Estafetnya

Kebanyakan orang memperlakukan zona waktu sebagai masalah. Tim terdistribusi yang baik memperlakukannya sebagai pipeline — pekerjaan berjalan sepanjang waktu seperti lari estafet. Tapi operan tongkat hanya berhasil kalau handoff-nya tertulis.

Aturan saya:

- **Akhiri setiap blok kerja dengan catatan handoff.** Apa yang selesai, apa selanjutnya, apa yang terhambat. Tiga baris di issue. Orang yang bangun harus bisa mulai dalam lima menit.
- **Temukan jam tumpang tindih dan lindungi.** Dengan selisih 10+ jam kamu punya paling banyak satu jam siang bersama. Habiskan untuk hal yang benar-benar butuh sinkron: ketidaksepakatan, keputusan arsitektur, feedback sulit.
- **Jangan pernah menjadwalkan di luar jam yang dinyatakan seseorang tanpa bertanya.** "Cuma sekali kok" adalah cara kamu diam-diam membakar orang.

```text
Template handoff yang masih saya pakai:
Selesai:   migrasi skema deploy ke staging
Lanjut:    job backfill — siap jalan, butuh approval
Terhambat: kenaikan kuota API (tiket #4821, menunggu vendor)
```

## Dokumentasi sebagai Default

Kalau pengetahuan hanya ada di kepala seseorang, tim tidak punya pengetahuan itu — tim punya dependensi. Dokumentasi mencakup tiga lapisan:

- **Keputusan** — RFC dan thread issue. Kenapa, bukan cuma apa.
- **Proses** — runbook untuk apa pun yang dilakukan lebih dari dua kali: deploy, rollback, respon insiden, onboarding.
- **Konteks** — dokumen proyek yang menjawab "kita sedang apa dan kenapa" untuk orang yang bergabung jam 2 pagi waktu mereka.

Dokumen membusuk, jadi dokumen punya owner dan tanggal review. Runbook yang enam bulan tidak dijalankan siapa pun adalah liabilitas, bukan aset.

## Meeting Adalah Pengecualian

Waktu sinkron adalah sumber daya termahal tim terdistribusi, jadi belanjakan seperti uang. Standar meeting saya:

1. Ada keputusan yang gagal diselesaikan lewat tulisan.
2. Ada agenda yang diposting sebelumnya.
3. Siapa pun yang tidak bisa hadir tetap bisa berkontribusi — komentar dikumpulkan sebelumnya, notulen dan rekaman sesudahnya.

Sisanya adalah update async. "Weekly sync" tanpa keputusan di agenda adalah kebiasaan kalender, bukan meeting. Bunuh saja.

## Stack Tooling, Tanpa Cargo Cult

Alat tidak sepenting norma di sekitarnya, tapi ini yang bertahan dari beberapa setup terakhir saya:

- **Linear** untuk issue — cepat, beropini, memaksa jejak kertas.
- **Notion** untuk dokumen dan RFC — editor biasa saja, memori bersama luar biasa.
- **Slack** untuk chat — disiplin channel agresif dan hampir semua notifikasi mati.
- **Loom** untuk walkthrough — rekaman layar tiga menit menggantikan telepon 30 menit.
- **GitHub** — PR sebagai dokumentasi; deskripsi menjelaskan *kenapa*, bukan *apa*.

Stack ini sengaja membosankan. Mode gagalnya bukan salah pilih alat — melainkan percakapan yang sama terjadi di empat alat.

## Remote-First vs Remote-Friendly

"Remote-friendly" berarti pekerja remote adalah warga kelas dua: keputusan terjadi di kantor lalu disiarkan sesudahnya. "Remote-first" berarti setiap proses mengasumsikan tidak ada yang berbagi ruangan — hiring, review, planning, perayaan. Kalau jalur promosi mengharuskan "terlihat" di kantor, kamu tidak punya budaya remote; kamu punya kantor dengan webcam.

Tes saya: kalau besok kantor pusat terbakar, apakah ada yang berubah soal cara keputusan dibuat? Kalau ya, kalian remote-friendly.

## Masalah Kesepian

Ini bagian yang dilewati blog teknik, padahal ini alasan utama orang remote benar-benar resign. Yang berhasil untuk saya dan orang yang saya kelola:

- **Coworking, selalu.** Setiap negara tempat tinggal lama di peta saya punya coworking space "milik saya". Rutinitas adalah fitur.
- **Channel non-kerja.** Hewan peliharaan, makanan, meetup lokal. Channel kami bertahan melewati dua pivot perusahaan.
- **Waktu tatap muka per kuartal saat penting.** Satu minggu bertemu muka membeli kira-kira satu kuartal kepercayaan. Habiskan untuk sesi desain dan makan malam, bukan update status.

## Checklist yang Bertahan Tujuh Tahun

- [ ] Keputusan dicatat dalam 24 jam
- [ ] Issue ditulis untuk orang yang tidak bisa bertanya padamu
- [ ] Catatan handoff di akhir setiap blok kerja
- [ ] Meeting hanya dengan agenda + keputusan + rekaman
- [ ] Dokumen punya owner dan tanggal review
- [ ] Minimal satu channel non-kerja masih hidup
- [ ] Jam tumpang tindih dipakai untuk ketidaksepakatan, bukan status

Kerja remote bukan fasilitas atau kebijakan lokasi. Ia adalah sistem operasi — dan seperti OS lainnya, ia dinilai dari seberapa baik berjalan saat tidak ada yang memperhatikan.