9 min leitura • Guide 603 of 877
Melhores Práticas de Liderança Técnica
Liderança técnica requer balancear trabalho técnico hands-on com pensamento estratégico, mentoria e comunicação. O GitScrum fornece visibilidade que ajuda tech leads a entender carga de trabalho da equipe, identificar bloqueios e garantir que direção técnica esteja alinhada com prioridades de negócio. Grandes tech leads multiplicam seu impacto através de outros ao invés de tentar escrever todo o código sozinhos.
Responsabilidades do Tech Lead
| Área | Responsabilidades | Tempo % |
|---|---|---|
| Técnica | Arquitetura, qualidade de código, decisões | 30-40% |
| Execução | Desbloquear, entrega, planejamento | 20-30% |
| Pessoas | Mentoria, crescer a equipe | 20-25% |
| Comunicação | Stakeholders, coordenação | 15-20% |
Direção Técnica
DEFININDO DIREÇÃO TÉCNICA
DECISÕES DE ARQUITETURA:
┌─────────────────────────────────────────────────┐
│ Como tech lead, você: │
│ ├── Propõe direção arquitetural │
│ ├── Coleta input da equipe │
│ ├── Avalia trade-offs │
│ ├── Toma decisões (não adia para sempre) │
│ ├── Documenta racional (ADRs) │
│ └── Assume resultados (bons ou ruins) │
└─────────────────────────────────────────────────┘
FRAMEWORK DE DECISÃO:
┌─────────────────────────────────────────────────┐
│ Antes de decidir: │
│ ├── Que problema estamos resolvendo? │
│ ├── Quais são as opções? │
│ ├── Quais são os trade-offs? │
│ ├── O que é reversível vs porta de mão única? │
│ ├── O que a equipe pensa? │
│ └── Qual o impacto de longo prazo? │
│ │
│ Portas de duas vias: Decida rápido, pode voltar│
│ Portas de uma via: Decida com cuidado, difícil │
│ reverter │
└─────────────────────────────────────────────────┘
ADR (ARCHITECTURE DECISION RECORD):
┌─────────────────────────────────────────────────┐
│ Título: ADR-003: Usar PostgreSQL como DB │
│ Data: 2025-03-15 │
│ Status: Aceito │
│ │
│ Contexto: │
│ Precisamos de banco para novo serviço. │
│ │
│ Decisão: │
│ Usar PostgreSQL no AWS RDS. │
│ │
│ Opções Consideradas: │
│ ├── PostgreSQL: Rico em features, equipe sabe │
│ ├── MySQL: Simples, menos features │
│ └── MongoDB: Schema flexível, joins difíceis │
│ │
│ Consequências: │
│ ├── ✓ Produtividade da equipe (familiar) │
│ ├── ✓ Ecossistema forte │
│ └── ✗ Deve gerenciar migrations de schema │
└─────────────────────────────────────────────────┘
Qualidade de Código
MANTENDO QUALIDADE DE CÓDIGO
DEFININDO PADRÕES:
┌─────────────────────────────────────────────────┐
│ Defina e documente: │
│ ├── Guia de estilo de código │
│ ├── Expectativas de cobertura de teste │
│ ├── Requisitos de code review │
│ ├── Padrões de documentação │
│ └── Benchmarks de performance │
│ │
│ Automatize onde possível: │
│ ├── Linting no CI │
│ ├── Gates de cobertura de teste │
│ ├── Análise estática │
│ └── Scan de segurança automatizado │
└─────────────────────────────────────────────────┘
LIDERANÇA EM CODE REVIEW:
┌─────────────────────────────────────────────────┐
│ Lidere pelo exemplo: │
│ ├── Faça reviews completos e pensados │
│ ├── Seja construtivo, não crítico │
│ ├── Explique o "porquê" do feedback │
│ ├── Reconheça bom trabalho │
│ └── Review em até 24 horas │
│ │
│ Ensine através de reviews: │
│ "Considere usar X aqui porque lida com Y │
│ edge case. Aqui está um recurso: [link]" │
│ │
│ Não apenas: │
│ "Use X ao invés" │
└─────────────────────────────────────────────────┘
GESTÃO DE TECH DEBT:
┌─────────────────────────────────────────────────┐
│ ├── Rastreie dívida explicitamente │
│ ├── Aloque tempo para pagamento (15-20%) │
│ ├── Torne trade-offs visíveis │
│ ├── Advogue por trabalho de dívida │
│ └── Balance features com saúde │
└─────────────────────────────────────────────────┘
Desenvolvimento de Pessoas
Mentoria da Equipe
DESENVOLVENDO A EQUIPE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MENTORIA: │
│ ───────── │
│ │
│ • Pair programming para ensinar │
│ • Reviews como momentos de aprendizado │
│ • Delegar tarefas de stretch │
│ • Dar feedback regular (não só em 1:1) │
│ • Celebrar crescimento │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DELEGAÇÃO: │
│ ────────── │
│ │
│ NÃO DELEGUE: │
│ • Decisões arquiteturais críticas │
│ • Comunicação com stakeholders senior │
│ • Feedback de performance │
│ │
│ DELEGUE: │
│ • Features de complexidade apropriada │
│ • Investigações técnicas (spikes) │
│ • Documentação e processos │
│ • Mentoria de membros mais novos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CRESCENDO TECH LEADS: │
│ ───────────────────── │
│ │
│ Identifique potencial: │
│ • Boa comunicação │
│ • Pensa além do código │
│ • Ajuda colegas naturalmente │
│ • Toma ownership │
│ │
│ Desenvolva gradualmente: │
│ • Liderar feature pequena │
│ • Coordenar com outra equipe │
│ • Apresentar decisão técnica │
│ • Mentorar novo membro │
└─────────────────────────────────────────────────────────────┘
Feedback Efetivo
DANDO FEEDBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO SBI: │
│ ──────────── │
│ │
│ SITUAÇÃO: Descreva o contexto │
│ COMPORTAMENTO: O que a pessoa fez (fatos, não julgamento) │
│ IMPACTO: Efeito do comportamento │
│ │
│ EXEMPLO POSITIVO: │
│ "Na sprint review ontem (situação), você explicou │
│ trade-offs técnicos de forma que PM entendeu │
│ (comportamento). Isso ajudou o time alinhar prioridades │
│ rapidamente (impacto)." │
│ │
│ EXEMPLO CONSTRUTIVO: │
│ "No code review do PR #234 (situação), os comentários │
│ foram bastante curtos como 'refatore isso' (comportamento).│
│ Junior ficou confuso sobre o que fazer (impacto). │
│ Poderia adicionar sugestões específicas?" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FREQUÊNCIA: │
│ ─────────── │
│ │
│ • Feedback positivo: Imediato, público OK │
│ • Feedback construtivo: Privado, oportuno │
│ • Não guarde para 1:1 semanal │
│ • Muitos pequenos feedbacks > poucos grandes │
└─────────────────────────────────────────────────────────────┘
Comunicação com Stakeholders
Traduzindo Técnico para Negócio
COMUNICANDO PARA CIMA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRADUZINDO TÉCNICO → NEGÓCIO: │
│ │
│ NÃO DIGA DIGA │
│ ────────── ──── │
│ "Precisamos refatorar" → "Podemos entregar X 30% │
│ mais rápido após" │
│ │
│ "Temos dívida técnica" → "Velocidade caiu 20% │
│ por manutenção atrasada" │
│ │
│ "A arquitetura não escala" → "Com crescimento atual, │
│ teremos problemas em 6m" │
│ │
│ "Preciso de 2 sprints → "Investimento de 4 │
│ para infraestrutura" semanas economizará 2h │
│ por dev por semana" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ UPDATES DE STATUS: │
│ ───────────────── │
│ │
│ • Comece com o que importa (on track? at risk?) │
│ • Seja específico sobre bloqueios │
│ • Proponha soluções, não só problemas │
│ • Comunique trade-offs claramente │
│ • Quantifique impacto quando possível │
└─────────────────────────────────────────────────────────────┘
Gestão de Tempo
Alocação do Tech Lead
COMO TECH LEAD GASTA TEMPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ POR TAMANHO DE EQUIPE: │
│ │
│ EQUIPE PEQUENA (2-4 devs): │
│ ├── Coding: 50-60% │
│ ├── Code review: 15% │
│ ├── Planejamento: 10% │
│ ├── Mentoria: 10% │
│ └── Reuniões: 10% │
│ │
│ EQUIPE MÉDIA (5-8 devs): │
│ ├── Coding: 30-40% │
│ ├── Code review: 20% │
│ ├── Planejamento: 15% │
│ ├── Mentoria: 15% │
│ └── Reuniões: 15% │
│ │
│ EQUIPE GRANDE (8+ devs): │
│ ├── Coding: 10-20% │
│ ├── Arquitetura/Design: 20% │
│ ├── Code review: 15% │
│ ├── Planejamento: 20% │
│ ├── Mentoria: 15% │
│ └── Reuniões: 20% │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ARMADILHAS COMUNS: │
│ ───────────────── │
│ │
│ ✗ Tentar codar 80% e liderar nos 20% restantes │
│ ✗ Ser gargalo em todos code reviews │
│ ✗ Estar em todas as reuniões │
│ ✗ Não bloquear tempo para trabalho focado │
│ │
│ ✓ Delegue code reviews para seniors │
│ ✓ Defina horários para disponibilidade │
│ ✓ Proteja tempo de deep work │
└─────────────────────────────────────────────────────────────┘
Armadilhas Comuns
O Que Evitar
ERROS DE TECH LEADS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROBLEMA: Tentar fazer todo código importante │
│ RESULTADO: Gargalo, equipe não cresce │
│ SOLUÇÃO: Delegue com confiança, guie através de reviews │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROBLEMA: Evitar conversas difíceis │
│ RESULTADO: Problemas crescem, ressentimento │
│ SOLUÇÃO: Feedback direto e respeitoso, oportuno │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROBLEMA: Decisões unilaterais sem input │
│ RESULTADO: Equipe desengajada, decisões piores │
│ SOLUÇÃO: Colete input, explique racional, decida │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROBLEMA: Nunca decidir ("vamos pesquisar mais") │
│ RESULTADO: Paralisia, frustração │
│ SOLUÇÃO: Time-box decisões, 80% informação é suficiente │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROBLEMA: Focar só no técnico, ignorar pessoas │
│ RESULTADO: Equipe talentosa sai │
│ SOLUÇÃO: Investir em relacionamentos e crescimento │
└─────────────────────────────────────────────────────────────┘