Esses dias, numa conversa individual, um dos desenvolvedores do time me contou que tinha chegado ao fim de um dia cheio com a sensação de que não tinha feito nada.

Não era falta de trabalho. Ele tinha respondido mensagem, ajudado outras pessoas e lidado com pedidos que apareceram no meio do caminho. Só que as tarefas que realmente dependiam dele continuavam no mesmo lugar. O dia ficou cheio, mas o resultado que ele esperava enxergar não apareceu. Reconheci ali um comportamento que já tive no passado. Eu também tinha dificuldade de não assumir um problema quando sabia resolver. Alguém chamava, eu conhecia o contexto e parecia mais rápido fazer logo do que parar para pensar se aquilo precisava mesmo ser feito por mim.

O que me ajudou foi aprender a delegar. Não simplesmente tirar uma tarefa da minha lista, mas entender quando eu precisava resolver, quando outra pessoa podia assumir e qual contexto ela precisava para seguir. Parece óbvio olhando de fora. Para quem se acostumou a ser chamado justamente porque sabe resolver, não é.

Agora, nesses primeiros meses como tech manager, tenho visto o mesmo desafio aparecer com os desenvolvedores do time. Alguém chama no Slack, outra pessoa precisa de suporte, um incidente aparece e uma tarefa que nem existia de manhã chega com cara de que deveria ter sido entregue ontem. A vontade é ajudar todo mundo. Não tem como.

[!NOTE] Minha meta para este ano era publicar um artigo por mês. Junho passou em branco. Foi um mês corrido, mas o artigo não saiu por falta de planejamento meu. Então julho vai ter dois textos. A conta continua a mesma: fechar o ano com 12 artigos publicados.

A vontade de resolver porque eu sei resolver

O caso que puxou essa conversa era simples. Um dashboard estava com um link desatualizado e quem precisava acessar chamou justamente ele, porque tinha criado o alerta original. O primeiro impulso foi assumir o problema. Faz sentido: ele conhecia o contexto, sabia por onde começar e queria ajudar. Só que a correção levaria cerca de uma hora e meia. E havia duas demandas mais importantes esperando por ele, incluindo uma transferência de conhecimento que bloqueava o começo de outra entrega. Se ele aceitasse aquele pedido, resolveria um problema rápido para alguém e empurraria o próprio trabalho para o dia seguinte.

Dessa vez ele parou. Lembrou de um feedback que tínhamos conversado e orientou quem o chamou a procurar a pessoa que já tinha feito aquele tipo de troca de link. Ela sabia exatamente o que fazer. Ele voltou para as duas demandas que dependiam dele.

Quando me contou, disse que ficou alguns minutos olhando para o vazio, meio surpreso por ter conseguido não bancar o super-herói daquela vez. Fiquei feliz de verdade porque, mesmo parecendo pequena, aquela decisão mexia num comportamento difícil de largar: confundir ser prestativo com assumir tudo que chega. Foi por isso que puxei a imagem que tinha compartilhado com ele, a Matriz de Eisenhower. A decisão já estava tomada. A matriz só ajudava a explicar.

Quatro caminhos para o que chega

A matriz separa o trabalho por dois eixos, urgência e importância, e cruza os dois para chegar em quatro caminhos: fazer agora, agendar, delegar ou eliminar. O desenho é simples. A parte difícil é responder com honestidade em qual quadrante cada coisa entra.

Uma tarefa importante e urgente tem prazo curto e impacto real se atrasar. Produção caiu, um cliente está sendo impactado, uma entrega crítica da sprint está bloqueada ou outro time não consegue seguir sem uma resposta. Não tem muito o que inventar. É para fazer agora.

Já o importante que ainda não é urgente costuma perder a disputa para qualquer notificação barulhenta. É o refactor que evita um problema conhecido, o PDI que sempre perde espaço ou aquela documentação que ninguém protege tempo para escrever. Esse trabalho precisa entrar na agenda. Se ficar esperando sobrar tempo, uma parte dele volta depois como urgência.

O urgente que não precisa ser feito por você é onde a delegação aparece. A demanda precisa andar, mas outra pessoa consegue resolver com o contexto certo. Interromper quem está numa entrega mais importante não pode ser a única saída.

E tem aquilo que não é urgente nem importante. Reunião sem objetivo, melhoria cosmética sem impacto, investigação que não leva a decisão nenhuma, tarefa que continua aberta só porque ninguém teve coragem de fechá-la. Algumas coisas podem esperar e outras precisam morrer, porque manter tudo vivo também custa atenção.

O caso do link nem encaixava perfeitamente no quadrante clássico. Para quem recebeu, aquilo não era urgente nem importante. O pedido ainda precisava andar, só que havia outra pessoa muito mais perto da solução. A parte útil da matriz foi lembrar que ele não precisava assumir. Mesmo quando a classificação não fica perfeita, essa pausa já muda a decisão.

[!TIP] Quando algo novo chegar, pare antes de responder. Eu faço agora, agendo, delego ou elimino?

Urgência faz mais barulho

O problema é que urgente e importante não vêm etiquetados. Quase toda pessoa que chama acredita que o pedido dela é urgente, e talvez seja mesmo do ponto de vista dela. Mas isso não significa que virou a maior prioridade de quem recebeu a mensagem.

Eu tento começar pelo impacto. Quero saber quem fica bloqueado e qual consequência aparece se aquilo esperar. Produção parada e cliente perdendo dinheiro têm um peso bem diferente de alguém que só gostaria de receber a resposta hoje. A urgência começa a ficar mais clara quando a gente tira o tom da mensagem e olha para a consequência.

Importância também depende de contexto. Uma documentação pode parecer menos importante que um chamado, mas muda de peso quando só uma pessoa conhece uma operação crítica. Um teste automatizado pode esperar uma semana, até o dia em que o mesmo bug volta para produção. Priorizar exige olhar para o impacto de agora e para a conta que estamos deixando para depois.

[!IMPORTANT] A matriz não toma a decisão por você. Ela obriga você a dizer qual impacto está protegendo quando escolhe uma coisa e deixa outra para depois.

Tem mais uma armadilha aqui. Às vezes a pessoa sabe que uma tarefa poderia ser delegada, mas assume mesmo assim porque vai fazer mais rápido. E provavelmente vai. Só que, quando isso vira padrão, a pessoa mais experiente passa o dia resolvendo tudo que já sabe fazer e nunca protege tempo para o trabalho que realmente depende da experiência dela.

Quanto mais senioridade, mais o trabalho passa por escolher onde colocar atenção, dar contexto e ajudar outras pessoas a resolver. Já escrevi mais sobre isso em Nem só de código vive o dev. Código continua fazendo parte, claro, mas não sustenta a carreira inteira sozinho. Senioridade também aparece no trabalho que você ajuda os outros a assumir.

O contexto precisa ir junto

Delegar mal só muda o dono da confusão. Você encaminha uma mensagem solta, marca alguém e desaparece, deixando a outra pessoa descobrir sozinha por que aquilo existe e o que pode decidir. Uma delegação boa faz o oposto: dá contexto suficiente para começar, deixa claro o resultado e o prazo e combina quando o assunto volta para você. Nem toda tarefa precisa de uma especificação enorme. Às vezes duas mensagens resolvem.

Também não dá para usar a matriz como desculpa para empurrar trabalho chato. Delegar porque outra pessoa tem mais contexto ou porque a tarefa pode ajudá-la a crescer é diferente de repassar carga. Se só as tarefas ruins descem e todas as decisões interessantes ficam concentradas, isso não é desenvolvimento. É fila com hierarquia.

No caso do link, a delegação funcionou porque havia alguém que já conhecia a troca e conseguia resolver com menos esforço. O pedido não ficou abandonado, e quem delegou não sumiu. Cada pessoa cuidou da parte em que fazia mais diferença.

O que eu estou tentando praticar

Eu ainda erro essa classificação. Às vezes abro uma mensagem para responder rápido, entro num contexto que nem era meu e, quando percebo, quarenta minutos foram embora. Um assunto que parecia pequeno pode revelar um bloqueio sério, enquanto outro chega cheio de pressão e, depois de duas perguntas, pode tranquilamente esperar até amanhã.

A matriz ajuda porque cria uma pausa entre receber e assumir. Pode ficar numa imagem no celular ou num papel ao lado do monitor. O que eu estou tentando praticar é olhar antes de responder. E isso vale para o time inteiro, não só para quem virou gestor. No dia a dia de um desenvolvedor, muita gente chama, muito suporte atravessa a sprint e sempre existe mais trabalho do que capacidade. Tentar absorver tudo não aumenta a vazão. Só fragmenta o foco e esconde qual entrega ficou para trás.

[!TIP] Dizer “isso não entra agora” também é trabalho. A prioridade só fica clara quando alguma coisa pode esperar.

Aprender a delegar me ajudou a sair desse ciclo no passado. Agora, a matriz me dá uma forma concreta de trabalhar o mesmo ponto com o time.

Naquele dia, o desenvolvedor voltou para as duas tarefas que precisavam dele. O pedido seguiu com quem já conhecia a troca. E ninguém precisou virar super-herói.