Belajar Engineering Manager - Performance Management
Menjalankan siklus performance yang adil dan berguna: goal setting dengan OKR, anatomi review cycle dari planning sampai calibration, development plan (IDP) yang benar-benar dieksekusi, rating dengan rubrik, serta bias klasik seperti recency effect dan halo effect
#Pendahuluan
Setelah di episode 3 kita menguasai 1:1 dan feedback harian, sekarang kita naik ke sistem yang lebih formal: performance management — proses menetapkan ekspektasi, menilai kinerja, dan mengembangkan karir secara terstruktur.
Mengapa topik ini penting? Karena performance management adalah tempat karir orang dipertaruhkan: promosi, kenaikan gaji, bahkan PIP (Performance Improvement Plan). Proses yang buruk merusak trust yang sudah dibangun lewat puluhan 1:1; proses yang baik justru memperkuatnya, karena anggota tim tahu persis apa yang dinilai dan mengapa. Tujuan akhirnya bukan memberi rating, melainkan memastikan setiap orang tahu posisinya dan jalur pertumbuhannya.
#Goal Setting dengan OKR
Standar de facto goal setting di perusahaan teknologi adalah OKR (Objectives and Key Results). Strukturnya: satu Objective (arah yang inspiratif, kualitatif) ditopang 3-5 Key Results (terukur, kuantitatif).
objective: "Platform pembayaran stabil dan cepat sehingga tim produk berani ship tanpa takut"
key_results:
- kr: "Kurangi p99 latency checkout dari 900ms menjadi di bawah 300ms"
progress: "0.4"
- kr: "Change failure rate deployment turun dari 12% menjadi di bawah 5%"
progress: "0.7"
- kr: "Zero incident SEV-1 di jalur pembayaran selama kuartal"
progress: "1.0"
owners:
- "Tim Platform Payments (8 engineer)"
cadence_check: "mingguan di delivery sync"Tiga aturan OKR yang sering dilanggar. Pertama, Key Results adalah hasil (outcome), bukan aktivitas: "deploy fitur X" adalah task; "latency turun ke 300ms" adalah hasil. Kedua, OKR tim harus bisa ditarik garis lurus ke OKR organisasi — kalau tidak ada garisnya, pertanyaan yang layak diajukan adalah kenapa tim ini ada. Ketiga, OKR bukan daftar semua pekerjaan: hal operasional rutin (on-call, bug fix harian) tidak masuk OKR, cukup dikelola sebagai baseline.
#Anatomi Siklus Performance
Siklus tahunan tipikal terlihat seperti ini:
| Fase | Waktu | Aktivitas EM |
|---|---|---|
| Goal setting | Awal kuartal | Turunkan OKR org ke OKR tim, sepakati KR per orang |
| Check-in | Bulanan | Review progres KR di 1:1; geser target jika konteks berubah |
| Mid-year review | Pertengahan tahun | Feedback formal dua arah; koreksi arah lebih awal |
| Self-review | Akhir tahun | Anggota menulis capaian versi mereka sendiri |
| Peer feedback | Akhir tahun | Kumpulkan input dari rekan kerja lintas peran |
| Calibration | Akhir tahun | Manager se-peer menyamakan standar penilaian |
| Delivery | Awal tahun | Rating, promosi, kompensasi, development plan baru |
Dua fase yang paling sering diabaikan tapi paling menentukan: check-in bulanan (tanpa itu, review akhir tahun penuh kejutan — dan kejutan dalam review adalah kegagalan manajer) dan calibration (tanpa itu, rating antar tim tidak bisa dibandingkan).
#Rating dan Calibration
Banyak perusahaan memakai skala bertingkat, misalnya lima level. Contoh rubrik sederhana untuk konteks engineering:
| Rating | Makna | Ciri Bukti |
|---|---|---|
| Jauh di bawah ekspektasi | Tidak memenuhi syarat level | Butuh supervisi intensif, dampak negatif |
| Di bawah ekspektasi | Ada gap nyata | Sebagian ekspektasi tercapai, gap sudah dibicarakan |
| Memenuhi ekspektasi | Solid pada level-nya | Ekspektasi level terpenuhi konsisten |
| Melebihi ekspektasi | Di atas level saat ini | Konsisten menunjukkan perilaku level berikutnya |
| Luar biasa | Dampak luar biasa | Mengubah arah tim/org, dicontoh lintas tim |
Calibration adalah forum manager se-peer membahas rating bersama agar standar seragam. Persiapkan dirimu dengan bukti konkret, bukan kesan: PR yang mengubah arah, incident yang ditangani baik, mentoring yang membuat junior naik level. Kalimat "saya rasanya dia hebat" akan langsung diserang di calibration — dan pantas begitu.
Warning
Aturan emas performance management: tidak boleh ada kejutan. Jika rating di akhir tahun mengejutkan anggota tim, akar masalahnya bukan rating itu — melainkan feedback bulanan yang gagal disampaikan di episode 3. Kejutan = bukti kegagalan sistem feedback, bukan ketegasan reviewer.
#Bias yang Merusak Penilaian
Empat bias yang wajib kalian waspadai saat menulis review:
- Recency effect: menilai hanya dari dua bulan terakhir. Solusi: baca catatan 1:1 dari awal periode — inilah alasan manager OS kalian berharga.
- Halo effect: satu kehebatan (coding cepat) menutupi gap lain (kerjasama buruk). Nilai dimensi satu per satu.
- Horn effect: kebalikannya — satu kesalahan awal membayangi seluruh periode.
- Similar-to-me bias: menilai lebih tinggi orang yang mirip gaya komunikasi atau latar belakang kita. Minta peer feedback dari orang yang berbeda gaya darimu.
Kebiasaan yang menetralkan bias: tulis bukti per dimensi kompetensi (technical, collaboration, ownership), bukan narasi bebas tentang orangnya. Fakta dulu, interpretasi kemudian.
#Development Plan (IDP)
Review menutup masa lalu; Individual Development Plan membuka masa depan. IDP yang baik punya tiga bagian dan maksimal dua fokus — lebih dari itu tidak ada energi yang tersisa:
# IDP {nama} - H2 2026
## Arah
Ingin diperkuat ke Tech Lead: memimpin proyek lintas 3 engineer
dan mewakili tim di diskusi arsitektur.
## Fokus 1: Memimpin proyek end-to-end
- Target : Memimpin migrasi event pipeline (Q3)
- Bukti : Rancangan, eksekusi, dan retro proyek selesai
- Dukungan : Saya coaching biweekly; akses ke diskusi planning
## Fokus 2: Komunikasi teknis lintas fungsi
- Target : Menulis 2 RFC yang diadopsi tanpa revisi besar
- Bukti : Link RFC + catatan adopsi di meeting arsitektur
- Dukungan : Template RFC internal + review draft oleh saya
## Checkpoint
Bulanan di 1:1 minggu kedua.Perhatikan polanya: setiap fokus punya target perilaku yang dapat diverifikasi ("2 RFC diadopsi"), bukan niat kabur ("memperbaiki soft skill"). Hubungkan IDP dengan pekerjaan nyata — development plan yang isinya kursus online saja hampir selalu mati dalam sebulan, karena pertumbuhan engineer terjadi lewat pekerjaan yang menantang plus dukungan yang tepat.
#Ketika Performa Bermasalah
Bagian tersulit: bagaimana jika seseorang konsisten di bawah ekspektasi? Urutan langkahnya:
- Diagnosis dulu: capability (tidak mampu) atau engagement (mampu tapi tidak mau)? Solusinya beda total.
- Ekspektasi tertulis: sampaikan gap secara eksplisit dengan contoh perilaku dan tenggat perbaikan — di 1:1, bukan lewat email dingin.
- Dukungan nyata: pairing, kurikulum belajar, pengaturan ulang scope. PIP tanpa dukungan cuma dokumen pemecatan yang lambat.
- Keputusan: jika setelah periode yang disepakati tidak berubah, tindakan lanjutan adalah tanggung jawab kalian — membiarkannya berlarat tidak adil bagi tim yang menanggung bebannya.
#Penutup
Inti yang harus dibawa pulang:
- OKR menetapkan arah: objective kualitatif, key results kuantitatif berbasis outcome, ditarik garis dari OKR organisasi.
- Siklus performance hidup di check-in bulanan; review formal hanya memfinalkan yang sudah dibicarakan sepanjang tahun.
- Tidak boleh ada kejutan di review — jika ada, sistem feedback kalian yang gagal.
- Waspadai recency, halo, horn, dan similar-to-me bias; nilai per dimensi dengan bukti konkret.
- IDP maksimal dua fokus, berbasis perilaku terverifikasi, dan terhubung dengan pekerjaan nyata.
Di episode 5 selanjutnya kita bahas aktivitas dengan ROI people-management tertinggi: Hiring & Onboarding — struktur interview yang teruji, scorecard terstruktur anti-bias, hiring plan yang realistis, dan onboarding 30-60-90 hari yang membuat orang baru produktif cepat. Sampai jumpa!