Apa yang Saya Lakukan sebagai Staff Engineer — Leverage, Standar, dan Dampak di Seluruh Organisasi
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.
Faisal Affan
Apa yang Saya Lakukan sebagai Staff Engineer
"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.
Proposition Staff: Leverage di Atas Output
Pergeseran Inti
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:
- Leverage 1x: Bangun fitur sendiri
- Leverage 10x: Bangun alat yang memungkinkan 10 engineer membangun fitur
- Leverage 100x: Bangun standar yang diadopsi 100 engineer tanpa perlu berpikir
Tahun-tahun staff saya adalah pengejaran tanpa henti terhadap leverage 100x itu. Kadang saya berhasil. Kadang saya meleset. Inilah yang terjadi.
Arsitektur LMS Multi-Tenant
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:
- Domain dan branding white-label
- Feature flags yang dapat dikonfigurasi (jenis penilaian, format kurikulum, skema penilaian)
- Data terisolasi dengan metadata skema bersama
- Otentikasi yang dapat dipasang (LDAP untuk universitas negeri, OAuth untuk swasta)
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.
Metrik Utama
Waktu onboarding: 14 hari → 2 hari per klien
Tim yang terdampak: Satu tim platform menjadi mampu layanan mandiri
Total klien yang dilayani: 100+ universitas
Dynamic Form Engine
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:
- Deklaratif, bukan imperatif — Formulir didefinisikan sebagai skema JSON, bukan kode
- Field yang dapat dikomposisi — 50+ tipe field atomik (teks, angka, tanggal, dropdown, unggahan file, tanda tangan, geolokasi, dll.) yang dapat dikombinasikan ke dalam tata letak apa pun
- Logika bersyarat adalah warga kelas satu — Tampilkan/sembunyikan, aktif/nonaktifkan, dan hitung field berdasarkan nilai sebelumnya, tanpa menulis satu pun pernyataan
if
Adopsinya: 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.
Metrik Utama
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
Jembatan ISO 8583 — Dari Proyek ke Standar
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:
- Connection pooling dan health check untuk sesi mainframe
- Definisi pesan sebagai konfigurasi (bukan offset field yang di-hardcode)
- Pola retry, timeout, dan circuit breaker bawaan yang spesifik untuk protokol keuangan
- Integration test harness yang mensimulasikan mainframe bank
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.
Metrik Utama
Pembangunan awal: 4 minggu untuk mitra pertama
Integrasi berikutnya: 3-5 hari per mitra
Adopsi: Standar di seluruh organisasi untuk semua integrasi bank
Apa yang Tidak Saya Lakukan dengan Baik
Tidak ada retrospeksi jujur yang melewatkan penyesalan. Inilah penyesalan saya.
Papan Skor Staff Saya
| 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 |
Saran untuk Calon Staff Engineer
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.