Tech Lead deve programar? O dilema de quem lidera e ainda é cobrado por entrega

Todo Tech Lead já recebeu duas cobranças na mesma semana: entregar o que está no seu nome e cuidar do time. A resposta de sempre, “depende”, quase nunca ajuda. Este artigo explica de onde vem o dilema, o que cada lado custa e quais critérios ajudam a decidir quanto código faz sentido assumir.

Em resumo

• O Tech Lead deve programar em parte do tempo, e a pergunta mais útil é quanto e que tipo de código.
• O dilema nasce de duas cobranças medidas por réguas diferentes: código tem números, liderança quase não tem.
• O cargo não tem definição única, e o tamanho do time muda quanto código cabe na agenda.
• Três critérios orientam a decisão: caminho crítico, tamanho do time e fase do produto.
• Um combinado explícito com o time e com a diretoria troca a culpa por uma escolha consciente.

Uma quinta-feira de fim de sprint

Cenário ilustrativo, composto para este artigo. Não descreve uma pessoa ou empresa real.

Rafael é Tech Lead de um squad de seis pessoas. O sprint fecha na sexta. Ele tem um PR crítico para terminar, três revisões de código esperando por ele e um 1:1 que já remarcou duas vezes. Às 18h, o PR está pronto e as revisões foram feitas, mas o 1:1 ficou para a semana seguinte.

Na sexta, a diretoria pergunta pela entrega e ele responde com o que foi para produção. Ninguém pergunta pelo dev que passou dois dias travado esperando uma decisão de arquitetura, nem pelo feedback que ele não deu. Rafael fecha a semana com a sensação de ter feito o trabalho de duas pessoas e de ter falhado em uma delas.

Duas cobranças que não cabem na mesma agenda

O dilema existe porque cada cobrança usa uma régua diferente. A entrega de código tem régua pronta: PR aberto, PR aprovado, tarefa no ar. A liderança não tem. Revisar com cuidado, destravar uma decisão de arquitetura ou conduzir um bom 1:1 são trabalhos que quase não deixam rastro nos números do sprint.

Isso cria um viés previsível: o que se mede ganha prioridade. O Tech Lead que quer mostrar resultado tende a puxar mais código, justamente porque o código é o que aparece. É comum, nessa posição, sentir menos tempo programando, mais tempo em reunião e uma culpa por não estar “fazendo coisas”.

O que fica de fora é o trabalho invisível: arquitetura, mentoria e revisão de código, que sustentam a qualidade do time mas não entram em nenhum painel. Quando só uma das duas cobranças tem régua, a decisão sobre quanto programar deixa de ser técnica e vira reação ao que é cobrado.

Por que o dilema existe: o papel não tem definição única

Tech Lead não é um cargo com o mesmo significado em todo lugar. Existe uma linha de pensamento que separa três responsabilidades de liderança em um time de produto: produto, técnica e pessoas. Na prática, as empresas costumam acumular essas funções em duas pessoas, ou até em uma só. Em algumas, o Tech Lead segue uma trilha técnica sem subordinados diretos. Em outras, também cuida de pessoas.

Dois fatores empurram o Tech Lead para o código. O primeiro é a origem: muita gente chega ao cargo por excelência técnica, e nem sempre com formação em gestão. O segundo é a expectativa: há uma linha de raciocínio segundo a qual o tech lead programa bem mais do que o engineering manager e costuma assumir os projetos longos e mais complexos do backlog.

Os dois lados, cada um com um custo

Nenhum dos extremos é neutro. A tabela resume o que cada escolha costuma dar e custar.

Aspecto	Programa bastante	Programa pouco
O que ganha	Credibilidade técnica, contexto do código e capacidade extra no sprint	Tempo para revisão, mentoria, alinhamento e decisões de arquitetura
O que custa	Revisão e mentoria ficam para depois, e o time espera por decisões	Distância do código real, com o risco de decidir sobre algo que já não conhece
Risco principal	Virar gargalo: o PR do líder e a decisão pendente disputam o mesmo tempo	Perder a leitura técnica do time e a credibilidade com ele

Há quem defenda que o maior valor do Tech Lead está no julgamento técnico, e não na velocidade de digitação. Há também quem o descreva como alguém que divide o tempo entre programar e liderar o restante do time, sem fixar a proporção. As duas leituras convivem: o equilíbrio muda conforme o contexto.

A virada: a pergunta útil é quanto e que tipo de código

“Deve programar?” esconde duas perguntas melhores: que tipo de código e quanto. Três critérios ajudam a responder.

• Caminho crítico. Código no caminho crítico do sprint é o pior candidato para o Tech Lead, porque qualquer interrupção (uma revisão, uma dúvida, uma reunião) atrasa a entrega inteira. Spikes, protótipos e tarefas que podem esperar funcionam melhor: o trabalho continua útil mesmo quando o Tech Lead é interrompido.
• Tamanho do time. Quanto mais pessoas dependem de revisões e decisões, mais caro é o tempo gasto em código próprio. Em um time pequeno, programar mais pode ser razoável. Conforme o time cresce, cada hora de código do líder é uma hora a menos de apoio para várias pessoas.
• Fase do produto. Na descoberta ou na arquitetura inicial, o contexto que vem de programar é valioso. Na fase de escala e manutenção, o valor do líder tende a migrar para alinhar, revisar e antecipar problemas.

Delegar faz parte da resposta: tarefas técnicas repassadas a engenheiros mais experientes também geram experiência para eles.

De volta à quinta-feira do Rafael

Continuação do cenário ilustrativo.

Na semana seguinte, Rafael muda uma coisa: antes do sprint começar, ele escolhe uma tarefa técnica fora do caminho crítico e passa as tarefas urgentes para outras pessoas do squad. Reserva dois blocos fixos para revisão e um para os 1:1s. E conta ao time e à diretoria o combinado: neste ciclo, ele programa pouco e decide rápido.

O PR dele sai mais devagar. Em compensação, ninguém fica travado esperando uma decisão, e o 1:1 acontece. A cobrança por entrega não desaparece, mas agora ele sabe responder a ela com um combinado explícito, e não com culpa.

Como o Devint ajuda a tirar a liderança técnica do achismo

Parte do dilema do Tech Lead nasce de uma régua que só enxerga código. O Devint combina sinais de Git, horas, uso de IA e a avaliação estruturada da liderança em um DevScore com composição aberta, incluindo as dimensões de Competência técnica e Comportamento, para que a conversa sobre desempenho tenha critério além da quantidade de código. Veja como o Devint apoia a avaliação de times de tecnologia com critério.

Perguntas frequentes

Tech Lead deve programar?

Em geral, sim, mas em parte do tempo. Uma linha de raciocínio comum descreve o Tech Lead como quem divide o tempo entre programar e liderar o time. A proporção depende de três fatores: se a tarefa está no caminho crítico, o tamanho do time e a fase do produto. Quanto maior o time, menos código próprio costuma fazer sentido.

Qual a diferença entre Tech Lead e Engineering Manager?

O Tech Lead cuida da direção técnica do time, como qualidade de código e decisões de design, e programa bem mais. O Engineering Manager foca em pessoas: 1:1s, contratação, carreira e comunicação com a empresa. Em empresas pequenas, uma pessoa pode acumular os dois papéis, o que fica difícil de sustentar quando o time cresce.

Quanto tempo um Tech Lead deve dedicar a código?

Não existe um percentual consagrado, e a resposta muda conforme o time e a fase do produto. Uma regra prática é programar fora do caminho crítico e reservar blocos fixos para revisão, decisões de arquitetura e 1:1s, combinando com o time e com a diretoria quanto código o líder assume em cada ciclo.

Como mostrar o trabalho de liderança que não aparece em PRs?

Com combinados explícitos e critérios de avaliação que incluam revisão, mentoria e decisão técnica, em vez de medir só a entrega de código. Registrar o que foi decidido e destravado em cada ciclo ajuda na conversa com a diretoria. O que não tem régua tende a perder prioridade para o que tem.