Neste publish, quero compartilhar um pouco da minha trajetória e alguns valores sobre trabalho em equipe e liderança que costumo aplicar no meu dia-dia.
Há diversos estudos, livros e práticas catalogadas sobre o assunto, mas eu prefiro me apoiar em valores vindo de pessoas com as quais trabalhei e sempre admirei, sendo ótimos líderes que trabalham para que a equipe se sinta confortável e produtiva no desempenhar das funções.
Não espere um artigo científico cheio de referências, mas sim um compilado empírico baseado tão somente na minha visão de mundo e trajetória.
Mas não posso deixar de destacar que o melhor livro que li sobre o assunto, é o Debugging Groups, do Ben Collins-Sussman e Brian Fitzpatrick. Inclusive há um web site sobre o livro onde dá pra ler on-line a versão internet.
Tudo começa com confiança
Minha primeira experiência profissional foi no Brasil em um órgão público do Estado de São Paulo. Lá, pude aprender sobre processos e como as pessoas “adultas” trabalham.
Eu tinha 18 anos.
Minha primeira líder foi uma pessoa que me inspirou, pois ela confiava no trabalho das pessoas. Eu comparava com outros departamentos, e na minha visão de uma pessoa ainda sem experiência de mercado (e de vida), nosso departamento period o que tinha mais sinergia.
Eu sempre tive um perfil de pessoa empenhada e focada no que faz. Isto adicionado a uma liderança que confia no trabalho, pude dar o meu melhor, evoluindo ali dentro profissionalmente e também enquanto pessoa, pois estava praticamente iniciando minha vida profissional naquele departamento.
Pensar simples é difícil
Depois de experimentar diversos projetos para adquirir experiência, me deparei com um projeto onde o líder estimulava todos a pensarem no mais simples possível.
Mas o que outline simplicidade?
Ali, pude sentir que simplicidade period um desafio constante, e não um estado de arte. Se o simples fosse fácil, não haveria tantos projetos falhos, com desperdício de recursos, prazos exorbitantes e alta rotatividade.
No geral, o que aprendi sobre simplicidade period baseado em tentar responder a estas duas perguntas:
- eu realmente entendi o problema?
- a solução que estou pensando, já existe na minha atual caixa de ferramentas ou terei que buscar fora?
A resposta para isto não é simples. Mas uma vez que conseguimos uma resposta adequada para estas perguntas, estamos pelo menos a meio caminho da solução simples.
Blindagem da equipe
Uma outra experiência minha foi trabalhar em uma empresa grande com processos burocráticos e muito bem definidos.
Geralmente, em ambientes assim, há muita política envolvida e conflito de interesses. É regular, faz parte da natureza humana de interações.
Mas deixar os conflitos baterem na equipe de desenvolvimento é a receita para a desmotivação e alta rotatividade. Meus líderes faziam um ótimo papel em blindar. Eu não sabia de muita coisa; e não queria saber. Há pessoas que gostam de lidar com isso, mas julgo que a grande maioria, não.
Eu queria apenas ajudar a equipe a desenhar e desenvolver soluções para os problemas reais que as pessoas tinham ao utilizar o software program.
Pra mim, um bom líder precisa saber blindar a equipe em diversos aspectos: política, prazos, escopos, orçamentos…mas isto não tem a ver com não ter transparência, que é assunto do próximo tópico.
Transparência abre caminhos para a entrega de valor
Muito se fala de entrega de valor. Mas o quê é entrega de valor?
Valor é a satisfação que se obtém através de um trabalho. Se a satisfação é alta, então o valor é alto. Num cenário em que não há entrega alguma, então não há valor sendo entregue.
Em outra experiência que tive, meu líder tinha uma postura de confiar na equipe e fomentar a transparência.
Havia apenas uma forma de visualizarmos o trabalho da equipe. Havia apenas uma forma de visualizarmos o suggestions das entregas feitas.
Num processo transparente assim, não há muita margem para a falta de entrega pois o próprio processo se encarrega que as entregas sejam feitas. Com transparência, conseguimos saber o que está sendo feito (não confundir isto com micro-gerenciamento, que é danoso para a saúde das equipes!), como está sendo feito, se a entrega está sendo feita com qualidade e se a satisfação está sendo ou não garantida.
Como atingir isto?
- eleger uma única ferramenta de apoio em projetos
- centralizar em apenas um único lugar a documentação e desenhos de arquitetura
- fomentar code evaluations
- falar sobre trabalho em canais públicos de comunicação, e não em canais privados
Experimentação converte em inovação
Uma notória experiência que tive em Portugal foi onde a liderança incentivava a experimentação. Isto colocava a empresa num patamar onde estava sempre inovando, quer trazendo novas ideias de produtos quer melhorando a arquitetura como um todo.
Lugares onde a experimentação não é incentivada ou é evitada, geralmente têm a tendência a ficarem defasados em termos de tecnologia e muitas vezes são massacrados pelo ecossistema acelerado de startups.
Há que se fazer um balanço entre entregar valor e experimentar. Diversas formas de atingir isto, dentre as alternativas:
- criar uma equipe de “R&D” focada nestas práticas de pesquisa
- fomentar a prática de spikes/POC’s (provas de conceito) que buscam respostas rápidas para problemas que surgem
E aqui vai uma dica, na minha completa visão mais empírica possível: nunca, jamais, em hipótese alguma, uma liderança técnica deve permitir que spikes sejam contabilizados no escopo de produto. Isto a médio prazo corta qualquer ideia de inovação, pois na primeira oportunidade de cumprir um prazo apertado, produto vai desestimular a experimentação de forma indireta.
E este é mais um motivo para eu não ser a favor se “sprints de refactoring” ou algo do gênero. Uma boa liderança técnica precisa permitir que trabalho arquitetural, refactoring, spikes e coisa do tipo seja feito ao longo dos dias, durante o trabalho regular.
Precisamos ser transparentes em permitir que produto saiba da cultura de experimentação, mas também precisamos ser capazes de convencê-los que é saudável que isto não seja contabilizado no planejamento de produto.
Automação não abre margem para discussões inúteis
Todos sabemos que discussões são importantes e devem ser fomentadas, caso contrário o produto não anda pra frente. Mas também sabemos que há diversas discussões que são completamente inúteis e não ajudam a chegar a lugar algum.
Outro projeto que eu gostaria de mencionar, a equipe contava com uma linha de automação top-notch, onde não havia margem para discussões triviais, o código period revisado com base em padrões arquiteturais apenas, pois code-style e preferências de padrões eram avaliados por ferramentas automáticas.
As options eram entregues numa velocidade adequada, não havia PR’s enormes com discussões que nunca terminavam nem havia guerra de preferência de código.
Em um ambiente com muitas pessoas, é pure que cada uma tenha opinião diferente. Mas precisamos estabelecer um processo onde problemas triviais são resolvidos de forma automática, deixando para as pessoas a tarefa de discutirem problemas que são realmente difíceis.
Coisas como discutir indentação de código, preferência de cor, usar um padrão A vs padrão B and so forth and so forth são coisas triviais que podem ser resolvidas de forma automatizada, não deixando margem para que as pessoas fiquem dias discutindo algo que um linter teria resolvido.
Algumas práticas para ajudar na automação:
- investir em linters durante a integração contínua (CI)
- estabelecer um styleguide. Há quem goste e quem não goste, mas um projeto precisa ter um ponto de partida. Deixar tudo aberto faz o projeto travar
- deploy automático, testes automatizados, rollback acessível
Estas práticas ajudam a mitigar o problema de discussões triviais.
Formação de talentos
Um valor que sempre admirei foi nos líderes que incentivavam a formação de talentos de forma genuína.
Recentemente passei a atuar num projeto onde a formação é a premissa base. Lá não pode haver margem para julgar uma pessoa por uma falta de conhecimento, nem colocá-la em público quando erros são cometidos.
Um lugar onde não há essa preocupação, tende a virar um ambiente cheio de pessoas “ninjas” que acham que podem resolver todos os problemas da “melhor forma”. O problema é que lugares assim, ao longo do tempo, ficam defasados pois não há a cultura de formação de talentos, pelo que os ninja builders buscam seus próprios caminhos ao longo do tempo.
Ambiente assim é ruim para o projeto, e não para os ditos ninjas.
Sendo assim, um ambiente que pratica a cultura de não culpar as pessoas, não julgá-las e, acima de tudo, ajudá-las a evoluir, tem menos propensão a ficar defasado.
Bons líderes formam outros líderes.
Resumo
Após descrever um pouco de minha trajetória e em como avaliei diferentes tipos de liderança, coloco aqui um resumo do que acredito traduzir em uma boa liderança:
- Confiança: sem margem para micro-gerenciamento
- Simplicidade: buscar soluções dentro antes de ir pra fora
- Experimentação: fomentar prática de experimentar sem adicionar ou afetar escopo do projeto
- Automação: delegar para as ferramentas a tarefa de avaliar problemas triviais e de preferências de código
- Formação: não culpar, não julgar, e ensinar. Bons líderes criam outros líderes.
Conclusão
Este artigo foi uma tentativa de compilar os valores que acredito serem importantes para uma boa liderança.
Apesar de saber que nunca sabemos todo o necessário, o que faz líderes serem “bons” pode ser relativo dependendo da experiência de cada um.
Aqui, foi apenas uma tentativa empírica baseada apenas na minha experiência.
