Tratei a Mim Mesmo Como um Recurso Infinito

Gastei uma quantidade enorme de esforço otimizando cuidadosamente cada parte do sistema, e quase nada no componente mais importante e menos confiável que faz tudo isso funcionar: eu. Tratei a mim mesmo como um recurso infinito e sempre disponível — uma máquina capaz de operar a plena capacidade indefinidamente — e o projeto pagou por esse erro, repetidamente e a um custo alto.

Esta é a lição que resisti por mais tempo, porque admiti-la parecia uma desculpa. Não é uma desculpa. É apenas a descrição precisa de uma restrição que me recusei a modelar, e recusar-se a modelar uma restrição real não a faz desaparecer. Só faz com que ela pegue você de surpresa.

O único componente que nunca modelei

Eu me orgulhava de pensar cuidadosamente sobre limites. Raciocinava sobre a capacidade de cada parte do sistema, seus modos de falha, como se comportaria sob carga, onde quebraria. Cada parte, exceto uma. Nunca apliquei essa mesma honestidade de engenharia a mim mesmo.

Implicitamente, sem nunca dizê-lo, eu havia assumido que poderia operar a plena capacidade para sempre — que minha energia e meu foco eram ilimitados e estavam permanentemente disponíveis, que a pessoa fazendo o trabalho não tinha teto de capacidade nem modos de falha dignos de planejamento. Nenhum engenheiro competente modelaria um componente dessa forma. Você jamais projetaria um sistema partindo da premissa de que uma parte crítica tem vazão infinita e nunca precisa de manutenção. E, no entanto, foi exatamente assim que modelei a mim mesmo, sem perceber que estava fazendo isso.

Sprints que terminavam em crateras

O padrão era sempre o mesmo, e levei um número constrangedor de repetições para enxergá-lo. Havia uma explosão de trabalho intenso e empolgante — longos períodos de foco total, ultrapassando em muito qualquer limite sustentável, porque parecia produtivo, urgente e bom. E então, com total previsibilidade, o colapso. Dias, às vezes semanas, em que eu mal conseguia trabalhar, em que o poço estava simplesmente seco e nenhuma quantidade de esforço o reabastecia.

E todas as vezes eu culpava a mim mesmo. Minha disciplina, minha fraqueza, minha incapacidade de forçar a barra. Tratava o colapso como uma falha moral pessoal, algo que uma pessoa mais durona não teria sofrido. Por muito tempo, nunca me ocorreu que o colapso não era, de modo algum, uma falha de caráter. Era a consequência inteiramente mecânica de operar um recurso finito além do seu limite. O recurso fez o que recursos finitos sempre fazem quando você os sobrecarrega. A única coisa surpreendente era que eu continuava me surpreendendo.

Burnout é uma falha de sistema, não uma falha de força de vontade

Esta é a releitura que finalmente mudou algo. Eu vinha tratando meus colapsos como falhas de vontade — eu deveria ter sido mais forte, deveria ter forçado a barra, deveria ter desejado mais aquilo. Mas burnout não é um defeito de caráter, e tratá-lo como tal garante que você continue causando-o.

Burnout é simplesmente o que acontece quando você opera qualquer sistema além de sua capacidade sustentável por tempo suficiente. É uma falha de sistema, não uma falha moral. Chamá-lo de problema de força de vontade é como chamar um motor superaquecido de problema de covardia — diagnostica de forma fundamentalmente errada o que deu errado e, por isso, prescreve exatamente a correção errada. A resposta para um motor superaquecendo não é exigir que ele seja mais corajoso. É parar de operá-lo além do limite que ele sempre teria. Mais força de vontade aplicada a um operador exausto não produz mais resultado. Só produz um colapso pior.

A matemática do ritmo

Por baixo de tudo isso há uma aritmética que eu havia ignorado por completo. Um projeto longo e difícil não é vencido pelo pico de produção em um único momento. É vencido pela produção total integrada ao longo de um tempo muito longo. E aqui está o que deveria ter sido óbvio: a soma de um ritmo moderado e sustentável, mantido de forma constante por muitos meses, supera em muito a soma de sprints heroicos pontuados por crateras.

O sprint parece mais rápido. No momento, ele é genuinamente mais rápido. Mas ao longo da distância real do projeto, é muito mais lento, porque os colapsos custam mais do que as explosões jamais renderam. Cada semana espetacular de excesso de trabalho comprava uma quinzena sombria de recuperação, e a troca era sempre um prejuízo quando você fazia a contabilidade honesta de todo o percurso. Eu vinha otimizando o quão rápido eu me sentia no momento, que é precisamente a variável errada quando a corrida é medida em meses.

Descanso é um insumo, não uma traição

Parte do que me mantinha preso era como eu pensava sobre o descanso. Tratava-o como a ausência de trabalho — tempo roubado do progresso, uma indulgência da qual sentir culpa, evidência de dedicação insuficiente. Então eu o minimizava, e me sentia virtuoso por minimizá-lo.

Mas para um recurso finito realizando trabalho cognitivo sustentado, a recuperação não é o oposto da produção. É um insumo necessário à produção. O descanso não é tempo subtraído do trabalho; é parte do que torna o trabalho possível, antes de mais nada. Recusar-se a descansar não é dedicação. É operar uma máquina sem manutenção e então tratar a quebra inevitável como azar, em vez do resultado direto e previsível de pular a manutenção. Eu havia confundido a negligência de um requisito com uma virtude.

Projetando para o operador

Então, por fim, comecei a fazer a coisa óbvia que eu havia evitado por tanto tempo: projetar o projeto em torno das restrições reais da pessoa que o conduz, exatamente como eu projetaria em torno de qualquer outra limitação real. Um ritmo que eu conseguisse genuinamente manter, em vez de um que parecia impressionante e terminava em colapso. Margens deliberadas para os dias ruins, porque sempre haverá dias ruins. Uma contabilidade honesta da minha própria capacidade como algo finito, variável e passível de manutenção — não um motor infinito ao qual eu falhava em corresponder.

A princípio, isso pareceu rebaixar meus padrões. Era o oposto. Era finalmente levar o sistema real a sério, incluindo a parte dele feita de uma pessoa, em vez de fingir que essa parte era algo que ela jamais poderia ser.

A lição mais profunda: você é o gargalo que se recusa a modelar

O que tudo se resume é isto. Em qualquer projeto conduzido majoritariamente por uma única pessoa, essa pessoa é o componente mais importante de todo o sistema — e, perversamente, aquele que mais relutamos em tratar como algo real, limitado e passível de manutenção. Otimizamos o código com carinho e abusamos do operador sem piedade, e depois nos perguntamos por que tudo continua emperrando.

Mas o projeto só avança enquanto o operador avança, e o operador não é infinito. Sustentabilidade não é uma cortesia branda, opcional e autoindulgente para se chegar quando o trabalho de verdade estiver feito. É a restrição rígida dentro da qual todo o resto do trabalho precisa caber. Passei muito tempo tratando a parte mais crítica do meu sistema como a única parte que não merecia ser projetada com engenharia. O projeto não conseguiu superar esse erro, e eu, ao que parece, também não.

— Sem sinais, sem retornos, isto não é recomendação de investimento.