Os dados concordavam com eles. No início.

O que nos disseram

Disseram-nos que um engenheiro estava com desempenho abaixo do esperado.

As preocupações vinham da liderança de produto e de engenharia.

O engenheiro era descrito como alguém que demorava demais para entregar, questionava decisões com frequência excessiva e prejudicava a harmonia da equipe.

A organização considerava tirar o engenheiro da equipe.

As evidências pareciam claras.

Do momento em que um trabalho era atribuído no GitHub até a abertura de um pull request, esse engenheiro frequentemente levava mais tempo do que esperaríamos para a implementação em si.

Por essa métrica, o engenheiro realmente era mais lento.

O que observamos

O GitHub mostrava o tempo decorrido.

Não mostrava o que o engenheiro fazia durante esse tempo.

Então seguimos o trabalho até o Slack.

Depois de receber uma solicitação, o engenheiro frequentemente perguntava por que determinada especificação existia, que problema ela pretendia resolver ou se uma implementação diferente atingiria melhor o mesmo objetivo.

Não eram objeções aleatórias.

Eram tentativas de entender o contexto do requisito ou de propor uma alternativa antes que a implementação começasse.

O product owner geralmente tratava essas perguntas e propostas como desnecessárias.

Quando uma proposta era rejeitada, o engenheiro começava a implementação imediatamente.

Quando uma pergunta ou proposta não recebia resposta, o engenheiro não esperava indefinidamente.

Após três dias úteis, ele registrava que não havia recebido resposta e que a implementação seguiria com base na solicitação original.

Só então o trabalho de codificação começava.

O padrão

A organização media todo o tempo entre a atribuição e a entrega como tempo de execução da engenharia.

Mas uma parcela significativa desse tempo era gasta antes da implementação.

O engenheiro tentava esclarecer a intenção, questionar premissas ou propor uma alternativa.

Essas atividades não eram contabilizadas como trabalho útil.

Eram interpretadas como atraso.

Essa interpretação também moldava a reputação do engenheiro.

Fazer perguntas parecia resistência.

Propor alternativas parecia recusa em seguir instruções.

Esperar por uma decisão de produto sem resposta parecia implementação lenta.

O mesmo comportamento era, portanto, usado como evidência para vários julgamentos negativos sobre a pessoa.

Então encontramos outro sinal

Algumas das propostas do engenheiro que haviam sido rejeitadas ou ignoradas não desapareceram.

Depois que a implementação original era lançada, o product owner às vezes solicitava a mesma ideia em uma sprint posterior.

A proposta antes tratada como desnecessária podia voltar depois como requisito oficial.

Isso importava.

Mostrava que as perguntas e as propostas alternativas do engenheiro não eram mera obstrução.

Ao menos algumas delas identificavam melhorias que a área de produto acabaria querendo de qualquer forma.

Nossa hipótese

O engenheiro não sofria, principalmente, de um problema de capacidade.

A organização havia criado um ambiente em que um tipo de comportamento de engenharia era recompensado acima de todos os outros:

Executar a instrução como ela foi dada.

Questionar a especificação gerava atraso.

Sugerir uma alternativa gerava atrito.

Esperar por esclarecimentos aumentava o lead time medido.

Dessa perspectiva, um engenheiro que tentava melhorar o trabalho antes de implementá-lo podia parecer menos produtivo do que um engenheiro que simplesmente começava a codificar de imediato.

O sistema não estava apenas medindo a velocidade de entrega.

Estava, indiretamente, recompensando a obediência às instruções.

Por que o diagnóstico original parecia convincente

O julgamento original não se baseava em dados imaginários.

O tempo decorrido realmente era maior.

Era isso que tornava o caso interessante.

Uma única fonte de evidência sustentava a conclusão da organização.

Se tivéssemos parado no GitHub, poderíamos ter chegado à mesma conclusão.

Mas a métrica respondia apenas uma pergunta:

Quanto tempo se passou entre a atribuição e a entrega?

Ela não respondia:

• Quando a implementação realmente começou?
• O que aconteceu antes da implementação?
• Quem estava esperando por quem?
• Que decisões estavam pendentes?
• Que valor estava sendo criado fora do próprio código?

O que as evidências mostraram

O engenheiro era mais lento se medíssemos apenas o tempo decorrido até a entrega.

Mas esse número combinava vários tipos diferentes de atividade em uma única métrica.

Quando separamos a implementação do esclarecimento, da proposta, da decisão e do tempo de espera, o significado do número mudou.

A organização havia interpretado um padrão de interação no nível do sistema como um problema de desempenho individual.

Tirar o engenheiro da equipe não teria corrigido esse padrão.

Teria apenas removido a pessoa cujo comportamento tornava o padrão visível.

Os dados não estavam errados. A interpretação é que estava incompleta.

A visão da Pulsar

Não começamos decidindo se uma pessoa é boa ou ruim no que faz.

Rastreamos o trabalho.

Neste caso, o GitHub mostrou que a entrega demorava mais.

O Slack mostrou por quê.

Decisões de produto posteriores mostraram que parte do comportamento supostamente desnecessário vinha identificando valor real.

Nenhuma dessas observações, sozinha, contava a história inteira.

Juntas, elas mudaram o diagnóstico.

Não avaliamos pessoas a partir de um único sinal. Investigamos o sistema que produziu o sinal.