Tell me about a time you shipped something under ambiguity.

I owned the demand-forecasting model for a logistics support operation. It predicts hourly contact volume so workforce planning can staff the right number of agents each day. About six months after launch, the forecasts started drifting: we were consistently under-predicting, and staffing was running short on the busiest days.

The ambiguity was that no one could say why. Several things had changed at once, volumes were climbing, the business was running promotions, and the model hadn't been retrained since it went live. Wrong outputs, no confirmed cause.

My job was to get forecast accuracy back to a usable level, fast. Staffing decisions were being made off these numbers every week, so every week of drift was real understaffing on peak days.

The hard part: the clean fix, a full retrain on fresh data, wasn't available in the timeframe. The retraining pipeline wasn't production-ready and would have taken weeks. So I had to act under genuine ambiguity: a broken output, no confirmed root cause, and no clean lever to pull.

I started by separating what changed from what was always weak. Instead of staring at the blended average error, I pulled the error apart by day and by day-of-week. A pattern fell out: the misses weren't random. Volume had ramped roughly 65% since the training period, and the model was stuck near training-era levels, and the gap was worst on specific weekdays, Thursdays and Fridays, where real volume had grown most.

That told me two things. One, the core problem was structural, the world had moved past the model's training data, not a bug to hunt. Two, the error had a stable shape: it tracked day of week. Which meant I could correct it without fully understanding every driver of the surge.

The "right" answer, retrain, wasn't available in time. So I made a call: ship a lightweight correction layer rather than wait for certainty.

I built a day-of-week scale factor: a multiplier computed from a recent trailing window that nudged each day's raw prediction toward where actual volume had been landing, clipped to a sane range so it couldn't overcorrect. It rode on top of the existing model instead of replacing it, and it sat behind a config toggle so we could roll it back instantly if it misbehaved.

I was explicit with my manager and the ops team that this was a deliberate stopgap, not the final answer, and I set the bar up front: it had to close most of the gap and not make any single day worse. And we kept the proper retrain moving in parallel as the real fix.

It worked. Over the first five weeks in production, across about 78,000 contacts, weighted error dropped from roughly 40% to 24%. The worst days improved most: Friday went from about 41% error to 24%, and Thursday moved almost as much. Staffing stopped running systematically short on the peak days.

And because it was a thin, toggle-able layer rather than a rebuild, I shipped it in days, not the weeks a retrain would have taken, and we still landed the proper retrain later as the durable fix.

What I took from it: under ambiguity the instinct is to wait for certainty, the full diagnosis, the clean fix. The unlock was separating the parts I was sure of from the parts I wasn't. I couldn't explain every driver of the surge, but I could see the error had a stable, day-of-week shape, and that was enough to act on safely and reversibly.

I'd do the same again: find the part of the problem you can be confident about, ship a reversible fix that addresses it, and keep the proper solution moving in parallel. The one thing I'd do earlier is the accuracy monitoring that eventually caught the drift, we found it later than we should have, and that's the change that would have made the whole episode smaller.