O problema da equipe de 20 pessoas: grande demais para o caos, pequena demais para um LMS
Com 8 pessoas, muita equipe ainda consegue funcionar na base da memória.
A pessoa nova senta perto de quem conhece o fluxo de faturamento. A gerente de operações responde à mesma pergunta quatro vezes no Slack e mal percebe. A liderança de customer success grava uma tela rápida, joga num canal e isso passa a ser chamado de treinamento.
Não é elegante, mas funciona bem o bastante. Todo mundo sabe mais ou menos quem sabe o quê. As lacunas são resolvidas na conversa.
Aí a equipe cresce.
Em algum ponto perto de 20 pessoas, os pequenos atritos deixam de ser pequenos. As mesmas perguntas de onboarding continuam aparecendo, mas agora caem em caixas de entrada diferentes. A especialista informal vive em reuniões. Vendas explica o produto de um jeito, suporte de outro, e operações vai criando sua própria versão da verdade para conseguir tocar o trabalho.
Nada está pegando fogo. Essa é parte do problema. A equipe já passou do ponto em que o caos improvisado funciona, mas ainda não o bastante para justificar uma stack completa de learning, uma pessoa dedicada a enablement ou um projeto de treinamento de seis meses. Então compartilhar conhecimento vira um bico de todo mundo, o que normalmente significa que não vira trabalho de ninguém.
Quando “pergunta pra aquela pessoa” para de funcionar
Quase sempre existe aquela pessoa.
Não literalmente. Mas toda equipe tem alguém carregando uma quantidade pouco razoável de contexto na cabeça. Essa pessoa sabe por que o processo de reembolso tem três exceções esquisitas. Sabe qual cliente enterprise ainda precisa do fluxo antigo. Sabe que o SOP no Notion está tecnicamente certo, mas esquece aquela etapa que evita dor de cabeça depois.
Por um tempo, isso parece eficiente. Para que documentar tudo se aquela pessoa responde em trinta segundos?
Porque trinta segundos não ficam em trinta segundos por muito tempo.
Quando a equipe cresce, as perguntas se multiplicam mais rápido do que as respostas. Quem entra não sabe o que não sabe, então pergunta de forma reativa. Gestores vão tapando buracos ao vivo. O treinamento vira uma cadeia de interrupções. As pessoas são prestativas, mas o sistema é frágil.
O problema não é só conhecimento não documentado. É que conhecimento documentado e conhecimento absorvido não são a mesma coisa.
A maioria das equipes em crescimento acaba escrevendo as coisas. Cria pastas, wikis, gravações de walkthrough, documentos de processo. Depois assume que a mera existência da documentação resolve o problema. Raramente resolve.
Um SOP de 14 páginas pode estar perfeito e ainda falhar como treinamento. Uma pasta cheia de gravações de calls pode ser útil e ainda ensinar quase nada, se ninguém souber o que procurar. Documentação armazena informação. Treinamento ajuda uma pessoa a usar essa informação no momento certo, sob a pressão normal do trabalho, sem caçar em cinco abas.
É outro tipo de trabalho.
Esse meio do caminho existe mesmo
Empresas grandes resolvem isso com estrutura. Compram um LMS, definem responsáveis, montam cursos, acompanham conclusão, criam regras de governança e gastam um bom tempo administrando tudo isso.
Uma empresa com 35 pessoas geralmente não precisa disso. E, mais importante, geralmente não consegue sustentar isso.
Sistemas corporativos de aprendizagem partem de um certo mundo: requisitos de compliance entre departamentos, administradores em tempo integral, programas formais, avaliações longas de software, escala suficiente para justificar complexidade. Para uma equipe enxuta, isso pode parecer instalar segurança de aeroporto para cuidar da cozinha do escritório.
Então as equipes adiam. Mantêm o treinamento informal porque a opção formal parece pesada demais.
É aqui que muita dor evitável nasce. Não exatamente por ignorar treinamento. Mas por assumir que só existem duas escolhas: continuar improvisando ou comprar um software feito para uma empresa dez vezes maior.
Existe um caminho do meio, mas ele costuma parecer menos impressionante do que se imagina.
Geralmente começa com uma pergunta mais estreita: onde a inconsistência custa mais caro para esta equipe?
Não “como montar um programa completo de aprendizagem?”.
Mais algo como: por que novas pessoas de CS levam seis semanas para tocar renovações com segurança? Por que toda contratação de suporte precisa da mesma explicação improvisada sobre regras de escalonamento? Por que gestoras ainda estão reteachando o mesmo processo dois meses depois do onboarding?
Essas perguntas levam a treinamentos melhores porque estão presas ao trabalho. Trabalho real, com modos de falha e consequências. Isso importa. Equipes nessa fase não precisam de uma universidade corporativa. Precisam de menos erros repetidos, ramp-up mais rápido e menos dependência de quem estiver online.
Sistemas pequenos, não grandes programas
As equipes que lidam bem com isso normalmente fazem algumas coisas pouco glamourosas.
Elas param de tratar treinamento como evento único. Ler documentação na primeira semana não é a mesma coisa que aprender um trabalho. As pessoas precisam de informação em sequência, com exemplos, prática e algum jeito de verificar se aquilo realmente ficou.
Elas partem do material que já existe em vez de começar da página em branco. A melhor matéria-prima costuma estar espalhada por aí: demos gravadas, revisão de calls, documentos de política, walkthroughs de processo, explicações de gestores em threads de Slack. O trabalho não é inventar conteúdo do zero. É transformar contexto disperso em algo ensinável.
Elas escolhem alguns momentos que realmente importam. A equipe não precisa operacionalizar todo pedaço de conhecimento de uma vez. Precisa identificar os pontos em que a confusão gera atrito: handoffs, casos de borda, etapas de compliance, explicações para clientes, erros recorrentes.
E tornam a responsabilidade tediosa e explícita. Não “o time cuida do onboarding”. Uma pessoa de fato cuida do fluxo de onboarding de suporte. Alguém atualiza o treinamento da política de devolução quando a política muda. Alguém percebe que metade da turma errou a mesma pergunta ou continua cometendo o mesmo erro no trabalho real.
Isso tem menos a ver com volume de conteúdo e mais com ciclos de feedback.
Um sistema de treinamento decente para uma empresa de 20 a 200 pessoas não é uma biblioteca gigante. É um pequeno conjunto de trilhas de aprendizagem ligadas a responsabilidades reais, mantidas por quem está mais perto do trabalho e revisadas com frequência suficiente para que informação desatualizada não vire política da empresa em silêncio.
Isso pode viver em ferramentas simples. Às vezes é um criador leve de cursos. Às vezes é wiki mais explicações gravadas mais check-ins com a gestão. Às vezes uma plataforma como a Capya fica no meio e estrutura o que a equipe já tem. O ponto não é a categoria da ferramenta. O ponto é o treinamento virar um sistema mantido, em vez de um monte de referências soltas.
Passou da osmose, ainda não virou burocracia
Esse estágio meio torto costuma ser mal interpretado.
Lideranças assumem que a sensação de bagunça vem só do crescimento, e crescer é bagunçado mesmo. Isso é parcialmente verdade. Mas existe um tipo específico de bagunça que aparece quando a equipe continua dependendo de proximidade social muito depois de isso deixar de escalar.
Numa empresa de 12 pessoas, as pessoas aprendem ouvindo umas às outras. Numa empresa de 60, aprendem chutando, interrompendo ou deixando de perguntar.
Essa mudança é fácil de não perceber porque os documentos existem. As gravações de reunião existem. A ideia de que o treinamento está “em algum lugar no Notion” existe. O que falta é a ponte entre informação disponível e entendimento repetível.
Essa ponte não exige um departamento de T&D. Exige que a equipe aceite que saber alguma coisa não é o mesmo que ensiná-la, e guardar alguma coisa não é o mesmo que aprendê-la.
Para empresas nesse meio do caminho, essa costuma ser a transição real. Não de startup para enterprise. De proximidade para sistemas.
Muitas equipes demoram demais para fazê-la.
Quando fazem, aquela pessoa já está cansada.