VP Engineering, EM dan PM — Kolaborasi yang Benar

Tiga peran ini ada di hampir setiap tim engineering yang tumbuh melewati fase startup awal, tapi cara mereka bekerja bersama sering kali tidak pernah didefinisikan secara eksplisit. Akibatnya, konflik muncul bukan karena orangnya buruk, melainkan karena tidak ada kesepakatan tentang siapa yang memutuskan apa, dan kapan satu peran boleh memasuki wilayah peran yang lain. Artikel ini membahas struktur kolaborasi yang sehat antara VP Engineering, Engineering Manager (EM), dan Product Manager (PM) — mulai dari definisi peran, bagaimana sebuah project seharusnya mengalir dari inisiasi hingga delivery, disfungsi yang paling merusak, hingga bagaimana mendiagnosis bahwa sesuatu tidak berjalan dengan benar sebelum terlambat.

Tiga Peran, Tiga Orientasi

Sebelum membahas bagaimana ketiganya berkolaborasi, penting untuk memahami bahwa masing-masing peran punya orientasi yang berbeda — dan perbedaan ini bukan kelemahan, melainkan desain yang disengaja.

VP Engineering memastikan tim punya kondisi terbaik untuk berhasil. EM memastikan tim deliver dengan sehat dan tumbuh sebagai engineer. PM memastikan tim membangun hal yang benar pada waktu yang tepat.

Ketiganya bisa gagal sendirian, tapi hanya bisa berhasil bersama-sama.

Gambaran posisi dalam org:

VP Engineering
├── EM
│   └── Engineers
└── PM  ← dalam setup di mana PM masuk ke org engineering

Setup di mana PM berada di bawah VP Engineering (bukan di bawah VP Product terpisah) adalah pola yang sangat umum di perusahaan yang belum punya divisi product tersendiri. Artikel ini menggunakan setup ini sebagai konteks utama.

Peran VP Engineering yang Sering Disalahpahami

VP Engineering bukan “senior engineer yang punya jabatan lebih tinggi.” Ini adalah peran yang secara fundamental berbeda dari engineering — dan justru karena perbedaan ini, banyak VP Engineering yang baru naik jabatan mengalami kesulitan dalam transisi.

Dari Teknis ke Sistemik

Seorang engineer yang hebat menyelesaikan masalah teknis. VP Engineering menyelesaikan masalah sistemik — mengapa tim terus menghadapi masalah yang sama, mengapa velocity menurun setiap quarter, mengapa engineer terbaik meninggalkan tim dalam 18 bulan pertama.

ANTI-PATTERN: VP Engineering sebagai problem-solver teknis

VP Engineering menerima laporan bahwa ada bug production serius.
Reaksi: langsung buka kode, analisis root cause, perbaiki sendiri.

BENAR: VP Engineering sebagai problem-solver sistemik

VP Engineering menerima laporan yang sama.
Reaksi: tanya EM — "ini terjadi pertama kali atau ada pola?",
         tanya PM — "apakah ada tekanan timeline yang menyebabkan
         testing terpotong?", kemudian putuskan intervensi sistemik:
         tambah coverage threshold di CI, atau review sprint planning.

Perbedaannya bukan pada hasilnya (bug tetap diperbaiki), tapi pada apa yang berubah setelah itu. VP Engineering yang mengerjakan langsung tidak menciptakan perbaikan sistemik — hanya perbaikan insidental.

Sebagai Buffer antara Bisnis dan Tim

Salah satu fungsi VP Engineering yang paling kritis adalah menyerap tekanan dari atas sebelum sampai ke tim. Ketika CEO atau stakeholder bisnis meminta sesuatu yang tidak realistis, VP Engineering adalah lapisan pertama yang harus bisa mendebat, menegosiasikan scope, atau menunda dengan alasan yang bisa diterima.

ANTI-PATTERN: tekanan diteruskan mentah-mentah

CEO: "Kita butuh fitur X selesai minggu depan."
VP Engineering ke EM: "CEO minta X selesai minggu depan."
EM ke tim: "Ada request urgent dari atas..."

Hasilnya: tim panik, kualitas turun, orang lembur tanpa konteks.

BENAR: VP Engineering sebagai buffer

CEO: "Kita butuh fitur X selesai minggu depan."
VP Engineering: "Oke, saya perlu cek dengan tim dulu. Apa yang
                 paling kritis dari X — bisa kita identifikasi
                 MVP-nya dulu?"

[VP Engineering berdiskusi dengan EM dan PM, lalu kembali ke CEO]

VP Engineering: "Kita bisa deliver core X dalam 2 minggu dengan
                 scope yang dikurangi di bagian ini. Kalau perlu
                 full X, realistisnya 4 minggu."

Tanpa buffer ini, tim hidup dalam kondisi reaktif permanen — tidak pernah punya ruang untuk berpikir, merencanakan, atau membangun dengan benar.

Mendelegasikan, Bukan Mengerjakan

VP Engineering yang baik punya rasa ingin tahu teknis yang tinggi, tapi tahu kapan harus menahan diri. Ketika EM sedang memimpin diskusi teknis dengan tim, VP Engineering yang tiba-tiba masuk dan mendominasi percakapan — meskipun dengan niat baik — melemahkan otoritas EM di depan timnya.

ANTI-PATTERN: VP Engineering micromanage EM

Sprint planning sedang berjalan. VP Engineering masuk ke meeting,
mengomentari estimasi engineer satu per satu, mengubah prioritas
task secara langsung, dan menyimpulkan meeting.

Akibat: EM terlihat tidak punya otoritas. Engineer bingung
        harus mendengarkan siapa. EM mulai kehilangan rasa
        ownership terhadap timnya sendiri.

BENAR: VP Engineering memberi ruang ke EM

VP Engineering hadir di sprint planning hanya saat diundang,
atau untuk memberikan konteks strategis di awal ("prioritas
Q3 adalah X karena Y"), kemudian keluar.

Kalau ada concern, VP Engineering menyampaikannya ke EM
secara private — bukan di depan tim.

Peran EM yang Lebih dari Sekedar “Manager”

EM sering digambarkan sebagai “orang yang mengurus orang” — ini tidak salah, tapi terlalu sempit. EM adalah titik konvergensi antara sisi manusia (engineer) dan sisi eksekusi (delivery). Tanpa EM yang kuat, gap antara “apa yang dijanjikan PM” dan “apa yang bisa didelivery tim” tidak akan pernah terkelola dengan baik.

Penjaga Kapasitas dan Ritme Tim

EM tahu persis siapa di timnya yang sedang overload, siapa yang sedang belajar teknologi baru, siapa yang lagi ada masalah personal yang memengaruhi performa. Pengetahuan ini tidak bisa diperoleh dari sprint board atau daily standup saja — ini hasil dari investasi hubungan yang konsisten.

Karena itu, ketika PM datang dengan request baru, EM adalah satu-satunya orang yang bisa memberikan estimasi yang kredibel — bukan berdasarkan “seharusnya bisa berapa lama” secara teoritis, tapi berdasarkan “dengan tim dan kondisi saat ini, realistisnya berapa lama.”

Gatekeeper Kualitas Teknis

EM bertanggung jawab atas standar teknis dalam timnya — bukan hanya delivery. Code review culture, test coverage, pengelolaan technical debt, dokumentasi internal — semua ini berada di bawah perhatian EM. PM tidak bisa dan tidak seharusnya masuk ke wilayah ini.

ANTI-PATTERN: PM menekan EM untuk skip kualitas demi kecepatan

PM: "Fitur ini harus selesai Sprint ini. Testing bisa nanti kan?"

BENAR: EM mempertahankan standar sambil tetap bernegosiasi scope

EM: "Kalau kita skip testing sekarang, kita akan spend 2x waktu
     itu untuk fix bug di Sprint berikutnya. Saya bisa suggest
     kita cut fitur Z dari scope Sprint ini supaya testing tetap
     ada untuk fitur yang paling kritis."

Eskalasi yang Tepat ke VP Engineering

EM harus tahu dengan baik kapan harus menangani sesuatu sendiri dan kapan harus membawa ke VP Engineering. Eskalasi yang terlalu sering membuat VP Engineering tidak bisa fokus pada hal strategis. Eskalasi yang terlalu jarang membuat masalah menumpuk tanpa ada yang tahu.

Eskalasi ke VP Engineering diperlukan ketika:
  ✓ Keputusan berdampak pada arsitektur lintas tim
  ✓ Ada konflik dengan PM yang tidak bisa diselesaikan berdua
  ✓ Ada kebutuhan resource atau hiring yang melampaui authority EM
  ✓ Ada isu performa engineer yang sudah melewati PIP tahap awal
  ✓ Ada perubahan scope yang mengancam komitmen ke stakeholder

Tangani sendiri tanpa eskalasi ketika:
  ✗ Bug production yang ada owner-nya
  ✗ Konflik kecil antar engineer
  ✗ Perubahan prioritas task dalam satu sprint
  ✗ Keterlambatan deliverable yang masih dalam margin wajar

Peran PM dalam Org Engineering

Ketika PM berada di bawah VP Engineering (bukan VP Product tersendiri), dinamikanya berbeda dari setup dua-divisi klasik. PM bukan dari “sisi produk” yang independen — mereka bagian dari org engineering, tapi dengan tanggung jawab yang secara inheren menghadap ke kebutuhan user dan bisnis.

PM Membawa Masalah, Bukan Solusi

Ini adalah prinsip yang paling sering dilanggar dan paling merusak. Ketika PM datang ke tim dengan solusi yang sudah jadi (“kita perlu pakai WebSocket”), tim engineering kehilangan kesempatan untuk menawarkan solusi yang mungkin lebih baik secara teknis dan lebih efisien secara resources.

ANTI-PATTERN: PM datang dengan solusi

PM ke EM: "Kita butuh implementasi WebSocket untuk notifikasi real-time.
           Saya sudah research ini dan ini yang paling tepat."

Masalah: PM menutup ruang diskusi teknis. EM tidak tahu
         apakah ini sudah dipertimbangkan vs polling, SSE,
         atau solusi yang lebih sederhana untuk skala saat ini.

BENAR: PM datang dengan masalah

PM ke EM: "User complain mereka tidak tahu kalau ada aktivitas baru
           yang relevan. Data kita menunjukkan 40% user tidak balik
           setelah hari pertama. Kita perlu solusi notifikasi yang
           bisa mengurangi angka ini."

Hasilnya: EM dan tim bisa propose solusi yang mempertimbangkan
          constraint teknis yang PM mungkin tidak tahu.

Acceptance Criteria adalah Tanggung Jawab PM

PM mendefinisikan apa artinya “selesai” — secara fungsional, bukan teknis. Acceptance criteria yang baik memungkinkan engineer dan EM bekerja tanpa harus terus bertanya ke PM untuk setiap keputusan kecil.

Acceptance criteria yang buruk adalah sumber paling umum dari rework dan keterlambatan delivery.

Acceptance criteria yang buruk:
  ✗ "Fitur notifikasi sudah berjalan dengan baik"
  ✗ "User bisa melihat notifikasi"

Acceptance criteria yang baik:
  ✓ User menerima notifikasi dalam maksimal 30 detik setelah event terjadi
  ✓ Notifikasi muncul di in-app notification center
  ✓ User bisa mark notifikasi sebagai sudah dibaca
  ✓ Notifikasi yang sudah dibaca tidak muncul lagi di unread count
  ✓ Sistem tidak crash ketika ada lebih dari 100 notifikasi belum dibaca

PM Tidak Bypass EM

Ini cukup penting sampai perlu dibahas secara terpisah. Ketika PM langsung mendatangi engineer untuk meminta sesuatu — bahkan sesuatu yang kecil — tanpa lewat EM, akibatnya tidak kecil.

flowchart TD
    A[PM bypass EM, langsung ke Engineer] --> B[Engineer punya dua 'bos' de facto]
    A --> C[EM kehilangan visibilitas kapasitas tim]
    A --> D[Komitmen informal terbentuk tanpa sepengetahuan EM]
    B --> E[Engineer bingung, memilih yang paling vocal]
    C --> F[Sprint planning tidak akurat]
    D --> F
    F --> G[Velocity turun, delivery meleset]
    G --> H[EM disalahkan atas masalah yang diciptakan pola komunikasi salah]
    E --> I[Otoritas EM tererosi di depan timnya sendiri]
    I --> J[EM kehilangan ownership, performa menurun]
    J --> H

Masalah terbesarnya bukan keterlambatan delivery — tapi erosi otoritas EM yang terjadi secara perlahan dan baru terasa ketika sudah parah. Dan pada titik itu, memperbaikinya jauh lebih mahal daripada mencegahnya sejak awal.

Flow Project yang Sehat

Dengan pemahaman peran masing-masing, berikut adalah bagaimana sebuah project seharusnya mengalir dari inisiasi hingga launch.

sequenceDiagram
    participant BIS as Bisnis / CEO
    participant VPE as VP Engineering
    participant PM as PM
    participant EM as EM
    participant ENG as Engineers

    BIS->>VPE: Request / inisiasi project baru
    VPE->>PM: Delegasi: validasi problem dan buat brief
    PM->>PM: User research, analisis data, competitive check
    PM->>VPE: Problem brief + hipotesis solusi
    VPE->>EM: Libatkan EM untuk feasibility awal
    EM->>VPE: Input teknis: constraint, dependency, risiko
    VPE->>PM: Align scope dan ekspektasi
    PM->>EM: Requirements + acceptance criteria
    EM->>ENG: Technical planning, breakdown task
    ENG->>EM: Estimasi dan feedback teknis
    EM->>PM: Negosiasi scope vs kapasitas
    PM->>EM: Scope final yang disepakati
    EM->>ENG: Sprint dimulai
    PM->>ENG: Jawab pertanyaan requirement (lewat EM jika struktural)
    ENG->>EM: Progress update, blockers
    EM->>VPE: Eskalasi jika ada isu lintas boundary
    VPE->>BIS: Update stakeholder, protect tim dari interupsi
    EM->>PM: Delivery untuk review
    PM->>EM: Acceptance / feedback
    EM->>ENG: Retrospektif internal
    VPE->>VPE: Analisis pola sistemik dari retrospektif

Tahap 1: Inisiasi (VP Engineering + PM)

Request masuk ke VP Engineering — dari CEO, dari data, atau dari PM sendiri yang mengidentifikasi opportunity. VP Engineering tidak langsung melibatkan EM. Dulu align dengan PM dulu: apakah problem statement sudah cukup jelas? Apa success metric-nya? Ini layak dibangun sekarang atau bisa ditunda?

Melibatkan EM terlalu awal, sebelum ada problem brief yang solid, hanya membuang kapasitas berpikir EM untuk sesuatu yang mungkin tidak jadi dikerjakan.

Tahap 2: Problem Brief (PM memimpin)

PM mengeksplor masalah: user interview, analisis data, benchmark kompetitor. Output yang dihasilkan adalah problem brief — dokumen ringkas yang menjawab: apa masalahnya, siapa yang terpengaruh, seberapa besar dampaknya, dan apa yang terjadi kalau kita tidak memecahkannya.

PM membawa brief ini ke VP Engineering untuk dikonfirmasi. VP Engineering memutuskan: lanjut ke planning atau tidak.

Tahap 3: Alignment Triad (VP Engineering, EM, PM)

Ini adalah satu-satunya tahap di mana ketiganya harus duduk bersama. EM dibawa masuk untuk memberikan perspektif teknis: apakah feasible? Ada dependency ke sistem lain? Berapa estimasi kasar di level tim saat ini?

Negosiasi yang sehat terjadi di sini:

PM:  "User butuh notifikasi real-time, bisa push dan in-app."
EM:  "Real-time dengan skala 500k user itu berat — WebSocket atau
      polling? Ini bisa makan 6 minggu dengan tim kita sekarang."
VPE: "6 minggu terlalu lama untuk window Q3. Apa yang bisa kita cut?"
PM:  "In-app saja dulu, push notification fase 2 — acceptable?"
EM:  "In-app dengan polling tiap 30 detik? 2 minggu."
VPE: "Deal. Dokumentasikan trade-off-nya, kita revisit push di Q4."

Hasil dari tahap ini: scope disepakati, timeline dikunci, trade-off didokumentasikan. Tidak ada yang bisa unilateral mengubah ini setelahnya tanpa diskusi ulang.

Tahap 4: Planning (EM memimpin, PM mendampingi)

EM menerjemahkan requirements ke technical plan: arsitektur, pembagian task, sprint breakdown. PM memastikan urutan prioritas di plan ini konsisten dengan business priority yang sudah disepakati. PM juga finalisasi acceptance criteria untuk setiap deliverable.

VP Engineering tidak perlu hadir di tahap ini kecuali ada keputusan yang memerlukan authority-nya.

Tahap 5: Eksekusi (EM memimpin)

Tim engineering build. PM aktif menjawab pertanyaan requirement yang muncul — karena selalu ada ambiguitas yang baru terlihat setelah coding dimulai. Tapi pertanyaan struktural (yang memengaruhi scope atau kapasitas) tetap harus lewat EM.

EM melindungi tim dari scope creep. Kalau PM ingin menambah sesuatu di tengah sprint, EM yang pertama merespons: “Bisa, tapi kita perlu diskusi impact ke timeline dan apa yang di-drop sebagai gantinya.”

VP Engineering di tahap ini hadir dalam kapasitas minimal tapi konsisten:

• 1-on-1 dengan EM: coaching, remove blockers yang EM tidak bisa atasi sendiri
• Skip-level sesekali dengan engineer: bukan untuk micromanage, tapi untuk pulse check
• Stakeholder management: melindungi tim dari interupsi mendadak dari atas

Tahap 6: Review dan Retrospektif

PM melakukan product review — apakah output sesuai acceptance criteria? EM memimpin retrospektif internal tim. VP Engineering membaca hasil retrospektif dan mencari pola sistemik yang perlu diintervensi di level org.

Ketika VP Product Tidak Ada

Setup tanpa VP Product — di mana PM berada di bawah VP Engineering — menciptakan vakum di sisi “what dan why” yang strategis. Vakum ini tidak hilang; ia hanya perlu diisi secara eksplisit.

flowchart TD
    A{Ada VP Product?} -- Ya --> B[VP Product pegang strategi produk]
    A -- Tidak --> C{Siapa yang mengisi vakum?}
    C --> D[VP Engineering naik peran]
    C --> E[PM senior yang lebih mandiri]
    C --> F[CEO langsung terlibat]
    D --> G[VP Engineering duduk di business conversation]
    D --> H[VP Engineering menjadi translator teknis ke bisnis]
    E --> I[PM punya akses langsung ke leadership]
    E --> J[Risiko: keputusan terlalu reaktif tanpa filter strategis]
    F --> K[Kecepatan tinggi]
    F --> L[Risiko: inkonsistensi arah roadmap]

Tiga risiko utama yang harus diantisipasi secara eksplisit ketika tidak ada VP Product:

Roadmap jadi reaktif. Tidak ada yang secara struktural menjaga visi jangka panjang produk. VP Engineering perlu mengalokasikan waktu secara eksplisit untuk ini — misalnya sesi roadmap review bulanan bersama PM dan CEO, di mana keputusan prioritas jangka panjang dikunci dan didokumentasikan.

PM kelelahan. PM tanpa “atasan produk” akan menerima tekanan dari semua arah — bisnis, engineering, dan user — tanpa ada yang memfilter. VP Engineering perlu sadar ini dan aktif membantu PM memprioritaskan, bukan hanya menerima semua request yang masuk.

Technical debt tidak punya advocate di sisi bisnis. Biasanya VP Product yang membantu menjelaskan ke stakeholder mengapa investasi teknis perlu dilakukan. Tanpa mereka, VP Engineering harus bisa menerjemahkan kebutuhan teknis ke bahasa bisnis — dan ini adalah skill yang tidak semua VP Engineering miliki secara natural.

1. Definisikan Batas Wewenang secara Eksplisit

Paling banyak konflik antar peran terjadi bukan karena orangnya tidak kompeten, tapi karena tidak pernah ada kesepakatan tertulis tentang siapa memutuskan apa.

ANTI-PATTERN: batas wewenang dibiarkan implisit

"Semua orang sudah dewasa, pasti tahu batas masing-masing."

Akibat: PM mengambil keputusan teknis karena merasa tidak ada
        yang melarang. EM menolak requirement karena merasa itu
        bukan wilayahnya. VP Engineering override keputusan EM
        tanpa tahu bahwa EM sudah punya alasan kuat di baliknya.

BENAR: batas wewenang ditulis dan dikomunikasikan

Contoh working agreement sederhana:

PM memutuskan: prioritas fitur, scope MVP, acceptance criteria,
               kapan launch dari sisi produk.

EM memutuskan: estimasi teknis, kapasitas sprint, pembagian task,
               standar code quality, siapa mengerjakan apa.

VP Engineering memutuskan: arah teknis jangka panjang, hiring,
                            standar arsitektur, eskalasi ke atas,
                            keputusan yang melampaui satu tim.

2. Pisahkan “Request” dari “Keputusan”

PM boleh punya request ke engineering — ini normal dan seharusnya terjadi. Yang tidak boleh adalah PM membuat keputusan teknis unilateral, atau EM membuat keputusan scope unilateral.

Request yang sah dari PM ke EM:
  ✓ "Apakah kita bisa selesaikan ini dalam Sprint ini?"
  ✓ "Apa opsi teknis yang kita punya untuk masalah ini?"
  ✓ "Kalau kita harus potong scope, bagian mana yang paling kecil
      impact teknisnya?"

Keputusan yang bukan wewenang PM:
  ✗ "Kita akan pakai database X untuk fitur ini."
  ✗ "Engineer A yang akan mengerjakan task ini."
  ✗ "Testing bisa skip untuk release ini."

Request yang sah dari EM ke PM:
  ✓ "Dari dua fitur ini, mana yang lebih penting untuk user?"
  ✓ "Apa yang terjadi di sisi bisnis kalau ini kita tunda 1 Sprint?"
  ✓ "Acceptance criteria untuk edge case ini apa?"

Keputusan yang bukan wewenang EM:
  ✗ "Fitur ini tidak perlu dibangun."
  ✗ "Kita launch ketika tim merasa siap."
  ✗ "Scope ini terlalu besar, saya cut separuhnya."

3. Jadikan Eskalasi sebagai Proses, Bukan Kelemahan

Di banyak tim, eskalasi dianggap sebagai tanda bahwa seseorang tidak mampu menyelesaikan masalahnya sendiri. Ini adalah budaya yang salah dan akhirnya menyebabkan masalah kecil dibiarkan membesar.

flowchart TD
    A[Konflik atau keputusan sulit muncul] --> B{Bisa diselesaikan di level ini?}
    B -- Ya --> C[Selesaikan, dokumentasikan keputusan]
    B -- Tidak --> D{Siapa yang harus eskalasi?}
    D -- Konflik PM dan EM --> E[Bawa ke VP Engineering bersama-sama]
    D -- Isu kapasitas besar --> F[EM eskalasi ke VP Engineering]
    D -- Isu strategis produk --> G[PM eskalasi ke VP Engineering]
    E --> H[VP Engineering fasilitasi, bukan memutuskan sepihak]
    F --> H
    G --> H
    H --> I[Keputusan didokumentasikan dan dikomunikasikan ke tim]

VP Engineering yang baik tidak membuat eskalasi terasa seperti hukuman. Ketika EM atau PM membawa konflik, VP Engineering memfasilitasi resolusi — bukan mengambil alih keputusan dan memberikan jawaban final tanpa mendengar semua sisi.

4. Retrospektif Bukan Hanya untuk Tim Engineering

Pola disfungsi antar peran hampir tidak pernah muncul di daily standup atau sprint review. Mereka muncul di retrospektif — tapi hanya kalau retrospektifnya melibatkan semua pihak yang relevan.

ANTI-PATTERN: retrospektif hanya untuk engineer

EM memimpin retrospektif. PM tidak diundang. VP Engineering tidak tahu
hasilnya. Masalah kolaborasi dibicarakan di antara engineer, tapi tidak
pernah sampai ke pihak yang bisa mengubahnya.

BENAR: retrospektif dengan representasi yang tepat

Sprint retrospektif internal (EM + Engineers):
- Fokus: proses teknis, team dynamics, tech debt yang harus diatasi

Retrospektif kolaborasi (EM + PM, sekali sebulan):
- Fokus: bagaimana kerja sama berjalan, apa yang perlu diubah

Retrospektif strategis (VP Engineering + EM + PM, per quarter):
- Fokus: apakah cara kerja kita masih sesuai dengan skala dan
         kompleksitas yang terus bertumbuh?

Anti-Pattern yang Harus Dihindari

// ✗ PM bypass EM, langsung ke engineer
PM meminta engineer langsung untuk mengerjakan sesuatu tanpa
sepengetahuan EM. Engineer mengiyakan karena tidak enak menolak.
EM kehilangan visibilitas. Sprint planning tidak akurat.
// ✓ Semua request ke engineer harus lewat EM, bahkan untuk hal kecil.

// ✗ EM menolak requirement secara sepihak
EM memutuskan bahwa requirement PM tidak layak dikerjakan dan
menginformasikan keputusan ini langsung ke engineer tanpa berdiskusi
dulu dengan PM.
// ✓ Keberatan teknis disampaikan ke PM sebagai input, bukan keputusan final.
   Kalau tidak bisa resolve berdua, eskalasi ke VP Engineering bersama.

// ✗ VP Engineering terlalu dalam di detail teknis sehari-hari
VP Engineering hadir di code review, mengomentari implementasi spesifik,
dan mendominasi diskusi teknis yang seharusnya dipimpin EM.
// ✓ VP Engineering set standar dan guardrail, lalu beri EM ruang untuk
   mengelola detail teknisnya sendiri.

// ✗ VP Engineering tidak memberikan konteks strategis ke EM dan PM
EM dan PM mengeksekusi tanpa tahu mengapa sesuatu diprioritaskan,
apa yang sedang terjadi di level bisnis, atau ke mana arah tim dalam
6 bulan ke depan.
// ✓ VP Engineering secara rutin sharing konteks strategis — bukan hanya
   keputusan, tapi alasan di baliknya.

// ✗ PM memberikan solusi teknis, bukan masalah bisnis
PM datang dengan spesifikasi teknis yang sudah jadi dan meminta
engineering mengimplementasikannya persis seperti yang sudah
didesain PM.
// ✓ PM membawa problem statement dan outcome yang diinginkan, lalu
   biarkan EM dan tim mencari solusi teknis terbaiknya.

// ✗ Batas wewenang tidak pernah didefinisikan
Semua orang bekerja berdasarkan asumsi tentang apa yang boleh dan
tidak boleh mereka putuskan, dan asumsi masing-masing tidak konsisten.
// ✓ Buat working agreement sederhana yang mendefinisikan domain
   keputusan masing-masing peran, dan review setiap 6 bulan.

Checklist Review Struktur Kolaborasi Tim

KEJELASAN PERAN:
  □ Ada working agreement tertulis tentang domain keputusan masing-masing peran
  □ Semua anggota tim (termasuk engineer) tahu harus ke siapa untuk jenis request berbeda
  □ VP Engineering, EM, dan PM bisa menjelaskan perbedaan perannya tanpa kebingungan

FLOW KOMUNIKASI:
  □ Semua request ke engineer melewati EM terlebih dahulu
  □ PM tidak membuat keputusan teknis unilateral
  □ EM tidak menolak requirement tanpa diskusi dengan PM
  □ VP Engineering tidak override keputusan EM di depan tim

RITME KOLABORASI:
  □ Ada sesi alignment reguler antara EM dan PM (minimal per sprint)
  □ VP Engineering punya 1-on-1 rutin dengan EM
  □ Ada retrospektif kolaborasi EM-PM minimal sekali sebulan
  □ Ada review strategis VP Engineering + EM + PM per quarter

INISIASI PROJECT:
  □ Project baru dimulai dengan problem brief dari PM, bukan solusi
  □ EM dilibatkan setelah problem brief solid, bukan sebelum
  □ Scope, timeline, dan trade-off didokumentasikan sebelum eksekusi dimulai
  □ Acceptance criteria tersedia sebelum engineering mulai coding

TANDA BAHAYA — SEGERA TINDAKLANJUTI JIKA:
  □ Engineer tidak tahu harus mendengarkan siapa
  □ EM selalu dalam kondisi "catching up" terhadap apa yang sudah dijanjikan timnya
  □ Sprint velocity tidak bisa diprediksi dan tidak ada yang tahu kenapa
  □ EM resign atau menunjukkan tanda-tanda disengagement yang signifikan
  □ PM mengeluh engineering tidak responsif; EM mengeluh PM tidak bisa diprediksi

Ringkasan

• VP Engineering, EM, dan PM punya orientasi berbeda yang saling melengkapi — VP Engineering ke atas dan ke luar, EM ke dalam tim, PM ke produk dan bisnis. Perbedaan ini adalah desain, bukan sumber konflik.
• VP Engineering berfungsi sebagai buffer, bukan problem-solver teknis — tugasnya melindungi tim dari tekanan atas, memberikan konteks strategis, dan menyelesaikan masalah sistemik, bukan masalah teknis individual.
• EM adalah satu-satunya yang tahu kapasitas tim secara akurat — estimasi yang valid hanya bisa datang dari EM, bukan dari PM atau VP Engineering yang tidak punya visibilitas ke kondisi aktual tim.
• PM membawa masalah, bukan solusi teknis — problem statement yang baik membuka ruang untuk solusi terbaik; spesifikasi teknis dari PM menutup ruang itu.
• Semua request ke engineer harus lewat EM — bypass sekecil apapun merusak otoritas EM dan visibilitasnya terhadap kapasitas tim, yang berujung pada sprint yang tidak predictable.
• Batas wewenang harus eksplisit, bukan diasumsikan — working agreement sederhana tentang siapa memutuskan apa lebih berharga daripada ratusan meeting alignment.
• Eskalasi adalah proses, bukan kelemahan — konflik antara EM dan PM yang dibawa ke VP Engineering adalah tanda tim yang sehat, bukan tanda kegagalan.
• Tanpa VP Product, VP Engineering naik peran — ini harus disadari secara eksplisit, karena kalau tidak, vakum “what dan why” diisi oleh chaos, bukan oleh siapapun secara terstruktur.
• Retrospektif kolaborasi perlu melibatkan semua layer — masalah antar peran tidak akan pernah terselesaikan kalau hanya dibicarakan di dalam satu peran saja.