Seorang staff engineer tidak hanya memecahkan masalah sulit. Mereka memecahkan masalah yang menghalangi engineer lain untuk produktif. Saya membangun framework LMS multi-tenant yang melayani 100+ universitas, dynamic form engine yang diadopsi 3 tim, dan jembatan ISO 8583 yang menjadi standar organisasi. Seperti inilah wujud leverage di level staff sebenarnya.
"Seorang staff engineer adalah seseorang yang membuat orang-orang di sekitarnya menjadi lebih baik, bukan sekadar kodenya." ā Seseorang yang lebih bijak dari saya
Lompatan dari senior ke staff adalah transisi karier tersulit yang pernah saya jalani ā lebih sulit dari junior ke mid, lebih sulit dari mid ke senior. Alasannya sederhana: aturan mainnya berubah total. Sebagai senior, Anda dinilai dari kualitas output teknis Anda. Sebagai staff engineer, Anda dinilai dari leverage Anda ā kemampuan Anda untuk melipatgandakan produktivitas engineer di sekitar Anda.
Ini adalah cerita tentang apa yang sebenarnya saya lakukan di level staff, alat apa yang saya bangun, dan apa yang saya sesali tidak saya lakukan.
Senior: "Apakah sistem ini dirancang dengan baik dan berjalan andal?" Staff: "Apakah organisasi ini diperlengkapi dengan baik untuk merancang dan menjalankan sistem yang andal tanpa saya?"
Pekerjaan seorang staff engineer tidak terlihat dengan cara terbaik. Jika saya membuat fitur yang viral, itu adalah kemenangan senior. Jika saya membangun framework yang memungkinkan tiga tim mengirimkan fitur lebih cepat, itu adalah kemenangan staff. Satu memperkuat diri sendiri. Yang lain memperkuat semua orang.
Persamaan leverage-nya sederhana:
Tahun-tahun staff saya adalah pengejaran tanpa henti terhadap leverage 100x itu. Kadang saya berhasil. Kadang saya meleset. Inilah yang terjadi.
Masalahnya: Divisi pendidikan kami membangun sistem manajemen pembelajaran (LMS) yang sama untuk setiap klien universitas baru. Setiap onboarding membutuhkan 2 minggu kustomisasi ā perubahan tema, pengaturan fitur, setup integrasi. Dengan 100+ universitas, ini tidak berkelanjutan.
Pendekatannya: Alih-alih satu codebase per klien, saya merancang satu inti LMS yang dapat dikonfigurasi yang melayani semua tenant. Setiap universitas mendapatkan:
Arsitekturnya: Backend Go bersama dengan konteks tenant yang disebarkan melalui setiap lapisan ā middleware, repositori, dan bahkan connection pool database. Skema menggunakan pendekatan hybrid: tabel bersama untuk metadata dan baris khusus tenant untuk data pengguna, dengan keamanan tingkat baris yang ketat ditegakkan di lapisan ORM.
Hasilnya: Onboarding klien turun dari 2 minggu menjadi 2 hari. Framework white-label sangat dapat dikonfigurasi sehingga tim implementasi dapat melakukan onboarding universitas baru tanpa menulis satu baris kode pun ā cukup file konfigurasi dan perubahan DNS.
Waktu onboarding: 14 hari ā 2 hari per klien Tim yang terdampak: Satu tim platform menjadi mampu layanan mandiri Total klien yang dilayani: 100+ universitas
Masalahnya: Setiap tim produk di organisasi sedang membangun formulir. Aplikasi pinjaman, pendaftaran pelanggan, alat survei, daftar periksa kepatuhan ā pola yang sama berulang tanpa henti. Logika validasi, field bersyarat, wizard multi-langkah. Setiap tim mengimplementasikannya sendiri, dari awal.
Pendekatannya: Saya membangun dynamic form engine dengan tiga aksioma:
ifAdopsinya: Tiga tim produk mengadopsi engine tersebut dalam kuartal pertama. Product manager non-teknis dapat membuat formulir multi-langkah yang kompleks dengan logika percabangan hanya dengan mengedit file konfigurasi JSON. Tim kepatuhan, yang sebelumnya terhambat oleh kapasitas engineering, membuat formulir daftar periksa audit mereka sendiri dalam satu sore.
Kemenangan tersembunyi: Engine tersebut memaksakan konsistensi. Sebelumnya, setiap tim memvalidasi formulir secara berbeda (atau tidak sama sekali). Setelahnya, setiap formulir di seluruh organisasi mengikuti aturan validasi yang sama, jalur pengiriman yang sama, jejak audit yang sama. Konsistensi di skala besar adalah hasil di level staff.
Tipe field: 50+ tipe yang dapat dikomposisi Tim pengadopsi: 3 tim produk di kuartal pertama Adopsi non-pengembang: Product manager dan tim kepatuhan mampu layanan mandiri
Konteksnya: Saya membangun integrasi ISO 8583 pertama untuk SiTepat ā sebuah layanan Go yang menerjemahkan panggilan REST menjadi pesan ISO 8583 yang kompatibel dengan mainframe. Itu adalah proyek satu kali untuk satu mitra perbankan. Saat itu, saya tidak menyadari bahwa itu akan menjadi standar organisasi untuk setiap integrasi bank di masa depan.
Evolusinya: Setelah mitra perbankan kedua dan ketiga bergabung, masing-masing meminta integrasi mereka sendiri, polanya jelas. Saya mengekstrak jembatan tersebut menjadi pustaka yang dapat digunakan kembali dengan:
Dampak di seluruh organisasi: Setiap mitra perbankan berikutnya terintegrasi dalam hitungan hari, bukan minggu. Pustaka tersebut menjadi standar yang terdokumentasi ā ketika tim kepatuhan perlu mengaudit pola integrasi, mereka merujuk ke pustaka jembatan. Ketika seorang engineer baru bergabung dengan tim, mereka mempelajari jembatan terlebih dahulu.
Pembangunan awal: 4 minggu untuk mitra pertama Integrasi berikutnya: 3-5 hari per mitra Adopsi: Standar di seluruh organisasi untuk semua integrasi bank
Tidak ada retrospeksi jujur yang melewatkan penyesalan. Inilah penyesalan saya.
Keputusan arsitektur saya hidup di utas Slack, obrolan lorong, dan di kepala saya. Ketika saya pindah ke tim yang berbeda, kesenjangan pengetahuan muncul seketika. Keputusan yang butuh berminggu-minggu untuk dibuat tidak terlihat oleh engineer yang mewarisi sistem tersebut.
Biayanya: Anggota tim baru menghabiskan waktu berbulan-bulan menemukan kembali mengapa semuanya seperti adanya. Beberapa keputusan buruk diulangi karena alasan masa lalu telah hilang.
Saya mentoring melalui reputasi ā orang datang untuk bertanya, dan saya menjawab. Ini berhasil untuk orang yang bertanya. Ini tidak berhasil untuk orang yang tidak tahu harus bertanya apa, atau mereka yang terlalu terintimidasi untuk mendekat.
Saya tidak pernah mengadakan sesi berbagi pengetahuan formal, tidak pernah membuat playbook onboarding, tidak pernah menuliskan model mental yang saya gunakan untuk menguraikan masalah di skala organisasi.
Saya bisa memberi tahu Anda berapa banyak universitas yang menggunakan LMS. Saya bisa memberi tahu Anda berapa banyak tim yang mengadopsi form engine. Tapi saya tidak pernah mengukur sebelum dan sesudah produktivitas engineering. Dapatkah tim yang menggunakan form engine mengirimkan formulir 3x lebih cepat? Saya yakin bisa. Tapi saya tidak bisa membuktikannya. Dan tanpa data, itu hanya cerita.
Promosi staff membutuhkan bukti, bukan anekdot. Saya membuat kesalahan dengan menganggap dampaknya sudah jelas.
| Item Portofolio | Apakah Saya Melakukannya? | Catatan |
|---|---|---|
| Inisiatif lintas tim | ā | Framework LMS, form engine, jembatan ISO 8583 |
| Standar yang diadopsi di seluruh organisasi | ā | Standar integrasi perbankan, pola form engine |
| Dokumen strategi teknis | ā | Semua keputusan ada di Slack/rapat, bukan dokumen |
| Pembingkaian masalah di level organisasi | ā ļø | Reaktif, bukan proaktif. Memecahkan masalah yang dibawa orang, tidak menemukan masalah yang belum dilihat siapa pun |
| Mentoring engineer lain | ā ļø | Efektif secara informal, tidak pernah diinstitusionalisasikan |
| Mengukur dampak di seluruh organisasi | ā | Tidak ada metrik sebelum/sesudah untuk peningkatan produktivitas |
Ketika seseorang meminta Anda membangun X, tanyakan: "Jika saya membangun ini dengan baik, berapa banyak orang lain yang tidak perlu membangunnya sendiri?" Optimalkan untuk angka itu. Sebuah framework yang diadopsi 3 tim mengalahkan fitur yang digunakan 10.000 pengguna.
Keputusan Anda memiliki waktu paruh. Keputusan di Slack dilupakan dalam seminggu. Keputusan yang terdokumentasi bertahan lebih lama dari masa jabatan Anda. Tulislah RFC, ADR, dan memo strategi ā bahkan jika tidak ada yang memintanya. Tindakan menulis memaksa kejelasan, dan artefak tersebut menjadi warisan Anda.
Staff engineer dibayar untuk periferal mereka ā kemampuan untuk melihat masalah yang belum diartikulasikan siapa pun. Ketika Anda berjalan di organisasi, pola apa yang Anda perhatikan? Apa yang sedang diperjuangkan oleh tim yang sudah mereka terima sebagai "memang sudah begini"? Rasa sakit yang diterima itulah peluang Anda.
Simpan daftar berjalan: (a) keputusan yang Anda buat yang membuka blokir tim, (b) alat yang Anda bangun yang diadopsi lintas tim, (c) pola yang Anda tetapkan yang menjadi default. Ukur sebelum/sesudah. Tanpa data, dampak Anda tidak terlihat selama percakapan promosi.
Staff engineering bukanlah promosi ā ini adalah pekerjaan yang berbeda. Anda berhenti menjadi orang yang memiliki jawaban dan mulai menjadi orang yang menciptakan kondisi bagi orang lain untuk menemukan jawaban. Sistem yang Anda bangun, standar yang Anda tetapkan, pola yang Anda buat ā semua itu bertahan lebih lama dari fitur mana pun yang pernah Anda kirimkan. Bangunlah dengan kesadaran itu.
