Year-End Retrospective Buat Developer: Evaluasi Skill dan Karier

Daftar Isi

Kenapa Developer Perlu Retrospective Pribadi Tiap Tahun?
Evaluasi Skill Teknis: Apa yang Benar-Benar Meningkat?
Ukur Impact Kerja, Bukan Sekadar Kesibukan
Refleksi Kolaborasi dan Dinamika Tim
Hal yang Tidak Berjalan: Jujur Tanpa Menyalahkan Diri Sendiri
Susun Target Tahun Depan yang Spesifik dan Realistis
Template Retrospective Pribadi Siap Pakai

Kenapa Developer Perlu Retrospective Pribadi Tiap Tahun?

Di tim product, retrospective sprint sudah jadi hal biasa. Tapi banyak developer yang tidak pernah melakukan retrospective untuk dirinya sendiri, padahal:

Role dan ekspektasi kamu bisa berubah pelan-pelan tanpa terasa.
“Sibuk terus” tidak selalu berarti skill dan karier ikut naik.
Kalau tidak kamu yang memetakan progres, biasanya orang lain yang akan mengisi narasinya (misalnya saat performance review).

Retrospective pribadi akhir tahun membantu kamu:

Melihat kembali setahun penuh dengan data, bukan perasaan sesaat.
Menyadari area di mana kamu sebenarnya sudah banyak berkembang, tapi tidak terdokumentasi.
Mengidentifikasi pola yang bikin kamu stuck (misalnya sering kehabisan energi, terlalu banyak konteks switching, atau jarang dapat kerjaan strategis).

Tujuannya bukan untuk menghakimi diri sendiri, tapi untuk mendapatkan peta yang lebih akurat: kamu ada di mana sekarang, dan mau bergerak ke mana tahun depan.

Evaluasi Skill Teknis: Apa yang Benar-Benar Meningkat?

Daripada sekadar mengingat “tahun ini belajar Go dan Kubernetes”, coba evaluasi skill teknismu dengan cara yang lebih konkret.

Beberapa pertanyaan yang bisa kamu pakai:

Bahasa & framework: Stack apa yang paling sering kamu pakai tahun ini? Di situ, apa yang benar-benar naik level? (misalnya: sebelumnya cuma konsumsi API, sekarang sudah desain dan implement API sendiri).
System design & arsitektur: Apakah kamu ikut mendesain modul/layanan baru? Bisa jelaskan trade-off yang kamu ambil? Ada decision yang bisa kamu tulis jadi design doc?
Quality & reliability: Apakah test, observability (logging, metrics, tracing), dan praktik reliability kamu lebih baik dibanding awal tahun?
Tooling & automation: Apakah kamu membangun script, pipeline, atau tooling yang membuat pekerjaan tim lebih cepat/aman?

Coba tulis 3–5 contoh konkret:

PR yang paling kamu banggakan dan kenapa.
Incident atau bug yang kamu perbaiki dan apa yang kamu pelajari dari situ.
Fitur teknis sulit yang sekarang terasa “biasa saja” padahal dulu menakutkan.

Dari situ, kamu bisa melihat pola: area mana yang sudah kuat, dan area mana yang perlu diberi ruang di tahun depan.

Ukur Impact Kerja, Bukan Sekadar Kesibukan

Developer mudah terjebak di to-do list panjang, sampai lupa bertanya: “Sebenarnya impact-nya apa?” Tahun ini, coba ukur kontribusi kamu dari sisi dampak, bukan hanya jam kerja.

Contoh dimensi impact:

Ke user atau bisnis: Fitur apa yang paling terasa efeknya ke user? Apakah ada metrik (adopsi, conversion, penurunan complaint) yang bisa dikaitkan dengan kerjaanmu?
Ke reliability sistem: Apakah kamu terlibat dalam inisiatif yang menurunkan incident, on-call page, atau mempercepat recovery?
Ke kecepatan tim: Apakah kamu membuat hal yang bikin tim lain lebih cepat? (misalnya reusable component, template, CLI, dokumentasi yang mengurangi pertanyaan berulang).

Coba tulis beberapa kalimat seperti ini:

“Tahun ini aku berkontribusi ke ___ yang berdampak ke ___ dengan cara ___.”

Tidak semua kerjaan bisa diukur angka, tapi semakin sering kamu memformulasikan kontribusi dalam bentuk cerita berbasis dampak, semakin mudah kamu:

Menjelaskan kontribusimu ke manager saat review.
Menentukan mana jenis kerjaan yang ingin kamu kejar lagi di tahun depan.

Refleksi Kolaborasi dan Dinamika Tim

Skill teknis penting, tapi cara kamu bekerja dengan orang lain sering kali lebih menentukan karier jangka panjang.

Beberapa hal yang bisa kamu refleksikan:

Kolaborasi lintas role: Bagaimana kualitas kerjasama kamu dengan PM, designer, QA, dan engineer lain? Ada contoh kolaborasi yang sangat lancar atau sangat sulit? Kenapa?
Komunikasi: Apakah kamu makin nyaman menjelaskan solusi teknis ke orang non-teknis? Apakah kamu terbiasa menulis issue/PR description yang jelas dan lengkap?
Feedback: Seberapa sering kamu memberi dan menerima feedback tahun ini? Ada feedback tertentu yang mengubah cara kamu bekerja?
Peran informal: Apakah kamu sering jadi “go-to person” untuk area tertentu? Atau justru ingin mengurangi ketergantungan itu supaya tidak jadi bottleneck?

Tuliskan 2–3 situasi penting (baik maupun buruk) terkait kolaborasi, lalu jawab:

Apa yang aku lakukan dengan baik di situasi ini?
Apa yang akan aku lakukan berbeda kalau situasi serupa terjadi tahun depan?

Hal yang Tidak Berjalan: Jujur Tanpa Menyalahkan Diri Sendiri

Retrospective yang jujur selalu menyentuh hal-hal yang tidak berjalan: target yang tidak tercapai, keputusan yang disesali, atau kebiasaan kerja yang menghambat.

Cara membahasnya tanpa menjatuhkan diri:

Fokus ke sistem dan pola, bukan ke label (“aku malas”, “aku bodoh”). Misalnya: “Aku terlalu sering context switching sehingga deep work jarang terjadi.”
Bedakan antara hal di luar kontrol (perubahan prioritas besar, restrukturisasi tim) dan hal yang bisa kamu pengaruhi (cara kamu mengatur waktu, cara kamu mengatakan “tidak”).
Cari minimal satu insight yang bisa dipraktikkan dari setiap hal yang tidak berjalan.

Contoh yang bisa kamu tulis:

“Aku ingin belajar X, tapi tidak ada waktu” → Apakah benar tidak ada waktu, atau waktunya tercecer di context switching dan task yang sebenarnya bisa ditolak?
“Sering kelelahan menjelang akhir sprint” → Apakah komitmen sprint terlalu penuh? Apakah kamu merasa harus selalu bilang “ya” untuk semua permintaan?

Tujuannya adalah membuat daftar pelajaran, bukan daftar hukuman.

Susun Target Tahun Depan yang Spesifik dan Realistis

Setelah melihat ke belakang, waktunya melihat ke depan. Target yang baik biasanya:

Spesifik: jelas skill/area apa yang ingin ditingkatkan.
Terukur seperlunya: punya indikator sederhana bahwa kamu bergerak (bukan angka sempurna).
Masuk akal dengan konteks hidupmu: mempertimbangkan beban kerja, kondisi pribadi, dan energi mental.

Kamu bisa membagi target ke 3 kelompok:

Skill teknis – misalnya: “Menulis minimal 2 design doc untuk fitur backend yang menyentuh lebih dari 1 service.” / “Kontribusi ke 1 open source project yang relevan dengan kerjaan.”
Impact & kepemimpinan – misalnya: “Memimpin end-to-end deliverable untuk 1 inisiatif yang berdampak ke [metric X].” / “Mementor 1 engineer junior di area tertentu.”
Cara kerja & energi – misalnya: “Blok minimal 2x3 jam deep work per minggu tanpa meeting.” / “Menyiapkan sistem catatan (brag document) yang di-update bulanan.”

Lebih baik punya 3–5 target yang benar-benar kamu jaga sepanjang tahun dibanding 15 target yang dilupakan setelah Februari.

Template Retrospective Pribadi Siap Pakai

Kamu bisa memakai struktur sederhana ini (tulis di doc/notion favoritmu, atau bahkan di markdown di repo pribadi):

Highlight tahun ini
- 3–5 hal yang paling kamu banggakan (fitur, project, inisiatif).
- 3 skill teknis yang paling berkembang + contoh konkretnya.
Impact dan kolaborasi
- Contoh kontribusi yang berdampak ke user/bisnis/tim.
- 2–3 momen kolaborasi yang berkesan (positif atau negatif) dan pelajarannya.
Hal yang tidak berjalan & pelajaran
- Daftar singkat hal yang meleset dari rencana.
- Untuk masing-masing: apa penyebab utama, apa yang bisa kamu ubah tahun depan.
Fokus utama tahun depan
- Maksimal 3 fokus: 1 teknis, 1 impact/karier, 1 cara kerja/pribadi.
- Untuk tiap fokus, tulis langkah konkret 3 bulan pertama (bukan rencana setahun penuh).

Kalau kamu konsisten mengisi retrospective seperti ini tiap akhir tahun (dan idealnya versi mini setiap kuartal), kamu akan punya jejak perkembangan karier yang jauh lebih jelas — dan bahan yang sangat kuat untuk negosiasi role, gaji, atau peluang baru.

Referensi

Cal Newport — Deep Work: Rules for Focused Success in a Distracted World
Staff Engineer — Will Larson
Brag Document Template — Julia Evans
The Senior Engineer’s Checklist — Tanya Reilly