Deja de optimizar tu stack, empieza a optimizar tu influencia

Hay un punto en la carrera donde ya no te falta un framework más. Te falta influencia.

Pero como nadie te lo dice así, sigues haciendo lo único que te funcionó hasta ahora: aprender otra herramienta, meterte a otro curso, reescribir otro módulo para dejarlo “bonito”. Y mientras tanto, el roadmap sigue siendo absurdo, las decisiones siguen bajando de la nada y tu impacto real no crece casi nada aunque seas “el/la senior del equipo”.

A partir de cierto nivel, tu stack ya no es React, Go o Kubernetes. Tu stack es incentivos, contexto e influencia.

El mito del senior como “mejor implementador”

La narrativa clásica es simple:

• junior: aprende
• mid: ejecuta
• senior: ejecuta pero más rápido y mejor

Entonces tú haces lo que te prometieron: te vuelves una máquina de shipping. Eres quien rescata el sprint, quien entiende los sistemas legacy, quien arregla el bug crítico el viernes a las 7 pm.

¿Problema? Que eso es ser necesario, no necesariamente tener poder.

Puedes ser el/la que más sabe del sistema… y al mismo tiempo el/la que menos pinta en la mesa donde se decide el futuro de ese sistema. Te llaman cuando ya se tomó la decisión y solo queda “aterrizarlo técnicamente”.

Y duele, porque sientes que “no valoran tu opinión técnica”, pero en realidad hay algo más profundo: nunca invertiste en entender el juego donde se decide qué problemas valen la pena resolver.

Jugar a ser el “mejor implementador” es una forma muy sofisticada de esconderte del trabajo incómodo: negociar, poner límites, decir que no, desafiar un roadmap mal planteado.

Tu stack real a partir de cierto nivel

Imagina que tu “stack senior” fuera una ficha técnica. No diría:

React, Node, microservicios, event-driven, arquitectura hexagonal.

Diría cosas como:

• Lectura de contexto: Qué está intentando lograr el negocio de verdad, más allá del OKR bonito en Notion.
• Cartografía de poder: Quién decide qué, cómo se reparten recursos, quién tiene veto silencioso, quién tiene influencia informal.
• Traducción entre mundos: Cómo explicar riesgos técnicos en lenguaje que finanzas, producto y leadership pueden usar para decidir.
• Diseño de apuestas: No solo “hacer features”, sino proponer apuestas con impacto en métricas y tradeoffs claros.
• Narrativa y visibilidad: Hacer que el trabajo importante se vea, se entienda y se cuente en los foros correctos.

Ese es el stack que te lleva de “buen senior” a alguien que realmente mueve sistemas completos (técnicos y humanos).

La ironía: casi nadie te entrena ahí. La empresa sí te paga cursos de Kubernetes, pero no te enseña a decirle a tu VP “esto que quieres suena bien en slide, pero está completamente desalineado con los incentivos del equipo”.

Síntomas de que sigues optimizando el stack equivocado

Algunos patrones que veo una y otra vez en senior engineers:

• Sabes exactamente qué habría que hacer… pero siempre llegas tarde a la conversación. Te enteras de las decisiones en un Slack thread de 50 mensajes que ya nadie está leyendo.
• Tu feedback se queda en “comentarios técnicos”. Nunca escalas el argumento a: “si hacemos esto así, el incentivo que creamos es X, y eso nos va a morder en seis meses”.
• Todo el mundo te respeta, pero casi nadie te escucha a nivel estratégico. Te piden ayuda para estimar, para revisar diseños, para destrabar PRs… pero no estás en las juntas donde se decide qué proyectos existen.
• Te promocionan “a medias”. Título bonito, más responsabilidad, misma capacidad real de cambiar cosas. Eres “senior” en tu job title, pero “mid” en el esquema de poder e influencia.

Mientras tanto, sigues pensando que la solución es “meterte a ese curso de arquitectura avanzada” o “leer otro libro de patterns”.

De frameworks a incentivos: las preguntas que no estás haciendo

Parte de optimizar tu influencia es cambiar las preguntas que te haces. No es “¿con qué stack se hace esto?”, sino:

• ¿Quién pidió esto de verdad? No el PM que te lo mandó, sino quién va a ganar o perder poder si esto sale bien o mal.
• ¿Qué está optimizando este roadmap? ¿Velocidad? ¿Percepción ante inversionistas? ¿Control político de algún área? ¿Reducir riesgos para alguien en particular?
• ¿Qué incentivos crea esta decisión técnica? ¿Vamos a recompensar hacks rápidos? ¿Vamos a castigar el maintenance? ¿A quién le cae la deuda técnica que generamos hoy?
• ¿Qué métricas dicen que esto es importante? Y si no hay métricas, ¿es una apuesta honesta o un capricho de alguien con suficiente poder?
• ¿Quién puede bloquear esto aunque todo parezca aprobado? El “stakeholder oculto” que no sale en el org chart pero tiene la última palabra.

Estas son conversaciones que no pasan en el repo. Pasan en 1:1s, en juntas aburridas, en Slack DMs. Y sí, son incómodas, pero ahí es donde se define tu capacidad real de mover cosas.

Mini manual de influencia para senior engineers

No necesitas volverte político profesional. Necesitas dejar de jugar en modo “solo código”.

Algunas prácticas concretas:

1. Mapea tu sistema de poder (no tu diagrama de microservicios)

Haz un dibujo tan obsesivo como el de tu arquitectura, pero con personas e incentivos:

• ¿Quién define el roadmap?
• ¿Quién controla los recursos (headcount, presupuesto, prioridades)?
• ¿Quién influye informalmente (la persona que “no tiene rango” pero tumba o impulsa ideas)?
• ¿En qué foros se deciden las cosas de verdad (no siempre es la junta formal)?

Eso te permite dejar de tirar ideas al vacío y empezar a diseñar rutas de adopción real.

2. Haz menos pull requests, pero más propuestas de cambio

En lugar de solo “opinar sobre tickets”, empieza a armar propuestas de cambio:

• Problema concreto y costo de no hacer nada.
• Opciones posibles con tradeoffs.
• Impacto esperado en métricas importantes para el negocio.
• Riesgos y cómo los reducirías.

No es un “rant técnico”, es un memo que cualquier decision maker pueda usar.

3. Diseña tu visibilidad, no la de tu backlog

Influenciar sin que te vean es muy difícil. No se trata de “hacer teatro”, se trata de que el trabajo importante no se pierda:

• Resúmenes cortos y claros de lo que lograste cada trimestre.
• Antes/después de sistemas claves: qué cambió y por qué importa.
• Llevar temas incómodos a espacios donde haya poder para hacer algo, no solo a la queja privada.

4. Aprende a decir “no” sin sonar a “no quiero trabajar”

Decir que no es una skill senior central. No es “esto es imposible”, es:

Si hacemos A y B, no podemos hacer C en este trimestre sin bajar la calidad / asumir este riesgo. ¿Qué quieren sacrificar?

Eso mueve la conversación de “hazlo como sea” a “decidamos como adultos qué queremos”.

Pasas de usar lenguaje técnico, a usar lenguaje de valor.

Lo que te frena no es la empresa, es tu identidad

Hay empresas objetivamente disfuncionales, claro. Pero incluso ahí hay gente con más capacidad de influir que otras.

Una resistencia profunda que veo en muchos seniors es identitaria:

• “Yo no vine a hacer política, vine a hacer código.”
• “No quiero perder mi tiempo en juntas, quiero producir.”
• “Si el trabajo está bien hecho, se va a notar solo.”

Lo entiendo. La historia que te contaste de ti mismo es “soy el/la que resuelve con conocimiento y trabajo duro”. El problema es que, a partir de cierto nivel, seguir defendiendo esa identidad a rajatabla empieza a jugar en tu contra, así como me pasó a mí.

No se trata de volverte un PowerPoint engineer. Se trata de aceptar que tu valor ya no está solo en la línea de código que escribes, sino en los sistemas que eres capaz de cambiar: roadmaps, procesos, prioridades, decisiones.

Y eso implica entrarle al terreno que antes despreciabas: incentivos, poder, negociación.

Sí, tu stack técnico ya está, pero tu influencia no

Si leyendo esto piensas cosas como:

• “Sé que podría aportar más, pero no sé por dónde empezar a mover el sistema.”
• “Siento que ya juego en nivel Staff en mi cabeza, pero mi empresa me sigue usando como ‘senior plus’.”
• “Estoy cansado de ser el bombero técnico sin poder tocar el diseño del edificio.”

Entonces no necesitas otro curso de arquitectura avanzada.

Necesitas un mapa de poder.

¿De aquí a donde?

Estoy armando un programa para senior engineers que quieren dejar de optimizar solo su stack técnico y empezar a optimizar su influencia:

• Ejercicios para mapear quién decide qué en tu empresa.
• Preguntas para detectar incentivos ocultos que explican por qué tu trabajo no se ve.
• Un framework simple para convertir quejas técnicas en propuestas estratégicas.

La idea es que puedas sentarte una tarde, hacer ese mapa, y ver con otros ojos dónde estás parado y qué palancas tienes realmente.

Si quieres la guía y quieres que trabajemos juntos en diseñar tu siguiente movimiento (dentro o fuera de tu empresa), aplica a una sesión de coaching conmigo y te la muestro.

Tu stack ya está más que probado. Ahora toca actualizar la parte que nunca vino en la documentación: tu capacidad de mover sistemas, personas y decisiones.