Seniority más allá del código
El seniority no se mide en años de experiencia ni en la cantidad de tecnologías que conoces. Se mide en la calidad de tus decisiones, en el impacto que tienes sobre las personas a tu alrededor, y en la capacidad de navegar ambigüedad sin perder el rumbo.
Hay una confusión persistente en la industria del software sobre qué significa ser senior. La versión más común dice algo así: es la persona que conoce más tecnologías, que resuelve los bugs más difíciles, que escribe el código más limpio. La que tiene respuesta para todo en la code review. La que puede leer un stack trace y saber en treinta segundos dónde está el problema.
Eso describe habilidad técnica. Es valiosa. Pero no es suficiente para definir seniority, y confundirlas tiene un costo real tanto para las personas como para las organizaciones.
El error de equiparar seniority con profundidad técnica
La habilidad técnica tiene una curva de retorno decreciente que muchos no anticipan. Pasar de no saber usar un framework a usarlo con soltura produce un salto de impacto enorme. Pasar de usarlo bien a dominarlo completamente produce un incremento mucho más modesto. Después de cierto punto, profundizar más en una tecnología específica aporta muy poco al impacto real en el equipo o en el producto.
Lo que escala de forma diferente —y lo que distingue a un ingeniero verdaderamente senior— es la capacidad de operar en contextos de mayor complejidad y ambigüedad.
Un ingeniero junior recibe una tarea definida y la ejecuta. Un ingeniero mid recibe un problema y lo convierte en tareas. Un ingeniero senior recibe una situación — a veces sin nombre, a veces con información incompleta, a veces con múltiples interpretaciones válidas — y decide cómo encuadrarla, qué parte del problema vale la pena resolver, y qué solución tiene sentido dado el contexto organizacional, técnico y de negocio.
Esa última capacidad no se aprende escribiendo más código. Se aprende tomando decisiones, enfrentando sus consecuencias, y reflexionando con honestidad sobre la diferencia entre lo que esperabas y lo que ocurrió.
Juicio: la habilidad que no tiene nombre en el job description
Si tuvieras que nombrar la habilidad central de un ingeniero senior, probablemente sería esta: juicio.
Juicio es la capacidad de tomar buenas decisiones con información incompleta, bajo restricciones reales, considerando efectos que no son inmediatamente visibles. No es lo mismo que conocimiento — puedes tener mucho conocimiento y pésimo juicio. No es lo mismo que experiencia — puedes acumular años repitiendo los mismos patrones sin desarrollar criterio propio.
El juicio se manifiesta en decisiones concretas:
- Cuándo es suficiente una solución simple y cuándo el problema realmente justifica complejidad adicional.
- Cuándo empujar en una discusión técnica y cuándo soltar y moverse.
- Cuándo una deuda técnica es manejable y cuándo se ha convertido en un riesgo real para el equipo.
- Cuándo un requisito de negocio está mal formulado y necesita cuestionarse antes de implementarse.
- Cuándo una arquitectura que funciona hoy va a ser un problema en seis meses.
Ninguna de estas decisiones tiene una respuesta en la documentación del framework. Todas requieren leer el contexto, entender las fuerzas en juego, y estar dispuesto a opinar — sabiendo que puedes estar equivocado.
Influencia sin autoridad formal
Otro marcador de seniority que rara vez aparece en los perfiles de LinkedIn: la capacidad de influir en cómo trabaja el equipo sin necesidad de un cargo formal que te dé autoridad para hacerlo.
Un ingeniero senior cambia la forma en que su equipo aborda los problemas. No porque sea el líder técnico o el arquitecto designado, sino porque sus preguntas en las discusiones de diseño hacen que todos piensen más cuidadosamente. Porque sus comentarios en la code review no solo señalan problemas sino que explican el razonamiento detrás. Porque cuando propone una forma diferente de hacer algo, lo hace con suficiente contexto y claridad para que el equipo pueda evaluar la propuesta en lugar de simplemente aceptarla o rechazarla.
Esta influencia se construye lentamente y se basa en algo simple: ser consistente. Que las personas que trabajan contigo puedan predecir que vas a hacer preguntas útiles, que vas a señalar problemas de forma constructiva, que vas a compartir lo que aprendes, que vas a cumplir lo que dices que vas a hacer. La confianza no es un activo que se declara — se acumula en pequeñas interacciones consistentes a lo largo del tiempo.
El costo de no multiplicar
Existe una trampa cómoda en la que caen muchos ingenieros técnicamente fuertes: convertirse en el cuello de botella. Son tan buenos resolviendo problemas que terminan resolviéndolos todos. El equipo aprendió a llevarles los problemas difíciles porque saben que los van a resolver. Y el ingeniero, sin darse cuenta, dejó de ser un multiplicador para convertirse en una dependencia.
Un ingeniero senior que opera bien no hace que el equipo dependa de él. Hace que el equipo sea más capaz sin él. Hay una diferencia fundamental entre resolver el problema de alguien y ayudar a que esa persona desarrolle la capacidad de resolver ese tipo de problemas por sí misma.
Esto requiere una habilidad que tiene poco que ver con el código: la paciencia de no dar la respuesta inmediata. De hacer la pregunta que lleva a la persona a encontrar la solución. De explicar el razonamiento en lugar de solo mostrar la solución. De crear las condiciones para que alguien menos experimentado pueda asumir más responsabilidad gradualmente, con apoyo pero sin dependencia.
El impacto de un ingeniero que multiplica no se mide en las líneas de código que escribe. Se mide en el nivel de autonomía que tiene el equipo cuando esa persona no está.
Comunicación como habilidad técnica
La comunicación efectiva no es una habilidad “blanda” separada de la ingeniería. Es una habilidad técnica en sí misma, y su ausencia tiene consecuencias tan concretas como un bug en producción.
Un ingeniero senior necesita comunicarse en múltiples registros:
Con personas no técnicas: Explicar el impacto de una decisión técnica en términos de riesgo, costo o tiempo. No para simplificar en exceso, sino para hacer accesible la información que esa persona necesita para tomar su propia decisión. Un stakeholder que no entiende por qué algo toma tres semanas en lugar de tres días no va a confiar en la estimación — y tiene razón de no hacerlo si nadie se tomó el tiempo de explicarle la complejidad real.
Con el equipo: Articular posiciones técnicas con claridad, sin ambigüedad, de forma que se pueda debatir. Un senior que dice “creo que deberíamos usar X” sin explicar el razonamiento no está ayudando al equipo a aprender — está creando consenso por autoridad, que es frágil y no escala.
En la escritura: Los documentos de diseño, los ADRs, los comentarios en código, los mensajes en tickets — todos son formas de comunicación técnica que tienen vida larga. Un documento de diseño bien escrito puede evitar horas de reuniones. Un comentario que explica por qué se tomó una decisión puede salvar a alguien de deshacer un cambio que parecía redundante pero no lo era.
La comunicación no es lo que haces después de resolver el problema técnico. Es parte del problema técnico.
Pensar en sistemas, no en componentes
El pensamiento de un ingeniero junior tiende a ser local: ¿cómo hago que este test pase? ¿cómo implemento esta función? Es el pensamiento correcto para el alcance del trabajo que tiene.
Un ingeniero senior piensa en sistemas: ¿qué pasa con el resto del equipo si introduzco esta dependencia? ¿qué efecto tiene este cambio en el comportamiento del sistema bajo carga? ¿qué pasará con este código en dieciocho meses cuando las personas que lo escribieron ya no estén?
Este pensamiento sistémico no es abstracto ni filosófico. Tiene consecuencias prácticas inmediatas: en qué cambios se hacen y cuáles se descartan, cómo se diseñan las interfaces entre componentes, cómo se documenta una decisión para que sea interpretable en el futuro, cómo se estructura el trabajo del equipo para reducir el acoplamiento organizacional.
Desarrollar pensamiento sistémico requiere exposición deliberada a sistemas completos — no solo a los componentes que uno posee. Requiere leer post-mortems. Requiere participar en discusiones de arquitectura aunque el problema esté fuera de tu área directa. Requiere cultivar la curiosidad de entender por qué el sistema se comporta como se comporta, no solo qué hace.
Lo que el título de Senior no garantiza
Es útil ser honesto sobre esto: el título de Senior Engineer en muchas organizaciones no garantiza que la persona tenga estas capacidades. El título se da por años de experiencia, por habilidad técnica demostrada, por permanencia, por proceso de performance review. No necesariamente por evidencia de juicio, influencia o pensamiento sistémico.
Esto no es un problema del título — es un problema de cómo las organizaciones piensan el desarrollo de carrera. Si el único camino para que un ingeniero avance es demostrar más profundidad técnica, el sistema está produciendo exactamente lo que incentiva: especialistas técnicos con poco desarrollo en las habilidades que realmente escalan con la seniority.
Un ingeniero que quiere desarrollar seniority real no debe esperar a que el título se lo confirme. Puede empezar hoy: tomando responsabilidad de decisiones más allá de su área directa, buscando contexto de negocio activamente, practicando explicar razonamientos técnicos a personas no técnicas, eligiendo conscientemente las ocasiones en que da respuestas directas versus las que usa para que alguien desarrolle su propio criterio.
Cierre
La carrera técnica tiene una ilusión conveniente: que avanzar significa saber más. Más tecnologías, más patrones, más profundidad. Es parcialmente cierto, y no tiene fecha de vencimiento — siempre habrá algo más que aprender.
Pero el salto real — el que marca la diferencia entre una persona técnicamente sólida y una que tiene impacto real a escala — no ocurre cuando aprendes otra tecnología. Ocurre cuando empiezas a operar con juicio propio en situaciones ambiguas, cuando el equipo a tu alrededor se vuelve más capaz de lo que sería sin ti, cuando puedes hablar de las implicaciones técnicas de una decisión de negocio con la misma precisión con que hablas de la implementación.
El código es el medio. El impacto es el fin.