Existe um padrão silencioso e muito perigoso que acontece com frequência em times de engenharia que entregam muitas tarefas:
Um erro estranho começa a pipocar no painel de logs. Alguém comenta no Slack: "Engraçado, essa requisição deu timeout de novo". Dias depois, o suporte recebe um chamado isolado. Ninguém abre um card no Jira porque não faz parte do sprint atual. O tempo passa e, três meses depois, aquele pequeno detalhe vira um incidente crítico que derruba a plataforma.
Na reunião de post-mortem, surge aquela pergunta desconfortável:
De quem era a responsabilidade por isso?
Por muito tempo, eu respondi a essa pergunta de forma equivocada. Eu achava que ter "ownership" (senso de dono) significava carregar o mundo nas costas: se eu vi o bug, eu tenho que codar a solução. Ou o extremo oposto: se não tem card no quadro, não é problema meu.
Os dois extremos destroem o time.
Neste artigo, vamos entender por que ver um problema não te obriga a codar a solução, mas te obriga a não fingir que não viu.
1. As Quatro Posturas de Engenharia: Em Qual Delas Você Opera?
Nenhum desenvolvedor nasce sênior ou líder técnico da noite para o dia. A evolução da maturidade técnica acontece quando a pergunta norteadora do seu trabalho muda:
┌────────────────────────────────────────────────────────┐
│ 1. POSTURA TASK: "O card está movido para Done?" │
│ Foco exclusivo em fechar o ticket do sprint. │
└───────────────────────────┬────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 2. POSTURA DELIVERY: "O código subiu para produção?" │
│ Acompanha o deploy, mas não monitora a saúde real. │
└───────────────────────────┬────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 3. POSTURA OUTCOME: "Resolveu o problema do cliente"│
│ Olha métricas de negócio e feedback pós-lançamento. │
└───────────────────────────┬────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 4. POSTURA OWNERSHIP: "O que mais está frágil aqui?" │
│ Identifica riscos adjacentes ANTES que virem crise! │
└────────────────────────────────────────────────────────┘
A postura de Ownership não substitui as outras. Ela simplesmente impede que o time chame de "resolvido" um bug que foi apenas varrido para debaixo do tapete.
2. O Framework S.U.E.O.: OWN Não Significa CODE
Um dos maiores motivos de burnout em engenheiros sêniores é a crença de que ter ownership significa codar tudo sozinho. Isso não escala e transforma você no gargalo da equipe.
Para lidar com problemas sistêmicos, adote quatro passos claros:
┌─────────────┐
│ 1. SEE │ ──> Percebi uma anomalia nos gráficos ou no código
└──────┬──────┘
│
▼
┌─────────────┐
│2. UNDERSTAND│ ──> Isso afeta quem? Qual o risco se ignorarmos por 30 dias?
└──────┬──────┘
│
▼
┌─────────────┐
│ 3. EXPOSE │ ──> Trago dados e evidências concretas, não apenas "feeling"
└──────┬──────┘
│
▼
┌─────────────┐
│ 4. OWN │ ──> Garanto uma decisão formal (inclusive aceitar o risco!)
└─────────────┘
O Que Pode Ser o "OWN" na Prática?
- Abrir um ticket bem estruturado com logs e passos de reprodução;
- Agendar uma conversa de 15 minutos com o Product Manager para avaliar impacto;
- Escrever um documento técnico de uma página propondo opções;
- Ou até uma decisão explícita: "Concordamos em não resolver agora porque o custo de correção é maior que o risco, mas revisaremos em 60 dias".
O Desafio do Ownership na Era dos Agentes de IA
Com ferramentas como Claude Code, Cursor e Copilot gerando dezenas de pull requests em minutos, a velocidade de escrita de código deixou de ser o gargalo da engenharia.
O agente de IA pode escrever o teste, gerar o diff e até abrir o PR no repositório. Mas o modelo não tem CPF, não é acordado pelo PagerDuty às 3 da madrugada durante um apagão de pagamentos e não responde pelo incidente no post-mortem.
Na era da inteligência artificial, o valor do engenheiro sênior e Staff está exatamente no ownership irredutível da decisão técnica: a máquina produz o código como ferramenta de apoio, mas a responsabilidade de garantir que o sistema é seguro, auditável e resiliente continua 100% humana.
3. Evidência Antes do Feeling: Como Destravar Priorização
Dizer em uma reunião: "Acho que a API de pagamentos está meio lenta" é a forma mais rápida de ser ignorado em favor de uma nova feature comercial. Opinião contra opinião, o backlog de vendas sempre vence.
O segredo para destravar tempo técnico é apresentar evidência mensurável:
[!NOTE]
Estrutura de Evidência Técnica (Exemplo de Telemetria de SLA): No comparativo abaixo, contrastamos a diferença prática entre uma impressão subjetiva e uma argumentação baseada em métricas mensuráveis de latência e perda financeira:
[ Relato Vago (Sem Tração) ]
"A API está demorando para responder às vezes."
[ Relato com Evidência Técnica (Ação Imediata) ]
"Nas últimas três semanas, o P95 da rota /checkout subiu de 400ms para 1.9s.
Isso causou 120 timeouts de compras no mobile, representando R$ 45.000 em
vendas não concluídas."
Com números reais na mesa, o problema deixa de ser um incômodo abstrato da engenharia e vira uma decisão de negócio inegociável.
4. O Radar de 15 Minutos para Reter Riscos na Retrospectiva
Você não precisa criar processos burocráticos. Em uma retrospectiva a cada duas semanas, reserve 15 minutos e faça três perguntas simples para a squad:
- Que comportamento estranho você viu nos últimos 15 dias que ninguém está olhando?
- Se não fizermos nada pelos próximos dois meses, o que vai quebrar?
- Quem deve ser o guardião responsável por acompanhar esse ponto?
Para cada resposta, o time escolhe uma de três saídas transparentes:
- Ignorar com Consciência: Risco calculado e aceito pelo time;
- Investigar: Timebox curto para coletar mais dados de logs e telemetria;
- Priorizar no Backlog: Criação do card com contexto real e critérios de sucesso.
Referências Técnicas Canônicas
Para desenvolver cultura de alta performance e liderança técnica na prática:
- 📖 Referência Seminal DORA: DORA Research: State of DevOps Report - Estudo canônico sobre como práticas de entrega contínua, responsabilidade compartilhada e telemetria impactam o negócio.
- 📖 Liderança Técnica (Will Larson): An Elegant Puzzle: Systems of Engineering Management - Métodos práticos para gerenciar dívida técnica e alocação de esforço em equipes de engenharia.
- 📖 Padrão de Confiabilidade Google: Google Site Reliability Engineering (SRE): Service Level Objectives (SLOs) - Como transformar queixas vagas de performance em contratos de confiabilidade baseados em dados reais.
Resumo em Uma Frase
O seu trabalho como engenheiro de software não termina quando o código compila ou o PR é mergeado. Termina quando o problema do usuário é resolvido ou quando você garante que alguém capacitado está cuidando dele.
Não deixe problemas técnicos morando apenas na sua cabeça. Traga-os para a luz com dados, transparência e maturidade.
Top comments (0)