24.1 Dari Task ke Dampak: Memperluas Radius Keputusan
Anda terbiasa menyelesaikan pekerjaan teknis. Ada task, ada bug, ada perubahan kecil, ada permintaan dari tim lain, lalu Anda mengerjakannya sampai selesai. Pekerjaan seperti ini penting. Tanpa orang yang bisa mengeksekusi, tidak ada software yang benar-benar hidup. Tetapi setelah beberapa waktu, muncul pertanyaan yang lebih besar: apakah dampak Anda hanya sebatas task yang diberikan, atau Anda juga ikut membantu menentukan pekerjaan apa yang memang layak dilakukan?
Banyak orang teknis sampai pada titik ini. Jawaban yang sering terdengar adalah naik jabatan: senior engineer, tech lead, atau architect. Buku ini tidak menolak label itu, tetapi label bukan pusat pembahasannya. Yang lebih penting adalah perluasan radius keputusan. Seseorang mulai berpikir seperti arsitek ketika ia tidak hanya bertanya "bagaimana task ini dibuat?", tetapi juga "kenapa ini perlu dibuat, apa dampaknya, sistem apa yang tersentuh, dan bagaimana kita tahu keputusan ini benar?"
Seorang engineer biasa mengambil keputusan dalam lingkup task. Bagaimana cara mengimplementasikan fitur ini? Database query mana yang paling efisien? Apakah perlu refactor method ini? Keputusan-keputusan ini penting, tapi dampaknya terbatas pada satu bagian kecil dari sistem. Seorang arsitek mengambil keputusan dalam lingkup yang lebih luas: bagaimana sistem ini berinteraksi dengan sistem lain? Apakah arsitektur saat ini masih bisa mendukung pertumbuhan bisnis dua tahun ke depan? Teknologi apa yang sebaiknya dipakai untuk menyelesaikan masalah yang belum muncul?
Perbedaan ini bukan soal senioritas teknis semata. Banyak engineer senior yang sangat mahir menulis code, tetapi tetap berada di zona nyaman sebagai pelaksana. Mereka adalah task taker: orang yang menunggu instruksi dan mengerjakannya dengan baik. Cara berpikir arsitektural bergerak lebih awal dari itu. Ia membantu organisasi mendefinisikan masalah sebelum solusi dicari. Ia tidak menunggu tugas datang; ia ikut memperjelas tugas apa yang memang perlu dikerjakan.
Untuk memperjelas perbedaan radius keputusan, perhatikan diagram berikut.
Di era AI, perbedaan ini semakin penting. AI bisa menjadi eksekutor yang sangat efisien. Anda bisa memberikan instruksi ke AI, dan dalam hitungan detik Anda mendapatkan code, dokumentasi, atau analisis. Namun pembentukan masalah tetap wilayah manusia. AI tidak bisa duduk bersama stakeholder, mendengar kebingungan mereka, lalu merumuskan masalah yang sebenarnya perlu dipecahkan. AI tidak bisa melihat konteks organisasi, politik internal, dan prioritas bisnis yang saling bertabrakan.
Maka pertanyaan yang perlu diajukan bukanlah "bagaimana cara mendapatkan jabatan architect?", melainkan "apakah saya siap memperluas radius keputusan saya?" Jika jawabannya ya, langkahnya dimulai dari cara memandang pekerjaan harian. Mulailah bertanya mengapa sebuah fitur dibuat, bukan hanya bagaimana cara membuatnya. Mulailah memperhatikan sistem secara utuh, bukan hanya bagian yang menjadi tanggung jawab Anda. Mulailah melihat keputusan teknis sebagai keputusan yang punya konsekuensi bagi pengguna, tim, biaya, risiko, dan arah organisasi.
Subbab selanjutnya akan memakai beberapa role di organisasi sebagai peta pembanding. Bukan untuk mengatakan bahwa semua orang harus mengejar title tertentu, tetapi untuk menunjukkan bagaimana radius keputusan bisa melebar dari task, ke tim, ke sistem, sampai ke arah organisasi.
