Being Necessary Is Not the Same as Being Valuable

A lot of engineers and support people quietly build their identity around being necessary. They know the magic command, which table to patch, and which service needs a restart. They know how to calm down the angry customer and the tribal workaround that never made it into documentation. At first that feels like job security, but in reality it creates organizational risk, because now the company has a business process that only works when one person is available, in a good mood, not on vacation, not sick, not burned out, and not already buried under three other emergencies.

That is not expertise. That is 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 immediate pain goes away, and everyone moves on. Then the same issue comes back later, 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 the team is under pressure, so stopping the bleeding is the obviously correct thing to do in the moment. Nobody is being lazy or careless.

The problem is that the moment keeps repeating, and each repetition gets treated as a fresh emergency rather than the same emergency wearing a new timestamp. 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 that was never actually fixed.

A Better Shovel Is Not a Solution

There is a failure pattern that shows up everywhere once you start looking for it. 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. It writes an internal runbook for the recurring incident. It trains three more people to run the magic command. In other words, it builds a better shovel instead of asking why people keep falling into the same hole.

Quick fixes are sometimes necessary. Production is on fire, the customer is blocked, and you need to stop the bleeding. A quick fix is responsible during an incident. It is irresponsible as a business model. If the organization stops at the workaround, the workaround quietly becomes the product, and eventually the company is not solving problems anymore. It is operating a factory for recurring pain.

Then What Would I Do?

The most honest moment in all of this is a question I have heard more than once, usually 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. Not because they are bad, and not because they do not care, but because the broken system has become their role, their importance, and maybe their protection. It is an understandable place to end up, and it is a trap. The point is not to preserve the old problem so you always have something to do. A growing company will never run out of problems worth solving. The point is to earn your way into bigger, more valuable ones.

Fix the Class, Not the Instance

The better move is to fix the class of problem, not just the instance in front of you. Make the issue disappear for this customer and for the next customer who would have hit it. That usually means going one layer deeper than the ticket, to the bad assumption, the missing validation, the unclear ownership, or the fragile step that keeps generating the same failure.

It is slower than the quick fix, and it is less satisfying in the moment, because nobody throws a parade when an incident simply stops happening. But it is the difference between fixing something once and fixing it many times. You do not babysit problems. You fix them.

Scale the Way You Think, Not Just the Fix

One person fixing root causes is good, but it is still fragile if that person is the only one who works that way. So the goal is not just to fix the problem, it is to spread the habit. Teach the pattern. Write the fix down where the next person will actually find it. Make root-cause thinking a normal part of how the team handles incidents, rather than a heroic exception performed by one stubborn engineer.

You cannot scale heroics, and you cannot scale a mindset that lives in a single head. The teams that get this right turn one person's good judgment into something the whole group does by default, which is the only version of this that survives someone changing roles, going on vacation, or leaving.

Make Yesterday's Emergency Boring

None of this is about being needed less. It is about being needed for better things. The fastest way to become a single point of failure is to be proud that nobody else can do what you do. The opposite move, making your hardest problem boring and handing it off, can feel like giving something up, but it is exactly what frees you to take on work that matters more.

Working yourself out of a job does not make you less valuable. It proves you can create leverage. The reward for making one problem disappear is not unemployment. It is being trusted with bigger problems. Your job is not to be needed for the same problem forever. It is to keep making the system better until yesterday's emergency becomes boring, and then to go find the next one.

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. You are removing the fragile dependency, not your value. The person who makes problems disappear becomes leverage; 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. That is fragility, not expertise.

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 wearing a new timestamp, until the company is effectively running a factory for recurring pain.