"I am the only one who knows how to do this" sounds like a flex. It feels like security and it sounds like expertise, but most of the time it's a quiet admission that some part of the system only works because you are standing next to it.
Working yourself out of a job means eliminating the part of your job that only exists because the system is broken, undocumented, or dependent on one person's memory. You aren't making yourself useless by doing that, and it isn't career suicide. Babysitting a problem turns you into part of the operating cost, while making the problem disappear is how you become more valuable.
Necessary Feels Like Job Security
A lot of engineers and support people build their identity around being necessary. They know the magic command, which table to patch, and which service needs a restart when the queue backs up. They know the workaround that never made it into the documentation, and how to calm down the angry customer while they run it. That feels like job security, and what it actually creates is organizational risk, because the company now has a business process that only works when one person is available, healthy, and not already buried under three other emergencies.
That's a single point of failure wearing a badge.
Patch, Move On, Repeat
The shape of it is almost always the same. A customer issue comes in, someone patches the symptom, the pain goes away, and everyone moves on. Then the same issue comes back, maybe for a different customer, and someone patches it again. From the inside, every step feels responsible. The customer is angry, the queue is full, and stopping the bleeding is the correct thing to do in the moment. Nobody is being lazy or careless.
The trouble is that the moment keeps repeating, and each repeat gets handled as a fresh emergency when it's the same one with a new ticket number. Meanwhile the company keeps paying for the same failure, customers keep feeling the same pain, and the engineers closest to it slowly turn into babysitters for a system nobody ever fixed.
Building a Better Shovel
Once you start looking for this pattern, it shows up everywhere. A company sees repeated customer pain, and instead of removing the cause, it gets better at the workaround. It builds tooling to make the quick fix faster, writes a runbook for the recurring incident, and trains three more people to run the magic command. It builds a better shovel instead of asking why people keep falling into the same hole.
Quick fixes are sometimes necessary. When production is on fire and the customer is blocked, you stop the bleeding, and that's the responsible call during an incident. As a business model it's irresponsible. Stop at the workaround and you end up running a factory for recurring pain, where the workaround has become the product and the support queue exists to process the same few failures over and over.
Then What Would I Do?
The moment that tells you the most is a question I have heard more than once, usually asked quietly, when someone realizes their workaround could be designed away. "Then what would I do?"
That question says the quiet part out loud. The person has become attached to the problem, and it usually has nothing to do with being bad at the job or not caring. The broken system has become their role and their importance, and maybe their protection. It's an understandable place to end up, and it's a trap, because a growing company never runs out of problems worth solving, and holding on to the old one so you always have something to do costs you the chance to earn your way into the bigger ones.
Fix the Class, Not the Instance
The better move is to fix the class of problem along with the instance in front of you, so the issue disappears for this customer and for the next one who would have hit it. That usually means going one layer deeper than the ticket, to the missing validation, the unclear ownership, or the fragile step that keeps generating the same failure.
It's slower than the quick fix, and less satisfying in the moment, because nobody throws a parade when an incident stops happening. It's also the difference between fixing something once and fixing it every time the ticket comes back.
Teach the Habit Along With the Fix
One person fixing root causes is good, and it's still fragile if that person is the only one who works that way. The fix has to come with the habit. Teach the pattern, write the fix down where the next person will find it, and make root-cause thinking a normal part of how the team handles incidents instead of something one stubborn engineer does on their own.
You cannot scale heroics, and a mindset that lives in one head doesn't scale either. The teams that get this right turn one person's judgment into something the whole group does by default, which is the only version of it that survives someone changing roles, going on vacation, or leaving.
Make Yesterday's Emergency Boring
The fastest way to become a single point of failure is to be proud that nobody else can do what you do. Making your hardest problem boring and handing it off can feel like giving something up, and it's exactly what frees you for work that matters more.
It also proves you can build things that work without you, and the usual reward for making one problem disappear is being trusted with a bigger one. Your job is to keep making the system better until yesterday's emergency is boring, and then go find the next one.
Being the only one who knows how to fix something should never be the boast. At its best, it's the first item on your to-do list.
Frequently asked questions
Does working yourself out of a job mean making yourself redundant?
- No. It means eliminating the part of your work that only exists because the system is broken, undocumented, fragile, or dependent on one person's memory. The person who makes problems disappear becomes an asset; the person who babysits them becomes part of the operating cost.
Isn't being the only one who can fix something good job security?
- It feels that way, but it creates organizational risk. A business process that only works when one specific person is available, healthy, and not already buried in other emergencies is a single point of failure wearing a badge.
Are quick fixes always wrong?
- No. When production is on fire and a customer is blocked, a quick fix is the responsible thing to do. The problem is stopping there. A quick fix is responsible during an incident and irresponsible as a business model. If the organization only ever optimizes the workaround, the workaround quietly becomes the product.
What does "fix the class, not the instance" mean?
- It means going one layer deeper than the ticket and removing the cause, so the issue disappears for this customer and for the next customer who would have hit it. It is slower and less satisfying than patching the symptom, but it is the difference between fixing something once and fixing it many times.
How do I work myself out of a job without actually losing it?
- Spread the habit instead of hoarding it. Teach the pattern, document the fix where the next person will find it, and make root-cause thinking the team's default rather than your personal heroics. A growing company never runs out of problems worth solving, so the reward for solving one well is being trusted with bigger ones.
Why do teams keep optimizing the workaround instead of the cause?
- Because in the moment it always feels responsible. The customer is angry, the queue is full, and the team is under pressure, so stopping the bleeding is obviously correct. The trap is treating each repetition as a fresh emergency instead of the same emergency with a new ticket number, until the company is running a factory for recurring pain.