WalmartHealth & Benefits Technology.

Why this work matters

Walmart reports roughly 1.6 million associates in the United States and offers a broad set of benefits for associates and eligible dependents. At that scale, benefits technology is not one application. It is an ecosystem of programs, rules, vendors, member journeys, and regulated data.

Healthcare data is also moving toward clearer interoperability standards. CMS now requires impacted payers to support FHIR-based access for patients, providers, other payers, and prior-authorization workflows. That public direction makes a shared claims and benefits foundation more than an internal cleanup project. It is part of how the industry has to operate next.

What was hard

I joined to lead two different kinds of work at the same time. One portfolio serves an established benefits business of more than $6 billion and 1.6 million members. The other is a new healthcare business being built from the ground up.

The portfolios look different on a roadmap, but they share the same leadership problem: turn a business idea into a system that teams can operate repeatedly. Product choices, architecture, financial assumptions, compliance boundaries, team ownership, and delivery cadence all have to reinforce one another.

Benefits programs can also accumulate their own onboarding paths, integrations, and operating exceptions. When every new program becomes a custom engineering project, teams spend more time navigating old boundaries than improving the member experience.

What I owned

I lead engineering across both portfolios. My role connects product strategy, architecture, financial modeling, organization design, and day-to-day execution. The job is to make the business and technical choices clear enough that teams can move independently without drifting apart.

I organized the work around two portfolios with dedicated engineering and program ownership. Each team needed room to execute its own strategic bet while sharing the architecture and operating decisions that mattered across both.

For the greenfield business, I worked from the value chain backward: what has to be true for the business model to work, which decisions need software support, which controls are non-negotiable, and what organization can ship and run it. The product details remain confidential; the leadership method does not.

What we built

For the established benefits platform, we are moving from repeated custom work toward a configurable builder model: shared components, consistent data and integration patterns, and guardrails that allow business and application teams to do more without starting a new build every time.

I also led architecture work that treats claims and benefits as a connected lifecycle rather than a collection of processing systems. The point is not consolidation for its own sake. It is to make the rules, data, and ownership clearer from program setup through the member experience.

For the new business, we connected strategy, financial modeling, product direction, engineering, operations, compliance, and organization formation from the beginning instead of handing the idea from one function to the next.

What changed

The clearest change is a shared way to decide what belongs in the platform, what should remain specific to a program, and who owns each decision. That gives the established platform and the greenfield business a common operating language without pretending they are the same product.

It also reframes technology from a downstream delivery function into part of business design. Engineering participates while the value chain, financial model, product boundaries, and operating controls are still being shaped—not after those choices have already hardened.

What I learned

At enterprise scale, platform strategy and organization design cannot be separated. A reusable capability does not create value if teams cannot find it, trust it, or understand the boundary around it.

The leader’s job is to make both kinds of architecture visible: the systems that carry the work and the organization that owns the decisions.