- Em um ambiente com especialistas de várias áreas, o líder é responsável menos por dominar os detalhes técnicos e mais por conectar os problemas e definir a direção da solução
- Na liderança, mais do que conhecimento técnico puro, o que importa é a capacidade de tradução e as habilidades sociais, além de mediar conflitos e reforçar objetivos em comum
- O mais importante, acima da profundidade da especialidade de cada um, é deixar claro qual é o problema real e para onde vai a solução, garantindo que a discussão leve às necessidades do usuário e a resultados concretos
- Um líder eficaz não finge saber tudo; ele tem a coragem de dizer “não sei” e cria um ambiente em que os especialistas possam contribuir de forma autônoma
- O verdadeiro valor do líder está em traduzir perspectivas, oferecer contexto para o problema e criar espaço para colaboração, e isso é um fator central para alcançar os melhores resultados
Algo que percebi recentemente
- Estive em uma sala com desenvolvedores especialistas e o time de produto de áreas diferentes
- Eu não sou a pessoa com a maior especialização em uma tecnologia específica, mas estou no papel de desenvolvedor líder
- Entre especialistas, meu papel como líder não é saber todas as respostas, e sim encontrá-las e conectá-las
Technical Leadership
- O líder atua menos pela profundidade do conhecimento técnico e mais como um tradutor eficaz que viabiliza a comunicação entre equipes
- Seja ao explicar o cronograma do time de backend ou os requisitos do time de produto, ele interpreta cada perspectiva para conduzir a colaboração do time
Leading is a Social Skill
- Credibilidade técnica, sozinha, não basta; são as habilidades sociais que realmente geram produtividade
- É preciso saber ler as discussões entre desenvolvedores e entender quando mediar um debate ou fazer a conversa avançar
- Comunicação eficaz não acontece só em documentos, mas também por meio de conversas ativas
Leading is Remembering the Goal
- Quanto mais especialista alguém é, maior a tendência de mergulhar nos detalhes técnicos; o líder, porém, precisa manter o foco no objetivo geral
- Mais importante do que a discussão técnica é definir com clareza o problema essencial da experiência do usuário e o objetivo de negócio
- Se a essência do problema não for definida com clareza, os membros do time podem deixar passar a questão real por seguirem seus próprios modos de análise
- Cabe ao líder traduzir para que o time entenda corretamente o problema e enxergue o mesmo objetivo
Leading is Saying "I Don't Know"
- Em vez de fingir saber todas as respostas, a postura de dizer “não sei, vamos descobrir juntos” cria confiança e uma cultura aberta
- Essa atitude abre espaço para dúvidas e discussões entre os especialistas e dá a cada um a chance de mostrar sua capacidade
- O líder dá voz e poder de decisão aos especialistas de cada tema e aponta uma direção produtiva para a discussão
- Quando dois especialistas discordam sobre a forma de implementar algo, o papel do líder não é escolher a “resposta certa”, mas oferecer um enquadramento com base nos trade-offs e no impacto para o usuário
The Translation Challenge
- O líder precisa saber traduzir a linguagem de desenvolvedores, produto e executivos de acordo com o contexto
- Desenvolvedor: "Se o serviço de autenticação não tiver um circuit breaker adequado, pode haver uma falha em cascata sob carga"
- Time de produto: "Se houver problema no sistema de login, o app inteiro pode ser afetado; por isso precisamos de uma proteção extra, e o cronograma aumenta em uma semana"
- Executivos: "Neste sprint, vamos priorizar a estabilidade do sistema para reduzir o risco para o negócio"
- Não é necessário que os especialistas aprendam também a linguagem de outros departamentos; o líder deve cumprir o papel de ponte para fechar essa lacuna
Beyond "Because, that's why!"
- Tomar decisões no estilo “faz assim porque eu sou o líder” prejudica a confiança, a cultura de colaboração e a produtividade do time
- É importante tratar o time como adultos e explicar com clareza os motivos e o contexto das decisões
- "Escolhemos uma abordagem mais conservadora porque o custo de errar aqui é alto, e depois podemos melhorar de forma iterativa"
- "Pode parecer trabalho extra, mas isso está alinhado com os objetivos de arquitetura e vai ajudar no desenvolvimento das próximas funcionalidades"
- "Essa não é a solução mais elegante, mas é a que podemos colocar em produção com confiança dentro do prazo"
- Quanto mais se abandona a necessidade de parecer o mais especialista da sala, mais se torna possível exercer a verdadeira liderança
O valor que um líder deve entregar ao time
- Definição clara do problema
- Explicação suficiente do contexto das decisões
- Tradução das diferenças de perspectiva entre os times
- Proteção contra complexidade desnecessária
- Criação de um ambiente voltado para o melhor resultado possível
Conclusão
- A liderança técnica em organizações cheias de especialistas vai além de comando e controle; ela se concentra em conexão e fornecimento de contexto
- O líder não é o músico que toca diretamente o instrumento, mas sim o maestro que ajuda a orquestra a completar uma obra
- Esse é um desafio muito mais interessante do que simplesmente ser a pessoa mais inteligente da sala
4 comentários
Pensando pelo lado oposto, acho que em um ambiente sem especialistas, não há outra opção a não ser você mesmo se tornar o especialista.
Claro, às vezes também penso em exercer outros tipos de liderança além da liderança técnica, mas na prática, quando você encontra membros da equipe que não compartilham bem as informações, até isso fica difícil, então acho que varia conforme a situação.
Que perspectiva excelente.
É assim que devo trabalhar
Comentários do Hacker News
Como líder da equipe, procuro evitar ao máximo decisões do tipo “eu sou o líder, e foi isso que decidi”, mas ressalto que, quando necessário, é preciso usar essa autoridade sem hesitar. Costumo dedicar tempo para ouvir a opinião de todos e decidir com cuidado, mas percebi que, quando a equipe cai em discussões intermináveis sobre detalhes não essenciais, cabe ao líder restabelecer a ordem. Fico pensando naquela frase atribuída a Steve Jobs: “se você quer agradar todo mundo, não seja líder, vá vender sorvete”. Depois que uma situação dessas passa, é fundamental reconstruir a confiança e explicar à equipe por que não havia outro caminho além de agir daquela forma
Eu também aprendi essa lição da pior maneira. Quando virei gerente pela primeira vez, ingenuamente achava que sempre conseguiria construir consenso e que a equipe naturalmente se alinharia. Funcionou no começo, em equipes excelentes, mas depois passei a trabalhar com engenheiros que insistiam apenas em práticas de 25 anos atrás de outras equipes, e acabei desperdiçando tempo demais esperando por consenso. No fim, percebi que, depois de todos terem exposto bem suas posições, chega um momento em que o líder precisa definir a direção e decidir
Pela minha experiência, vivi situação parecida durante alguns anos trabalhando numa F50. Num domínio com 3 pessoas-chave, só nós sabíamos que a opção A parecia boa na superfície, mas na prática tinha muitos problemas. Mesmo explicando, não conseguimos convencer a equipe, então acabamos ignorando a votação e falando com o chefe para tomar a decisão correta. Nesse processo, percebi profundamente que, se você segue a opinião da maioria (opção A) em vez da direção desejada por quem realmente vai lidar com o resultado diretamente (opção C), o projeto continua sofrendo com problemas e atrasos. O ponto importante é que quem assume diretamente a responsabilidade e as consequências precisa ter “poder de veto”, e não depender de voto popular, para que o projeto tenha tração. Em projetos grandes, vários líderes devem tomar decisões em seus respectivos domínios, e só em caso de impasse o superior deve decidir de forma clara. Quando o líder evita tomar a decisão, todo mundo só fica reclamando, e isso derruba seriamente o moral da equipe — foi uma experiência extremamente frustrante
Também me lembrei da história de Steve Jobs trancando a equipe numa sala e fazendo todos discutirem até encontrarem uma visão em comum. É difícil alinhar todo mundo na mesma direção, mas, se isso falha, a capacidade de execução cai muito. Ao mesmo tempo, se você ignora a opinião da equipe, as pessoas se sentem ignoradas, então, por mais que o resultado importe, isso não é sustentável no longo prazo
Achei marcante a diferença entre “ouvir a voz de todos” e “dar poder de veto a todos”. Como líder, acho essencial ter a função de romper impasses. Claro, se o líder precisa decidir tudo em todas as questões, isso também é sinal de problema de gestão, motivação, ou de que a equipe não está entendendo a estratégia
A forma que eu prefiro é dizer: “se você fosse o responsável direto, me diga qual seria a decisão”. A missão do líder não é necessariamente tomar todas as decisões pessoalmente, e sim garantir que uma decisão seja tomada
Acho que tenho alguma experiência nesse assunto. Fui nomeado líder de um projeto que já tinha fracassado três vezes antes, trabalhando com 6 dos melhores engenheiros de cada equipe. Todos tinham opiniões fortes e boas razões para elas, mas tentei adotar uma postura parecida com “não atrapalhe um inimigo quando ele estiver cometendo um erro”, só que no sentido de “não atrapalhe um amigo quando ele estiver fazendo algo excelente”. A atitude era: “se não é a sua parte, então vá construir outra coisa em que você seja bom”. Fomos distribuindo papéis naturalmente, influenciando uns aos outros de forma leve, aceitando que partes menos importantes não precisavam ser perfeitas, e mantendo flexibilidade. No fim, deu certo, e tenho muito orgulho de termos criado uma estrutura em que várias pessoas talentosas puderam aprender umas com as outras e focar apenas nos pontos que realmente exigiam debate
Acho que a sua experiência se parece com o que chamam de Servant Leadership(link da wiki relacionado). Também é um estilo de liderança de que eu gosto
Acho que, para dar espaço a engenheiros excelentes liderarem e desenvolverem suas próprias ideias sem interferência excessiva, o líder precisa de confiança genuína, autocontrole e segurança em si mesmo
Sempre que o time de produto pede uma funcionalidade “simples”, a primeira coisa que me vem à cabeça é que provavelmente serão necessárias pelo menos 3 equipes, e cada uma vai ter de atualizar seus respectivos microsserviços. Nessas horas, às vezes eu realmente odeio os sistemas web modernos
Acho que o problema aqui não é tanto a web moderna em si, e sim uma arquitetura em que uma funcionalidade “simples” depende de 3 microsserviços diferentes, com dependências espalhadas. No fim, a causa maior é uma falha de design do sistema
Então fico curioso: qual seria a alternativa?
Pela minha experiência, é melhor evitar dizer “eu sou o líder”, porque isso pode soar como falta de confiança. O ideal é coletar todas as informações, tomar a decisão e então conseguir dizer com firmeza algo como “certo, agora vamos fazer assim” ou “gostaria que fizéssemos desta forma”
O cerne do problema não é mal-entendido, e sim falta de confiança entre as pessoas. Se uma equipe diz que algo leva 2 semanas, outra equipe pode achar que aquilo daria para fazer em 1 dia e simplesmente não acreditar. Se houvesse confiança suficiente, seria possível aceitar que a outra equipe talvez tenha mais especialização naquele assunto, mas, na prática, muita gente suspeita que estimativas não refletem o trabalho real, e sim uma tentativa de criar folga no cronograma. Nesses casos, compartilhar explicações e fundamentos ajuda a aumentar a confiança
Faz cerca de um ano que fui promovido a desenvolvedor líder. Eu estava confuso sobre qual era exatamente o meu papel e minhas responsabilidades, mas fiquei aliviado ao perceber que venho trabalhando com ideias parecidas com as do texto original. Há alguns dias li um texto sobre “como ler tutoriais do ponto de vista de quem não é desenvolvedor” e me identifiquei bastante, então sinto que talvez eu esteja indo na direção certa
Também já vivi 3 casos em equipes de desenvolvimento de produtos próximos de software em que o líder conduziu tudo de forma autoritária, e o resultado sempre foi ruim. Depois de liderar equipes algumas vezes, percebi que meu papel não deve ser o de “comandante”, mas sim de “hub e mediador”. Quando há conflito entre membros da equipe, eu ajudo a resolver; quando surgem dúvidas, tento reduzir a ansiedade; quando aparece uma ideia, avalio viabilidade e valor; e, se faltam recursos, ajudo a encontrar quem possa providenciá-los. Se surge um problema, assumo a responsabilidade e incentivo a equipe a resolvê-lo. Levei mais de 10 anos para aprender tudo isso. Não sou o melhor, e meu nome provavelmente não é conhecido pela maioria das pessoas, mas, quando trabalho como parte da equipe, os resultados melhoram e a evasão de talentos diminui. E, como líder, acho muito importante poder dizer “eu também não sei muito bem, mas vamos encontrar a resposta juntos”. Isso permite que especialistas admitam incerteza, evita que entrem na defensiva e ainda faz com que não se sintam sozinhos. Para quem já se sentiu excluído ou tratado como peça substituível por líderes antigos, espero que encontre algum conforto nisso; e, se um líder quer conduzir bem sua equipe por muito tempo, precisa parar de pensar nas pessoas como máquinas e realmente cuidar delas
Fiquei impressionado ao saber que o autor gravou pessoalmente o áudio do texto
A pessoa diz gostar da expressão “It's because that's why” e comenta que, para quem se interessa por esse campo, os livros de Vanessa Van Edwards ajudaram bastante a aprender como transmitir os sinais certos de calor humano e competência dependendo da situação. É difícil que uma única pessoa tenha todas as respostas, mas ela teve várias experiências positivas com isso
Sobre tomar decisões, sinto que há algo além — e também nada além — de “garantir que uma decisão seja tomada”. Primeiro, eu recomendaria, sempre que possível, fazer com que outra pessoa tome a decisão diretamente. Na época da Apple, Jean-Louis Gassee costumava dar a gerentes que levavam disputas até ele uma decisão que desagradasse aos dois; então eles voltavam e encontravam por conta própria uma alternativa em que conseguissem concordar. Segundo, é preciso fazer com que todos os envolvidos realmente comprem a decisão, e o próprio líder deve começar por isso. Isso é muito difícil para gestores que vivem mudando de posição conforme o vento. Faço uma analogia com estudantes de direito, que sempre pensam com cautela e analisam tudo, enquanto advogados precisam defender uma posição com firmeza e adotar uma postura capaz de convencer os outros. Como nem sempre se chega a um consenso ideal, também vale definir um ponto concreto — como o cliente ou o objetivo de resultado — para impulsionar a decisão e sua execução