A edição de Novembro da Harvard Business Review traz um artigo muito interessante chamado “The Boss as Human Shield”, que se baseia no novo livro de Bob Sutton, “Good boss, bad boss”. Considerando que Sutton é o autor de No Asshole Rule eu estou bem ansioso para ler seu novo livro.
O artigo me fez lembrar sobre minhas experiências gerenciando times. Eu comecei em empresas pequenas. Nestes lugares minhas responsabilidades incluíam gerenciar pequenos times. Após um hiato trabalhando para empresas grandes eu acabei voltando a “ter meu time ” na Globo.com. Hoje em dia boa parte do que eu faço é gerenciar equipes, incluindo não apenas desenvolvedores mas todas as competências relacionadas ao desenvolvimento de software.
E uma das coisas que eu aprendi é exatamente o que este artigo diz. Para mim, a primeira obrigação de um líder de equipe —ou chefe, ou algo do tipo—é formar uma excelente equipe. A segunda obrigação é deixar este povo trabalhar em paz, sem interrupções desnecessárias.
Quando comecei na Globo.com desenvolvedores no meu time estavam acostumados a comparecer a diversas reuniões por semana. Eram reuniões internas da equipe, com outros departamentos… Naquela época nosso time ficava situado num prédio diferente do resto da empresa, o que fazia com que para cada reunião houvesse um gasto extra de uns 30/40 minutos em deslocamento.
Mudar cultura é algo sempre complicado e eu falhei diversas vezes em conseguir convencer as pessoas de que havia algo muito errado nisso. Existem momentos, entretanto, onde você pode pedir e deve carta branca. No caso do antigo time, esta ocasião foi o lançamento do GloboVideos 4.2, que é basicamente a versão que se encontra no ar ainda hoje, mais de três anos depois daquele projeto.
O time havia passado maus bocados no lançamento do GloboRádio, nosso projeto anterior. Por diversos motivos nós trabalhamos todos os fins-de-semana por um mês e meio. Para o novo projeto eu pedi à gerencia carta branca para tentar algumas coisas diferentes e deixei claro que não me comprometeria com o prazo se tivesse que trabalhar com as limitações do projeto anterior.
O pedido foi aceito e uma das mudanças que implantamos foi uma metodologia mais ágil (a primeira vez que a empresa viu um Story Wall na vida foi a cartolina improvisada que colamos no nosso rack de servidores de desenvolvimento). Uma outra foi ser mais seletivo com reuniões, especialmente reuniões que exigiam o time todo.
Nas primeiras duas semanas do projeto eu pareei com o Tiago Motta desenvolvendo o embrião do framework de widgets que desenvolvemos para o site (que eventualmente virou caso de estudo). Depois de definido um bom rascunho do framework e da nossa API de WebServices eu , praticamente, passei a atuar como porteiro para o time.
A cultura que implantamos nunca foi formalmente definida, mas alguns pontos estavam em nossas cabeças:
- Nada é segredo, a menos que seja: Ninguém estava proibido de ir a reuniões. Todas as reuniões eram abertas ao time e eu fazia o máximo para explicar ao time o que tinha sido discutido e os impactos.
- Liderar é basicamente coordenar: Apesar de ser o responsável técnico pelo que era produzido pelo time eu evitava ao máximo tomar qualquer decisão durante as reuniões. Geralmente eu sabia a pauta com antecedência e discutia com o time antes de falar com os outros grupos. Quando eu sabia que teríamos que decidir algo durante a reunião eu trazia o especialista naquela parte comigo.
O grande problema para mim em seguir esta estratégia foi como me manter por dentro da parte técnica. Por gastar tanto tempo em reuniões, quase sempre infrutíferas, eu tinha pouquíssimo tempo para chegar na minha mesa, atualizar meu computador com o código-fonte e dar uma olhada nos commits do dia. Eu tive que investir muito tempo extra para, geralmente em casa, entender onde estávamos e ajudar as pessoas com a visão de para onde queríamos ir. Se pensarmos que este projeto introduziu diversas tecnologias novas na empresa (Memcached, Server-side JavaScript, Widgets, REST…) isso era uma preocupação constante na minha cabeça.
Para o time na era fácil acumular as coisas que queriam conversar comigo para discussão em lotes. Por sorte nós conseguimos montar um time fabuloso antes do projeto iniciar; as pessoas conseguiam, de fato, trabalhar e decidir muita coisa em conjunto e compartilhavam a mesma visão para o produto e a arquitetura.
Essa experiência moldou a forma com que lido com meus times. No início de um desenvolvimento (ou no início do processo de refactoring, caso o trabalho que esteja fazendo seja a recuperação de um projeto que está indo mal) eu passo a maioria do tempo escrevendo código e lidando com problemas técnicos. Depois de algum tempo, talvez uma ou duas iterações, eu passo a dedicar a maior parte do tempo à não deixar desenvolvedores (e testadores, e analistas, e etc.) desperdiçarem o deles em coisas sem valor real.
Isto é central à maneira como eu vejo liderança em times de desenvolvimento. O primeiro problema que, como líder, me preocupo é o ciclo de feedback imediato, as coisas que fazem com que o desenvolvedor perca tempo para escrever código. Com este problema remediado –geralmente seguindo uma destas estratégias– eu passo a focar mais no próximo ciclo de feedback, e no próximo… Estes ciclos foram melhor explicados
na minha apresentação do Caelum Day 2009.
É duro para alguém que gosta do que faz pensar que liderar uma equipe de desenvolvedores significa ter pouco tempo para escrever código mas, no final, o que você precisa ter na cabeça é que é há muito mais valor em capacitar o seu time do que em qualquer peça de código que você consiga escrever sozinho.
