O momento em que algo começa a sair do lugar raramente é um grande evento. Normalmente é um pull request que fica parado por dias porque ninguém sabe quem deveria revisar. Ou a terceira reunião para decidir algo simples que, meses atrás, teria sido resolvido com uma conversa rápida no Slack. Aquela sensação de contexto compartilhado e velocidade que o time tinha no início começa a se perder. Esse é o primeiro sinal de que a cultura de engenharia está sofrendo com o crescimento.
Por que boas intenções não escalam
A maioria dos times não começa querendo uma cultura confusa ou inconsistente. A aposta é que, contratando pessoas boas e motivadas, uma boa cultura vai surgir sozinha. E por um tempo isso até que funciona funciona, ainda mais se o time é pequeno.
Mas o crescimento introduz um atrito que essa abordagem “orgânica” não consegue sustentar. O que acontece é o seguinte:
As dependências entre times se multiplicam. Uma funcionalidade simples passa a exigir coordenação entre três times diferentes, cada um com seu backlog e suas prioridades. O que antes era uma chamada de função vira uma requisição de rede e um acordo de nível de serviço.
O nível de experiência também se diversifica. O time inicial de engenheiros sêniores passa a trabalhar junto com muitos desenvolvedores júnior e pleno. As regras não escritas e boas práticas que antes todo mundo “sabia” deixam de ser um conhecimento comum.
A tomada de decisão se espalha sem um conjunto claro de princípios. Mais pessoas decidem todos os dias, mas sem diretrizes, essas decisões começam a entrar em conflito. Um time escolhe uma tecnologia de banco de dados para um serviço, enquanto outro resolve um problema parecido com outra ferramenta, criando sobrecarga operacional mais à frente.
Simplesmente esperar que as novas contratações absorvam a cultura por osmose é uma estratégia falha.
Boas intenções não fornecem a estrutura necessária para manter alinhamento e qualidade conforme você escala.
Encarando a cultura como um sistema, não como um artefato
A alternativa é parar de tratar cultura como um artefato, um manifesto na parede, e passar a encará-la como um sistema que precisa ser projetado e cuidado de forma consciente. Como qualquer sistema, ela tem entradas, processos e resultados. Você pode observar o que acontece no dia a dia, medir os efeitos e fazer ajustes direcionados para melhorar como o time trabalha.
Como você pode fazer isso:
Entradas
São as mudanças constantes que afetam o sistema. Pense em novos membros no time, grandes mudanças de projeto ou reestruturações organizacionais. Cada nova contratação pode reforçar ou enfraquecer as normas que já existem.
Processo
Ele se forma a partir das interações e rotinas do dia a dia do time. Como os code reviews acontecem, como decisões técnicas são tomadas e comunicadas, como incidentes são tratados e até o tom das conversas nos pull requests. Tudo isso molda o processo.
Saídas
São os resultados observáveis. Você sente isso na saúde e no moral do time, e consegue medir em coisas como qualidade de código, taxa de bugs e velocidade de entrega do produto.
Onde agir e o que observar na cultura de engenharia
Quando você passa a enxergar a cultura como um sistema, começa a procurar os pontos-chave de alavancagem. Eles não são valores abstratos, mas os rituais concretos do dia a dia onde a cultura é reforçada ou corroída. A informação mais valiosa vem de ouvir o atrito.
Preste atenção aos temas recorrentes nas retrospectivas. As pessoas estão constantemente frustradas com builds lentos, documentações confusas ou um processo de code review pouco claro.
Esses sinais mostram onde o sistema está sob pressão.
Arquitetando para o crescimento cultural
Construir uma cultura resiliente significa ser intencional no desenho dos seus principais processos de engenharia. É sobre criar estruturas que orientem as pessoas para os comportamentos desejados, especialmente conforme o time cresce e a supervisão direta se torna impossível.
Projete suas interações centrais com intenção
Em vez de deixar processos críticos acontecerem por acaso, defina-os. Isso cria consistência e clareza, que são essenciais para escalar.
Estruture a tomada de decisões técnicas.
Use um processo como Architecture Decision Records (ADRs). O valor real de um ADR não está no documento em si, mas no processo que ele incentiva: articular claramente o problema, avaliar trade-offs e criar um registro para quem entrar no time depois.
Isso força um pensamento claro e evita que os times voltem a discutir sobre as mesmas coisas.
Defina as boas práticas de code review
O que é um bom code review na sua organização? É sobre bloquear mudanças ou é uma oportunidade de ensino e compartilhamento de conhecimento? Estabeleça expectativas claras.
Por exemplo, um review deve confirmar se a mudança está alinhada com a arquitetura do sistema, se tem cobertura de testes adequada e se é compreensível para a próxima pessoa que for mexer naquele código.
Construa um bom processo de onboarding
Os primeiros 30 dias de um novo engenheiro são a oportunidade de maior impacto para transmitir cultura.
Ele deve mergulhar a pessoa em como vocês constroem software.
Coloque alguém experiente acompanhando, dê uma tarefa inicial bem definida e siga de perto o primeiro pull request e o deploy. Isso ensina as normas do sistema pela prática, não apenas pela documentação.
Faça da cultura uma responsabilidade de todos
Uma cultura de engenharia saudável não pode ser imposta de cima para baixo. Ela precisa ser assumida e mantida por quem faz o trabalho todos os dias.
Líderes de time como referência cultural
Tech leads e gestores amplificam a cultura no dia a dia. Eles dão o tom nos code reviews, ajudam a manter os rituais funcionando e são a primeira linha de defesa quando padrões começam a não ser seguidos. Dê a eles autonomia e suporte para atuarem como guardiões culturais de seus times.
Crie pontes entre times
Comunidades de prática ou guildas, como um grupo de backend ou de observabilidade, ajudam a quebrar silos. Elas conectam pessoas com interesses parecidos em times diferentes. É nesses espaços que padrões compartilhados surgem e se espalham de forma natural, em vez de serem impostos.
Distribua responsabilidade para indivíduos
Dê a engenheiros a responsabilidade por partes específicas do sistema de engenharia. Uma pessoa pode cuidar da performance do pipeline de CI, outra da qualidade da documentação. Isso espalha a responsabilidade e permite melhorias contínuas que beneficiam o time inteiro.
Acompanhe o progresso
Por fim, cultura é um sistema vivo. Ela precisa de manutenção constante. Não dá para definir processos, documentar tudo e seguir a vida esperando que funcione para sempre.
Tenha check-ins regulares pra sentir o pulso do time, como pesquisas focadas em engenharia. Faça perguntas objetivas sobre tempo de resposta em code reviews, qualidade das reuniões ou confiança no processo de deploy. O objetivo é entender a saúde do sistema no dia a dia.
Mais importante: use esse feedback para agir.
Tratar cultura como um trabalho contínuo de engenharia, assim como monitorar performance ou pagar dívida técnica, é o que permite que ela acompanhe o crescimento do time, em vez de quebrar sob pressão.
