Uma das coisas mais difíceis quando começamos a liderar um time técnico é aprender a não resolver tudo sozinhos. No começo parece simples. Você percebe que está centralizando decisões, começa a falar sobre autonomia e decide delegar mais. Só que aí aparece um problema: delegar o quê, para quem e quanto?
Porque nem toda decisão deveria ser tomada pelo time. Da mesma forma, nem toda decisão precisa passar pelo Tech Lead.
Uma decisão relacionada a uma mudança crítica de arquitetura pode exigir uma participação muito maior da liderança. A escolha de uma biblioteca pode ser discutida com o time. Uma decisão pequena sobre a implementação de um componente talvez nem precise chegar até você. Então, quando falamos que um Tech Lead precisa delegar, a pergunta mais interessante não é “o que eu posso tirar da minha mesa?”. É: “Qual é o nível de autonomia adequado para essa decisão?”
É justamente aí que entra o Delegation Poker, uma prática apresentada pelo Management 3.0 que trabalha com sete níveis diferentes de autoridade e responsabilidade. A ideia é simples, mas tem bastante coisa por trás dela: delegação não é uma chave que você liga ou desliga. Existe uma escala.
1. Dizer
No primeiro nível, a liderança toma a decisão e comunica ao time o que precisa ser feito. É o nível com menor autonomia.
Imagine que existe uma vulnerabilidade crítica em produção e você já sabe que determinada ação precisa ser tomada imediatamente. Talvez não exista tempo para uma discussão extensa. Você toma a decisão e orienta o time. “Vamos fazer dessa forma.”
Esse nível pode ser perfeitamente adequado em algumas situações. O problema aparece quando ele vira o padrão para praticamente tudo.
Se o Tech Lead define qual biblioteca será usada, qual arquitetura será adotada, como cada problema deve ser implementado e até como as tarefas devem ser executadas, o time pode até entregar bem, mas dificilmente vai desenvolver autonomia.
Dizer não é necessariamente microgerenciamento. Usar Dizer para todas as decisões é que pode se tornar um problema.
2. Vender
Aqui a liderança continua tomando a decisão, mas existe uma diferença importante: ela explica o motivo e procura convencer o time daquela escolha. Não é simplesmente: “Vamos usar essa solução.”
É: “Vamos usar essa solução porque temos esse requisito, essas restrições e esses riscos. Avaliei as alternativas e acredito que esse caminho faz mais sentido.”
Pode parecer uma mudança pequena, mas compartilhar o raciocínio ajuda o time a entender como aquela decisão foi construída. E isso importa porque uma das coisas que um Tech Lead precisa fazer é justamente distribuir contexto.
O time não precisa apenas saber o que foi decidido. Quanto mais possível, precisa entender por que aquilo foi decidido.
3. Consultar
Agora a liderança ainda toma a decisão, mas antes procura ouvir o time. Esse é um nível interessante porque começa a introduzir uma mudança importante na dinâmica.
Imagine que você precisa escolher entre duas alternativas arquiteturais. Em vez de simplesmente analisar sozinho e comunicar a decisão, você apresenta o problema para o time, coleta opiniões, discute os impactos e depois toma a decisão. A responsabilidade final continua sendo sua. Mas você ganhou algo importante no processo: informação que provavelmente não teria se tomasse a decisão sozinho.
Consultar também ajuda a criar participação. As pessoas percebem que suas opiniões são consideradas, mesmo quando a decisão final não é exatamente aquilo que sugeriram. E aqui existe uma distinção importante: consultar não significa prometer que a opinião recebida será seguida.
Se você pergunta ao time e depois precisa tomar uma decisão diferente, faz parte. O importante é deixar claro qual é o nível de autoridade envolvido.
4. Concordar
Aqui a dinâmica muda mais significativamente. A liderança e o time discutem a decisão juntos e chegam a um consenso. A responsabilidade pela decisão passa a ser compartilhada. Esse nível pode fazer bastante sentido em decisões que afetam diretamente o funcionamento da equipe.
Por exemplo, imagine que o time está enfrentando problemas recorrentes no processo de desenvolvimento. Em vez de simplesmente definir uma nova regra, você pode colocar o problema na mesa, discutir as alternativas e construir com o grupo uma forma diferente de trabalhar.
O resultado tende a ser mais sustentável porque as pessoas participaram da construção da decisão. Mas existe um cuidado: consenso também custa tempo. Nem toda decisão precisa envolver todo mundo. Se tentarmos transformar qualquer escolha pequena em uma decisão coletiva, podemos criar um processo pesado e lento. Parte da maturidade da liderança está justamente em saber quando vale a pena envolver o grupo.
5. Aconselhar
Aqui acontece uma inversão importante. A equipe toma a decisão, mas pode procurar a liderança para receber orientação antes de finalizá-la. Você deixa de ser a pessoa que precisa aprovar a decisão e passa a ser uma fonte de conhecimento para quem está decidindo.
Imagine que um desenvolvedor esteja avaliando duas alternativas para resolver um problema de performance. Ele pode fazer a análise, levantar os impactos e escolher um caminho, mas antes conversa com você para ouvir sua experiência.
Você apresenta sua visão, aponta riscos e compartilha o que sabe. Mas a decisão continua sendo da pessoa ou do time. Esse é um passo importante na construção de autonomia porque o conhecimento do Tech Lead continua disponível sem transformar o líder no responsável por todas as escolhas.
6. Indagar
Aqui a autonomia aumenta ainda mais. A equipe tem autoridade para tomar a decisão e implementar a solução. A liderança não precisa aprovar previamente, mas pode fazer perguntas para entender o processo e os resultados. Essa diferença é bastante interessante.
Imagine que o time decidiu adotar uma determinada abordagem técnica. Você não precisou aprovar a decisão antes da implementação. Depois, porém, pode perguntar:
- “Como vocês chegaram nessa conclusão?”
- “Quais alternativas foram consideradas?”
- “Qual risco vocês identificaram?”
- “Como vamos saber se essa decisão funcionou?”
Perceba que as perguntas não existem necessariamente para recuperar o controle da decisão. Elas podem existir para aumentar a qualidade das decisões futuras. É uma mudança importante para quem está acostumado a ser a autoridade técnica da equipe. Você deixa de avaliar apenas se a resposta está certa e começa a se interessar também pelo processo que levou à resposta.
7. Delegar
No último nível, a equipe possui autonomia para tomar a decisão e implementar a solução sem precisar de aprovação ou aconselhamento contínuo da liderança. O Tech Lead continua disponível, mas a iniciativa parte do time. Esse talvez seja o nível mais associado à ideia de autonomia, mas existe um detalhe importante: Delegar não significa abandonar.
Você ainda acompanha os resultados, entende o que está acontecendo e permanece disponível quando necessário. A diferença é que a responsabilidade pela decisão está claramente com a equipe. E chegar nesse nível deveria ser consequência de contexto, competência e confiança, não simplesmente de uma vontade de “não centralizar”.
Então qual dos sete níveis eu devo usar?
Essa é justamente a parte mais interessante do Delegation Poker. Não existe um nível certo para todas as situações. Os sete níveis existem porque decisões diferentes exigem níveis diferentes de autoridade e envolvimento.
Uma decisão crítica de segurança pode exigir uma abordagem muito mais próxima da liderança. Uma escolha de ferramenta pode ser consultada. Uma decisão sobre implementação pode ser completamente delegada. E também existe outro fator: a maturidade da equipe.
Talvez uma pessoa recém-chegada ao time precise de mais orientação em determinada atividade. Depois de alguns meses, com mais contexto e experiência, a mesma decisão pode passar para outro nível de autonomia. Isso significa que delegação não deveria ser pensada apenas como uma propriedade da tarefa.
Ela também depende de quem está tomando a decisão, qual contexto essa pessoa possui e quais consequências aquela decisão pode gerar.
Delegar não é perder controle
Existe uma crença comum de que líderes centralizadores controlam tudo e líderes maduros simplesmente deixam o time decidir. Na prática, a situação é bem mais interessante.
Uma boa liderança precisa saber onde o controle é necessário e onde ele está apenas criando dependência. Se você precisa aprovar todos os PRs, todas as decisões arquiteturais, todas as escolhas técnicas e todas as mudanças no processo, talvez o problema não seja que seu time precisa de mais supervisão. Talvez o problema seja que você ainda não criou mecanismos para distribuir conhecimento, contexto e responsabilidade.
Por outro lado, simplesmente entregar uma decisão para alguém sem explicar objetivos, restrições ou riscos também não é liderança. Delegar responsabilidade sem contexto é apenas transferir um problema. Por isso, gosto da ideia de pensar nos sete níveis como uma espécie de mapa de autonomia. Antes de decidir, pergunte:
- Quem deveria tomar essa decisão?
- Quanto contexto essa pessoa possui?
- Qual é o risco de uma decisão ruim?
- Quanto preciso estar envolvido?
- Esse nível de autonomia faz sentido para este momento?
Essas perguntas são muito mais importantes do que simplesmente tentar chegar ao nível 7 em todas as situações.
O objetivo não é chegar ao “Delegar”
Talvez essa seja a principal conclusão que eu tiraria do framework. O objetivo de um Tech Lead não deveria ser colocar todas as decisões no nível Delegar para poder dizer que construiu um time autônomo. O objetivo é criar um ambiente em que cada decisão esteja no nível de autonomia adequado.
Às vezes você vai precisar dizer. Às vezes vai vender uma ideia. Em outras situações vai consultar, construir uma decisão junto com o time ou simplesmente aconselhar. E haverá momentos em que a melhor coisa que você pode fazer é sair do caminho e deixar a equipe decidir. A maturidade da liderança não está em controlar menos.
Está em saber exatamente quando controlar, quando participar e quando deixar o controle com outras pessoas.
No fim, delegação não é sobre tirar trabalho da sua mesa. É sobre aumentar a capacidade do time de tomar decisões sem precisar que você esteja no centro de todas elas. E talvez seja justamente aí que a liderança técnica comece a deixar de ser sobre você. E passe a ser sobre o time.
