Siempre me ha caracterizado la competitividad. Busco que mis acciones impacten, que mis desarrollos sean escalables y que mis ideas aporten valor real al negocio. Sin embargo, esta intensidad tiene un costo. En varias etapas de mi vida laboral, ese deseo de “salvar el proyecto” me ha llevado al límite.
Recuerdo que una vez, un CTO me dio una lección que tardé años en procesar: “Debes dejar de pensar que estás apoyando; lo que estás haciendo es alcahueteando. No eres un superhéroe”.
Fue la primera vez que aprendí a decir “no” a los requerimientos extemporáneos y a dejar de solucionar errores ajenos solo por ser más rápido. Antes de ese consejo, yo pasaba noches en vela con una taza de café mientras los verdaderos responsables dormían tranquilos. Mi sentido de pertenencia me estaba consumiendo.
La recaída: La dualidad que agota
Casi tres años después, las circunstancias de un proyecto me llevaron de nuevo a un rol de liderazgo. Un rol que, honestamente, no quería ocupar bajo esas condiciones: debía liderar al equipo y, al mismo tiempo, actuar como desarrollador principal.
En contextos donde liderar implica planear, resolver errores urgentes, interactuar con el cliente y optimizar recursos, sumar el desarrollo activo es una receta para el desastre. Tu cerebro se agota, los picos de cortisol te afectan físicamente y la calidad de las entregas se compromete.
El fenómeno del “Desarrollador Quema Puntos”
En medio de esta saturación, identifiqué algo que denominé “Desarrolladores Quema Puntos”. Equipos que se enfocan obsesivamente en cerrar tickets para cumplir métricas superficiales, dejando de lado la escalabilidad, la calidad y los estándares de arquitectura.
Al estar yo desbordado, el equipo dependía excesivamente de mi criterio para todo. El resultado fue un círculo vicioso: el equipo entregaba lo elemental para que QA no lo rechazara, y si surgían problemas complejos, se esperaba que yo los solucionara para cumplir con los tiempos del cliente.
Levantar la mano no es rendirse
Me cansé. Me estallé. Llegué al punto de burnout nuevamente y tuve que tomar una decisión difícil pero necesaria: levantar la mano y decir que no daba más.
Decidí que no quería seguir dirigiendo bajo ese esquema. Perdí la confianza en el sistema que estábamos construyendo y preferí velar por mi salud y el tiempo de calidad con mi familia. Muchos podrían verlo como una renuncia a un reto, pero yo lo veo como un acto de liderazgo responsable.
Conclusión: El líder sin cargo
Me apego a la filosofía de Robin Sharma: el líder que no tenía cargo. He decidido que puedo aportar mucho más al equipo promoviendo soluciones innovadoras y solucionando errores críticos desde una posición que no comprometa mi integridad física ni mental.
Liderar no es cargar con el trabajo de todos; liderar es saber cuándo el sistema no funciona y tener el valor de proponer un cambio. Hoy, sigo liderando, pero de una forma que me permite seguir siendo un profesional de alto nivel a largo plazo.