Em um dos primeiros anos da SysMiddle, bati o olho numa fila de demandas represadas e tomei a decisão mais óbvia que um gestor poderia tomar, que foi abrir vagas e contratar rápido, empilhando gente no time técnico até a fila parecer menor. Durou pouco, porque em três meses a fila voltou maior do que antes, e agora com um time novo que ainda aprendia o mesmo processo que já não funcionava.
O sintoma mais comum do crescimento é pedir mais gente
Toda empresa que cresce sente o mesmo aperto, porque as demandas aumentam mais rápido do que a capacidade de entregar, e o primeiro instinto de quem gerencia é olhar para o quadro de pessoal e concluir que faltam mãos para dar conta do volume.
O problema aparece depois, quando se percebe que contratar aumenta a capacidade bruta da operação, mas não corrige o motivo pelo qual o processo estava lento desde o início. Se o gargalo é um sistema que não conversa com outro, um fluxo manual que exige três conferências antes de seguir adiante ou uma integração que trava toda vez que muda um layout, os novos colaboradores acabam reproduzindo o mesmo gargalo em uma escala ainda maior.
Os dados mostram que talento não é o fator decisivo
A McKinsey publicou em 2024 uma análise sobre empresas em fase de scale-up que traz um ponto relevante para esse debate, mostrando que, à medida que a empresa cresce, as necessidades de talento mudam e ficam mais difíceis de acompanhar, ao ponto de os fundadores perderem a capacidade de se envolver pessoalmente em cada contratação. Segundo os pesquisadores Claudy Jules, Shahar Markovitch e Charlotte Seiler, a recomendação vai na direção oposta ao instinto comum, sugerindo um diagnóstico formal do que a operação realmente precisa antes de sair abrindo vaga atrás de vaga.
A Deloitte, em pesquisa recorrente com scale-ups europeias, traz outro dado que reforça esse ponto sob um ângulo diferente, mostrando que em 2022 as empresas pesquisadas aumentaram o quadro de funcionários em 29%, um ritmo bastante alto, e mesmo assim relataram lentidão crescente nos processos internos e nos prazos de entrega ao cliente, o que sugere que o problema estrutural continuou lá apesar de todo o time novo.
O erro fica caro porque se repete
Uma empresa que contrata para resolver um problema estrutural acaba entrando em um ciclo, no qual contrata, sente algum alívio por algumas semanas, vê o volume voltar a crescer e contrata de novo, sempre com a sensação de que dessa vez vai ser diferente. A cada rodada desse ciclo a folha de pagamento sobe, mas a velocidade da operação não acompanha na mesma proporção, até que em algum momento o time fica grande, o custo fica alto e o cliente segue esperando mais do que deveria.
Esse padrão costuma ser mais comum em empresas com sistemas legados, ERPs antigos ou processos que dependem de digitação manual entre uma ferramenta e outra, porque a cada cliente novo alguém precisa refazer na mão aquilo que já deveria estar automatizado havia muito tempo.
Aprendi isso vendo o gargalo se mover, não desaparecer
Foi assim que entendi, na prática e não na teoria, que o problema raramente está na quantidade de gente disponível, mas sim na estrutura que sustenta o trabalho dessa gente no dia a dia. Quando paramos para mapear com calma onde as integrações entre sistemas travavam a operação, a fila que parecia exigir mais dez contratações caiu para menos da metade sem que ninguém novo precisasse entrar.
Foi assim, uma combinação de processo, arquitetura e um pouco de humildade para admitir que o problema nunca tinha sido a falta de gente correndo atrás das demandas.
Estrutura primeiro, contratação depois
Antes de abrir uma vaga, vale a pena perguntar com precisão onde exatamente o trabalho trava, porque se a resposta envolve sistemas que não se falam, planilhas que substituem integrações que deveriam existir ou processos manuais dependentes de uma única pessoa, contratar apenas adia o problema para alguns meses à frente. Resolver a estrutura, por outro lado, permite que a mesma equipe dê conta de um volume bem maior sem esticar a folha de pagamento na mesma proporção.
Foi essa lição que carreguei para dentro da SysMiddle depois de errar a mão algumas vezes, e hoje, quando um cliente me procura já convencido de que precisa de mais gente, a primeira pergunta que costumo fazer é sobre onde exatamente a operação dele trava entre um sistema e outro.
