Quantas vezes você já ouviu a seguinte frase "a empresa é assim, lide com isso" e engoliu seco porque parecia a única opção? Essa frase costuma ser tratada como "algo comum", como "personalidade de gestor". Raramente mencionam o termo correto que é despreparo para gerir pessoas.
A história abaixo não é sobre uma grande empresa com RH ineficiente, ou uma startup sem controle. A empresa era pequena, que seguiu pequena, onde o gestor era o dono e não havia ninguém acima dele para trazer à tona um despreparo que era evidente.
Os fatos descritos aqui aconteceram com uma pessoa próxima, que chamarei de Maria, e que autorizou o uso da sua história na carreira tech.
O início do conflito: Quando a pressa substitui o planejamento
O projeto era grande: refazer um SaaS inteiro, com frontend e backend construídos do zero. Quando ela entrou na equipe, o backend já estava encaminhado, faltava o frontend. A decisão do gestor foi comprar um template pronto e construir tudo em cima dele. Parece prático, mas não é: um template genérico, feito para qualquer tipo de aplicação, carrega dependências e estruturas depreciadas que nada têm a ver com o projeto proposto, e boa parte do tempo da equipe acaba consumida limpando código desnecessário e torcendo para tudo continuar funcionando.
Maria ficou de analisar o primeiro template. Percebeu que a quantidade de dependências depreciadas e bugs atrasaria o projeto, e sugeriu construir o frontend do zero. A sugestão foi aceita, e ela passou os 7 meses seguintes construindo sozinha uma base sólida, eficiente e confiável.
Com a entrada de um novo desenvolvedor sênior na equipe, o que Maria esperava ser uma colaboração alimentada pela experiência do colega, se transformou em mais 14 meses de trabalho em cima de uma nova compra de template. Imposto sem debate técnico prévio, e que resultaram no descarte de todo o trabalho prévio de Maria com desenvolvimento de uma base correta.
A decisão não foi tomada com base em qual abordagem era tecnicamente melhor, foi tomada com base em quem falou por último e com mais anos de experiência no currículo. Isso não é um erro técnico, é um erro de processo. Quando a palavra de quem tem mais cargo ou mais tempo de casa pesa mais do que meses de entrega comprovada, a equipe aprende que propor, testar e validar não importa tanto quanto convencer quem decide.
É esse tipo de ambiente que ensina gente boa a parar de sugerir.
O risco real apareceu 4 meses antes da nova e última data de lançamento, já sem margem para mais adiamentos. Uma das tecnologias base do template sofreu uma atualização de versão, o gestor pediu a atualização no projeto, e o template simplesmente parou de funcionar. Nem o sênior conseguiu resolver os erros de incompatibilidade gerados. Reverter para a versão anterior lançaria o projeto já obsoleto, então tudo foi refeito pela terceira vez, em um terceiro template diferente que também trazia depreciações e erros na base.
Um projeto com prazo de lançamento de menos de 1 ano chegou a 2 anos sem estimativa de conclusão.
Em nenhum momento houve uma avaliação real do risco de construir a base inteira de um SaaS em cima de templates prontos e genéricos. Comprar pronto parece economizar tempo, mas só empurra o custo para frente, e quando ele chega, vem maior. É gestão de projeto amadora tratar prazo e tecnologia como decisões independentes uma da outra, e quem paga por essa desconexão não é quem decide, é quem está na ponta reescrevendo o mesmo projeto pela terceira vez.
Duas vozes que não se alinhavam e o trabalho que não chegava a lugar nenhum
A comunicação interna era um ponto extremo a se questionar, principalmente entre gestor e sênior, raramente consistentes entre si. Quando Maria buscava resolver alguma dúvida, um dizia uma coisa, o outro dizia o oposto. Ela virou o ponto de contato involuntário entre os dois, tentando alinhar o que já deveria estar alinhado antes de chegar até ela. Levou as divergências para um canal aberto a todos, mas raramente isso resolvia algo.
Havia também um desgaste diário nas trocas de direção sem comunicação: PRs ficavam semanas ou meses sem revisão, acumulando conflitos impossíveis de resolver e obrigando Maria a refazer a mesma PR 5, 6, 7 vezes. Via seu trabalho parado, sem avançar nem retroceder, enquanto cobranças chegavam como se ela não estivesse entregando: "você não está entregando o suficiente" ou "há muitas PRs suas paradas", as mesmas PRs que esperavam validação de quem simplesmente deixava pra mais tarde.
Em paralelo, seu trabalho podia ser jogado fora a qualquer momento, sem aviso.
Repare o tamanho da inversão aqui, quando duas pessoas em posições diferentes de decisão que não se alinham entre si. O custo desse desalinhamento não fica apenas com elas, ele chega até quem tem menos poder de recusa para um papel de intermediário. Cobrar entrega de quem está travado esperando revisão não podemos chamar de gestão de performance, isso é confundir sintoma e causa sem observar quem controla o gargalo.
Um ambiente que normalizava o desconforto
Além dessa instabilidade técnica que ela enfrentava no dia a dia, havia um padrão constante nas reuniões: piadas constrangedoras, algumas colocando Maria como alvo e fazendo dela o "palhaço" da vez. Aparentemente ninguém percebia, ou ninguém se importava com o quanto aquilo a incomodava. Em certo momento ficou implícito, uma piada feita onde todos riram menos ela, o que significava que não merecia aumento. Isso foi verbalizado na frente de todos, e ela ficou sem palavras. Não rir foi tratado como sinal de que ela não queria aumento ou não queria ser promovida. Talvez até uma forma de coação sutil, porém eficaz, o tipo de coisa que ensina a engolir o desconforto.
Isso não é cultura descontraída nem falta de jeito social, é condicionar reconhecimento profissional a uma performance emocional que nada tem a ver com entrega de trabalho. Quando rir de uma piada vira pré-requisito informal para crescer na empresa, o problema não é falta de senso de humor de quem não riu, é gestão de pessoas tratando desconforto alheio como moeda de troca.
O corpo começou a cobrar
O primeiro episódio de burnout Maria não percebeu, mas o segundo e o terceiro não vieram sozinhos. Acompanhados de ansiedade, noites mal dormidas e depois um quadro depressivo que chegou devagar. A imunidade caiu e a fez verbalizar que estava no limite, um pedido de ajuda. A resposta veio em poucos minutos: "A empresa é assim, lide com isso.", a mesma empresa que prometia um ambiente familiar, amigável e compreensível quando a contrataram.
Aqui o despreparo deixa de ser só falta de experiência e passa a ser negligência. Ninguém espera que um líder de equipe tenha resposta pronta para tudo, muito menos para a saúde mental de alguém. Mas existe uma diferença enorme entre não saber o que fazer e escolher não fazer nada diante de um pedido de ajuda direto, e a segunda opção é omissão.
O alívio misturado com a perda e a incerteza na carreira
Finalmente a demissão chegou, e o primeiro sentimento foi de alívio. Mas, passadas algumas semanas, veio a famosa sensação de estar perdida sem saber o que fazer. Se 7 meses de trabalho podiam ser descartados com uma conversa, se em 2 anos e meio de trabalho tudo o que fez sempre foi visto como errado e questionável, o que ela realmente sabia fazer? Foi o suficiente para fazer com que ela se afastasse da carreira, por sentir que perdeu todo o seu tempo durante todos esses meses de trabalho, um tempo que foi gasto tentando sobreviver em um ambiente que deveria ser de crescimento profissional e pessoal.
Depois de quase 6 meses, Maria está retornando aos poucos e entendendo que, ao contrário do que imaginava, ela estava certa em boa parte do tempo, se não o tempo todo.
O que fica dessa história
Maria terminou esses dois anos e meio se perguntando o que ela realmente sabia fazer, mas nada do que ela viveu foi sobre incompetência técnica. Templates falham, códigos quebram, tecnologias são atualizadas e bugs aparecem, isso faz parte do trabalho de qualquer time. O que a fez duvidar de si mesma não foi o próprio trabalho, foi ver 7 meses de entrega descartados sem debate, foi ser cobrada por PRs que ela não podia validar sozinha, foi ter o silêncio diante de uma piada usado contra ela como prova de que não merecia crescer. Nada disso mede competência. Mede o quanto alguém aguenta absorver a desorganização de quem deveria estar organizando.
Um gestor que tomou decisões sem avaliar o que já havia sido construído, que deixou a palavra de quem falava mais alto pesar mais do que meses de entregas, que não conseguiu alinhar a própria comunicação com a da equipe que ele mesmo montou. Foi esse gestor quem tolerou, quando não incentivou, um ambiente onde desconforto virava moeda de troca por reconhecimento, e que, diante de um pedido de ajuda real, escolheu responder que a empresa era assim. Essa parte não se dilui em "cultura de empresa", é responsabilidade de uma pessoa específica, e também não é exclusividade de negócios pequenos: é o retrato de um tipo de gestão que existe aos montes, seja numa empresa pequena onde o gestor é o dono, seja numa empresa grande com uma liderança que não cumpre seu papel, onde não há ninguém disposto a dizer que aquilo precisa mudar e o despreparo nunca é confrontado.
Liderar bem não é sobre nunca errar numa escolha feita. É escutar quem está no dia a dia do projeto antes de descartar o trabalho dessa pessoa, alinhar antes de cobrar, garantir que ninguém precise se sentir mal para provar seu valor. Quando isso falta, o custo não aparece só em atrasos de cronograma, aparece depois, na carreira de quem saiu de lá achando que o problema era ela. Se você reconheceu esse padrão em algum lugar onde trabalha ou já trabalhou, vale se perguntar se o que te fez duvidar de você foi mesmo o seu trabalho ou foi a bagunça de quem deveria estar te dando direção, e prestar atenção em quem pode estar carregando esse peso sozinho agora.
- Agradecimentos
Quero agradecer ao @clintonrocha98 pelo feedback quando apresentei minha primeira versão, a @szaranct pelo review minucioso quando a segunda versão chegou, e a @cherryramatis que me ajudou muito com seu artigo de como escrever artigos. 💜
Top comments (12)
Acredito que nunca é demais ou exagerada qualquer discussão relacionada a saúde mental no ambiente de trabalho, ainda temos muito a caminhar pra de fato viver num mundo que olha pra isso com a devida atenção. Seu texto é muito importante pra trazer à tona o tanto que essa lógica de que toda contribuição pode ser descartável a qualquer momento muitas vezes acaba por minar a confiança ou mesmo impactar na dedicação ou desempenho de um profissional.
Eu ainda adicionaria mais uma reflexão, será que nesse contexto as contribuições de Maria, fosse ela João, seriam mais relevantes para a gestão e colegas?
Gostei de como você separou falha técnica de falha de gestão. Quando decisões e revisões travam o trabalho, cobrar entrega de quem está esperando só esconde o gargalo.
Já perdi a conta de quantas vezes vi devs talentosos queimarem não por falta de skill técnica, mas por ficarem anos num ambiente onde "é assim mesmo" vira desculpa pra não resolver dívida técnica, não dar feedback, não definir prioridades claras e tratar gente como recurso descartável.
O perigo real não é o caos em si — é a normalização. Quando a equipe para de questionar porque "não adianta", você perde a capacidade de identificar o que de fato dá pra melhorar vs. o que é estrutural. Já vi gente sair de lugares tóxicos e levar 6 meses só pra reaprender a ter opinião técnica, propor arquitetura, dizer "não" pra prazo impossível.
Uma heurística que uso: se em 3 meses você não consegue citar uma mudança concreta que sua voz ajudou a acontecer, o problema não é você. Gestão preparada cria espaço pra discordância produtiva; despreparada confunde silêncio com alinhamento (site: labagent .tech)
Câu "công ty như thế, chấp nhận đi" thực chất là cách nói mềm của "chúng tôi không định thay đổi và cũng không quan tâm bạn có lớn hay không". Tôi từng ở lại một nơi như vậy 2 năm với hy vọng "thay đổi từ trong ra ngoài" — kết quả: burnout, kỹ năng đọng lại, và CV bị空白 2 năm vì không có project nào xứng đáng viết.
Dấu hiệu nhận biết sớm: khi raise concern về process/technical debt, manager không hỏi "làm sao fix?" mà hỏi "ai chịu trách nhiệm?". Hoặc khi onboarding không có doc, không có mentor, chỉ ném bạn vào production "để học nhanh".
Lesson learned: đừng cố "chữa" culture hỏng. Dùng energy đó để build side project, học stack mới, hoặc phỏng vấn nơi khác. Career là marathon, không phải sprint để chứng minh mình "kiên cường" trước người không quan tâm.
Nếu đang ở chỗ đó: document mọi thứ, keep receipts, và chuẩn bị exit plan. Loyalty dành cho người trị vì bạn, không dành cho logo trên lương PS: the tool I meant is on labagent .tech
Essa frase do "a empresa é assim" é um sinal vermelho clássico que muita gente ignora tentando ser resiliente. Já passei por situações onde achei que era apenas um problema de cultura pontual, mas na verdade era uma falha estrutural de liderança que drenava toda a energia do time. O grande perigo é que essa passividade acaba normalizando processos ineficientes e burnout. Aprendi que, quando o custo emocional de "engolir seco" começa a afetar a qualidade técnica do meu código e minha vontade de estudar, é sinal de que o ciclo precisa ser quebrado antes que a carreira estagne de vez — found it via LabAgent, site: labagent .tech
Câu "công ty là như vậy, hãy chấp nhận" thực chất là cách che giấu sự lười biếng của leadership — không muốn sửa quy trình hỏng, không muốn đối mặt conflict, không muốn đầu tư vào people. Tôi từng ở lại 18 tháng ở nơi có văn hóa này, hy vọng "tôi sẽ thay đổi được từ bên trong". Kết quả: burnout, kỹ năng đọng lại, và CV có một khoảng trống khó giải thích.
Dấu hiệu nhận biết sớm: khi feedback được gán cho "attitude problem", khi on-call rotation không có comp time, khi senior dev phải fix bug do manager không dám nói "không" với stakeholder. Đừng hỏi "tôi có thể cải thiện gì?", hãy hỏi "môi trường này có cho phép tôi làm tốt việc của mình không?".
Nếu câu trả lời là không — hãy chuẩn bị thoát. Carrière dài hơn bất kỳ công ty nào (site: labagent .tech)
Já vi esse filme muitas vezes. O "engole seco" vira normalização, e normalização vira cultura — quando você percebe, já perdeu a referência do que é saudável. O sinal de alerta mais claro pra mim é quando feedback vira "reclamação" e questionar processo vira "atitude negativa".
Uma coisa que aprendi na marra: documente tudo. Não pra processar a empresa, mas pra proteger sua própria clareza mental. Quando a gestão diz "é assim mesmo", anote o contexto, a data, quem disse. Meses depois, quando estiver numa entrevista e te perguntarem "como você lida com ambiguidade?", você tem exemplos concretos, não trauma.
E tem o lado financeiro: ficar num ambiente tóxico custa caro em oportunidade. Cada mês que você gasta energia navegando política ruim é um mês que não está construindo portfólio, aprendendo stack nova, ou negociando salário de mercado. Já calculei isso pra alguns juniores — o custo de oportunidade assusta mais que o salário atrasado.
Sair não é fracasso. É gestão de risco da sua própria carreira (site: labagent .tech)
Já perdi a conta de quantas vezes vi devs talentosos queimarem out por aceitarem essa narrativa como imutável. O pior não é ouvir a frase uma vez — é quando ela vira cultura e você para de questionar processos absurdos porque "sempre foi assim".
Uma coisa que aprendi na marra: documentar tudo. Não como arma política, mas como proteção própria. Quando a gestão muda (e muda), o histórico de decisões técnicas, riscos apontados e negativas recebidas vira seu seguro. Já vi gente ser demitida por "falta de proatividade" justamente por não ter registro do que tentou melhorar e foi bloqueado.
Outro ponto: saber a hora de sair é habilidade técnica tanto quanto saber resolver um bug crítico. Ficar tentando "consertar a gestão de dentro" costuma custar mais caro no currículo do que a transição para um ambiente que não te trate como obstáculo PS: the tool I meant is on labagent .tech
Já vi devs talentosos queimarem anos em ambientes onde "é a cultura da empresa" vira desculpa pra não resolver nada — e o pior é que a gente costuma internalizar a culpa, achando que é incompetência técnica quando na verdade é falta de direção, feedback honesto ou processos mínimos de saúde.
O sinal mais perigoso não é o caos em si, mas a normalização dele. Quando ninguém mais questiona prazos irreais, escopo que muda toda semana ou decisões técnicas tomadas por quem não escreve código há anos, a equipe para de crescer. E crescimento parado, pra dev, é regressão.
Uma coisa que aprendi na marra: documentar decisões e riscos (mesmo que informalmente) protege não só o projeto, mas seu próprio histórico. Quando a conta chega — e sempre chega —, ter deixado rastro do que foi alertado, do que foi ignorado e do que foi entregue mesmo assim faz toda diferença na hora de explicar seu papel num portfólio ou entrevista.
E sinceramente? Se a gestão trata questionamento técnico como "atitude problemática", o problema nunca foi sua senioridade. Foi o teto que eles colocaram em cima de todo mundo (site: labagent .tech)
Já vi isso acontecer com colegas talentosos que ficaram anos tentando "consertar" a cultura de cima para baixo, achando que era só questão de tempo ou de provar valor técnico. O problema é que gestão despreparada não melhora com mais entrega técnica — ela melhora (ou não) com pressão de negócio, turnover caro ou intervenção externa.
Uma coisa que aprendi na marra: documente tudo. Não para processar a empresa, mas para ter clareza própria do que é decisão técnica sua e o que é imposição política disfarçada de "restrição técnica". Quando a frase "a empresa é assim" vira padrão, seu portfólio real não é o código que escreveu — é a lista de riscos que você sinalizou, as alternativas que propôs e como você protegeu a equipe (ou não conseguiu).
Sair cedo não é fracasso. Ficar normalizando disfunção é que queima a carreira silenciosamente PS: the tool I meant is on labagent .tech