ஒரு developer-இன் performance-ஐ மதிப்பிட நீங்கள் என்ன அளவுகோல்களைப் பயன்படுத்துகிறீர்கள்?

Question

Accepted Answer

lines of code, commits, அல்லது story points போன்ற raw output metrics அல்ல, **அவர்கள் உருவாக்கும் outcomes மற்றும் team-இல் அவர்கள் கொண்டிருக்கும் impact** மீது developers-ஐ மதிப்பிடுகிறேன். ஒரு நல்ல மதிப்பீடு ஒரு sprint அல்ல, அர்த்தமுள்ள கால இடைவெளியில் பல signals-ஐ triangulate செய்கிறது.

## நான் உண்மையில் என்ன பார்க்கிறேன்

- **Impact மற்றும் ownership.** product-ஐ நகர்த்தும் அல்லது மற்றவர்களை unblock செய்யும் வேலையை அவர்கள் ship செய்கிறார்களா? rollout, monitoring, மற்றும் follow-up bugs போன்ற குழப்பமான பகுதிகள் உட்பட ஒரு பிரச்சினையை முழுவதுமாக own செய்கிறார்களா?
- **தரம் மற்றும் நம்பகத்தன்மை.** அவர்களின் code production-இல் நிலைக்கிறதா? அவர்கள் codebase-ஐ சிறப்பாக விட்டுச் செல்கிறார்களா அல்லது மற்றவர்கள் கட்ட வேண்டிய **tech debt**-ஐ குவித்துக்கொண்டிருக்கிறார்களா?
- **சரியான மட்டத்தில் autonomy.** வழக்கமான பணிகளில் hand-holding தேவைப்படும் ஒரு mid-level engineer, ஒரு தெளிவற்ற பிரச்சினையை எடுத்து ஒரு திட்டத்தை திருப்பித் தரக்கூடிய senior-இலிருந்து வேறுபட்டவர்.
- **Collaboration multiplier.** code review தரம், mentoring, design input, documentation. சிறந்த engineers தங்களைச் சுற்றியுள்ள மக்களை உயர்த்துகிறார்கள்.
- **வளர்ச்சி பாதை.** ஆறு மாதங்களுக்கு முன்பை விட அவர்கள் சிறப்பாக இருக்கிறார்களா? feedback-க்கு பதிலளிக்கிறார்களா?

## நான் அதை எப்படி நியாயமாக ஆக்குகிறேன்

- எழுதப்பட்ட, **அவர்களின் level-இன் எதிர்பார்ப்புகளுக்கு** எதிராக calibrate செய்யுங்கள், இதனால் feedback தன்னிச்சையாக இல்லை.
- review நேரத்தில் மறுகட்டமைப்பதற்குப் பதிலாக concrete ஆதாரத்தைத் தொடர்ந்து சேகரிக்கவும். ஒவ்வொரு நபருக்கும் குறிப்புகளை வைத்திருக்கிறேன்.
- **performance** (முடிவுகள்)-ஐ **potential** (அடுத்த level-க்கான திறன்)-இலிருந்து பிரிக்கவும். அவற்றை குழப்புவது மோசமான promotion மற்றும் PIP முடிவுகளை ஏற்படுத்துகிறது.

| Signal | நல்ல source | தவறான வழிநடத்தும் source |
|---|---|---|
| Productivity | ship செய்யப்பட்ட outcomes | Lines of code, commit count |
| தரம் | Incident/defect trends | அகநிலை உணர்வு |
| Collaboration | Peer feedback, PR history | meetings அளவு |

## தவறுகள்

- **Recency bias** — காலகட்டத்தை அல்ல, கடைசி இரண்டு வாரங்களை மதிப்பிடுவது.
- **Visibility bias** — சத்தமான வேலையை வெகுமதி அளித்து on-call மற்றும் reviews போன்ற அமைதியான glue வேலையைத் தவறவிடுவது.
- metrics-ஐ targets ஆகக் கருதுவது; ஒரு metric ஒரு goal ஆகும் தருணத்தில், மக்கள் அதை game செய்கிறார்கள்.

## இது ஏன் முக்கியம்

நியாயமான, ஆதார அடிப்படையிலான மதிப்பீடு நம்பிக்கை, retention, மற்றும் சரியான வளர்ச்சி முதலீடுகளை இயக்குகிறது. அதைத் தவறாகச் செய்தால், நீங்கள் தவறான மக்களை promote செய்கிறீர்கள், உங்கள் வலுவான பங்களிப்பாளர்களை demoralize செய்கிறீர்கள், மற்றும் performative வேலை உண்மையான impact-ஐ விஞ்சும் என்று team-க்குக் கற்பிக்கிறீர்கள்.

Signal	நல்ல source	தவறான வழிநடத்தும் source
Productivity	ship செய்யப்பட்ட outcomes	Lines of code, commit count
தரம்	Incident/defect trends	அகநிலை உணர்வு
Collaboration	Peer feedback, PR history	meetings அளவு