The most valuable engineers I've worked with often looked... less "productive". They weren't always the fastest at closing tickets. They didn't push the most code. Sometimes it even felt like they were slowing things down.
And yet, somehow, teams around them ended up dealing with a lot less bullshit six months later.
Typical story: an API occasionally responds in 10 seconds under load. Not always. Just often enough to become painful. A ticket shows up: "Need to fix slow responses ASAP."
One engineer goes for the obvious fix: "Let's add caching."
A couple of days later, the issue seems gone. Everyone's happy. Ticket closed. Velocity looks great.
Then the familiar magic begins: cache invalidation becomes painful, stale data starts showing up in weird places, edge cases multiply, more patches pile on top, and a month later the system is more complicated than before the "fix".
Another engineer does the thing people often hate: instead of immediately writing code, they start asking why the problem exists in the first place.
And suddenly it turns out the backend isn't really the issue. The frontend is hammering the API because it has no proper way to receive updates.
So instead of another caching layer, the solution becomes boring but clean: events, change notifications, fewer requests, less state, less magic.
In the moment, the second engineer looked slower. They asked annoying questions. They added friction. Maybe they even irritated people a little.
But six months later, systems around people like that somehow tend to be simpler, more stable, and easier to work with.
And I think this is one of the strangest things in our industry.
We're very good at measuring delivery speed. We're much worse at noticing engineers who reduce the amount of future pain inside a system.
And these aren't necessarily "10x architects" or technical geniuses.
Often they're just the people who ask an uncomfortable question at the right moment:
"Wait. Are we actually solving the right problem?"
The funny part is that these are usually the engineers people try to bring with them from company to company, pull into difficult projects, and retain at almost any cost.
Even though their value is incredibly hard to measure formally.
Have you worked with engineers like this?
Top comments (1)
This is a great observation—and honestly, a painful truth for a lot of teams.
The “slow” engineer is often the one optimizing for system health, not just ticket velocity. Short-term, they look like friction. Long-term, they quietly remove entire classes of problems.
I’ve seen the same pattern: quick fixes boost metrics this sprint, but thoughtful solutions reduce incidents for the next six months. Guess which one actually scales 😄
The tricky part is most dashboards reward output, not avoided complexity. That’s why these engineers are undervalued until things start breaking.
And yes—those “are we solving the right problem?” moments are usually where real engineering begins.
If this resonates, feel free to check my profile website and reach out—happy to discuss how teams can better recognize and support this kind of impact.