Introdução
Em mais de uma situação, a pessoa que se tornou formalmente a líder técnica do time não é a que tinha mais tempo de casa ou a mais experiente tecnicamente: era a que mais sabia se comunicar com pessoas do time e fora dele. Mas esse é um tema bastante abrangente. Por isso, nesta segunda parte deste manual, vamos listar algumas práticas mais concretas que devem ser levadas em consideração. Mas todas são baseadas muito mais nas suas habilidades pessoais do que técnicas.

1. Fale no Idioma do Negócio

Uma das principais expectativas de qualquer liderança técnica ou pessoa com mais experiência é que elas consigam explicar qualquer coisa, por mais baixo nível que seja, de forma idiomática. É preciso utilizar termos que todos consigam entender, principalmente as pessoas menos técnicas e mais voltadas para a área de negócio.

Isso se torna ainda mais importante quando você precisa argumentar ou convencer pessoas que não são da área de desenvolvimento a aplicar alguma boa prática de código ou arquitetura que, quando explicadas de forma superficial, parecem não agregar tanto valor ao seu produto quanto uma nova funcionalidade agregaria.

Um bom e comum exemplo é quando queremos quebrar um monolito numa arquitetura de microsserviços. Se você precisa apresentar este grande e trabalhoso processo para um grupo, ou convencê-los de que isso precisa ser feito, não seja tão literal. Quanto mais poder de decisão uma pessoa tem, menos ela vai entender profundamente o que significam esses termos. E será ainda mais difícil fazer elas compreenderem ou serem convencidas, principalmente quando acompanhados de argumentos rasos como dizer que isso deve ser feito simplesmente porque todos estão fazendo, por ser uma boa prática ou porque foi publicado em algum artigo.

É preciso falar o idioma profissional deles que, com certeza, não envolvem as palavras monolito, arquitetura ou microsserviços. Por exemplo: "Hoje, todo nosso sistema está concentrado em um único lugar, isso dificulta a criação e o experimento de novas ideias, além de demorar bem mais que nossos competidores para entregar novas funcionalidades (traga dados contextuais e experiências suas aqui). Para resolver isso, existe uma boa prática chamada arquitetura de microsserviços, onde de forma gradual e estruturada, conseguimos dividir este grande sistema em sistemas menores. Assim temos mais liberdade e podemos escolher tecnologias mais apropriadas para uma dada necessidade de negócio. Além disso, ter sistemas desacoplados e bem definidos também ajuda na performance e diminui o custo de manutenção do nosso produto pois podemos prover mais recursos físicos somente para um serviço, e não para toda a aplicação que é o que temos que fazer hoje".

Sempre tente trazer termos mais próximos de um idioma comum ou explicar sucintamente (cuidado com a prolixidade) algo técnico que tenha surgido no seu discurso. Foque no que realmente importa: o valor que aquela alteração vai agregar ao negócio do seu produto. Inclusive, para qualquer decisão técnica que for tomada, questione sempre sua prioridade e se ela realmente agregará, mesmo que indiretamente, melhorias para seus clientes. É muito comum cair na armadilha de tomar uma decisão por puro preciosismo profissional ou pela imensa vontade de usar uma tecnologia mais moderna, por isso, tenha bastante cuidado.

2. Dê Feedbacks Positivos e Construtivos de Forma Estruturada

Não existe agilidade sem feedback. E isso não serve só para os feedbacks das pessoas que utilizam seu produto. Serve também para nós, pessoas do time e da organização, que queremos evoluir pessoalmente e profissionalmente. Quando melhoramos nossas habilidades, sejam elas comportamentais ou técnicas, o time trabalha com menos atrito, de forma mais fluida e ainda constrói um software melhor pois ele nada mais é do que um reflexo de seus responsáveis. Se nós melhorarmos, ele também vai melhorar.

Infelizmente, nem toda organização fomenta uma cultura de feedback e essa responsabilidade acaba sendo atribuída para um gestor. Na minha opinião, essa abordagem acaba sendo cômoda, mas impede uma evolução orgânica e inclusiva da própria organização. Além disso, é uma ferramenta muito poderosa para a vida pessoal de cada um pois fortalece, através de uma comunicação não violenta e genuína, nossos relacionamentos.

Outro ponto é que, geralmente, gestores não são técnicos ou estão há muito tempo afastados dos ofícios de desenvolvimento. Além disso, um gestor não está no dia a dia das pessoas técnicas do time: não fazem revisões de código, não pareiam, não estão presentes quando decisões técnicas são tomadas, etc. São só através dessas práticas que é possível entender o momento técnico de cada um e, assim, direcionar determinada pessoa para um caminho técnico que você julga importante dada sua experiência na área.

A forma de dar e receber feedbacks que mais funcionaram em todos os projetos que participei foram cara a cara, nas reuniões chamadas de 1:1. Elas aconteciam com determinada frequência dependendo do contexto (a cada uma ou duas semanas). Mas, para que isso seja possível, é necessário saber aplicar o ferramental de feedback. Caso contrário, podem ser gerados atritos entre as pessoas do time que vão resultar no oposto do nosso objetivo. Um bom livro sobre este tema é o "Comunicação Não-Violenta", de Marshall Bertram Rosenberg. Se precisar de algo mais rápido, existe este artigo que ensina o básico que deve ser seguido para realizar esses tipos de conversas.

Lembre-se que receber feedbacks também requer conhecimento. Por isso, certifique-se de que esse estudo esteja disseminado no seu time de alguma forma: dê uma apresentação com o que você aprendeu, assegure-se de que todas as pessoas leram sobre feedback ou pergunte se já adquiriram esse conhecimento em algum lugar.

Dito tudo isso, agora é a sua vez de atuar. Com sua experiência na área de desenvolvimento, comece a observar códigos e argumentos técnicos com a vontade genuína de não só destacar pontos positivos, mas também pontos de melhoria baseados em seus conhecimentos teóricos. Tome nota de todos eles, priorize os mais críticos caso tenha encontrado muitos e os organize de forma que se torne fácil entender o conhecimento que falta por trás dos pontos que você encontrou. Exemplo: Se, constantemente, uma pessoa desenvolvedora tem o costume de criar variáveis com nomes "a", "b" e "c", talvez seria uma boa ela entender mais sobre código limpo e suas vantagens.

E para fechar esta prática com chave de ouro, não esqueça de acompanhar a evolução das pessoas que receberam seu feedback e não hesite em trazer isso para elas, até mesmo de maneira informal. Por outro lado, lembre-se que feedbacks são presentes e que as pessoas podem fazer o que bem entenderem com eles: muitas vezes, por uma questão de contexto ou de prioridade, os pontos de melhoria que você trouxe podem ter sido deixados para um outro momento. E está tudo bem!

3. Compartilhe Conhecimento através de Mentorias ou Apresentações

Conhecimento bom é conhecimento compartilhado, principalmente nos times de desenvolvimento ágil. Deixar que se formem "silos" de determinados assuntos dentro do time é extremamente prejudicial: E se aquela pessoa faltar ou tirar férias? E se ela sair da empresa? E se isso tudo acontecer em meio a um bug crítico relacionado àquele assunto?

Mas além de evitar esses problemas, conhecimento compartilhado também gera aprendizado para todas as pessoas e ajuda a alcançar um dos principais objetivos de uma liderança: o alinhamento técnico para que o time tenha mais autonomia para não só proporcionar segurança para a tomada de decisão, mas também essa decisão ser baseada em padrões de código e arquitetura definidos pelo time.

Existem muitas formas de se compartilhar conhecimento. Escolha ou adapte uma delas de acordo com seu perfil e o contexto do seu time naquele momento. Se você se considera uma pessoa mais extrovertida e comunicativa, ou quer melhorar sua habilidade de falar em público, prepare apresentações mesmo pequenas e sem layout profissional. Nelas, fale sobre conhecimentos que você já estudou ou até mesmo alguma prática ou padrão que utilizou para resolver alguma tarefa do backlog. Outra ideia que já funcionou bem em uma equipe que fiz parte foi organizar coding dojos para refatorar trechos do código ou aprender alguma nova linguagem. Nesse tópico, você pode usar sua criatividade, o que importa é o conhecimento chegar da melhor forma para a maior parte de pessoas do seu time.

Em casos de pessoas que preferem não falar em público, existem práticas extremamente eficientes como a mentoria e o pareamento. A primeira trata-se de, através de reuniões frequentes, ensinar de forma teórica e prática um determinado tema para uma pessoa que busca aquele conhecimento. A segunda, o pareamento, é uma prática famosa no desenvolvimento ágil que, além de melhorar a qualidade da sua aplicação, permite que duas pessoas tenham mais domínio sobre o código e sobre o conhecimento de negócio relacionado à tarefa que está sendo feita.

A ideia neste tópico não é centralizar e se sobrecarregar com essa responsabilidade. Tome a iniciativa e, liderando pelo exemplo, certifique-se de que compartilhar conhecimento tornou-se algo cultural e orgânico no seu time. Encoraje, usando até mesmo feedbacks, todas as pessoas da equipe a realizarem estas práticas. Perceba quem na sua equipe tem bastante conhecimento em algum assunto, seja ele geral ou relacionado ao código ou produto, e incentive essa pessoa a compartilhar esses conhecimentos de alguma forma. Pelas minhas experiências, um time que compartilha conhecimento de forma natural tende a resolver problemas mais assertivamente e desenvolver tarefas com mais velocidade porque mais pessoas vão ter a capacidade de navegar sobre diversos contextos de negócio da aplicação.

4. Gerencie seu Tempo e Delegue Responsabilidades

Um dia eu ouvi uma frase que fez muito sentido: a função da liderança técnica é fazer com que o time não precise de uma liderança técnica. E, para isso, é necessário que você tenha uma boa gestão de tempo e saiba delegar as atribuições que lhe foram dadas para as pessoas à medida que elas evoluem tecnicamente.

Quando você é uma liderança técnica, mesmo sem esse rótulo formal, todas as pessoas de toda a organização buscam a você para resolver problemas ou discutir assuntos de maior calibre. E é natural, principalmente para quem está começando, a aceitar todos esses convites e se perder em um mar de reuniões.

Para resolver este problema e tornar a vida mais fácil, é necessário saber quando dizer não. Pergunte sobre o teor daquela reunião, avalie o contexto atual do seu time e o quanto ele precisa de você naquele momento, priorize esse encontro entre seus afazeres naquele dia. Feito essa análise, existem três opções: delegar aquela reunião para alguém do seu time que tenha contexto sobre aquele assunto, adiar esse encontro para um outro dia ou simplesmente aceitá-lo.

Para delegar uma atribuição é essencial que se pratique os tópicos anteriores: feedback e conhecimento compartilhado. Só assim você vai conhecer as forças e fraquezas das outras pessoas e ter segurança para convidá-los a resolver novos problemas. Isso também contribui muito para a evolução profissional daquela pessoa, tanto dentro quanto fora da organização, além de liberar mais espaço na sua agenda para você fazer tarefas mais prioritárias e urgentes (ou quem sabe codar?).

5. Resolução de Conflitos e Facilitação

Por mais alinhado tecnicamente que seja um time, sempre existirão divergências na hora de tomar decisões de forma colaborativa. A saída fácil e cômoda para esse problema é centralizar esse tipo de decisão nas pessoas mais experientes do time mas, por diversas razões, esse é um caminho a ser escolhido somente em cenários extremos.

Dois fatores são essenciais para nossa motivação profissional: sentir-nos co-autores do que estamos fazendo e quando alcançamos um propósito maior do que simplesmente desenvolver tarefas totalmente pré-definidas por alguém. E esses dois fatores são alcançados quando tomamos decisões de forma colaborativa, sejam elas técnicas, de negócio, ou relacionadas aos processos do time.

É claro que, dependendo da demanda do seu projeto, isso significaria encher o seu time de reuniões. Se for esse o caso, priorize as de maior impacto e aquelas onde o time tem mais contexto para argumentar e agregar à decisão final. Veja quais dessas reuniões de tomada de decisão podem ser opcionais ou, para alguns casos, chame somente as pessoas que tem conhecimento sobre o assunto relacionado à decisão.

Com o time reunido, seja a pessoa facilitadora daquela reunião. Introduza o assunto com a ajuda de desenhos e diagramas, lembrando sempre de mostrar o valor de negócio envolvido, e certifique-se que todos entenderam. Se já tiver pensado em caminhos a seguir, fica a seu critério apresentá-los ou não, pois se assim o fizer pode enviesar a decisão das pessoas do time e acabar perdendo ideias que poderiam ser mais interessantes que as suas.

Deixe a discussão rolar e vá anotando de uma forma que todos consigam ver os possíveis que estão aparecendo. Tome nota de seus pontos positivos, negativos e tente medir suas complexidades. Interfira na discussão sempre que necessário, como nos casos de alguém começar uma conversa baseada em uma premissa falsa ou perceber que se está perdendo muito tempo em um certo ponto que não está convergindo para lugar nenhum. Embora o ideal seja o consenso, tem horas que ele pode demorar muito e é preciso seguir em frente. Nesses casos, que devem ser exceções, pode-se abrir uma votação desde que o time entenda que a decisão tomada será de todo mundo, independente do seu voto. Seja sempre fiel ao tempo estipulado para aquela discussão.

Caso seu time esteja com bastante dificuldade em chegar a consensos, faça uma análise mais profunda de outros aspectos pois é um forte indicativo de um alinhamento técnico fraco. Será que precisamos compartilhar mais o que estamos fazendo no dia a dia? Será que precisamos parear mais? Será que existe algum conceito ou prática de mercado que nosso time precisa se aprofundar?

E é papel da pessoa facilitadora ajudar o time a chegar a um consenso. Quando existe um conflito, tente analisar as reais motivações por trás das opiniões contrárias. Faça perguntas para as pessoas envolvidas até chegar no real objetivo ou motivação de aquela pessoa preferir fazer daquele jeito. Essa tática é quase infalível para escolher um dos caminhos ou até mesmo construir um novo que contemple ambos. Além disso, muitas das vezes, percebe-se que as pessoas estão falando a mesma coisa mas de formas diferentes, o que causaria uma discussão longa e desnecessária que foi evitada pela sua habilidade de facilitação e resolução de conflitos.

Ao chegar perto do final, separe um tempo para sumarizar as decisões que foram tomadas e ter certeza que todo o time está alinhado. Também é aconselhável documentar essas decisões e a motivação delas (lembra do ADR?)

Encerramento

Não existe nada escrito em pedra ou balas de prata para problemas complexos. Não chegue amanhã no seu trabalho e simplesmente tente transportar tudo que foi exposto aqui achando que em pouco tempo será reconhecido como uma liderança técnica. A chave para esse processo está em entender a motivação e a essência por trás de cada um destes tópicos e, como toda boa pessoa agilista, adaptá-los para o contexto da sua organização, produto e equipe. Às vezes algumas práticas já estão sendo feitas de forma satisfatória ou sequer fazem sentido para seu contexto. Lembre-se que o objetivo nunca deve ser fazer as coisas para se tornar liderança e sim agregar valor de negócio ao seu produto, de forma direta ou indireta. Tudo que acontecer depois disso é consequência.

A verdadeira lição desse artigo não são os tópicos em si mas sim mostrar que uma das formas de evoluir tecnicamente é pensar fora da caixa e atuar em frentes que vão além das tarefas do seu backlog. Existe um universo de práticas possíveis que podem ser idealizadas e aplicadas quando você une sua criatividade e sua experiência. Não tenha medo de errar. Assim como no desenvolvimento ágil é comum testarmos hipóteses e falharmos o quanto antes, o mesmo serve experimentar ideias dentro do seu próprio time e de seus processos.

Espero ter contribuído de alguma forma para o seu momento de carreira ao compartilhar essas experiências e, por fim, te encorajo a compartilhar comentários, feedbacks, sugestões e experiências sobre os diversos temas que discutimos. Obrigado e até a próxima!

Confira a parte 1 do artigo aqui.

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp.

Por: Luiz Dias, Backend Software Engineer