What to Do When Old Tasks Keep Creeping Back Into Your Role
You redesigned your role six months ago. The reporting format that used to eat your Mondays now runs on autopilot. You sit in meetings you used to hear about secondhand. Your manager has started routing decisions to you before they're finalised, not after. And yet last week you found yourself reconciling a spreadsheet you thought you'd handed off in March, covering a coordination call because someone was "only away for two days", and drafting a status update nobody with real stakes was going to read.
None of it felt like a step backwards at the time. Each request looked small enough to absorb without comment. That's exactly the problem.
Exceptions don't stay exceptions
Most people assume role erosion looks dramatic: a reorganisation, a demotion, a manager quietly reassigning your best work to someone else. In practice it rarely announces itself that way. It arrives as a string of individually reasonable requests, each one framed as temporary, urgent, or too minor to be worth the friction of refusing.
A colleague asks you to handle something "just this once" because someone else is on leave. A manager routes an execution request to you during a crisis, bypassing the process you set up to filter exactly this kind of work. Someone asks for quick input on a task that sits well outside what you now do, and you say yes because saying no over something this small feels petty. Each of these, taken alone, is a reasonable accommodation. Taken together over a few months, they rebuild the calendar you spent half a year dismantling.
The mechanism is not laziness or poor prioritisation on your part. Stakeholders default to whatever worked before, because switching their mental model of what you're for takes deliberate effort they have no reason to make unless you make it necessary. If you used to be the person who handled a certain kind of coordination, that expectation doesn't expire just because your job changed. It persists until something actively corrects it, and every time you quietly absorb the old task instead of redirecting it, you confirm the old expectation rather than the new one.
How a threshold moves without anyone deciding to move it
The clearest illustration of this comes from a finance analyst who had built a clean rule for her own workflow: budget variances under ten percent were monitored automatically, and only variances above ten percent entered her manual investigation queue. It was a sensible boundary, grounded in where her judgement actually added value.
Then a department head asked her to look into an eight percent variance because it "felt wrong", even though it fell under the threshold. She agreed. Two weeks later, a different department head made a similar request for a seven percent variance. She agreed again. By the third month she was investigating variances as low as five percent, because department heads had learned that expressing enough concern was enough to bypass the rule entirely. Her queue filled with low-materiality checks that consumed her time without improving anything, while a genuinely significant variance, one that actually needed her judgement, sat waiting four days because her calendar had no room for it.
Nothing about this happened through negligence. It happened because each individual exception was small enough not to seem worth defending against, and small exceptions that succeed become the template for the next request. She eventually restated the threshold in writing to every department head and held it when three of them pushed back. Within two months, the sub-threshold requests stopped. The rule hadn't changed. What changed was that she'd stopped letting it be tested informally, one polite favour at a time.
Two operations managers who redesigned their roles over roughly the same period, elevating their work from execution coordination to process optimisation, ended up in very different places for the same reason. One absorbed outside-scope work through a long series of individually reasonable accommodations, and her positioning dissolved as temporary favours quietly became permanent expectations. The other maintained the boundaries he'd set, and when a restructuring review eventually looked at both roles, his had solidified into something the organisation now depended on structurally. Hers had drifted most of the way back to where she'd started.
Delegating tasks without delegating the part that matters
Part of protecting a redesigned role means handing off the execution work that used to define your old position, and this is where a second, quieter kind of erosion tends to appear. It's possible to delegate so completely that you delegate away the judgement that made the redesign worth having in the first place.
A product manager who moved her role toward strategic roadmap planning delegated feature-specification writing to a junior colleague, but kept final approval over which features made it onto the roadmap and how they were sequenced. That distinction mattered. Six months later, once the junior product manager had built real competence, he asked for authority to finalise specifications without her review. She declined, but she was precise about why: he had full authority over technical implementation, and she retained approval only where a specification touched roadmap sequencing or resource allocation. Everything that executed an already-approved feature could proceed without her.
The line she drew wasn't about control for its own sake. Tasks can be handed off freely without any loss of positioning. Decisions are different, because decisions are where your leverage actually sits. Delegate the task and you free up capacity. Delegate the decision along with it, even by accident, and you've quietly dismantled the redesign.
Capacity works on a similar logic. A programme coordinator managing four active projects was asked to absorb a fifth. Rather than accepting silently, she worked out that maintaining quality across all five would require fifty-five hours a week, and that she could sustain that overload for perhaps four weeks before delivery quality across every project began to slip. She said so directly, laid out the trade-off, and asked her manager which option fit the organisation's priorities better. One of her existing four projects was reassigned elsewhere. Eight weeks later, all five projects, split across two people, were on track. Had she absorbed the extra load without naming the limit, at least one of them almost certainly wouldn't have been.
Telling a real exception from a creeping one
Not every request outside your redesigned scope is a threat to it. Genuine short-term help, covering someone who's actually on leave, stepping in during an actual crisis, is a normal part of working with other people, and treating every one of these as an erosion risk will make you rigid and difficult to work with for no good reason. The distinction that matters isn't whether a request falls outside your current scope. It's whether the request keeps its temporary status or quietly loses it.
A useful habit, when something old resurfaces, is to ask what kind of request it actually is before deciding how to respond. Is it genuinely one-off, in which case it's worth naming as one-off out loud, so it isn't remembered later as precedent? Is it recurring, in which case it belongs back on the list of things you deliberately moved away from, and needs redirecting rather than absorbing? Could it be delegated to someone else without taking your judgement with it? Was it simply misrouted, sent to you out of habit rather than by design, in which case the fix is pointing it toward wherever it should actually land? Or, on reflection, has your role genuinely grown to include it, in which case it isn't erosion at all, and treating it as one would just be territorial.
That question, asked consistently, is what keeps a redesigned role redesigned. Boundaries you set once and never revisit don't hold on their own. They hold because you keep noticing which requests are testing them, and because you keep answering honestly.
Maintenance, not a one-off fix
A redesigned role isn't a state you arrive at and then keep by default. It's closer to a structure that needs upkeep, because every stakeholder who worked with the old version of you has a small, understandable incentive to keep treating you like the old version, and nothing about that incentive goes away just because your job description changed. The version of the role you built stays intact only for as long as you keep noticing, and correcting, the moments when the old one tries to reassert itself.
David Taylor
Interested in going further?
The AI-Ready Career looks at why protecting a redesigned contribution is as important as building it in the first place, and what that protection actually requires in practice.
Ad · Amazon affiliate link.
