¿Qué criterios usas para evaluar el rendimiento de un desarrollador?

Question

Accepted Answer

Evalúo a los desarrolladores por los **resultados que producen y el impacto que tienen en el equipo**, no por métricas de producción bruta como líneas de código, commits o story points. Una buena evaluación triangula varias señales a lo largo de un periodo significativo, no de un único sprint.

## Qué miro de verdad

- **Impacto y propiedad.** ¿Entregan trabajo que mueve el producto o desbloquea a otros? ¿Son dueños de un problema de extremo a extremo, incluidas las partes incómodas como el rollout, la monitorización y los bugs de seguimiento?
- **Calidad y fiabilidad.** ¿Su código aguanta en producción? ¿Dejan el codebase mejor o acumulan **tech debt** que otros tienen que pagar?
- **Autonomía al nivel correcto.** Un ingeniero mid-level que necesita que lo lleven de la mano en tareas rutinarias es distinto de un senior que toma un problema ambiguo y devuelve un plan.
- **Multiplicador de colaboración.** Calidad del code review, mentoría, aportes de diseño, documentación. Los mejores ingenieros elevan a quienes los rodean.
- **Trayectoria de crecimiento.** ¿Son mejores que hace seis meses? ¿Responden al feedback?

## Cómo lo hago justo

- Calibrar frente a las **expectativas de su nivel**, escritas, para que el feedback no sea arbitrario.
- Reunir evidencia concreta de forma continua en lugar de reconstruirla en el momento de la review. Tomo notas por persona.
- Separar el **rendimiento** (resultados) del **potencial** (capacidad para el siguiente nivel). Confundirlos provoca malas decisiones de promoción y PIP.

| Señal | Buena fuente | Fuente engañosa |
|---|---|---|
| Productividad | Resultados entregados | Líneas de código, número de commits |
| Calidad | Tendencias de incidentes/defectos | Sensación subjetiva |
| Colaboración | Feedback de pares, historial de PRs | Volumen de reuniones |

## Errores a evitar

- **Sesgo de recencia** — juzgar las últimas dos semanas, no el periodo.
- **Sesgo de visibilidad** — premiar el trabajo ruidoso y pasar por alto el trabajo de pegamento silencioso como el on-call y las reviews.
- Tratar las métricas como objetivos; en cuanto una métrica se vuelve una meta, la gente la manipula.

## Por qué es importante

Una evaluación justa y basada en evidencia impulsa la confianza, la retención y las inversiones de crecimiento correctas. Hazla mal y promocionarás a las personas equivocadas, desmoralizarás a tus contribuidores más fuertes y enseñarás al equipo que el trabajo performativo gana al impacto real.

Señal	Buena fuente	Fuente engañosa
Productividad	Resultados entregados	Líneas de código, número de commits
Calidad	Tendencias de incidentes/defectos	Sensación subjetiva
Colaboración	Feedback de pares, historial de PRs	Volumen de reuniones