Como tirar o mindset de early-stage sem criar burocracia

Source: Dev.to

Contexto

Quando entrei na Monest como Head de Tecnologia, o time de tech tinha 12 pessoas. Um ano depois, somos 35. Esse crescimento muda tudo: processos que funcionavam com 12 pessoas simplesmente quebram com 35. O problema é que ninguém percebe na hora; o time continua operando do mesmo jeito, até que algo estoura. Quando você tenta mudar, ouve a frase que todo líder de tech conhece: “mas sempre foi assim”.

O difícil não é identificar o que precisa mudar, e sim mudar sem transformar a empresa numa máquina burocrática que demora semanas para fazer um deploy. Startups vivem de velocidade; criar processo demais pode matar o que fez a empresa chegar até ali.

Exemplos de processos implementados

A seguir, quatro mudanças concretas que introduzimos e que geraram atrito inicial:

1. Testes end‑to‑end (e2e) obrigatórios

   • Antes não havia testes automatizados; o time testava manualmente ou não testava.
   • Com 12 pessoas, todos conheciam o sistema inteiro.
   • Com 35, ninguém tem visão completa, então tornamos os testes e2e obrigatórios.

2. Tipagem real no TypeScript

   • Nosso “TypeScript” era JavaScript com extensão .ts, usando any em tudo.
   • Isso funcionava quando todos sabiam o que cada função esperava.
   • Implementamos tipagem estrita e, em 6 meses, eliminamos 4.041 erros de TypeScript (detalhes no artigo mencionado).

3. Observabilidade como regra

   • Implementamos New Relic em todos os serviços.
   • Antes, um problema em produção exigia um “detetive” reproduzindo o erro localmente.
   • Agora sabemos exatamente o que aconteceu, onde e por quê, usando dados em vez de memória.

4. RFC (Request for Comments) para novas features

   • Antes, alguém tinha uma ideia, conversava no corredor e começava a codar.
   • Agora, novas features precisam de um documento mínimo explicando o quê, por quê e como.
   • O documento não precisa ser longo, mas deve existir.

Em todos os casos, a reação inicial foi a mesma: “mas antes não precisava”. A resposta não pode ser “agora precisa porque eu mandei”. Isso gera ressentimento.

Resultados

Depois de um ano com essas mudanças, nossos números mostram:

• 50 % menos tickets de suporte
• 36 % menos post‑mortems no Q4 comparado ao Q1, mesmo com o time quase 3× maior e realizando 80+ deploys por semana

Quando você demonstra que a “chatice” gerou resultados concretos, a conversa muda.

Como decidir novos processos

É tão importante saber o que implementar quanto saber onde parar. Algumas diretrizes que adotamos:

• Testes e2e: exigidos, mas sem 100 % de coverage.
• RFC: obrigatório para features novas, mas não para bugfixes.
• Tipagem: correta, porém com migração gradual.

Antes de criar qualquer processo novo, pergunto:

“Isso vai ajudar o time a entregar melhor, ou só vai dar mais trabalho?”

Se a resposta for “só mais trabalho”, não implemento.

Conclusão

Crescer dói. O que funcionava antes deixa de funcionar, e você precisará convencer pessoas a mudar algo que elas não veem como problema. O equilíbrio está em criar processos que protegem a empresa sem gerar burocracia que a trave. Não existe fórmula mágica; é tentativa, erro e atenção constante aos resultados.