Gerente de Tecnología:
cómo no morir en las reuniones
El mayor riesgo de un Gerente de Tecnología e Innovación no es quedarse sin presupuesto — es quedarse sin criterio técnico. Cuando dejás de entender lo que tu equipo construye, de evaluar una propuesta de vendor, o de detectar cuándo alguien te está vendiendo humo con buzzwords de IA, perdés la única ventaja que tenés: saber cuándo el equipo tiene razón y cuándo está equivocado.
El problema que nadie te dice cuando llegás a gerencia
Cuando pasás a un rol de Gerencia de Tecnología e Innovación, el sistema te empuja en una dirección muy clara: más reuniones, más reportes, más procesos. El calendario se llena de planning, comités, revisiones de presupuesto, presentaciones a dirección. Y de repente, sin que nadie te lo diga explícitamente, dejás de leer sobre tecnología, dejás de experimentar, dejás de saber si lo que tu equipo propone es realmente la mejor opción.
El riesgo no es que te conviertas en un mal líder. Es que te convertís en un gerente que no tiene criterio propio para evaluar lo técnico. Y eso tiene consecuencias concretas: comprás software que no resuelve el problema real, aprobás arquitecturas que van a ser un problema en 18 meses, o descartás ideas que no entendés suficiente para defenderlas.
Cuando un Gerente de Tecnología pierde el criterio técnico, empieza a depender 100% de lo que le dicen los vendors, los consultores y su propio equipo. Eso no es liderazgo — es delegación de decisiones disfrazada de confianza.
La diferencia entre mantenerse actualizado y saber programar
Esta es la confusión más grande: mucha gente cree que un Gerente de Tecnología que "sigue siendo técnico" tiene que seguir programando. No. Eso no escala y tampoco es tu rol.
Lo que necesitás no es escribir código — es entender lo suficiente como para hacer las preguntas correctas. Hay una diferencia enorme entre:
- Saber implementar un endpoint en NestJS (eso es trabajo de tu equipo)
- Entender qué es una API REST, qué implica versionar una API, y cuándo tiene sentido usar GraphQL vs REST (eso es lo que necesitás para tomar decisiones)
El criterio técnico de un gerente no se mide en líneas de código — se mide en la calidad de las preguntas que hace en una reunión con un vendor, en una revisión de arquitectura, o cuando el equipo presenta una propuesta de migración.
Cómo mantenerse actualizado: el framework práctico
1. Tiempo de aprendizaje bloqueado — no negociable
El calendario de un gerente es voraz. Si no bloqueás tiempo explícito para aprender, el sistema lo va a ocupar con reuniones. La regla que me funciona: 4 horas semanales de aprendizaje técnico, bloqueadas en el calendario como si fueran una reunión con el CEO.
Ese tiempo no es para leer emails. Es para:
- Seguir un paper técnico, un blog de ingeniería (AWS, Cloudflare, Anthropic, Stripe Engineering), o una newsletter como The Pragmatic Engineer
- Hacer un PoC mínimo de una tecnología que tu equipo está evaluando — no para entrar en producción, sino para tener criterio propio
- Experimentar con herramientas de IA, infra, o lo que sea que tu área de innovación esté mirando
2. Antes de aprobar, experimentar
Cuando el equipo propone adoptar una nueva tecnología (un modelo de IA, una plataforma de observabilidad, un servicio de comunicaciones), el impulso natural del gerente es preguntar "¿cuánto cuesta?" y "¿cuánto tarda la implementación?". Esas son preguntas importantes pero insuficientes.
La pregunta previa es: ¿yo entiendo qué problema resuelve esto y cómo lo resuelve? Si la respuesta es no, antes de aprobar o rechazar, dedicá 2 horas a probarlo personalmente. Abrí una cuenta de prueba, levantá algo mínimo, leé la documentación de arquitectura. No para convertirte en el experto, sino para que tu decisión esté basada en comprensión, no en presentaciones de PowerPoint.
Antes de decidir si integrar un LLM en un flujo de trabajo interno, monté un script mínimo con la API de OpenAI para entender cuánto cuesta por query, qué tan variable es la respuesta, y dónde estaban los límites reales. Eso me permitió hacer preguntas concretas al equipo — y detectar que la propuesta inicial no contemplaba el costo de tokens en escenarios de alto volumen.
3. Reuniones técnicas sin estar de decoración
Cuando participás en una reunión técnica sin criterio propio, aportas nada y consumís tiempo del equipo. La alternativa no es falsa modestia ("dejen que los técnicos decidan") sino llegar preparado.
Antes de cualquier Architecture Review, reunión con vendor o evaluación de una herramienta nueva:
- Leé la documentación de arquitectura o el sitio técnico del producto — 30 minutos
- Anotá 3 preguntas concretas que no podés responder solo
- Identificá cuál es el riesgo técnico principal que querés que el equipo justifique
Con eso, tu participación deja de ser decorativa y pasa a ser relevante.
IA: el área donde más fácil es quedarse desactualizado
En 2026, cualquier Gerente de Tecnología que no entienda los fundamentos de cómo funcionan los LLMs, qué es RAG, cuándo tiene sentido fine-tuning vs prompting, y cuáles son los riesgos reales de poner un modelo en producción: está tomando decisiones a ciegas.
No necesitás saber entrenar un modelo. Necesitás saber:
- Que los LLMs alucinan, que eso no se resuelve con un mejor prompt, y que la confiabilidad en producción requiere arquitectura (RAG, guardrails, evaluación)
- Que el modelo es el 20% del trabajo — el pipeline de datos, retrieval y evaluación continua es el 80%
- Que el costo de tokens escala rápido y hay que modelarlo antes de comprometerse con una arquitectura
- Que hay diferencia entre un MVP con un LLM y un sistema de producción con un LLM
Con eso, podés evaluar propuestas, hacer preguntas que incomoden a los vendors que te quieren vender una solución mágica, y proteger a tu organización de comprometerse con algo que no va a funcionar.
Cómo matar la burocracia antes de que te mate a vos
Los procesos burocráticos crecen solos. Nadie los diseña con mala intención: aparecen como respuesta a problemas reales. Pero si no los gestionás activamente, terminan ocupando el espacio que debería ser innovación y criterio técnico.
Tres reglas que aplico:
- Reunión sin agenda escrita = no existe. Si alguien no puede escribir en 3 líneas para qué sirve la reunión y qué decisión tiene que salir de ella, la reunión no va al calendario.
- Reporte que nadie lee = eliminado. Cada trimestre, revisá qué reportes generás y preguntá quién los usa para tomar decisiones. Los que no tienen dueño activo, se cortan.
- Comité de aprobación ≠ garantía de calidad. Más firmas no hacen mejores decisiones técnicas. Si un proceso de aprobación tarda más de lo que tarda implementar la cosa en un PoC, el proceso es el problema.
Un Gerente de Tecnología e Innovación no necesita ser el mejor programador del equipo. Necesita tener suficiente criterio técnico para NO ser engañado — por vendors, por consultores, o por el entusiasmo de su propio equipo con una tecnología nueva. Ese criterio se construye con curiosidad activa, tiempo bloqueado para aprender, y la disciplina de experimentar antes de aprobar. No existe atajo.