Por qué los ingenieros de telecom hacen buenos CTOs

A veces me preguntan cómo acabé en el liderazgo tecnológico viniendo del telecom. La suposición es que el telecom es una industria legacy, llena de protocolos antiguos e infraestructura rígida. Es parcialmente cierto. Pero también es el mejor campo de entrenamiento que he encontrado para construir productos a escala.

Pasé años trabajando con infraestructura de voz en Legos, donde gestionábamos 1.200 millones de minutos al año en 110 países. Después cofundé Cantoo, una plataforma telecom cloud. Ahora dirijo la ingeniería en Consentio, una plataforma de supply chain. El bagaje telecom ha moldeado cómo pienso sobre cada uno de estos sistemas.

El tiempo real no es opcional

En desarrollo web, a menudo puedes permitirte la consistencia eventual. Si una notificación llega unos segundos tarde, nadie muere. Si una página tarda 200 milisegundos extra en cargar, los usuarios puede que ni lo noten.

En telecom, la latencia mata. Literalmente, en algunos casos, porque la infraestructura de voz sirve a los servicios de emergencia. Cuando alguien marca un número, espera oír un tono en menos de un segundo. Si el establecimiento de la llamada tarda tres segundos, algo está roto. Si tarda cinco, pierdes al cliente.

Esto me entrenó para pensar en el rendimiento como un requisito de producto, no como una tarea de optimización. En Consentio, donde gestionamos trading en tiempo real de productos perecederos, esa mentalidad se transfirió directamente. Cuando un comprador envía un pedido de 20 toneladas de tomates, necesita confirmación rápida. El producto se está echando a perder literalmente mientras espera.

La mayoría de los desarrolladores web piensan en la latencia como algo deseable. Los ingenieros telecom la ven como una obligación contractual. Ese cambio de perspectiva cambia cómo diseñas todo, desde consultas a base de datos hasta contratos de API.

Los protocolos te enseñan a pensar en contratos

SIP, SS7, SMPP, Diameter. El telecom está construido sobre protocolos diseñados por comités, debatidos durante años e implementados por decenas de proveedores que interpretan las especificaciones de forma ligeramente distinta.

Trabajar con estos protocolos te enseña algo que ninguna cantidad de diseño de API REST te dará: la importancia de contratos estrictos entre sistemas. Cuando tu gateway SIP habla con un operador, ambos lados necesitan estar de acuerdo en qué significa cada header, qué indica cada código de respuesta y qué ocurre cuando las cosas van mal.

Esto se traduce directamente en cómo diseño las API internas. En OneRagtime, la frontera entre la Platform (cara al inversor), el Core (operaciones) y Deepdive (pipeline de datos) estaba definida con tanta claridad como una frontera de protocolo telecom. Cada sistema tenía su propio modelo de datos, su propio ciclo de despliegue y un contrato estricto sobre cómo se comunicaba con los demás.

La mayoría de las startups que audité en OneRagtime no pensaban así. Sus servicios estaban fuertemente acoplados, compartiendo bases de datos, importando código entre sí, haciendo suposiciones sobre el estado interno. Funcionaba con dos desarrolladores. Se desmoronaba por completo con diez.

El fallo es el estado por defecto

Los sistemas telecom fallan constantemente. Los operadores se caen. Las rutas se degradan. El hardware muere. El tráfico fraudulento se dispara. La pregunta nunca es "va a fallar?" sino "con qué rapidez nos recuperamos?"

En Legos, estaba en guardia 24/7 gestionando cores SIP, gateways SMS y sistemas de detección de fraude para 100 operadores. Cuando algo se rompía a las 3 de la madrugada, la corrección tenía que llegar en minutos, no en horas. Aprendes muy rápido a diseñar para la degradación elegante.

En Cantoo, construimos la infraestructura de voz con el auto-healing como principio fundamental. Si un nodo de enrutamiento caía, el tráfico se desviaba automáticamente a los nodos sanos. Si un operador empezaba a devolver errores, el motor de enrutamiento lo despriorizaba en tiempo real. Sin intervención humana necesaria.

Esto es algo que la mayoría de las aplicaciones web siguen haciendo mal. Diseñan para el happy path y tratan los fallos como casos extremos. Pero a escala, los casos extremos se convierten en eventos diarios. Un sistema que gestiona los fallos con elegancia es más valioso que uno teóricamente más rápido pero frágil.

La conformidad regulatoria como ventaja

El telecom es una de las industrias más reguladas del planeta. Para operar en Reino Unido, Francia y Alemania, como hacíamos con Cantoo, necesitas licencias separadas para cada país. Tienes que cumplir con requisitos de interceptación legal, normas de retención de datos, regulaciones de planes de numeración y obligaciones de servicios de emergencia.

La mayoría de los desarrolladores ven la conformidad como una carga. En telecom, aprendes a verla como una ventaja competitiva. Conseguir las licencias en tres países nos llevó meses de trabajo. Pero una vez que las tuvimos, se convirtieron en una barrera de entrada. Cualquier competidor que quisiera ofrecer el mismo servicio tenía que pasar por el mismo proceso doloroso.

En Consentio, aplico la misma lógica a nuestras certificaciones ISO (27001, 27017, 27018). Sí, el proceso de certificación es exigente. Pero da a nuestros clientes, incluyendo Aldi, Carrefour y Kroger, la confianza de que sus datos se gestionan correctamente. La conformidad no es un sobrecoste. Es un argumento de venta.

La planificación de capacidad no es adivinar

En telecom, no escalas bajo demanda. Planificas la capacidad con meses de antelación porque el aprovisionamiento de circuitos con operadores lleva tiempo. Necesitas saber cuánto tráfico vas a gestionar el próximo trimestre, qué rutas van a crecer y dónde necesitas redundancia.

Esa disciplina se trasladó directamente a cómo pienso en la planificación de infraestructura en cada empresa desde entonces. En Cantoo, aunque corríamos sobre Kubernetes con auto-scaling, seguíamos haciendo revisiones de capacidad trimestrales. El auto-scaling gestiona los picos, pero no gestiona el crecimiento estructural. Si tu base de usuarios se duplica, necesitas pensar en la capacidad de la base de datos, los costes de almacenamiento, el ancho de banda de red y la carga operativa mucho antes de que el auto-scaler entre en acción.

Las startups que audité en OneRagtime que tenían problemas con el escalado eran casi siempre las que dependían completamente del auto-scaling y nunca hacían planificación anticipada. Se topaban con un límite de conexiones de base de datos o un rate limit de una API de terceros y se apresuraban a arreglarlo en producción.

Depurar sistemas distribuidos

Los ingenieros telecom depuran sistemas distribuidos por defecto. Una llamada de voz puede atravesar cinco o seis sistemas entre el llamante y el receptor: la gateway de origen, el motor de enrutamiento, el sistema de facturación, el operador de destino y varios traductores de protocolo en el camino. Cuando la calidad de llamada se degrada, necesitas rastrear el problema a través de todos estos componentes.

Llevé este pensamiento a cada equipo de ingeniería que he liderado. En Consentio, cuando un pedido falla al procesarse, el proceso de depuración sigue el mismo patrón: rastrear la petición a través de los servicios, examinar cada punto de transferencia, identificar dónde los datos o los tiempos fallaron.

La mayoría de los desarrolladores web están acostumbrados a depurar una sola aplicación. Miran logs, ponen breakpoints y recorren el código paso a paso. Depurar sistemas distribuidos requiere una mentalidad diferente: piensas en flujos, no en funciones. Te importa lo que ocurrió entre sistemas, no solo dentro de ellos.

La ventaja poco glamurosa

Nada de esto es glamuroso. Protocolos, conformidad, planificación de capacidad, recuperación ante fallos: no son los temas que atraen atención en las conferencias de desarrolladores. Pero son los temas que determinan si tu producto sobrevive al contacto con la realidad.

Los mejores CTO que conozco comparten un rasgo: piensan en las cosas aburridas. No en el nuevo framework, no en la abstracción ingeniosa, sino en el monitoring, el comportamiento de fallback, las verificaciones de integridad de datos, el proceso de rollback de despliegue.

El telecom me enseñó eso. Y es la mayor ventaja que llevo a cada rol de liderazgo técnico. La industria será "legacy", pero la disciplina de ingeniería que produce es todo lo contrario.