Introducción: El salto de ejecutar a liderar

La transición de Ingeniero Cloud a Tech Lead es uno de los saltos más desafiantes (y gratificantes) en la carrera de un profesional de TI. De repente, tu éxito ya no se mide solo por la calidad de tus scripts de Terraform o lo bien que dominas el portal de Azure, sino por cómo logras que tu equipo construya soluciones escalables, seguras y mantenibles.

Cuando una organización decide adoptar Microsoft Azure o madurar su infraestructura en la nube, el Tech Lead se convierte en el puente entre las necesidades del negocio (velocidad, coste, cumplimiento) y la realidad técnica (arquitectura, CI/CD, deuda técnica).

En este artículo exploraremos las claves para liderar equipos técnicos en la nube, centrándonos en el ecosistema de Azure.

1. Definir y comunicar una arquitectura clara (Azure Landing Zones)

Como ingeniero, tu objetivo es que las cosas funcionen. Como Tech Lead, tu objetivo es que las cosas funcionen para todos, de la misma manera, y bajo un estándar.

El primer paso es no reinventar la rueda. Microsoft proporciona un marco excelente llamado Azure Landing Zones (ALZ). No es solo un conjunto de recursos, es un modelo operativo. Tu trabajo como líder es adaptar ese modelo a la realidad de tu empresa y, lo más importante, comunicarlo eficazmente al equipo.

¿Cómo hacerlo práctico?

• Dibuja y documenta: No asumas que todos entienden la topología Hub-and-Spoke. Dibuja diagramas claros mostrando dónde van las cargas de trabajo (Spokes) y dónde residen los servicios compartidos como firewalls y conectividad On-Premise (Hub).
• Repertorio de decisiones: Crea un Architecture Decision Record (ADR). Si decides usar Azure Firewall en lugar de un Network Virtual Appliance (NVA) de terceros, documenta el por qué. Esto ahorra debates recurrentes cuando entran nuevos miembros al equipo.

2. Poner ‘Guardrails’, no barreras (Azure Policy)

Uno de los mayores miedos al migrar a la nube es perder el control. El instinto de muchos mánagers tradicionales es restringir permisos hasta ahogar la productividad. Un buen Tech Lead utiliza Azure Policy para poner guardrails (quitamiedos), no muros de ladrillo.

En lugar de requerir que el equipo de Operaciones cree cada servidor, dales a los desarrolladores permisos para desplegar, pero restringe los desastres a través de políticas.

Ejemplos de Políticas de Tech Lead:

• Restricción de Regiones: Permite despliegues solo en westeurope y northeurope para cumplir con las leyes de residencia de datos (GDPR).
• SKUs permitidas: Evita sustos en la factura impidiendo la creación de series G (instancias gigantescas de cómputo) en entornos de desarrollo.
• Auditoría de Tags: Obliga a que todos los Resource Groups tengan las etiquetas Environment y CostCenter. Esto te salvará la vida en las reuniones de presupuesto trimestrales.

{
  "if": {
    "field": "location",
    "notIn": "[parameters('allowedLocations')]"
  },
  "then": {
    "effect": "deny"
  }
}

Fragmento de una definición de Azure Policy para restringir regiones.

3. Fomentar una cultura DevOps sin “Silos”

El rol de Tech Lead no es ser el mejor programador de la sala que corrige el código de todos. Es ser un habilitador de flujo. Si tu equipo de desarrollo tiene que abrir un ticket a infraestructura para crear un Azure App Service, y esperar tres días, la adopción cloud está fallando.

“El verdadero valor de Azure no está en alquilar servidores, sino en acelerar la entrega de valor, y eso requiere integrar Infraestructura como Código (IaC) en la cultura del día a día.”

Estrategias de Liderazgo:

• Infraestructura como parte de la Feature: Cuando se planifica una nueva funcionalidad (ej. un microservicio nuevo), la creación de su infraestructura en Bicep o Terraform debe ser parte de la Definición de Terminado (Definition of Done).
• Propiedad compartida: Anima a los desarrolladores backend a revisar los PRs de infraestructura. Desmitifica Bicep/Terraform; al final del día, es código que define configuración.

4. El delicado balance entre Autonomía y Gobernanza

Este es quizás el arte más difícil del liderazgo técnico. ¿Cuánta libertad le das a un equipo de desarrollo frente a cuánto control impones para evitar caos de seguridad y desbordamiento de costes?

Un patrón exitoso en Azure es el modelo de Subscription Vending Machine. En lugar de tener una cuenta de Azure monolítica, el equipo plataforma (liderado por ti) “vende” o provisiona Suscripciones de Azure nuevas a los equipos de producto.

Cada suscripción ya viene “pre-cocinada”:

1. Conectada a la red por defecto vía VNet Peering.
2. Con las Azure Policies aplicadas heredadas desde los Management Groups.
3. Con los roles de RBAC apropiados para el equipo de producto (Reader en producción, Contributor en desarrollo).

Resultado: El equipo de desarrollo obtiene un “cajón de arena” donde tienen amplia autonomía (Contributor), pero los límites de ese cajón evitan que rompan la red corporativa o expongan datos sensibles.

Conclusión

Ser promovido a Tech Lead significa cambiar tu enfoque. Tu código fuente primario ya no es Terraform o C#; tu código fuente primario son tus procesos, tu arquitectura y tu equipo.

Dominar Azure a nivel técnico te da el respeto de tus ingenieros, pero dominar la comunicación, la gobernanza (Azure Policy) y la cultura de despliegue (DevOps) es lo que determinará el éxito o el fracaso del viaje a la nube de tu organización.