Work

Customer Adoption Acceleration Program

Context

When generative AI reset the competitive landscape, AWS field teams suddenly needed to coordinate technical validation work across more than 25 specialist units — each with its own intake process, its own tooling, and its own definition of an "opportunity." There was no central mechanism to route requests or alert the right team when a new workload appeared.

Constraint

The hard part was never the pipeline. It was that 25+ teams had 25+ workflows, and every one of them had good reasons for working the way they did. Any system that required teams to abandon their process would simply not get adopted. It also had to ship fast — the business context was moving weekly.

Decisions

I led requirements gathering across all of the teams, then designed the data integration and delivery architecture from scratch: a unified intake model, automated routing logic, and opportunity tracking that met each team where it already worked instead of forcing a new tool on them. I traded elegance for adoption at several points — a messier data model that mapped to how teams actually operated beat a cleaner one they would have ignored.

Outcome

The system processed thousands of technical engagements with 92% automated routing, became the coordination backbone for the program, and was featured in a launch announcement to senior field leadership. The lesson I keep from it: at organizational scale, requirements synthesis is the architecture.

Ask Chris

What it is

The assistant on this site. It answers questions about me using only a knowledge base I wrote, and says so when something isn't in it.

How it works

Each message runs a small function on AWS Lambda. It checks the visitor's daily limit, picks up the conversation if they wrote in the last hour, and sends the question to Google Gemini with the knowledge base. If one model is unavailable, the next one answers.

Cost and safety

Nothing runs between messages, so it costs nothing when no one is asking. Each visitor has a daily limit, and a cap across everyone keeps the bill fixed. API keys are stored encrypted in AWS Parameter Store, not in the code.

FPL Intelligence Engine

Context

Fantasy Premier League rewards squad and captain decisions made from incomplete information, fifteen minutes before a deadline, every week for ten months straight. I wanted a system that made that decision better than I could by hand, and that kept doing it without me.

Constraint

It had to run unattended for an entire season: new data every gameweek, a model that doesn't quietly go stale, and a public output, so there was nowhere to hide if a prediction was wrong.

Decisions

Six separate XGBoost models, each specialized on a different signal (form, fixtures, price, minutes risk) rather than one model trying to learn everything at once. A Python pipeline pulls the official FPL API, retrains, and regenerates squad and captain recommendations automatically each gameweek. The frontend rebuilds and redeploys on that same schedule with no manual step in between.

What broke

The uncomfortable engineering decision was the scoreboard: a page that tracks the model's own hit rate against reality, gameweek by gameweek, permanently public. It would have been easier to only show the wins. I built it anyway, because a prediction engine that hides its record isn't one worth trusting, including by me.

Outcome

A production system that has run a full season end to end without hand-holding, plus a technical writeup ("Under the Hood") and manager's guide for anyone who wants to see the model's reasoning, not just its picks.