Maturidade de engenharia: quando “apagar incêndio” deixa de ser identidade · faconi

A empresa costuma admirar o time “bombeiro”: cai produção, eles resolvem; bug crítico, viram a noite; pediu “pra ontem”, entregam. O problema é quando isso vira padrão — e não exceção. Aí a organização confunde heroísmo com maturidade, e o time confunde movimento com evolução.

No meu texto eu bato numa ideia simples: incidente é normal. O que denuncia baixa maturidade não é quebrar — é quebrar sempre do mesmo jeito. E isso aparece em sinais bem comuns: troubleshooting preso em 1–2 pessoas, solução do dia virando padrão sem revisão, post-mortem que vira relato (e não melhoria), atalhos que viram herança.

Depois eu conecto as peças com um caminho prático:

Métricas (DORA / Four Keys) pra separar volume de entrega de capacidade de sustentar: deployment frequency, lead time, change failure rate e MTTR — olhando o equilíbrio, não uma métrica isolada.
Duas métricas extras que ajudam muito em contexto “apagar fogo”: incidentes repetidos por causa raiz e tempo para diagnosticar (TTD).
Um PDCA pequeno e constante (plan/do/check/act) pra transformar “lição aprendida” em “sistema melhor” com ações concretas (runbook, alertas úteis, ADR simples, testes de contrato, etc.).
E fecho com um jeito simples de acompanhar evolução: uma “planilha”/checklist de maturidade por pilares (operação, observabilidade, qualidade, arquitetura evolutiva, conhecimento compartilhado).

Se você vive esse dilema entre “entregar agora” e “não piorar o sistema”, acho que o texto completo pode te ajudar.