Liderar em Tech na Blip: Quando o teu maior impacto deixa de estar no teclado

A Blip é uma empresa de engenharia de software com sede no Porto, fundada em 2009 e hoje parte do grupo Flutter Entertainment. Desenvolve produtos e plataformas para clientes em todo o mundo, o que coloca as suas equipas a operar consistentemente numa escala que a maioria das empresas portuguesas de tecnologia nunca chega a conhecer.

O Daniel Sousa, Software Engineering Director na Blip, fala-nos sobre o que muda quando se lidera engenharia a sério: o momento em que o contributo de um líder técnico deixa de estar na execução e passa a estar na influência e na estratégia.

O que se segue é uma reflexão sobre esse percurso e sobre o que significa continuar a ser engenheiro sem escrever uma linha de código.

Uma reflexão sobre influência, estratégia e o papel de quem lidera equipas de engenharia.

Há um momento, na vida de quem lidera equipas de engenharia, em que o teclado começa a fazer menos barulho. Não é um momento dramático. Não há memorando, nem anúncio, nem sequer uma reunião a marcá-lo. Acontece devagar: um pull request que deixa de ser revisto porque há uma conversa mais importante a acontecer, uma decisão de arquitetura que se toma sem a liderança na sala, um debate técnico no Slack onde se entra tarde e já não faz sentido acrescentar.

É nesse momento que muitas lideranças técnicas se deparam com uma pergunta carinhosamente desconfortável: Continua a fazer sentido chamar-me engenheiro?

A resposta honesta é que o papel mudou e é importante reconhecê-lo cedo. A partir de um certo nível de responsabilidade, o valor acrescentado de uma liderança de engenharia deixa de estar na execução e passa a estar em dois eixos - influência e estratégia. A missão, nesta fase, não é executar. É amplificar.

O desafio de liderar tecnicamente em escala.

Liderar uma equipa de engenharia parece, à primeira vista, um jogo simples: pessoas de um lado, tecnologia do outro. É uma corda bamba estendida entre dois cuidados. De um lado, o risco de se afastar da tecnologia ao ponto de perder a ligação com quem a faz acontecer. Do outro, o risco oposto: o de se agarrar ao código e, sem querer, ocupar o espaço de decisão dos outros. Ambos são armadilhas, e a segunda é, na experiência de quem já passou por ela, a mais difícil de ver, porque se disfarça de dedicação.

O contributo técnico mais valioso de quem lidera em escala raramente é escrever código. É fazer a pergunta certa na reunião certa. É levantar, com cuidado, a hipótese de que uma proposta pode criar dívida técnica daqui a três sprints. É partilhar a suspeita de que um suposto trade-off é, na verdade, uma escolha entre simplicidade futura e velocidade agora. Este tipo de contributo não se impõe, sugere-se. Não decide, ilumina. É liderança por influência, não por autoridade. E, quando é bem feita, nem se nota.

Para sustentar essa influência, é preciso manter a cabeça técnica acesa, mas de uma forma diferente da que trouxe a liderança até aqui. Mais estratégica, menos operacional. Mais ligada ao porquê, menos ao como.

O equilíbrio: continuar perto sem ocupar o lugar de ninguém.

Durante muito tempo, "continuar hands-on" foi entendido, na prática, como escrever código de vez em quando. Essa definição é limitada e arriscada. Quando uma liderança abre o editor para resolver um bug que pertence a outra pessoa, acontecem três coisas: o bug talvez se resolva mais depressa, a oportunidade de aprendizagem de quem o devia resolver desaparece e a equipa aprende uma lição implícita: quando as coisas apertam, é o líder que resolve. Nenhuma delas é positiva para a equipa, nem para a organização.

O verdadeiro equilíbrio está noutro lado. Quem lidera em escala não precisa de estar dentro do código, precisa de estar dentro das conversas-chave. A diferença é subtil, mas importante. Participar pontualmente em discussões de arquitetura, platform engineering ou observability não tem como propósito impor uma opinião, mas trazer contexto que as equipas, por estarem muito perto do problema, nem sempre têm à mão - contexto de negócio, histórico, de produto e de outras equipas.

É essa a nova forma de estar perto. As mãos já não estão no teclado, mas continuam firmemente agarradas ao problema. E isso, curiosamente, exige tanta disciplina como a de escrever código, porque implica continuar a estudar, a ler post-mortems, a acompanhar RFCs, a perceber o que muda e o que não muda, sem o conforto diário de sentir a tecnologia a passar pelos dedos. É um esforço silencioso, muitas vezes solitário, mas é o que torna a influência credível.

A estrutura que torna tudo isto possível.

Liderar pela estratégia e não pela execução não é apenas um traço individual. É também o resultado de uma decisão estrutural: investir a sério na senioridade técnica da equipa. Construir uma track de Senior e Senior Principal Software Engineers que não é apenas uma escada de títulos, mas uma rede viva de decisão técnica. Estas pessoas não se limitam a seguir uma direção, desafiam-na, validam-na e por vezes contrariam-na. Esses são os momentos em que a estrutura dá provas de estar a funcionar e em que o papel da liderança se confirma no lugar certo.

Este é, talvez, o pilar menos falado da liderança técnica em escala - a liderança não precisa de ser o cérebro técnico da equipa. Precisa de ajudar a equipa a ter um cérebro técnico coletivo, distribuído e forte. Quando essa rede existe, a liderança liberta-se do impulso de ser o decisor final em tudo e passa a ser outra coisa - catalisador, tradutor entre negócio e engenharia, guardião da coerência de longo prazo. Passa a influenciar, em vez de decidir.

É nesse papel que se continua a ser, de facto, engenheiro. Não por escrever código, mas por pensar como engenheiro em praticamente todas as conversas. E, quando uma decisão técnica importante chega ao radar executivo, o privilégio é contribuir com uma voz, sem ter de ser a voz.

O bug que ensinou mais sobre liderança do que sobre código.

Estávamos a meio de um incidente em produção, um daqueles pontos de pressão em que o instinto antigo pede para abrir o editor e intervir diretamente. Sentei-me ao lado do engenheiro que estava a conduzir a investigação, convencido de que estava ali para "ajudar". Entre uma sugestão e outra, percebi que a minha presença estava a atrapalhar mais do que a somar: cortava hipóteses antes de serem testadas, substituía a autonomia dele pela minha pressa, transformava o que devia ser uma oportunidade de crescimento numa demonstração do meu raciocínio.

Calei-me. Deixei-o conduzir. O problema foi resolvido sem mim. Aquele silêncio forçado foi a primeira vez que senti, de forma quase física, que o papel tinha mudado. Deixou de ser sobre o que eu conseguia fazer. Passou a ser sobre o que conseguia fazer com que acontecesse à minha volta.

Formação e mentoria.

A evolução técnica das pessoas da equipa é, provavelmente, a alavanca mais subestimada da liderança de engenharia. E convém ser claro num ponto: a mentoria técnica, propriamente dita, não deve viver no topo da hierarquia. Deve viver onde tem mais valor: junto dos Senior e Senior Principal Engineers, dos tech leads, dos pares que aprendem uns com os outros todos os dias, em pair programming, em revisões de código, em design reviews. O papel da liderança é outro e é mais estrutural: criar as condições para que essa mentoria técnica aconteça e aconteça bem.

Isso significa proteger tempo para mentoria, mesmo quando o roadmap aperta. Garantir pares certos entre quem tem experiência e quem está a crescer. Colocar pessoas em desafios que as desafiem. Proteger espaço para estudo, experimentação e erro seguro. Abrir oportunidades, como projetos, comunidades de prática e apresentações internas, que dão palco a quem ainda está a construir a sua voz técnica. A mentoria técnica faz-se ao lado do problema, o contributo da liderança faz-se, sobretudo, a remover atrito à volta desse encontro.

A mentoria direta da liderança tem outra natureza: é de carreira, de propósito, de contexto. É conversar sobre caminho, dúvidas, medos, próximas decisões importantes. É ajudar a pensar qual o próximo desafio que faz sentido, ou o tipo de engenheiro ou engenheira que cada pessoa quer vir a ser. A evolução técnica, em si, acontece entre quem está mais perto do problema. À liderança cabe assegurar que o terreno é fértil.

Uma liderança que se mede pelo que executa tem um teto muito baixo. Uma liderança que se mede pelas pessoas que ajudou a crescer tem um efeito que se multiplica por cada uma delas, muitas vezes sem que isso chegue a ser visível em qualquer dashboard.

O melhor dos dois mundos.

Durante muito tempo, sustentou-se o mito de que liderar engenharia exigia escolher entre dois mundos: o das pessoas ou o da tecnologia. Hoje, esse mito não resiste à prática. As lideranças técnicas que mais impacto têm não são as que largaram o código com desprezo, nem as que se agarram a ele com teimosia. São as que perceberam que liderar é, acima de tudo, amplificar.

Amplificar as melhores ideias da equipa, sobretudo quando não são as nossas. Amplificar o impacto de cada pessoa, oferecendo contexto, confiança e espaço. Amplificar a voz técnica dentro das decisões de negócio, para que a tecnologia deixe de ser vista como custo e passe a ser reconhecida como alavanca estratégica. E, talvez o mais importante de tudo, amplificar a próxima geração, com a serenidade de saber que, quando ela crescer, não vai precisar da atual liderança para tomar as decisões que hoje ainda tomamos.

Liderar engenharia é exatamente isto: deixar de ser quem resolve e passar a ser quem faz com que os problemas sejam resolvidos melhor. É trocar o mérito pela multiplicação. É aceitar que o melhor código que se pode escrever, nesta fase, é o código que não chega a ser escrito, porque alguém, na equipa, o vai escrever melhor.

Não há, no fim, maior privilégio do que este.