---

---

Autonomía o anarquía: cuando “estandarizar el piso” significa construir sobre arena movediza

Existe un discurso que se ha vuelto popular en el mundo de Platform Engineering: no debe haber procedimientos corporativos únicos para el manejo de servicios cloud como Lambdas. Definir procesos rígidos, argumentan, es un antipatrón que crea cuellos de botella. La propuesta suena seductora: estandarizar el piso, no el techo. Proveer building blocks y que cada equipo decida cómo implementar su lógica según sus necesidades. Autonomía pura.

Se citan conceptos como Team Topologies, Thin Viable Platform, Cloud Playbook. Se habla de reducir carga cognitiva, de no reemplazar el criterio técnico de los equipos, de evitar TicketOps. Todo muy bonito en teoría.

Pero déjenme contarles lo que realmente pasa cuando esto se implementa sin los contrapesos adecuados.

Cuando le dices a 50 equipos que pueden hacer “lo que les funcione mejor”, no obtienes 50 soluciones óptimas. Obtienes 50 formas diferentes de hacer exactamente lo mismo. Unos suben el ZIP manualmente a S3 y lo referencian en tfvars. Otros crean pipelines complejos en sus repos. Algunos usan variables de entorno directas como POWERTOOLS_SERVICE_NAME, otros implementan Secrets Manager con ARNs hardcodeados, y cada uno lo hace a su manera porque “así les acomoda mejor”.

Y ahí está el problema que nadie quiere admitir en voz alta: esto no escala. Se multiplica por 50, por 100, por el número de equipos que tengas.

Cuando el equipo original rota y se va, ¿quién mantiene esa Lambda que solo dos personas entienden? Cuando hay un incidente de seguridad a las 3 AM, ¿cómo investigas 50 implementaciones diferentes? Cuando necesitas hacer un cambio corporativo urgente, ¿te pones a negociar con 50 equipos que hicieron las cosas “a su manera” y ahora cada uno tiene su propia arquitectura?

La autonomía sin guardrails reales no es empoderamiento. Es abandono disfrazado de confianza. Es lavarse las manos y llamarlo “Platform Engineering moderno”.

Me dicen que imponer procedimientos es crear cuellos de botella. Pero, ¿saben qué es un cuello de botella real? Tener que investigar 50 formas diferentes de hacer logging cuando hay una brecha de seguridad. Tener que reescribir la misma función 50 veces porque cada equipo eligió su propio framework, su propia forma de manejar errores, su propia estrategia de retry. Tener 50 patrones de tagging diferentes que hacen imposible tener visibilidad real de costos. Tener 50 formas de manejar secretos, algunas seguras, otras cuestionables.

El problema no es estandarizar. El problema es creer que la estandarización es enemiga de la agilidad. Son mentiras cómodas que nos contamos para evitar el trabajo difícil de definir patrones claros.

Las mejores plataformas que he visto no dan “building blocks” y se lavan las manos. Definen patrones claros y documentados. Crean guardrails automáticos que previenen errores antes de que ocurran. Hacen que la forma correcta sea también la forma más fácil, no la más complicada. No eliminan la autonomía, la canalizan hacia donde realmente importa: la lógica de negocio, no la infraestructura básica.

Porque al final del día, cuando el sistema se cae, cuando hay una vulnerabilidad crítica, cuando el cliente no puede usar el producto, no importa qué tan “ágil” fue cada equipo para tomar sus propias decisiones técnicas. No importa si cada desarrollador pudo expresar su creatividad implementando Lambdas. Importa si el sistema funciona, si es seguro, si es mantenible, si es escalable.

Dejen de llamar “autonomía” a la falta de liderazgo técnico. Sus equipos no necesitan más libertad para hacer lo que quieran con la infraestructura. Necesitan dirección clara, patrones probados, mejores prácticas validadas y, sí, ciertos límites que eviten que cada decisión técnica se convierta en un experimento personal que después nadie quiere mantener.

La verdadera agilidad no viene de hacer lo que quieras. Viene de poder moverte rápido sobre una base sólida, no sobre 50 cimientos diferentes que se hunden a distinta velocidad. Viene de tener patrones que funcionan, no de reinventar la rueda 50 veces.

El caos no es innovación. La falta de estándares no es agilidad. Y llamar “autonomía” al abandono técnico es, simplemente, deshonestidad intelectual.

#PlatformEngineering #DevOps #ArquitecturaDeSoftware #Leadership #TechDebt #CloudComputing #IngenieríaDeSoftware #GestiónTécnica #AWS #Serverless #TeamTopologies #DevSecOps