É quase meia-noite. O silêncio do escritório é perturbador, mas acolhedor. Faz tempo que não me sinto assim, com a mente clareando depois de um dia que mais parecia um labirinto de interrupções. Tentar mergulhar fundo em um problema técnico, enquanto se está à frente de uma equipe, é como tentar refatorar um código legado complexo com uma dúzia de pessoas te cutucando a cada cinco minutos. Impossível. Mas não é bem assim, sei que não é.
Passei a maior parte do dia com aquele bug que insiste em se manifestar esporadicamente no ambiente de produção. Um daqueles “silent failures” que só a gente que está no front entende a malícia. A métrica de erro não explode, a funcionalidade parece OK, mas algo pequeno, quase imperceptível, está fora do lugar. Tentei isolar, reproduzir, e a cada vez que chegava perto, uma mensagem no Teams, um e-mail urgente, uma “só uma perguntinha rápida” de alguém da equipe. E o fluxo de pensamento, aquela linha tênue que nos guia pela lógica do código, se desfazia. É frustrante. Não a interrupção em si, mas a sensação de que não consigo criar aquele espaço mental para a solução.
Lembro-me de uma reunião longa, interminável, sobre o roadmap do próximo trimestre. Três horas. Saí de lá com a cabeça cheia de jargões e buzzwords, mas sem a menor ideia de como traduzir aquilo em tarefas concretas para a equipe, muito menos para mim. O pior é que, enquanto o pessoal discutia as “grandes visões”, eu estava mentalmente revisitando trechos de código, tentando visualizar a arquitetura de uma nova feature que teríamos que desenvolver. O foco se dividia, uma parte empolgada com a abstração do problema técnico, outra entediada com a abstração gerencial. E no fim, nem uma coisa nem outra se completava.
Talvez o ponto não seja a interrupção em si, mas a nossa reação a ela. Ou, melhor, a incapacidade de criar um escudo. Quando eu estava apenas codificando, sem a responsabilidade de liderar, era mais fácil. Colocava os fones de ouvido, abria o editor, e o mundo sumia. Agora, com a equipe, há uma expectativa diferente. O “silêncio” do líder pode ser interpretado de diversas formas. Desinteresse? Falta de proatividade? Falta de acessibilidade? É um equilíbrio delicado entre estar disponível para guiar, resolver impedimentos, e ainda assim conseguir aprofundar-se nos problemas técnicos que, no fundo, são o pão e a manteiga do nosso trabalho.
Teve uma vez que um membro da equipe me perguntou sobre uma decisão arquitetural. Eu estava imerso em uma análise de performance e respondi de forma um pouco seca, quase automática. Mais tarde, percebi que ele ficou chateado. Não foi intencional, mas a pressa em voltar ao meu “túnel” me fez parecer desinteressado. Isso me faz pensar: como manter esse foco profundo, essa capacidade de “debugar” a mente, sem isolar quem depende de você?
O backlog da equipe é uma coisa. O meu backlog pessoal, de coisas que precisam de um mergulho mais técnico, é outra. Muitas vezes, o meu backlog fica em segundo plano, empurrado para horários mais tardios, como agora. É a velha história: quem é o “guardião” do tempo do líder técnico? Ninguém, aparentemente. Somos nós mesmos.
Comecei a experimentar algumas coisas. Bloquear períodos na agenda para “foco profundo”, sem reuniões, sem interrupções. É difícil manter, mas quando consigo, a diferença é brutal. Consigo fazer um “deploy” mental de ideias complexas que antes ficavam em stand-by. Também aprendi a sinalizar para a equipe quando estou em um desses blocos. Não é para parecer inacessível, mas para comunicar que, naquele momento, estou em modo “refatoração interna”. Pequenas falhas de comunicação, como o bug que se manifesta esporadicamente, podem ter grandes impactos na performance da equipe.
E o feedback? Ah, o feedback. Recebi um feedback uma vez de que eu era “muito técnico”. Na hora, achei irônico. Afinal, sou um profissional de TI. Mas depois entendi o que a pessoa queria dizer: eu tendia a mergulhar tão fundo nos detalhes técnicos que, por vezes, perdia a visão mais ampla da comunicação com a equipe. É um paradoxo. O mesmo foco que me permite resolver problemas complexos pode ser o que me distancia da dinâmica humana.
Não há uma chave mágica, um design pattern para isso. É mais como um processo de tuning contínuo. Um ajuste fino da própria rotina, das próprias expectativas. Percebo que o problema não é o barulho externo, mas o ruído interno que ele gera. Aquele sentimento de que você está sempre atrasado, sempre jogando catch-up. É preciso criar uma arquitetura mental que consiga isolar os módulos. Uma espécie de contêiner para o foco, onde as dependências externas são gerenciadas de forma mais eficiente.
Às vezes, penso que a própria estrutura do nosso trabalho, com a comunicação instantânea e a colaboração constante, nos empurra para a superficialidade. É como se a expectativa fosse a de que sejamos multitarefas por natureza, sempre disponíveis. Mas o trabalho técnico profundo, o tipo de trabalho que realmente move as coisas para frente, exige o oposto. Exige um estado de fluxo, uma imersão. É uma luta diária contra a entropia da atenção.
Enfim, o bug ainda não está 100% resolvido, mas avancei. O sentimento de frustração diminuiu. Talvez o foco profundo não seja um estado constante, mas uma sequência de sprints intensos, protegidos, onde conseguimos avançar um pouco antes que a próxima interrupção nos force a um “context switch” caro. É uma dança, na verdade. Uma dança entre o mergulho e a emergência, entre o código e as pessoas. E a gente vai aprendendo a coreografia no caminho.
Ainda me pego pensando naqueles momentos de silêncio, onde a linha de raciocínio parece fluir sem esforço. É como um código que compila de primeira. Esse estado é raro, especialmente quando se gerencia. Talvez o segredo não seja eliminar as interrupções, mas construir a resiliência para refazer o deploy do foco, mesmo depois de uma falha inesperada.
