Gerente de Engenharia

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.md do 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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

1. 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.
2. 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.
3. Retros que culpam indivíduos. Sem dados, a voz mais alta ganha a narrativa. Causas sistêmicas ficam invisíveis.
4. 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.
5. 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ã

1. Abra o Visual Studio Code no repositório eng-ops. GitHub Copilot Chat carrega o .github/instructions/management.instructions.md escopado.
2. Invoque /pulse para 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.
3. 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

1. 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.
2. Revise o risk register do Azure Boards com o Project Manager. Qualquer item com a tag delivery-risk ganha uma view de workbook linkada no Azure Monitor.
3. Rode /staff-ops para 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

1. 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.
2. Atualize o dashboard de delivery-health em Azure Workbooks. Commite as mudanças de query. GitHub Actions publica o workbook atualizado.
3. 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 compartilhada
• post-commit: regenera o JSON do dashboard de delivery-health quando queries DORA mudam
• pre-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:

1. Um eng-ops/dora/2026-W17.md gerado com as quatro métricas DORA, setas de tendência e um link para cada query subjacente no Azure Monitor.
2. Um post no Teams via Microsoft 365 Agents SDK resumindo o scorecard e sinalizando a regressão de change failure rate.
3. 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:

1. Uma agenda rolante em eng-ops/one-on-ones/priya.nair/2026-04-24.md com três seções: metas de carreira, destaques do trabalho recente (PRs e incidentes linkados), bloqueios.
2. Um rascunho privado visível só para o Engineering Manager no Teams, nunca compartilhado automaticamente.
3. Uma lista de follow-up que carrega qualquer item não resolvido do 1:1 anterior.

Anti-padrões

1. 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.md proíbe linguagem de veredicto e exige opt-in para compartilhamento.
2. 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.
3. 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.
4. Modelos de staffing que escondem premissas. Capacidade dividida por story points é mentira. Mitigação: /staff-ops retorna premissas explícitas e sinaliza cada uma.
5. 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.md do 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