Kriteria apa yang Anda gunakan untuk mengevaluasi performa seorang developer?

Question

Accepted Answer

Saya mengevaluasi developer berdasarkan **hasil yang mereka produksi dan dampak yang mereka berikan pada tim**, bukan berdasarkan metrik output mentah seperti baris kode, jumlah commit, atau story point. Evaluasi yang baik mentriangulasi beberapa sinyal selama rentang waktu yang berarti, bukan satu sprint saja.

## Apa yang sebenarnya saya lihat

- **Dampak dan kepemilikan.** Apakah mereka merilis pekerjaan yang menggerakkan produk atau membuka jalan bagi orang lain? Apakah mereka memiliki sebuah masalah dari ujung ke ujung, termasuk bagian-bagian yang rumit seperti rollout, monitoring, dan bug tindak lanjut?
- **Kualitas dan keandalan.** Apakah kode mereka bertahan di produksi? Apakah mereka meninggalkan codebase dalam kondisi lebih baik atau menumpuk **tech debt** yang harus dibayar orang lain?
- **Otonomi pada level yang tepat.** Seorang engineer mid-level yang butuh dituntun pada tugas rutin berbeda dari seorang senior yang bisa mengambil masalah ambigu dan mengembalikannya dalam bentuk rencana.
- **Pengganda kolaborasi.** Kualitas code review, mentoring, masukan desain, dokumentasi. Engineer terbaik mengangkat orang-orang di sekitar mereka.
- **Lintasan pertumbuhan.** Apakah mereka lebih baik dibanding enam bulan lalu? Apakah mereka merespons umpan balik?

## Bagaimana saya membuatnya adil

- Kalibrasikan terhadap **ekspektasi sesuai levelnya**, yang ditulis, agar umpan balik tidak sewenang-wenang.
- Kumpulkan bukti konkret secara berkelanjutan alih-alih merekonstruksinya saat waktu review. Saya menyimpan catatan per orang.
- Pisahkan **performa** (hasil) dari **potensi** (kemampuan untuk level berikutnya). Mencampuradukkannya menyebabkan keputusan promosi dan PIP yang buruk.

| Sinyal | Sumber baik | Sumber menyesatkan |
|---|---|---|
| Produktivitas | Hasil yang dirilis | Baris kode, jumlah commit |
| Kualitas | Tren incident/defect | Perasaan subjektif |
| Kolaborasi | Umpan balik rekan, riwayat PR | Volume rapat |

## Jebakan

- **Bias kekinian** — menilai dua minggu terakhir, bukan keseluruhan periode.
- **Bias visibilitas** — menghargai pekerjaan yang lantang dan melewatkan pekerjaan perekat yang senyap seperti on-call dan review.
- Memperlakukan metrik sebagai target; begitu sebuah metrik menjadi tujuan, orang akan mengakalinya.

## Mengapa ini penting

Evaluasi yang adil dan berbasis bukti mendorong kepercayaan, retensi, dan investasi pertumbuhan yang tepat. Salah melakukannya dan Anda mempromosikan orang yang salah, mematahkan semangat kontributor terkuat Anda, serta mengajarkan tim bahwa pekerjaan yang sekadar tampak hebat mengalahkan dampak yang nyata.

Sinyal	Sumber baik	Sumber menyesatkan
Produktivitas	Hasil yang dirilis	Baris kode, jumlah commit
Kualitas	Tren incident/defect	Perasaan subjektif
Kolaborasi	Umpan balik rekan, riwayat PR	Volume rapat