Como tirar o mindset de early-stage sem criar burocracia
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.
E quando você tenta mudar, ouve a frase que todo líder de tech conhece: "mas sempre foi assim".
O desafio real
O difícil não é identificar o que precisa mudar. O difícil é mudar sem transformar a empresa numa máquina burocrática que demora 3 semanas pra fazer um deploy.
Startup vive de velocidade. Se você cria processo demais, mata o que fez a empresa chegar até ali.
O que mudamos
Vou dar quatro exemplos concretos de coisas que implementamos e que geraram atrito inicial:
Testes e2e obrigatórios. Antes não tinha. O time testava na mão, ou não testava. Com 12 pessoas, todo mundo conhecia o sistema inteiro e sabia o que podia quebrar. Com 35, ninguém tem essa visão completa. Testes e2e viraram obrigatórios.
Tipagem real no TypeScript. Nosso "TypeScript" era JavaScript com extensão .ts. Qualquer coisa era any. Isso funcionava quando todo mundo sabia o que cada função esperava. Não funciona mais. Escrevi sobre como eliminamos 4.041 erros de TypeScript em 6 meses nesse artigo.
Observabilidade como regra. Implementamos New Relic em tudo. Antes, quando algo dava problema em produção, era um detetive tentando reproduzir o erro localmente. Agora a gente sabe exatamente o que aconteceu, onde, e por quê. Com 12 pessoas, dava pra perguntar "quem mexeu nisso?". Com 35, você precisa de dados, não de memória.
RFC pra features novas. Antes, alguém tinha uma ideia e começava a codar. Agora, se é algo que muda o rumo do produto, precisa de um documento mínimo explicando o que, por que, e como. Não precisa ser longo. Mas precisa existir.
Nos quatro casos, a reação inicial foi a mesma: "mas antes não precisava".
Como convencer sem impor
A resposta pra "antes não precisava" não pode ser "agora precisa porque eu mandei". Isso não funciona e cria ressentimento.
O que funcionou pra mim foi mostrar dados. Não opinião, não "melhores práticas", não "em empresa séria é assim". Dados.
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 3x maior e fazendo 80+ deploys por semana
Quando você mostra que a "chatice" gerou resultado concreto, a conversa muda.
Onde não exagerar
Tão importante quanto saber o que implementar é saber onde parar.
- Exigimos testes e2e, mas não exigimos 100% de coverage.
- RFC pra feature nova, mas não pra bugfix.
- Tipagem correta, mas com migração gradual.
A pergunta que me faço antes de criar qualquer processo novo: "isso vai ajudar o time a entregar melhor, ou só vai dar mais trabalho?"
Se a resposta for só mais trabalho, não implemento.
A lição
Crescer dói. O jeito que funcionava antes vai parar de funcionar, e você vai precisar convencer pessoas a mudar algo que elas não veem como problema.
O equilíbrio é: criar processos que protegem a empresa sem criar burocracia que trava a empresa.
Não existe fórmula. É tentativa, erro, e prestar atenção nos resultados.
Top comments (1)
Parabéns pelo conteúdo!