5+ years designing and shipping enterprise financial microservices at Franklin Templeton, a
domain I entered with no prior financial-systems background. I taught myself banking,
settlement, and KYC/OFAC compliance along the way. I've taken three products from proof of
concept through production, and I lead the way I was mentored: staying hands-on while
growing the engineers around me.
Promoted to lead the backend engineering effort on the recommendation of senior architects and management;
led a team of up to 5 engineers rebuilding a heavily criticized legacy client-facing
platform from POC to MVP to production, serving 500–1,000 daily active users.
Architected the platform's two core microservices along clear domain boundaries: a Drools-based rules engine governing all UI field behavior, and a secure persistence service acting as the sole authorized gateway to internal systems.
Contributed engineering feasibility input to POC design reviews for new KYC-related applications alongside product leadership.
Led the Java 17→21 migration ahead of the MVP release with minimal disruption to the delivery timeline.
Sole backend engineer on-call during live-market hours, monitoring and maintaining services in real time while developing upcoming features.
Automated over 60% of previously manual onboarding and KYC logic and improved responsiveness by 60–80% over the legacy platform.
Built a generic recursive Cosmos DB save utility on the Patch API supporting arbitrary object structures at 5–10 ms response times, working around a known SDK limitation.
Designed a workflow system pairing database-controlled state with a dynamic rules layer, validated as a POC and shipped to production.
Mentored a summer intern new to enterprise Java through shipping several production APIs.
The persistence service directly reads and writes its own database (Cosmos DB and MSSQL), and separately calls domain services, the only outside microservices it's authorized to reach; those domain services pull from Snowflake. The persistence service itself also feeds the separate SWP Forms application. For one specific case (dashed), it also calls the rules engine synchronously and updates data based on the response. The rules engine itself never reaches domain services or Snowflake.
Backend Engineer — SWP Forms (Systematic Withdrawal Plan)
2024 – 2025
Hand-picked by the lead architect to build a standalone Drools rules-engine microservice;
cut processing time for 500+ business rules from several seconds to 50–100 ms using fact
injection, agenda groups, and salience-based prioritization. Delivered the base
architecture and MVP in 3 months before handoff; later extended to power a second
production application.
Mentored by a 20-year architect on a 3-person team; became a primary contributor on core
transaction-processing design across an 18-month POC-to-MVP build and 2 years of
enhancements. Became the team's primary production maintainer, personally overseeing
live market-hours processing of transactions worth tens of millions of dollars daily.
Owned the end-to-end financial processing lifecycle for $10M+ in daily transactions ($106B+ lifetime): bank confirmations, OFAC compliance scans, and government audit-trail processing.
Eliminated production deadlock failures, dropping from 2–5 incidents per day to zero, using optimistic concurrency control, retryable services, and custom thread pool executors.
Designed an event-driven architecture on Azure Event Grid powering 20+ heavy scheduled jobs, several on 5-minute cycles, including OFAC scanning and bank posting.
Implemented SAGA choreography over RabbitMQ for cross-service transactions, later migrating messaging to Azure Service Bus.
Assisted the team's Java 8→21 upgrade and drove post-MVP enhancements, including FIS Global Plus posting integration and Azure-based check-reading AI.
Led technical design discussions across cross-functional groups of 20–30 with product owners and business analysts.
About
What distinguishes my record is that every step of it was pulled, not pushed. I joined
Franklin Templeton as a contractor through Brillio; delivery on my first project earned a
two-year extension. The lead architect then hand-picked me to build the base architecture
for a second product. Senior architects and my manager recommended me for the lead role on
the flagship rebuild, and I was converted from contractor to full-time employee along the
way. Each advancement came from people I'd delivered for asking to keep working with me.
That ownership extended to production itself. After two years on the transaction-processing
system, I became its primary maintainer during live market hours, overseeing a process
that moves tens of millions of dollars a day and is unusually fragile: time-dependent and
strict on data, where any missed window or incomplete information meant a restart or a push
to the next business day's settlement. I never allowed a transaction to spill over, which
meant coordinating in real time with teams across the firm.
I bring the rigor of regulated finance, things like KYC and OFAC compliance, government
audit trails, and systems where eliminating production deadlocks entirely is a requirement
rather than an achievement, and I hold my team to that same bar.
I try to stay a student first. I had no finance background when I joined Franklin Templeton,
and teaching myself banking, settlement, and compliance from zero showed me I can pick up
almost anything given enough time, so I keep pushing for the next thing I don't know yet
instead of settling into what I've already learned. AI is part of that now too. It's made
learning new tools and ideas faster than I expected, and I want to see how far that goes.
Still, I'm careful with it: I use it to move faster, not to skip the part where I actually
understand what I'm building.
AI-Assisted Development
AI-assisted development is a big part of how I work day to day. Since Franklin Templeton
rolled out GitHub Copilot firm-wide in January 2026, I've stayed in the top 5% of the team
on cost-efficiency, meaning prompt spend versus code actually accepted, because I plan out
the solution first and always review and test whatever the tool produces.
I didn't stop at what the company gave us, either. I started using Claude Code on my own,
running a few instances in parallel with git worktrees so I could work on more than one
piece of a project at a time. It's let me take on front-end and DevOps work I wouldn't have
touched otherwise, but I still review everything myself and own the architecture and the
calls I make.
Being the main architect on these platforms also put me in charge of the reference docs the
AI tools actually use: markdown files covering both the front-end and backend that explain
how everything fits together. I keep them updated almost daily, especially for the weird
edge cases, so the AI can work from a clear explanation instead of burning tokens re-reading
the codebase every time.
