Ownership não é o PR. É não deixar o problema só na sua cabeça

Pessoal, tem um padrão que eu vi demais em time que já sabe entregar.

O erro está no board de observabilidade há meses. Alguém já comentou no canal. Suporte eventualmente reclama. Nunca virou card. Um dia vira incidente.

Aí a pergunta aparece, desconfortável: de quem era a responsabilidade?

Eu costumava responder errado. Ownership, pra mim, era pegar o código. Se eu vi, eu conserto. Ou o contrário: se não tem task, não é comigo.

Os dois lados quebram o time. Um vira herói e gargalo. O outro normaliza o problema até ele explodir.

O que mudou foi uma distinção chata e útil: ver um problema não te obriga a implementá-lo. Obriga você a não fingir que não viu.

Quatro posturas (nenhuma é “errada” sozinha)

O salto não é de júnior pra Staff. É de pergunta.

Postura	Pergunta que guia	Sinal
Task	“Está done?”	Fecha o card sem olhar comportamento em produção
Delivery	“Está em produção?”	Acompanha o deploy, não o resultado
Outcome	“Resolveu o problema do usuário?”	Olha métrica depois do merge
Ownership	“O que mais está errado aqui?”	Percebe o adjacente sem esperar task

O problema não é alguém estar em task. É o time inteiro parar ali e ninguém carregar visão de sistema.

See it, own it — o que isso não é

Não é: “vi, então agora é minha sprint.”

É: “vi, então sou responsável por isso existir fora da minha cabeça.”

Na prática eu uso quatro passos. Nomes feios de propósito, pra não virar poster.

SEE          percebi algo estranho
UNDERSTAND   isso importa? recorrente? quem se ferrar?
EXPOSE       o problema precisa de dado, não de feeling
OWN          existe decisão ou dono — mesmo que a decisão seja “aceitamos o risco”

OWN não significa CODE.

Pode ser um card com contexto de verdade. Uma conversa com quem prioriza. Um parágrafo escrito. Uma investigação com prazo. Inclusive: “vamos conviver com isso por enquanto” — desde que isso seja decisão, não esquecimento.

Se ownership virar “quem viu implementa”, o Senior/TL vira o único adulto da sala. Isso não escala. E queima gente boa.

A heurística que muda a conversa

“Corrigimos um bug” é output.

O que costuma destravar priorização é outra frase:

Problema → evidência → impacto → ação → (depois) resultado.

Exemplo sintético, de propósito:

Uma API crítica seguia respondendo 200. Em três semanas o P95 foi de ~400 ms para quase 2 s. Ninguém tinha aberto incidente porque “ainda funciona”. Alguém colocou o gráfico no canal e perguntou o que tinha mudado. Aí deixou de ser feeling.

Sem número, o problema compete com o backlog e perde. Com número, ele vira escolha consciente.

DORA coloca o dedo nisso há anos: time de alto desempenho não é só o que mergeia rápido. É o que detecta e responde. Achar tarde custa mais — a indústria de qualidade (incluindo trabalhos associados ao NIST) repete isso em variações. O ponto prático pra mim não é o fator exato. É que “ainda está 200” não é saúde.

O que eu não estou pedindo

Ownership não é:

• resolver tudo que passar na sua timeline;
• furar priorização porque você ficou inquieto;
• trabalhar fora do horário pra “provar” que é dono;
• caçar culpado no post-mortem.

Se o framework criar ansiedade, ele falhou. O objetivo é sistema mais saudável, não indivíduo exausto.

Artefato: três perguntas, três saídas

Dá pra usar numa retro, num 1:1 ou sozinho no fim da semana.

1. Que problema você viu nas últimas duas semanas que ninguém está tratando?
2. Se continuar um mês, o que piora (usuário, on-call, lead time)?
3. Quem deveria ser o owner — ou quem decide que não tem owner agora?

Cada item sai com um status, sem teatro:

• ignorar com consciência (risco aceito, data pra rever);
• investigar (hipótese + evidência);
• abrir card (com as duas linhas de cima, não “olhar depois”).

Se a mesma coisa aparecer toda quinzena, o problema não é o card. É o sistema que ensinou o time a esperar o card.

A frase que eu deixei no material interno, e que ainda seguro em público:

Seu trabalho não termina quando o código funciona. Termina quando o problema deixa de existir — ou quando você garante que alguém é responsável por fazê-lo deixar de existir.

Onde o seu time para?

Não preciso do seu pior incidente. Quero a postura.

No último problema chato que todo mundo já via: vocês ignoraram com consciência, investigaram ou abriram card? E o que impediu a opção que vocês não escolheram?

Referências

O framework SEE → UNDERSTAND → EXPOSE → OWN e a distinção OWN ≠ CODE são síntese minha. Os links abaixo são o contexto público que usei pra amarrar “detectar tarde custa” e “entrega ≠ resultado”:

• Accelerate State of DevOps Report 2023 (DORA)
• DORA — capacidades e four keys
• NIST — The Economic Impacts of Inadequate Infrastructure for Software Testing (2002; o “quanto mais tarde, mais caro” que o mercado cita)
• Stripe — The Developer Coefficient (tempo gasto em legado / débito; leitura complementar)