Engineering Manager

El Engineering Manager es la persona responsable de la salud de las personas y de la salud del flujo de entrega. En un SDLC AI-native, el Engineering Manager opera un loop de gobierno sobre señales DORA, agendas de 1:1 y retrospectivas a nivel de equipo, no una hoja de cálculo de tickets.

Resumen ejecutivo

El Engineering Manager asegura que los ingenieros crezcan, que el flujo de entrega sea predecible y que el riesgo organizacional aflore antes de convertirse en incidente. En un SDLC AI-native, el Engineering Manager trabaja dentro de la fase de Governance con un conjunto fijo de primitivas: un agente de delivery health, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son scorecards DORA, agendas de 1:1, briefs de retrospectiva y recomendaciones de staffing amarradas al flujo medido.

Rol y responsabilidades

Piensa en el Engineering Manager como el director de una orquesta durante la temporada de ensayos. El director no toca un instrumento en el escenario, pero la orquesta se desbarata sin su sentido del tempo, dinámica y disciplina de ensayo. En un SDLC AI-native, el código y la arquitectura los manejan otras personas. El Engineering Manager es responsable del tempo: la cadencia con la que el equipo aprende, entrega y se recupera.

Responsabilidades principales:

• Trackear las métricas DORA (lead time, deployment frequency, change failure rate, mean time to restore) vía GitHub Actions y workbooks de Azure Monitor
• Correr 1:1s semanales con ingenieros usando una agenda rodante surfaceada por el M365 Agents SDK en Microsoft Teams
• Facilitar retrospectivas de sprint con datos extraídos de Azure Boards y GitHub Projects
• Ser dueño del dashboard de delivery health en Azure Workbooks y mantenerlo enlazado desde el README.md del repositorio
• Detectar burnout, conflicto y riesgo de attrition usando señales SPACE semanales
• Asociarse con el Technical Lead en staffing, escaleras de carrera y brechas de habilidades
• Operar el agente Delivery Pulse y los prompts /pulse, /one-on-one, /retro, /staff-ops

Jobs to be done

1. Como Engineering Manager, quiero un scorecard DORA semanal auto-generado a partir de GitHub Actions y Azure Monitor, para que discuta hechos con mi skip-level en lugar de anécdotas.
2. Como Engineering Manager, quiero que cada agenda de 1:1 venga prellenada con los PRs recientes del ingeniero, los incidentes y las metas de aprendizaje, para que treinta minutos se sientan coachados, no improvisados.
3. Como Engineering Manager, quiero las entradas de retro agregadas desde Azure Boards, GitHub Projects y logs de incidentes, para que el equipo debata patrones en lugar de re-listar eventos.
4. Como Engineering Manager, quiero que las señales de attrition y burnout afloran con cadencia semanal, para que intervenga antes de una renuncia, no después.
5. Como Engineering Manager, quiero un modelo de staffing que mapee el costo del roadmap a la capacidad actual, para que los compromisos de entrega sean honestos.
6. Como Engineering Manager, quiero un rastro de auditoría de cada sugerencia de IA cara a las personas, para que el equipo confíe en el loop.

Puntos de dolor antes de la era AI-native

1. Teatro de métricas. El liderazgo pide DORA, el equipo pega capturas de pantalla de tres herramientas distintas, y nadie confía en el número. Sin un pipeline de agregación firmado, cada reporte es una nueva negociación.
2. 1:1s que derivan a status. Sin una agenda prellenada amarrada a artefactos reales, la media hora se vuelve un micro-standup y la conversación de crecimiento se pospone para siempre.
3. Retros que culpan a individuos. Sin datos, la voz más fuerte gana la narrativa. Las causas sistémicas son invisibles.
4. Burnout invisible. Las rotaciones de on-call, los reviews de PR tardíos y las tasas de rework crecientes son tres dashboards distintos. El manager solo los conecta después de que alguien renuncia.
5. Staffing por intuición. Los compromisos de roadmap se hacen sobre el feeling de la velocidad del equipo, luego se renegocian cada trimestre en una reunión de presupuesto.

Flujo diario AI-native

El Engineering Manager opera un loop semanal y diario. El loop usa primitivas de GitHub Copilot dentro de Visual Studio Code, Claude Code en la terminal para generación de reportes, y el M365 Agents SDK en Microsoft Teams para surface de 1:1.

Setup de la mañana

1. Abrir Visual Studio Code en el repositorio eng-ops. GitHub Copilot Chat carga las instrucciones con alcance .github/instructions/management.instructions.md.
2. Invocar /pulse para refrescar los dashboards DORA y SPACE. El agente Delivery Pulse llama al MCP de GitHub para corridas de Actions y al MCP de Azure para consultas de Application Insights y Azure Monitor.
3. Leer el canal de Teams donde el M365 Agents SDK publica las anomalías nocturnas (picos de pruebas flaky, regresiones de change failure rate, PRs estancados).

Ejecución al mediodía

1. Correr dos o tres 1:1s. Cada 1:1 abre con una agenda prellenada por /one-on-one <engineer>, que extrae los PRs fusionados del ingeniero, su involucramiento en incidentes y participación en tickets desde el MCP de GitHub y el MCP de Azure DevOps.
2. Revisar el registro de riesgos de Azure Boards con el Project Manager. Cualquier ítem etiquetado delivery-risk recibe una vista enlazada de workbook desde Azure Monitor.
3. Correr /staff-ops para evaluar capacidad versus los próximos dos sprints de trabajo comprometido. El agente devuelve un análisis de brechas con riesgos nombrados, nunca promesas.

Revisión al final de la tarde

1. Liderar una retro para uno de los equipos usando /retro. El agente ingiere datos de sprint desde Azure Boards y GitHub Projects y produce un brief estructurado: qué funcionó, qué se atascó, causas sistémicas, experimentos propuestos.
2. Actualizar el dashboard de delivery health en Azure Workbooks. Hacer commit de los cambios de queries. GitHub Actions publica el workbook actualizado.
3. Cerrar el día publicando el resumen diario de pulse al canal de liderazgo en Teams a través del M365 Agents SDK.

Primitivas recomendadas

Agente

Agente	Archivo	Propósito
delivery-pulse	.github/agents/delivery-pulse.agent.md	Agregar señales DORA y SPACE, redactar agendas de 1:1, facilitar retros, producir recomendaciones de staffing

El agente Delivery Pulse usa claude-sonnet-4-6 por defecto, con herramientas read, search, grep, bash, y acceso a los MCPs de GitHub, Azure, Azure DevOps y Microsoft 365 Agents SDK. El extended thinking se habilita para análisis de staffing donde se requiere razonamiento multi-salto sobre datos de capacidad y habilidades.

Slash prompts

Comando	Archivo	Propósito
/pulse	.github/prompts/pulse.prompt.md	Refrescar dashboards DORA y SPACE, marcar anomalías
/one-on-one	.github/prompts/one-on-one.prompt.md	Generar una agenda de 1:1 a partir de artefactos recientes y metas rodantes
/retro	.github/prompts/retro.prompt.md	Producir un brief de retrospectiva con hipótesis de causa sistémica
/staff-ops	.github/prompts/staff-ops.prompt.md	Análisis de capacidad y brecha de habilidades para los próximos sprints

Instrucciones con alcance

El applyTo con alcance reduce el costo en tokens y mantiene el contenido cara a las personas distinto de la guía de code review.

Alcance (applyTo)	Archivo	Propósito
eng-ops/dora/**	.github/instructions/dora.instructions.md	Reglas de agregación DORA, umbrales de anomalía
eng-ops/one-on-ones/**	.github/instructions/one-on-ones.instructions.md	Tono de 1:1, fronteras de confidencialidad, nunca sugerir veredictos de desempeño
eng-ops/retros/**	.github/instructions/retros.instructions.md	Estructura de retro, causa sistémica sobre culpa individual

Hooks

Los hooks son gobierno de cero tokens para artefactos de management.

• pre-commit: redactar nombres de ingenieros de los borradores de retro antes de que se hagan commit a una rama compartida
• post-commit: regenerar el JSON del dashboard de delivery health cuando cambian las queries DORA
• pre-push: validar que cada recomendación de staffing cite una query de capacidad, nunca una corazonada

MCPs validados

Cada MCP a continuación está registrado en el catálogo de MCP. No referenciar ningún MCP que no esté en el catálogo.

MCP	Estado	Uso en esta persona
GitHub MCP Server	Oficial	Leer PRs, corridas de Actions, tableros de Projects; redactar agendas de 1:1 a partir de contribuciones recientes
Azure MCP Server	Oficial (Microsoft)	Consultar Azure Monitor y Application Insights por métricas de despliegue e incidentes
Azure DevOps MCP Server	Oficial (Microsoft)	Leer work items, iteraciones y entradas de registro de riesgos en Azure Boards
Microsoft Learn Docs MCP	Oficial	Anclar la guía de management en Microsoft Learn y GitHub Docs vigentes
Microsoft 365 Agents SDK MCP	Oficial (Microsoft)	Publicar resúmenes de pulse y agendas de 1:1 en canales de Microsoft Teams

Ejemplos reales

Ejemplo 1: pulse semanal de DORA

Entrada: El pulse del lunes vence a las 09:00. El equipo fusionó 42 PRs la semana pasada, con dos rollbacks.

Invocación: /pulse.

Salida esperada:

1. Un eng-ops/dora/2026-W17.md generado con las cuatro métricas DORA, flechas de tendencia y un enlace a cada query subyacente en Azure Monitor.
2. Una publicación en Teams vía el Microsoft 365 Agents SDK que resume el scorecard y marca la regresión de change failure rate.
3. Un work item de Azure Boards abierto automáticamente para la regresión, asignado al Technical Lead de on-call para investigación.

Ejemplo 2: agenda de 1:1 para una ingeniera senior

Entrada: Un 1:1 con una ingeniera senior está agendado para las 14:00. La ingeniera envió tres PRs la semana pasada y fue paginada dos veces en on-call.

Invocación: /one-on-one priya.nair.

Salida esperada:

1. Una agenda rodante en eng-ops/one-on-ones/priya.nair/2026-04-24.md con tres secciones: metas de carrera, highlights de trabajo reciente (PRs e incidentes enlazados), bloqueadores.
2. Un borrador privado surfaceado solo al Engineering Manager en Teams, nunca auto-compartido.
3. Una lista de todos de seguimiento que arrastra cualquier ítem sin resolver del 1:1 anterior.

Anti-patrones

1. Convertir los datos del 1:1 en evidencia de desempeño. La agenda del 1:1 es un andamio de conversación, no un rastro de auditoría. Mitigación: el one-on-ones.instructions.md prohíbe el fraseo de veredicto y requiere compartir con opt-in.
2. Correr DORA sin que los ingenieros lo vean primero. Las métricas convertidas en arma en mazos de liderazgo antes de que el equipo las vea matan la confianza. Mitigación: el pulse publica al canal del equipo antes que al canal de liderazgo.
3. Retros que nombran individuos. Culpar a personas es una falla de management. Mitigación: el agente Delivery Pulse reescribe cualquier fraseo de culpa individual a fraseo de causa sistémica.
4. Modelos de staffing que esconden supuestos. Capacidad dividida por story points es una mentira. Mitigación: /staff-ops devuelve supuestos explícitos y marca cada uno.
5. Dashboards que nunca llevan a acción. Un workbook que nadie lee es ruido. Mitigación: cada anomalía del pulse abre un work item de Azure Boards con un dueño.

KPIs y métricas de impacto

Métrica	Línea base (manual)	Meta (agéntica)	Medición
Entrega del scorecard DORA semanal	Ad hoc	Cada lunes 09:00	Programación de GitHub Actions
Tiempo de prep de 1:1 por ingeniero	20 minutos	Bajo 5 minutos	Log de tiempo a agenda
Tasa de causa sistémica en retro	Bajo 30 por ciento	Sobre 70 por ciento	Auditoría de etiquetas de retro
Lead time de alerta temprana de attrition	0 días	Sobre 30 días	Historial de anomalías de pulse
Precisión de compromiso de staffing	Más o menos 40 por ciento	Más o menos 10 por ciento	Roadmap versus entrega real
Eficiencia en tokens del manager	N/A	Bajo 200k tokens por semana	Reporte de uso de Copilot

Madurez en cuatro niveles

Nivel	Nombre	Marcadores
L1	Manual	DORA en hoja de cálculo, 1:1s improvisados, retros corridas de memoria
L2	Asistido	GitHub Copilot Chat para redactar, sin agente, dashboards en una sola herramienta
L3	Aumentado	Agente Delivery Pulse, cuatro slash prompts, instrucciones con alcance, dashboard DORA en Azure Workbooks
L4	Agéntico	Kit completo de primitivas, hooks forzados, surface del M365 Agents SDK en Teams, detección de anomalías de attrition y burnout con cadencia semanal, scorecard de madurez sobre 80 por ciento

Integración con otras personas

• Con Technical Lead: modelo de staffing compartido, revisión emparejada de indicadores de salud arquitectónica
• Con Scrum Master: facilitación de retro, diagnósticos de flujo de sprint desde Azure Boards
• Con Project Manager: reconciliación del registro de riesgos, cadencia de reporte a stakeholders
• Con SRE: carga de on-call y toil de incidentes alimentan señales de burnout
• Con Product Owner: revisión de factibilidad del roadmap contra capacidad
• Con InfoSec Officer: señales de people-risk (review de accesos, separación de funciones) afloran en el pulse
• Con DevRel: tendencias de contribución externa influyen en señales de hiring

Glosario

• Métricas DORA: las cuatro métricas clave de entrega definidas por el programa de investigación DORA: lead time, deployment frequency, change failure rate, mean time to restore.
• Marco SPACE: un modelo de productividad que cubre Satisfaction, Performance, Activity, Communication, Efficiency.
• Pulse: el artefacto rollup semanal que combina DORA, SPACE y señales de anomalía.
• Dashboard de delivery health: la vista de Azure Workbooks enlazada desde el README.md del repo que hace público el flujo del equipo.
• Alerta temprana de attrition: una señal compuesta derivada de carga de on-call, tasa de rework y latencia de PR que indica riesgo elevado de renuncia.
• Modelo de staffing: una proyección de capacidad versus compromiso que hace explícitos los supuestos.

Referencias

• DORA metrics research — la fundación empírica detrás de las cuatro métricas clave para entrega de software
• SPACE framework, Microsoft Research — dimensiones de productividad de developer más allá de la velocity
• Azure Monitor workbooks documentation — construir dashboards de delivery health sobre telemetría de Azure
• GitHub Actions metrics and insights — fuente autoritativa para telemetría de despliegue y workflow
• Microsoft 365 Agents SDK — el SDK para construir agentes que publican en Teams y otras superficies de M365