24.2 Peta Radius Keputusan: Task, Tim, Solusi, dan Organisasi

Setelah memahami bahwa inti pembahasan adalah radius keputusan, kita bisa melihat beberapa role di organisasi sebagai contoh. Role bukan tujuan utama. Role hanya membantu kita membaca jenis keputusan yang berbeda: ada keputusan dekat dengan code, keputusan yang menjaga ritme tim, keputusan yang membentuk solusi, dan keputusan yang mengarahkan banyak sistem sekaligus.

Mari mulai dari posisi yang paling dekat dengan code. Seorang senior engineer adalah orang yang keputusannya masih berada di sekitar implementasi. Ketika tim menghadapi bug yang sulit direproduksi, senior engineer yang memutuskan pendekatan debugging mana yang paling efisien. Ketika ada trade-off antara kecepatan pengiriman dan kualitas code, senior engineer yang ikut menentukan standar yang realistis. Radius keputusannya meliputi modul atau service tempat ia bekerja, dan dampaknya terasa dalam hitungan hari hingga satu sprint.

Untuk memudahkan perbandingan, berikut diagram yang merangkum perbedaan radius keputusan, horizon waktu, dan tipe keputusan utama dari tiga peran pertama yang dibahas.

flowchart TD SE["Senior Engineer"] TL["Tech Lead"] SA["Solution Architect"] SE --> SE1["Radius: Modul / Service"] SE --> SE2["Horizon: Hari - 1 Sprint"] SE --> SE3["Tipe: Implementasi & Debugging"] TL --> TL1["Radius: Satu Tim"] TL --> TL2["Horizon: 1 - 3 Bulan"] TL --> TL3["Tipe: Pengiriman & Prioritas"] SA --> SA1["Radius: Lintas Tim / Domain"] SA --> SA2["Horizon: 6 - 12+ Bulan"] SA --> SA3["Tipe: Batas Sistem & Aliran Data"]

Selanjutnya ada tech lead. Peran ini menarik karena sering disalahartikan sebagai "senior engineer yang ngurusin orang". Padahal, tech lead adalah posisi di mana radius keputusan mulai melebar ke arah pengiriman tim. Seorang tech lead tidak hanya memutuskan bagaimana code ditulis, tetapi juga apa yang harus dikerjakan dalam sprint berikutnya, bagaimana membagi tugas antar anggota tim, dan kapan harus mengatakan tidak pada permintaan fitur yang tidak realistis. Keputusan tech lead berdampak pada ritme dan moral tim, dengan horizon waktu satu hingga tiga bulan.

Lalu kita sampai pada solution architect. Inilah titik di mana seorang engineer mulai meninggalkan code sebagai pusat gravitasi. Solution architect membuat keputusan tentang batas sistem: service mana yang perlu dibuat, mana yang bisa dipakai ulang, bagaimana data mengalir antar komponen, dan teknologi apa yang cocok untuk problem yang dihadapi. Keputusan ini tidak bisa diambil hanya dengan membaca dokumentasi framework. Ia harus memahami konteks bisnis, keterbatasan infrastruktur, dan kemampuan tim yang akan membangun solusi tersebut. Radius keputusannya mencakup satu domain atau beberapa tim, dengan dampak yang terasa dalam enam bulan hingga satu tahun.

Di atas solution architect, ada software architect yang kadang disebut juga principal engineer. Peran ini mirip dengan solution architect, tetapi lebih fokus pada konsistensi teknis di seluruh organisasi. Software architect yang memutuskan pola arsitektur yang harus diikuti semua tim, standar API yang berlaku, dan pendekatan refactoring untuk codebase yang sudah tua. Keputusannya membentuk cara organisasi membangun software secara keseluruhan.

Ada juga platform lead, yang keputusannya berpusat pada pengalaman engineer lain. Platform lead tidak membangun fitur bisnis, melainkan membangun fondasi yang membuat fitur bisnis lebih cepat dikirim. Ia memutuskan tool apa yang perlu disediakan, jalur pemrosesan seperti apa yang standar, dan bagaimana mengurangi friction bagi tim product.

Dan yang paling luas radiusnya adalah enterprise architect. Peran ini jarang menyentuh code secara langsung. Enterprise architect membuat keputusan tentang peta jalan teknologi organisasi: aplikasi mana yang perlu dipertahankan, mana yang perlu dipensiunkan, bagaimana data mengalir lintas domain, dan investasi teknologi apa yang paling strategis untuk tiga hingga lima tahun ke depan.

Yang penting dipahami dari peta ini: setiap role hanyalah nama untuk radius keputusan tertentu. Seseorang tidak perlu menunggu title baru untuk mulai melatih cara berpikir yang lebih luas. Ia bisa mulai dari pekerjaan yang ada: memperjelas masalah, membaca dampak lintas sistem, menulis keputusan, menjaga kualitas delivery, dan membantu tim melihat konsekuensi sebelum terlambat.

Setelah melihat peta radius keputusan ini, pertanyaan selanjutnya adalah: fondasi apa yang harus tetap dikuasai agar seseorang bisa berpikir lebih luas tanpa kehilangan pijakan teknis?