What separates top-performing engineers

Engineering performance is hard to measure.

And it’s hard to describe in a single sentence.

But when you can tell the difference between top performance when you see it.

You want to fight for a top-performing engineer to retain them on the team.

Working with a low-performing engineer typically leads to considerable frustration for everyone involved.

I’ve been thinking about what differentiates top-performing engineers from the rest.

What’s interesting is that it doesn’t seem to correlate with technology proficiency.

It’s not uncommon that engineers who have less intimate knowledge of the specific technology write better software than those who use the most sophisticated constructs.

I have seen that engineers with no commercial experience in a particular technology have been able to resolve issues and deliver more reliable solutions than engineers who have been working with the technology for years.

So if it isn’t technical proficiency, then what is?

I’d argue that the qualities that separate top-performing engineers are more subtle, such as attitude, ownership, and standards.

It’s hard to describe exactly what they are because they’re less tangible than technical skills.

But here are a few recurring themes that I have been noticing

Standars

Top-performing engineers seem to have higher standards.

They know what good code, architecture, and user experience are

And then they don’t consider their work as done until it reaches this standard.

Low-performing engineers are perfectly content shipping half-baked solutions to production.

And not because they want to do poor work, but because it’s good enough in their eyes.

Ownership

Low-performing engineers tend to write unmaintainable and brittle solutions.

And usually have plenty of excuses why it isn’t up to scratch.

E.g., “It was like that before me, so I just made my changes.”

or “I wasn’t told from the beginning that it would be that way.”

While top-performing engineers write maintainable code, regardless of what it looked like before them.

And treat changing requirements as given and account for that.

They take ownership of the code they work with and treat it like their job to write maintainable code.

Long-term solutions

The way top-performing engineers approach troubleshooting also separates them from the rest.

Low performers tend to choose the path of least resistance and fix local problems with band-aids.

This usually means that it doesn’t fully resolve the problem, but adds layers of complexity instead.

While top performers look for the root cause and implement a long-term solution.

It’s not unusual for fixes from the top-performing engineer in a PR to look like hundreds of deletions and a couple of additions.

They fix the root problem and remove band aids.

These are my observations on what distinguishes top-performing engineers.

While technical proficiency is important and a prerequisite for delivering any solution.

I believe that less tangible qualities can significantly impact performance after an engineer has achieved foundational technical proficiency.