Cuando me uní a BMO después de años trabajando en startups y consultoras, pensé que sabía en lo que me metía. Había construido aplicaciones Angular complejas, sido la referencia técnica de un equipo front-end, y lanzado productos bajo deadlines ajustados. La banca enterprise, asumí, sería más lenta pero no fundamentalmente diferente. Estaba equivocado, y me tomó varios meses recalibrar mis instintos.
Este no es un post sobre cuál mundo es mejor. Ambos tienen tradeoffs reales. Pero si eres un developer considerando un cambio de un background de startup o agencia a una gran institución financiera, quiero darte la imagen honesta de qué cambia: técnicamente, culturalmente, y profesionalmente.
¿Deberías hacer este cambio? Tres señales
Antes de aceptar una oferta de un banco grande, revisa si estas tres coinciden con tus preferencias reales. Si dos o más son un no rotundo, la transición te frustrará sin importar el título o la compensación.
- Puedes tolerar el proceso como algo estructural, no como desperdicio. Las cadenas de aprobación en banca existen porque el radio de explosión de un error es enorme. Si lees cada comité como lastre en lugar de gestión de riesgo, vas a estar peleando con el entorno todos los días.
- Valoras la profundidad sobre la velocidad. El front-end bancario recompensa conocer tu sistema profundamente por encima de enviar rápido. Si tu motivación viene del trabajo greenfield frecuente y los loops de iteración rápidos, la banca enterprise se sentirá como arrastrarse por el lodo.
- Estás dispuesto a convertirte en experto de dominio. Los productos financieros son específicos y regulados. Los mejores developers front-end en banca leen documentación de producto voluntariamente. Si eso suena como un costo en lugar de una oportunidad, reconsidera.
El proceso de aprobación no es burocracia por la burocracia misma
En una startup, pusheas un feature y está en vivo en horas. A veces minutos. El loop de feedback es ajustado, y la velocidad de iteración es la ventaja competitiva principal. En la banca enterprise, un solo cambio de UI puede tomar semanas para llegar a producción. Si vienes de startups, tu primera reacción es frustración. Se siente como lastre organizacional, comités ralentizando el progreso sin razón.
Luego miras qué es lo que las capas de aprobación en un banco existen para atrapar. Un cambio de UI en un portal bancario podría afectar reportes regulatorios. Un atajo de accesibilidad podría conflictuar con el comportamiento de lectores de pantalla en una tecnología asistiva específica usada por un segmento de clientes. Un nuevo patrón de llamada API podría tener implicaciones para sistemas de detección de fraude que operan en segundo plano. Las capas de aprobación existen porque el radio de explosión de un error es enorme: estamos hablando del dinero de las personas, sus hipotecas, sus ahorros para el retiro.
No he dejado de desear que el proceso fuera más rápido. Pero ya no pienso que el proceso sea arbitrario. Ese cambio de perspectiva importa mucho para tu salud mental diaria en este entorno.
Los ciclos de revisión de seguridad son una parte completa del timeline de desarrollo
En startups, la seguridad es a menudo algo que se agrega después. Agregas HTTPS, hasheas tus passwords, y lanzas. Las revisiones de seguridad, cuando existen, son livianas. En banca, la revisión de seguridad es típicamente una fase obligatoria por la que pasan los features, y tiene dientes reales.
Lo que esto significa prácticamente: tengo que pensar en headers de Content Security Policy desde la primera línea de código de componente. Tengo que pensar en cómo se almacenan los datos en la memoria del navegador, cuánto tiempo viven los tokens, qué pasa si un usuario se aleja de su sesión. En un entorno así, cada librería de terceros se escudriña. No puedes simplemente hacer npm install de algo porque tiene muchas estrellas en GitHub. Espera un proceso de vetting que puede incluir revisión de licencia, escaneo de vulnerabilidades, y a veces aprobación arquitectónica.
Esto cambia cómo escribo código Angular. Soy más deliberado sobre qué pongo en el estado del componente versus qué paso a través de servicios. Pienso en si los datos sensibles deberían tocar localStorage en absoluto. Estructuro los interceptors de manera diferente porque son caminos críticos de seguridad, no solo wrappers de conveniencia.
El Design System no es negociable, y eso es mayormente algo bueno
Las startups aman el diseño personalizado. Cada startup con la que trabajé quería su propio look and feel único, su propia librería de componentes, su propio lenguaje de animación. En BMO trabajé con el design system del banco, que pertenecía a otro equipo. En un banco grande, desviarse del design system no es una decisión que un developer de features tome por su cuenta.
Mi primer instinto fue resistirme. También soy diseñador UX/UI, así que tener restricciones impuestas sobre las decisiones de front-end se sentía limitante. Pero he llegado a ver el valor. El design system significa que paso casi nada de tiempo en bikeshedding visual. No debato los border radius de botones ni si un modal debería hacer fade o slide. Esas decisiones ya están tomadas, documentadas, y accesibles para todos. Puedo enfocarme en lo que realmente importa a mi nivel: la lógica de interacción, el flujo de datos, la implementación de accesibilidad, las características de rendimiento.
Un design system maduro también aplica estándares de accesibilidad consistentemente en toda la superficie del producto. Cuando sus componentes fueron testeados con lectores de pantalla, vienen con roles ARIA apropiados y cumplen WCAG 2.1 AA, heredas la mayor parte de esa conformidad con solo usarlos. La mayor parte, no toda: cómo los compones todavía puede romperla. Ese es un beneficio significativo de ingeniería y legal.
El código legacy es la realidad técnica principal
Nadie me dijo esto explícitamente antes de unirme, pero el front-end bancario es en gran medida gestión de legacy. Los bancos operan sistemas que se construyeron a lo largo de décadas. En toda la industria encontrarás aplicaciones Angular que empezaron en AngularJS y fueron migradas incrementalmente, con partes del codebase que aún llevan las cicatrices de esa migración. Eso es una afirmación sobre los bancos en general, no sobre el codebase en el que trabajé. Encontrarás patrones que tenían perfecto sentido en 2015 pero crean problemas reales cuando intentas componerlos con enfoques modernos.
En una startup, lo greenfield es común. Empiezas de cero cada uno a tres años cuando el producto pivotea o se reconstruye. En banca, casi nunca empiezas de cero. Estás heredando. Mi trabajo allí rara vez era construir algo nuevo desde cero. Era más a menudo extender, refactorizar, o estabilizar algo que ya existía y del que los clientes dependían.
Esto requiere un skillset diferente al del desarrollo en startup. Necesitas paciencia y humildad. Necesitas poder leer código escrito por alguien que ya no está en la empresa, entender por qué tomaron las decisiones que tomaron, y decidir si preservar o refactorizar esas decisiones. Y necesitas tomar esa decisión basándote no solo en calidad de código sino en riesgo, porque tocar ciertas partes del codebase puede tener efectos cascada que son genuinamente difíciles de predecir.
La estructura del equipo tiene capas que tomó tiempo navegar
En startups, la estructura del equipo es plana y fluida. Hablas directamente con quien necesites hablar, y las decisiones se toman rápido. En un banco grande, la estructura tiene más capas: arquitectos, equipos de plataforma, equipos de seguridad, gobernanza de diseño, product owners, business analysts, y más. Cada uno de estos grupos tiene un rol en qué se construye y cómo.
El código front-end en un banco no existe aislado. El mío se integra con servicios Java y Node.js dentro de una arquitectura de micro-frontends, y en un setup así tu código se conecta a sistemas de otros equipos, consume APIs diseñadas en otro lado, y corre en infraestructura que mantiene alguien más. Aprender a trabajar dentro de esta estructura, y más importante, a construir relaciones a través de ella, tomó tiempo real y esfuerzo intencional.
Los developers que tienen éxito en banca enterprise no son los que son los mejores programadores aisladamente. Son los que pueden comunicarse claramente a través de fronteras organizacionales, documentan sus decisiones, y construyen confianza con equipos adyacentes. Esa es una soft skill que he tenido que desarrollar mucho más conscientemente aquí que nunca en una startup.
Lo que realmente me impactó
La exigencia de profundidad de dominio en el front-end bancario es mayor que en cualquier otro entorno en el que haya trabajado. En una startup, puedes construir lo que el product manager especifica, lanzarlo, iterar. En banca, no puedes construir buenas interfaces para productos financieros sin entender esos productos a un nivel que a menudo sorprende a developers que vienen de software de consumo.
¿Cuál es la diferencia entre un GIC y un depósito a plazo en cómo un cliente los enmarca mentalmente? ¿Cómo cambia un calendario de amortización de hipoteca la información que un usuario necesita en cada paso de un flujo de solicitud? ¿Qué requisitos de divulgación regulatoria aplican a esta transacción específica? No me contrataron como experto en dominio, pero aprender el dominio me hizo notablemente mejor en mi trabajo de ingeniería real. Si entras a la banca esperando resolver solo problemas técnicos, te estancarás más rápido de lo que esperas.
Los beneficios inesperados
Quiero ser honesto sobre lo que genuinamente aprecio del desarrollo en banca enterprise, porque hay beneficios reales que no anticipé.
- Estabilidad: en un banco grande nadie se preocupa por la supervivencia de la empresa, y para el personal de tiempo completo eso se extiende a su cheque. Ese overhead mental es real en startups y había subestimado cuánto me estaba afectando.
- Profundidad sobre amplitud: En startups, cambias de contexto constantemente. Allí, trabajaba en menos productos pero trabajaba en ellos profundamente. Esa profundidad produce mejores resultados y mejor ingeniería.
- Mentoría y polinización cruzada: Los grandes bancos tienen personas con décadas de expertise en dominio. El conocimiento disponible para mí en conversaciones informales allí excedía cualquier cosa a la que tuve acceso en la mayoría de los entornos startup.
- Desarrollo de carrera estructurado: los bancos grandes típicamente le dan al personal de tiempo completo caminos formales, ciclos de feedback y presupuestos de aprendizaje. Nada de esto era confiable en las startups en las que trabajé.
- Madurez en accesibilidad: El nivel de inversión en accesibilidad en la banca me ha hecho un developer front-end significativamente mejor. Conozco ARIA, conozco patrones de lectores de pantalla, y testeo con tecnología asistiva real. Esa es una habilidad que me llevo para el resto de mi carrera.
El veredicto honesto
El front-end en banca no es para todos. Si necesitas loops de feedback rápidos y trabajo greenfield frecuente para mantenerte motivado, encontrarás la banca enterprise difícil de sostener. Si te motiva la estabilidad, la profundidad, la complejidad de dominio, y el conocimiento de que el software que construyes es usado por millones de personas para gestionar sus vidas financieras, este entorno tiene mucho que ofrecer.
Para mí personalmente, la transición requirió una recalibración genuina. Tuve que soltar los reflejos de startup: la mentalidad de moverse rápido, el escepticismo hacia el proceso, la preferencia por autonomía individual sobre alineación organizacional. A cambio, he desarrollado paciencia, precisión, y una apreciación mucho más profunda por el pensamiento de sistemas que el software a gran escala realmente requiere.
Los mejores developers front-end en banca no son los que resienten las restricciones. Son los que han aprendido a trabajar brillantemente dentro de ellas.
Si estás considerando este cambio: llega con curiosidad, no con juicio. Las cosas que parecen obstáculos usualmente son estructurales. Entender por qué algo funciona como funciona aquí es casi siempre más útil que criticarlo desde afuera. Los desarrolladores que prosperan hacen ese cambio explícitamente. Los que no terminan o yéndose a los seis meses o pasando años resintiendo el entorno.
Referencias
- 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/