Gestão Dev & TIARTIGO

Então você pensa que pode liderar?

A maioria dos desenvolvedores que não pretende seguir para gerenciamento pensa que sua carreira deve levá-lo a se tornar um “arquiteto”. Quando pressionados sobre o que significa ser um arquiteto, eles geralmente descrevem o papel de um líder técnico: aquele que define a agenda técnica, que monitora os outros, que aborda as questões mais difíceis etc.

Embora isso possa perfeitamente ser uma meta válida para se tentar, nem todo mundo está destinado a chegar lá. O fato é que ninguém se torna um líder por decreto. Você só é um líder se houver pessoas dispostas a segui-lo. Isso é especialmente verdadeiro em uma meritocracia de equipes de desenvolvimento de software. Então, se você realmente quer ser um líder, entenda o que isso acarreta.

Para ser um líder técnico, você precisa ser perspicaz, persuasivo e persistente. Você precisa de discernimento para encontrar uma maneira melhor de fazer algo. Você precisa de persuasão para convencer os seus parceiros e gerentes a prosseguir com sua ideia. E você precisa de persistência para ver sua ideia ser colocada em prática.

Encontre o Melhor Caminho

A melhor maneira de fazer algo é um meio que leva a uma base de código mais limpa, a uma maior qualidade, a prazos mais curtos, ou a uma combinação disso tudo. O Melhor Caminho não é necessariamente sobre pureza técnica ou elegância. Tão difícil quanto pode ser difícil para os geeks reconhecerem, o Melhor Caminho deve ser sobre como impactar nas linhas de baixo. Menores custos, maior produtividade, e as até receitas maiores são resultados mensuráveis de fazer algo melhor.

Eu acho que a maioria dos ambientes são alvos ricos. Ou seja, provavelmente não é tão difícil encontrar algo que pode ser feito de forma melhor, mais barata, mais eficiente. Bases de código legadas podem ser refatoradas para acelerar a execução, caches de sistemas podem ser projetados para otimizar o desempenho, processos de integração contínua podem ser implementados para aumentar a qualidade.

Conheça seus limites

Provavelmente, a parte mais difícil de ser um líder técnico é se manter atualizado. É muito parecido com extração de petróleo. Cem anos atrás, a extração de petróleo era quase literalmente uma questão de perfurar um buraco no lugar certo no chão e colocar uma bomba rudimentar dentro. Atualmente, ou você está perfurando em mar aberto ou aplicando processos sofisticados de xisto.

Quando seu time é ruim, é fácil encontrar maneiras de conduzir. Uma apresentação simples sobre o teste de unidade pode ter um impacto importante sobre um time que nunca fez isso antes. No entanto, na medida em que sua equipe melhora e frutas podres caem, as ideias de mudança são mais difíceis de aparecer. Uma vez que todos estão praticando TDD, fazem OO adequadamente e executam CI o tempo todo, encontrar uma maneira melhor se torna mais difícil.

Então, você precisa mostrar seu jogo e ir atrás de coisas mais difíceis. Isso pode ser um grande desafio, pois coisas como implementar um novo ORM, criar um modelo de domínio adequado ou criar um sistema de cache avançado requerem grande aptidão e experiência. E a verdade é que nem todo mundo consegue fazer isso. Mesmo que você seja um bom desenvolvedor. E não há vergonha alguma nisso.

Afinal, se escrever software te dá um sentimento de grande realização e satisfação, não há nada de errado com “apenas” ser um bom programador. Um fabricante de relógios suíços provavelmente não se vê como “apenas um fabricante de relógio” que secretamente espera um dia se tornar um arquiteto de relógios. Ele se vê como um mestre de seu ofício, que gosta do processo de criação e é valorizado pela realização, não pelo título.

Pensamento final

Se você é um dev que sonha em ser um líder técnico, o meu conselho é encontrar um lugar que lhe dê a oportunidade de conseguir fazer isso. Se você acha que pode, abrace essa oportunidade. Mas, por favor, seja honesto consigo mesmo sobre suas habilidades e limitações.

?

Texto original disponível em http://tatiyants.com/so-you-say-you-can-lead/

Gosta de escrever coisas engraças sobre tecnologia. É criador do JS.js e do movimento MoreSQL, além de inventor do Guilt Driven Development.

Ver perfil