Onboarding de Novos Desenvolvedores: Checklist Completo Para Tech Leads

Segundo dia do novo dev no time. Ele chega, abre o Slack, e a primeira mensagem que recebe e: “Oi, tudo bem? Entao, o fulano que ia te ajudar saiu de ferias ontem. Da uma olhada no repositorio e qualquer duvida pergunta no canal.” Eu ja vi essa cena se repetir dezenas de vezes em 22 anos de carreira. E toda vez que isso acontece, o resultado e o mesmo: um profissional talentoso que levou meses para entregar o que poderia ter entregue em semanas.

Onboarding nao e “mostrar onde fica o cafe e dar acesso ao Git”. Onboarding e o processo que define se um desenvolvedor vai se tornar produtivo em 30 dias ou em 6 meses — e se vai ficar na empresa ou sair antes de completar um ano. Se voce e Tech Lead e nao tem um processo estruturado de integracao, voce esta literalmente jogando dinheiro fora e desgastando seu time sem perceber.

Neste artigo, vou compartilhar o checklist completo que construi ao longo de anos liderando times de engenharia — incluindo passagens como CTO com dois exits. Voce vai encontrar um plano semana a semana, o framework 30-60-90 dias adaptado para devs, templates prontos para copiar e usar, e os erros que eu mesmo cometi (e que voce pode evitar).

Por Que o Onboarding E a Decisao Mais Subestimada do Tech Lead

Pergunte a qualquer Tech Lead quais sao suas maiores responsabilidades. A maioria vai falar de arquitetura, code review, alinhamento com produto. Poucos vao mencionar onboarding. E ai esta o problema.

A decisao de como integrar um novo membro ao time tem efeito cascata em tudo que vem depois: velocidade de entrega, qualidade do codigo, dinamica do time, e ate a reputacao da sua area de engenharia como um lugar bom para trabalhar. Segundo pesquisa da Glassdoor, empresas com um processo de onboarding estruturado melhoram a retencao de novos funcionarios em 82% e a produtividade em mais de 70%.

Pense assim: voce investiu semanas no processo seletivo. O time de recrutamento fez triagem, voce conduziu entrevistas tecnicas, negociou salario, esperou o aviso previo. Todo esse investimento — de tempo, energia e dinheiro — e colocado em risco nos primeiros 90 dias se o onboarding for improvisado.

O papel do Tech Lead nesse processo e insubstituivel. O RH pode cuidar de contrato, beneficios e integracao institucional. Mas quem define se o novo dev vai entender a arquitetura, conhecer as convencoes do time, ter contexto sobre as decisoes tecnicas e se sentir parte do grupo? Voce.

Eu costumo dizer que onboarding e a primeira entrega do Tech Lead para o novo membro do time. E como qualquer entrega, precisa de planejamento, execucao e acompanhamento.

O Custo Real de Um Onboarding Mal Feito

Antes de entrar no checklist, vale quantificar o problema. Quando falo com Tech Leads sobre onboarding, muitos dizem “a gente da um jeito, o dev vai pegando no dia a dia”. Essa abordagem tem custos que normalmente ficam invisiveis.

Tempo Ate a Primeira Entrega Produtiva

Segundo dados compilados pela Society for Human Resource Management (SHRM), o tempo medio para um novo funcionario atingir produtividade plena e de 8 a 12 meses em cargos de conhecimento. Em engenharia de software, com um onboarding bem feito, esse numero cai para 2 a 4 meses.

Faca a conta: um dev senior com salario de R0.000/mes que leva 6 meses extras para ficar produtivo custa, conservadoramente, R0.000 a R0.000 em produtividade perdida. Multiplique isso por 3-4 contratacoes por ano e voce tem um argumento solido para investir tempo em onboarding.

Cenario real: em um time que liderei, tinhamos dois devs que entraram na mesma semana. Um foi integrado com um processo estruturado, buddy definido e plano de 30-60-90. O outro, por uma combinacao de ferias e correria, ficou “se virando”. O primeiro fez seu primeiro deploy em producao na segunda semana. O segundo levou quase dois meses. Mesma senioridade, mesmo time, mesmo codebase.

Impacto na Retencao e Motivacao

A BambooHR publicou um dado que deveria tirar o sono de qualquer lider: 31% dos profissionais pedem demissao nos primeiros 6 meses. E o motivo mais citado? Falta de clareza sobre expectativas e sensacao de abandono nos primeiros dias.

Desenvolvedores sao especialmente sensiveis a isso. Um dev que passa a primeira semana sem conseguir rodar o projeto local, sem entender a arquitetura e sem ter com quem tirar duvidas rapidamente conclui: “esse time e desorganizado”. E a partir dai, cada problema confirma essa percepcao inicial.

Retencao nao comeca na conversa de contra-proposta. Retencao comeca no primeiro dia.

O Checklist Completo de Onboarding (Semana a Semana)

Aqui esta o checklist que uso e refino ha anos. Adapte a realidade do seu time, mas nao pule etapas. Cada item existe porque, em algum momento, a ausencia dele causou problema real.

Antes do Primeiro Dia: Preparacao

O onboarding comeca antes do dev pisar (virtual ou fisicamente) na empresa. Se voce espera o primeiro dia para preparar as coisas, ja comecou atrasado.

• Acessos tecnicos: repositorios Git, ambientes de staging/producao, ferramentas de CI/CD, servicos de cloud (AWS, GCP, etc.), ferramentas de monitoramento (Datadog, New Relic, Grafana)
• Ferramentas de comunicacao: Slack (adicionar nos canais certos), email corporativo, calendario compartilhado do time
• Ferramentas de gestao: Jira/Linear/Shortcut, Confluence/Notion, Figma (se necessario)
• Equipamento: notebook configurado ou instrucoes de setup se for remoto
• Documentacao preparada: documento de boas-vindas (template abaixo), guia de arquitetura, ADRs (Architecture Decision Records), convencoes de codigo
• Buddy designado: escolha alguem do time que sera o ponto focal do novo dev (mais detalhes na secao dedicada)
• Agenda da primeira semana: bloqueie reunioes de contexto com as pessoas-chave. Nao deixe para “ver no dia”
• Primeira tarefa definida: tenha uma task pequena e bem definida reservada, idealmente um bug simples ou melhoria de documentacao

Dica pratica: crie um documento “Checklist de Novo Membro” no seu Notion ou Confluence e transforme em template. Cada nova contratacao, duplique o documento e va marcando os itens. Isso evita que coisas caiam no esquecimento.

Semana 1: Acolhimento e Contexto

A primeira semana e sobre acolhimento e contexto, nao sobre produtividade. Resista a tentacao de colocar o dev para codar no primeiro dia.

• Dia 1: Boas-vindas do Tech Lead (voce!). Apresentacao ao time. Tour pelo codebase (overview de 30 minutos, nao deep dive). Configuracao do ambiente de desenvolvimento. Primeiro commit: algo simples como atualizar o README ou adicionar seu nome na lista do time
• Dia 2-3: Sessao de arquitetura — visao geral dos servicos, como eles se conectam, onde mora a complexidade. Sessao de produto — o que o produto faz, quem sao os usuarios, quais as metricas que importam. Pair programming com o buddy em uma task pequena
• Dia 4-5: Primeiro PR proprio (task pequena que voce reservou). Code review cuidadoso e educativo — este e o momento de ensinar as convencoes do time, nao de cobrar. Primeira 1:1 com o Tech Lead (use o template abaixo)

Um erro que cometi no inicio da minha carreira como lider: na primeira semana, eu soterrava o novo dev com documentacao. “Le esse doc de arquitetura de 40 paginas, depois le o runbook, depois o guia de deploy…” O resultado? Sobrecarga cognitiva e zero retencao. Hoje, dose a informacao. Entregue o que o dev precisa para aquele dia, nao para o proximo mes.

Semana 2-4: Primeiro Ciclo de Contribuicao

Aqui o dev comeca a contribuir de verdade, mas ainda com suporte proximo.

• Tasks de complexidade crescente: comece com bugs e melhorias pequenas, evolua para features de escopo limitado
• Participacao em cerimonias do time: planning, daily, retrospectiva. Incentive (mas nao force) participacao ativa
• 1:1 semanal: perguntas focadas em bloqueios, duvidas e sensacao de pertencimento
• Primeiro code review como reviewer: peca para o novo dev revisar um PR de alguem do time. Isso acelera o entendimento do codebase e mostra que a opiniao dele e valorizada
• Documentacao de aprendizado: peca para o dev documentar algo que teve dificuldade de encontrar. Isso melhora a doc do time e da ownership ao novo membro

Ao final da semana 4, o dev deve conseguir pegar uma task do backlog, implementar e abrir um PR com minima orientacao. Se isso nao esta acontecendo, nao e culpa do dev — e sinal de que o onboarding precisa de ajustes.

Mes 2: Autonomia Crescente

No segundo mes, o objetivo e transicionar de “suporte proximo” para “suporte sob demanda”.

• Tasks de media complexidade: features que envolvem mais de um servico ou que exigem entendimento de regras de negocio
• Participacao em discussoes tecnicas: design reviews, discussoes de arquitetura. O dev deve comecar a opinar e questionar
• Reducao gradual do buddy: o buddy ainda esta disponivel, mas o dev deve buscar respostas antes de perguntar (docs, codigo, colegas)
• 1:1 quinzenal: mude o foco para desenvolvimento de carreira e feedback bidirecional
• Primeiro on-call ou suporte (se aplicavel): com acompanhamento de alguem experiente

Mes 3: Contribuicao Plena e Avaliacao

Ao final do terceiro mes, voce deve ter clareza sobre a adaptacao do dev ao time.

• Contribuicao autonoma: o dev pega tasks complexas, faz estimativas razoaveis e entrega com qualidade
• Revisao formal do onboarding: reuniao dedicada para avaliar como foi o processo. O que funcionou? O que faltou? Use esse feedback para melhorar o onboarding do proximo
• Feedback 360 informal: converse com 2-3 membros do time sobre como esta a integracao
• Definicao de objetivos: agora que o dev conhece o contexto, defina metas claras para os proximos 3 meses
• Celebracao: reconheca publicamente a conclusao do onboarding. Pode ser simples — uma mensagem no Slack do time destacando as contribuicoes do dev nesse periodo

O Plano 30-60-90 Dias Para Desenvolvedores

O framework 30-60-90 e classico em gestao, mas precisa de adaptacao para engenharia de software. A versao que uso segue a logica de Aprender, Contribuir e Liderar.

30 Dias: Aprender

Objetivo: o dev entende o produto, a arquitetura, as ferramentas e a cultura do time.

• Consegue rodar todos os servicos localmente
• Entende o fluxo principal do produto (happy path)
• Conhece as convencoes de codigo e o processo de deploy
• Fez pelo menos 5 PRs (mesmo que pequenos) e 5 code reviews
• Consegue descrever a arquitetura macro em 2 minutos para alguem de fora
• Sabe quem procurar para cada tipo de duvida (infra, produto, design, dados)

Metrica de sucesso: o dev responde “sim” com confianca quando voce pergunta “voce sabe como deployar uma mudanca em producao?”.

60 Dias: Contribuir

Objetivo: o dev entrega valor de forma consistente com supervisao minima.

• Completa tasks de media complexidade dentro das estimativas
• Identifica e reporta bugs ou debitos tecnicos que encontra pelo caminho
• Participa ativamente de discussoes tecnicas com opiniao embasada
• Faz code reviews que agregam valor (nao apenas “LGTM”)
• Tem pelo menos uma melhoria de processo ou documentacao sugerida/implementada

Metrica de sucesso: voce nao precisa mais revisar cada PR com lupa. Confia que a qualidade esta la.

90 Dias: Liderar

Objetivo: o dev assume ownership de uma area e influencia o time positivamente.

• E referencia em pelo menos um dominio ou servico do sistema
• Consegue fazer onboarding de contexto para outro novo membro (sobre a area que domina)
• Propoe solucoes tecnicas e lidera a implementacao de features de ponta a ponta
• Contribui para melhorias no processo do time (retros, sugestoes de ferramentas, automacoes)
• Tem uma relacao de confianca estabelecida com os colegas de time

Metrica de sucesso: quando alguem do time tem uma duvida sobre a area do novo dev, ja procura diretamente ele.

O Papel do Buddy: Por Que Todo Novo Dev Precisa de Um

Buddy nao e mentor. Nao e gestor. E o colega que esta ali para responder aquelas perguntas que o novo dev tem vergonha de fazer em publico: “onde fica o documento de deploy?”, “como rodo os testes de integracao?”, “esse servico cai toda segunda-feira mesmo ou e so comigo?”.

O conceito de buddy system e usado extensivamente pelo Google (documentado no livro “Work Rules!” de Laszlo Bock) e e considerado um dos fatores de maior impacto na velocidade de integracao.

Como escolher o buddy:

• Alguem que esta no time ha pelo menos 6 meses (conhece o contexto)
• Que tem paciencia e gosta de ensinar (nem todo dev senior e bom buddy)
• Que nao esta sobrecarregado com deadlines criticos naquele periodo
• De preferencia, alguem que trabalha em uma area proxima a que o novo dev vai atuar

Responsabilidades do buddy:

• Estar disponivel para duvidas rapidas (nao precisa largar tudo, mas responder no mesmo dia)
• Fazer pair programming pelo menos 2-3 vezes na primeira semana
• Apresentar o novo dev informalmente a pessoas de outros times
• Almocar junto (virtual ou presencial) nos primeiros dias
• Dar feedback informal ao Tech Lead sobre como o novo dev esta se adaptando

Importante: reconheca e compense o buddy. Ser buddy toma tempo e energia. Reduza a carga de tasks dele naquele sprint, ou reconheca publicamente na retro. Se ser buddy for visto como “trabalho extra ingrato”, ninguem vai querer fazer.

Templates Prontos Para Usar

Templates economizam tempo e garantem consistencia. Aqui estao tres que uso em todo onboarding.

Template de Documento de Boas-Vindas

Crie um documento (Notion, Confluence, Google Docs) com a seguinte estrutura:

• Bem-vindo(a) ao time [nome do time]! — uma mensagem pessoal de 3-4 linhas
• Sobre o time: missao, produtos/servicos que mantem, metricas que acompanha
• Pessoas: nome, papel e uma curiosidade pessoal de cada membro (humaniza o time)
• Links essenciais: repositorios, documentacao, dashboards, canais de Slack
• Seu plano de 30-60-90: objetivos e expectativas para cada fase
• Glossario: termos internos e siglas que o time usa (todo time tem jargao proprio)
• FAQ: “como faco deploy?”, “como peco ferias?”, “onde reporto um incidente?”

Template de Checklist Tecnico

Lista de verificacao para garantir que o dev tem tudo que precisa para trabalhar:

• [ ] Acesso ao GitHub/GitLab (com permissoes corretas)
• [ ] Ambiente de desenvolvimento rodando (todos os servicos locais)
• [ ] Acesso a ambientes de staging e producao (read-only inicialmente)
• [ ] Acesso a ferramentas de observabilidade (logs, metricas, traces)
• [ ] Acesso ao gerenciador de tarefas (Jira, Linear, etc.)
• [ ] Acesso ao Slack nos canais relevantes (time, engenharia geral, alertas)
• [ ] VPN configurada (se aplicavel)
• [ ] Consegue rodar a suite de testes completa
• [ ] Consegue fazer um deploy para staging
• [ ] Fez o primeiro commit e PR

Template de 1:1 da Primeira Semana

A primeira 1:1 com um novo membro e diferente das 1:1s regulares. O foco e acolhimento e deteccao precoce de problemas. Use estas perguntas como guia:

• “Como voce esta se sentindo ate agora?”
• “Voce conseguiu configurar tudo? Tem algum bloqueio tecnico?”
• “Voce sabe quem procurar quando tiver duvidas?”
• “As expectativas da entrevista estao alinhadas com o que voce esta vendo?”
• “Tem algo que voce precisa de mim esta semana?”
• “Como posso tornar sua experiencia nessa primeira fase melhor?”

Anote as respostas. Elas sao ouro para ajustar o onboarding em tempo real e para melhorar o processo para os proximos.

Erros Comuns No Onboarding Que Afastam Talentos

Depois de participar de dezenas de onboardings — como novo membro, como Tech Lead e como CTO — mapeei os erros que se repetem. Veja se reconhece algum:

1. “Mergulha no codigo que voce aprende”

Jogar o dev no codebase sem contexto e como entregar um mapa sem legenda. Ele ate encontra coisas, mas perde horas que seriam economizadas com 30 minutos de explicacao. Conhecimento tacito precisa ser transmitido ativamente — ele nao se absorve por osmose.

2. Nenhum ponto de contato claro

O novo dev tem uma duvida e nao sabe para quem perguntar. Ele posta no canal do time e ninguem responde por 4 horas. Isso destroi a confianca e a motivacao mais rapido do que qualquer problema tecnico. Sempre defina um buddy.

3. Expectativas nao comunicadas

“Achei que ele ja ia estar entregando features complexas no segundo mes.” Se voce nao disse isso explicitamente ao dev, nao pode cobrar. O plano 30-60-90 resolve isso: coloca expectativas claras, por escrito, desde o primeiro dia.

4. Overload de informacao no dia 1

Reuniao de boas-vindas, apresentacao de 50 slides sobre a empresa, sessao de arquitetura de 2 horas, leitura de 3 documentos de 20 paginas. O dev sai do primeiro dia exausto e sem reter 80% do que ouviu. Dose a informacao ao longo das primeiras semanas.

5. Ignorar o aspecto humano

Onboarding nao e so sobre acessos e codigo. E sobre fazer alguem se sentir parte de um grupo. Apresentacoes pessoais, almoco com o time, perguntar sobre interesses fora do trabalho — essas coisas parecem triviais, mas fazem uma diferenca enorme na sensacao de pertencimento.

6. Nao pedir feedback sobre o processo

O novo dev e a pessoa com a perspectiva mais fresca sobre seu time. Pergunte: “O que poderiamos ter feito melhor no seu onboarding?” Use as tecnicas de feedback construtivo para criar um espaco seguro para essa conversa.

7. Tratar onboarding como evento, nao como processo

Onboarding nao acaba na primeira semana. O checklist acima cobre 90 dias por um motivo: integracao real leva tempo. Se voce para de acompanhar depois do dia 5, esta fazendo uma orientacao, nao um onboarding.

O Pilar People no First Lead

Onboarding e uma das habilidades centrais do que eu chamo de Pilar People na lideranca tecnica. Junto com 1:1s, feedback, gestao de conflitos e desenvolvimento de carreira, saber integrar novos membros ao time e o que diferencia um Tech Lead que “gerencia tarefas” de um que realmente lidera pessoas.

No programa First Lead, o Pilar People e um dos tres eixos fundamentais (ao lado de Tech e Delivery) que formam a base de um Tech Lead completo. Se voce quer aprofundar suas habilidades de gestao de pessoas em engenharia — nao com teoria generica de RH, mas com frameworks praticos criados por quem viveu na trincheira — esse e o caminho.

Construir um processo de onboarding e so o comeco. A jornada de liderar pessoas em tecnologia exige pratica deliberada, frameworks testados e acompanhamento. Voce nao precisa descobrir tudo sozinho.

Conclusao

Onboarding de desenvolvedores nao e burocracia. E investimento. Cada hora que voce gasta preparando a integracao de um novo membro economiza semanas de retrabalho, reduz turnover e constroi um time mais forte e coeso.

Recapitulando o essencial:

• Comece antes do primeiro dia: acessos, documentacao e buddy definidos com antecedencia
• Siga o ritmo certo: semana 1 para contexto, semanas 2-4 para primeiras contribuicoes, mes 2 para autonomia, mes 3 para contribuicao plena
• Use o framework 30-60-90: Aprender, Contribuir, Liderar — com expectativas claras e metricas de sucesso
• Designe um buddy: nao e opcional, e essencial
• Documente e melhore continuamente: cada onboarding e uma oportunidade de refinar o processo

Pegar o checklist deste artigo, adaptar a sua realidade e implementar no proximo onboarding do seu time ja e um grande primeiro passo. Seus futuros colegas de time — e o seu eu futuro, que nao vai precisar ficar apagando incendios de integracao — vao agradecer.

Se voce quer ir alem e desenvolver todas as competencias de um Tech Lead completo — incluindo People, Tech e Delivery — conheca o programa de lideranca tecnica em liderancatecnica.com.br e de o proximo passo na sua carreira.