El punto de partida
Cuando asumí la responsabilidad del equipo, la situación era complicada. No se nos veía como un equipo con rumbo ni con una estrategia clara. Incluso dentro del propio management había dudas de si valía la pena mantenerlo o si era mejor disolverlo y repartir sus servicios entre otros equipos. En términos de percepción, no éramos fuertes ni en ingeniería ni en producto, y esa sombra nos acompañaba en cada conversación.
El diagnóstico
Pronto entendí que los problemas eran múltiples y, como suele ocurrir, no se reducían a una sola persona. Cada trimestre nos fijábamos objetivos pequeños, dispersos, que parecían más una lista de tareas inconexas que una dirección clara hacia un usuario o un impacto real. No había sensación de avance ni de logro.
En el ámbito técnico, el equipo se apoyaba mucho en su Tech Lead. Su conocimiento profundo del dominio era un activo importante, pero esa misma concentración de expertise derivaba en una dinámica donde los demás no alcanzaban toda la autonomía deseada. Esto no era tanto un fallo individual como un síntoma de cómo estaba configurada la responsabilidad dentro del equipo.
Mirando atrás, creo que el mayor error fue mío. Como Engineering Manager no fui lo suficientemente claro ni contundente en trasladar la urgencia de la situación. No di a tiempo el feedback honesto que podía haber ayudado a acelerar el cambio. En cierto modo, fui demasiado tolerante con una dinámica que ya mostraba señales de estancamiento. Esta falta de claridad inicial contribuyó a que el equipo siguiera en un ecosistema en el que nos costaba mostrar tracción y generar confianza.
Decisiones difíciles
La primera decisión vino acompañada de una circunstancia inesperada. El Tech Lead decidió moverse lateralmente y volver a un rol de backend, donde se sentía más cómodo y podía aportar con más foco. Vi en ese movimiento una oportunidad: quedarme yo de forma temporal al frente del equipo como Tech Lead. De esa manera podía asegurar estabilidad técnica y, al mismo tiempo, tomar el control de la dinámica general.
Al mismo tiempo, introduje nuevos perfiles en el equipo. Incorporé a un senior interno con experiencia consolidada dentro de la empresa. Su llegada me permitió liberarme espacio para dedicarme a lo que realmente necesitaba atención: el cuarteto formado por Tech Lead, Product Manager, Process Owner y Product Designer, cuyas relaciones estaban tensionadas. Mientras él se ocupaba de elevar la calidad y las prácticas de ingeniería, yo podía enfocarme en desatascar esas dinámicas. También sumé a un perfil senior externo, alguien que venía de fuera de la organización y que aportaba una mirada fresca y distinta, rompiendo inercias que nos anclaban al pasado.
En conjunto, estas decisiones representaron un reset controlado: crear condiciones para reconstruir sobre bases más sólidas, tanto en lo técnico como en lo relacional.
El proceso de reconstrucción
Mi foco inicial estuvo en el área de ingeniería, donde tenía libertad total para actuar. Ajusté los rituales: las dailies pasaron a ser breves, concisas, sin historias largas ni rodeos innecesarios. Las retrospectivas dejaron de ser sesiones para lamentarse y se transformaron en espacios para aprender de lo que había funcionado o no en el sprint y decidir qué cambiar en el siguiente. Y sobre todo, fui constante en el feedback. A cada persona le compartí de forma cruda y transparente cómo era percibido, dónde estaba parado y qué camino de mejora debía recorrer. La claridad era mi mejor herramienta.
El proceso no fue fácil. Al principio hubo resistencias y dudas legítimas sobre si realmente algo iba a cambiar. Pero poco a poco, gracias a la constancia y al compromiso, la dinámica empezó a transformarse. El ambiente fue mejorando, las entregas empezaron a ser más claras y la percepción externa, lentamente, se movió en la dirección correcta.
Los resultados
El resultado no se alcanzó de un día para otro. Se fue construyendo paso a paso durante un año completo. El progreso se reflejó sobre todo en la manera en que empezamos a plantear y alcanzar los objetivos trimestrales. Dejamos atrás la dinámica de pequeñas tareas inconexas y comenzamos a trabajar con dirección, con un plan más estructurado y con una visión de mayor recorrido.
En el primer trimestre abordamos un gran refactor del backend. Entendíamos que una parte de nuestra lentitud y frustración provenía de un sistema con demasiado legacy, que nos condicionaba y frenaba. Fue un esfuerzo exigente, pero necesario para liberar al equipo y sentar bases sólidas.
A partir de ahí, trimestre a trimestre, fuimos moviéndonos hacia un trabajo mucho más centrado en el usuario y en la entrega de valor. Cada objetivo ya no era una pieza aislada, sino que respondía a un plan coherente y a una narrativa clara de impacto. Esa transición fue clave: nos dio confianza, nos permitió mostrar avances tangibles y, poco a poco, cambiar la percepción externa sobre lo que el equipo era capaz de lograr.
También se notó fuera del equipo. A lo largo del año, en cada quarter la percepción del upper management fue mejorando: los objetivos definidos tras el refactor fueron bien recibidos y muy valorados por su coherencia y tracción. La conversación pasó de cuestionar nuestra continuidad a respaldar el rumbo y a preguntarnos cómo acelerar. Ese cambio de tendencia fue, en sí mismo, una señal de que el plan estaba funcionando.
Aprendizajes
De esta experiencia me quedo con varias lecciones. La primera, que los cambios profundos tardan mucho más de lo que uno imagina al comienzo. No basta con introducir un par de ajustes: se requiere constancia, paciencia y la disposición a mantener el rumbo durante meses.
También aprendí que el feedback honesto y directo es irremplazable. Si uno suaviza demasiado el mensaje o evita la incomodidad, lo que consigue es retrasar la mejora. En mi caso, el mayor error fue no haber sido claro desde el principio; esa falta de contundencia permitió que se consolidaran dinámicas poco sanas.
Aprendí también que para provocar un cambio real en un equipo no basta con ajustar procesos o discursos: hay que introducir cambios tangibles. Cambiar personas de equipo, moverlas a otros contextos o incorporar gente nueva con ojos frescos son medidas que ayudan a romper hábitos y dinámicas enquistadas con mayor rapidez. Son decisiones difíciles, pero aceleran la transformación y envían una señal clara de que el cambio va en serio.
Otra lección clave es que los problemas de un equipo nunca se deben a una sola persona: son una combinación de contexto, relaciones, expectativas y liderazgo. Eso me enseñó a mirar con una lente más amplia antes de señalar causas.
Finalmente, confirmé dos cosas esenciales: la importancia de no rendirse —mantener una visión clara del destino y confianza en que se puede llegar— y la humildad de reconocer que no se puede hacer todo en solitario. Pedir ayuda al upper management en momentos críticos fue lo que nos permitió seguir avanzando cuando el camino se atascaba.
Durante este año he usado mucho una metáfora que me ayudaba a transmitir esta idea. Los jugadores de fútbol de los equipos top suelen tener las piernas cansadas porque juegan varias competiciones al mismo tiempo. Si quieres estar en todas las competiciones y optar a la victoria, el tradeoff es asumir un esfuerzo extra. Con los equipos pasa lo mismo: aspirar a más exige aceptar que habrá momentos de desgaste, y es precisamente ahí donde la resiliencia y el apoyo mutuo marcan la diferencia.
Al final, esta no es solo la historia de un equipo que salió adelante. Es también un recordatorio de que, con honestidad, autocrítica, decisiones valientes y perseverancia, incluso las crisis más profundas pueden convertirse en historias de éxito.
