Why Good Engineers Eventually Stop Caring

There’s a particular kind of exhaustion that comes from fixing the same problems you’ve been asking for permission to prevent.

You find an issue. You investigate it, collect data, write up your findings, and propose a fix. You test it in a lower environment and demonstrate that it works. Then you spend months trying to get someone with authority to care enough to let you do something about it.

Nothing happens. Eventually, the issue becomes a production incident, and suddenly everyone is available. The same organization that couldn’t find time to discuss prevention can now assemble an emergency call across three regions.

After fifteen years working in systems, I’ve learned that this cycle can drain your interest in a job faster than the technical work ever could.

The same recommendation, a different source

I spent over a year raising concerns about database deadlocks involving some of our most heavily used tables and their poor indexing. I brought data. I wrote wiki pages. I tested indexes in lower environments and showed actual performance improvements. There was evidence available for anyone willing to engage with it.

Eventually, the application owner brought in outside consultants. They arrived at the same recommendation.

Everyone involved knew I had been saying it. Other engineers knew I was right. But there was no acknowledgment that we had already done this investigation internally, or any apparent interest in why it had taken an outside firm to make the recommendation worth hearing. Even then, nothing happened.

I don’t need a ceremony every time I identify a problem. But when an organization ignores internal expertise, pays someone else to repeat it, and still fails to act, you start questioning the purpose of doing that work in the first place.

What exactly am I supposed to do differently next time? Write a longer wiki page? Add another chart?

Expertise needs a path to a decision

A lot of this comes down to the people sitting between engineers and the decisions engineers need made.

I’ve worked with technology managers who couldn’t meaningfully follow a discussion about the systems they were responsible for. Explaining database contention is difficult enough when there are legitimate tradeoffs to consider. It becomes exhausting when you first have to explain what a deadlock is, why indexes matter, and how any of this affects the application—and the person listening still has final authority over whether the work happens.

Technical gaps are manageable when someone recognizes them. They become a serious problem when a manager lacks the understanding to evaluate a recommendation and won’t trust the people who have it.

I worked with a manager at another hedge fund who wasn’t particularly technical. He knew that. He leaned on his engineers for technical guidance and concentrated on making sure people were doing their jobs. He understood that operational efficiency, reliability, and redundancy required listening to the people responsible for those things.

I respected him. I could work with him. He gave technical expertise a path to influence decisions.

Flat organizations can still have bottlenecks

I’ve also seen how organizational structure makes this harder. Hedge funds like flat organizations. On paper, having ten or twenty engineers report to one person sounds efficient. In practice, that person may also be dealing with enough firm-wide responsibilities that the nuances of everyday technical operations never get proper attention.

The reporting structure is flat, but decisions still have to pass through one overwhelmed human being.

Investment banks have their own problems, but the hierarchy can provide a useful route for escalation. Associates report to VPs, VPs to directors, directors to managing directors. In my experience, those layers can help issues reach someone who has both the time to understand them and the authority to move them forward.

What matters is whether an engineer can raise a substantiated concern and get a decision before production makes it for everyone.

Eventually, you stop volunteering

When that repeatedly fails, your behavior starts to change.

I’m an SME in my environment. Engineers in APAC and London rely on me when they run into problems they can’t figure out. For a long time, I made myself available because I knew the systems, cared about the outcome, and wanted to help the people dealing with the incident.

But losing sleep over problems you haven’t been given backing to fix gets old.

You become less available. You stop chasing the same recommendation through another round of discussions. You find yourself watching a familiar problem develop and feeling less urgency than you once did.

There’s anger in that. There’s resignation. Eventually, there’s apathy, which is probably the most troubling part. You remember how much effort you used to put into making things better, and you can explain exactly why you stopped.

Management will sometimes notice the withdrawal before it notices the years of ignored effort that preceded it. An engineer who used to volunteer now needs to be asked. Someone who always had suggestions has gone quiet. The person who answered every late-night message starts protecting their sleep.

By then, the organization has already received plenty of feedback. It just arrived as incident reports, test results, wiki pages, and requests for support.

Good engineers have a finite amount of energy to spend convincing people to let them do good engineering. If every improvement requires a prolonged campaign, eventually they start choosing where that energy goes.

The next time the phone rings at two in the morning, they may finally decide to stay asleep.