Aturan Kepemimpinan Engineering yang Direvisi

• Merangkum 5 aturan utama kepemimpinan engineering yang telah diuji dan dirumuskan ulang selama setahun terakhir di tengah peralihan ke alat AI dan lingkungan pertumbuhan cepat (hypergrowth), beserta contoh proyek nyata yang mendasarinya
• Migrasi kini bisa dipimpin 95% oleh individu, bukan tim, dan diselesaikan dalam 10% dari waktu sebelumnya; semakin rendah biaya awal, semakin besar pengaruh penilaian individu
• Kode versi pertama hampir gratis, tetapi biaya untuk menghasilkan kode yang benar-benar berjalan ditentukan oleh harness pengembangan seperti testing dan CI/CD, sehingga tidak gratis
• Kasus dasar dari sebagian besar proses dapat diotomatisasi sepenuhnya dengan agen, dan pass pertama code review juga lebih cepat dan efektif dilakukan oleh harness yang baik daripada manusia
• Untuk benar-benar menikmati manfaat AI, prasyaratnya adalah tim berkelanjutan dengan konteks domain serta pengambilan keputusan yang cepat dan kokoh

---

Latar belakang

• Bekerja dalam lingkungan hypergrowth dari awal 2014 hingga akhir 2020, dan nilai terbesar hypergrowth adalah bahwa kesalahan terlihat bulan depan, bukan tahun depan (jika bergerak cepat, masalah akan meledak lebih besar)
• Alasan kembali memikirkan hypergrowth belakangan ini adalah pertumbuhan bisnis Imprint yang cepat, perekrutan besar-besaran tahun lalu, dan karena peralihan ke alat AI telah mengubah kecepatan kerja yang mungkin dicapai
• Tulisan ini merangkum aturan kepemimpinan yang telah dirumuskan ulang beserta proyek-proyek konkret selama setahun terakhir yang membentuk keyakinan tersebut

Aturan yang direvisi

1. Migrasi bisa dijalankan oleh individu, bukan tim

• Bahkan perubahan yang kompleks dan besar dapat dimiliki 95% oleh individu atau tim yang memimpin dan diselesaikan dalam 10% dari waktu sebelumnya
• Semakin rendah biaya awal, semakin besar imbalan/hukuman atas kualitas tiap migrasi
  • Cacat kecil pun merusak model mental software rekan kerja yang harus ikut memeliharanya
• Pengaruh penilaian individu terhadap perusahaan kini lebih besar daripada sebelumnya

2. Kode versi pertama hampir gratis, tetapi biaya kode yang berjalan ditentukan oleh harness pengembangan

• Ini adalah era ketika semua orang harus bisa menulis kode, tetapi menulis kode yang benar-benar berjalan sambil menghindari edge case yang berantakan tetaplah sulit
• Tingkat kesulitan itu ditentukan oleh harness pengembangan seperti testing, CI/CD, lingkungan verifikasi, dan pratinjau perubahan
• Bahkan di perusahaan tempat "semua orang bisa ngoding", yang penting bukan tim marketing mengurangi alokasi server, melainkan ada tidaknya batasan yang memungkinkan mereka berpartisipasi dengan aman (mirip produk SaaS yang mengizinkan kustomisasi melalui penulisan software)
• Hal-hal yang paling bernilai untuk meningkatkan kecepatan engineering dua tahun lalu masih tetap menjadi yang paling bernilai hari ini

3. Optimalkan kasus dasar proses untuk agen

• Dengan harness, kontrol, konteks domain yang tepat, dan penilaian desain yang baik, kasus dasar sebagian besar proses bisa diotomatisasi sepenuhnya
• Kasus dasar code review oleh manusia lebih lambat dan kurang efektif dibanding code review oleh harness yang baik
  • Harness bisa lolos, tetapi manusia juga bisa lolos, dan di sebagian besar area perubahan relatif aman
  • Namun beberapa area berisiko tinggi adalah pengecualian; jika pembedaan ini ditangkap dengan tepat, kita bisa bergerak lebih cepat tanpa risiko, dan jika gagal maka akan muncul tak terhitung banyaknya masalah
• Konsekuensinya, proses perencanaan seperti sprint mingguan atau dua mingguan bekerja di ketinggian yang terlalu rendah, dan perencanaan kolaboratif manusia seharusnya berlangsung pada level yang lebih tinggi

4. Tim berkelanjutan dengan konteks domain dan ownership tinggi menjadi makin penting

• Pelajaran dari Uber: tim yang berkelanjutan dan kokoh menghasilkan performa seperti sulap melalui akumulasi konteks domain, rasa kebersamaan, dan ownership yang kuat
• Meski biaya eksekusi kini lebih murah, kita tetap harus mengerjakan hal yang benar, dan itu hanya menjadi sedikit lebih mudah, bukan jauh lebih mudah
  • Contoh: data yang dibutuhkan untuk optimasi production sama sekali tidak dikumpulkan, sehingga solusi harness tampak masuk akal tetapi salah; satu-satunya solusi adalah menginstrumentasikan informasi yang hilang
• Menentang anggapan bahwa perusahaan AI-first bisa dijalankan oleh segelintir engineer jenius; bahkan individu dengan penilaian tinggi pun akan terbentur kurangnya konteks domain, sehingga tim berkelanjutan tetap menjadi unit fundamental

5. Pengambilan keputusan yang cepat, baik, dan kokoh adalah prasyarat untuk menikmati manfaat AI

• Untuk mengganti legal review dengan otomatisasi, tim Legal harus bisa berkomitmen pada perubahan itu, dan hal ini bergantung pada desain yang cermat serta kemauan tim untuk berkolaborasi
• Manfaat peningkatan kecepatan eksekusi hanya mungkin jika kita mampu membuat keputusan yang cepat, kokoh, dan baik
• Inilah alasan utama peran CTO rata-rata kini jauh lebih teknis dan kurang birokratis dibanding setahun lalu
  • Saat ada perbedaan pendapat antartim, sering kali mereka adalah satu-satunya orang yang bisa membuat keputusan yang mengikat, sehingga terus-menerus harus memutuskan demi menjaga kecepatan
  • Bukan berarti eksekutif selalu pengambil keputusan yang lebih baik, tetapi selama para eksekutif selaras dan saling menghormati keputusan, keputusan eksekutif yang mengikat sangatlah kuat

Contoh penerapan nyata

Migrasi

• Setahun lalu deploy manual sekitar 6 kali per minggu → sekarang 200~400 deploy per minggu; jumlah engineer memang menjadi dua kali lipat, tetapi secara YoY meningkat 20~30 kali, dan perubahan total pada cara operasi deploy serta migrasi dikerjakan 90% selama dua bulan oleh dua orang di tim infra
• Pada 1 Januari hanya ~25% yang setiap hari memakai Claude Code atau Cursor → pada akhir Februari menjadi 100%; tanpa instruksi top-down, gesekan dihilangkan melalui peningkatan kualitas alat dan percakapan dengan pihak yang belum mengadopsi, dan kini hampir semua draft pertama PR dibuat oleh harness
• Berbagai cara konfigurasi disatukan menjadi dua mekanisme konfigurasi (satu untuk konstanta client/server yang hampir tidak berubah, satu lagi untuk nilai per produk yang sering berubah), dan dikerjakan sebagai proyek independen oleh engineer individu
  • Satu orang merapikan arsitektur → orang lain mengimplementasikan arsitektur referensi → beberapa orang menerapkannya di area lain; yang dulu merupakan proyek bertahun-tahun selesai dalam kurang dari satu kuartal, termasuk alat internal untuk mengelola nilai bagi tim engineer maupun non-engineer
• Front-end multi-repo disatukan ke arsitektur monorepo dalam sekitar satu bulan, dengan 95% pekerjaan dipimpin oleh satu front-end engineer, sekaligus memperoleh harness front-end bersama dan sepenuhnya lepas dari hosting paket npm yang selama ini menjadi sumber friksi
• Kode front-end yang sebagian besar belum bertipe diubah menjadi typed statis sepenuhnya, dikerjakan oleh satu engineer selama beberapa minggu dengan jumlah token yang besar
• Untuk default keamanan yang lebih baik dan deploy yang lebih cepat, dilakukan peralihan dari npm ke pnpm, dikerjakan oleh satu engineer beberapa jam per hari selama beberapa hari

Biaya kode yang berjalan ditentukan oleh harness pengembangan

• Cara melempar design doc atau PR "melewati tembok" ke engineer tim lain tidak menghasilkan apa-apa; PR dan design doc yang asal-asalan memang murah, tetapi justru berbahaya
  • Karena perlu dirapikan dan diperbaiki, lalu konteks itu mencemari LLM sehingga hasilnya lebih buruk daripada mulai dari awal
• Selama manajer memverifikasi perubahan secara langsung, memeriksa dashboard setelah deploy, dan menyelesaikan masalah yang muncul, maka kontribusi kode dari manajer menjadi sukses besar; jika tidak, tidak ada efek positif

Optimasi agen untuk kasus dasar proses

• Semua issue masuk dari tim customer operations ditriage oleh harness yang mengetahui tim, tiket terbuka, dan memiliki akses terbatas ke data warehouse untuk memperkirakan dampak, sehingga pekerjaan yang kompleks, butuh skill tinggi, tetapi tidak menarik bisa diproses lebih cepat
  • Edge case tetap ditriage oleh manusia, dan hanya beberapa langkah yang diotomatisasi dalam alur yang sama tanpa mengubah workflow manusia
• Pass pertama code review dilakukan oleh harness yang sama yang mengimplementasikan perubahan, tetapi dengan konteks penulisan dibersihkan, sehingga manusia bisa fokus pada feedback yang bernilai lebih tinggi
• Kuartal lalu Claude Code dan Cowork diluncurkan ke seluruh perusahaan; tim fraud sangat aktif mengganti pekerjaan manual dengan otomatisasi pass pertama untuk melakukan investigasi awal terhadap potensi serangan (termasuk attribution yang berasal dari data itu sendiri)
• Pindah dari Jira ke Linear, memperkuat infrastruktur workflow agent-first dengan MCP yang lebih kuat dan integrasi Slack yang lebih baik; alpha test untuk harness internal yang mengambil issue dari Linear dan menyelesaikannya secara otomatis hampir selesai

Tim berkelanjutan dengan konteks domain dan ownership tinggi

• Saat pertama bergabung, orang-orang bertalenta berputar cepat antararea berdasarkan proyek sehingga sangat responsif, tetapi kini di setiap area penting ditempatkan tim kecil khusus untuk investasi berkelanjutan, dan tim-tim ini sendiri yang memanfaatkan teknik AI baru
• Setelah peluncuran SierraAI, tim terus-menerus meningkatkannya hingga mencapai tingkat yang benar-benar unggul, sesuatu yang mustahil tanpa tim yang khusus dan fokus

Pengambilan keputusan yang cepat, baik, dan kokoh

• Perubahan cara konfigurasi cukup kontroversial sehingga pendekatannya harus dijelaskan berulang kali; dampaknya berbeda untuk tiap tim dan manfaatnya hanya muncul di level ekosistem (satu orang bisa mengonfigurasi pengaturan seluruh tim), sehingga sulit dilakukan secara bottom-up
• Pengerjaan ulang pipeline CI/CD juga kontroversial karena mengubah model mental deploy dan release, dengan feature flag yang secara eksplisit memisahkan deploy dan release
• Integrasi monorepo web juga merupakan keputusan kontroversial dengan banyak perbedaan pendapat, dan manfaat dari keputusan yang disatukan sangat besar
• Adopsi SierraAI melibatkan diskusi sulit dengan pesaing dan opsi untuk tidak mengadopsinya, serta membutuhkan persetujuan eksekutif untuk menutup perdebatan lintas fungsi

Penutup

• Contoh-contoh di atas hanya sebagian yang representatif; masih banyak lagi yang telah dilakukan, dan cakupan hal yang mungkin dilakukan terus meluas setiap bulan
• Faktor penghambat pada dasarnya tidak banyak berubah: ketidakselarasan organisasi, kurangnya kejelasan, dan arsitektur teknis yang buruk