Soy Tech Lead y no me hacen caso. ¿Qué hago?
Cómo ganarte el derecho a influir en tu equipo
En junio de 2018 entré como Backend Chapter Lead en mytaxi (FREE NOW), un competitor de Uber en el sector del ride-hailing. Estaba buscando una oportunidad para crecer en el liderazgo técnico. La verdad, no sabía ni muy bien qué quería decir “Chapter Lead”. Buscando un poco, vi que era parte del modelo de squads (equipos) y chapters (dominios horizontales como iOS, Android, Backend, Data, etc.) de Spotify. Y tribes (conjuntos de squads organizados en dominios verticales; p. ej., todo lo relacionado con el conductor).
Ese rol tenía un doble componente:
Liderazgo técnico de backend (TL) mediante buenas prácticas y con énfasis en la mejora continua. En esa época, mytaxi crecía bastante en tráfico. Algunos de sus servicios — por ejemplo, el que se usaba para incentivar a los conductores a hacer más carreras — presentaban picos de tráfico significativos y requerían mejoras, rearquitecturas, etc. Por otro lado, había unos 200 y pocos servicios que gestionar, en total.
Gestión de personas, de forma horizontal. La idea era que los backends reportaran todos a mí o a Ariel — el otro Chapter Lead —, independientemente del equipo. No es un set-up muy ortodoxo, pero en esa época entraban quizá 3-5 backends cada mes y había la necesidad de hacer que esta gente se volviese productiva lo más rápido posible, alinear la arquitectura y el producto no paraba!
Yo venía sin ningún tipo de experiencia previa (formal) como Tech Lead y creo que nunca leí tanto en mi vida como ese mes en que anuncié que dejaba mi trabajo anterior y entraba en mytaxi. No solo eso, sino que nunca había tenido un TL de verdad del que aprender. ¿Qué podría salir mal?
El primer día fue muy divertido. Entro a Slack y me presento al manager de infraestructura/plataforma. Y me dice:
Oye, por cierto, tenéis un incidente en el servicio X. Lo podrías mirar?
Así, en frío. Son las nueve de la mañana de un lunes y tenemos un incidente. ¡Que no sé ni dónde están los logs, Henning! Pasado ese susto inicial, soy capaz de dar con el equipo responsable, que identifica el problema, lo soluciona y todo queda arreglado.
Esta primera interacción me hace ver varias cosas:
Ninguno sabe gestionar incidentes, documentar los problemas encontrados ni comunicar el avance. ¡Empezamos bien!
No hay cultura de hacer una “retrospectiva” (incident review) ni de sacar acciones que eviten ese tipo de incidentes en el futuro
Hay cierto acoplamiento entre dominios. En este caso, se utilizaba el concepto de Impuesto sobre el Valor Agregado (IVA) para dos casos de uso totalmente distintos. Y un cambio en uno de ellos provocó el incidente en el otro.
Mucha gente no sabe depurar (debugging). Me miran como si los logs hablaran conmigo o si fuera Harry Potter.
La parte buena es que había, claramente, mucho que arreglar. Yo tenía bastante claro cómo se podría mejorar la cultura de ingeniería. Encima, tenía el título de Tech Lead. ¡Estaba chupado! O no…
👋 Hola, soy João. Este es el segundo artículo de una serie pensada para Tech Leads y Engineering Managers que quieren liderar con más claridad e intención:
“Soy Tech Lead y no me hacen caso. ¿Qué hago?” ← Este artículo
“KPIs, SLOs y excelencia operacional”. Próximamente. Suscríbete para no perderlo
Continuará…
Estoy escribiendo “El Manual del Tech Lead”, cuyo lanzamiento está previsto para la primera mitad de 2026. Las ideas de esta serie serán su base.
Si quieres unirte a la lista de espera, recibirás un 25 % de descuento en el lanzamiento.
La confianza
Después de ese incidente, creé un documento de incident review y sugerí una pequeña revisión de las tareas que deberían priorizarse para evitar que se repitiera. Me vine arriba y creé una primera presentación para los demás Chapter Leads de backend con una estrategia para el backend. Ya no me acuerdo al 100%, pero había arquitectura hexagonal, una pirámide de pruebas (tests) que incluía tests de contrato para no romper las APIs que usaban las aplicaciones móviles, y más. Pasan los días y pienso:
Mierda, nadie me hace caso. ¡Sí, me he currado un montón las diapositivas y la estrategia!
La razón, hoy en día, me parece obvia: los títulos no confieren influencia. Para influir, es necesario generar confianza. Y yo aún no me la había ganado lo suficiente como para proponer algo tan fundamental. Ya sea a través de mi propia experiencia o de sesiones de coaching, este error lo he visto clavado en varias otras ocasiones a lo largo de mi carrera.
Años más tarde descubrí la célebre ecuación de la confianza de Maister, Green y Galford. Me habría venido de maravilla en aquella época. Dice lo siguiente:
La primera vez que la leí, me explotó la cabeza porque describía exactamente lo que me estaba pasando. Vamos a desglosarla:
Credibilidad: saber de lo que hablas. Tener criterio técnico. Que cuando dices algo, la gente sienta que está bien fundamentado. En 2018 quizá tenía parte de esta credibilidad, pero aún no estaba demostrada en ese contexto, con esa gente, con esos sistemas. Venía de fuera. Y la credibilidad importada siempre vale menos — a menos que vengas de una FAANG o te hayas construido una marca personal — que la credibilidad ganada en el terreno.
Fiabilidad: cumplir lo que dices. Ser constante. Estar cuando toque. En un entorno de alto ritmo como el de mytaxi, esto pesa muchísimo. En esos primeros días yo aún estaba aprendiendo dónde estaban los logs. Es difícil demostrar fiabilidad si ni siquiera controlo el mapa.
Intimidad: que la gente sienta que puede hablar contigo, que no la vas a dejar vendida y que entiendes sus miedos y dudas. Esto, para un TL, es más importante de lo que parece. Sin esta parte, cualquier propuesta técnica se percibe como un juicio. Y cuando las personas se ponen a la defensiva, todo se frena.
Y luego está el denominador: la autoorientación. Cuando tus propuestas parecen responder más a tu agenda que a las necesidades del equipo, la confianza se derrumba. Ese fue mi error. Llegar con una estrategia demasiado pronto, sin haber escuchado, sin haber visto qué necesitaban ellos, sin haberme ganado aún el derecho moral a plantearla.
En otras palabras: aunque mis ideas no fuesen malas, la ecuación no me salía. Tenía algo de credibilidad, un poco de fiabilidad para construir, intimidad aún por crear y demasiada autoorientación. El resultado era obvio: poca confianza.
Dos momentos clave
Con el tiempo me di cuenta de que la confianza no se construye con grandes discursos, sino con acciones concretas que resuelven problemas reales del día a día. Mirando atrás, hubo dos momentos muy claros que aceleraron ese cambio en cómo el equipo me percibía.
Complejidad regulatoria
Como mytaxi competía con Uber en un sector tan regulado como el del taxi, y además con normativas muy locales en toda Europa, la aplicación necesitaba soportar múltiples variantes del mismo flujo. Eso llevó a la proliferación de decenas y decenas de configuration flags repartidas por todos los servicios. El resultado era un caos: nadie sabía con certeza qué estaba activado en cada ciudad, qué afectaba a iOS, qué afectaba a Android o dónde estaba realmente definida cada opción. Para colmo, la configuración vivía dispersa entre unos 200 servicios distintos.
Un día, Maria — Agile Coach — me habló de este dolor de forma muy directa. Y yo hice lo que mejor sabía hacer en ese momento: construir. Monté un portal — un poco cutre, si os soy honesto —, que consultaba las APIs de configuración de todos los servicios y agregaba esa información por funcionalidad, país o ciudad.
De repente, con un vistazo, cualquiera podía saber qué estaba activado y dónde. No era bonito, pero resolvía un problema. Y, sobre todo, demostraba que estaba allí para ayudarles a trabajar mejor (credibilidad), no para imponer una agenda técnica abstracta. Al poco tiempo, otros equipos comenzaron a usar el portal, incluyendo Product Owners, QA y hasta gente de Operations. Sin quererlo, se convirtió en una herramienta de alineamiento organizativo. Y llevó a algo aún más interesante: otros ingenieros empezaron a contribuir.
Al ver el valor que generaba, varios compañeros propusieron mejoras, corrigieron pequeños fallos y añadieron funcionalidades que yo ni había considerado. Uno de ellos creó incluso una pequeña web para visualizar las Zonas de una ciudad, algo que resolvía un dolor histórico para los equipos que trabajaban con geofencing o la asignación de conductor a pasajero. Otro automatizó parte del proceso de actualización de flags. Alguien más añadió métricas para detectar configuraciones inconsistentes entre plataformas.
De pronto, lo que había empezado como un apaño rápido se convirtió en un pequeño ecosistema de herramientas internas que reducía incertidumbre, aceleraba decisiones y, sobre todo, hacía la vida del equipo un poco más fácil cada semana.
Ese efecto dominó me enseñó algo importante: cuando solucionas un problema real y lo haces visible, la gente se suma. La confianza también se construye así, invitando a otros a mejorar lo que empezaste y celebrando que lo hagan mejor que tú.
Depurar
El segundo momento tuvo que ver con algo mucho más humano: ayudar a depurar (debugging). Nunca me he considerado especialmente listo, pero sí he sido siempre muy sistemático al conectar puntos entre mensajes de error, código, hipótesis y comportamiento del sistema. Para mi sorpresa, mucha gente veía esto casi como magia. En realidad no lo era: era una mezcla de experiencia, fundamentos, intuición, saber dónde buscar y no tener miedo de meterme incluso en el código de librerías de terceros.
Empecé a acompañar a compañeros en la resolución de incidentes (intimidad), a enseñarles cómo formular y descartar hipótesis, a leer logs con intención, a diferenciar síntomas de causas. Propuse prácticas de incident review, lo que elevó la calidad de nuestras respuestas y nos ayudó a aprender colectivamente.
Sin darme cuenta, estas dos contribuciones hicieron más por mi reputación que cualquier presentación o strategy deck. Construir algo útil y estar al lado de la gente cuando el sistema arde crea más confianza que cualquier título. Y fue a partir de ahí cuando mis ideas empezaron, por fin, a tener tracción. Curiosamente, estas dos acciones redujeron a cero mi autoorientación. Dejé de pensar en “mi estrategia” y empecé a pensar en “nuestro trabajo”.
Qué dirías a tu yo del 2018?
Al mirar atrás, me quedo con una idea: ningún TL consigue influencia porque “le toca”. Se gana día a día. No con discursos, sino resolviendo los problemas que duelen y estando en los momentos en los que la gente necesita apoyo real.
Si estás en una situación parecida, algunos consejos que me habría gustado recibir en 2018:
Antes de proponer una estrategia, entiende primero qué le duele a tu equipo.
Elige una o dos acciones que aporten valor inmediato y ejecútalas.
Habla menos de arquitectura y más de cómo tu propuesta reduce toil, riesgos o incertidumbre.
No busques demostrar que eres el más listo; busca que los demás puedan hacer mejor su trabajo.
El ciclo de feedback, al contrario del código, es más lento. Se mide en semanas, o meses. Hay que tener paciencia.
Y, sobre todo, recuerda que la confianza es acumulativa. Se gana en cada interacción.
La influencia técnica no empieza con un título, sino con el impacto visible que generas.
Porque cuando un TL no se siente escuchado, la solución no es hablar más fuerte.
Es cambiar la conversación. Y empezar por el único lugar donde de verdad tienes control: tu propio comportamiento.
🎁 ¿Quieres aterrizar esto mañana mismo en tu equipo? Regalo sólo para suscriptores
Muchos Tech Leads no se sienten escuchados porque EMs, TLs y el resto del equipo operan con expectativas distintas que nadie ha explicitado. Esa fricción no se resuelve con más reuniones ni más procesos. Se resuelve con claridad.
Para ayudarte a cerrar esa brecha, he preparado un toolkit de alineación GRATIS con tres herramientas prácticas:
Para Tech Leads: un semáforo de autoevaluación para combatir el síndrome del impostor y entender con precisión dónde estás aportando valor y dónde te estás quemando.
Para Engineering Managers: un semáforo de evaluación para dar feedback objetivo basado en comportamientos, no en sensaciones. Ayuda a tus Tech Leads a tener impacto!
Para el equipo: una plantilla de principios operativos para dejar de discutir las mismas decisiones cada semana y crear criterios compartidos.
Y además, para acompañar este artículo, incluiré un plan concreto para tus primeros 90 días como Tech Lead: qué observar, qué priorizar, qué evitar y cómo generar confianza a través de pequeños pasos visibles. Es exactamente el plan que me habría gustado tener aquella primera semana en mytaxi.
Si ya has descargado el toolkit, no tienes que hacer nada: ya tienes la versión actualizada y recibirás automáticamente el plan de 90 días.
Si aún no estás suscrito, apúntate y te lo envío. Es gratis y te ayudará a pasar de la intención a la acción.
— João