Hay algo que me lleva tiempo dando vueltas en la cabeza:
¿Cómo es posible que, en roles de Platform Engineering, DevOps Lead o SRE Lead, acabe sentándose en la silla de “decisor técnico” gente que no ha pasado por todas las capas del stack?
Me refiero a perfiles que, con solo experiencia en operaciones, de pronto lideran decisiones que afectan a la plataforma completa. Un cargo donde no solo tienes que saber que el pod arranca, sino también por qué arranca, cómo se comporta bajo presión, y qué hace realmente ese software que estás sirviendo.
La desconexión está servida
Pongamos un ejemplo real: Un frontend que lanza peticiones AJAX con cada pulsación de teclado, sin debouncing.
-
Un SRE Lead que ha hecho frontend, al ver ráfagas de tráfico en Grafana, pensará enseguida:
“Esto suena a un onChange mal gestionado, sin debounce de 300ms”.
Va al repo de frontend, identifica el patrón, y coordina a quien tenga que arreglarlo. -
Un SRE Lead que jamás tocó frontend, verá:
“Hay un pico de tráfico”, abrirá un ticket genérico, pedirá revisiones, organizará reuniones y meterá el tema en el backlog. Y mientras tanto, la factura de AWS se hace bien gorda.
Ocurren cosas similares en backend
Otro caso: Un backend con queries que escalan horriblemente mal con datos crecientes.
- Un lead que ha hecho backend sabrá pensar en N+1, joins innecesarios, índices que faltan, queries en loops, overfetching en APIs…
- Un lead que solo conoce infraestructura verá la CPU del pod al 100% y empezará a subir réplicas sin entender cómo el servicio consume tanto.
Y en infra, más de lo mismo
Un clásico: Llegan latencias altísimas al responder peticiones. El “infra lead” sin experiencia de programación podría empezar a jugar con tamaños de instancia, balanceadores y políticas de red.
Pero alguien que haya picado código pensará primero en:
- Problemas de serialización
- Payloads gigantes
- Bucles que bloquean autopistas
- Clientes que no respetan timeouts
¿Por qué? Porque sabe qué puede estar haciendo ese código dentro de la CPU.
El platform lead debe saber dónde buscar
No digo que un Lead DevOps, SRE o Platform Engineer deba arreglar él mismo cada bug. Su responsabilidad no es esa. Pero sí espero que tenga la experiencia suficiente para:
- Entender lo que está pasando al ver métricas y logs
- Hacerse un mapa mental rápido de posibles causas
- Abrir el repositorio adecuado
- Identificar el patrón general del problema
- … y asignar directamente al desarrollador correcto con instrucciones claras
Ese nivel de contexto ahorra semanas de incertidumbre.
Si no entiendes qué corre dentro del contenedor, solo puedes abrir un ticket genérico y esperar que otro equipo descubra la causa. Y sí, eso no hace más que arrancar la maquinaria burocrática: reuniones, priorizaciones, sprints… y mientras tanto la factura de AWS sigue subiendo.
Escalar sin entender multiplica el coste
Por dos motivos muy claros:
- Si no sabes qué produce la sobrecarga, la receta rápida es “escalamos y listo”. ¿Resultado? Diez veces más pods, diez veces más EC2, diez veces más personas buscando el bug.
- Si la investigación entra en un backlog sin priorizar, seguirás pagando de más durante semanas o meses.
Con alguien transversal (con experiencia real en frontend, backend e infra) la historia cambia:
- Ve el pico en Grafana
- Genera un par de teorías fundamentadas
- Abre el repo correcto
- Localiza el patrón sospechoso
- Y asigna a la persona adecuada, explicando qué arreglar y por qué
El coste oculto de la inexperiencia
Más allá de la factura de AWS, está el coste de pagar a toda la gente para reuniones interminables, tickets de análisis, documentación, validaciones y discusiones sin contexto técnico real.
- Cada reunión cuesta dinero
- Cada sprint “para investigar” cuesta dinero
- Cada triage lento cuesta dinero
Un lead sin visión transversal es, en la práctica, un coladero de dinero monumental. Porque el equipo pierde foco, el negocio pierde velocidad, y las facturas siguen subiendo.
La moraleja
Si alguien solo pasó por la capa de infraestructura, va a mirar Grafana y abrir tickets.
Si alguien pisó frontend, backend e infra, va a mirar Grafana, sabrá qué repo abrir, y orientará el arreglo en 15 minutos.
La diferencia puede ser meses de burocracia o 15 minutos de criterio.
Y esa diferencia, en Platform Engineering, es todo.