Jangan Meminta “Ya”, Mintalah “Tidak” (2022)

• Saat mendorong pekerjaan yang berada dalam lingkup tanggung jawab sendiri di perusahaan kecil, memberi kesempatan dan tenggat untuk menolak alih-alih menunggu izin dapat mempercepat eksekusi
• Permintaan persetujuan seperti “Bolehkah saya memasang action X?” dapat membuat atasan harus meninjau masalah, menilai cara penyelesaian, hingga menyesuaikan prioritas, sehingga jawabannya bisa terlambat
• Jika mengatakan, “Saya akan memasang action X pada hari Senin. Beri tahu saya jika Anda berpikir lain,” Anda menunjukkan niat untuk menjalankan sambil tetap memberi ruang bagi atasan untuk ikut campur
• Cara ini cocok ketika pekerjaan tersebut berada dalam lingkup peran Anda, Anda menyambut masukan, tetapi cukup yakin dengan arah yang diambil untuk tetap lanjut meski tidak ada jawaban
• Dengan menyertakan tenggat yang dekat, orang yang perlu merespons kemungkinan akan bereaksi lebih cepat, dan Anda bisa terus memberi tahu pihak terkait tanpa menghentikan eksekusi

---

Memberi Kesempatan Menolak tanpa Menunggu Izin

• Bias untuk bertindak, bahkan dalam langkah yang sangat kecil, membantu memecah kondisi mandek
• Kebiasaan intinya adalah tidak meminta “ya”, melainkan meminta “tidak”
  • Dasar pengalamannya adalah perusahaan kecil dengan kurang dari 200 karyawan
  • Belum pasti apakah cara yang sama akan berhasil di perusahaan besar, organisasi nirlaba, atau organisasi pemerintah
• Ketika ingin melakukan sesuatu yang terasa berada dalam lingkup pekerjaan sendiri tetapi membutuhkan rasa aman atau ingin memberi tahu atasan, biasanya orang terlebih dahulu meminta izin
• Sebagai gantinya, berikan atasan kesempatan untuk menolak, sekaligus sertakan tenggat yang jelas agar ia bisa membuat keputusan itu

Perbedaannya lewat Contoh GitHub Action

• Contohnya adalah situasi memasang GitHub Action baru di repositori karena dinilai membantu meningkatkan kualitas perangkat lunak
  • Ini bukan sekadar keinginan mendadak, melainkan sudah melalui riset dan pengujian lokal
  • Anda mungkin juga sudah bertanya kepada mantan kolega tentang pengalaman menggunakan GitHub Action tersebut
• Cara bertanya “Bolehkah saya memasang action X? Ini membantu masalah XYZ yang kita alami” membuat atasan melakukan pekerjaan tambahan sebelum mengatakan “ya”
  • Ia harus meninjau kembali masalah XYZ
  • Ia harus menilai bagaimana X akan menyelesaikan masalah itu
  • Ia mungkin perlu mempertimbangkan prioritas dibanding pekerjaan lain, atau ingin agar penanggung jawab membagikan dulu hal-hal yang sudah diketahuinya
  • Bagi atasan yang sibuk, hal ini bisa tersisih, dan Anda mungkin perlu mengingatkan berkali-kali
• Alternatifnya adalah mengatakan, “Saya akan memasang action X untuk menyelesaikan masalah XYZ. Jika Anda berpikir lain, beri tahu saya; jika tidak, saya akan menanganinya pada hari Senin”
  • Ini menjadi sinyal bahwa penanggung jawab akan menangani masalah tersebut secara langsung
  • Atasan tetap bisa ikut campur jika mau, tetapi beban untuk wajib menjawab berkurang
  • Walau atasan lupa atau ada urusan lain, proses tidak berhenti
• Cara ini dapat diterapkan bukan hanya pada individu, tetapi juga pada kelompok yang terdiri dari beberapa orang

Tekanan Respons yang Diciptakan Tenggat

• Tenggat adalah elemen inti dari pendekatan ini
  • Jika acuannya 15 Januari, “Saya akan mengerjakan task X pada 17 Januari” dapat mendorong respons lebih cepat dibanding “Saya akan mengerjakan task X”
  • Tenggat dalam waktu dekat lebih mungkin memicu respons segera dibanding tenggat yang masih jauh seperti “Saya akan mengerjakan task X pada 15 Februari”
• Cara ini paling cocok ketika Anda membuka peluang masukan, tetapi cukup yakin dengan arah yang diambil untuk tetap mengeksekusi meski tidak ada masukan

[GN⁺]

Opini Hacker News

• Di perusahaan besar, tempat semua orang sibuk dan pekerjaan mudah terkubur, ini adalah kompetensi inti
  Setelah menjelaskan masalah lewat email, tulis “Jika tidak ada jawaban dalam [N] hari, pada [hari ke-N] saya akan melakukan XYZ”. Alih-alih mengajukan permintaan persetujuan lalu menunggu tanpa daya atau terus mengingatkan, caranya adalah meninggalkan pemberitahuan bahwa jika tidak ada tindakan, XYZ akan berjalan
  Kadang beberapa minggu kemudian ada orang yang marah kenapa dilakukan tanpa memberi tahu, tetapi setiap kali itu terjadi, kita bisa menunjukkan catatan yang mereka lewatkan

  • Ungkapan “jika tidak ada jawaban, saya akan melakukan XYZ” terdengar konfrontatif tanpa perlu
    Mengatakan “Saya bermaksud melakukan XYZ karena alasan ini, dan akan menjalankannya pada [tanggal]. Tolong beri tahu jika ada keberatan atau kekhawatiran” sudah cukup
    Cara ini memaksa kita menyampaikan dasar yang kuat sebelumnya, dan juga memungkinkan kita mendapat masukan untuk menghindari batasan atau kesalahan yang tidak kita ketahui
    Perilaku cargo cult yang meniru prinsip kepemimpinan Amazon seolah-olah itu solusi masalah juga aneh. “Bias for action” berhasil di Amazon karena orang yang bergerak sepihak lalu gagal akan dijadikan kambing hitam dan dipecat, dan orang-orang seperti itu tidak menulis blog tentang kebajikan bias for action
  • Penasaran bagaimana ini sebenarnya diungkapkan
    Apakah kira-kira seperti “Pada 1 Maret saya berencana mendefrag thingamajig. Saya menghubungi lebih dulu pihak-pihak yang pekerjaan ini mungkin bisa timbulkan masalah. Beri tahu jika ada kekhawatiran. Jika tidak ada jawaban hingga 1 Maret, thingamajig akan didefrag”
  • Ini terdengar agak seperti fantasi, atau hanya mungkin jika aturan yang dilanggar sama sekali tidak penting secara bisnis
    Kalimat “jika tidak ada jawaban dalam 5 hari, saya akan melakukan X” tidak menjadi pembelaan apa pun ketika kita melakukan sesuatu yang bisa berujung tindakan disipliner
    Tempat ini berhasil paling-paling hanya sebatas melanggar keputusan desain internal yang tidak terkait bisnis
  • Bagian “kadang beberapa minggu kemudian ada orang yang marah karena XYZ dilakukan tanpa memberi tahu” terasa mencurigakan
    Katanya ini “selalu dilakukan” sambil menuliskan frasa ajaib seperti template; saya ragu apakah ini benar-benar pengalaman pribadi, atau proyeksi tentang cara kerja yang diinginkan seperti di artikel utama
    Membayangkan adegan menunjukkan catatan kepada rekan kerja yang marah lalu menang membuat detektor omong kosong saya naik sampai merah
  • Bagus juga karena punya efek mencatat secara tertulis siapa yang menghambat atau menolak proses berjalan

• Saya menyebut ini “jangan bertanya, beri tahu”, dan ini sangat berguna di dalam maupun di luar perusahaan
  Ini adalah keterampilan komunikasi dasar, dan membuat hasil menjadi ringkas serta tegas
  Saya juga sering berdialog seperti ini dengan istri saya. Ia cenderung mengirim pertanyaan terbuka ke grup berisi 8 orang seperti “kalian sampai jam berapa?”. Karena kami tahu kami akan datang satu jam lebih awal karena jadwal penitipan anak, saya menyarankan agar ia cukup memberi tahu, “Kami akan tiba jam segini, dan yang mau minum duluan bisa ketemu di bar”
  Tidak perlu meminta balasan, semua orang datang lebih awal, dan semuanya berjalan baik dengan komunikasi minimal
  Ini juga sedikit terkait dengan “lebih baik minta maaf daripada minta izin”, tetapi tempat kolaborasi banyak orang seperti repositori GitHub bukan tempat yang baik untuk begitu saja melempar perubahan besar yang memengaruhi orang lain

  • Saya juga melakukan ini. Ini bukan sekadar komunikasi yang lebih baik, melainkan juga cara hidup yang lebih baik
    Bukan berada dalam kondisi hanya bisa menikmati sesuatu jika orang lain mengoordinasikannya, melainkan memulai hal yang ingin saya lakukan dan memberi tahu orang lain bahwa mereka bisa ikut bergabung

• Saat rekan kerja bertanya bagaimana caranya mendapat persetujuan atas usulan mereka, saya memberi saran serupa: “Buatlah agar pihak lain semudah mungkin mengatakan ya”
  Jangan melempar 14 paragraf kepada seseorang lalu berharap mereka langsung mengejar tingkat pemahaman masalah yang sudah kita dalami selama berjam-jam
  Jika yakin dengan pendekatannya, jelaskan secara ringkas mengapa masalah dan solusinya tepat, lalu lampirkan tautan dokumen bagi yang ingin membaca lebih dalam. Sebaiknya persetujuan dari anggota tim atau penanggung jawab produk sudah diperoleh terlebih dahulu
  Contoh: “Kami berencana menyelesaikan X dengan Y. Seluruh tim sudah setuju. Dokumen proposal lengkap ada di [link]. Jika tidak ada masukan tambahan yang perlu dibahas, kami akan mulai pada hari Selasa”
  Manajer tidak punya waktu melihat semua detail, dan jika pekerjaan sudah dirapikan termasuk dukungan dari tim yang lebih luas, mereka tinggal menyetujui, sehingga mereka akan berterima kasih

  • Jika manajer bekerja seperti ini, kontes popularitas akan dimulai. Manajer seperti itu tidak efisien atau tidak berguna
  • “Jika yakin” adalah kuncinya. Saya menentukan keyakinan bukan dengan narsisme, melainkan dengan statistik objektif dan ketidakpastian
    Jika peluang suksesnya 10% tetapi ada alasan untuk mencoba, saya akan mengatakannya begitu, bukan mengemasnya sebagai presentasi omong kosong seolah saya yakin akan berhasil. Jika peluang suksesnya 80%, saya juga tidak menyembunyikan 20% sisanya; jika saya mengatakan 98%, itu berarti memang kira-kira sedekat itu
    Tugas manajer adalah menangani statistik semacam ini dan melakukan hedging terhadap risiko. Hedge fund melakukannya dengan uang, manajer melakukannya dengan orang dan sumber daya
    Sayangnya, manajer korporat tipikal lebih menyukai orang yang mengatakan 100% akan berhasil padahal kenyataannya gagal 50% dari waktu

• Saya suka ungkapan serupa, radiating intent
  Ini adalah cara memberi tahu secara luas apa yang ingin dilakukan dan kapan, memberi ruang bagi pemangku kepentingan untuk menentang secara eksplisit, tetapi tidak mengejar konsensus, penyelarasan, atau persetujuan satu per satu
  Ini berhasil dalam sebagian situasi, dan umumnya kita perlu lebih dulu mendapatkan kepercayaan dasar
  https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...

  • Empat alasan untuk melakukan “radiating intent” masuk akal. Ini bekerja baik di organisasi dengan tingkat kepercayaan menengah ke atas
    Saya juga menyukai nuansa tambahan dari Eliz Ayer: “Agar adil, dengan radiating intent mungkin pekerjaan yang diselesaikan justru lebih sedikit, karena ini memberi jalur bagi orang yang menghambat atau ikut campur untuk masuk. Selain itu, saran seperti ini sangat bergantung pada situasi dan organisasi, jadi tidak selalu tepat”

• Cara berkomunikasi seperti ini tampaknya akan membuat orang lain langsung melihat kita sebagai sosok berisiko
  Di permukaan terlihat seperti menghemat waktu mereka, tetapi sebenarnya ini memberi tahu manajer bahwa jika ia tidak selalu memantau apa yang dilakukan karyawan itu, karyawan tersebut bisa melakukan tindakan yang tidak diinginkan
  Artikel ini memperlakukannya seperti notifikasi, tetapi sebaik apa pun niat dan pemahamannya, notifikasi mudah tenggelam dalam derau sinyal, dan tidak adanya jawaban bukan berarti setuju. Bisa saja berarti pesannya tidak diterima
  Kalau karyawan dan manajer sudah membahas masalahnya dan kini sedang menjalankan solusinya, ini mungkin baik-baik saja. Namun ketika pertama kali mengangkat masalah yang bahkan belum dipertimbangkan pihak lain, ini adalah yang terburuk. Egois dan kebalikan total dari kerja tim
  Rasanya juga seperti meniru engineer 10x Rockstar legendaris yang melakukan hal seperti ini. Engineer itu selalu bekerja dengan baik, tahu apa yang harus dilakukan, dan punya saling pengertian serta rasa hormat dengan manajemen sehingga ada ruang untuk diberi pengelolaan mandiri. Sepertinya seseorang melihat itu lalu mengira hal yang sama juga berlaku untuk dirinya, tanpa memahami mengapa orang itu mendapat perlakuan seperti itu dan bagaimana ia sendiri harus mendapatkannya

  • Pada akhirnya semuanya bergantung pada hubungan
    Jika Anda melakukan ini tiga kali berturut-turut lalu mendapat jawaban “tolong berhenti”, berarti ada yang tidak beres. Jika tiga kali berturut-turut mendapat pujian, lanjutkan saja
    Orang yang benar-benar berbahaya adalah orang yang, meski sudah diberi tahu tidak boleh, tetap menjalankan sebagian besar hal dengan berbagai cara, lalu belakangan mencari “ya”. Pada pekerjaan berikutnya pun sama, dan tidak menanggapi umpan balik
    Jadi intinya lebih pada hubungan kerja daripada metode itu sendiri. Di lingkungan dengan kepercayaan tinggi dan semua orang sibuk, ini layak dicoba
  • Kalau orang yang tidak saya kenal melakukan ini kepada saya, rasanya akan terkesan arogan dan menyebalkan
    Jika kami pernah bekerja bersama, ada kepercayaan, dan saya tahu ia melakukannya karena menghormati waktu saya, ceritanya sama sekali berbeda

• Saat pertama kali sesuatu rusak karena ini, ia menjadi resep bencana
  Mendapat “ya” atau “tidak” berarti atasan tahu. Ketika sesuatu terjadi dan muncul pertanyaan “siapa yang menyetujui?”, jawaban jujurnya adalah tidak ada yang menyetujui

  • Ini sangat bergantung pada budaya organisasi dan efektivitas manajemen
    Jika di dalam organisasi tidak ada seorang pun yang bisa bertindak seperti ini, itu pertanda tim kepemimpinan gagal mendelegasikan
  • Ini tampaknya bukan untuk dipakai kepada atasan, melainkan lebih dekat ke cara yang dipakai kepada orang-orang dari departemen rekan kerja yang perlu terlibat dalam pekerjaan
    Misalnya ketika X dari tim Y menolak suatu hal
    Jika atasan 1) mengatakan sesuatu harus dilakukan dan 2) tidak menyetujui rencana apa pun, ya jangan lakukan saja. Dalam kasus itu, tanggung jawab untuk menginstruksikan agar pekerjaan bisa berjalan ada pada atasan
  • Jika semua hal yang dilakukan bawahan harus disetujui atasan, itu bukan atasan melainkan micromanager, dan keduanya sama-sama keliru
  • Setidaknya dalam perangkat lunak, seharusnya tidak ada orang yang bisa melakukan apa pun sendirian
    Mengatakan “saya akan melakukan ini” tidak masalah, tetapi tidak boleh masuk ke production tanpa prosedur seperti review dan automated test
    Tentu saja itu menciptakan bottleneck. Jika merge request sudah diajukan tetapi tidak ada yang meninjaunya tepat waktu, tidak ada yang terjadi. Dalam situasi seperti ini, kesepakatan untuk memeriksa dan meninjau dalam jangka waktu tertentu harus ditetapkan di level team lead
  • Bertanggung jawab atas sesuatu juga mencakup merusakkan dan memperbaikinya

• Pendekatan seperti ini tampaknya hanya berhasil dengan atasan yang terbiasa dengan perusahaan Amerika atau budaya bisnis ala Amerika
  Jika atasan tidak menyukainya, ini bisa sangat berbalik merugikan. Saat evaluasi kinerja, atasan mudah memberi cap pembangkangan, dan Anda seperti menyerahkan sendiri bukti yang dibutuhkan di atas nampan
  Kadang-kadang bahkan di Amerika pun meminta izin memang pilihan terbaik, apalagi jika menyangkut sumber daya

  • Pembangkangan adalah istilah yang lebih cocok untuk militer. Gagasan bahwa orang dewasa bisa “membangkang” itu sendiri terdengar konyol
  • Cara kerja non-Amerika juga sangat beragam
    Misalnya dalam budaya Skandinavia, manajemen sering kali cukup lepas tangan, dan karyawan diharapkan mengambil banyak keputusan secara mandiri atau melalui diskusi bersama
  • Hampir tidak ada atasan yang pernah saya alami yang akan membenci cara ini. Tentu dengan asumsi hal yang hendak dilakukan tidak bodoh
    Namun semua atasan itu sangat terbenam dalam budaya Amerika
  • Jika pengambilan keputusan mandiri dianggap sebagai pembangkangan, saya penasaran bagaimana manajer seperti itu mendelegasikan, dan bagaimana pekerjaan berjalan di masyarakat secara umum
    Bahkan pengambilan keputusan militer yang efektif pun sangat bergantung pada kemampuan unit di lapangan untuk beradaptasi tanpa harus menelepon markas setiap saat
  • Di perusahaan non-Amerika tempat atasan benar-benar punya kehidupan sehingga tidak bekerja di akhir pekan, atau bahkan mengambil libur beberapa hari atau beberapa minggu, cara ini mungkin tidak berhasil

• Ini disebut membuat default yang masuk akal
  Alih-alih meminta orang membuat keputusan untuk setiap detail, caranya adalah menetapkan sekumpulan default yang masuk akal yang menunjukkan bahwa Anda memahami situasinya, lalu memberi tahu bahwa Anda akan melanjutkan sesuai itu
  Dengan begitu kepercayaan terbangun, dan ketika benar-benar membutuhkan perhatian, orang akan lebih memperhatikannya. Karena mereka tahu Anda tidak membuang-buang waktu mereka sehari-hari

  • Saya suka framing “default”. Itu menyisakan ruang untuk usulan dan perubahan

• Cara komunikasi ini bagus, tetapi bagian tenggat waktu kurang saya sukai
  Jika bawahan melakukan sesuatu yang mungkin saja saya veto, cukup beri tahu saya. Karena saya mungkin tahu lebih banyak konteks dan bisa menilai bahwa pekerjaan itu buang-buang waktu atau bukan prioritas
  Memberi tenggat waktu kepada manajer terasa aneh, dan terdengar seperti ancaman yang halus tapi menjengkelkan
  Untuk hal kecil seperti GitHub Action, saya ingin berpikir bahwa anggota tim diberi otonomi yang cukup untuk memutuskan sendiri

  • Meminta “tidak” seperti “beri tahu jika ini tidak boleh dilanjutkan” benar-benar bagus
    Namun jika ditambah “saya akan melakukannya pada tanggal ini, kecuali ada arahan lain”, rasanya agak agresif
    Dengan hanya menyebutkan waktu pengerjaan dan membiarkannya seperti “sepertinya akan saya selesaikan sekitar waktu itu”, Anda tetap memberi ruang bahwa mungkin lebih baik tidak melanjutkan
    Meski begitu, sejak lama tujuannya memang menjadi lebih tegas. Hanya meringkuk tidak akan banyak membantu
  • Kalau tidak mengatakan kapan akan mengerjakannya, bagaimana pihak lain tahu apakah ia sudah mengatakan tidak atau belum?
    Anda mungkin berpikir satu hari sudah cukup lalu melanjutkan, tetapi jika pihak lain menjawab dua hari kemudian, Anda sudah berada dalam posisi melakukan pekerjaan yang bertentangan dengan instruksi
    Menambahkan tanggal bisa menghindari itu: “Saya akan memigrasikan build system pada Rabu (tanggal 26). Beri tahu jika ada kekhawatiran”
  • Artikel ini merugikan dirinya sendiri dengan menyebutnya tenggat waktu
    Saya baru paham setelah membaca contohnya; sebenarnya itu lebih mirip tanggal rencana pengerjaan, bukan tenggat waktu
  • Tenggat waktu untuk tindakan sendiri bisa juga menjadi bentuk sopan santun
    Karena memberi tahu pihak lain tentang periode pemberitahuan, dan membantu orang yang membaca email lama belakangan menilai apakah isinya masih relevan
  • Memberi tenggat waktu pada sesuatu yang masih sekadar ide itu aneh dan agresif
    Biasanya tenggat waktu dipakai dengan makna “sudah diputuskan untuk dilakukan dan persetujuan atau kesepakatan juga sudah didapat, jadi sekarang hanya memberi tahu pelaksanaannya”

• Salah satu trik dari “saya akan melakukan ini kecuali diberi tahu sebaliknya” adalah mengurangi biaya komunikasi dengan tidak mengungkapkannya seperti pertanyaan
  Dengan begitu, penerima tidak perlu menulis balasan, dan saya maupun orang-orang yang di-CC juga tidak perlu membaca email tambahan
  Dalam arti itu, fitur seperti reaksi emoji di GitHub atau Google Docs, yang memungkinkan orang menekan jempol sebagai tanda sudah membaca dan setuju, adalah hal yang bagus. Anehnya, di sebagian kalangan HN fitur ini tidak populer, tetapi ini adalah cara komunikasi ringan yang membuat kita tidak perlu melewati prosedur menulis komentar seperti “Bagus, masuk akal!” setiap kali. Mirip dengan upvote