Staffing reduction from 10 to 2 in a supply chain workflow

Evidence status — candidate-confirmed P outcome, architecture from resume/portfolio: eight positions were eliminated (not redeployed). The multi-agent supply-chain platform, HITL gates, and eval discipline are resume-supported at Lucid. Exact employment-decision ownership, measurement windows, and transition support for affected people stay in private notes — do not invent them under pressure. See the evidence ledger.

Expected question

"Tell me about a time you significantly reduced manual or operational effort through automation, while keeping risk and reversibility under control."

Variant forms

Interviewers often probe the same competency with different framing — recognize the archetype and answer with your story:

"Tell me about a time you automated a workflow and reduced headcount or staffing intensity — how did you know it was safe?"
"Describe shipping agentic automation for repeatable ops work without replacing human judgment on the hard 20%."
"Tell me about a time you cut toil by 80% — what stayed manual and why?"
"How did you decide which exceptions still need human approval after you automated a process?"
"Tell me about measuring success of automation beyond 'it runs' — what metrics did you use?"
"Describe a time stakeholders wanted full autonomy and you insisted on HITL gates — what happened?"
"Walk me through reverse-engineering risk tiers so staffing intensity followed evidence, not optimism."
"Tell me about separating architecture ownership from employment decisions when automation changed staffing."

The question, as it might actually be asked

"Tell me about a time you significantly reduced manual or operational effort through automation, while keeping risk and reversibility under control." They're testing whether you'd ship automation that looks great in a demo and then breaks when someone leans on it for staffing. Answer with your verified story — not a generic "we automated X" pitch.

Candidate-owned evidence prompts

Keep these private before naming finer numbers in a live interview:

Measurement period and before/after case volumes for the 10→2 workflow.
Exception, incident, and manual-review rates before and after.
Exact boundary between architecture ownership and the employment decision.
What support/notice/transition was provided to the eight people affected.
Which sentences may be spoken publicly without confidentiality risk.

Author reference (do not memorize)

Use the STAR below as a verified skeleton. Do not add quality chronology, HR process, or “evals caused the staffing cut” claims unless private notes confirm them.

Situation

At Lucid Motors (Nov 2023–present), supply chain and ops were burning people on the same judgment loop at volume — intake, validation, exceptions, routing. Vendor EDI/tools and rule-only automation covered the easy path; the ambiguous cases still landed on humans. I was architecture lead for the multi-agent supply-chain platform that replaced those vendor-dependent workflows with something we could actually govern (resume + Lucid case study).

Task

Ship agentic automation that could take the repeatable work without pretending the hard 20% was safe for full autonomy. The confirmed outcome is staffing on that flow went from 10 to 2 — eight positions eliminated. I do not claim I owned the employment decision. I owned the architecture, the controls, and the reliability argument that made a smaller human footprint operable.

Action

I refused the "one agent does the whole case" pitch. We shipped a multi-agent, multi-model setup with retrieval, task routing, eval checkpoints, human review paths, and production monitoring.

Three calls I'd defend in a panel:

Orchestration and retrieval stay separate. If you change a prompt or model and it silently rewires your RAG and tool plane, you can't iterate under load. I'd rather pay the boundary tax.
HITL by risk tier — not "a human looks at everything." Structural correctness can pass and still route irreversible or high-blast-radius actions to a person. Same instinct as the open policy/HITL gateway patterns I've implemented (O — pattern language, not Lucid runtime proof).
Evals before volume. Golden/regression thinking — fail the build on regression, not on anecdote. If someone asks "did evals cause the staffing cut," only claim the sequence you can defend privately. Public line: controls and monitoring were design requirements for operability; the 10→2 outcome is confirmed separately.

What I rejected: maximize autonomy first so the headcount slide looks good before failure modes show up. That's how you get a staffing number and an incident class in the same quarter.

Result

P (candidate-confirmed): staffing on the repeatable workflow went from 10 to 2; eight positions eliminated — not redeployed, not "capacity released."
Spoken default: stop there. The broader platform's vendor-replacement savings live on the resume as a separate story — don't glue dollars to headcount unless private finance notes actually tie them in the same window.
The two remaining roles own the exceptions and judgment the automation was designed to leave alone.
Scar I'd name early: pressure to "just let the agent finish the case" on high-risk tiers. I refused. The thing that stuck wasn't heroics — it was risk-tiered HITL.

The follow-up question you should expect

"How did you know it was safe to reduce staffing that much?" If you have private before/after quality and review numbers, use them. If you don't, say so out loud: "I can defend the architecture and the confirmed staffing outcome. I won't invent a quality time-series." Then walk the control design — risk tiers, HITL, monitoring, exception path — and who owned the employment call. If they want pattern proof, point once to open governance/orchestration work (O) — never as Lucid production proof.

Staff+/Principal signal rubric

Mid-level: automation reduced effort; light on risk controls.
Senior: quantified outcome + at least one concrete safeguard.
Staff+: explains the automated vs human split by risk/reversibility, not vibes.
Principal: separates architecture ownership from HR outcomes, refuses unsupported chronology, and leaves a reusable control mechanism.