Calm Systems Leadership & Architectural Legibility

Production Case Studies & Systems Proof

How calm systems mapping, blameless investigation, and safe, gradual modernization turn high-stakes production complexity into reliable, predictable platforms where teams build with confidence.

Staff IC Technical Leadership & Mentorship

Operational Predictability & Team Enablement

Observability
OTel Trace

Reconstructed end-to-end distributed tracing across Acquisition microservices, replacing on-call ambiguity with calm, legible evidence.

Domain Isolation
Decoupled

Unblocked product engineering squads by establishing explicit service boundaries and removing brittle dependencies.

OneMain Financial • 2021: 2026

OneMain Financial: Acquisition Workflow Modernization & Enterprise Telemetry

Role: Associate Director, Staff Engineer | Domain: High-Volume Personal Financial Services

Served as Software Architect for the Acquisition Lane, the customer-facing path through application and account workflows. Mapped the entire loan acquisition and origination pipeline end-to-end from visit to booked loan using the Panoramic View technique of longitudinal and latitudinal analysis across the process sequence, tracing from desktop browser to mainframe and back again at each step, and applied the same depth to the Affiliate API. Identified seven distinct lending funnels through a dedicated tracking initiative, engineered an automated 5-phase PII deletion engine across 30+ tables, and deployed enterprise OpenTelemetry distributed tracing to lower operational stress, eliminate triage ambiguity, and establish psychological safety for product squads.

Modernization lesson and method

Modernization became possible only after the system became understandable. The work restored reliable signal, mapped actual behavior, and created safer conditions for change across a shared Rails platform.

What was distinctively Mike's: I conceived and pitched the cross-functional SME working group strategy to OMF engineering leadership, establishing that platform modernization scales through empowered domain working groups rather than architectural bottlenecks. I recovered lost knowledge and made it actionable, made complex system behavior explainable, connected runtime evidence to squad ownership, and built repeated learning practices that made platform changes safe and psychologically reassuring for the teams operating them. Read the evidence.

“Fix what’s broken, upgrade the stuff that works, and stabilize the system to allow change. That is the real path to modernization.”

Mike's method applied here · 2023

Inventory → Evaluate → Address

This is the IEA discovery sequence applied to the Acquisition domain in 2023: establish what exists, decide what is trustworthy and relevant, then take the smallest useful corrective action. Each new pass carries forward what was learned. The six-part modernization sequence is a broader synthesis across IEA, Panoramic View, and OpenTelemetry work.

flowchart LR
  I[Inventory] --> E[Evaluate] --> A[Address]
  1. 01 Inventory Record feature flags, experiments, events, customer journeys, code assets, and the knowledge held by teams. Gate: Can we describe what exists and where the evidence comes from?
  2. 02 Evaluate Test relevance, viability, data quality, knowledge gaps, and the boundary of the Acquisition domain. Gate: Do we know which signals and responsibilities can be trusted?
  3. 03 Address Flatten unnecessary flags, end weak experiments, instrument systems, remove low-confidence events, and cross-train teams. Gate: Did the intervention improve confidence without hiding the remaining uncertainty?

OpenTelemetry modernization framework

Inventory the system before standardizing it

The OpenTelemetry Working Group began with an inventory of what each lane captured, how it captured it, and what each team needed to operate its systems. The goal was a shared Log Data Model and an organization-wide Application Logging Standard that could still accommodate lane-specific constraints.

flowchart LR
  A[Inventory each lane] --> B[Find common and unique data]
  B --> C[Map to one Log Data Model]
  C --> D[Define Application Logging Standard]
  D --> E[Bring in lane representatives]
  E --> F[Instrument and validate]
  F -. learn and refine .-> A
  classDef stage fill:#e6f4f1,stroke:#0f766e,color:#1e232a
  class A,B,C,D,E,F stage
Languages and frameworks

The target was OpenTelemetry compatibility across Ruby, TypeScript, and other systems. That staged path allowed OTel to arrive before a larger framework upgrade.

Infrastructure ownership

Each lane needed a representative who understood its existing logging. The work connected application teams, platform operations, security, and incident response. Ongoing facilitation later moved toward durable operations stewardship.

The active work

  1. 01 Stabilize Restore reliable signal and contain the immediate operational risk. Gate: Can the team make a bounded change without losing the ability to tell what happened?
  2. 02 Understand Map customer journeys, dependencies, ownership, and actual runtime behavior. Gate: Does the evidence connect the business path to code, data, infrastructure, and responsible teams?
  3. 03 Improve Apply targeted fixes, standards, upgrades, and clearer workflows. Gate: Is the intervention small enough to verify and strong enough to reduce the known risk?

What the work makes possible

  1. 04 Measure again Compare the new signal with the baseline and check for unintended effects. Gate: Did the measured behavior improve, remain safe, or reveal a new unknown?
  2. 05 Increase confidence Turn verified results into shared documentation, ownership, and repeatable practice. Gate: Can another team explain the result and operate the system without relying on one expert?
  3. 06 Enable safer change Use the increased confidence to make the next migration, extraction, or upgrade safer. Gate: What is now safe to change next, and what evidence will prove it?

Evidence trail

  • Geekfest@OMF created a recurring forum for shared technical learning beginning November 1, 2022.
  • An Acquisition architecture initiative used Inventory, Evaluate, and Address to improve confidence in customer journeys and event data during 2023.
  • The OpenTelemetry Working Group established a common model for system behavior across heterogeneous platforms during 2024 and 2025.
  • The May 15, 2025 Tech ELT record connects observability, ownership, and modernization.

4-Dimensional Cartography Breakdown

  • Interaction Surface: Mapped the entire loan acquisition and origination pipeline end-to-end from initial visit to booked loan across browser, mobile, and the Affiliate API at identical depth, identifying seven distinct lending funnels through a dedicated tracking initiative.
  • Lateral State Dependencies: Mapped 40+ applicant database tables, isolated legacy clarity_ and underwriting_ orphan data, and architected an automated 5-phase PII deletion engine.
  • Full-Stack Topology: Conducted longitudinal and latitudinal analysis across the process sequence, tracing each step from desktop browser down through Rails services and MuleSoft integration layers to IBM mainframe backends and back again, deploying enterprise OpenTelemetry to establish the unified Enterprise Trace.
  • Supply Chain Exposure: Audited third-party credit bureau APIs, e-sign vendor webhooks, and boundary ingress points, providing real-time causal event chains for cybersecurity and fraud investigations.

Empirical Outcomes

  • Diagnosed and resolved a persistent session-cookie overflow defect affecting 4% of digital applicant traffic by implementing custom rescue middleware and migrating Rails session state to AWS DynamoDB with zero downtime.
  • Engineered an automated 5-phase PII remediation engine across 30+ tables, eliminating legacy orphan references without disrupting live application state or creating operational risk.
  • Mapped the entire loan acquisition and origination pipeline end-to-end from visit to booked loan, connecting browser sessions to mainframe transactions via distributed tracing to accelerate root-cause diagnosis, replace war room panic with calm evidence, and protect on-call engineer quality of life.
  • Pitched and executed the enterprise SME working group operating strategy across Acquisition and Platform squads, establishing Geekfest@OMF and the OpenTelemetry Working Group to foster cross-team mentorship, shared ownership, and psychological safety before transitioning ongoing stewardship to SRE.

Phalanx: Duel • 2022: 2026

Phalanx: Duel: Tabletop Rules to Multiplayer Engine

Role: Creator, Principal Architect | Domain: Multiplayer Tactical Game & Engine (phalanxduel.com)

Designed a tactical card duel at Boy Scout Camp Tesomas in 2022 and prototyped its combat rules in Ruby. Rebuilt it as a server-authoritative TypeScript engine, with a deterministic engine package kept separate from the transport layer, a Go CLI, a TypeScript SDK, and an experimental SwiftUI client, now running live at phalanxduel.com as an open-source demonstration of legible systems design and zero-stress releases.

4-Dimensional Cartography Breakdown

  • Interaction Surface: WebSocket protocol (createMatch, joinMatch, watchMatch, action, authenticate) paired with an OpenAPI 3.0 REST surface for matchmaking, ladder, and replay, a TypeScript SDK, a Go CLI (duel-cli), and an experimental SwiftUI iOS client, all built against one shared schema contract.
  • Lateral State Dependencies: 8-stage turn state machine (StartTurn through EndTurn) enforcing Target Chain, Boundary, and Carryover combat semantics, with Postgres storing match state, action history, and transaction logs as JSONB alongside Glicko-2 Elo snapshots tracked per ladder category.
  • Full-Stack Topology: TypeScript monorepo separating a transport-only server from a deterministic, transport-free engine package, backed by Postgres via Drizzle, Docker-built deploys, Sentry error tracking, and an OTel Collector feeding OTel/LGTM observability across the server and Go client.
  • Supply Chain Exposure: AGPLv3 open-source codebase with 40+ operational wiki and docs guides, an independent combat verifier that checks 2,355,388 declared finite cases and pins a SHA-256 result digest, and CI-gated rule, replay, and playthrough verification ahead of every release.

Empirical Outcomes

  • Built an explainable battle engine that records a versioned, step-by-step combat calculation for every attack, with named operands, ordered operators, and stable PD-RULE identifiers, driving live damage previews, narration, and spectator replay with complete mathematical transparency.
  • Verified the combat engine against an independent reference checker covering 2,355,388 declared finite cases, pinning a SHA-256 result digest as a bounded correctness proof to remove guesswork and regression anxiety.
  • Kept game state synchronized across WebSocket and REST paths for TypeScript, Go, and Swift clients, using role-specific projections and knowledge-safety tests that keep hidden hand and deck information out of what any client can see.
  • Shipped a live production platform (phalanxduel.com) with an automated release pipeline that builds an immutable GHCR container image, promotes it after health and readiness checks, and rolls back to the last known-good image on failure, ensuring zero-stress, predictable deployments.

The Discovery Method Behind the Studies: IEA & 4D Cartography

In the 2023 Acquisition architecture initiative, I used IEA to turn uncertainty about customer journeys and event data into an actionable record. System Cartography extends that evidence-first practice when reconciling what people think a system does with what it actually does.

Acquisition (ACQ) was the customer-facing path through application and account workflows. The initiative aimed to make ACQ the highest-confidence source for analytics data in OMF by documenting flags, experiments, events, customer journeys, code assets, and team knowledge, then evaluating gaps and addressing them.

flowchart TD
  A[Inventory] --> B[Evaluate]
  B --> C[Address]
  classDef sequence fill:#e6f4f1,stroke:#0f766e,color:#1e232a
  class A,B,C sequence

Outcome: We know where our customers are going. We can make informed decisions. We iterate with confidence. Each new pass starts with what the last pass taught us.

Four questions that make the system legible

The technical names are useful shorthand. These are the questions they answer.

01 // Where does work enter? (interaction surface)

Requests from browsers, mobile clients, APIs, and external consumers.

02 // What else changes? (lateral state dependencies)

Changes crossing domains, queues, transactions, databases, and locks.

03 // What path does it take? (full-stack topology)

The route from the first request through applications, services, infrastructure, and data.

04 // Who else is involved? (supply chain exposure)

External providers, shared dependencies, compliance boundaries, and release checks.