No eres senior por los años

Tarde o temprano, todo desarrollador hace la misma pregunta: “¿cuándo soy senior?”. Y casi siempre se la responde con la métrica equivocada. Que si ya llevo cinco años. Que si ya me pagan tanto. Que si en mi tarjeta dice “Senior Developer”.

Ninguna de esas cosas te hace senior. He conocido gente con diez años de experiencia que en realidad tiene un año repetido diez veces, y gente con tres años que ya piensa como alguien mucho más maduro.

El seniority no se mide en tiempo. Se mide en el tamaño y la ambigüedad de los problemas que puedes cargar tú solo, y al final del camino, en cuánto haces crecer a los que tienes alrededor. Déjame explicar la progresión como la veo después de años construyendo software y formando equipos.

Junior: aprende a ejecutar

El junior ejecuta tareas bien definidas. Le das algo claro — “agrega este campo al formulario”, “arregla este bug”— y lo resuelve. A veces necesita que le digan no solo el qué sino también el cómo, y eso está perfectamente bien: para eso está esta etapa.

Su pregunta constante es “¿cómo hago esto?”. Su trabajo es aprender rápido, hacer muchas preguntas — las preguntas son una virtud aquí, no una debilidad— y poco a poco necesitar menos supervisión. El mejor junior no es el que finge saber, es el que convierte cada tarea en aprendizaje y vuelve más fuerte a la siguiente.

El progreso se nota en una sola cosa: cada vez te necesita menos para terminar.

Mid: ya domina el cómo

En algún momento el “¿cómo lo hago?” se convierte en “lo hago”. El desarrollador intermedio ya domina las herramientas. Le das un problema acotado y lo resuelve de punta a punta, sin que tengas que estar encima. Es productivo, confiable, y carga su parte sin drama.

Aquí mucha gente se estanca, y es entendible: ya eres bueno, ya entregas, ya te pagan decente. El error es creer que el siguiente salto consiste en saber más. Aprender el framework de moda, otra base de datos, otro lenguaje. Eso suma, pero no es lo que te convierte en senior. El salto a senior no es de conocimiento. Es de juicio.

Senior: sabe qué no construir

Aquí está la diferencia que más cuesta entender hasta que la ves de cerca: lo que distingue a un senior no es técnico, es de criterio.

Un senior maneja la ambigüedad. Le das un problema mal definido — que es como llegan casi todos los problemas reales— y él lo define. Encuentra el problema de verdad detrás de lo que te pidieron, que muchas veces no es lo que dijeron que querían. Anticipa lo que se va a romper antes de que se rompa. Piensa en el costo de mantener eso dentro de dos años, no solo en hacerlo funcionar hoy. Pesa el lado del negocio, no solo el técnico.

Y, contra toda intuición, a veces el mejor trabajo de un senior es convencer al equipo de no construir algo. La función que nadie va a usar, la abstracción elegante que nadie va a entender después, el sistema sobrediseñado para un problema que aún no existe. Borrar código, simplificar, decir “esto no vale la pena” — eso también es seniority, y de la más valiosa.

Su pregunta ya no es “¿cómo lo hago?” sino “¿deberíamos hacer esto? ¿qué pasa cuando crezca diez veces? ¿quién lo va a mantener?”. Piensa en sistemas, no en tareas.

Y empieza algo nuevo: a multiplicar. Sus revisiones de código hacen mejores a los demás. Las decisiones que toma las heredan otros. Sin pedírselo, ya está elevando al equipo. Ese instinto es justo el puente hacia lo siguiente.

Líder técnico: su producto ya no es el código, es el equipo

Aquí está el giro de carrera peor entendido de toda la industria.

Cuando pasas a liderar, la métrica cambia por completo: ya no te mides por el código que tú escribes, sino por lo que tu equipo es capaz de lograr. Tu producto dejó de ser el software. Tu producto es el equipo.

Y esto es brutal para mucha gente técnicamente brillante, porque exige soltar precisamente lo que los hizo destacar. Liderar bien significa:

• Dejar que otros resuelvan problemas que tú resolverías más rápido — porque si todo pasa por ti, eres un cuello de botella, no un líder.
• Dejar que se equivoquen, con una red de seguridad, porque así es como aprendieron lo que tú sabes.
• Crear las condiciones para que la gente pueda hacer su mejor trabajo: quitar bloqueos, dar contexto, proteger al equipo del ruido de arriba.
• Traducir entre el mundo del negocio y el mundo técnico, en las dos direcciones.
• Dar crédito hacia afuera, absorber la culpa hacia adentro.

El líder que fracasa casi siempre falla por la misma razón: quiere seguir siendo el héroe que resuelve todo. Sigue clavándose en el código difícil, sigue queriendo ser el que más sabe en la sala. Pero el héroe individual y el multiplicador de equipos son dos trabajos distintos, y no se pueden hacer los dos a la vez.

Dos aclaraciones que importan

Liderar no es un ascenso obligatorio; es un cambio de trabajo. Demasiadas empresas tratan “manager” como el premio por ser buen desarrollador, y así arruinan a un gran ingeniero para crear un líder mediocre. No todo el mundo quiere — ni debe— dejar de programar. Por eso existe la carrera técnica: senior, staff, principal. Puedes crecer, ganar más e impactar muchísimo sin manejar gente nunca. Que nadie te convenza de que la única forma de avanzar es dejando el teclado.

Y los niveles no son una escalera de valor humano. Un junior brillante puede aportar más que un senior amargado en piloto automático. Estas etapas describen el tipo de problema que alguien puede cargar, no cuánto vale como persona ni como profesional.

En resumen

Olvídate de los años. El camino real va de ejecutar tareas (junior), a resolver problemas solo (mid), a decidir qué problemas vale la pena resolver (senior), a hacer que un equipo entero resuelva mejor de lo que tú podrías solo (líder). En cada escalón el cambio no es cuánto sabes, sino qué tan grande y qué tan difuso es el problema que puedes tomar y volverlo claridad para los demás.

Si quieres saber dónde estás, no cuentes años. Pregúntate: ¿qué tan grande es el problema que me pueden aventar sin instrucciones… y qué tanto, al resolverlo, queda mejor la gente a mi alrededor?

En DantukiSoft creemos que formar desarrolladores es parte del trabajo, no un extra. Si te interesa crecer en un equipo que piensa así, escríbenos.