07 enablement · Governance
Engineering ManagerGerente de EngenhariaGerente de Ingeniería
People and delivery health.Saúde de pessoas e entrega.Salud del equipo y de la entrega.
The Engineering Manager is the persona accountable for the health of the people and the health of the delivery flow. In an AI-native SDLC, the Engineering Manager operates a governance loop over DORA signals, 1:1 agendas, and team-level retrospectives, not a spreadsheet of tickets.
Executive summary
The Engineering Manager ensures that engineers grow, that delivery flow is predictable, and that organizational risk is surfaced before it becomes incident. In an AI-native SDLC, the Engineering Manager works inside the Governance phase with a fixed set of primitives: one delivery-health agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. The primary outputs are DORA scorecards, 1:1 agendas, retrospective briefs, and staffing recommendations tied to measured flow.
Role and responsibilities
Think of the Engineering Manager like the conductor of an orchestra during rehearsal season. The conductor does not play an instrument on stage, but the orchestra falls apart without their sense of tempo, dynamics, and rehearsal discipline. In an AI-native SDLC, the code and the architecture are owned by other personas. The Engineering Manager is accountable for tempo: the cadence at which the team learns, ships, and recovers.
Primary responsibilities:
- Track DORA metrics (lead time, deployment frequency, change failure rate, mean time to restore) via GitHub Actions and Azure Monitor workbooks
- Run weekly 1:1s with engineers using a rolling agenda surfaced by the M365 Agents SDK on Microsoft Teams
- Facilitate sprint retrospectives with data pulled from Azure Boards and GitHub Projects
- Own the delivery-health dashboard in Azure Workbooks and keep it linked from the repository
README.md - Detect burnout, conflict, and attrition risk using weekly SPACE signals
- Partner with the Technical Lead on staffing, career ladders, and skill gaps
- Operate the Delivery Pulse agent and the
/pulse,/one-on-one,/retro,/staff-opsprompts
Jobs to be done
- As an Engineering Manager, I want a weekly DORA scorecard auto-generated from GitHub Actions and Azure Monitor, so that I discuss facts with my skip-level instead of anecdotes.
- As an Engineering Manager, I want each 1:1 agenda prefilled with the engineer’s recent PRs, incidents, and learning goals, so that thirty minutes feel coached, not improvised.
- As an Engineering Manager, I want retro inputs aggregated from Azure Boards, GitHub Projects, and incident logs, so that the team debates patterns instead of re-listing events.
- As an Engineering Manager, I want attrition and burnout signals surfaced on a weekly cadence, so that I intervene before a resignation, not after.
- As an Engineering Manager, I want a staffing model that maps roadmap cost to current capacity, so that delivery commitments are honest.
- As an Engineering Manager, I want an audit trail of every people-facing AI suggestion, so that the team trusts the loop.
Pain points before AI-native
- Metrics theatre. Leadership asks for DORA, the team pastes screenshots from three different tools, and nobody trusts the number. Without a signed aggregation pipeline, each report is a new negotiation.
- 1:1s that drift into status. Without a prefilled agenda tied to real artifacts, the half-hour becomes a micro-standup and the growth conversation is postponed forever.
- Retros that blame individuals. Without data, the loudest voice wins the narrative. Systemic causes are invisible.
- Invisible burnout. On-call rotations, late PR reviews, and growing rework rates are three different dashboards. The manager only connects them after someone resigns.
- Staffing by intuition. Roadmap commitments are made on gut feel for team velocity, then re-negotiated every quarter in a budget meeting.
AI-native daily workflow
The Engineering Manager operates a weekly and daily loop. The loop uses GitHub Copilot primitives inside Visual Studio Code, Claude Code at the terminal for report generation, and the M365 Agents SDK on Microsoft Teams for 1:1 surfacing.
Morning setup
- Open Visual Studio Code on the
eng-opsrepository. GitHub Copilot Chat loads the scoped.github/instructions/management.instructions.md. - Invoke
/pulseto refresh the DORA and SPACE dashboards. The Delivery Pulse agent calls the GitHub MCP for Actions runs and the Azure MCP for Application Insights and Azure Monitor queries. - Read the Teams channel where the M365 Agents SDK posts the overnight anomalies (flaky test spikes, change failure rate regressions, stalled PRs).
Midday execution
- Run two or three 1:1s. Each 1:1 opens with an agenda prefilled by
/one-on-one <engineer>, which pulls the engineer’s merged PRs, incident involvement, and ticket participation from the GitHub MCP and Azure DevOps MCP. - Review the Azure Boards risk register with the Project Manager. Any item tagged
delivery-riskgets a linked workbook view from Azure Monitor. - Run
/staff-opsto evaluate capacity versus the next two sprints of committed work. The agent returns a gap analysis with named risks, never promises.
Afternoon review
- Lead a retro for one of the teams using
/retro. The agent ingests sprint data from Azure Boards and GitHub Projects and produces a structured brief: what worked, what stalled, systemic causes, proposed experiments. - Update the delivery-health dashboard in Azure Workbooks. Commit the query changes. GitHub Actions publishes the updated workbook.
- Close the day by posting the daily pulse summary to the leadership Teams channel via the M365 Agents SDK.
Recommended primitives
Agent
| Agent | File | Purpose |
|---|---|---|
delivery-pulse | .github/agents/delivery-pulse.agent.md | Aggregate DORA and SPACE signals, draft 1:1 agendas, facilitate retros, produce staffing recommendations |
The Delivery Pulse agent uses claude-sonnet-4-6 by default, with tools read, search, grep, bash, and access to GitHub, Azure, Azure DevOps, and Microsoft 365 Agents SDK MCPs. Extended thinking is enabled for staffing analyses where multi-hop reasoning over capacity and skill data is required.
Slash prompts
| Command | File | Purpose |
|---|---|---|
/pulse | .github/prompts/pulse.prompt.md | Refresh DORA and SPACE dashboards, flag anomalies |
/one-on-one | .github/prompts/one-on-one.prompt.md | Generate a 1:1 agenda from recent artifacts and rolling goals |
/retro | .github/prompts/retro.prompt.md | Produce a retrospective brief with systemic-cause hypotheses |
/staff-ops | .github/prompts/staff-ops.prompt.md | Capacity and skill-gap analysis for upcoming sprints |
Instructions scoped
Scoped applyTo reduces token cost and keeps people-facing content distinct from code review guidance.
Scope (applyTo) | File | Purpose |
|---|---|---|
eng-ops/dora/** | .github/instructions/dora.instructions.md | DORA aggregation rules, anomaly thresholds |
eng-ops/one-on-ones/** | .github/instructions/one-on-ones.instructions.md | 1:1 tone, confidentiality boundaries, never suggest performance verdicts |
eng-ops/retros/** | .github/instructions/retros.instructions.md | Retro structure, systemic-cause over individual blame |
Hooks
Hooks are zero-token governance for management artifacts.
pre-commit: redact engineer names from retro drafts before they are committed to a shared branchpost-commit: regenerate the delivery-health dashboard JSON when DORA queries changepre-push: validate that every staffing recommendation cites a capacity query, never a hunch
Validated MCPs
Every MCP below is registered in the MCP catalog. Do not reference any MCP that is not in the catalog.
| MCP | Status | Use in this persona |
|---|---|---|
| GitHub MCP Server | Official | Read PRs, Actions runs, Projects boards; draft 1:1 agendas from recent contributions |
| Azure MCP Server | Official (Microsoft) | Query Azure Monitor and Application Insights for deployment and incident metrics |
| Azure DevOps MCP Server | Official (Microsoft) | Read Azure Boards work items, iterations, and risk register entries |
| Microsoft Learn Docs MCP | Official | Ground management guidance in current Microsoft Learn and GitHub Docs |
| Microsoft 365 Agents SDK MCP | Official (Microsoft) | Post pulse summaries and 1:1 agendas into Microsoft Teams channels |
Real examples
Example 1: weekly DORA pulse
Input: The Monday pulse is due at 09:00. The team merged 42 PRs last week, with two rollbacks.
Invocation: /pulse.
Expected output:
- A generated
eng-ops/dora/2026-W17.mdwith the four DORA metrics, trend arrows, and a link to each underlying query in Azure Monitor. - A Teams post via the Microsoft 365 Agents SDK summarizing the scorecard and flagging the change failure rate regression.
- An Azure Boards work item opened automatically for the regression, assigned to the on-call Technical Lead for investigation.
Example 2: 1:1 agenda for a senior engineer
Input: A 1:1 with a senior engineer is scheduled for 14:00. The engineer shipped three PRs last week and was paged twice on-call.
Invocation: /one-on-one priya.nair.
Expected output:
- A rolling agenda in
eng-ops/one-on-ones/priya.nair/2026-04-24.mdwith three sections: career goals, recent work highlights (linked PRs and incidents), blockers. - A private draft surfaced only to the Engineering Manager in Teams, never auto-shared.
- A follow-up todo list that carries forward any unresolved item from the previous 1:1.
Anti-patterns
- Turning 1:1 data into performance evidence. The 1:1 agenda is a conversation scaffold, not an audit trail. Mitigation: the
one-on-ones.instructions.mdforbids verdict phrasing and requires opt-in sharing. - Running DORA without the engineers seeing it first. Metrics weaponized in leadership decks before the team sees them kill trust. Mitigation: the pulse posts to the team channel before the leadership channel.
- Retros that name individuals. Blaming people is a management failure. Mitigation: the Delivery Pulse agent rewrites any individual-blame phrasing into systemic-cause phrasing.
- Staffing models that hide assumptions. Capacity divided by story points is a lie. Mitigation:
/staff-opsreturns explicit assumptions and flags each one. - Dashboards that never drive action. A workbook nobody reads is noise. Mitigation: every anomaly on the pulse opens an Azure Boards work item with an owner.
KPIs and impact metrics
| Metric | Baseline (manual) | Target (agentic) | Measurement |
|---|---|---|---|
| Weekly DORA scorecard delivery | Ad hoc | Every Monday 09:00 | GitHub Actions schedule |
| 1:1 prep time per engineer | 20 minutes | Under 5 minutes | Time-to-agenda log |
| Retro systemic-cause rate | Under 30 percent | Over 70 percent | Retro label audit |
| Attrition early warning lead time | 0 days | Over 30 days | Pulse anomaly history |
| Staffing commitment accuracy | Plus or minus 40 percent | Plus or minus 10 percent | Roadmap versus actual delivery |
| Manager token efficiency | N/A | Under 200k tokens per week | Copilot usage report |
Maturity in four levels
| Level | Name | Markers |
|---|---|---|
| L1 | Manual | Spreadsheet DORA, improvised 1:1s, retros run from memory |
| L2 | Assisted | GitHub Copilot Chat for drafting, no agent, dashboards in one tool only |
| L3 | Augmented | Delivery Pulse agent, four slash prompts, scoped instructions, DORA dashboard in Azure Workbooks |
| L4 | Agentic | Full primitives kit, hooks enforced, M365 Agents SDK surfacing in Teams, attrition and burnout anomaly detection on a weekly cadence, maturity scorecard above 80 percent |
Integration with other personas
- With Technical Lead: shared staffing model, paired review of architecture-health indicators
- With Scrum Master: retro facilitation, sprint flow diagnostics from Azure Boards
- With Project Manager: risk register reconciliation, stakeholder reporting cadence
- With SRE: on-call load and incident toil feed into burnout signals
- With Product Owner: roadmap feasibility review against capacity
- With InfoSec Officer: people-risk signals (access review, separation-of-duties) surfaced in the pulse
- With DevRel: external contribution trends influence hiring signals
Glossary
- DORA metrics: the four key delivery metrics defined by the DORA research program: lead time, deployment frequency, change failure rate, mean time to restore.
- SPACE framework: a productivity model covering Satisfaction, Performance, Activity, Communication, Efficiency.
- Pulse: the weekly rollup artifact that combines DORA, SPACE, and anomaly signals.
- Delivery health dashboard: the Azure Workbooks view linked from the repo
README.mdthat makes the team’s flow public. - Attrition early warning: a composite signal derived from on-call load, rework rate, and PR latency that indicates elevated resignation risk.
- Staffing model: a capacity-versus-commitment projection that makes assumptions explicit.
References
- DORA metrics research — the empirical foundation behind four key metrics for software delivery
- SPACE framework, Microsoft Research — developer productivity dimensions beyond velocity
- Azure Monitor workbooks documentation — build delivery-health dashboards on Azure telemetry
- GitHub Actions metrics and insights — authoritative source for deployment and workflow telemetry
- Microsoft 365 Agents SDK — the SDK for building agents that post into Teams and other M365 surfaces
O Engineering Manager é a persona responsável pela saúde das pessoas e pela saúde do fluxo de entrega. Em um SDLC AI-native, o Engineering Manager opera um loop de governança sobre sinais de DORA, agendas de 1:1 e retrospectivas em nível de time, não uma planilha de tickets.
Resumo executivo
O Engineering Manager garante que os engenheiros cresçam, que o fluxo de entrega seja previsível e que o risco organizacional apareça antes de virar incidente. Em um SDLC AI-native, o Engineering Manager trabalha dentro da fase de Governance com um conjunto fixo de primitivas: um agente de delivery-health, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são scorecards DORA, agendas de 1:1, briefs de retrospectiva e recomendações de staffing ligadas a fluxo medido.
Papel e responsabilidades
Pense no Engineering Manager como o maestro de uma orquestra na temporada de ensaios. O maestro não toca nenhum instrumento no palco, mas a orquestra desmorona sem o senso de tempo, dinâmica e disciplina de ensaio que ele impõe. Em um SDLC AI-native, o código e a arquitetura são responsabilidade de outras personas. O Engineering Manager é responsável pelo tempo: a cadência com que o time aprende, entrega e se recupera.
Responsabilidades primárias:
- Acompanhar métricas DORA (lead time, deployment frequency, change failure rate, mean time to restore) via GitHub Actions e workbooks do Azure Monitor
- Conduzir 1:1s semanais com engenheiros usando uma agenda rolante trazida pelo M365 Agents SDK no Microsoft Teams
- Facilitar retrospectivas de sprint com dados puxados do Azure Boards e do GitHub Projects
- Ser dono do dashboard de delivery-health em Azure Workbooks e mantê-lo linkado a partir do
README.mddo repositório - Detectar risco de burnout, conflito e attrition usando sinais semanais de SPACE
- Fazer parceria com o Technical Lead em staffing, trilhas de carreira e gaps de skill
- Operar o agente Delivery Pulse e os prompts
/pulse,/one-on-one,/retro,/staff-ops
Jobs to be done
- Como Engineering Manager, eu quero um scorecard DORA semanal auto-gerado a partir do GitHub Actions e do Azure Monitor, para que eu discuta fatos com meu skip-level em vez de anedotas.
- Como Engineering Manager, eu quero que cada agenda de 1:1 seja pré-preenchida com os PRs recentes, incidentes e metas de aprendizado do engenheiro, para que os trinta minutos pareçam coaching, não improviso.
- Como Engineering Manager, eu quero que os inputs de retro sejam agregados do Azure Boards, GitHub Projects e logs de incidente, para que o time debata padrões em vez de relistar eventos.
- Como Engineering Manager, eu quero sinais de attrition e burnout aparecendo em cadência semanal, para que eu intervenha antes do pedido de demissão, não depois.
- Como Engineering Manager, eu quero um modelo de staffing que mapeie o custo do roadmap contra a capacidade atual, para que os compromissos de entrega sejam honestos.
- Como Engineering Manager, eu quero um audit trail de toda sugestão de IA voltada a pessoas, para que o time confie no loop.
Dores antes da era AI-native
- Métricas de fachada. A liderança pede DORA, o time cola screenshots de três ferramentas diferentes e ninguém confia no número. Sem um pipeline de agregação assinado, cada relatório é uma nova negociação.
- 1:1s que derivam para status. Sem uma agenda pré-preenchida ligada a artefatos reais, a meia hora vira um mini-standup e a conversa de crescimento é adiada para sempre.
- Retros que culpam indivíduos. Sem dados, a voz mais alta ganha a narrativa. Causas sistêmicas ficam invisíveis.
- Burnout invisível. Escalas de on-call, reviews de PR atrasadas e taxas crescentes de retrabalho são três dashboards diferentes. O gestor só conecta os pontos depois que alguém pede demissão.
- Staffing por intuição. Compromissos de roadmap são feitos no feeling sobre a velocidade do time e renegociados a cada trimestre em uma reunião de budget.
Fluxo diário AI-native
O Engineering Manager opera um loop semanal e diário. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code, Claude Code no terminal para geração de relatórios e o M365 Agents SDK no Microsoft Teams para trazer os 1:1s à tona.
Setup da manhã
- Abra o Visual Studio Code no repositório
eng-ops. GitHub Copilot Chat carrega o.github/instructions/management.instructions.mdescopado. - Invoque
/pulsepara atualizar os dashboards DORA e SPACE. O agente Delivery Pulse chama o GitHub MCP para runs do Actions e o Azure MCP para queries de Application Insights e Azure Monitor. - Leia o canal do Teams onde o M365 Agents SDK posta as anomalias da madrugada (picos de testes flaky, regressões de change failure rate, PRs parados).
Execução no meio do dia
- Faça dois ou três 1:1s. Cada 1:1 abre com uma agenda pré-preenchida por
/one-on-one <engenheiro>, que puxa os PRs merged do engenheiro, envolvimento em incidentes e participação em tickets via GitHub MCP e Azure DevOps MCP. - Revise o risk register do Azure Boards com o Project Manager. Qualquer item com a tag
delivery-riskganha uma view de workbook linkada no Azure Monitor. - Rode
/staff-opspara avaliar capacidade contra os próximos dois sprints de trabalho comprometido. O agente retorna uma análise de gap com riscos nomeados, nunca promessas.
Revisão no fim da tarde
- Conduza uma retro para um dos times usando
/retro. O agente ingere dados do sprint do Azure Boards e GitHub Projects e produz um brief estruturado: o que funcionou, o que travou, causas sistêmicas, experimentos propostos. - Atualize o dashboard de delivery-health em Azure Workbooks. Commite as mudanças de query. GitHub Actions publica o workbook atualizado.
- Encerre o dia postando o resumo do pulse diário no canal de liderança do Teams via M365 Agents SDK.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
delivery-pulse | .github/agents/delivery-pulse.agent.md | Agregar sinais de DORA e SPACE, rascunhar agendas de 1:1, facilitar retros, produzir recomendações de staffing |
O agente Delivery Pulse usa claude-sonnet-4-6 por padrão, com ferramentas read, search, grep, bash e acesso aos MCPs do GitHub, Azure, Azure DevOps e Microsoft 365 Agents SDK. Extended thinking fica habilitado para análises de staffing em que raciocínio multi-hop sobre capacidade e dados de skill é necessário.
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/pulse | .github/prompts/pulse.prompt.md | Atualizar dashboards DORA e SPACE, sinalizar anomalias |
/one-on-one | .github/prompts/one-on-one.prompt.md | Gerar uma agenda de 1:1 a partir de artefatos recentes e metas rolantes |
/retro | .github/prompts/retro.prompt.md | Produzir um brief de retrospectiva com hipóteses de causa sistêmica |
/staff-ops | .github/prompts/staff-ops.prompt.md | Análise de capacidade e gap de skills para os próximos sprints |
Instruções escopadas
Um applyTo escopado reduz o custo em tokens e mantém conteúdo voltado a pessoas distinto do guia de code review.
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
eng-ops/dora/** | .github/instructions/dora.instructions.md | Regras de agregação DORA, limiares de anomalia |
eng-ops/one-on-ones/** | .github/instructions/one-on-ones.instructions.md | Tom do 1:1, fronteiras de confidencialidade, nunca sugerir veredictos de performance |
eng-ops/retros/** | .github/instructions/retros.instructions.md | Estrutura de retro, causa sistêmica acima de culpa individual |
Hooks
Hooks são governança de custo zero em tokens para artefatos de gestão.
pre-commit: remove nomes de engenheiros de drafts de retro antes de serem commitados em uma branch compartilhadapost-commit: regenera o JSON do dashboard de delivery-health quando queries DORA mudampre-push: valida que toda recomendação de staffing cita uma query de capacidade, nunca um palpite
MCPs validados
Todos os MCPs abaixo estão registrados no catálogo de MCPs. Não referencie nenhum MCP que não esteja no catálogo.
| MCP | Status | Uso nesta persona |
|---|---|---|
| GitHub MCP Server | Oficial | Ler PRs, runs do Actions, boards de Projects; rascunhar agendas de 1:1 a partir de contribuições recentes |
| Azure MCP Server | Oficial (Microsoft) | Consultar Azure Monitor e Application Insights para métricas de deployment e incidente |
| Azure DevOps MCP Server | Oficial (Microsoft) | Ler work items do Azure Boards, iterações e entradas do risk register |
| Microsoft Learn Docs MCP | Oficial | Ancorar o guia de gestão em Microsoft Learn e GitHub Docs atuais |
| Microsoft 365 Agents SDK MCP | Oficial (Microsoft) | Postar resumos de pulse e agendas de 1:1 em canais do Microsoft Teams |
Exemplos reais
Exemplo 1: pulse DORA semanal
Entrada: O pulse de segunda-feira está marcado para 09:00. O time deu merge em 42 PRs na semana passada, com dois rollbacks.
Invocação: /pulse.
Saída esperada:
- Um
eng-ops/dora/2026-W17.mdgerado com as quatro métricas DORA, setas de tendência e um link para cada query subjacente no Azure Monitor. - Um post no Teams via Microsoft 365 Agents SDK resumindo o scorecard e sinalizando a regressão de change failure rate.
- Um work item do Azure Boards aberto automaticamente para a regressão, atribuído ao Technical Lead de plantão para investigação.
Exemplo 2: agenda de 1:1 para um engenheiro sênior
Entrada: Um 1:1 com uma engenheira sênior está marcado para as 14:00. A engenheira entregou três PRs na semana passada e foi paged duas vezes durante o on-call.
Invocação: /one-on-one priya.nair.
Saída esperada:
- Uma agenda rolante em
eng-ops/one-on-ones/priya.nair/2026-04-24.mdcom três seções: metas de carreira, destaques do trabalho recente (PRs e incidentes linkados), bloqueios. - Um rascunho privado visível só para o Engineering Manager no Teams, nunca compartilhado automaticamente.
- Uma lista de follow-up que carrega qualquer item não resolvido do 1:1 anterior.
Anti-padrões
- Transformar dados de 1:1 em evidência de performance. A agenda de 1:1 é um scaffold de conversa, não um audit trail. Mitigação: o
one-on-ones.instructions.mdproíbe linguagem de veredicto e exige opt-in para compartilhamento. - Rodar DORA sem os engenheiros verem primeiro. Métricas usadas como arma em decks de liderança antes do time ver matam a confiança. Mitigação: o pulse posta no canal do time antes do canal de liderança.
- Retros que nomeiam indivíduos. Culpar pessoas é falha de gestão. Mitigação: o agente Delivery Pulse reescreve qualquer frase de culpa individual em frase de causa sistêmica.
- Modelos de staffing que escondem premissas. Capacidade dividida por story points é mentira. Mitigação:
/staff-opsretorna premissas explícitas e sinaliza cada uma. - Dashboards que nunca geram ação. Um workbook que ninguém lê é ruído. Mitigação: toda anomalia no pulse abre um work item no Azure Boards com dono.
KPIs e métricas de impacto
| Métrica | Linha base (manual) | Meta (agentic) | Medição |
|---|---|---|---|
| Entrega do scorecard DORA semanal | Ad hoc | Toda segunda às 09:00 | Schedule do GitHub Actions |
| Tempo de prep de 1:1 por engenheiro | 20 minutos | Menos de 5 minutos | Log de time-to-agenda |
| Taxa de causa sistêmica em retros | Menos de 30 por cento | Acima de 70 por cento | Auditoria de labels de retro |
| Lead time de alerta precoce de attrition | 0 dias | Acima de 30 dias | Histórico de anomalias do pulse |
| Acurácia de compromisso de staffing | Mais ou menos 40 por cento | Mais ou menos 10 por cento | Roadmap versus entrega real |
| Eficiência de tokens do gestor | N/A | Menos de 200k tokens por semana | Relatório de uso do Copilot |
Maturidade em quatro níveis
| Nível | Nome | Marcadores |
|---|---|---|
| L1 | Manual | DORA em planilha, 1:1s improvisados, retros conduzidos de memória |
| L2 | Assistido | GitHub Copilot Chat para rascunho, sem agente, dashboards em só uma ferramenta |
| L3 | Aumentado | Agente Delivery Pulse, quatro slash prompts, instruções escopadas, dashboard DORA em Azure Workbooks |
| L4 | Autônomo | Kit completo de primitivas, hooks aplicados, M365 Agents SDK trazendo 1:1s no Teams, detecção semanal de anomalia de attrition e burnout, scorecard de maturidade acima de 80 por cento |
Integração com outras personas
- Com Technical Lead: modelo de staffing compartilhado, revisão em pares dos indicadores de architecture-health
- Com Scrum Master: facilitação de retro, diagnóstico de fluxo de sprint a partir do Azure Boards
- Com Project Manager: reconciliação de risk register, cadência de reporting para stakeholders
- Com SRE: carga de on-call e toil de incidente alimentam os sinais de burnout
- Com Product Owner: revisão de viabilidade do roadmap contra a capacidade
- Com InfoSec Officer: sinais de people-risk (access review, segregação de deveres) aparecem no pulse
- Com DevRel: tendências de contribuição externa influenciam sinais de hiring
Glossário
- Métricas DORA: as quatro métricas-chave de entrega definidas pelo programa de pesquisa DORA: lead time, deployment frequency, change failure rate, mean time to restore.
- Framework SPACE: um modelo de produtividade cobrindo Satisfaction, Performance, Activity, Communication, Efficiency.
- Pulse: o artefato semanal de rollup que combina sinais de DORA, SPACE e anomalias.
- Delivery health dashboard: a view em Azure Workbooks linkada a partir do
README.mddo repo que torna o fluxo do time público. - Alerta precoce de attrition: um sinal composto derivado de carga de on-call, taxa de retrabalho e latência de PR que indica risco elevado de demissão.
- Modelo de staffing: uma projeção de capacidade versus compromisso que torna premissas explícitas.
Referências
- Pesquisa de métricas DORA — a fundação empírica por trás das quatro métricas-chave para entrega de software
- Framework SPACE, Microsoft Research — dimensões de produtividade de desenvolvedor além de velocity
- Documentação de workbooks do Azure Monitor — construa dashboards de delivery-health sobre telemetria do Azure
- Métricas e insights do GitHub Actions — fonte autoritativa para telemetria de deployment e workflow
- Microsoft 365 Agents SDK — o SDK para construir agentes que postam no Teams e outras superfícies M365
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.mddel 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- Retros que culpan a individuos. Sin datos, la voz más fuerte gana la narrativa. Las causas sistémicas son invisibles.
- 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.
- 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
- Abrir Visual Studio Code en el repositorio
eng-ops. GitHub Copilot Chat carga las instrucciones con alcance.github/instructions/management.instructions.md. - Invocar
/pulsepara 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. - 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
- 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. - Revisar el registro de riesgos de Azure Boards con el Project Manager. Cualquier ítem etiquetado
delivery-riskrecibe una vista enlazada de workbook desde Azure Monitor. - Correr
/staff-opspara 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
- 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. - Actualizar el dashboard de delivery health en Azure Workbooks. Hacer commit de los cambios de queries. GitHub Actions publica el workbook actualizado.
- 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 compartidapost-commit: regenerar el JSON del dashboard de delivery health cuando cambian las queries DORApre-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:
- Un
eng-ops/dora/2026-W17.mdgenerado con las cuatro métricas DORA, flechas de tendencia y un enlace a cada query subyacente en Azure Monitor. - 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.
- 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:
- Una agenda rodante en
eng-ops/one-on-ones/priya.nair/2026-04-24.mdcon tres secciones: metas de carrera, highlights de trabajo reciente (PRs e incidentes enlazados), bloqueadores. - Un borrador privado surfaceado solo al Engineering Manager en Teams, nunca auto-compartido.
- Una lista de todos de seguimiento que arrastra cualquier ítem sin resolver del 1:1 anterior.
Anti-patrones
- 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.mdprohíbe el fraseo de veredicto y requiere compartir con opt-in. - 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.
- 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.
- Modelos de staffing que esconden supuestos. Capacidad dividida por story points es una mentira. Mitigación:
/staff-opsdevuelve supuestos explícitos y marca cada uno. - 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.mddel 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