Belajar Staff Engineer - Scaling Engineering Practices

#Pendahuluan

Setelah di episode 15 kita membangun kerangka metrik untuk keputusan, pada episode ini kita hadapi tantangan yang datang bersama pertumbuhan organisasi: scaling engineering practices. Praktik yang bekerja di satu tim berisi orang hebat — review ketat, standar tinggi, onboarding cepat — otomatis rusak saat jumlah tim naik dari 3 ke 15. Kualitas tak bisa discale dengan menambah polisi; ia harus discale lewat desain sistem kerja.

Tugas staff engineer di sini presisi: cukup standardisasi agar tidak ada pekerjaan ulang dan risiko sia-sia, cukup otonomi agar tim tetap cepat dan merasa memiliki.

#Pilih Model: Dekrit, Konsensus, atau Paved Road

Ada tiga cara menyebarkan praktik lintas tim — masing-masing dengan harga:

Model yang terbukti bekerja di skala besar adalah paved road (istilah Netflix) atau "golden path": kalian membangun jalan yang paling mudah dilalui — template service, pipeline bawaan, library wrapper — sehingga mengikuti standar adalah pilihan malas yang juga pilihan benar. Keluar dari jalur diperbolehkan, asal sadar dan siap menanggung biayanya.

Prinsip desain paved road: jika jalur resmi lebih susah daripada improvisasi, kalian belum selesai membangunnya. Ukur adopsi; adopsi rendah bukan pembuktian tim bandel, melainkan feedback bahwa jalurnya kurang enak.

#Kodifikasi: Standar Harus Hidup di Tooling

Standar yang hidup di dokumen wiki akan terlupa dalam dua sprint. Tiga lapis kodifikasi, dari terkuat ke terlemah:

1. Enforced by machine — linter, formatter, CI gate. Standar ini tidak bisa dilanggar, maka tidak perlu diingat.
2. Scaffolded by template — template proyek baru sudah mengandung struktur folder, konfigurasi observability, health check, dan CI yang benar.
3. Documented for judgment calls — hanya hal-hal yang butuh pertimbangan manusia (trade-off arsitektur) yang layak jadi dokumen panjang.

Aturan alokasi energi kalian: otomatiskan semua yang bisa, templatkan sisanya, dokumentasikan hanya yang tersisa. Dokumen standar 40 halaman biasanya tanda dua lapis pertama belum dibangun.

Contoh gate sederhana yang mengubah budaya:

name: quality-gates
on: pull_request
 
jobs:
  gates:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bun install --frozen-lockfile
      # Standar kode: tidak bisa dilanggar, tak perlu didebat
      - run: bunx biome check .
      # Kontrak API: consumer-driven tests wajib hijau
      - run: bun run test:contracts
      # Coverage gate bertahap per episode 13
      - run: bun run test:coverage --min=60

#Guild, Champions, dan Jaringan Penyebaran

Standar menyebar lewat orang, bukan hanya tooling. Dua struktur ringan yang berhasil:

#Practice Guild

Komunitas lintas tim per bidang (backend, frontend, data) dengan ritme ringan: sesi dua mingguan berganti pembawa topik, katalog keputusan tertulis, dan kanal diskusi async. Aturan sukses guild: tanpa mandat, tanpa KPI — ia forum teknis, bukan komite approval. Staff engineer biasanya menjadi fasilitator awal lalu rotasi kepemimpinannya agar guild tidak jadi dependensi personal.

#Champions Network

Satu engineer per tim menjadi titik kontak praktik (security champion, quality champion). Manfaat ganda: penyebaran standar punya jalur lokal yang dipercaya, dan kalian mendapatkan sensor array untuk mendeteksi masalah lebih awal. Bayarkan loyalitasnya dengan akses awal ke roadmap platform, pelatihan, dan pengakuan publik.

Perhatikan arah panah balik ke paved road: jaringan tanpa loop umpan balik hanya megafon satu arah — dan akan mati karena tak ada yang mendengar mereka.

#Praktik: Program Scaling Praktik 90 Hari

Susun ~/staff-lab/initiatives/practices-program.md:

# Program Scaling Engineering Practices - 90 Hari
 
## Diagnosis singkat
14 tim, 5 varian struktur repo, 4 format review berbeda;
onboarding dev baru rata-rata 6 pekan sampai deploy pertama;
insiden akibat konfigurasi drift 2 kali per bulan.
 
## Target hari ke-90
- 10 dari 14 layanan baru lahir via template golden path.
- Quality gates seragam: lint + contract test + coverage 60%.
- Onboarding: dev baru deploy produksi di hari ke-3.
- Guild backend aktif dengan 8 champions terlatih.
 
## Langkah
Pekan 1-3   : audit variasi + pilih 3 standar dampak terbesar
              (bukan semuanya! urutkan by cost of inconsistency).
Pekan 4-8   : bangun template + gates; pilot 2 tim sukarela.
Pekan 9-12  : workshop champions; rollout bertahap;
              dashboard adopsi publik.
 
## Yang sengaja TIDAK distandardisasi (jaga otonomi)
Framework frontend per produk, pola domain internal,
pemilihan ORM - selama kontrak eksternal terpenuhi.

Bagian yang tidak distandardisasi sama strategisnya dengan bagian "yang tidak kami kerjakan" di episode 6: ia melindungi otonomi dari scope creep standardisasi — dan membuat proposal kalian bisa diterima tim-tim yang waspada.

#Pitfall Umum Scaling Praktik

• Menstandarisasi segalanya — birokrasi seragam membunuh konteks lokal; pilih 3 standar dengan biaya inkonsistensi tertinggi, bukan 30 yang enak didengar.
• Template yang membeku — golden path tanpa pemilik dan rilis berkala berubah menjadi legacy dalam setahun; perlakukan sebagai produk dengan roadmap.
• Compliance theater — checklist ditandatangani tanpa dipahami; kalau kepatuhan hanya formalitas, ukur outcome (insiden, lead time), bukan centang.
• Guild jadi komite veto — begitu guild punya kuasa blokir tanpa legitimasi, tim akan menghindarinya; pegang prinsip advise (masukan dihitung), bukan consent paksa.
• Mengabaikan tim yang menolak dengan alasan baik — kadang penolakan adalah bug report gratis untuk standar kalian; telusuri dulu sebelum menyimpulkan resistensi.

#Penutup

Inti yang harus dibawa pulang:

• Pilih model penyebaran secara sadar: paved road mengalahkan dekrit dan konsensus di skala besar, asal jalurnya benar-benar lebih enak.
• Kodifikasi tiga lapis: enforced by machine, scaffolded by template, documented for judgment — otomatiskan maksimal.
• Guild dan champions menyebarkan standar lewat kepercayaan; jaga loop umpan balik dua arah ke paved road.
• Program 90 hari harus eksplisit soal apa yang TIDAK distandardisasi — otonomi adalah fitur, bukan korban.

Di episode 17 selanjutnya kita akan membahas engineering enablement — dokumentasi, templates, dan program enablement yang membuat seluruh organisasi bekerja lebih cepat, termasuk cara mengukur dampaknya dengan time-to-first-deploy dan metrik onboarding. Sampai jumpa di episode 17!