Permintaan kecil yang tidak akurat sangat membuang waktu tim
(staysaasy.com)- Permintaan yang ambigu dari manajer dan pemimpin, meski terlihat seperti pertanyaan kecil, dapat sangat mengguncang waktu tim, prioritas, dan arah eksekusi
- Ungkapan seperti “tolong cek”, “harus dibuat modern” mudah berkembang menjadi respons berlebihan seperti laporan, slide, kerja akhir pekan, atau upgrade besar-besaran
- Pihak yang meminta perlu sekaligus menyampaikan besarnya waktu yang diharapkan, dampaknya pada prioritas, apakah cukup mengecek materi yang sudah ada atau perlu pekerjaan baru, serta untuk apa hasilnya akan digunakan
- Orang yang menerima permintaan juga harus menanyakan kembali tingkat usaha yang diharapkan dan mengonfirmasi hal yang belum jelas, serta tidak boleh berasumsi bahwa pemimpin terlalu sibuk untuk menjawab
- Jika sejak awal berbicara dengan cukup spesifik sampai terasa sedikit canggung, kebingungan, pekerjaan yang salah, dan pemborosan biaya di belakang bisa sangat berkurang
Bagaimana permintaan kecil membesar menjadi pekerjaan besar
- Di dalam organisasi, permintaan yang singkat dan tampak ringan berulang kali membesar menjadi pekerjaan yang jauh lebih besar dari perkiraan
- Ada kasus ketika manajer bertanya, “bisa bantu lakukan X?”, lalu bawahan langsung menghabiskan 10 kali lebih banyak waktu daripada yang dibayangkan, dan manajer bereaksi, “saya tidak bermaksud meminta waktu sebanyak itu”
- Ucapan singkat seorang eksekutif dalam rapat seperti “bisa tolong cek ini?” bisa berujung pada 24 orang membuat 4 versi slide deck dan bekerja sampai akhir pekan
- Padahal dalam rapat itu, eksekutif tersebut mungkin hanya melihat ringkasan kalimat pertama di slide pertama lalu berkata, “tidak perlu presentasi lengkap”
- Kalimat seperti “harus modern tanpa alasan” juga bisa ditafsirkan sebagai upgrade teknologi skala besar jika maknanya tidak dikonfirmasi
- Padahal niat sebenarnya mungkin hanya memperbarui sintaks API pada versi baru selama beberapa tahun
- Sementara itu, rilis proyek penting bisa tertunda
Hal yang harus ditentukan lebih dulu oleh pihak yang meminta
- Saat meminta sesuatu, pemimpin harus menyebutkan langsung batas waktu usaha yang diharapkan
- Contoh: “jangan habiskan lebih dari 20 menit, lalu setelah 20 menit bawa saja apa yang sudah ada”
- Pemimpin juga perlu menjelaskan dampaknya terhadap prioritas
- Contoh: “ini saya perkirakan butuh sekitar 2 minggu, dan seharusnya tidak menurunkan prioritas pekerjaan penting lain secara signifikan”
- Harus juga disampaikan agar segera menghubungi jika jadwal aktual berbeda atau bentrok dengan pekerjaan lain
- Perlu dibedakan apakah cukup mengecek materi yang sudah ada, atau perlu analisis atau pembuatan baru
- Contoh: “cukup beri tahu apakah kita sudah punya sesuatu tentang topik ini. Jika belum pernah dipikirkan sebelumnya, mengetahui itu saja sudah cukup”
- Jika tujuan penggunaan hasil disampaikan, lawan bicara akan lebih mudah menyesuaikan tingkat usahanya
- Contoh: jawaban untuk dikirim ke calon pelanggan penjualan, persiapan Q&A untuk All Hands berikutnya, atau topik inti untuk rapat dewan berikutnya
Hal yang perlu dikonfirmasi oleh penerima permintaan
- Orang yang menerima permintaan harus mengajukan pertanyaan klarifikasi
- Tingkat usaha perlu dikonfirmasi, misalnya: “apakah Anda mengharapkan hasil yang sangat menyeluruh dan butuh beberapa jam, atau hanya ringkasan singkat?”
- Bertanya tidak membuat seseorang terlihat bodoh; jauh lebih berisiko jika tidak bertanya lalu mengerjakan hal yang sepenuhnya salah
- Daripada menghabiskan waktu menafsirkan email atau pesan pemimpin seperti artefak kuno, lebih baik langsung mengonfirmasikannya kepada pemimpin yang meminta
- Jika pemimpin punya waktu untuk meminta sesuatu, maka ia juga punya waktu untuk memperjelas permintaan tersebut
1 komentar
Komentar Hacker News
Yang paling tidak saya suka adalah ketika pemimpin nonteknis melewati satu-dua jenjang dan berbicara langsung kepada tenaga teknis junior, alih-alih kepada tenaga teknis senior yang berpengalaman mengajukan pertanyaan klarifikasi atau mendefinisikan jadwal dan deliverable.
Ini pola yang sering saya lihat di berbagai organisasi kampanye atau organisasi teknologi politik.
Tenaga teknis junior juga memahami rantai komando, jadi jika itu dilanggar—entah disengaja oleh atasan atau tidak—yang muncul adalah kebingungan dan kekacauan.
Orang yang mengerjakan pekerjaan fisik sebenarnya sering kali adalah engineer junior, dan untuk pertanyaan tertentu mereka bisa menjawab lebih baik daripada orang yang melihatnya dari level lebih tinggi.
Rasanya tidak perlu memainkan permainan “pesan berantai”.
Ketika koordinator proyek dari vendor yang belum berpengalaman, teknisi vendor yang terbiasa pekerjaannya dibereskan oleh koordinator, dan pelanggan yang baru pertama kali masuk ke ranah ini bertemu, bisa timbul kekacauan yang cukup besar.
Terkait pernyataan “kalau tidak bertanya lalu mengerjakan sesuatu yang benar-benar keliru, jelas akan terlihat bodoh” dan “jangan pernah berasumsi orang lain terlalu sibuk untuk menjawab pertanyaan klarifikasi saat pekerjaan berlangsung”, saya penasaran apa yang sebaiknya dilakukan dalam situasi kerja jarak jauh dan bahkan chat online pun tidak tersedia.
Kalau tatap muka, mudah untuk melontarkan banyak pertanyaan kecil, cepat, dan setengah matang, tetapi email terasa lebih formal dan mengganggu, sehingga perlu lebih banyak waktu untuk menjelaskan apa yang membingungkan dan bahkan mengantisipasi kemungkinan jawaban.
Panggilan video butuh waktu untuk dijadwalkan dan biaya tambahannya juga besar.
Dalam proyek pelanggan, setiap kali muncul pertanyaan kecil, saya menambahkannya ke Google Doc, lalu sesekali memberi tahu pelanggan untuk memeriksa dokumen itu atau meminta pelanggan berlangganan notifikasi perubahan.
Pelanggan menuliskan jawabannya langsung di dokumen, dan proses ini berulang seiring pekerjaan berjalan.
Kelebihannya: pelanggan tidak harus menjawab semuanya sekaligus, notifikasi berkurang, kedua pihak boleh menulis dengan lebih tidak formal, terasa kolaboratif, mudah menambahkan pertanyaan lanjutan di dekat bagian yang relevan, diskusi singkat atau penugasan dan pelacakan pekerjaan kecil bisa dilakukan lewat komentar dokumen, dan orang lain juga mudah membaca serta ikut berkontribusi.
Di sini saya membayangkan situasi yang memunculkan banyak pertanyaan kecil, seperti pekerjaan kontrak dengan pelanggan nonteknis yang belum terlalu dikenal.
Orang lain tidak menaruh batasan seperti itu pada email.
Kalau bukan mengirim ke CEO, tulis saja pertanyaan yang terlintas dan langsung kirim.
Tidak perlu takut mengirim email kedua segera setelahnya, seperti “Oh, saya lupa pertanyaan ini juga. Terima kasih! $QUESTION”.
Kalau melihat email para eksekutif senior di https://twitter.com/TechEmails, sebagian besar sangat informal.
Sebagian email lama antara Bill Gates dan para eksekutif Microsoft bahkan tidak jauh lebih rapi daripada pesan teks anak SMA.
Bukan berarti Anda harus memakai emoji saat mengirim ke atasannya atasannya atasannya atasan Anda, tetapi email cepat yang informal tidak akan mengakhiri karier Anda.
Saya paham bagi banyak orang rasanya lebih besar, tetapi saya tidak yakin apakah itu benar-benar lebih merepotkan bagi kedua pihak.
Jika untuk memperjelas pertanyaan dibutuhkan percakapan bolak-balik, lakukan saja.
Cara dokumen bersama juga ide yang bagus, dan ada dua kelebihan tambahan.
Tindakan menuliskan pertanyaan menjadi langkah tambahan yang membuat pertanyaannya lebih jelas, dan pertanyaan beserta jawabannya terdokumentasi untuk nanti.
Keduanya adalah keuntungan besar dibanding percakapan cepat yang nantinya harus ditulis ulang.
Alihkan beban kognitif kepada pihak lain.
Karena lebih baik mengganggu sekali daripada mengganggu berkali-kali dalam sehari.
Saat menerima issue baru, saya terlebih dahulu membacanya sekilas, merencanakan apa yang akan dikerjakan, menggali potensi masalah atau konflik di kepala sampai kadang menghasilkan daftar pertanyaan yang sangat besar, lalu membagi siapa yang kemungkinan bisa menjawab pertanyaan mana, baru setelah itu memulai percakapan online.
Di dalam perusahaan, biasanya cukup meminta panggilan video singkat 5 menit lewat messenger internal seperti Slack.
Kalau rekan kerja yang dekat, kadang saya langsung menelepon tanpa pemberitahuan.
Untuk pelanggan eksternal pun, jika sudah disepakati sebelumnya, hal serupa bisa dilakukan lewat nomor telepon asli atau panggilan video.
Misalnya, dalam rapat kickoff, tentukan frekuensi kontak yang diinginkan pelanggan, serta pertanyaan mana yang perlu dikomunikasikan segera dan mana yang cukup ditangani lewat komunikasi asinkron yang lebih lambat.
Waktu adalah indikator yang sangat buruk untuk mewakili upaya·substansi·cakupan
Misalnya, kalau melihat permintaan seperti “tolong lihat 20 menit saja, lalu bawa apa yang kamu punya setelah 20 menit”, jumlah yang bisa dicapai tiap orang dalam 20 menit sedikit berbeda
Bahkan jika perbedaan itu diabaikan, tidak ada jaminan bahwa manajer yang meminta akan mendapatkan hal yang dibutuhkannya dari upaya 20 menit itu
Di lingkungan Agile, pekerjaan penemuan·investigasi sering disebut “spike” dan diberi “timebox”, tetapi ketika ditanya “apa yang terjadi kalau hal yang diinginkan tidak ditemukan dalam waktu itu?”, biasanya tidak ada jawaban yang bagus
Dalam praktiknya, timebox akan diperpanjang sampai hal yang dibutuhkan diketahui
Jadi waktu adalah proxy metric yang buruk untuk upaya, substansi, maupun cakupan
Menurut saya contoh di bagian belakang tulisan, “apakah Anda mengharapkan sesuatu yang sangat menyeluruh yang memakan beberapa jam, atau cukup rangkuman cepat?”, lebih baik
Karena ini membicarakan cakupan pekerjaan, bukan waktu yang dibutuhkan
Jika diukur dengan waktu, tidak ada jaminan akan mendapatkan yang diinginkan dalam waktu itu, dan akhirnya waktu tambahan akan ditempelkan lagi
Jawaban untuk “kalau tidak menemukan yang diinginkan dalam waktu itu?” adalah bahwa kita mengetahui fakta bahwa jawabannya tidak bisa ditemukan dalam waktu yang diperkirakan, lalu menyesuaikan ekspektasi atas upaya yang dibutuhkan untuk pekerjaan investigasi ini
Bagi manajer, informasi seperti itulah salah satu informasi inti yang ingin diketahui
Karena itu, agar proyek tidak keluar jalur dan berakhir di tempat sampah, apa pun perlu timebox
Ini juga berlaku untuk pekerjaan individu atau pekerjaan yang dikerjakan sendiri
Karena apa pun bisa terus dipegang selamanya, jauh lebih baik memaksa adanya titik berhenti, menerima umpan balik atau merilisnya, lalu memutuskan apakah layak dilanjutkan
Mekanisme yang bekerja di sini adalah memaksa orang menentukan prioritas
Jika seseorang sangat pandai menilai prioritas, timebox mungkin tidak terlalu dibutuhkan, tetapi bahkan dalam kasus itu, tanpa timebox, godaan untuk terus bekerja sampai kualitas yang lebih tinggi daripada tingkat yang diperlukan bisa sulit ditahan
Pola kerja seperti ini berguna ketika hal yang tidak diketahui jauh lebih banyak daripada hal yang diketahui
Tujuannya adalah sedikit demi sedikit meningkatkan porsi “yang diketahui” hingga cukup untuk membuat tebakan berbasis informasi, bukan tebakan liar
Misalnya ada bug di codebase legacy, sementara sistem penggantinya hampir selesai dan dijadwalkan rilis dua bulan lagi; bagaimana bug itu harus ditangani?
Bisa saja diabaikan, atau meminta seseorang “perbaiki dengan cara apa pun”, tetapi keduanya tidak bagus
Jadi kita berkata, “investigasi bug ini, tapi jangan lebih dari satu jam, lalu beri tahu sampai mana hasilnya”
Setelah selesai, kita akan lebih memahami bentuk masalahnya
Jika ia kembali dengan “area masalahnya sudah ditemukan, tetapi perlu diselesaikan bersama orang yang sangat memahami business logic agar bisa diperbaiki”, kita bisa menempatkan resource yang tepat dan melanjutkannya menjadi perbaikan
Jika ia berkata “ini bagian kodenya dan cukup rapi, tetapi belum terlacak sepenuhnya”, kita bisa memberinya lebih banyak waktu berdasarkan keyakinan bahwa ini tidak akan menjadi pekerjaan raksasa
Sebaliknya, jika ia berkata “ada di suatu tempat dalam spaghetti aneh ini, dan saat saya menatapnya, jurang balik menatap saya sampai bulu kuduk merinding dan lukisan-lukisan di dinding meneteskan air mata darah, jadi tolong jangan kirim saya lagi”, jelas bahwa tidak layak ditelusuri lebih jauh dan kita bisa melepasnya
Saya percaya Anda pernah mengalami tidak mendapatkan yang diinginkan dalam waktu yang tersedia lalu menambahkan waktu lagi, tetapi itu tidak universal
Masalahnya ada pada memperlakukan “hal yang diinginkan” itu sendiri sebagai tujuan akhir
Karena itu tulisan tersebut juga mengatakan “jelaskan mengapa itu diperlukan”
“Pelanggan terbesar harus mengetahuinya sebelum perpanjangan kontrak” lebih layak menghabiskan uang dan waktu staf dibanding “hanya penasaran”
Di tingkat leadership, perlu disadari bahwa tidak semua keuntungan bisa dikejar, dan harus fokus secara strategis pada hal dengan efektivitas biaya terbaik
Itu bukan sekadar menempelkan orang pada pekerjaan, tetapi juga mencakup menugaskan pekerjaan yang tepat kepada orang dengan keterampilan yang tepat
Seorang CEO startup pernah meminta sesuatu, dan sepertinya permintaannya hanya singkat, sekitar satu atau dua kalimat
Akibatnya saya membuat laporan 14 halaman, menghabiskan beberapa jam, dan sebagian besar dilakukan di waktu pribadi
Saya mengirim laporan itu ke CEO, tetapi setelah itu tidak ada jawaban apa pun, dan tidak ada yang terjadi
Setelah itu saya membuat aturan baru untuk diri sendiri
Biaya sebuah permintaan harus sebanding dengan biaya untuk menyampaikan permintaan tersebut
Sekarang jika menerima permintaan yang biayanya besar, saya menunggu, menundanya, dan meminta eskalasi
Orang yang meminta harus melakukan due diligence dan mendapatkan persetujuan dari tingkat yang lebih tinggi untuk menunjukkan bahwa permintaan itu layak dibayar biayanya
Jika itu permintaan omong kosong, tidak akan terdengar lagi; jika itu permintaan bernilai, akan dikerjakan, dengan manfaat tambahan bahwa upaya itu tidak dilakukan diam-diam tanpa visibilitas yang semestinya
Pertama, jangan pernah melakukan apa pun pada permintaan pertama
Jika penting, mereka akan meminta lagi, dan saat itu baru dipikirkan
Kedua, jika saya harus lembur, pihak lain juga harus lembur
Jika pihak lain tidak mau lembur, berarti itu tidak sepenting itu
Dalam engineering, setelah berada di berbagai level mulai dari junior hingga C-level, saya mempelajari beberapa hal
Pertama, semua orang harus bertindak dengan itikad baik
Saya pernah melihat pemimpin yang secara spontan meminta sesuatu kepada bawahan langsung tanpa berpikir bahkan 5 detik, dan sebaliknya saya juga pernah melihat bawahan langsung yang baru bergerak hanya jika diberi sintaks yang persis, seperti “command line manusia”
Keduanya tidak boleh terjadi
Kedua, bagi manajer atau pemimpin, tidak ada yang namanya “permintaan sekali saja”
Permintaan apa pun akan secara implisit mendapat prioritas di atas semua pekerjaan lain
Mereka harus bergerak dalam keseluruhan sistem dan lingkungan; jika tidak, mereka melemparkan pilihan itu kepada tim
Ketiga, jika Anda pihak yang menerima permintaan, Anda harus membantu peminta memahami apa yang sebenarnya ia butuhkan
Asumsi implisit harus disingkirkan, dan di situlah naga bersembunyi
Berkomunikasilah, beri tahu, ajari, pastikan apa yang diinginkan peminta, dan pastikan kedua pihak sepakat
Hal-hal seperti ini muncul karena efisiensi—tidak ingin membuang waktu jika tidak perlu—tetapi jika peminta dan penerima saling membantu, hidup pada umumnya menjadi jauh lebih bisa ditanggung
Ada perbedaan sangat jelas antara pemimpin yang terus mendorong batas sejauh mana sesuatu bisa dilakukan dan pemimpin yang berusaha membangun hubungan beritikad baik dengan tim
Manajer yang terus-menerus membuat tuntutan tanpa pikir panjang akan secara konsisten kehilangan karyawan terbaiknya
Dari pengalaman, setelah cukup waktu berlalu, yang tersisa di bawah pemimpin seperti ini hanya para junior, karena orang-orang berpengalaman menghindari tim itu
Anggota tim “command line manusia” juga contoh bagus dari orang yang bergerak dengan itikad buruk
Saya pernah bekerja dengan orang-orang yang menuntut bahkan permintaan sangat kecil pun harus mengisi formulir atau dokumen yang mereka buat sebelum bisa dimulai, lalu baru memikirkan pekerjaan kecil itu setelah berhari-hari berdebat, mengkritik, atau mengedarkannya
Mereka mengira telah melindungi diri dari permintaan kecil dengan membuat siapa pun tidak mau repot-repot mengajukan pertanyaan secara presisi, tetapi seiring waktu reputasi sebagai orang yang sulit diajak bekerja sama akan menumpuk
Variasi lainnya adalah orang yang mengeksploitasi ambiguitas dalam setiap permintaan
Meski pada dasarnya tahu apa yang diminta, mereka “ingin memberi pelajaran” lalu menghasilkan keluaran yang secara harfiah sesuai dengan permintaan, tetapi mereka tahu bukan itu yang dibutuhkan atau diinginkan semua orang
Bukan kebetulan, sebagian besar orang yang memainkan permainan seperti ini dipecat dalam setahun terakhir
Orang bisa menoleransi rekan kerja buruk yang masih melakukan sejumlah pekerjaan untuk sementara, tetapi saat ada pengurangan tenaga kerja, mereka naik ke posisi teratas dalam daftar yang akan disingkirkan
Sebulan lalu, sebagai pemimpin, saya menyadari kegagalan yang sedang saya lakukan
Di permukaan, niat saya adalah memberi tim rasa memiliki, dan saya membanjiri mereka dengan berbagai hal yang perlu dikerjakan, tetapi sebenarnya saya sedang melemparkan stres “apa yang harus dilakukan saat ini juga” kepada tim
Ini jebakan licik yang mudah membuat kita berpikir, “Saya sedang mendelegasikan kewenangan besar kepada tim!”, padahal sebenarnya membuat tim stres dan menurunkan fokus mereka
Menurut OED, nominalisasi ini bermula dari bahasa percakapan Australia
https://www.oed.com/search/dictionary/?q=ask
Kita semua tahu bahasa adalah produk kognitif biososial yang terus berubah, sehingga tidak ada aturan yang benar-benar mutlak, tetapi ketika sudah ada sinonim bagus yang masih berfungsi dengan baik, penggunaan seperti ini terasa mengganggu, seperti mengunyah pasir
Karena saya berharap informasi itu tidak menentukan keputusan
Saya berpikir kami harus melakukan yang terbaik bagi bisnis dan pengguna akhir, bukan yang paling mudah bagi saya
Namun pihak lain memilih opsi yang lebih panjang dan sulit, dan belakangan ternyata sebenarnya ia menginginkan opsi satunya, tetapi mengira opsi itu akan lebih sulit bagi saya
Hal yang sama terjadi di dunia nyata
Saat membuat kabinet dapur baru, saya memberi istri saya dua opsi rel atas pintu; salah satunya lebih sulit, tetapi saya tidak mengatakannya karena ingin ia memilih yang ia sukai
Tentu saja istri saya memilih yang lebih sulit, dan ternyata ia mengira itu akan lebih mudah serta sebenarnya lebih menyukai opsi satunya
Jadi, Anda harus selalu memberi pihak lain semua informasi
Mengapa kita tidak bisa mengatakan bahwa pertanyaan yang dilemparkan eksekutif tidak masuk akal?
Jawabannya tentu karena tidak ingin melawan hierarki
Namun kepatuhan pada hierarki seperti ini sebenarnya tidak membantu bisnis
Ini tampak seperti nilai yang seharusnya bisa lebih mudah ditinggalkan
Pertanyaan “Apakah Anda mengharapkan sesuatu yang sangat menyeluruh, atau cukup rangkuman cepat?” itu lucu
Jika engineer jujur kepada non-engineer tentang berapa lama suatu pekerjaan akan memakan waktu, non-engineer akan terkejut dan berkata tidak mungkin
Permintaan “jangan habiskan lebih dari 20 menit, bawa apa yang Anda punya setelah 20 menit” terdengar gila
Tidak ada pekerjaan yang memakan waktu 20 menit
Lebih baik mengatakan, “jangan lihat ini dulu, minum kopi dulu, lalu kembali dan berikan estimasi kasar”
Kita mengerjakan pekerjaan kompleks dan butuh waktu untuk berpikir
Jika tidak ingin meluangkan waktu untuk berpikir, lebih baik jangan bertanya
Sebagian masalahnya adalah kita tidak ingin menyuruh atasan pergi sana, dan juga tidak ingin mengatakan bahwa kita menghabiskan 6 jam untuk sesuatu yang menurut atasan hanya 20 menit
Jadi sebagai gantinya, semua pekerjaan lain terdorong mundur
Itulah sebabnya manajemen engineering yang baik sebisa mungkin menjauhkan engineer dari orang-orang yang, tanpa sengaja, akan membajak tenaga teknis
Sinyal khas manajemen yang lemah adalah meminta laporan atau menugaskan pekerjaan yang implikasi keseluruhannya tidak mereka pahami
Sinyal khas engineering yang lemah adalah menjawab “ya” terhadap permintaan itu
Jika manajer yang lemah meminta sesuatu yang berada di luar cakupan yang bisa diperlakukan sebagai hal sepele, pekerja harus melakukan salah satu dari tiga hal berikut, bergantung pada konteks teknis dan sosial
A) Bertanya, “Bagaimana cara melakukannya?”
Ini efektif ketika manajernya adalah orang teknis tetapi melempar pekerjaan secara samar untuk menutupi ketidakmampuan teknisnya sendiri
Jika omong kosong itu dikembalikan apa adanya, mereka akan berhadapan dengan cakupan pekerjaan yang mereka minta dan realitas mekanismenya
B) Memberi tahu, “Pekerjaan itu membutuhkan sumber daya X. Ekspektasinya apa?”
Di sini X bisa berupa jam-orang yang sangat besar, uang, GP RuneScape lawas, atau apa pun
Ini cocok untuk manajer non-teknis, dan mirip dengan A, membuat mereka berhadapan dengan fakta bahwa ini adalah permintaan besar yang tidak bisa disetujui begitu saja di tempat, melainkan harus melewati prosedur normal
C) Mengatakan “tidak”
Ini tidak mungkin di semua organisasi atau semua konteks sosial, tetapi organisasi berkinerja tinggi membuatnya mungkin
Dalam lingkungan engineering berkinerja tinggi, organisasi engineering punya hak veto yang kuat terhadap pekerjaan sia-sia yang tidak masuk akal, dan hanya bisa dibatalkan oleh jajaran C-level paling atas
Mengetahui kapan dan bagaimana menggunakan hak veto ini juga merupakan keterampilan penting yang perlu dikembangkan oleh engineering
Jadi apa pun yang dikatakan tentang hal itu bisa saja berakibat mendorong diri sendiri ke arah pintu keluar
Setiap kali melihat “ask” dipakai sebagai nomina, rasa bahasa saya terasa terusik, jadi saya mencarinya dan menemukan tulisan ini
https://english.stackexchange.com/questions/4246/can-or-shou...
Ini mungkin membantu orang yang merasa terganggu dengan cara serupa
Salah satu pemborosan waktu terbesar adalah ketika permintaan tidak menyertakan konteks
Tampaknya seperti upaya menghemat waktu dengan hanya memberi tahu orang yang perlu tahu, tetapi “mengapa” dan konteks benar-benar penting untuk menghasilkan solusi yang baik
Tanpa itu, kita tidak bisa tahu apa saja yang sudah dipikirkan pihak lain
Misalnya, jika dikatakan “kita harus memblokir permintaan dari negara X”, itu tidak sulit dilakukan dengan sebagian besar layanan firewall
Namun mengapa harus dilakukan?
Jika tujuannya adalah memberi jaminan kontraktual bahwa tidak ada trafik dari negara tertentu, cara itu tidak akan berhasil, karena siapa pun bisa melewati deteksi kode negara dalam 2 menit dengan VPN
Pengguna ingin melakukan X tetapi tidak tahu caranya, lalu mengira Y akan berhasil dan meminta bantuan untuk Y, sementara orang lain bingung karena Y tampak aneh
https://xyproblem.info/
Sudah banyak orang yang gugur di bukit itu, tetapi tetap saja diimplementasikan
Sebaiknya jangan menjadi korban berikutnya
Pada akhirnya, ini sangat bergantung pada budaya perusahaan dan seberapa nyaman orang-orang dapat membantah pemimpin senior
Beban itu ada pada pemimpin senior, yang harus membuat orang-orang di bawahnya merasa nyaman untuk membantah
Berdasarkan pengalaman, pemimpin terbaik bersikap rendah hati dan mau mendengar
Namun terkadang melakukan pekerjaan sia-sia juga merupakan bagian dari pekerjaan
Jika terlalu banyak, tentu saja Anda bisa mencari pekerjaan lain, tetapi sebaiknya jangan menjadi orang yang selalu mencurigai dan mempertanyakan ulang manajemen