Belajar Principal Engineer - Cost & Efficiency Programs

#Pendahuluan

Setelah di episode 15 kalian membangun arsitektur keputusan berbasis data — hierarki metrik dan budaya eksperimen — pada episode ini kita terapkan pada domain yang paling cepat mengubah sikap eksekutif terhadap tim engineering: biaya. Cloud bill yang tumbuh lebih cepat dari pendapatan adalah cara paling pasti membuat engineering kehilangan otonominya.

Mengapa ini pekerjaan principal? Karena optimasi biaya satu-off mudah (matikan instance lupa); yang sulit adalah program: sistem di mana ribuan keputusan harian engineer secara alami mempertimbangkan biaya. Itu masalah arsitektur, insentif, dan data — persis ranah kalian.

#Unit Economics: Bahasa Utama

Biaya absolut ("cloud kita $2M/bulan") hampir tidak bisa ditindaklanjuti. Yang bisa adalah biaya per unit nilai:

Unit Nilai	Metrik	Kenapa Berguna
Transaksi sukses	$ per order	Langsung dibanding margin bisnis
Pelanggan aktif	$ per MAU	Terkait model pricing
Request API	$ per juta request	Netral antar produk

Unit economics memberi tiga kemampuan yang tidak dimiliki angka absolut:

Deteksi dini: biaya naik 30% sambil trafik naik 10% terlihat instan di grafik unit — sebelum laporan bulanan mengejutkan CFO.
Perbandingan adil lintas layanan: service A mahal per transaksi, B murah — diskusi jadi tentang efisiensi desain, bukan ukuran tim.
Skalabilitas terlihat: apakah biaya kita sub-linear terhadap pertumbuhan? Itu pertanyaan strategis inti.

#Visibilitas: Alokasi Lintas Tim

Program mati tanpa visibilitas. Fondasinya tagging discipline:

Standar tag resource (contoh)

service: checkout-api        # wajib - pemilik teknis
team: payments               # wajib - pemilik budget
environment: production      # wajib
cost-center: CC-0421         # wajib - sinkron finance
feature: one-click-checkout  # opsional - analitik granular

Dengan tag disiplin, laporan bulanan otomatis menjawab siapa membelanjakan apa; tanpanya, 20-40% biaya jadi "unallocated" dan semua diskusi berubah menjadi tuduhan.

Lapisan kedua: showback lalu chargeback. Mulai dengan showback (tiap team lead melihat biayanya sendiri tiap minggu) — perilaku sering berubah hanya karena angka terlihat. Chargeback (biaya masuk P&L tim) baru setelah data dipercaya.

Tip

Metrik adopsi program ini sederhana: persentase biaya ter-tag. Di bawah 90%, prioritaskan disiplin tagging sebelum program apa pun — mengoptimalkan angka yang tidak bisa dialokasikan sama saja dengan mengoptimalkan kabut.

#Katalog Lever Efisiensi

Susun opsi org kalian dalam dua kelas — jangan campur dalam satu program:

#Quick Wins (hari-mingguan, tanpa ubah arsitektur)

Lever	Dampak Tipikal	Risiko
Rightsizing instance	15-30% compute	Under-provisioning saat puncak
Scheduled shutdown non-prod	20-40% env non-produksi	Gangguan kerja malam
Storage tiering & lifecycle	30-60% storage	Kebutuhan akses jarang
Reserved/savings plan	20-40% baseline stabil	Komitmen kapasitas salah

#Perubahan Struktural (kuartalan, ubah desain sistem)

Lever	Contoh
Konsolidasi duplikat	Tujuh queue → satu platform pesan
Arsitektur data	Cache tiering, pindah analytics dari OLTP
Efisiensi aplikasi	N+1 query massal, payload bengkak
Model harga vendor	Egress strategy, lisensi per-core vs per-use

Quick wins membayar kredibilitas program; perubahan struktural yang menurunkan kurva jangka panjang. Principal yang hanya menawarkan quick wins akan dicap kosmetik oleh CFO tahun depan.

#Ritual Cost Review

Disiplin lahir dari ritual, bukan dari krisis:

100%

Format review bulanan yang bekerja (30 menit, bukan 3 jam):

Tren unit economics utama — 5 menit.
Anomali & unallocated — 5 menit.
Keputusan atas top-3 item: optimasi/invest/terima — 15 menit.
Follow-up keputusan bulan lalu — 5 menit.

Poin empat itulah yang membuat ritual ini program, bukan pertunjukan: keputusan kemarin dicek hasilnya hari ini.

#Praktik: Cost Program

Di workspace kalian:

Hitung satu unit economics nyata: total biaya layanan utama ÷ unit nilainya, trenkan 6 bulan.
Audit tingkat tagging: berapa % biaya ter-tag? Susun rencana mencapai 90%+.
Buat katalog lever org kalian dalam dua kolom (quick win vs struktural) dengan estimasi dampak dan pemilik.
Rancang ritual review 30 menit + template log keputusannya.

Warning

Jangan pernah menjadikan penghematan bulanan sebagai target individu engineer. Hasilnya klasik: infrastruktur under-specified yang meledak jadi insiden SEV-1 — biayanya jauh melampaui penghematan. Biaya adalah properti sistem yang dikelola lewat desain dan ritual, bukan kuota personal.

#Penutup

Inti yang harus dibawa pulang:

Unit economics ($ per transaksi/pelanggan/request) adalah bahasa biaya yang bisa ditindaklanjuti dan mendeteksi inefisiensi dini.
Visibilitas dimulai dari disiplin tagging (target 90%+), lanjut showback sebelum chargeback.
Pisahkan quick wins dari perubahan struktural — keduanya penting, tapi jangan dikira satu sama lain.
Disiplin datang dari ritual review 30 menit dengan follow-up keputusan, bukan dari panik kuartalan.

Di episode 17 selanjutnya kita membahas mergers & technology integration — peran principal saat organisasi bergabung atau mengakuisisi: due diligence teknologi, strategi integrasi absorb/hold/tuck-in, prioritas Day-1 seperti identitas dan data, serta risiko retensi talenta pasca-akuisisi. Sampai jumpa di episode 17!