Por mucho tiempo, tu chamba se ha sentido relativamente cómoda porque cuando de escribir código se trata, la verdad es que tienes las reglas bien claras. Haces algo y pasa algo. No lo haces y no pasa nada. El código compila o no compila. Los tests pasan o fallan. El deploy sube o se cae. Incluso cuando algo se rompe, sabes dónde puede encontrar respuestas: hay logs, métricas, dashboards. Tienes un lugar concreto donde meter las manos.
Tu entorno te regresa feedback inmediato, y ese feedback casi siempre es binario, o si no, por lo menos predecible, determinístico.
Ese tipo de trabajo entrena al cerebro para pensar de una forma muy específica: asumir que los problemas tienen una solución clara y que, con suficiente habilidad técnica, siempre es posible encontrarla. Igualito que un cachorro eventualmente entiende que levantar la patita == galleta, gracias a tanta repetición internalizaste que escribir código es una manera segura de esperar algún tipo de recompensa —económica, social, intelectual, organizacional.
Esto funciona, y muy chingón, mientras estás operando en un ambiente donde lo único que te tiene que preocupar es cómo haces las cosas, más que el por qué las haces. Cuando tienes que comenzar a preocuparte por cosas menos claras, como estrategia de negocios, priorización de proyectos, resolución de conflictos, etc., este modelo mental deja de ser efectivo. Y es cuando comienzas a valer madre.
Cuando se trata de “dar el siguiente paso” en una carrera en software, lo que nos mueve el tapete a muchos es que los problemas que nos ponen enfrente ya no se pueden resolver escribiendo más o mejor código. Yo sé que me costó trabajo, y es algo que le digo a otros managers y líderes en sesiones de coaching: hacer las paces con que mi chamba ya no es lineal ni puedo mandar un Pull Request para resolver un problema fue de las adaptaciones más grandes que me tocó hacer en mi transición hacia Engineering Manager.
Pero ojo: no es que necesites convertirte en Engineering Manager para pasar por esta transición. En 2026, mucho más marcado que en años anteriores, comenzar a lidiar con estas ambigüedades es una tarea que cada vez más va a ser una expectativa de contribuidores individuales. En La definición de Full Stack Developer cambia para el 2026 escribí:
Cuando escribir código se vuelve barato, abundante y automatizable, lo que empieza a importar es todo lo demás: entender el problema correcto, navegar organizaciones, influir en decisiones, traducir necesidades humanas en sistemas que funcionen.
Dicho de otra forma: ser un Full Stack Developer ya no se trata de lenguajes de programación y frameworks, sino de habilidades sociales, políticas y de desarrollo de producto; de qué tan bueno eres hablando con personas que no tienen background técnico; de tu capacidad integral de resolver problemas.
A veces ni sabes que estás pasando por esta transición
Uno de los primeros síntomas de este cambio te agarra de bajada: las respuestas empiezan a sentirse incompletas. Haces preguntas razonables y recibes respuestas que no terminas de comprender. No es que te estén queriendo atorar a propósito, sino el hecho de que el problema ya no vive en un dominio técnico. Preguntas qué es importante y te hablan de preocupaciones, de riesgos, de cosas que podrían pasar si no le pones atención no a un problema, sino a una categoría de problemas. No hay una lista concreta de tareas, ni un “haz esto y listo”. Y, más críticamente, tampoco hay garantías de que la dirección en la que vas sea la correcta.
Se siente ambiguo. Poco accionable. Como si te estuvieran dejando demasiado espacio para interpretar. Para el ingeniero con I mayúscula, acostumbardo a pensar en problemas determinísticos, esto no tiene sentido. Pero cuando se trata con personas, nada es determinístico.
Cuando alguien es responsable de un resultado, su forma de pensar y de hablar cambia. Ya no se enfoca tanto en lo que hay que hacer, sino en lo que podría salir mal. Ya no optimiza únicamente para ejecución, sino para reducir (y no necesariamente eliminar) incertidumbre. Para alinear objetivos. Para prevenir que se descarrile el progreso.
Eso suele confundirse con falta de claridad, cuando en realidad es una señal de que el problema ya no se resuelve en el mismo nivel que antes. El valor deja de estar en ejecutar bien lo que te dicen y empieza a estar en entender lo suficiente el contexto como para anticiparte. En leer lo que no está escrito. En notar riesgos cuando todavía no son obvios, y cuando todavía es barato hacer algo al respecto. El trabajo deja de ser puramente reactivo. Se vuelve interpretativo. Y eso incomoda, sobre todo cuando vienes de un entorno donde la certeza era parte fundamental del día a día.
El impulso natural es intentar resolver esta nueva etapa con las herramientas de la anterior. Seguir buscando instrucciones claras, validación explícita, alguien que te diga exactamente qué hacer y cuándo hacerlo —lo que antes podías ver en tu test suite en verde, o en el compilador sin warnings.
Pero ese alguien ya no puede existir de la misma manera. Y no mames cómo da miedo darse cuenta de esto.
Aquí es donde muchos ingenieros se atoran, porque se abren dos caminos: o cachas que más y mejor código no es ni será la herramienta que te ayude a darle la vuelta a la situación y te pones en serio a desarrollar otras habilidades; o te montas en tu macho y compras otro curso de arquitectura en Platzi.
Cómo bajar la pelota
Una forma útil de entender este cambio es observar cómo se transforman las preguntas que importan. Durante mucho tiempo, casi todo gira alrededor del qué: qué hay que construir, qué falta, qué se rompió, qué sigue. Después, el centro de gravedad se mueve al por qué: por qué esto importa ahora y no después o viceversa, por qué este riesgo es aceptable y este no, por qué vale la pena invertir tiempo aquí y no en otra cosa.
Estas preguntas no tienen respuestas definitivas. No pasan test suites ni se validan con un dashboard. Se sostienen en criterio, contexto y experiencia acumulada. Y el criterio no se delega fácilmente.
Otro síntoma claro de esta transición es que ciertas actividades dejan de sentirse “extra” y se vuelven parte central del trabajo. Leer documentos de planeación, entender iniciativas antes de que se conviertan en tareas, revisar propuestas cuando todavía están formándose.
Llegar un paso antes cambia la naturaleza del impacto. Te permite hacer mejores preguntas, señalar riesgos cuando todavía no son problemas y evitar fricciones que nunca van a aparecer en un postmortem porque alguien las vio venir. Ese tipo de trabajo no siempre se mide bien, pero suele notarse cuando falta. Es la misma naturaleza de un equipo de plataforma: si hace bien su chamba pasa desapercibido, lo que hace que alguien que no entienda el valor que ese equipo aporta se comience a cuestionar si debería existir en primer lugar. Los efectos de haber deshecho el equipo solamente se vuelven evidentes meses después, cuando ya alguien no puede mandar un parche a producción sin tirar el servicio completo.
Durante años, sobre todo en entornos técnicos, confundimos profesionalismo con neutralidad. Como si mostrarse como persona fuera una distracción, o como si lo ideal fuera operar como piezas intercambiables dentro de un sistema bien diseñado. Las organizaciones intentan funcionar así. Las personas no.
¿Entonces cómo es, si no escribiendo código?
Cuando el trabajo se vuelve más ambiguo, la confianza deja de ser un nice to have y se convierte en una condición necesaria. Es lo que permite decir “esto me preocupa”, “no estoy seguro”, o “creo que aquí hay un riesgo” sin que eso se lea como incompetencia. Sin confianza, todo se vuelve defensivo. Con confianza, los equipos se vuelven adaptables.
No estoy hablando de esa “confianza” que más bien es convicción de que tú estás bien y otros mal. Me refiero a la confianza de saber que todos los que están colaborando quieren lo mismo, están trabajando hacia el mismo objetivo, y que nadie te va a echar en cara el error que inevitablemente vas a cometer.
Se construye con herramientas. Se construye humanizando la relación y recordando que del otro lado hay alguien con contexto, cansancio, intereses y límites. No es un tema de ser más amable. Es un tema de crear las condiciones organizacionales para que esta confianza nazca y crezca: incentivos correctos, procesos definidos, oportunidades de aportar y evolucionar la forma de operar.
Pero nada de eso importa si no cambiamos también la definición de éxito: el output tiene que dejar de ser únicamente el proyecto, y tenemos que voltear a ver al equipo. Features, deadlines y resultados siguen importando, pero se vuelven efectos secundarios de algo más fundamental: un grupo de personas que confía lo suficiente entre sí como para operar sin fricción constante.
Un equipo así puede absorber cambios, adaptarse y seguir funcionando incluso cuando alguien clave no está disponible. Cuando todo depende de una sola persona, el sistema es frágil. Cuando la confianza está distribuida, el sistema escala. Nada de eso ocurre por accidente. Nada de esto se siente natural al inicio.
Venimos de años entrenando el cerebro para buscar certeza, feedback inmediato y validación clara. De pronto, las respuestas tardan más, el feedback se vuelve difuso y las decisiones pesan distinto. No es que seas peor en tu trabajo. Es que el trabajo cambió.
La incomodidad no es una señal de incompetencia, sino de transición. Estás dejando un mundo donde casi todo era binario y entrando a otro donde el valor está en el juicio, no en la ejecución perfecta.
Ese es el verdadero cambio de nivel. Eso, por lo menos para mí, es la verdadera marca de alguien sénior.
Deja un comentario