Hay una forma bastante extraña de ascender en ingeniería.
Durante años aprendés a programar mejor. Entendés sistemas cada vez más complejos, tomás problemas que otros no pueden resolver y te convertís en la persona a la que buscan cuando algo se rompe, cuando una decisión técnica se vuelve difícil o cuando hay que sacar adelante algo importante.
Eso funciona. Tu capacidad para resolver problemas te vuelve valioso y, muchas veces, ese valor termina convirtiéndose en una promoción. Un día sos Tech Lead, Engineering Manager o responsable de un equipo.
El cargo cambia de un día para el otro. Tu identidad profesional, no.
Y ahí empieza uno de los problemas más frecuentes del liderazgo en ingeniería.
La habilidad que te trajo hasta acá
Durante buena parte de una carrera técnica existe una relación bastante directa entre lo que hacés y el valor que producís. Hay un problema, lo entendés, escribís código, diseñás una solución, revisás un pull request, encontrás un bug o mejorás una arquitectura. Al final del día podés señalar algo y decir: esto lo hice yo.
No es solamente una forma de trabajar. También es una forma de construir identidad.
Con el tiempo aprendemos qué significa ser buenos en nuestro trabajo. Aprendemos qué comportamientos reciben reconocimiento, cuáles nos hacen sentir útiles y cuáles demuestran frente a los demás —y frente a nosotros mismos— que sabemos lo que estamos haciendo.
Después llega la promoción y la organización hace algo bastante particular: toma a alguien que aprendió durante años a producir valor de una determinada manera y le pide que empiece a producirlo de otra.
Ya no alcanza con resolver: ahora hay que conseguir que otros puedan resolver. Ya no alcanza con tener una buena decisión técnica: hay que construir las condiciones para que el equipo pueda tomar buenas decisiones sin depender permanentemente de vos. Ya no alcanza con hacer: hay que coordinar.
Y eso no es simplemente tener más responsabilidades. Es otro tipo de trabajo.
Henry Mintzberg (1983), en La naturaleza del trabajo directivo, mostró algo que todavía contradice bastante nuestra imagen intuitiva del management. Al estudiar qué hacían efectivamente los directivos, encontró un trabajo atravesado por roles interpersonales, circulación de información y toma de decisiones, caracterizado además por la fragmentación, la variedad y las interrupciones.
El manager no es simplemente alguien que realiza una versión más importante del trabajo que hacía antes. Ocupa otra posición dentro del sistema.
Ese cambio parece obvio cuando lo describimos desde afuera. Es mucho menos obvio cuando somos nosotros los que tenemos que atravesarlo, porque hacer sigue siendo mucho más satisfactorio.
El refugio de lo técnico
Imaginemos un equipo discutiendo una decisión de arquitectura. El nuevo líder escucha durante unos minutos. Conoce el sistema mejor que casi todos, ya vio ese problema antes y, además, probablemente tenga una respuesta razonable. Entonces interviene, explica la solución, la discusión termina y el equipo avanza.
Incluso es posible que haya tomado la mejor decisión.
El problema aparece cuando eso empieza a convertirse en una forma de liderazgo. Cada vez que surge una dificultad, el líder resuelve; cada vez que hay incertidumbre, define; cada vez que alguien se traba, interviene. Desde afuera parece compromiso. Desde adentro también.
Pero poco a poco empieza a ocurrir algo. Las decisiones importantes esperan su opinión, los desarrolladores consultan antes de avanzar, las discusiones técnicas terminan cuando él habla y las tareas complejas empiezan a concentrarse alrededor suyo.
El líder siente que el equipo lo necesita, y probablemente tenga razón.
Lo que quizá no advierta es que está construyendo un equipo que lo necesita.
El experto tiene una tentación
Edgar Schein (2014), en Preguntar con humildad, plantea una tensión especialmente relevante para quienes llegan al liderazgo desde posiciones de expertise. Frente a otra persona podemos relacionarnos desde aquello que ya sabemos —aconsejando, explicando o directamente diciendo qué hacer— o construir una relación basada en una curiosidad genuina por aquello que todavía no sabemos.
Para Schein (2014), preguntar con humildad supone precisamente aprender a preguntar en lugar de asumir que nuestra posición, conocimiento o experiencia nos obliga a tener inmediatamente la respuesta.
La idea resulta particularmente incómoda en ingeniería porque durante años aprendimos exactamente lo contrario. Nos volvimos valiosos porque sabíamos, porque encontrábamos el problema, porque teníamos la respuesta, porque podíamos resolver.
No se trata, por supuesto, de que el líder nunca deba dar respuestas. El problema aparece cuando darlas se convierte en su forma predominante de aportar valor, porque cada respuesta produce dos efectos. Uno es inmediato y evidente: resuelve el problema. El otro es menos visible: modifica la relación entre quien pregunta y quien responde.
Si ante cada dificultad importante el líder aporta la solución, el equipo aprende algo además de la solución técnica. Aprende dónde reside la autoridad para resolver.
Por eso una intervención puede ser técnicamente correcta y organizacionalmente contraproducente. Resolver el problema de hoy y desarrollar la capacidad del equipo para resolver los problemas de mañana no son necesariamente la misma cosa.
Ser necesario es una sensación peligrosa
Hay algo profundamente gratificante en ser la persona que sabe, especialmente después de una carrera construida alrededor de esa capacidad. Por eso delegar puede ser intelectualmente sencillo y emocionalmente difícil.
No se trata solamente de entregar una tarea. A veces implica renunciar a una fuente de reconocimiento. Si otro diseña la solución, otro escribe la parte más difícil y otro se convierte en referencia técnica, aparece una pregunta que rara vez se formula explícitamente:
¿Dónde está ahora mi valor?
Esa pregunta explica más comportamientos de liderazgo de lo que solemos admitir. Explica al Tech Lead que revisa cada decisión, al manager que sigue entrando en todos los detalles técnicos, al líder que delega tareas pero conserva las decisiones y al que dice que su equipo todavía “no está preparado” mientras interviene cada vez que alguien intenta asumir más responsabilidad.
No necesariamente hay mala intención. Muchas veces hay una identidad profesional que todavía no encontró dónde apoyarse.
El cuello de botella puede ser excelente
El problema se vuelve más difícil de detectar porque, durante un tiempo, este tipo de líder puede producir muy buenos resultados. Resuelve rápido, evita errores, destraba al equipo, conoce el sistema y los stakeholders confían en él porque siempre tiene una respuesta.
Justamente por eso el problema puede permanecer invisible.
Un cuello de botella no tiene que ser incompetente. Puede ser la persona más competente del equipo. De hecho, cuanto mejor sea resolviendo, más fácil es que la organización aprenda a depender de él.
El costo aparece después. Las decisiones no escalan, el equipo desarrolla menos autonomía, las personas con potencial encuentran menos espacio para crecer y el líder empieza a trabajar cada vez más horas porque todo parece necesitar su participación.
Cuando finalmente intenta delegar descubre algo paradójico: nadie está preparado para asumir aquello que nunca tuvo oportunidad de practicar. Entonces confirma su sospecha original: todavía me necesitan.
El círculo se cierra.
No todos los problemas deben ser resueltos por el líder
Ronald Heifetz (1997), en Liderazgo sin respuestas fáciles, propone una distinción especialmente útil para entender este problema: la diferencia entre los problemas técnicos y los desafíos adaptativos.
Un problema técnico puede abordarse recurriendo a conocimientos, procedimientos y capacidades que ya existen. Puede ser difícil, incluso extremadamente difícil, pero existe un saber capaz de enfrentarlo. Los desafíos adaptativos son diferentes. No alcanza con encontrar al experto adecuado y pedirle la solución; parte del problema consiste precisamente en que las personas involucradas tienen que aprender algo nuevo, modificar comportamientos, revisar supuestos o desarrollar capacidades que todavía no poseen (Heifetz, 1997).
De ahí surge una idea particularmente importante para el liderazgo: hay situaciones en las que el trabajo del líder no consiste en apropiarse del problema, sino en devolver parte del trabajo a quienes necesitan enfrentarlo.
Para alguien que construyó su identidad siendo un gran solucionador, la idea puede resultar incómoda. En ingeniería, además, convivimos permanentemente con ambas clases de problemas. A veces hay un incidente crítico y necesitás a la persona que más sabe tomando una decisión en minutos. Pero otras veces el problema es que el equipo no tiene suficiente criterio arquitectónico, que dos personas no consiguen trabajar juntas, que nadie asume una decisión ambigua o que cada dificultad termina escalando al Tech Lead.
En esos casos, intervenir y resolver puede producir exactamente el efecto contrario al buscado: el problema desaparece, pero la incapacidad que lo produjo permanece.
Tu unidad de trabajo cambió
Quizás una de las transformaciones más difíciles del liderazgo sea aceptar que el resultado de tu trabajo empieza a ser menos visible.
Un developer puede terminar una funcionalidad. Un líder puede pasar una semana construyendo contexto para que una conversación ocurra mejor dentro de tres meses, detectar un conflicto antes de que explote, ayudar a alguien a desarrollar criterio, conseguir que dos equipos que se bloqueaban empiecen a coordinarse o tomar una decisión incómoda que no produce ningún resultado inmediatamente visible.
Puede incluso hacer un trabajo excelente y que nadie pueda identificar con precisión qué hizo, porque muchas veces el resultado del liderazgo aparece en el trabajo de otros.
Peter Drucker (2014), en El ejecutivo eficaz, pone el foco precisamente en la contribución. Para el trabajador del conocimiento no alcanza con estar ocupado ni con medir su valor por la cantidad de actividad que produce. La pregunta relevante es cuál es su contribución a los resultados de la organización.
Para un líder de ingeniería, esa distinción obliga a cambiar la unidad con la que mide su propio trabajo. En lugar de preguntarse únicamente “¿qué resolví hoy?”, empieza a aparecer una pregunta diferente:
¿Qué puede resolver este equipo porque yo estoy haciendo bien mi trabajo?
La diferencia parece pequeña. No lo es.
En la primera pregunta, vos seguís siendo el centro del sistema. En la segunda, tu trabajo consiste en construir un sistema que pueda funcionar cada vez mejor sin necesitarte en el centro.
Liderar no es dejar de ser técnico
Nada de esto significa que un líder de ingeniería tenga que alejarse del código, perder profundidad técnica o convertirse en alguien que solamente organiza reuniones. Ese es un falso dilema.
La experiencia técnica sigue siendo parte del trabajo. Permite hacer mejores preguntas, entender riesgos, detectar problemas, discutir trade-offs y acompañar decisiones complejas. La diferencia está en para qué se usa esa capacidad.
Podés usar tu experiencia para demostrar que sabés más o para conseguir que el equipo piense mejor. Podés entrar a una discusión para dar la respuesta o para hacer visible una variable que nadie estaba considerando. Podés corregir una decisión o ayudar a que alguien desarrolle el criterio necesario para corregirla la próxima vez sin vos.
La habilidad técnica sigue ahí. Lo que cambia es su función.
Probablemente ahí esté una de las diferencias fundamentales entre expertise y liderazgo. El experto utiliza su conocimiento para resolver problemas; el líder también tiene que preguntarse qué capacidades está construyendo cada vez que decide resolver uno.
La promoción que todavía falta
Las organizaciones pueden cambiar cargos bastante rápido. Cambiar identidades lleva más tiempo.
Por eso convertirse en líder no ocurre necesariamente cuando alguien actualiza tu puesto en el organigrama. Ocurre cuando empezás a encontrar valor en cosas que antes podían parecer secundarias: una persona que crece, una decisión que ya no necesita pasar por vos, un conflicto que el equipo aprende a procesar o un sistema que funciona aunque estés de vacaciones.
Hay algo incómodo en esa transición. Para convertirte en un buen líder probablemente tengas que dejar de demostrar, todo el tiempo, algunas de las cosas que te permitieron llegar hasta ahí. No porque hayan dejado de ser valiosas, sino porque ahora tienen que estar al servicio de otra cosa.
Tu trabajo cambió cuando te promovieron.
La promoción más difícil ocurre después: cuando cambia la forma en que entendés tu propio valor.
Referencias
Drucker, P. F. (2014). El ejecutivo eficaz. Penguin Random House Grupo Editorial Argentina.
Heifetz, R. A. (1997). Liderazgo sin respuestas fáciles: Propuestas para un nuevo diálogo social en tiempos difíciles (J. Piatigorsky, Trad.). Paidós.
Mintzberg, H. (1983). La naturaleza del trabajo directivo. Ariel.
Schein, E. H. (2014). Preguntar con humildad: El sutil arte de pedir en vez de exigir (D. Menezo García, Trad.). Empresa Activa.