Como montei meu primeiro time de Engenharia

Luiz Rolim
Tech at Quero
Published in
7 min readAug 16, 2019

--

Sobre os desafios de abrir um escritório da Quero e manter os desenvolvedores motivados ao lado do produto

Após dez anos trabalhando como desenvolvedor de software, saí da zona de conforto para entrar no “lado negro da força”. Virei um Engineering Manager tunado, já que fui o escolhido para abrir o escritório da Quero Educação em São Paulo.

Até chegar nesse ponto da minha carreira, programei nas mais mais variadas plataformas, desde as tradicionais Java e .NET, passando por Ruby, até chegar na moderninha NodeJS. Também atuei em startups, empresas de médio e grande porte, tanto no Brasil, como no exterior, antes de viver na pele como criar estratégias para montar — e também manter — um time de Engenharia que faz a diferença no mercado de tecnologia.

Como descrito no papel oficial de um Engineering Manager, eu deveria montar um time de desenvolvimento e mantê-lo produtivo e motivado. Entre outras palavras, deveria negociar com o time do produto uma possível mudança de escopo e também seria responsável pelo crescimento dos desenvolvedores. Em outras palavras, eu deveria ser um líder de um time que ainda nem existia.

A lista a seguir pode até parecer uma receita de bolo com ingredientes e modo de preparo bem definidos, mas foram apenas as saídas que encontrei para meu próprio desafio na Quero Educação.

Recrutamento

O primeiro desafio que encontrei foi definição de um processo seletivo adequado. Naquele momento, deveria filtrar candidatos que fit cultural e pelos requisitos técnicos por meio de um processo que não fosse demasiadamente cansativo a ponto de demover bons desenvolvedores.

Para dificultar um pouco mais a minha situação, eu estava na cidade de São Paulo, onde eu teria desafios adicionais. A Quero Educação não era conhecida na capital, como era na sua cidade de origem, São José dos Campos. Além disso, a oferta de boas empresas de tecnologia em São Paulo é bastante elevada, o que torna o mercado extremamente competitivo para qualquer companhia.

Após testarmos algumas abordagens, chegamos ao modelo que usamos atualmente: um teste online de aptidões e algumas rodadas de entrevista, geralmente realizadas virtualmente. Com esse formato, geralmente conseguimos concluir todo o processo em cerca de uma semana, um prazo satisfatório.

Fit cultural

Já ouviu falar de candidatos tecnicamente brilhantes sendo eliminados no processo seletivo? Quando isso acontece, muitas vezes a justificativa é por não possuírem o famoso fit cultural, seja da empresa, seja do time.

Vejo que a maioria dos atrasos em projetos, códigos de má qualidade e problemas de processo é oriunda de problemas comportamentais e não, técnicos. Pode parecer clichê, mas, em primeira e grossa análise, fit cultural nada mais é do que adequação aos valores da empresa.

É praticamente impossível que alguém produza em alto nível quando não se acredita no mesmo que a empresa.

O perfil do candidato deve se encaixar bem no time que ele irá entrar, tanto de ponto de vista dos membros deste time, quanto do escopo de atuação do mesmo. Por isso, é de grande importância tentar entender o quanto antes o que motiva e o que desmotiva uma pessoa, o que ela espera do dia a dia e qual seria o ambiente de trabalho ideal para ela.

Desde o início de minha jornada como EM, baseando-me nos valores da Quero, entendi que o filtro deve ser feito desde o início para compor o mais balanceado time de Engenharia.

Motivação

Pela minha experiência, os melhores desenvolvedores são justamente os que têm um brilho nos olhos ao resolver problemas e ao comemorar, desde os pequenos avanço do dia a dia, até as grandes entregas. Eles trazem os benefícios mais perenes à empresa, sendo necessário identificar, já no processo seletivo, quais são os candidatos que poderão se sentir motivados com os desafios da empresa.

Quando entrevisto um desenvolvedor mais sênior, consigo prever seu comportamento, já que este possui uma visão mais clara do que o motiva e o incomoda no dia a dia. Ele também consegue identificar de forma certeira os pontos de ação que precisam ser atacados pela empresa, além de conseguirem implementar melhorias no processo.

Por outro lado, a estratégia deve ser diferente com um desenvolvedor com menos experiência. Muitas vezes, ele ainda não definiu suas motivações no trabalho, se gosta de fazer telas que sejam usadas por muitos usuários ou se prefere otimizar um framework.

Encontrei no equilíbrio entre pessoas mais e menos experientes o melhor caminho para ter um time motivado na medida certa.

Superstars vs. Rockstars

Em um time sempre haverá dois tipos de desenvolvedores: o que terá um processo de crescimento acentuado e o que evoluirá de forma sólida e gradual. Eles são chamados desenvolvedores superstars e rockstars, respectivamente, e a presença balanceada desses perfis é essencial em uma empresa.

Independentemente do nível de senioridade, superstars são aqueles que propõem as grandes disrupções técnicas e de processo, sendo realizador e não mandador. Por outro lado, costumam ser os mais ansiosos e sentem-se desmotivados quando não recebem estímulo intelectual constante, além de estarem sujeitos a empreender e buscar novos desafios.

Sólido como uma rocha, o desenvolvedor que ajudará no equilíbrio ao perfil acima é o rockstar, que deseja um crescimento sólido e gradual, compreendendo profundamente as regras de negócio. São os popularmente classificados como “paus para toda a obra”, porém, no geral, menos disruptivos.

É função do EM e eu assumi o papel de identificar quem são os superstars e rockstars no meu time. Se fosse composto somente por um dos perfis, seria uma receita para o fracasso.

Feedback contínuo

Já com o time montado, chega a hora de dar feedback — talvez a tarefa mais importante de um EM. Críticas e elogios devem ser fornecidos de preferência o mais próximo possível ao momento das ações que as desencadearam. Caso contrário, não surtirão o mesmo efeito.

Qualquer ação passível de crítica não pode passar em branco, sob risco de se tornar um mau comportamento habitual. Por outro lado, uma ação louvável sem o devido reconhecimento pode desmotivar rapidamente um desenvolvedor, especialmente um que tenha um perfil superstar. Além disso, um elogio tem de ser específico o suficiente para não entrar por um ouvido e sair pelo outro.

A falta de reconhecimento é um dos principais motivos dos pedidos de demissão dos desenvolvedores, mesmo aqueles que são vistos pelos líderes e membros do time como peça-chave. Portanto, comunique-se!

Aqui na Quero Educação, costumamos promover uma sessão de feedback individual a cada duas semanas, a qual batizamos carinhosamente de 1x1. Tentamos, na medida do possível, sempre alertar os pontos de atenção e celebrar cada pequena conquista de nossos colaboradores.

Cortando pela raiz

Uma parte importantíssima e dificílima do dia a dia de um EM é saber demitir. Eu estaria mentindo se dissesse que não fico nervoso apenas ao fazer o exercício mental de um processo de demissão.

No entanto, se o desempenho de um desenvolvedor está muito abaixo do restante do time mesmo com os feedbacks, é preciso demiti-lo, por mais que eu deva reter meus colaboradores na empresa. Afinal, um colaborador improdutivo pode transformar seu time em improdutivo também.

Ainda sobre liderança

Por mais que um líder com background de desenvolvimento seja capaz de contribuir individualmente, ele nunca será capaz de sozinho ter um impacto sequer próximo daquele alcançável pelo seu time. Um bom Engineering Manager é, portanto, aquele que consegue otimizar o seus times.

Eu, como Engineering Manager de São Paulo, tive que entender que meu desempenho está diretamente mensurado pelo desempenho dos meus times. E tal desempenho deve ser observado constantemente, tanto do ponto de vista da quantidade e qualidade das entregas, quanto da maturidade das práticas de desenvolvimento da equipe.

Apesar de haver inúmeras fórmulas e receitas de bolo por aí para montar e manter times produtivos, vejo que nada substitui a criatividade, capacidade e brilhantismo individuais. Assim, acredito que devo sempre:

Manter a régua alta no momento da contração,

Buscar por pessoas melhores tecnicamente que eu mesmo,

Levar sempre em conta os fatores culturais e motivacionais de cada um.

E, para complementar, eu busco sempre extrapolar as minhas principais tarefas como Engineering Manager, seguindo os seguintes pontos como mantra:

Comunicar a visão da empresa com clareza

Promover uma comunicação inspiracional com os funcionários

Promover o estímulo intelectual

Prestar apoio emocional em momentos difíceis

Reconhecer e elogiar

O resultado esperado é, claro, sucesso garantido. E, se não for, aprenderemos com os erros para montar — e manter — um time melhor ainda.

--

--