CASO 01
Já sabíamos antes de começar.
Disseram-nos que o acesso necessário para realizar o trabalho seria concedido imediatamente.
O comportamento que observamos durante a mesma conversa sugeria o contrário.
O que nos disseram
Uma empresa nos pediu ajuda para melhorar sua organização de desenvolvimento de software.
Antes do início do projeto, nos reunimos com o CEO e com o head de desenvolvimento para discutir onde poderíamos ajudar.
Também nos disseram que os acessos e as permissões necessários para realizar o trabalho seriam concedidos imediatamente.
No papel, não havia problema de acesso.
Mas, durante a mesma conversa, observamos algo que nos fez duvidar dessa previsão — não porque achássemos que alguém estivesse mentindo, mas porque o comportamento apontava em outra direção.
O que observamos
O CEO sugeriu primeiro que entrássemos em um projeto existente que precisava de melhorias.
O head de desenvolvimento explicou por que isso não funcionaria: o projeto já tinha uma data de lançamento definida.
O CEO sugeriu outro projeto. Esse não tinha data de lançamento definida.
Novamente, o head de desenvolvimento explicou por que não funcionaria: havia stakeholders demais envolvidos para que alguém de fora assumisse a responsabilidade.
Cada objeção, isoladamente, poderia ser perfeitamente razoável.
Então o CEO tentou uma terceira opção: em vez de nos atribuir um projeto, talvez pudéssemos ajudar a melhorar a produtividade da equipe de desenvolvimento.
Dessa vez, a resposta foi positiva.
Isso parecia promissor.
Então fizemos uma pergunta.
Havia uma abordagem de desenvolvimento comum a toda a organização, ou cada engenheiro era livre para decidir como trabalhar?
A resposta foi que os engenheiros tinham, intencionalmente, liberdade para escolher os próprios métodos.
Em seguida, fizemos ao head de desenvolvimento uma pergunta hipotética:
Se alguém pudesse lhe mostrar uma forma diferente de trabalhar que o tornasse dez vezes mais produtivo, você a adotaria?
A resposta foi não.
Essa resposta importava.
Mas o padrão importava mais.
O padrão
Toda vez que o CEO propunha uma forma de contribuirmos, o head de desenvolvimento explicava por que aquilo não funcionaria.
- O projeto A não funcionaria.
- O projeto B não funcionaria.
- Melhorar as práticas de desenvolvimento pareceu aceitável no início — mas o responsável pelo desenvolvimento disse então, explicitamente, que nem mesmo uma forma de trabalhar drasticamente mais produtiva seria adotada se viesse de outra pessoa.
Havia outro sinal.
Nenhuma alternativa foi proposta.
A conversa era, em tese, sobre encontrar uma forma de ajudarmos. Ainda assim, uma pessoa explicava repetidamente por que cada caminho proposto era impossível, sem sugerir um caminho que fosse possível.
As objeções individuais eram dados.
O padrão entre elas era evidência de algo maior.
Nossa hipótese
O problema não era o projeto A.
Não era o projeto B.
E não era a forma específica de melhoria de produtividade que estava em discussão.
Nossa hipótese era que a organização de desenvolvimento, na prática, não aceitava intervenção externa.
Se essa hipótese estivesse correta, o problema não terminaria na decisão sobre qual trabalho faríamos.
Assim que o projeto começasse, a mesma resistência apareceria naquilo que era necessário para realizar esse trabalho — inclusive o acesso a sistemas, informações e permissões.
Por isso, antes do início do projeto, previmos que obter o acesso necessário para trabalhar de forma efetiva se tornaria um problema.
Por que seguimos em frente mesmo assim
Em circunstâncias normais, isso teria sido motivo para recusar o projeto.
Era o que pretendíamos fazer.
Mas decisões de negócio são tomadas por pessoas, não por algoritmos de otimização.
O projeto havia chegado até nós por meio de alguém a quem devíamos muito. Diante dessa relação e das circunstâncias, recusar não era, realisticamente, uma opção.
Então seguimos em frente apesar do risco que havíamos identificado.
O que as evidências mostraram
Depois que o projeto começou, os acessos e as permissões que, segundo nos disseram, seriam concedidos imediatamente se tornaram um obstáculo significativo.
A previsão se confirmou.
Mas isso não era um exercício de detecção de mentiras.
Não precisávamos determinar se alguém havia feito uma afirmação falsa de forma consciente. É possível que acreditassem sinceramente que o acesso necessário poderia ser fornecido imediatamente.
Para o nosso propósito, a intenção era irrelevante.
A declaração era um dado.
O comportamento que observamos durante a mesma conversa era outro.
Quando esses dados apontaram em direções diferentes, formulamos uma hipótese sobre o que aconteceria de fato — e esperamos por evidências observáveis que a confirmassem ou a rejeitassem.
O que as pessoas diziam era um dado. Como elas se comportavam ao dizer isso era outro.
A visão da Pulsar
A maior parte do que fazemos acontece depois que um problema já apareceu. Este caso foi diferente.
Formulamos uma hipótese sobre um problema que ainda não havia acontecido, com base em nada além da forma como duas pessoas conversaram entre si em uma única reunião.
A previsão poderia estar errada. Ela não estava garantida no momento em que a fizemos.
O que a tornou possível foi tratar o sinal comportamental como evidência por si só, e não como uma nota de rodapé ao que foi dito.
Uma hipótese confirmada depois não é sorte. É o que acontece quando se trata o comportamento como dado antes de ser preciso.