Cara Staff Engineer Menemukan Masalah yang Layak Dikerjakan

Ada perbedaan mendasar antara engineer yang menunggu task dan engineer yang menemukan masalah. Di level staff engineer, kemampuan menemukan masalah bukan lagi pelengkap — ia adalah inti dari peran tersebut. Staff engineer diharapkan tidak hanya menyelesaikan apa yang sudah ditugaskan, tapi mengidentifikasi masalah yang paling penting untuk dikerjakan, bahkan sebelum orang lain menyadarinya.

Artikel ini membahas bagaimana staff engineer menemukan masalah yang layak dikerjakan, pola pikir yang mendasarinya, dan metode praktis yang bisa diterapkan oleh engineer di level mana pun.

Kenapa Menemukan Masalah Itu Sulit

Menemukan masalah yang tepat lebih sulit dari yang terlihat. Ada dua ekstrem yang sering terjadi: engineer pemula cenderung tidak melihat masalah apa pun karena belum memahami sistem secara utuh, sementara engineer yang terlalu sibuk dengan task harian tidak punya waktu untuk melihat masalah yang lebih besar.

Masalah lain adalah kecenderungan untuk mengerjakan hal yang terlihat, bukan yang penting. Bug yang berisik, permintaan fitur yang vokal dari satu pengguna, atau task yang mudah dikerjakan sering kali menyita perhatian — sementara masalah struktural yang berdampak jauh lebih besar dibiarkan membusuk di latar belakang.

Staff engineer melawan kecenderungan ini dengan sengaja. Mereka tidak menunggu masalah datang; mereka membangun sistem untuk menemukannya.

Pola Pikir: Masalah sebagai Peluang

Ada beberapa pola pikir yang membedakan cara staff engineer memandang masalah:

• Masalah adalah informasi. Setiap keluhan, bug, atau hambatan adalah data tentang kelemahan sistem. Daripada kesal, engineer yang baik bertanya: apa yang masalah ini katakan tentang sistem?
• Gejala vs akar masalah. Keluhan yang muncul berulang sering kali gejala dari satu akar masalah. Menemukan akar itu jauh lebih berharga daripada menambal gejala satu per satu.
• Dampak lebih penting dari kesulitan. Masalah yang berdampak besar tapi sulit lebih layak dikerjakan daripada masalah kecil yang mudah. Pertanyaannya bukan "bisakah ini dikerjakan?", tapi "seberapa besar dampaknya jika selesai?"
• Banyak masalah kecil = satu masalah besar. Ketika tim terus mengeluhkan hal yang sama dengan kata-kata berbeda, itu biasanya tanda adanya satu masalah struktural yang belum diidentifikasi.

Pola pikir ini menggeser fokus dari menyelesaikan task menjadi memahami sistem. Dan pemahaman adalah bahan bakar untuk menemukan masalah yang tidak terlihat.

Metode Praktis Menemukan Masalah

Berikut metode yang bisa dipraktikkan untuk menemukan masalah bernilai tinggi:

1. Ikuti rasa frustrasi tim. Ketika orang mengeluh, jangan abaikan. Catat keluhan yang berulang. Jika tiga orang mengeluh tentang hal yang sama dengan cara berbeda, kemungkinan besar ada satu masalah akar yang sama.

2. Perhatikan proses, bukan hanya hasil. Bagaimana fitur dikembangkan? Di mana bottleneck-nya? Deploy yang lama, review yang macet, test yang sering rusak — semuanya adalah masalah proses yang sering tidak terlihat karena sudah dianggap normal.

3. Pelajari data operasional. Error log, metrik performa, dan data observability adalah tambang emas untuk menemukan masalah. Lonjakan error, peningkatan latensi, atau degradasi bertahap adalah sinyal yang tidak akan muncul di rapat.

4. Dengarkan pengguna secara langsung. Dukungan pelanggan, feedback forum, dan percakapan langsung dengan pengguna sering mengungkap masalah yang tidak tertangkap oleh metrik. Pengguna berbicara dalam bahasa masalah, bukan bahasa teknis — dan itu justru berharga.

5. Tanyakan "kenapa" berulang kali. Ketika menemukan satu masalah, tanya kenapa sampai ke akarnya. Lima kali "kenapa" biasanya cukup untuk sampai ke masalah struktural yang sebenarnya.

6. Buat daftar masalah yang hidup. Jangan simpan temuan di kepala. Catat masalah yang ditemukan, perkirakan dampaknya, dan tinjau daftar itu secara berkala. Daftar ini menjadi bahan untuk memilih pekerjaan berikutnya secara sadar.

Memprioritaskan Masalah

Menemukan masalah saja tidak cukup — harus tahu mana yang layak dikerjakan. Staff engineer biasanya memprioritaskan dengan mempertimbangkan beberapa faktor:

• Skala dampak. Berapa banyak orang atau sistem yang terpengaruh? Masalah yang memengaruhi banyak pengguna atau banyak tim biasanya lebih mendesak.
• Frekuensi. Masalah yang muncul terus-menerus lebih layak dibandingkan yang sekali-sekali saja.
• Biaya menunda. Apa yang terjadi jika masalah tidak dikerjakan? Beberapa masalah memburuk seiring waktu dan jadi jauh lebih mahal untuk diperbaiki.
• Leverage. Apakah menyelesaikan masalah ini juga menyelesaikan masalah lain? Masalah akar punya leverage tinggi — satu perbaikan, banyak manfaat.
• Kesiapan. Apakah tim punya kapasitas dan konteks untuk mengerjakan ini sekarang? Masalah terbaik sekalipun tidak akan selesai jika dikerjakan di waktu yang salah.

Yang sering dilupakan: masalah yang layak dikerjakan tidak selalu harus besar. Kadang masalah kecil yang mengganggu banyak orang setiap hari justru memberi dampak kumulatif yang besar — terutama jika itu masalah proses yang terjadi berulang kali.

Menjual Masalah ke Tim

Menemukan masalah adalah setengah perjalanan. Setengah lainnya adalah meyakinkan orang lain bahwa masalah itu layak dikerjakan. Staff engineer tidak bisa mengerjakan semuanya sendiri — mereka butuh dukungan tim dan stakeholder.

Kunci menjual masalah adalah membingkainya dalam bahasa dampak, bukan bahasa teknis. Jangan bilang "kita perlu refactor modul ini". Bilang "setiap fitur baru di area ini butuh waktu dua kali lebih lama karena kode yang sulit dimodifikasi — dan ini biaya yang kita bayar setiap minggu".

Data membantu. Jika bisa menunjukkan angka — berapa kali masalah terjadi, berapa waktu yang hilang, berapa pengguna yang terdampak — argumen jadi jauh lebih kuat daripada sekadar intuisi.

Kesimpulan

Menemukan masalah yang layak dikerjakan adalah keterampilan yang bisa dilatih, bukan bakat bawaan. Semua berawal dari rasa ingin tahu tentang sistem, kemauan mendengarkan frustrasi orang lain, dan disiplin untuk mencatat serta memprioritaskan temuan.

Untuk engineer yang ingin tumbuh ke level staff, mulailah dari hal sederhana: buat daftar masalah yang lo temukan minggu ini. Perhatikan yang berulang, tanya kenapa sampai ke akar, dan pilih satu yang paling berdampak untuk dikerjakan. Seiring waktu, kebiasaan ini akan membentuk pola pikir yang membedakan pelaksana task dari penemu masalah.

Mengembangkan Kebiasaan Menemukan Masalah

Kebiasaan menemukan masalah tidak terbentuk dalam semalam. Seperti keterampilan lain, ia butuh latihan yang konsisten dan lingkungan yang mendukung. Berikut beberapa kebiasaan harian yang bisa dibangun:

Jadwalkan waktu eksplorasi. Staff engineer yang baik menyisihkan waktu secara rutin — misalnya satu jam seminggu — untuk sekadar menjelajahi sistem tanpa task tertentu. Waktu ini dipakai untuk membaca kode yang jarang disentuh, memeriksa log, atau melihat metrik. Eksplorasi yang tidak terarah sering kali justru menemukan masalah yang tidak terlihat dari permukaan.

Catat sebelum melupakan. Temuan yang tidak dicatat akan hilang. Biasakan mencatat masalah kecil yang ditemui — bahkan yang terlihat sepele — dalam satu tempat. Enam bulan kemudian, pola dari catatan-catatan kecil itu sering mengungkap masalah besar yang tidak pernah disadari.

Diskusikan dengan orang di luar tim. Perspektif dari luar tim sering melihat apa yang tidak terlihat oleh orang di dalam. Ngobrol dengan tim lain, dukungan pelanggan, atau bahkan pengguna akhir bisa membuka masalah yang selama ini dianggap normal oleh tim sendiri.

Belajar dari kegagalan operasional. Incident dan outage adalah sumber belajar yang kaya. Setiap insiden mengungkap kelemahan proses, kesenjangan monitoring, atau asumsi yang salah. Staff engineer mempelajari insiden bukan hanya untuk menyalahkan, tapi untuk menemukan masalah berikutnya yang tersembunyi di baliknya.

Tantang asumsi secara rutin. "Sudah dari dulu begini" adalah kalimat yang paling sering menyembunyikan masalah. Ketika mendengar kalimat itu, tanya: apakah alasan di balik keputusan itu masih berlaku? Banyak masalah struktural bertahan hanya karena tidak ada yang berani mempertanyakan asumsi lama.

Menghindari Jebakan Umum

Dalam proses menemukan dan memprioritaskan masalah, ada beberapa jebakan yang sering dialami engineer:

Jebakan solusi dini. Kecenderungan untuk langsung melompat ke solusi sebelum masalah dipahami dengan baik. Ini menghasilkan perbaikan yang menangani gejala, bukan akar — dan masalah akan kembali muncul dengan bentuk berbeda.

Jebakan kepopuleran. Masalah yang paling banyak dikeluhkan tidak selalu yang paling penting. Keluhan bisa datang dari segelintir pengguna yang vokal, sementara masalah yang memengaruhi mayoritas tidak terdengar karena penggunanya tidak protes — mereka hanya diam-diam pergi.

Jebakan kesibukan. Terus sibuk mengerjakan task memberi rasa produktif, tapi bisa menghalangi waktu untuk berpikir. Staff engineer sadar bahwa waktu "tidak produktif" untuk berpikir dan mengeksplorasi justru sering kali yang paling bernilai.

Jebakan kepemilikan. Merasa semua masalah adalah tanggung jawab sendiri. Staff engineer yang baik tahu kapan harus mengerjakan sendiri dan kapan harus mengangkat masalah ke orang lain — atau mengajak tim untuk mengerjakannya bersama.

Menghindari jebakan ini butuh kesadaran diri. Yang membantu adalah kebiasaan bertanya: "apakah saya sedang mengerjakan hal yang paling penting, atau hal yang paling terlihat?"

Kapan Suatu Masalah Bukan Masalah Lo

Bagian yang jarang dibahas: tidak semua masalah perlu dikerjakan. Staff engineer yang baik juga tahu kapan harus melewatkan. Beberapa kriteria yang membantu:

Masalah di luar lingkup. Jika masalah berada di area yang tidak bisa dipengaruhi — kebijakan perusahaan, keputusan vendor, atau sistem yang dikelola tim lain — mengerjakan langsung mungkin bukan langkah terbaik. Kadang yang perlu dilakukan adalah mengangkat masalah itu ke orang yang tepat.

Dampak yang tidak jelas. Jika tidak bisa memperkirakan dampak suatu masalah secara masuk akal, mungkin masalah itu belum layak dikerjakan. Lebih baik menunggu bukti tambahan daripada mengerjakan sesuatu yang mungkin tidak penting.

Waktu yang salah. Masalah yang benar-benar penting pun bisa dikerjakan di waktu yang salah. Jika tim sedang dalam tekanan deadline besar atau sedang melakukan restrukturisasi, menambahkan pekerjaan baru justru bisa merugikan.

Energi yang terbatas. Setiap tim punya kapasitas terbatas. Mengambil terlalu banyak masalah berarti semuanya dikerjakan setengah-setengah. Kadang keputusan paling bijak adalah fokus pada satu masalah dan membiarkan yang lain menunggu.

Kemampuan memilih apa yang TIDAK dikerjakan sama pentingnya dengan kemampuan menemukan apa yang layak dikerjakan. Ini bagian dari kebijaksanaan yang membedakan staff engineer dari engineer yang sekadar produktif.

Membangun Jaringan Penemuan Masalah

Staff engineer tidak menemukan masalah sendirian. Mereka membangun jaringan — formal maupun informal — yang menjadi sumber temuan:

Dukungan pelanggan. Tim yang berbicara langsung dengan pengguna setiap hari adalah sumber informasi yang luar biasa. Bangun hubungan baik dengan tim ini dan jadikan mereka saluran umpan balik yang aktif.

On-call dan operasional. Engineer yang menangani insiden punya pengetahuan langsung tentang di mana sistem paling rapuh. Percakapan rutin dengan mereka mengungkap masalah yang tidak pernah muncul di dashboard.

Tim product. Product manager dan designer melihat masalah dari sudut pengguna. Kolaborasi dengan mereka menghubungkan masalah teknis dengan dampak bisnis — kombinasi yang membuat argumen untuk mengerjakan suatu masalah jauh lebih kuat.

Komunitas dan konferensi. Engineer lain di luar perusahaan sering menghadapi masalah yang sama. Berbagi pengalaman di komunitas bisa mengungkap solusi yang sudah dicoba orang lain — atau masalah yang belum pernah terpikirkan.

Jaringan ini bukan sekadar sumber informasi; ia juga menjadi saluran untuk menguji ide. Sebelum mengerjakan masalah, bicarakan dengan orang-orang ini untuk memvalidasi bahwa masalah itu nyata dan layak dikerjakan.

Kesimpulan

Menemukan masalah yang layak dikerjakan adalah keterampilan yang bisa dilatih, bukan bakat bawaan. Semua berawal dari rasa ingin tahu tentang sistem, kemauan mendengarkan frustrasi orang lain, dan disiplin untuk mencatat serta memprioritaskan temuan.

Untuk engineer yang ingin tumbuh ke level staff, mulailah dari hal sederhana: buat daftar masalah yang lo temukan minggu ini. Perhatikan yang berulang, tanya kenapa sampai ke akar, dan pilih satu yang paling berdampak untuk dikerjakan. Seiring waktu, kebiasaan ini akan membentuk pola pikir yang membedakan pelaksana task dari penemu masalah.