Jen Nunca Pode Sair de Férias: Quando a Especialista É o Ponto Único de Falha

TV
Thiago Victorino
7 min de leitura
Jen Nunca Pode Sair de Férias: Quando a Especialista É o Ponto Único de Falha

Jen trabalhava no Reed Group, hoje Alight Absence Management. No papel, a função dela parece tediosa. Ela processava arquivos de folha de pagamento com códigos de duas letras em colunas chamadas “Action” e “Action Reason Code”. Uma combinação como PAY/SRT não dizia nada para um analista novo. Para a Jen, significava um afastamento parcial com um tratamento específico de compliance, e ela identificava o caso em três segundos numa planilha com milhares de linhas.

Ninguém mais conseguia.

Essa última frase é o problema inteiro. Jason Cole, o CTO que conta a história da Jen no blog da darthealth, descreve a situação sem melodrama. Jen nunca conseguia tirar férias de verdade. Não daquelas em que você desliga o e-mail. Porque toda vez que algo incomum passava pelo pipeline da folha, o sistema não sinalizava. A Jen sinalizava. E se a Jen estava na praia, o caso incomum ficava parado na fila, ou pior, era processado errado.

Essa é a textura de uma falha de governança que não tem cara de falha de governança. Não há vazamento. Não há achado de auditoria. Não há regulador batendo na porta. Há apenas um ser humano que virou uma parede estrutural, e uma empresa que aceitou silenciosamente que essa parede nunca pode ser reformada sem derrubar o prédio.

A Pergunta de Diagnóstico

Quando você descobre uma Jen na sua operação, o instinto é tratar como problema de pessoal. Contratar mais duas Jens. Treinar juniores em cross-training. Pagar um bônus de retenção grande o suficiente para comprar a lealdade dela pelo próximo ano fiscal.

Nada disso resolve o problema. O cross-training assume que o conhecimento pode ser transferido numa conversa. Não pode. O reconhecimento de padrão da Jen não estava no PowerPoint dela. Estava nas mãos dela, construído ao longo de milhares de arquivos em que ela viu o que acontecia quando PAY/SRT era classificado errado dois trimestres depois. Contratar mais Jens assume que o mercado de trabalho produz Jens. Não produz. A Jen é um artefato da história específica de uma empresa específica, processada por uma carreira específica de uma pessoa específica.

A pergunta de diagnóstico correta é a que Cole fez. Não “como substituímos a Jen”, mas “por que a empresa depende da Jen, em primeiro lugar?” A resposta é que o sistema de folha nunca codificou o que o sistema de folha realmente fazia. Os códigos nunca foram documentados porque as pessoas que os usavam não precisavam de documentação. Os padrões nunca foram escritos porque os padrões viviam na memória muscular da equipe que os lia.

Isso é dívida técnica. Só que carregada por uma pessoa em vez de uma página de Confluence.

Documentação É uma Fotografia

Aqui está a frase de Cole que justifica todo o texto. “Documentação é uma foto do que alguém lembrava no dia em que escreveu. Sabedoria é saber o que fazer quando dados com o mesmo cheiro mas uma cara diferente aparecem na próxima vez.”

Leia duas vezes. A implicação é brutal para qualquer organização que passou a última década rodando iniciativas de gestão do conhecimento. O runbook é uma foto de um momento. A sabedoria é o olho do fotógrafo, que o runbook nunca consegue capturar. Toda trilha de auditoria, todo procedimento operacional padrão, todo deck de onboarding é necessariamente incompleto da mesma forma. O caso incomum, aquele que tem cheiro de PAY/SRT mas não é exatamente PAY/SRT, é justamente o caso que a documentação não cobre.

É por isso que a resposta padrão para o problema da Jen falha. Você escreve o runbook. O runbook cobre os casos que a Jen já viu várias vezes. O próximo caso incomum aparece. O runbook não cobre. A Jen continua tendo que olhar. A Jen continua sem poder tirar férias. O runbook não resolveu nada para os casos que realmente importam, que são justamente aqueles que precisavam do julgamento da Jen.

A armadilha é tratar documentação como destino. Documentação é uma estação intermediária. O destino é um sistema que consegue fazer o que a Jen faz, ou seja, reconhecer que algo é incomum e saber o que fazer a respeito. Ou, nos casos em que não consegue fazer a segunda parte, pelo menos saber como escalar a primeira.

O Que Cole de Fato Construiu

A resposta do Reed Group foi algo que Cole chama de Data Nexus. A arquitetura importa menos do que o comportamento operacional. O Nexus aprende o reconhecimento de padrão da Jen. Ele olha para o arquivo de folha e aplica as mesmas heurísticas que a Jen construiu ao longo dos anos. Quando vê um padrão familiar, processa o caso. Quando vê algo ambíguo, algo com o mesmo cheiro mas uma cara diferente, ele não chuta. Marca o registro para revisão humana e diz ao humano o que tornou o caso suspeito.

O sistema cuida dos casos com precedente. A Jen cuida dos casos sem precedente. Essa única mudança reescreve toda a economia da função.

Vale citar Cole diretamente. “A Jen com o Data Nexus vira o Dr. House, consultando apenas nos casos realmente interessantes, enquanto o sistema aprende.” O House não atendia todos os pacientes que entravam no Princeton-Plainsboro. Ele atendia os pacientes que tinham derrotado o pipeline diagnóstico padrão. Esse é o trabalho de um especialista. A Jen, antes do Nexus, estava fazendo o equivalente a diagnosticar de faringite a lúpus, todos os dias, o dia inteiro. O Nexus não substituiu a Jen. Promoveu a Jen.

Esse é o padrão de governança. Codifique o conhecimento tácito que já tem precedente. Escale os casos novos para o humano com o julgamento para resolvê-los. O sistema fica mais rápido no trabalho rotineiro ao longo do tempo. O humano passa a ser pago pelo trabalho que exige expertise de verdade. E o humano, finalmente, consegue tirar férias, porque a fila rotineira continua andando sem ela.

Por Que Esse É um Padrão de 2026, Não de 2018

A gente vinha contando essa história de forma errada por uma década. A versão que continuávamos contando era “IA vai substituir trabalhadores do conhecimento”. Essa história sempre foi simples demais, e quem fazia o trabalho operacional de verdade sentia que era simples demais. Substituir a Jen por quê? Por um modelo que nunca viu um arquivo de folha do Reed Group? Por um SaaS de fornecedor que não sabe o que PAY/SRT significa no contexto de compliance específico da sua empresa?

A versão de 2026 dessa história é diferente. O Nexus não é um modelo genérico. É um sistema construído ao redor da Jen, que aprendeu com a Jen e que roda ao lado da Jen como instrumento dela. Ele só existe porque a Jen existiu antes. O conhecimento institucional foi o insumo, não o produto a ser deletado.

O padrão transferível é este. Toda frase do tipo “temos uma pessoa que sabe X” na sua organização é dívida técnica. Não é uma peculiaridade simpática. Não é sinal de cultura forte. É dívida. Tem custo de carregamento (as férias que a pessoa não consegue tirar, o conhecimento que sai pela porta quando ela sai, as filas que acumulam quando ela fica doente) e custo de refinanciamento (o projeto que finalmente codifica o conhecimento num sistema). Hoje, em 2026, o custo de refinanciamento está mais baixo do que nunca, porque as ferramentas para capturar, codificar e escalar viraram commodity.

As empresas que vão operar IA bem nos próximos três anos são as que vão sair procurando suas Jens de forma deliberada. Não para substituí-las. Para finalmente quitar a dívida que vinham carregando nas costas delas.

Faça Isso Agora

Escolha uma operação da sua empresa e faça uma única pergunta. Se essa pessoa tirasse três semanas de férias, sem e-mail, sem Slack, o que ficaria parado na fila e o que seria processado errado?

Essa resposta é sua candidata a Jen. A próxima pergunta é que fração do trabalho dela tem precedente (codificar) e que fração é genuinamente nova (escalar). Trate a codificação como projeto de software, não como projeto de documentação. Trate a escalação como problema de desenho de workflow, não como problema de contratação. E coloque a humana na cadeira que exige o julgamento dela, não na cadeira que exige que ela faça a mesma tarefa de reconhecimento dez mil vezes seguidas.

Depois mande ela tirar férias. O sistema que você construiu vai dizer se você terminou o serviço de verdade.


Fontes

A Victorino ajuda lideranças de operações a converter dependências de especialista único em workflows governados e aumentados por IA, transformando a Jen do seu time na especialista que finalmente tira férias de verdade: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa