1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Saat “bergerak cepat” menjadi lebih dari sekadar kebutuhan praktis dan berubah menjadi bukti keseriusan dan ambisi, peninjauan yang hati-hati diperlakukan sebagai sikap yang menghambat momentum
  • Kecepatan yang sesungguhnya muncul ketika pekerjaan, batasan, dan ketergantungan dipahami lalu keputusan diambil dengan jelas sebelum dieksekusi, tetapi banyak organisasi membungkus kebutuhan yang kabur dan keputusan yang belum selesai sebagai kecepatan
  • Ketika tahap pemahaman dipercepat, pengerjaan ulang dicatat sebagai “iterasi”, kekacauan sebagai “penyelarasan”, dan kegagalan yang sebenarnya bisa dicegah sebagai “pembelajaran”, sementara sistem yang tidak dipercaya dan prosedur akal-akalan mengeras menjadi struktur inti bisnis
  • Urgensi adalah keadaan ketika pekerjaan penting benar-benar memiliki batas waktu, sedangkan ketergesa-gesaan adalah keadaan ketika orang mencari kelegaan emosional dari bertindak tanpa menanggung beban untuk memastikan kejelasan
  • Untuk bekerja dengan benar, kita perlu memahami dan memutuskan terlebih dahulu, lalu meninjau dengan cukup sebelum bergerak; harga dari melewati pemikiran, konteks, dan tanggung jawab akan kembali sebagai sistem yang rusak, tim yang kelelahan, pelanggan yang pergi, dan luka operasional jangka panjang

Bagaimana kecepatan disalahartikan sebagai kemajuan

  • Rilis, respons, perekrutan, ekspansi, dan peralihan yang cepat diperlakukan seolah-olah dengan sendirinya merupakan bukti ambisi dan keseriusan
    • Permintaan untuk melambat dan berpikir dianggap menghambat momentum
    • Menunjukkan bahwa sebuah rencana rapuh secara struktural diterima sebagai sikap negatif
  • Kecepatan bekerja seperti narkotika organisasional yang memberi rasa seolah-olah kita sedang bergerak bahkan tanpa disiplin penilaian
    • Semua orang merasa sibuk dan mendesak, dan aktivitas itu sendiri bisa dijadikan bukti kemajuan
    • Namun, banyak hal yang disebut kecepatan sebenarnya hanyalah ketergesa-gesaan dengan nama lain
  • Kecepatan yang sesungguhnya hanya mungkin ketika pekerjaan dan batasannya jelas, penanggung jawab yang kompeten mengeksekusi berdasarkan keputusan yang sudah tuntas, dan pembahasan ulang tidak terus berulang
  • Situasi yang sering disebut kecepatan biasanya masih menyisakan kebutuhan yang kabur, keputusan yang belum selesai, ketergantungan yang belum ditinjau, dan konteks yang kurang
    • Masalah yang belum diputuskan diharapkan diselesaikan oleh orang berikutnya, lalu semua orang terkejut ketika hasilnya berantakan
    • Ini gagal karena dibangun di atas asumsi bahwa proses berpikir adalah bagian yang paling mahal
  • Pola ini muncul bukan hanya dalam software, tetapi juga saat aktivitas disalahartikan sebagai kemajuan dalam operasional, manajemen, perekrutan, logistik, layanan pelanggan, dan pengembangan produk
  • Setelah mempercepat tahap yang seharusnya dipahami, orang lalu menghabiskan waktu sepuluh kali lebih lama untuk membereskan hasilnya, sementara makna dalam catatan pun terbalik
    • Pekerjaan tergesa-gesa di awal menjadi “eksekusi cepat”
    • Pemberesan menjadi “hal yang tak terduga”, pengerjaan ulang menjadi “iterasi”, kekacauan menjadi “penyelarasan”, dan kegagalan yang sebenarnya bisa dicegah menjadi “pembelajaran”
  • Saat di setiap keputusan kecil yang dipilih adalah kecepatan alih-alih pemahaman, yang menumpuk adalah sistem yang tak dipercaya siapa pun, prosedur yang tak dipahami, rapat yang tak diinginkan, dan dashboard yang tak diyakini
    • Solusi sementara pada akhirnya menjadi struktur esensial yang menopang bisnis
    • “Modernisasi” setelahnya pun sering hanya mengganti kekacauan yang terlihat sambil membiarkan pemujaan terhadap kecepatan tetap utuh

Cara bergerak dengan benar tanpa tergesa-gesa

  • Melambat bukan berarti bekerja lambat, melainkan tidak melewatkan proses membuat pekerjaan menjadi jelas
    • Kita harus memastikan apa sebenarnya yang sedang dibangun dan siapa yang bergantung padanya
    • Kita perlu melihat apa yang akan rusak jika asumsi ternyata salah, apa yang sudah kita ketahui, dan apa yang kita pura-pura tidak tahu
    • Titik kegagalan di masa lalu dan syarat yang diperlukan untuk berhasil juga harus diperiksa
  • Pertanyaan-pertanyaan dasar ini menghilangkan kepuasan instan dari sekadar bergerak, dan membuat orang tak bisa bersembunyi di balik rasa mendesak atau PowerPoint
    • Karena kita harus benar-benar memahami pekerjaan dan bertanggung jawab atas keputusan detail, hal ini mudah dihindari
  • Kecepatan memungkinkan keputusan tetap kabur dan rincian dilemparkan kepada orang lain sebagai keadaan darurat mereka
    • Ketika keadaan darurat muncul, perbaikan yang lebih cepat, perekrutan yang lebih cepat, penggantian yang lebih cepat, dan rilis yang lebih cepat kembali dijadikan solusi, sehingga masalah yang sama berulang seolah-olah itu obatnya
  • Urgensi tepat ketika pekerjaan penting benar-benar memiliki batas waktu, tetapi ketergesa-gesaan muncul ketika orang ingin memperoleh kelegaan emosional dari bertindak tanpa menanggung beban kejelasan
  • Mengkritik kecepatan bukan berarti sengaja bergerak lambat atau mengubah setiap keputusan menjadi rapat
    • Kita juga tidak perlu menghabiskan enam bulan membangun sendiri infrastruktur deployment demi membuktikan bahwa kita penuh pertimbangan
    • Intinya adalah menghormati pekerjaan cukup besar untuk mengerjakannya dengan benar sejak awal
  • Urutan yang benar adalah memahami → memutuskan → meninjau secukupnya → mengeksekusi
    • Jika urutannya dibalik, harganya dibayar lewat sistem yang rusak, tim yang kelelahan, dan pelanggan yang diam-diam pergi
    • Juga akan tertinggal luka operasional yang harus diakali selama bertahun-tahun karena tidak ada kesabaran untuk kembali memahami penyebabnya
  • Perubahan pasar, persaingan, pelanggan yang menuntut, tim kecil, anggaran ketat, dan peluang yang segera tertutup memang bisa menjadi batasan nyata
    • Namun, itu juga sering dipakai sebagai alasan untuk menghindari pekerjaan yang lebih lambat dan lebih sulit: memahami situasi sebelum bergerak
  • Cara yang lebih baik adalah tetap tenang sambil terus mengambil keputusan dan merilis
    • Tidak mengira kepanikan sebagai keseriusan, setiap jeda sebagai kelemahan, atau gerakan itu sendiri sebagai kemajuan
    • Jika pemikiran, kejelasan, konteks, dan tanggung jawab dihilangkan, kita mungkin akan terasa lebih cepat sesaat, tetapi sistem dan orang yang memeliharanya akan terus menanggung akibatnya
    • Beberapa pekerjaan justru baru bisa menjadi lebih cepat setelah kita berhenti terburu-buru

1 komentar

 
GN⁺ 2 jam lalu
Opini Hacker News
  • Lambat itu mulus, mulus itu cepat
    Hal yang saya pelajari tentang kecepatan adalah orang cenderung tidak mengukurnya, atau salah mengukur hanya hal-hal yang terasa nyaman saat itu. Pengukuran yang benar bisa diobjektifkan dengan angka, tetapi ada juga orang yang bahkan tidak bisa mengukur dengan benar, seperti orang yang sulit melakukan refleksi diri. Angka hasil tebakan salah lebih dari 80% dan mudah meleset beberapa orde besaran. Perbaikan kecil yang muncul dari pengukuran sering terakumulasi jauh lebih besar dari dugaan, dan cara paling pasti untuk menjadi lebih cepat adalah mengubah teknologi dan teknik. Perekrutan itu lambat, dan menambah orang ke proyek yang sudah terlambat justru membuatnya makin lambat; semakin banyak memperbaiki lapisan bawah dari tech stack, semakin besar pula kecepatan dan fleksibilitas yang didapat, dan itu bisa dimanfaatkan untuk memperbesar skala

    • Atlet dayung menyebut keadaan bergerak tanpa gesekan sebagai swing. Seperti mengayun yang lebih baik mengikuti gravitasi dan momentum alih-alih dipaksa bergerak, perahu pada dasarnya memang ingin melaju cepat, jadi yang penting adalah tidak merintangi dengan meronta mati-matian. Terlalu banyak usaha merusak kecepatan, dan swing bukanlah keadaan saat berusaha keras, melainkan keadaan yang sudah tercapai — Houghton Mifflin, Mind Over Water
    • Sulit memahami mengapa sebagian orang tidak bisa melakukan refleksi diri, dan apakah benar ada orang yang memang tidak mampu melakukan refleksi diri
    • Jika Anda orang pertama yang benar-benar mulai mengukur dalam sebuah codebase, hasilnya tidak akan berhenti pada perbaikan kecil. Biasanya ada peluang perbaikan besar dan jelas yang bertebaran di mana-mana
    • Tidak semua hal bisa diukur, dan memilih apa yang akan diukur sendiri sudah merupakan keputusan editorial yang membawa bias
  • Walaupun tidak salah secara teknis, proyek bisa gagal jika Anda menghabiskan 6 bulan, bukan 6 minggu, untuk mencari solusi praktis atas masalah pelanggan sampai pelanggan kelelahan. Dari sudut pandang pelanggan, kecepatan adalah fitur sekaligus nilai ekonomi
    Bayangkan saja perasaan saat harus memanggil teknisi untuk memperbaiki AC yang rusak pada sore hari di bulan Agustus di Texas. Dalam bidang yang kompleks dan penuh ketidakpastian, proses iterasi yang cepat itu penting, dan lebih baik menilai apakah terlalu cepat melalui reaksi yang ditunjukkan pelanggan

    • Pelanggan software sangat beragam: mulai dari perusahaan yang memesan aplikasi acara, Walmart yang membuat platform e-commerce, developer yang memakai layanan AWS, sampai pengguna umum Windows dan iOS. Karena pelanggan pun tidak mengendalikan kualitas, keandalan, atau solusi, tidak ada cara untuk tahu sebelumnya apakah pengembangan berjalan terlalu cepat
      Perbaikan AC lebih mirip perbaikan darurat; analogi yang lebih baik adalah membangun rumah dalam beberapa hari agar lolos dari panas Texas, lalu menghabiskan 6 tahun memperbaiki insulasi, dinding yang tidak terpasang kuat, kabel luar, dan pipa yang menumpahkan air ke bawah rumah
    • Tulisan itu juga tampaknya beranggapan bahwa kecepatan yang sesungguhnya muncul ketika pekerjaan dan batasannya dipahami, lalu orang-orang yang terampil mengambil keputusan yang jelas dan mengeksekusinya tanpa perdebatan berulang. Sikap tergesa-gesa yang mengganggu perencanaan dan kesepakatan mudah menambah kesalahan dan biaya, serta merusak proyek, kepercayaan, dan moral; jika kepanikan dijadikan kondisi default, hasil cepat pun cenderung gagal
    • Perlu juga memikirkan situasi ketika teknisi datang enam kali dalam seminggu dan setiap kali bilang sudah diperbaiki, tetapi AC tetap rusak
    • Saya ragu apakah tulisan ini benar-benar mengatakan bahwa urgensi itu sendiri harus diabaikan, dan saya juga penasaran berapa banyak perusahaan atau orang yang benar-benar mengabaikan urgensi
      Dalam gangguan besar yang berdampak bisnis, orang sering mencoba tindakan apa pun tanpa memandang jabatan lalu malah menambah kekacauan, dan total waktu serta dampaknya menjadi lebih besar dibanding saat mereka bekerja sama, memahami masalah, lalu menyelesaikannya. Pendekatan yang tenang dan konsisten yang berhenti sejenak untuk memahami keseluruhan masalah termasuk urgensinya ternyata pada akhirnya lebih cepat, dan itu juga tetap bisa berjalan seiring dengan memberi tahu pelanggan tentang progres dan menenangkan kekhawatiran mereka
    • Kita perlu mendefinisikan dulu tolok ukur solusi praktis. Penilaian bahwa 6 minggu itu cukup sama subjektifnya dengan 6 bulan, dan jika hasil yang awalnya tampak layak terus diperbarui, perlu dipertimbangkan berapa kali pelanggan akan menoleransinya, dan seberapa parah masalah pada minggu ke-7. Setelah beralih dari model waterfall ke agile, rasanya kita hidup dalam solusi praktis yang terus diperbarui tanpa henti
  • Pemujaan terhadap kecepatan berasal dari jadwal venture capital. Investor VC punya tenggat untuk mengembalikan hasil kepada para pemberi modal, jadi mereka hanya tertarik jika dibuat percaya bahwa perusahaan bisa tumbuh 10x dalam jadwal itu
    Jika sungguh terikat pada jadwal itu, orang mudah menetapkan tenggat sewenang-wenang yang mengabaikan realitas teknis, lalu menghapus proyek hanya karena tenggat itu tidak tercapai

    • Bagi investor VC, tenggat itu tidak sewenang-wenang; yang menentukannya adalah biaya modal. Kondisi pasar dan teknologi tidak penting; jika laba, pendapatan, atau pangsa pasar tidak tumbuh cukup cepat, mereka akan mencatatnya sebagai kerugian dan melikuidasi perusahaan
      Jika struktur mati-kalau-tidak-tumbuh-gila-gilaan itu tidak cocok dengan tujuan Anda, Anda seharusnya tidak menerima pendanaan VC. Jika ingin mengembangkan tanpa terburu-buru, Anda harus memilih startup dengan product-market fit (PMF) yang sudah terbukti dan tim sales yang hebat untuk memikul kurva pertumbuhan
    • Perusahaan yang menerima pendanaan VC hanyalah sebagian kecil dari seluruh perusahaan. Alternatifnya, pembiayaan utang justru punya lebih banyak tenggat dan tekanan waktu
    • Pada perusahaan yang tumbuh dengan kekuatan sendiri tanpa VC, rasa mendesaknya bisa lebih besar. Jika tidak cepat sukses besar, tekanan untuk cepat mengirimkan hasil agar bisa menghasilkan pendapatan dan menerima gaji yang layak itu nyata, dan juga sulit merekrut lebih banyak orang untuk membagi pekerjaan
      Startup yang mendapat pendanaan VC justru terasa lebih ringan karena punya bantalan kas yang longgar dan kemungkinan dukungan tambahan. Investor menginginkan imbal hasil lebih tinggi daripada pasar saham, dan pendiri menginginkan kekayaan lebih besar daripada saat bekerja di FAANG, jadi tekanan untuk imbalan yang sepadan dengan risiko muncul terlepas dari cara pendanaannya
    • Tonggak proyek atau jadwal yang sewenang-wenang pun tetap berguna. Itu tidak harus dipakai sebagai dasar untuk menghapus proyek, tetapi bisa menjadi patokan yang memperlihatkan hasil dari upaya bila dibandingkan dengan perubahan dari luar
    • Dalam hal membuat orang mengabaikan bukan hanya realitas teknis tetapi hampir semua hal yang layak dianggap bernilai, venture capital itu seperti kanker dunia
  • Seorang kolonel Angkatan Darat yang sinis sering berkata, “dalam satuan waktu yang cukup pendek, bahkan gerakan periodik pun tampak seperti kemajuan”, dan “lambat itu mulus, mulus itu cepat”

    • Di tikungan tajam balap lintasan, rasanya seperti melambat sehingga kita ingin memaksa lebih cepat, tetapi justru lebih baik mengurangi kecepatan lagi agar bisa berbelok dengan halus, terkendali, dan presisi, sehingga akselerasi setelahnya lebih baik. Prinsipnya adalah masuk lambat, keluar cepat
      Secara hitungan pun, menaikkan kecepatan 1 mil per jam di lintasan lurus seperempat mil lebih menguntungkan daripada menaikkan 1 mil per jam di tikungan lambat sepanjang 100 kaki
    • Dalam pelatihan militer dasar, para instruktur terus-menerus mengulang kalimat itu. Saat masuk ke bunker beton yang memanaskan butiran gas air mata dalam salah satu pelatihan perwira, mata terasa terbakar hebat, tetapi bahkan sebelum sempat berpikir sadar, saya sudah mengambil dan memakai masker gas, lalu menjalankan prosedur filter dan krim dekontaminasi dengan benar
      Saya bisa menahan dorongan untuk melepas masker gas dan mengucek mata karena latihan yang lambat dan berulang menghasilkan tindakan cepat yang otomatis. Mengganti magasin dan mengoperasikan forward assist juga mengikuti prinsip yang sama
  • Dari sudut pandang engineering, melakukannya pelan membuat segalanya lebih mulus dan lebih cepat, tetapi dari sudut pandang sales, lambat ya tetap lambat. Jika selama menjanjikan kualitas lebih tinggi 6 bulan kemudian, pesaing mengambil kontrak langka berdurasi 5~10 tahun, situasinya bisa berujung bukan sekadar fokus ke hal lain, melainkan harus memecat seluruh tim yang tidak lagi punya tempat untuk ditempatkan
    Titik kegagalannya adalah menuntut hasil sejak awal sambil katanya memberi perusahaan waktu untuk membangunnya dengan benar. Jika 6 bulan atau 1 tahun dihabiskan untuk infrastruktur, design system, component library, dan system design tanpa hasil yang bisa ditunjukkan, penagihan biaya dan pelacakan jadi aneh, dan janji bahwa pengembangan ke depan akan menjadi sangat cepat tidak mempan bagi eksekutif

    • Rasa mendesak bisa saja nyata, tetapi melewatkan perencanaan tidak membuat segalanya lebih cepat. Sering kali hanya dengan merencanakan beberapa jam, kita bisa mencegah berminggu-minggu kerja sia-sia dan pengerjaan ulang
    • Dalam jangka pendek, terburu-buru memang tampak benar, tetapi sudut-sudut yang dipotong pada akhirnya akan mengejar balik. Jika pernah mengalami tim sales yang demi kontrak besar memaksa fitur khusus disisipkan tanpa waktu memikirkan struktur, atau menuntut rilis sebelum pengujian selesai, pasti paham. Mereka mungkin menang satu kontrak, tetapi jarang menang perang jangka panjang
      Kita harus membedakan antara bergerak lambat karena teliti dan bertanggung jawab dengan lambat karena tidak kompeten. Tekanan pasar itu nyata, dan tim yang terus lambat akan tersingkir. Kadang lambat berujung pada kelancaran dan kecepatan, kadang hanya benar-benar lambat, jadi kuncinya adalah mengetahui perbedaan keduanya
  • Di awal karier, saya sadar bahwa kadang eksekutif menganggap suatu masalah tidak ditanggapi serius jika stresnya tidak ditunjukkan secara lahiriah. Ucapan seperti “tidak terasa ada urgensi” sangat mengguncang mental saya saat itu

    • Manajemen yang sesungguhnya adalah memutuskan bagaimana mengalokasikan sumber daya yang terbatas di antara pilihan-pilihan yang saling bersaing. Tetapi banyak manajer dan anggota tim menganggap manajemen sebagai urusan mengendalikan orang, dan pada praktiknya hanya berhenti pada peran pengawas yang memantau apakah orang lain bekerja lebih keras
    • Saya juga pernah mendengar hal yang sama, tetapi alih-alih goyah saya menyimpulkan bahwa orang yang tidak bisa membedakan penampilan dan kenyataan seharusnya tidak menjadi CEO
    • Manajer yang cemas cenderung ikut gelisah saat melihat orang lain tidak gelisah, tetapi banyak juga manajer yang tidak seperti itu
  • “Jangan bingungkan gerakan dengan kemajuan. Kursi goyang terus bergerak, tetapi tidak maju ke depan” — Alfred A. Montapert

  • Sulit untuk tidak setuju dengan tulisan ini, tetapi tenggat waktu sama sekali hilang dari pembahasannya. Tuntutan kecepatan tidak selalu muncul dalam ruang hampa, dan meski harus dilawan jika tidak adil, secara realistis saya ragu kita selalu punya pilihan

    • Tulisan ini tampaknya memandang pekerjaan dengan agak idealistis dan santai. Dibanding terjebak perfeksionisme, menunggu umpan balik, atau membuat hal yang tidak perlu, ada keuntungan yang jelas dari bergerak cepat meski beberapa hal jadi berantakan. Ini adalah pelajaran dasar dari manajemen agile, dan walau tidak mutlak, secara umum kecepatan yang lebih tinggi daripada tingkat yang terasa nyaman memang menguntungkan
    • Sebagai penulis, saya melihat tenggat biasanya sebagai batasan buatan. Memang ada tenggat yang tidak bisa diubah, seperti syarat peluncuran atau jadwal produksi vendor, tetapi sering kali tenggat dipakai sebagai alasan untuk mengalihkan perhatian dari tujuan sebenarnya dan memaksa orang terburu-buru, atau sebagai cambuk psikologis
      Jika hanya terburu-buru demi memenuhi tenggat, pada saat itu mungkin terlihat lebih cepat, tetapi hasilnya akan lebih buruk daripada yang sebenarnya bisa dicapai tim, dan nanti lebih banyak waktu terbuang untuk membereskan hasil yang berantakan. Ini bukan berarti kita harus santai dalam semua situasi, tetapi dalam lingkungan yang selalu bergerak cepat namun hampir tak pernah benar-benar mencapai target, kita perlu meninjau apakah ketergesaan itu sendiri adalah penyebab kegagalan
      Setelah FedEx meluncurkan dashboard baru untuk staf pengiriman, sistem macet saat proses penerimaan MacBook, dan staf memprosesnya secara manual lalu memberikan tanda terima, tetapi label yang tercetak salah. Akibatnya laptop itu tidak pernah sampai ke Apple, sehingga selama beberapa minggu saya harus berulang kali menjelaskan situasinya kepada berbagai staf, dan sebulan kemudian Apple harus mengirim laptop baru seharga 5 ribu dolar. Ini contoh bagaimana satu software yang diburu karena tenggat sewenang-wenang membuang waktu dan biaya dalam jumlah besar; maksud memperlambat bukan demi kenyamanan psikologis, melainkan untuk mencegah kekacauan sekarang dan di masa depan
    • Sebagian besar tenggat adalah batasan buatan yang diciptakan sendiri. Ini bukan berarti saat separuh rumah terbakar kita menjadwalkan rapat dan membahasnya lewat Slack; ada hal-hal yang memang sungguh lebih mendesak. Tulisan ini bukan bersifat absolut, melainkan mengkritik pemujaan terhadap kecepatan dan menuntut disiplin untuk menilai sesuai konteks
  • Laju dan vektor kecepatan itu berbeda. Orang yang jatuh dari gedung 100 lantai mungkin merasa dirinya melaju dengan kecepatan luar biasa, tetapi vektor kecepatan menuju tujuan hanya muncul ketika kita mempertimbangkan banyak ketergantungan dan bernavigasi dengan benar
    Di perusahaan besar, sering kali keduanya tidak penting dan sebagian besar hasil kerjanya buruk. Tenggat direncanakan agar cocok dengan evaluasi kinerja tahunan, dan orang-orang yang disukai eksekutif membangun kisah sukses dengan mencapai metrik yang “benar” atau mengubah milestone agar tampak berhasil lalu diberi imbalan. Eksekutif sendiri juga diberi imbalan karena dianggap mengawasi keberhasilan itu dengan baik

  • Semakin panjang karier saya, semakin jelas prinsip ini. Tetapi bisa jadi masalah ketika rekan kerja yang lebih muda belum menyadarinya namun berada di atas lapisan manajemen saya
    Saya kadang mendorong refleksi dengan mengatakan hal-hal seperti, “Beberapa hasil terbesar yang pernah saya capai adalah kode yang saya putuskan untuk tidak saya tulis