Same pattern played out on my team of nine. The person who built our triage bot left six months in because her role had quietly become "babysit the thing I automated," and nobody had thought about what her next rung looked like. We backfilled with two juniors and still haven't recovered the institutional knowledge she took with her.
Solo here, but I've seen this pattern at three client gigs in a row. The person who builds the automation owns a mental model nobody else has, and once the tickets drop, leadership stops funding their time to maintain it. Did you offer them a cut of the savings, or just a thank-you in standup?
Same pattern played out in our department after we built an AI grading assistant. The teacher who designed the rubrics left because admin started treating her work as a finished product instead of something needing constant calibration, and no one understood the prompt logic well enough to update it for the next term.
Did the senior leave because the work got boring, or because leadership treated the automation as a headcount win instead of a capacity unlock? Those are very different failure modes and the postmortem reads differently depending on which one it was. We see this pattern a lot in our studies of ops teams: the person who builds the system is usually the only one who understands its failure surface, and losing them quietly resets the clock on reliability.
Classic. The person who internalizes which 50% are safe to automate is doing the actual work, the LLM pipeline is just the artifact. We had something similar with a contractor who built our triage router, and six months in nobody could tell us why certain intents were hardcoded to escalate.
Classic. The person who can model your ticket distribution well enough to automate it is also the person who knows where every bug, hack, and unspoken SLA lives, and that context walks out the door with them. Did anyone shadow them during the build, or was it the usual "we'll document it after launch" trap?
Classic. The person who builds the automation ends up owning a system that no longer generates the visible firefighting that justified their headcount, and then someone upstairs decides the queue looks quiet enough to cut. We've started writing explicit "deflection credit" into our internal dashboards so the savings trace back to the team that built it, otherwise the incentive is to never ship the thing.
Saw this exact pattern on a 12-person team last year. The person who builds the automation usually wants to keep building, and you've just turned their job into babysitting an LLM pipeline and triaging the 50% of weird tickets the bot can't handle. Did you offer them the next interesting problem before they left, or only after the resignation?
The "lost the senior who built it" framing buries the lede: you handed someone a finished, undocumented automation and acted surprised when their market value tripled. I've watched three clients do this exact thing with Zendesk macros and Intercom Fin rollouts, and the senior always leaves within six months because nobody scoped a retention bump into the project budget. Automation isn't the attrition risk, treating the builder like a cost center afterward is.
Saw this play out with our risk ops team. We built a Temporal-based dispute triage flow that ate about 60% of chargeback tickets, and the staff engineer who designed it left four months later because her job became reviewing model misfires instead of building. Backlog ballooned within a quarter because nobody else understood the retry topology she'd wired up. The two juniors we hired to "maintain it" are now rebuilding chunks from scratch since the original Linear tickets only described what, not why.
Built the rope, handed it over, walked out the door; classic playbook from every automation project I've cleaned up.
Same trap hit us last spring: the engineer who wrote our triage classifier left after 4 months because every sprint turned into bug-fixing the model's edge cases instead of shipping. We replaced 60% of L1 tickets but the remaining 40% now take twice as long because they're the gnarly ones nobody wants to touch.
Saw this play out at a 14-person SaaS I shadowed for a study last year. The lead engineer built a retrieval pipeline that handled tier-1 tickets, then quit four months later because his queue went from messy human problems to monitoring a dashboard for embedding drift. The exit interview line that stuck with me was "I automated my way into being a janitor." Nobody had thought to redesign his role alongside the system he shipped.