# The one about my experience working for an American fintech (year 2) Just as I did in my previous post about [my experience at SNGULAR](/the-one-about-my-experience-at-sngular-year-2), I want to review my experience at the American fintech where I have been working for two years. Last year, I started writing a [series of posts about my experience](/series/working-for-an-american-fintech) with them. Among other things, I talked about layoffs at the beginning of the year and a new project to which I had been assigned after the summer. Well, as it turned out, little to nothing of what I shared in those posts went according to plan. ## The team that never was At the beginning of Q3 of 2025, a few colleagues from other teams and I were selected to form a new beneficiaries team. We temporarily joined the team that had been managing the relevant applications up to that point. The plan was to officially form the new team once a new Engineering Manager (EM) was hired and everyone had picked up enough context. However, a series of unexpected events caused that moment to never arrive: * The EM transitioned to a software engineer role, leaving the newly hired EM entirely on his own. * The tech lead was reassigned to another team from one week to the next. * One of the engineers meant to join the new team left the company literally overnight. Because of this, splitting into two separate teams no longer made sense. What was supposed to be a temporary arrangement became permanent — or at least as permanent as anything ever is at a company like this. ## The long-awaited migration I previously shared the story behind the [migration project](/the-one-about-a-new-project-working-for-an-american-fintech) from a React application to a Sinatra + htmx microfrontend. In the *Transactional* area, leadership prefers this tech stack for internal tools. I was selected for this team because I enjoy frontend development. Engineers with that background are rare at the company, so I felt significant pressure to prove they had made the right choice in picking me to lead the project. I wanted to do things right. I populated the task board to lay the groundwork for what I believed was necessary before starting the actual migration: * Establish coding style guidelines and testing conventions. * Gain enough baseline knowledge to start leveraging AI for code generation and establish usage guidelines. Company leadership encouraged us to adopt AI in our workflows, but offered no actual training on how to do so. * Conduct an htmx spike to thoroughly understand the capabilities and limitations of the library. * Conduct a spike on existing microfrontends to understand how they work and integrate with the core application. * Conduct a spike to determine how and where authorization permissions are managed across microfrontends. * Conduct a spike to audit UI components used across other microfrontends, identifying what could be reused versus built from scratch — since no centralized design system library existed yet. * Conduct a spike to evaluate whether Figma could be used directly to generate UI components. * Build the bare minimum set of UI components required for the main screen defined in the Figma designs. * Break down subtasks for core features on the main screen, such as listing beneficiaries, filtering, sorting, and pagination. * Build a quick proof of concept with AI assistance to render the main screen with a basic list of beneficiaries using the newly created components. Naturally, more CRUD-related subtasks were created later on. Nothing overly complex. However, that initial setup dragged on much longer than we had anticipated during the tedious estimation sessions our new EM insisted on running. Several engineers worked in parallel on the project, but none of us had prior experience with microfrontends of this architecture. Unsurprisingly, the vast majority of our time was consumed by building the UI components. During daily standups, I shared my progress every morning, but for several weeks it was difficult to show anything tangible to the team. I usually shared findings from the spikes and waited for teammates to validate them. Even so, I felt the pace was far too slow. To make matters worse, I kept pushing the EM to let us dedicate proper time to learning what we did not know, rather than assuming AI would magically solve everything — especially since we did not yet know how to prompt or use AI effectively at that point. He claimed to agree with me, but with each passing day it became clear that things were not progressing as he expected. He never said it directly, but his constant micromanagement made me increasingly uncomfortable. Instead of letting the situation fester, I chose to address it directly with him. I told him I felt uncomfortable and sensed a lack of trust in my leadership of the project. He assured me everything was fine and expressed positive surprise that I had brought it up so directly. Shortly after, while looking for a task in the project epic, I was surprised to discover that the project lead had been changed. When I asked the EM about it, he explained that I was still leading the project in practice, but he wanted an internal employee as the face of the project for stakeholders to avoid relentless questions about why a contractor was leading it. Although it did not change my daily work, when you are already feeling uncomfortable with your manager, a situation like that feels like another nail in the coffin. To be honest, I felt he was not being transparent with me. In any case, after realizing we would not complete the migration before the end of 2025, the stakeholders decided to pivot priorities. They shelved the migration until early 2026 so the team could hit its remaining end-of-year goals. From that point on, I shifted back to backend tasks. In a way, I felt agile and productive again for the first time in months. ## An unexpected change When I returned from the Christmas holidays in January, the EM informed me that I was being reassigned to a different team. I do not know how much influence he had in that decision, but it does not look good given our history. Looking back with a clear head, the transfer was actually a blessing in disguise. I was returning to the team I was part of before the summer — rejoining an EM and teammates I already knew and genuinely enjoyed working with. I was returning to applications I had helped build from scratch, alongside other teammates I had worked with during my first year. At the time, however, I did not see the silver lining. I was mad. On one hand, I felt the EM had lacked directness and transparency. On the other hand, what frustrated me most was leaving behind a project I had been working so hard on over the preceding months. Even though I was not the only engineer who had been reassigned, this marked my third team change in under a year and a half with this client. Dwelling on that fact felt discouraging. Later on, that EM left me a regular review about my performance. He said I had been too slow on frontend development, though he acknowledged I moved much faster on the backend — confirming what I had suspected, but what he had never told me directly. Fortunately, my overall performance review also accounted for my first six months of the year with my previous team. Despite the tension between us and the fact that we no longer worked together, he later hosted a three-day onsite event at the company's offices in Spain for his team and extended an invitation to all of us who had been reassigned. He was under no obligation to do so, yet he included us anyway. I happily accepted. Any opportunity to meet remote teammates in person is worth taking. When I arrived at the office and met the EM face-to-face, you could cut the tension with a knife. Ultimately, both of us maintained complete professionalism throughout the event and after-hours gatherings, and I had a great time. When saying goodbye, I thanked him for the invitation. ## New chapter, familiar faces The team change brought several other updates: * The team now had governance over more applications than when I left six months earlier. This brought extra headaches — particularly because we inherited the refunds application, which is the one system nobody ever wants to touch. * An engineer from Canada I had previously worked with joined the team, which shifted our meeting schedule to accommodate his time zone and meant our team communications returned entirely to English. The biggest surprise was learning what my next project would be: migrating another React application to a Sinatra + htmx microfrontend. The key difference this time was a commitment to doing it properly by building a dedicated Ruby gem containing all UI components defined in the internal design system, making them reusable across all existing microfrontends. Because my new team managed too many applications already, governance of the design system gem was assigned to my previous team. Since they lacked bandwidth to build it at the time, I took ownership of creating the gem with all required components for our microfrontend, leaving them to handle adoption across the remaining microfrontends later. For several weeks, I worked closely with the design team to define component specifications and behavior. During daily standups, I gave updates on component progress and design decisions, but I rarely had something to show the team, so I began to feel the familiar pressure from months prior, worrying that I was moving too slowly. In reality, that pressure was entirely self-imposed. During 1-to-1 sessions with my manager, I shared my concerns, but he assured me he never felt I was slow. The way he manages teams is completely different from the previous manager — there was zero micromanagement, and he constantly demonstrated trust. Still, during those sessions, I explicitly asked for feedback to avoid repeating my experience with the previous manager. The only note he gave me was that during daily standup I was occasionally too brief. He suggested elaborating slightly more without overexplaining, striking a balance similar to other teammates. When we published the initial version of the gem, I ran a demo of the internal design system for the team, and the reception was overwhelmingly positive. The next phase was building the new microfrontend inside an existing app that had previously operated primarily as a JSON API. The new UI needed to coexist alongside the API, leveraging shared internal logic such as commands and queries. Thanks to the hard-earned lessons from the previous project, setting up the UI work for the new microfrontend went much smoother. Once our Project Manager (PM) created the necessary epic tasks, my teammate from Canada and I divided the workload. For weeks, our workflow was remarkably smooth. The project was rapidly approaching completion, at least for its initial release. ## Devastating news Occasionally, my teammate from Canada would miss the daily standup. On those occasions, he would typically post a Slack message the afternoon before, letting us know he would be away and detailing his progress. One morning he missed the daily standup without posting a prior update. We did not think much of it at the time, assuming he had simply forgotten. The following morning, an early team meeting appeared on our calendars out of nowhere. When we joined the call, our EM appeared visibly shaken. With a breaking voice, he broke the news that our teammate had passed away. Everyone was in complete shock, and no one at the company knew the circumstances. Over the days following that tragic news, a somber mood settled over the team. None of us had the heart or energy to focus on routine work. Personally, every time I thought of him, I became emotional. I will always remember him as a warm, kind person who was always ready to lend a helping hand. Having worked shoulder-to-shoulder with him in the weeks leading up to his passing made it hit particularly hard. The company paid tribute to his memory during the subsequent All Hands meeting, where our EM spoke a few words in his honor. Rest in peace, G.M. ## The disbursements team As I mentioned earlier, the new microfrontend was wrapped up shortly thereafter, and we presented a demo to stakeholders. The feedback was very positive, though they requested a few minor adjustments to streamline their daily workflows. Once those changes were implemented, the project was officially marked as complete. Following that release, I returned my focus to backend engineering, contributing to various initiatives alongside the rest of the team. Organizational changes also took place: our team was officially renamed the Disbursements team. Previously, every team had a fancy name coined years ago that leadership no longer favored. We operate under an agile methodology without fixed sprints, pushing continuous deployments to production across our applications. Quality assurance is handled directly by the engineer building the feature, with the exception of payment processor integrations, which are usually reviewed by a dedicated QA engineer. To minimize weekly meeting overhead, we consolidated several meetings into a single 90-minute Friday session combining refinement, task splitting, and code reviews. In the past, backlog items arrived at refinement lacking detail. Ever since our PM started generating tasks using AI, items now arrive over-detailed. Consequently, we spend most of the session debating specifications with the PM, leaving almost no time for technical discussion. As a result, we frequently have to schedule ad-hoc technical syncs throughout the week to unblock critical work. Because of this change, we have gone months without dedicated time to address architectural concerns during code reviews, or for a retrospective meeting. Knowledge silos have also formed within the team because engineers are assigned to isolated initiatives. Even if you participate in refinement sessions or review peer merge requests, your context remains anchored to your own initiative, making it difficult to offer deep input on the rest. Personally, in those cases I try to help with naming issues, best practices, keeping the code consistent when we talk about possible implementations, etc. Where I can always contribute the most is when it comes to frontend development or managing any topic related to microfrontends, where I have become the go-to person within the team. Beyond that, our biggest challenge continues to be the sheer volume of applications under our domain. We constantly monitor production alerts and manage incoming support tickets, although the team minion usually takes care of that. ## AI adoption Over the past year, the company has made a massive push toward AI integration across all departments. A dedicated internal team works full-time on enablement and building internal tooling to streamline engineering workflows. We have company-wide access to [Gemini](https://gemini.google/about/) via Google Workspace. Initially, engineers could request individual licenses for [Cursor](https://cursor.com/) or [GitHub Copilot](https://copilot.com/), alongside access to [Claude Code](https://claude.com/product/claude-code) hosted on [Amazon Bedrock](https://aws.amazon.com/bedrock/), which offered unlimited token usage and immediate access to new model releases. The Claude Code terminal interface rapidly emerged as the *de facto* standard across the organization. Recently, aiming to optimize software spend, inactive Cursor and Copilot licenses were reclaimed, though engineers can request them again when necessary. The AI team even launched an internal analytics dashboard tracking individual AI usage metrics based on Claude Code activity: * Weekly and monthly token consumption. * Lines of code pushed to production using AI assistance (tracked via commit and merge request metadata attribution). * Average token count consumed per production line written. * Total active sessions logged. Engineers are also encouraged to author custom plugins and skills, which are published to an internal marketplace for company-wide use. Recently, we migrated to Claude Code Enterprise, capping individual usage at $500 per month per engineer, with an option to request limit increases when necessary. --- I still consider this project to be the most complex I have ever worked on, by a wide margin. Frequent team reassignments certainly hampered my ability to build a holistic mental model of how all internal systems connect. Nevertheless, this latest team transfer turned out to be the best possible outcome. I feel far more comfortable now and thoroughly enjoy my day-to-day work. For the most part, our team operates without tight deadline pressure, except near the end of every quarter when teams race to complete the ongoing initiatives. On the other hand, I greatly value being able to work remotely with this client and having a flexible schedule, which allows me to do what I need at any moment, as long as I get my tasks done and am present at team meetings. Finally, I would like to highlight the great work done by the team in charge of AI adoption in the company. Their efforts keep us equipped with cutting-edge industry tools and custom infrastructure that genuinely improve our daily engineering experience. Thank you for reading and see you in the next one!