You Are Not The Solution: How Good Engineers Become Organizational Debt

There's a pattern I've started recognizing in myself. Once you see it, you can't unsee it.

Someone sends a message (usually Slack, usually casual, usually phrased so it sounds small), and before I've finished reading it, I'm already calculating. How long would this take? Could I clear Thursday afternoon? I know exactly how to do it. It wouldn't be hard.

I'm already solving the problem before I've decided whether the problem is mine to solve.

That gap between "can I do this?" and "should I do this?" is where a lot of capable engineers quietly disappear.

The Fixer Identity

For a lot of engineers, especially engineers who got good early, who built their reputation on being reliable, who learned that "she'll figure it out" was a compliment... being the person who solves things becomes part of your identity.

Organizational psychologists have a name for a version of this at the institutional level: the competence trap. A team gets so good at a particular workaround that it never invests in the real solution, because the workaround keeps working. The very competence becomes the obstacle to improvement.

At the individual level, it's more personal than that. If being the fixer is part of how you understand your own value, then declining a request isn't just declining a task. It's a small, temporary suspension of the person you think you are. That's uncomfortable, and it has nothing to do with the task itself.

So you say yes. Not because you were manipulated. Not because you didn't see the pattern. Because saying yes is consistent with the story you tell about yourself, and saying no creates a friction that you've been avoiding for years.

When Invisible Labor Becomes Load-Bearing

A while back, I fixed a production issue by doing direct database surgery. This was a manual intervention on live data, the kind of thing that works but shouldn't become the norm. I said what I always say afterward:

"We need an endpoint for this."

Two weeks later, three hundred users needed the same fix. The API endpoint wasn't built. And a PM messaged me and asked (in Slack):

"Can you run the script again?"

What struck me later wasn't that the ask happened, it was how reasonable it seemed from the other side.

The person asking had no visibility into what database surgery actually required. They didn't know about the work you actually did, the double-checking, the background awareness of what a bad WHERE clause would do to a production environment. What they saw was: problem existed, Joanne fixed it, problem resolved.

There's a well-documented phenomenon in research on domestic and emotional labor: work that requires high skill and attention becomes invisible precisely because it's done well. When something gets handled cleanly, people see the outcome, not the handling. The effort disappears into the result.

For engineers, this creates a specific distortion: the more careful you are, the more your carefulness becomes invisible. Your expertise looks effortless, and effortless things don't feel like they require a system because all they require is you.

So the organization doesn't build the API. Not out of laziness. Because from the outside, the gap doesn't look like a gap. It looks like a solved problem with a human face attached to it.

You have become the load-bearing infrastructure. And load-bearing infrastructure is the last thing people want to replace.

How Organizations Learn This (Without Realizing They Are)

The uncomfortable truth about this pattern is that it doesn't require anyone to be a bad actor. It requires ordinary psychology operating inside a system that was never designed to counteract it.

There's a principle in behavioral economics called the availability heuristic: we estimate the feasibility of something based on how easily an example comes to mind. If you need a problem solved, and the most available example of "this getting solved" is a specific person solving it, that person becomes the default. Not because the team is exploiting you, but because that's how pattern recognition works.

Tangentially, there's also a related dynamic called diffusion of responsibility. In a group, when a task doesn't have a clear owner, everyone slightly assumes someone else will handle it. But when a task does have a clear default owner (even if it's a very informal one that emerged from a single incident) that diffusion runs in reverse. Everyone slightly assumes you'll handle it. And this is because it's the path of least resistance.

Finally, there's the way urgency and investment compete for the same budget. The proper solution, which was the API, keeps losing to things that are more immediately on fire. This isn't because it's a prioritization failure by any specific person. This is because it's a structural property of how most organizations allocate attention. Urgent things have advocates (or screaming clients); important things have to earn them. When you keep filling the gap, you remove the pressure that would otherwise force someone to advocate for closing it. The cost becomes invisible because you're absorbing it. So then your budget that should go to the real solution never materializes because the absence of the real solution has no visible consequence.

You're not just doing extra work. You're helping justify the decision to never build the thing.

The Resentment Arc

The early stage felt great, because you're needed. The problems land on your desk because you're the kind of person who handles things. There's real satisfaction in that.

The middle stage is where the quiet harm happens. You're still handling things, but you're starting to notice the pattern. You feel a slight irritation when certain requests come in. Requests that you used to feel neutral or even good about, but you still say yes anyway, because the argument feels bigger than the task. You're starting to resent a situation that, from the outside, still looks like success.

The late stage is where it breaks. Either you burn out, or you finally say no, and it lands like a bomb. Something that should have been a small conversation years ago feels enormous, because it is. Years of absorbed cost finally exploded.

The resentment arc is real. That quiet irritation when a certain kind of request comes in isn't a mood problem. It's a bill arriving for debt that was never yours to carry. If you're feeling it, something structural has already gone wrong.

Why "Just Say No" Is Incomplete Advice

Now this is where the standard career advice usually shows up: set boundaries, protect your time, say no more often.

That advice is not wrong. It's just downstream of the actual problem.

If being the solution has become part of your professional identity, "just say no" requires renegotiating something deeper than a single request. You have to tolerate the discomfort of temporarily not being the person you've been rewarded for being. It's uncomfortable in a way that advice doesn't usually acknowledge.

The practical move that actually works isn't a refusal. It's a reframe.

The most technically sophisticated thing you can do in some situations is make the invisible visible:

"We are treating an emergency workaround as a permanent workflow, and I want to name that out loud before we keep doing it."

That is not less capable than running the script. It's actually more capable because it addresses the actual problem instead of the symptom.

And the redirect matters as much as the refusal.

"I'm not going to do X, and here's what I think we should do instead, and here's how I can help make that happen"

This is a different move than just "no." It repositions you from the person who fills gaps to the person who closes them. That distinction compounds over time.

What you're really doing, when you hold the line, is refusing to fund the status quo with your own capacity anymore. You're making the real cost of the gap visible to the people who have the power to actually close it. That's not self-protection dressed up as principle, that's actual work.

What You're Actually Protecting

When I finally held the line on the script. When I said no, I held it when they asked again. I watched the API get built a few weeks later, and the thing that stayed with me afterward wasn't the time I got back.

It was that the organization learned something. Not from me lecturing anyone. Just from the workaround becoming unavailable.

When a gap has someone filling it, the gap is invisible. Remove the person, and the gap has to become a conversation, a priority, a ticket, a build. That's not comfortable, but it is honest. And, truthfully, people only want to fix what they can see.

The longer version of this is about identity. Building a professional self-concept around being the person who solves everything sounds like an asset, and for a while, it is. But at a certain level of seniority, it becomes the thing holding you back. The engineers I've watched do the most consequential work aren't the ones who kept saying yes to every solvable problem. They're the ones who got specific about which problems were theirs to solve. They built the systems, the habits, and the organizational muscle so that the other problems could get solved without them.

That's a different kind of competence. And it requires being willing to look, briefly, like you're not the solution.

You're not. That's the point.