Los criterios ocultos en las reviews de performance

La gran mentira de las reviews técnicas

Te dijeron que escribir buen código te iba a llevar al siguiente nivel. Te enfocaste en arquitectura limpia, testing y mejores prácticas. Pero cuando llegó la review de performance, el ascenso se lo llevó tu compañero que apenas sabe usar Git correctamente.

¿Qué pasó? Simple: nadie te contó que las promociones se deciden con criterios que casi nunca aparecen en las job descriptions.

Después de cinco años liderando equipos y participar en más de 200 reviews, te voy a contar qué evalúan realmente cuando deciden quién sube y quién se queda.

El mito del "buen programador"

La industria te vende que ser senior es escribir código elegante y conocer patrones de diseño. Pero en la práctica, los líderes técnicos buscan algo completamente distinto.

Lo que pensás que evalúan:

• Conocimiento técnico profundo
• Arquitectura de software impecable
• Dominio de frameworks y herramientas
• Años de experiencia

Lo que realmente evalúan:

• Capacidad para reducir fricción en el equipo
• Habilidad para acelerar a otros developers
• Intuición para detectar problemas antes que exploten
• Comunicación técnica clara con no-técnicos

Esa diferencia explica por qué muchos devs brillantes se estancan en roles junior mientras otros con menos skills técnicos ascienden rápidamente.

Los cinco pilares invisibles de las promociones

1. Amplificación de equipo

Los líderes no buscan superhéroes que resuelven todo solos. Buscan multiplicadores que hacen que todo el equipo sea más productivo.

Señales que buscan:

• ¿Tus pull requests generan discusiones constructivas o solo aprueban?
• ¿Otros devs recurren a vos cuando están trabados?
• ¿Tus decisiones técnicas facilitan o complican el trabajo del resto?

Ejemplo real: En una empresa donde trabajé, había dos senior developers candidatos a tech lead. Uno escribía código perfecto pero trabajaba aislado. El otro tenía bugs ocasionales pero sus PRs siempre incluían explicaciones detalladas que educaban al equipo. Adivina quién consiguió la promoción.

2. Navegación de ambigüedad

Los requirements cambian, las prioridades se modifican, los deadlines se acortan. Los líderes valoran a quien puede navegar el caos sin perder el rumbo.

Comportamientos que detectan:

• Cómo reaccionás cuando el PM cambia los requirements a mitad del sprint
• Si podés tomar decisiones técnicas con información incompleta
• Tu capacidad para balancear deuda técnica con features nuevas

La clave no es nunca equivocarte, sino recuperarte rápido y aprender del error.

3. Traducción técnica

Ser senior implica comunicarte con stakeholders que no entienden de código. Pero la mayoría de developers subestima esta habilidad.

Situaciones donde te evalúan:

• Explicar por qué una refactor va a tomar tres sprints
• Justificar inversión en testing o infraestructura
• Comunicar el impacto técnico de decisiones de producto

Pro tip: Aprendé a hablar en términos de riesgo de negocio y tiempo, no de elegancia arquitectural.

4. Ownership expandido

Los juniors se enfocan en sus tareas. Los seniors piensan en el sistema completo, incluso las partes que no tocan directamente.

Indicadores que rastrean:

• ¿Proponés mejoras en procesos que no te afectan directamente?
• ¿Anticipás problemas en otras áreas del sistema?
• ¿Colaborás activamente con QA, DevOps y producto?

Esto no significa meterte en todo, sino ampliar tu perspectiva más allá del código que escribís.

5. Mentoría natural

No necesitás ser mentor oficial para demostrar capacidad de liderazgo. Los líderes observan cómo interactuás con developers menos experimentados.

Momentos que importan:

• Code reviews constructivos vs críticas destructivas
• Cómo ayudás a juniors sin hacer su trabajo
• Tu reacción cuando alguien rompe algo que vos escribiste

La diferencia entre ser condescendiente y ser útil marca tu potencial como líder técnico.

Cómo posicionarte para la próxima review

Ahora que conocés los criterios reales, podés trabajar estratégicamente en demostrar estas habilidades.

Estrategias inmediatas:

1. Documentá tus decisiones técnicas
   Empezá a escribir ADRs (Architecture Decision Records) aunque tu equipo no los use. Mostrá que pensás en el contexto y las trade-offs.

2. Iniciá conversaciones de arquitectura
   No esperes que te asignen tareas de diseño. Proponé mejoras, señalá problemas futuros, sugiere refactors con justificación de negocio.

3. Mejorá tus pull requests
   Convertí cada PR en una oportunidad de enseñar. Explicá el "por qué", no solo el "qué".

4. Participá en reuniones cross-funcionales
   Ofrecete para sprint plannings, demos con stakeholders, post-mortems. Mostrá que podés comunicarte fuera del equipo técnico.

5. Medí tu impacto en métricas de equipo
   Empezá a trackear cómo tus acciones afectan la velocidad general del equipo, no solo tu throughput individual.

Las señales de alerta que te frenan

Algunos comportamientos matan tus chances de ascenso, aunque seas técnicamente excelente:

• Perfeccionismo paralizante: Retrasar releases por detalles que no impactan al usuario
• Síndrome de not-invented-here: Rechazar soluciones existentes para escribir todo desde cero
• Optimización prematura: Obsesionarte con performance cuando el bottleneck está en otro lado
• Comunicación técnica hermética: Usar jerga que excluye a non-developers

Esos comportamientos te posicionan como developer individual contributor, no como líder técnico potencial.

La verdad incómoda sobre los ascensos

Las promociones no son meritocráticas en el sentido que creemos. No se basan solo en skill técnico sino en percepción de potencial de liderazgo.

Esto significa que:

• Un developer "bueno" que comunica bien puede ascender más rápido que un developer "excelente" que trabaja solo
• Las soft skills no son "nice to have", son requisitos para roles senior
• La política organizacional importa tanto como el código que escribís

Aceptar esta realidad no es "venderse". Es entender cómo funcionan las organizaciones tech y posicionarte estratégicamente.

Preguntas frecuentes

¿Significa que el skill técnico no importa?
Importa como baseline. Pero una vez que pasás cierto umbral técnico, otros factores se vuelven más determinantes para ascensos.

¿Qué pasa si soy introvertido?
No necesitás ser extrovertido para demostrar liderazgo. Podés liderar a través de documentación clara, arquitectura sólida y mentoría 1:1.

¿Cuánto tiempo lleva demostrar estos criterios?
Depende del contexto, pero típicamente necesitás 6-12 meses mostrando estos comportamientos consistentemente antes de una promoción.

La próxima vez que te preguntes por qué no te ascendieron, no te enfoques solo en tu código. Preguntate qué tan amplificador fuiste para tu equipo y qué tan preparado estás para los desafíos de liderazgo técnico.