Me preparé para la entrevista como arquitecto de software.
Repasé patrones de diseño. Dominio, capas, principios SOLID, decisiones de escalabilidad. Sabía que el rol se llamaba Tech Lead, pero en mi mente los dos conceptos vivían en el mismo cajón: alguien que conoce la arquitectura del sistema y desde ahí guía al equipo. Eso hacía yo. Eso era lo que iba a demostrar.
El problema es que no me preguntaron sobre arquitectura. Me preguntaron sobre el equipo.
¿Cómo manejas a alguien que no entrega? ¿Cómo empujas a un developer que ya domina su área hacia algo nuevo? ¿Qué haces cuando hay fricción entre dos integrantes?
Respondí. Pero mis respuestas tenían un ángulo técnico que la entrevista no pedía. Hablé de estructura cuando me pedían comportamiento. Hablé de diseño cuando me pedían relaciones.
Cuando salí, lo supe.
La diferencia entre un Arquitecto de Software y un Tech Lead no es de jerarquía —es de enfoque.
El arquitecto vive en el sistema: toma decisiones de estructura, define las reglas del juego técnico, cuida que la solución resista el tiempo y el crecimiento. Es quien dibuja los diagramas que el equipo tarda meses en entender del todo.
El Tech Lead vive en el equipo: su trabajo no es decidir la arquitectura sino asegurarse de que cada persona que trabaja dentro de esa arquitectura esté haciendo su mejor versión posible de ese trabajo. Son roles distintos. En equipos pequeños a veces los carga la misma persona —y ahí está la trampa—. Porque cargarlos a la vez no es lo mismo que saber cuándo usar cuál.
Yo los confundía. Y no me di cuenta hasta que la entrevista me lo mostró.
Después de ese encuentro, hice algo que no siempre hago: reconstruí las respuestas que hubiera dado si hubiera entendido entonces lo que entiendo ahora.
La más importante era esta: un Tech Lead es servicial.
No en el sentido corporativo de "estar disponible". Sino en el sentido literal: su labor principal no es producir código —es hacer que los demás produzcan mejor código. Muestra lo que sabe a quien lo necesita. Comparte cómo resolvió un problema similar. Señala qué estudiar. Hace pair coding cuando alguien está atorado. Dice «yo lo veo así» y luego pregunta cómo lo ve el otro.
He tenido la suerte de aprenderlo de varias personas, cada una a su manera. Pero el patrón siempre fue el mismo: cuando llegabas con un problema, no lo resolvían por ti. Te llevaban hasta donde podías resolverlo solo. Te dejaban más capaz que como llegaste. Esa es la diferencia entre alguien que sabe y alguien que lidera.
Hay algo que me costó aceptar: esa vocación de servicio no la desarrollé solo trabajando. La heredé.
Mi mamá siempre tuvo esa forma de estar disponible sin hacerlo un peso. De ayudar sin llevar la cuenta. Cuando pienso en por qué me siento cómodo explicando, compartiendo, invirtiendo tiempo en que alguien entienda algo —reconozco eso. No es una habilidad que practiqué; es algo que vi tan seguido que se volvió natural.
En software, eso es un activo. En liderazgo, es quizás el activo más difícil de enseñar.
La segunda cosa que hubiera dicho en esa entrevista: un Tech Lead es retador.
Servicial no significa cómodo. Significa que te importa el crecimiento del otro —y el crecimiento casi siempre incomoda.
Un buen líder técnico empuja a su equipo fuera de lo que ya domina. No porque quiera que sufran, sino porque sabe que quedarse dentro del territorio conocido es una forma lenta de estancarse. Y estancarse en software es quedarse atrás. Los que avanzan no son siempre los más brillantes; son los que siguen encontrando cosas nuevas que los retan.
La tercera y la cuarta van juntas: respetuoso y amable. No como valores de HR —como condición de trabajo.
No hay nada más fluido que un equipo donde cada persona hace lo que tiene que hacer sin fricciones: sin fricciones con el producto, sin fricciones con los compañeros, sin fricciones consigo misma. Ese estado no llega solo. Requiere un ambiente donde la gente puede equivocarse sin miedo, preguntar sin pena y decir «no entendí» sin que eso tenga costo.
Un líder que grita, que humilla, que es celoso con el conocimiento, rompe ese flujo. Y una vez roto es difícil reconstruirlo.
(El perfil del hacker solitario de película —ese que no habla, que no comparte, que tiene el conocimiento encerrado— existe. Y puede tener talento real. Pero un equipo que depende de ese talento sin transferirlo es frágil. Cuando esa persona se va, el equipo vuelve a cero. Muchas veces ni es su culpa; nadie le enseñó que compartir también es parte del trabajo.)
Cuatro principios. Uno de los cuales no me preguntaron en esa entrevista —pero debí haber articulado igual:
Servicial · Retador · Respetuoso · Amable
No son los únicos. Pero son los que, cuando miro hacia atrás en equipos que funcionaron de verdad, están todos presentes. Y cuando miro equipos que no funcionaron, falta al menos uno.
No llegué a esa entrevista completo. Casi nunca se llega así. La distancia entre quién eres y quién necesita ser el rol a veces es grande, a veces es pequeña —pero siempre hay distancia—. Lo que importa es saber cuál es.
Ahora sé cuál era la mía.
ArchMindset — software, equipos, y lo que aprendí cuando todo tronó.
← Todos los artículos