Criar um time central de plataforma parece, na maioria das empresas, decisão óbvia: reunir especialistas de infraestrutura em um só lugar, padronizar ferramentas e liberar os demais times de desenvolvimento para focar exclusivamente em construir produto. Rolando Bonaccorsi, diretor de operações da Vert Analytics, observa que essa lógica funciona bem nos primeiros meses e começa a falhar exatamente quando a empresa cresce o suficiente para que aquele time central deixe de dar conta do volume de demanda.
O erro raramente está na decisão inicial de centralizar. Está em não perceber o momento em que a centralização, útil até ali, se transforma no principal obstáculo de velocidade da empresa inteira.
A promessa de centralizar que fazia sentido no início
Quando poucas equipes de desenvolvimento dependem de infraestrutura, um time central consegue atender cada solicitação com atenção individual, mantendo padrão de qualidade elevado e evitando a duplicação de esforço que aconteceria se cada equipe resolvesse seus próprios problemas de infraestrutura de forma isolada.
Essa centralização inicial também facilita governança, segurança e conformidade, já que existe um único ponto de controle sobre como recursos são provisionados e configurados. É exatamente esse conjunto de vantagens reais que leva tantas empresas a investir pesado nesse modelo desde cedo, sem prever o que acontece quando a demanda cresce muito além da capacidade original daquele time, expressa Rolando Bonaccorsi.
Nos primeiros meses, essa estrutura até parece prova de maturidade organizacional: existe padrão, existe controle, e cada nova equipe que chega recebe onboarding cuidadoso conduzido pelos mesmos poucos especialistas que conhecem toda a infraestrutura de cor. O problema é que esse mesmo conhecimento concentrado, tão valioso no início, se torna o próprio limite de capacidade da empresa mais adiante.
Quando toda mudança passa pela mesma fila
O problema aparece de forma gradual: cada nova equipe de desenvolvimento que a empresa contrata gera mais solicitações para o mesmo time central, que não cresce na mesma proporção. Filas de espera se formam, prazos se alongam, e times de produto passam a esperar dias por algo que deveria levar minutos.
Rolando Bonaccorsi destaca que esse atraso raramente é culpa de incompetência do time de plataforma, que geralmente trabalha no limite da capacidade. O problema é estrutural: um modelo pensado para atender poucas equipes simultaneamente não escala automaticamente para atender dezenas, e insistir nesse modelo além do ponto de ruptura apenas transfere frustração para toda a organização.
A ferramenta que substitui o chamado
A correção mais eficaz costuma envolver transformar o time de plataforma de executor de solicitações em criador de ferramentas de autoatendimento, permitindo que outras equipes provisionem recursos padronizados sozinhas, sem precisar abrir chamado e esperar fila para tarefas rotineiras e bem conhecidas.
Essa mudança de postura é mais difícil culturalmente do que tecnicamente: significa que o time de plataforma deixa de controlar cada decisão individualmente e passa a garantir que os trilhos estejam bem construídos para que outras equipes andem sozinhas sobre eles, um tipo de autoridade menos visível, mas igualmente relevante para a operação inteira.
Essa transição costuma gerar resistência interna, já que membros do time de plataforma, acostumados a serem procurados constantemente, sentem, à primeira vista, perda de relevância quando outras equipes passam a resolver sozinhas problemas que antes exigiam sua intervenção direta. Reconhecer esse desconforto abertamente e redirecionar o valor do time para construir boas ferramentas em vez de resolver chamados manualmente ajuda a superar essa resistência sem sacrificar a moral da equipe.
O sinal de que chegou a hora de descentralizar
O indicador mais confiável de que um time de plataforma virou gargalo não é reclamação isolada de uma equipe insatisfeita, mas o crescimento consistente do tempo médio de espera para solicitações rotineiras, medido ao longo de vários meses seguidos, não em um pico pontual de demanda.
No fim, Rolando Bonaccorsi reforça que empresas que acompanham essa métrica com regularidade percebem o problema a tempo de agir através de autoatendimento e documentação, antes que a frustração acumulada leve equipes de desenvolvimento a simplesmente contornar o time central, recriando de forma desorganizada exatamente a fragmentação que a centralização original pretendia evitar desde o começo.
