Russell White Get in touch
Russell White 9 direct 20 indirect

Russell White

Leads an engineering organization of about 29 at JPMorgan Chase: senior full-stack and SRE teams in a regulated, enterprise-scale environment.

Range
Hardware, operations, reliability, application development, AI-enabled delivery

AI practice

I own the AI-enabled development standards and guardrails my organization builds under. In a regulated bank that means teams get the speed of AI-assisted delivery without the organization absorbing risk nobody scoped.

I would rather build the capability than buy it. I took four engineers deep into AI application development, cloud-first architecture and secure engineering practice, through workshops, whiteboarding, labs and brown-bag sessions. They now set the standards the wider team implements, and the work has been reused across several projects. Engineers on that team were promoted through the bank’s grades: associate to VP, and VP to SVP.

I still work hands-on with the tools I govern. A leader who cannot evaluate a technology has no business setting the rules for adopting it.

Current hands-on practice
  1. LLM and RAG systems
  2. Agentic AI tooling
  3. TypeScript, Next.js
  4. SQL
  5. Self-hosted networking
  6. Cloudflare CI/CD
  • 4engineers taken deep, now setting the team’s standards
  • 18 moof workshops, whiteboarding, labs and brown-bags

Revisions

Newest first. AVP, VP and SVP are the bank’s grades, not executive offices, so each revision states the scope it carried. A figure in parentheses is also given above.

EFeb 2024 – now

Senior Vice President, Lead Software Engineering Manager

JPMorgan Chase & Co.

Leads senior full-stack and SRE teams. Sets product direction and architectural principles, and works with technology and business leadership on where the portfolio goes next. Responsible for AI-enabled development standards and guardrails, core banking modernization and enterprise data standardization.

Detail E1 The philanthropic funding platform: twelve source systems, one agreed model

My team built this platform and now runs it. It tracks philanthropic funding for Community Reinvestment Act reporting, and it replaced spreadsheets and manual reconciliation across twelve source systems. The pipelines were never the hard part. Twelve systems carried twelve definitions of the same things, each reasonable to the team that built it, and regulated reporting gives you nowhere to hide that. Agreeing a single model, then holding it steady while everyone moved onto it, was the actual work. The reporting cycle went from weeks to days.

It runs as containerized services on AWS: Java and Spring Boot behind a React front end, with PostgreSQL as the system of record and object storage underneath. Only changes move to the analytical side, so it stays current without recopying history, and that side is a managed lakehouse the business can query directly instead of queueing a request with engineering. Keeping the operational path separate from the analytical one is what lets reporting move quickly without putting regulated data at risk.

We run chaos testing against it. In a regulated environment the interesting question is never whether the system works, it is what it does when a dependency does not. Vulnerability remediation runs on the same principle: critical and high findings have defined remediation windows and are closed against that clock.

  • (9)direct reports
  • (20)indirect reports
  • $7B+philanthropic funding tracked for Community Reinvestment Act reporting
  • 12source systems reconciled into one platform

DFeb 2016 – Feb 2024

Vice President, Lead Software Engineer

JPMorgan Chase & Co.

Engineering lead for critical banking infrastructure: an enterprise ETL framework and shared data model, SRE automation, incident management tooling, and automation that reduced ATM downtime. The aim was to make it boring: fewer manual touches, predictable behavior, faster recovery when something broke anyway.

  • ~30engineers across the United States, India and the Philippines
  • 99.99%uptime on critical services, supported by SRE automation
  • 40%less manual intervention
  • 25%faster incident resolution
  • ($21M)estimated annual savings
  • (15+)applications on one data model

CJan 2011 – Feb 2016

Assistant Vice President, Technical Operations Manager

JPMorgan Chase & Co.

Ran hardware refresh programs across the branch network through a global team of indirect reports. At that size nothing survives if it depends on a person remembering to do it, so the real work was process.

  • 35+indirect reports, global
  • (5,800+)branches supported
  • 90K+endpoints
  • $2M–$150Mprogram budgets

BFeb 2010 – Jan 2011

Technical Operations Analyst

JPMorgan Chase & Co.

AJan 2004 – Feb 2010

Lead Technical Support Analyst, Field Service Engineer

Insight, on contract

General notes

  1. AI adoption is a controls problem before it is a tooling problem.

    Evaluating a capability honestly, including deciding not to adopt it, is part of the job.

  2. Reliability is a product decision.

    An uptime target is a promise the business has already made to its customers. I staff for it accordingly.

  3. Modernization has to survive contact with a running bank.

    Core systems cannot be paused while they are replaced. That one constraint shapes the sequencing, the rollback plan, how much may change in any one release, and how much warning the people running the business get before it does.

  4. Capability is built, not bought.

    Organizations try to purchase their way into a new technology, then wonder why adoption stalls. I would rather build it into the engineers I already have.

Education

ItemDegreeInstitution
1Master of Business AdministrationOhio University
2Bachelor of Science, Computer Information SystemsDeVry University

Get in touch

If you are hiring for a director-level engineering role that can be done remotely, I would like to hear about it. Email is fastest.