Cuando miro hacia atrás, a ese Lalo que pasó a senior developer, me acuerdo de una sensación medio incómoda, porque por un lado estaba el orgullo de decir “ok, algo estoy haciendo bien”, pero por otro lado empezó a aparecer una responsabilidad que no estaba dentro del editor, ni en el pull request, ni en ese componente de frontend que podía dejar más limpio si me quedaba un rato más.
Yo venía de años haciendo frontend, y creo, sin miedo a equivocarme, que era muy bueno en eso, no el mejor, no excelente (nunca me ha gustado ponerme en ese lugar), pero sí alguien que podía resolver, ordenar, proponer una arquitectura, mirar un problema visual o de estado y encontrar una forma razonable de construirlo.
El problema es que cuando uno empieza a crecer hacia roles más senior, y luego hacia liderazgo técnico, la promoción no viene con un manual que diga “desde hoy tu trabajo cambia así”, entonces uno intenta seguir demostrando valor de la misma forma en que llegó ahí, escribiendo mejor código, revisando más detalles, cuidando cada borde, hasta que te das cuenta de que el equipo, el producto y otras personas necesitan algo más que una buena solución técnica.
Lo perfecto se empieza a volver caro
Hay una frase que me da vuelta hace bastante tiempo, y que de alguna forma hice mía, que dice que lo perfecto es enemigo de lo bueno, y aunque suena simple, cuesta mucho aplicarla cuando durante años nos validamos por dejar el código limpio, bonito, reproducible, bien separado, con nombres que calzan, con componentes que se sienten correctos (esa sensación existe, aunque sea difícil explicarla).
Antes yo buscaba esa perfección en todo, y si había una historia de usuario, una pantalla o una lógica de negocio, mi cabeza se iba rápido a “cómo hacemos esto de la mejor forma posible”, pero hoy miro distinto, porque lo primero que intento revisar es si cumple con los criterios de aceptación, si tiene el coverage que corresponde, si responde a la necesidad del producto y si permite que podamos salir, probar y aprender con algo real.
Esto no significa aceptar cualquier cosa, porque un mal código nos cobra después, y lo cobra caro, pero también aprendí que el código perfecto puede ser una forma elegante de no soltar el control, una manera muy técnica de decir “todavía no está listo” cuando, quizás, lo que pasa es que no queremos que otra persona toque esa parte, o que el equipo avance con una solución que no habríamos escrito igual.
Lector: ¿Entonces ahora da lo mismo la calidad del código?
Yo: Mmmh, no, para nada, y por eso creo que hay que separar calidad de perfección, porque calidad es que el código haga lo que tiene que hacer, que sea entendible para el equipo, que se pueda mantener, que pase las pruebas acordadas y que no rompa lo que ya existe; perfección es otra cosa, muchas veces es una búsqueda personal que puede retrasar una entrega sin agregar valor real al producto.
Escribir menos también puede ser una decisión técnica
En varias experiencias como líder técnico me tocó tener perfiles distintos, en algunas escribía mucho código y gestionaba poco al equipo, y en otras, especialmente en los últimos años, empecé a escribir cada vez menos, no porque el código dejara de importarme, sino porque mi foco empezó a estar en que el equipo pudiera avanzar con claridad y sin depender de que yo estuviera encima de cada línea.
Ahí apareció algo que para mí fue bien concreto: escribir el código justo y necesario para lo que necesitamos hoy, sin hacer sobre ingeniería, porque antes me pasaba que veía muchas casuísticas, muchos “qué pasa si esto”, “qué pasa si esto otro”, y terminábamos diseñando una solución para futuros posibles que todavía no estaban en la mesa.
El software puede mutar, y esto es algo que a veces olvidamos cuando queremos dejar todo resuelto desde el día uno, porque podemos avanzar de forma iterativa e incremental, entregar lo que resuelve el problema actual, mirar cómo se usa, recibir señales del producto, y después mejorar, cambiar o extender, sin convertir cada historia en una arquitectura para los próximos cinco años (y no, no estoy diciendo que nunca haya que pensar en el futuro, pero no todo futuro merece código hoy).
La gente no va a trabajar como uno
Una de las partes más difíciles, y creo que menos enseñadas, es empezar a soltar, porque cuando uno viene de ser fuerte técnicamente es muy tentador mirar lo que otra persona hizo y pensar “yo lo habría hecho distinto”, “yo habría llegado más rápido”, “yo no me habría equivocado en ese caso”, y tal vez sea cierto, pero esa comparación no ayuda mucho si lo que queremos es formar equipo.
Las personas no son uno. Suena demasiado obvio, pero en la práctica cuesta, porque alguien puede tomarse una vuelta más larga, puede necesitar hacer preguntas que para nosotros ya tienen respuesta, puede equivocarse en algo que nosotros ya tenemos incorporado hace años, y ahí el liderazgo no puede ser entrar a corregir todo como si estuviéramos arreglando un archivo mal formateado.
Lo que me ha servido es dar espacio, guiar, corregir cuando corresponde y tratar de no ser impositivo por defecto, porque si cada conversación termina en “hagámoslo como yo digo”, el equipo aprende rápido que opinar no sirve de mucho, y después nos sorprendemos cuando nadie propone, nadie discute o todos esperan que el líder técnico decida hasta el nombre de una variable.
Esto no significa abandonar al equipo, porque soltar no es mirar desde lejos y decir “vean ustedes”, sino estar disponible, hacer preguntas, mostrar alternativas, explicar por qué algo puede traer problemas después, revisar un pull request con intención de ayudar y no de demostrar que uno sabe más, que es una diferencia pequeña en palabras, pero muy grande cuando estás del otro lado recibiendo la revisión.
Alguien tiene que tomar la decisión
A mí me gusta que exista conversación dentro del equipo, que podamos buscar acuerdos, que una decisión técnica no se sienta como algo que baja desde arriba sin contexto, porque cuando las personas entienden la visión del producto y el porqué de lo que estamos haciendo, trabajan con más tranquilidad y también con más criterio para decidir en los detalles.
Pero también aprendí que hay un momento donde la conversación deja de ayudar, o al menos deja de ayudar al avance, y ahí el líder técnico tiene que tomar una decisión, incluso si no es la decisión perfecta, incluso si alguien habría preferido otro camino, porque liderar también es aceptar que una buena decisión a tiempo vale más que una discusión técnicamente infinita.
Eso cuesta, sobre todo cuando queremos ser horizontales y no imponer, pero tomar la decisión no cancela la conversación anterior, la ordena, porque escuchamos, miramos alternativas, entendemos los costos y después alguien tiene que decir “vamos por aquí”, para que el equipo pueda seguir construyendo y el producto no quede detenido en una discusión que ya dio todo lo que podía dar.
Decir no lo sé también lidera
Con el tiempo empecé a valorar mucho más las habilidades blandas, y lo digo así aunque a veces ese nombre suene menor, porque transmitir confianza al equipo, a stakeholders y a program managers no aparece en una prueba unitaria, pero se nota cuando hay presión, cuando algo no está definido, cuando una historia cambia o cuando una decisión técnica necesita ser defendida con calma.
Uno puede saber mucho de ECMAScript, de frontend, de patrones, de rendimiento, de arquitectura, y todo eso sirve, obviamente sirve, pero si cada conversación deja al equipo más ansioso, más confundido o con miedo a equivocarse, entonces algo del liderazgo está fallando, aunque el código que escribamos sea impecable.
Para mí hay una parte bien simple y bien difícil a la vez: ser transparente. Decir “equipo, no lo sé”, “no lo conozco”, “conversemos”, “aprendamos”, en vez de actuar como si uno tuviera todas las respuestas guardadas desde antes, porque el equipo no necesita que uno lo sepa todo, necesita confiar en que si no lo sabemos, lo vamos a conversar de frente.
Creo que prepararse para liderar, especialmente cuando vienes de ser muy bueno en lo técnico, tiene mucho de aceptar esa incomodidad: escribir menos cuando corresponde, decidir antes de que la discusión se vuelva eterna, dejar que otras personas crezcan aunque no lo hagan como uno lo habría hecho, y dar tranquilidad cuando el problema todavía no está completamente resuelto. ¿Qué parte de tu forma de trabajar tendrías que soltar para que otra persona del equipo pueda avanzar sin esperar tu aprobación todo el tiempo?