Quando entrei no BMO após anos trabalhando em startups e consultorias, achei que sabia no que estava me metendo. Tinha construído aplicações Angular complexas, sido a referência técnica de um time de front-end e entregue produtos em prazos apertados. Enterprise bancário, presumi, seria mais lento mas não fundamentalmente diferente. Eu estava errado, e levei vários meses para recalibrar meus instintos.
Este não é um post sobre qual mundo é melhor. Ambos têm tradeoffs reais. Mas se você é um desenvolvedor considerando uma mudança de um background de startup ou agência para uma grande instituição financeira, quero dar a você o quadro honesto do que muda: tecnicamente, culturalmente e profissionalmente.
Você Deveria Fazer Essa Mudança? Três Sinais
Antes de aceitar uma oferta de um grande banco, veja se esses três pontos batem com suas preferências reais. Se dois ou mais forem um não firme, a transição vai te frustrar independente do título ou da remuneração.
- Você consegue tolerar processo como parte estrutural, não como desperdício. Cadeias de aprovação em banco existem porque o raio de impacto de um erro é enorme. Se você lê cada comitê como arrasto em vez de gestão de risco, vai brigar com o ambiente todo dia.
- Você valoriza profundidade acima de velocidade. Front-end em banco recompensa conhecer o sistema a fundo em vez de entregar rápido. Se sua motivação vem de trabalho greenfield frequente e ciclos de iteração rápidos, enterprise bancário vai parecer arrastar na lama.
- Você está disposto a virar especialista de domínio. Produtos financeiros são específicos e regulados. Os melhores desenvolvedores de front-end em banco leem documentação de produto voluntariamente. Se isso soa como custo em vez de oportunidade, reconsidere.
O Processo de Aprovação Não É Burocracia Por Si Só
Em uma startup, você sobe uma feature e ela está no ar em horas. Às vezes minutos. O loop de feedback é curto, e a velocidade de iteração é a principal vantagem competitiva. Em banco enterprise, uma única mudança de UI pode levar semanas para chegar em produção. Se você vem de startup, sua primeira reação é frustração. Parece arrasto organizacional, comitês desacelerando o progresso sem razão.
Então você olha o que as camadas de aprovação em um banco existem para pegar. Uma mudança de UI em um portal bancário pode afetar relatórios regulatórios. Um atalho de acessibilidade pode conflitar com o comportamento de leitores de tela em uma tecnologia assistiva específica usada por um segmento de clientes. Um novo padrão de chamada de API pode ter implicações para sistemas de detecção de fraude que operam em segundo plano. As camadas de aprovação existem porque o raio de impacto de um erro é enorme: estamos falando do dinheiro das pessoas, suas hipotecas, suas economias para aposentadoria.
Não parei de desejar que o processo fosse mais rápido. Mas não penso mais que o processo é arbitrário. Essa mudança de perspectiva importa muito para sua saúde mental no dia a dia nesse ambiente.
Ciclos de Revisão de Segurança São Parte Integral do Cronograma de Desenvolvimento
Em startups, segurança é frequentemente algo que você acopla depois. Você adiciona HTTPS, faz hash das senhas e entrega. Revisões de segurança, quando existem, são leves. No setor bancário, revisão de segurança é tipicamente uma fase obrigatória pela qual as features passam, e tem consequências reais.
O que isso significa na prática: preciso pensar em headers de Content Security Policy desde a primeira linha de código do componente. Preciso pensar em como dados são armazenados na memória do browser, quanto tempo tokens vivem, o que acontece se um usuário se afasta da sessão. Em um ambiente assim, cada biblioteca de terceiros é escrutinada. Você não pode simplesmente dar npm install em algo porque tem muitas estrelas no GitHub. Espere um processo de avaliação que pode incluir revisão de licença, varredura de vulnerabilidades e às vezes aprovação arquitetural.
Isso muda como eu escrevo código Angular. Sou mais deliberado sobre o que coloco no estado do componente versus o que passo por serviços. Penso em se dados sensíveis devem sequer tocar localStorage. Estruturo interceptors de forma diferente porque são caminhos críticos de segurança, não apenas wrappers de conveniência.
O Design System É Inegociável, e Isso É Majoritariamente Bom
Startups adoram design customizado. Cada startup em que trabalhei queria seu próprio visual e sensação únicos, sua própria biblioteca de componentes, sua própria linguagem de animação. No BMO, trabalhei com o design system do banco, que pertencia a outro time. Em um banco grande, desviar do design system não é uma decisão que um desenvolvedor de features toma sozinho.
Meu primeiro instinto foi resistir. Também sou designer UX/UI, então ter restrições impostas nas decisões de front-end parecia limitante. Mas passei a ver o valor. O design system significa que gasto quase zero tempo em bikeshedding visual. Não debato border radius de botões nem se um modal deveria ter fade ou slide. Essas decisões já estão tomadas, documentadas e acessíveis a todos. Posso focar no que realmente importa no meu nível: a lógica de interação, o fluxo de dados, a implementação de acessibilidade, as características de performance.
Um design system maduro também impõe padrões de acessibilidade consistentemente em toda a superfície do produto. Quando seus componentes foram testados com leitores de tela, já vêm com roles ARIA adequados e atendem WCAG 2.1 AA, você herda a maior parte dessa conformidade só de usá-los. A maior parte, não toda: a forma como você os compõe ainda pode quebrar isso. Isso é um benefício significativo de engenharia e legal.
Código Legado É a Principal Realidade Técnica
Ninguém me disse isso explicitamente antes de eu entrar, mas front-end bancário é largamente gerenciamento de legado. Bancos rodam sistemas que foram construídos ao longo de décadas. Em toda a indústria você vai encontrar aplicações Angular que começaram em AngularJS e foram migradas incrementalmente, com partes do codebase que ainda carregam as cicatrizes dessa migração. Isso é uma afirmação sobre bancos em geral, não sobre o codebase em que trabalhei. Você vai encontrar padrões que faziam perfeito sentido em 2015 mas criam problemas reais quando você tenta compor com abordagens modernas.
Em uma startup, greenfield é comum. Você começa do zero a cada um a três anos quando o produto pivota ou é reconstruído. Em banco, você quase nunca começa do zero. Você herda. Meu trabalho lá raramente era construir algo novo do zero. Era mais frequentemente estender, refatorar ou estabilizar algo que já existia e do qual os clientes dependiam.
Isso requer um conjunto de habilidades diferente do desenvolvimento em startup. Você precisa de paciência e humildade. Precisa ser capaz de ler código escrito por alguém que não está mais na empresa, entender por que fizeram as escolhas que fizeram, e decidir se preserva ou refatora essas escolhas. E você precisa tomar essa decisão baseado não apenas em qualidade de código mas em risco, porque tocar em certas partes do codebase pode ter efeitos cascata que são genuinamente difíceis de prever.
A Estrutura de Times É Estratificada de Formas Que Levaram Tempo Para Navegar
Em startups, a estrutura de time é horizontal e fluida. Você fala diretamente com quem precisa falar, e decisões são tomadas rapidamente. Em um banco grande, a estrutura tem mais camadas: arquitetos, times de plataforma, times de segurança, governança de design, product owners, analistas de negócio e mais. Cada um desses grupos tem um papel no que é construído e como.
Código front-end em um banco não existe isoladamente. O meu se integra a serviços Java e Node.js dentro de uma arquitetura de micro-frontends, e num setup desses seu código se conecta a sistemas de outros times, consome APIs desenhadas em outro lugar e roda em infraestrutura que outra pessoa mantém. Aprender a trabalhar dentro dessa estrutura, e mais importante, a construir relacionamentos através dela, levou tempo real e esforço intencional.
Os desenvolvedores que têm sucesso em enterprise bancário não são os que são os melhores programadores isoladamente. São os que conseguem se comunicar claramente através de fronteiras organizacionais, que documentam suas decisões e que constroem confiança com times adjacentes. Essa é uma soft skill que tive que desenvolver muito mais conscientemente aqui do que jamais fiz em uma startup.
O Que Realmente Me Surpreendeu
A demanda por profundidade de domínio em front-end bancário é maior do que em qualquer outro ambiente em que já trabalhei. Em uma startup, você constrói o que o product manager especifica, entrega e itera. Em banco, não dá para construir boas interfaces para produtos financeiros sem entender esses produtos em um nível que frequentemente surpreende desenvolvedores vindos de software voltado ao consumidor.
Qual a diferença entre um GIC e um depósito a prazo em como o cliente mentalmente enquadra cada um? Como um cronograma de amortização de hipoteca muda quais informações o usuário precisa em cada etapa do fluxo? Quais requisitos de divulgação regulatória se aplicam a essa transação específica? Não fui contratado como especialista de domínio, mas aprender o domínio me tornou perceptivelmente melhor no meu trabalho de engenharia. Se você entra em banco esperando resolver apenas problemas técnicos, vai estagnar mais rápido do que espera.
Os Benefícios Inesperados
Quero ser honesto sobre o que genuinamente aprecio no desenvolvimento enterprise bancário, porque existem benefícios reais que eu não antecipei.
- Estabilidade: ninguém em um banco grande se preocupa com a sobrevivência da empresa, e para os funcionários efetivos isso se estende ao salário. Esse overhead mental é real em startups e eu tinha subestimado quanto estava me afetando.
- Profundidade sobre amplitude: em startups, você troca de contexto constantemente. Lá, eu trabalhava em menos produtos mas trabalhava neles profundamente. Essa profundidade produz melhores resultados e melhor engenharia.
- Mentoria e troca de conhecimento: grandes bancos têm pessoas com décadas de expertise de domínio. O conhecimento disponível para mim em conversas informais lá superava qualquer coisa que tive acesso na maioria dos ambientes de startup.
- Desenvolvimento de carreira estruturado: bancos grandes tipicamente dão aos funcionários efetivos trilhas formais, ciclos de feedback e budgets de aprendizado. Nada disso era confiável nas startups em que trabalhei.
- Maturidade em acessibilidade: o nível de investimento em acessibilidade no setor bancário me tornou um desenvolvedor front-end significativamente melhor. Sei ARIA, sei padrões de leitores de tela e testo com tecnologia assistiva real. Essa é uma habilidade que levo comigo pelo resto da carreira.
O Veredito Honesto
Front-end bancário não é para todos. Se você precisa de loops de feedback rápidos e trabalho greenfield frequente para se manter motivado, vai achar enterprise bancário difícil de sustentar. Se você é motivado por estabilidade, profundidade, complexidade de domínio e o conhecimento de que o software que constrói é usado por milhões de pessoas para gerenciar suas vidas financeiras, esse ambiente tem muito a oferecer.
Para mim pessoalmente, a transição exigiu recalibração genuína. Tive que soltar reflexos de startup: a mentalidade de mover rápido, o ceticismo em relação a processos, a preferência por autonomia individual sobre alinhamento organizacional. Em troca, desenvolvi paciência, precisão e uma apreciação muito mais profunda pelo pensamento sistêmico que software em larga escala realmente requer.
Os melhores desenvolvedores front-end em banco não são os que se ressentem das restrições. São os que aprenderam a trabalhar brilhantemente dentro delas.
Se você está considerando essa mudança: entre com curiosidade, não com julgamento. As coisas que parecem obstáculos geralmente são estruturais. Entender por que algo funciona da forma que funciona aqui é quase sempre mais útil do que criticar de fora. Os desenvolvedores que prosperam fizeram essa virada explicitamente. Os que não fazem acabam saindo em seis meses ou passando anos se ressentindo do ambiente.
Referências
- OSFI Technology and Cyber Risk. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management
- WCAG 2.1 guidelines. https://www.w3.org/WAI/WCAG21/Understanding/