No dia em que alguém pede demissão, sua empresa esquece como ela funciona

Uma engenheira nova entra numa segunda. Até quinta ela precisa lançar um pequeno fix, e bate numa pergunta que só uma pessoa consegue responder, a pessoa que construiu aquele passo de deploy e foi embora três semanas antes de ela começar. O handle de Slack dele está desativado. As notas dele, se algum dia existiram, estão num doc que ninguém acha. Então ela faz o que todo novato faz: pergunta ao humano mais próximo, que lembra pela metade, e ela lança num chute.

Nada disso é um problema de treinamento. O treinamento estava bom. A apresentação de orientação estava boa. O problema é mais antigo e mais estranho do que tudo isso: a resposta que ela precisava nunca foi armazenada em lugar nenhum que uma pessoa pudesse alcançar. Ela vivia numa cabeça só, e a cabeça saiu pela porta, e no dia em que saiu, um pedaço pequeno e específico de como a empresa de fato funciona silenciosamente deixou de ser conhecível.

Essa é a dor que continuávamos encontrando, na nossa própria empresa e na de cada cliente, e é a dor que nada no mercado de fato resolve. Uma empresa que não consegue lembrar é uma empresa que reaprende a si mesma toda vez que alguém vai embora. Onboarding é só o lugar onde você finalmente sente isso, o momento em que uma pessoa fresca colide com tudo que a empresa esqueceu de guardar.

Este post é uma perícia: para onde o conhecimento vai, por que cada conserto existente erra, e o que se torna possível quando a própria empresa consegue segurar uma resposta.

Para onde a resposta de fato vai

Abra o almoço de boas-vindas e a sacola de brindes e pergunte o que onboarding é, mecanicamente. É uma transferência de conhecimento, rápida, em pânico, que tem que acontecer exatamente quando a fonte do conhecimento está menos disponível. O novato precisa de cem pequenas verdades: como fazemos deploy, quem aprova o quê, por que aquela coisa de aparência quebrada é load-bearing, qual fornecedor ligar, qual é a regra não escrita. Quase nada disso está num sistema. Está distribuído por algumas dúzias de cabeças humanas, cada uma segurando um caco diferente, nenhuma delas com tempo de transcrevê-lo.

Então o novato vira um detetive. A semana um é tranquila, o buddy designado está fresco, as calls de intro estão agendadas, a boa vontade é alta. Aí a semana dois chega e as costuras aparecem. O buddy é puxado para um lançamento. A única pessoa que entende billing está de férias. “Como fazemos code review aqui” retorna três respostas diferentes de três pessoas diferentes, porque a regra vive em cinco cabeças e nenhuma delas concorda. A verdadeira lição da semana dois não é nenhum fato isolado. É o meta-fato: conhecimento aqui é uma pessoa que você tem que pegar, e pegar pessoas é um trabalho de tempo integral que ninguém te disse ser seu trabalho.

Os números dizem que quase todo mundo está vivendo essa versão. A Gallup relata que apenas 12% dos funcionários concordam fortemente que sua organização faz um ótimo trabalho de onboarding, mais ou menos sete em cada oito novatos são o detetive acima. E a SHRM Foundation há muito documenta que um onboarding forte eleva a retenção do primeiro ano enquanto um fraco está entre os sinais mais claros de que um novato sai dentro do ano. O custo de um primeiro mês ruim não é uma semana desconfortável. É a pessoa que você contratou saindo de volta pela porta, porque uma empresa que não consegue lembrar a fez se sentir como se ela fosse a única que já não sabia.

Os dois consertos que o mercado fica vendendo, e por que ambos erram

Quando uma empresa finalmente leva isso a sério, o mercado lhe entrega duas respostas. Ambas são tentativas honestas. Ambas erram, e vale ser preciso sobre por quê, porque a forma como elas erram é a razão inteira de termos construído algo com um formato diferente.

A primeira resposta é um buddy melhor, um programa mais suave, um período de shadowing mais longo, uma checklist de calls de intro. Parece humano: pessoas aprendem de pessoas, então aponte a pessoa nova para mais pessoas, mais calorosamente. Mas não toca a falha de verdade. Só nomeia um humano como o lembrador designado e reza para que esse humano fique no prédio, fique não-ocupado, e calhe de segurar o caco exato que este novato precisa. Você não tornou o conhecimento durável. Você adicionou um ponto único de falha mais simpático que ainda pode pedir demissão.

A segunda resposta é escreva o wiki, exija documentação, faça as pessoas colocarem num doc. Você já viu como isso termina. Escrever docs é uma tarefa separada de fazer o trabalho, então é sempre a tarefa que é cortada. O wiki é escrito uma vez, no lançamento, por alguém que já sabe tudo e portanto não consegue ver o que um recém-chegado não vai saber. Seis meses depois ele descreve um sistema que não existe mais, e um wiki errado é pior que nenhum wiki, porque o novato confia nele e lança numa mentira.

Note o erro em comum. Ambos os consertos tratam memória como uma tarefa chata que um humano escolhe fazer, pegar a pessoa certa, ou sentar e escrever o doc. Qualquer coisa que dependa de um humano ocupado fazer trabalho extra, no momento em que esse trabalho é menos urgente para ele, não vai acontecer em escala. Uma empresa que não consegue lembrar sozinha não vai começar porque você pediu gentilmente. A suposição perdedora não é o buddy nem o wiki. É que memória institucional é um favor que as pessoas prestam, em vez de algo que a empresa é estruturalmente capaz de fazer.

Não estávamos tentando construir um buddy melhor ou um wiki mais esperto. Estávamos construindo uma empresa que não depende de nenhum dos dois, onde lembrar não é tarefa chata de ninguém porque é uma propriedade do substrato em que o trabalho já roda.

Aquela imagem é a diferença entre as duas pistas, e é o argumento inteiro num quadro só: numa, conhecimento é uma pessoa que pode ir embora; na outra, é um ativo que a empresa possui e pode servir para sempre.

O que é preciso para uma empresa de fato lembrar

Aqui está a parte que nos deu trabalho de verdade, porque “só armazene o conhecimento” é exatamente o que o wiki prometeu e não conseguiu entregar. A razão de não conseguir é que ele pediu a um humano para fazer o armazenamento. O substrato tem que fazê-lo no lugar, e ele consegue, por causa do que o OS já é, não por causa de uma feature de documentação que parafusamos.

Duas coisas têm que ser verdadeiras, e nenhuma pode ser um favor que alguém tem que lembrar de fazer.

A resposta tem que ser capturada do próprio trabalho. Quando o deploy roda, os passos já são observados. Quando uma pergunta é feita e respondida num canal, essa troca já é um fato recuperável. Quando o especialista explica uma coisa uma vez, a explicação é guardada, não como uma tarefa que ele fez na tarde de documentação, mas como o escapamento dele fazendo seu trabalho de verdade. O company brain enche da motion normal da empresa, o que significa que o passo de escrever-isso que sempre era cortado não é um passo que alguém tem que executar. Essa capacidade não é um wiki. É o que um sistema faz quando está ligado e vivendo onde o trabalho acontece, a mesma propriedade que o deixa fazer uma dúzia de outras coisas, aqui apontada para memória.

E o novato tem que conseguir alcançá-la nas próprias palavras. Captura é metade do trabalho; a outra metade é recall que funciona do jeito que uma pessoa travada de fato pensa. Não “saiba o termo de busca mágico sob o qual o doc foi arquivado”, mas “pergunte do jeito que você perguntaria a um colega”, como faço deploy de um hotfix aqui, e quem tem que aprovar?, e receba de volta os passos capturados e a razão por trás deles. A razão é a parte que mais importa e menos sobrevive. Uma lista de comandos te diz o que digitar; ela não te diz por que a aprovação existe, ou qual passo é aquele que as pessoas pulam e se arrependem. A resposta capturada carrega ambos, porque veio das pessoas que aprenderam do jeito difícil, e agora o novato herda a lição sem ter que revivê-la.

Uma empresa que não consegue lembrar faz sua pessoa mais nova e menos equipada re-derivar verdades que a empresa já pagou para aprender. O conserto não é um manual mais grosso. É tornar a memória uma propriedade da empresa em vez de uma propriedade de quem quer que calhe de ainda estar sentado lá.

A pessoa que já pediu demissão é o ponto inteiro

Você poderia ler tudo isso como uma conveniência simpática para a semana dois e perder a coisa que de fato importa. Então deixe-me dizer claramente.

Toda empresa, a todo momento, está vazando conhecimento através das pessoas prestes a sair. Turnover não é um evento do qual você se recupera, é um dreno constante. O US Bureau of Labor Statistics rastreia milhões de pedidos de demissão voluntária todo mês; em qualquer time de tamanho real, alguém está sempre a caminho da saída. Quando vão, eles não só desocupam uma cadeira. Eles levam as respostas que só eles tinham: o porquê por trás de uma gambiarra estranha, o contato do fornecedor, a razão pela qual a coisa load-bearing que parece quebrada não pode ser tocada.

A defesa padrão, a entrevista de desligamento, o doc de handoff de duas semanas, é uma ficção, e a mesma ficção do wiki. Ninguém transcreve dois anos de julgamento na última quinzena, e as coisas que você mais precisa são precisamente as coisas que eles não pensam em escrever, porque para eles são óbvias. O conhecimento mais difícil de capturar é o conhecimento mais caro de perder, e ele vai embora na cabeça de uma pessoa toda vez.

Este é o caso em que “uma empresa que não consegue lembrar reaprende a si mesma toda vez que alguém vai embora” deixa de ser uma frase e vira um número num calendário. Você não consegue impedir as pessoas de irem embora; você não deveria tentar. O que você pode mudar é se ir embora leva o conhecimento junto. Se a resposta foi capturada enquanto o especialista estava aqui, então no dia em que ele pede demissão, a cadeira dele esvazia mas as respostas dele não. O novato três semanas depois pergunta à empresa e recebe a resposta que o especialista teria dado, sem o especialista.

Esse loop é a coisa de fato que estamos construindo. Capture a resposta enquanto a cabeça está aqui. Mantenha-a quando a cabeça vai embora. Sirva-a à próxima pessoa que precisar, e deixe a pergunta dela aprofundá-la ainda mais. Turnover deixa de ser um penhasco de conhecimento e vira um fluxo normal de pessoas através de uma memória que sobrevive a qualquer uma delas.

Contrate bem e você mantém boas pessoas. Construa uma empresa que consegue lembrar e você mantém o que elas sabiam, quer fiquem ou não.

A amplitude que ninguém parafusou

Vale nomear por que isto não é um produto de onboarding e nunca será. Para fazer a quinta-feira do novato funcionar, não construímos uma ferramenta de RH. Apontamos as mesmas duas coisas que o OS já faz, capturar o escapamento do trabalho real, responder perguntas em linguagem simples com a razão anexada, para um momento doloroso na primeira semana de uma pessoa.

Que é por que o mesmo substrato quietamente responde ao engenheiro de suporte que herda um ticket sobre um sistema cujo autor foi embora, ao gerente reconstruindo por que uma decisão foi tomada duas reorganizações atrás, ao auditor rastreando quem aprovou o quê. Esses não são cinco features lançadas para parecer cinco ferramentas. São um formato, uma empresa segurando a própria memória e servindo-a de volta, caindo de graça onde quer que uma pessoa fosse de outro modo perseguir outra pessoa. A amplitude não é uma checklist da qual nos orgulhamos. É o sinal de que construímos memória no nível da empresa, não um departamento por vez.

A virada: as boas-vindas nunca foram a documentação

Então seja preciso sobre o que isto substitui e o que jamais deve tocar.

Não substitui o humano que leva o novato ao café no primeiro dia, nota que ela está sobrecarregada, diz a coisa certa, faz uma estranha se sentir pertencente. As boas-vindas, a confiança, o senso de que estas são pessoas com quem vale a pena fazer trabalho difícil ao lado, nenhum company brain captura isso, e nenhum deveria tentar. Pertencimento não é um fato recuperável.

O que ele substitui é o imposto sentado em cima das boas-vindas. O engenheiro sênior respondendo a mesma pergunta de setup pela décima primeira vez em vez de construir. O novato gastando a semana dois como detetive em vez de contribuir. O pavor lento de não saber a quem perguntar e não querer parecer que você não sabe. Esse imposto nunca foi a parte humana do onboarding, era a parte que tornava a parte humana impossível, porque as pessoas que deveriam estar dando boas-vindas estavam presas sendo um buscador para memória institucional que a empresa nunca se deu ao trabalho de guardar.

Esse mundo, onde ir embora deixa de custar à empresa a própria memória, onde a pessoa mais nova pode perguntar à empresa em vez de perseguir uma pessoa que já pediu demissão, não existe no mercado ainda. O mercado ainda está vendendo manuais mais grossos e buddies mais simpáticos, ainda tratando memória como uma tarefa chata para a qual um humano tem que se voluntariar. Achamos que uma empresa deveria simplesmente conseguir lembrar, do jeito que uma pessoa lembra, como uma propriedade de estar viva e em trabalho. Estamos construindo isso a partir da dor de ver a resposta ir embora, um pedido de demissão por vez, e onboarding é só o primeiro lugar onde você consegue senti-lo funcionar. A novata na quinta acerta o deploy de primeira, a cadeira do especialista esvazia e as respostas dele ficam, e as pessoas que costumavam ser um buscador voltam a ser pessoas de novo.