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

Posse não é a responsabilidade de um único indivíduo. É a postura de não deixar os problemas apenas na sua cabeça. Há um padrão que ela observa em times que entregam bem: o erro está no board de observabilidade há meses, mas ninguém assumiu a responsabilidade. Alguém comentou no canal, mas o suporte só reclama depois. O problema costuma virar um incidente somente quando a pergunta aparece: de quem era a responsabilidade?

Antigamente, ela pensava que a posse era pegar o código. Se ela viu, ela consertava. Mas essa visão quebrava o time, uma pessoa se tornava herói ou gargalo, enquanto o outro normalizava o problema até que explodisse. Ela percebeu que o tempo de ver um problema não significa que ela deve implementá-lo. O importante é reconhecer que ela viu, sem fingir que não viu.

Eles distinguem quatro posturas: Pergunta que guia, Task “Está done?”; Delivery “Está em produção?”; Outcome “Resolveu o problema do usuário?”; Ownership “O que mais está errado aqui?” O verdadeiro problema não é alguém ficando preso na tarefa. É o time inteiro parar e ninguém carregar a visão de sistema. Ela usa quatro passos práticos para lidar com o problema: SEE → UNDERSTAND → EXPOSE → OWN.

"See" significa perceber algo estranho, "Understand" se trata de entender se isso importa, "Expose" é colocar o problema em evidência com dados, não sentimentos, e "Own" envolve tomar uma decisão ou assumir a propriedade, mesmo que não seja codificação. A posse não significa apenas codificar o problema, pode ser abordar a questão com o dono do card, escrever um parágrafo de contexto, ou enquadrar um problema com um prazo, inclusive: "vamos conviver com isso por enquanto".

Se assumir a posse virar "quem viu implementa", o Senior ou Time Lead se torna o único adulto na sala, o que não escala e pode deixar boas pessoas cansadas. O framework que ela usa para mudar a conversa é: "Corrigimos um bug" é output. A frase que usa para priorizar é: Problema → evidência → impacto → ação → (depois) resultado. Por exemplo, ela observou que uma API crítica mudou de tempo de resposta, passando de 200ms para 2 segundos.

Sem um número, o problema seria ignorado, mas com o gráfico e a explicação, a priorização muda. A indústria de qualidade, incluindo aqueles que trabalham com NIST, repete que o time de alto desempenho não é só quem mergeia rápido, mas quem detecta e responde. Ela destaca que o verdadeiro objetivo é um sistema mais saudável, não quem fica exausto.

Ela deixa três perguntas para refletirem: qual problema você viu nas últimas duas semanas que ninguém está tratando? Se continuar um mês, o que piora? E quem deveria assumir a posse ou quem decide que não tem posse agora?