Hoje, no fim do dia, enquanto o monitor ainda reflete um pouco da luz azul da IDE, fico pensando naquela conversa com a Ana. Ela veio com uma daquelas solicitações “urgentes” que não parecem urgentes, mas viram se a gente não pega. E eu, no meio de um refactor que já estava virando um monstro, só consegui balbuciar um “vou ver isso”. Clássico. O problema não é fazer. É como fazer com que ela sinta que está pegando algo que é dela, e não uma batata quente que eu joguei.
É engraçado como a gente, de TI, que lida com lógica e sistemas, às vezes se enrola tanto em coisas que parecem tão, sei lá, humanas? Delegar. A palavra já vem com um peso. Significa “passar adiante”. E na cabeça de quem recebe, dependendo de como a coisa é dita, pode virar um “jogar fora”. Já vi muito colega meu se afogando em trabalho porque não conseguia passar nada pra frente. E eu mesmo, muitas vezes, me pego pensando se não seria mais rápido fazer logo do que explicar. Mas aí vira bola de neve. A gente sabe.
Lembro de uma vez, num projeto de integração de sistemas legados. Um inferno. Tinha um módulo específico que ninguém queria pegar, cheio de dependências obscuras e com uma documentação que parecia mais um enigma. Eu acabei pegando, claro. Porque era “mais rápido”. Só que o “mais rápido” levou três dias, e eu perdi o prazo de uma feature importante. Se eu tivesse delegado no começo, mesmo que levasse mais tempo pra explicar, o resultado final seria melhor. Mas a questão é: como delegar sem soar como se eu estivesse me livrando do problema? Sem que a pessoa sinta que está pegando o “módulo inferno” porque eu não quis pegar?
Acho que parte da coisa está no jeito de apresentar. Não é só jogar a tarefa. É a narrativa. É como se, em vez de dizer “Faz isso pra mim”, a gente dissesse “Olha, tem esse pedaço aqui que eu acho que você tem uma visão legal para resolver, e ele se encaixa com o que a gente está fazendo ali”. É diferente. Não é sobre o meu problema, é sobre a solução, sobre a contribuição da pessoa.
Tem a questão do contexto também. Muitas vezes, a gente só joga a tarefa e espera que a pessoa se vire. Mas a gente sabe o histórico, as pequenas armadilhas, as decisões tomadas em reuniões que ninguém lembra direito. O silêncio, nesse caso, pode ser interpretado como um “se vira, não é problema meu”. E aí a pessoa empaca, ou faz algo que não era bem aquilo, e a gente reclama. Mas quem não deu o contexto fui eu. É tipo um bug silencioso no processo. Ninguém reporta, mas o sistema falha.
Outra coisa que me incomoda é quando a gente tenta delegar demais, ou delega o que não é pra delegar. Tipo, um problema que eu causei e eu deveria resolver. Ou uma decisão estratégica que eu deveria tomar. Não é sobre tirar o peso de mim, é sobre otimizar o fluxo. Se eu passo algo que não deveria, a pessoa sente. Sente que estou empurrando. E aí a confiança vai pro ralo. E a gente sabe o quanto é difícil construir confiança numa equipe de TI, onde cada linha de código conta.
Já me vi nessa situação de ser o “mandão” sem querer. Achando que estava sendo eficiente, mas na verdade estava só despejando coisas nos outros. Aquele feedback que vem de lado, uma indireta sobre a sobrecarga. Aí a gente percebe que o problema não era a tarefa, mas o approach. Era o tom, a falta de cuidado na comunicação.
É um equilíbrio delicado. Não quero ser o cara que segura tudo, que vira o gargalo. Mas também não quero ser o cara que só passa o pepino adiante. Acho que a diferença está em como a gente se posiciona. Não como o chefe que distribui ordens, mas como um colega que vê um ponto de alavancagem para o time, uma oportunidade de crescimento para o outro.
E o que me veio à cabeça agora foi a analogia com um deploy. Quando a gente faz um deploy, a gente não só joga o código em produção. A gente prepara o ambiente, a gente testa, a gente monitora. A gente dá suporte. Delegar é um pouco isso. É preparar o ambiente, é dar o contexto, é estar disponível para o “suporte” se a coisa der errado. Não é só largar o pacote.
Porque, no fundo, todo mundo quer contribuir. Ninguém quer ser um mero executor de tarefas aleatórias. A gente quer sentir que o que a gente faz tem um propósito, que agrega valor. Se eu delego de uma forma que mostra esse propósito, que conecta a tarefa com o objetivo maior, acho que a coisa muda de figura. A tarefa deixa de ser um peso e vira parte de algo maior.
Talvez seja menos sobre a palavra “delegar” e mais sobre “compartilhar responsabilidades”. Mas não de um jeito burocrático, com reuniões de alinhamento intermináveis. É algo mais orgânico. Uma conversa, um entendimento. É como quando a gente faz um code review. Não é pra apontar erro, é pra garantir que o código esteja bom, que o sistema esteja robusto. É uma colaboração.
E a gente, que vive cercado de prazos apertados e de bugs inesperados, precisa de um time que funcione. Um time onde as pessoas se sintam valorizadas e não sobrecarregadas. Esse é o desafio. Não é uma fórmula pronta. É um ajuste fino, constante, como o tuning de um sistema que a gente nunca para de otimizar.
No fim das contas, talvez seja sobre reconhecer que o outro também tem suas prioridades, suas dificuldades. Que ele não é só um recurso disponível. E que a forma como a gente passa uma tarefa pode definir se ela vai ser recebida com boa vontade ou com um suspiro.
Ainda penso sobre isso. É um daqueles pontos que ficam borbulhando na cabeça depois que o dia de trabalho acaba. O monitor já escureceu, mas a ideia ainda está ali, meio em aberto, sem uma conclusão definitiva. É um nó que, de vez em quando, a gente tenta desatar, mas que parece sempre ter mais uma pontinha solta. O que sei é que a forma como lidamos com isso impacta o dia a dia de todo mundo, inclusive o meu.
