What Separates Good Engineers From Great Engineers
Every senior engineer you have ever worked with who made their team dramatically better shared something you could not quite name at the time. It was not that they wrote cleaner code. It was not that they knew more. It was something about how they made decisions, especially under pressure, that made outcomes better in ways that were hard to attribute to any single action.
The gap between good and great engineering is not primarily technical. Technical skill is the entry requirement, not the differentiator. The actual gap is in judgment — and judgment is harder to teach, harder to observe, and much harder to measure than code quality.
Technical Competence Is the Floor, Not the Ceiling
A good engineer solves the problem in front of them. A great engineer asks whether the problem in front of them is the actual problem.
This sounds simple. In practice, it requires a kind of discipline that goes against the instincts most engineers develop early in their careers. Early engineering rewards competence: you get tasks, you complete them, you get credit. The incentive structure trains you to solve the defined problem as efficiently as possible. Questioning whether the problem was defined correctly feels like obstruction, not engineering.
Great engineers have learned — usually through painful experience — that the cost of building the wrong thing well is much higher than the cost of clarifying what you are actually supposed to build. They ask upstream questions. They push back on requirements that do not make sense. They ship things that do not need to be built, but they also say "I think we are misunderstanding what users actually need here" before the sprint starts rather than after it ends.
The Judgment Gap: When to Push, When to Hold
Most engineering decisions exist on a spectrum between "ship it and iterate" and "slow down, this needs more thought." Good engineers know which technical problems require careful design. Great engineers also know which non-technical pressures should and should not move that judgment.
This is where the gap is most visible. Under deadline pressure, the temptation is always to cut corners — skip the review, skip the test, merge without the discussion. Good engineers recognize these shortcuts as technical debt. Great engineers know how to have the conversation with a stakeholder about why this particular shortcut will cost more than it saves, in terms that the stakeholder can act on, in the time window available.
The sunk cost fallacy hits engineers especially hard. When a team has spent three months building an architecture that turns out to be wrong, the rational engineering decision — start over, or at least acknowledge the error and redesign — feels psychologically impossible. Great engineers have the technical credibility and the interpersonal skill to say "we need to rethink this" and be heard, rather than watching the wrong architecture get shipped because no one wanted to be the person who killed three months of work.
Test your engineering judgment
10 real engineering dilemmas: budget cuts, safety risks, deadline pressure. Which trade-offs would you make?
Communication as a Core Engineering Competency
The most common complaint about good engineers from non-engineering colleagues: "They are technically excellent but impossible to understand." The most common thing said about great engineers by exactly the same non-engineering colleagues: "They make me feel like I understand what is happening."
This is not about dumbing things down. It is about understanding what question the person you are talking to actually needs answered, and answering that question in the terms that are useful to them. A product manager asking about a production incident does not need a root cause analysis in terms of distributed systems theory. They need to know: What broke. Why it broke. When it will be fixed. What is being done to prevent it from breaking again. In that order, in that level of specificity.
Great engineers develop a mental model of their audience that runs in parallel with their technical model of the problem. They are thinking about the system and simultaneously thinking about who needs to know what about the system. This is not a soft skill that sits alongside engineering. It is an engineering skill that determines whether the technical work actually produces value.
Long-Term Thinking in a Short-Term World
Technical debt is one of the least understood concepts in software development, even by engineers who use the term constantly. The usual framing — "we took a shortcut, we owe debt, we will pay it back later" — is technically accurate but misses the more important point: technical debt is an engineering decision with a financial structure, and like all debt, it needs to be managed, not just acknowledged.
Great engineers think about technical decisions in terms of their time horizon. Some decisions look expensive now but cheap over time. Some look cheap now and become catastrophically expensive. A quick fix that handles today's load but will need to be rewritten at five times the scale is not necessarily wrong — it depends on whether "five times the scale" is likely in the next six months or the next five years.
What separates great engineers on this dimension is not that they always choose the long-term option. It is that they make the trade-off explicit. They say "this decision is optimized for speed now and will cost us roughly three sprints in six months, and here's why that is or is not the right call given where we are." The team then makes an informed choice rather than accumulating debt through a series of decisions nobody was conscious they were making.
Safety Culture: The Willingness to Be the Difficult Person
In engineering — whether civil, chemical, software, or any other domain — safety failures are rarely caused by the absence of someone who knew a problem existed. They are caused by the absence of an environment where raising that problem felt possible.
The structural failure of a bridge does not happen because no one observed the anomalous load readings. It happens because the person who observed them calculated, correctly or not, that saying something would be unwelcome, costly, or dismissed. The production deployment that broke because of a known risk went out because the team member who flagged it did not feel empowered to stop it.
Great engineers carry safety culture in two directions. They make it easier for others to raise concerns — they respond to "I think this might be a problem" with curiosity rather than defensiveness, and they model the behavior of being the person who says "wait, let's look at this more carefully" in a room that has decided to move fast. And they also do raise concerns themselves, even when it is uncomfortable, because they understand that the default pressure-response pattern in engineering teams is to go along with momentum rather than break it.
The Compound Effect of Decision Quality
Great engineers are not right more often than good engineers in any dramatic way. The difference is often subtle — a slightly better question at the right time, a slightly more considered call on a trade-off, a slightly more honest conversation about risk. But these small differences compound over months and years in ways that become very large.
The team that consistently makes slightly better decisions about architecture ends up, three years later, with a system that is dramatically more maintainable than the team that made slightly worse ones. The engineer who consistently raises concerns at the right moments, and communicates them in ways that are heard, ends up having prevented problems that their equivalent with less judgment would have let through.
Decision quality is not dramatic. It does not announce itself. It accumulates quietly, in one direction or the other, over time. Which is why developing it deliberately — practicing the judgment calls, examining the defaults, stress-testing your frameworks — matters more than any single decision you will ever make.
Get a new scenario every week
One decision challenge, delivered to your inbox. Free, no spam.
Test yourself
Want to see what kind of engineer or leader you are becoming? Take the Leadership Style quiz — it only takes a few minutes, and every answer comes with an explanation.
