Enrollment that completes within an hour

1. Outcome

   A member can use digital, claims and service, not an internal milestone
2. Legacy

   Batch with no audit of fallout or XML failures
3. Redesign

   Streaming flow tracking every enrollment and policy update
4. Exception:

   Crisis

   20 XMLs a minute seven days before go-live
5. Fix

   200 a minute; data ready in one day instead of two

Product workflow, shown through the decisions and handoffs.

Write acceptance criteria in the language of the member’s next action. It lets every team improve its own stage without mistaking local completion for the outcome.

From my original account

Enrollment at Evernorth ran as a legacy batch with no audit for fallout or XML failures. Members experienced enrollment as access becoming available; internally, a completed batch said nothing about whether that had happened. In parallel, the enterprise membership program needed customer membership persisted in the master-data platform so digital, claims and service could rely on it, and leadership had set an unrealistic deadline for all of it at once.

The decisions

I chose to redesign the enrollment flow on the new streaming infrastructure instead of patching the batch. For the membership program I built a core team, grouped the work into eligibility, coverage, preferences and digital support, and convinced leadership to prioritize eligibility first with a phased roadmap rather than everything in a week.

The crisis

Seven days before go-live, XML creation ran at twenty files a minute against a target of a hundred. I stood up a tiger team to triage within twenty-four hours. The root cause was logic that bounced between tables for every XML; the fix read each table once.

Leading across teams

The claims work happened inside a larger job. At a healthcare platform business I led product work across master data, enrollment, claims and policy capabilities. The scope expanded across teams and portfolios, with operating-budget responsibility and a funding case I had to make.

You do not lead multiple teams by attending every stand-up. We ran the Scaled Agile Framework: program-increment planning every quarter, features prioritised by weighted shortest job first, and an explicit balance between enabler work — the platform investment nobody sees — and business-value features the sponsors could point at. I have earned SAFe product-owner/manager credentials, and I still believe its central idea: that the plan is a negotiation between capacity and value, made visible.

The platform used Reltio for master data. When leadership proposed a source-by-source migration, I disagreed and brought dependency evidence: the business capabilities relying on that information, the consequences of interruption and the readiness of their consumers. The sequencing changed to protect dependent capabilities. I was asked to lead both platforms.

We modernized enrollment with Kafka. Before launch, a performance problem led to a focused investigation with engineering; the team found avoidable repeated processing and improved it. I also worked on a digital member migration and reverse-engineered Medicare deductible logic for an accumulator application. Those projects connected platform behavior with usable access and customer-service needs.

And the people. I hired early-career engineers from a development program and supported their growth. When a direct report was caught between competing outage-window requests, I took the escalation and helped secure a workable alternative. Leading a platform is mostly making sure the people who build it can.

Tools in this chapter Reltio MDM · Kafka · Teradata · SQL · Java / XML / XSD · Jira Align · SAFe PI planning · WSJF · Tableau · Salesforce integration

A new enrollment flow tracking every new enrollment and policy update, streaming enrollments at a hundred policies a minute, with members getting digital access, claims and service within an hour of enrolling. Fallout is triaged by cause, which the batch never allowed.