Belajar Principal Engineer - Scope & Org Impact

#Pendahuluan

Setelah di episode 1 kita mendefinisikan peran principal — penentu arah teknis organisasi dengan horizon multi-tahun — pada episode ini kita membahas pertanyaan paling praktis yang mengikuti definisi itu: scope kalian apa persisnya?

Mengapa ini kritis? Karena principal adalah peran tanpa otoritas formal atas siapa pun. Satu-satunya hal yang melindungi waktu dan fokus kalian adalah kesepakatan eksplisit tentang scope. Tanpa itu, kalian akan tersedot menjadi "senior on-call untuk semua masalah" — dipanggil ke mana-mana, memengaruhi tidak ke mana-mana. Dengan scope yang jelas, org tahu kapan harus melibatkan kalian dan kapan tidak.

#Anatomi Scope Org-Wide

Scope principal dibaca sebagai tiga lapisan yang semakin luas:

100%

Prinsip pembagian kerjanya:

Lapisan	Pemilik Utama	Peran Principal
Fitur & service satu tim	Senior/staff engineer	Menasihati saat diminta atau saat risiko tinggi
Desain lintas domain	Staff engineer	Mengangkat pola berulang jadi standar
Arsitektur & standar org	Principal	Memiliki keputusan, menulis standar, menjaga kohesi
Strategi teknis bisnis	Principal + VP Eng/CTO	Menerjemahkan strategi bisnis ke arah teknis

Aturan praktisnya: kalian memiliki masalah yang sama berulang di banyak tim. Jika lima tim membangun lima sistem otorisasi, itu bukan pekerjaan tim mana pun — itu milik kalian.

#Area Ownership Inti

Tiga area yang hampir selalu ada dalam scope principal modern:

#1. Architecture

Kohesi arsitektur org-wide: batas antar sistem, kontrak API lintas tim, pilihan teknologi strategis, dan keputusan build vs buy. Kalian bukan yang merancang semua — kalian yang memastikan rancangan-rancangan itu saling cocok.

#2. Platform

Infrastruktur bersama yang semua tim pakai: internal developer platform, pipeline deployment, observability, tooling. Platform adalah cara pengaruh kalian terkemas jadi produk — topik penuh di episode 7.

#3. AI

Arah adopsi AI organisasi: use case mana yang layak, model/tool apa yang distandarkan, data apa yang boleh dipakai. Di 2026 area ini paling cepat berubah dan paling sering diminta board — kita bedah di episode 21.

Tip

Uji kepemilikan yang sederhana: untuk setiap area, jawab "siapa yang dipanggil orang saat ada keputusan sulit di sini?" Jika jawabannya nama kalian untuk arsitektur, platform, dan AI di level org — scope kalian sehat.

#Menulis Scope Statement

Scope yang hidup di kepala orang tidak berguna. Tulis satu dokumen setengah halaman, sepakati dengan manajer kalian, dan publikasikan. Templatnya:

vision/scope-statement.md

# Scope Statement - [Nama], Principal Engineer
 
## Misi
Memastikan keputusan teknis [org] saling kohesif dan mendukung
strategi bisnis [arah bisnis utama].
 
## Area Kepemilikan
- Arsitektur org-wide: batas sistem, kontrak API, standar teknologi.
- Platform: roadmap IDP, DX metrics, golden paths.
- AI: use case portfolio, governance, standardisasi tooling.
 
## Cara Kerja
- Keputusan besar lewat RFC + ARB (SLA review 5 hari kerja).
- Konsultasi desain: slot mingguan, prioritaskan risiko tinggi.
- Eskalasi: [nama VP] saat keputusan menyentuh budget/timeline.
 
## Di Luar Scope Saya
- Eksekusi harian proyek tim (milik staff/EM).
- Penugasan orang & performance review (milik EM).
- Keputusan produk (milik PM).
 
## Metrik Sukses
- Deployment frequency org naik, change failure rate turun.
- Biaya cloud per unit transaksi stabil/turun.
- Waktu onboarding engineer baru: target 5 hari ke PR pertama.

Bagian Di Luar Scope Saya sama pentingnya dengan bagian kepemilikan. Ia adalah izin tertulis untuk berkata "itu bukan pekerjaan saya" tanpa terlihat enggan.

#Praktik: Definisikan Scope Kalian

Lakukan sekarang, di workspace ~/principal-lab kalian:

Petakan realita tiga bulan terakhir — daftar semua permintaan masuk ke kalian, kelompokkan per area (arsitektur/platform/AI/eksekusi tim/lain-lain). Angka yang mengejutkan biasanya: 40%+ waktunya habis di "lain-lain".
Pilih dua sampai tiga area kepemilikan — lebih sedikit dari itu berarti underutilized; lebih banyak berarti tidak akan serius dijalankan.
Tulis scope statement dengan templat di atas, review bersama manajer kalian.
Publikasikan ke wiki org dan bahas di forum engineering — scope hanya bekerja jika diketahui.

Warning

Scope creep pada principal jarang datang dari tugas baru; ia datang dari ketidakmampuan berkata tidak pada eskalasi lama. Setiap kali kalian mengerjakan sesuatu di luar scope lebih dari satu hari, catat di portofolio — lalu tanyakan pada diri sendiri apakah scope statement perlu direvisi atau kebiasaan berkata tidak perlu diperbaiki.

#Tabrakan Scope yang Umum

Tiga titik rawan dan cara meredanya:

Tabrakan	Gejala	Mitigasi
Dengan EM	Kalian "menyarankan" cara kerja tim	Selalu lewat staff engineer tim, bukan langsung ke engineer
Dengan Director/VP	Kalian terdengar seperti menetapkan prioritas	Frame sebagai opsi + dampak biaya/risiko, keputusan tetap milik mereka
Dengan Staff Engineer	Kalian mengambil desain yang seharusnya jadi kesempatan tumbuh mereka	Review dan tantang, jangan tulis ulang

Perhatikan polanya: principal yang baik bekerja melalui struktur org, bukan menggantinya. Pengaruh kalian justru terukur dari seberapa banyak keputusan benar lahir di orang lain karena kalian.

#Penutup

Inti yang harus dibawa pulang:

Scope principal = org/company-wide, dengan area inti arsitektur, platform, dan AI.
Kepemilikan didefinisikan oleh pertanyaan "siapa yang dipanggil saat keputusan sulit?" — pastikan jawabannya kalian, secara tertulis.
Scope statement setengah halaman, termasuk bagian "di luar scope saya", disepakati dengan manajer dan dipublikasikan.
Tabrakan dengan EM/director/staff diredakan dengan bekerja melalui struktur, bukan menggantinya.

Di episode 3 selanjutnya kita masuk fase inti peran ini: technical vision — cara membuat visi teknis org/company yang menjawab "ke mana kita menuju dalam 3 tahun", anatomi vision doc, dan teknik menciptakan alignment sebelum dokumen diumumkan. Sampai jumpa di episode 3!