Good Engineers vs Great Engineers: A Practitioner View

“Great engineer” is a subjective label, not a credential or measurable personality type. This article uses it to describe engineers whose work improves the team's ability to deliver, operate, and learn—not only the amount of code one person produces.

The perspective is mine: I am a software, cloud, and DevOps engineer, and the examples focus on software and production systems. They should not be generalized to civil, mechanical, medical-device, or other regulated engineering disciplines with different qualifications and safety duties. Published material from DORA, Google Site Reliability Engineering, NIST, and the ACM provides external reference points; the seven-part synthesis is my own.

1. They Clarify the Outcome Before Optimizing the Solution

A competent engineer can implement a well-defined task. A higher-impact engineer also checks whether the task represents the real user or operational problem.

Useful questions include:

• Who experiences the problem?
• What observable outcome should change?
• Which constraint is fixed, and which is only assumed?
• What is the smallest test that would reduce the important uncertainty?
• What would make this work unnecessary?

This is not permission to challenge every requirement indefinitely. The aim is to avoid efficiently building the wrong thing and to make disagreements visible while they are still cheap to resolve.

2. They Prefer Short, Safe Feedback Loops

Large batches hide errors for longer. DORA describes continuous delivery as keeping software deployable and using fast feedback, comprehensive testing, observability, and security to make changes safer and more sustainable.

In practice, this often means breaking work into reviewable changes, automating repeatable checks, exposing behavior in a realistic environment, and releasing through a process that can detect and limit harm. “Move fast” is useful only when the system can tell the team what happened and recover responsibly.

The goal is not deployment frequency for its own sake. It is reducing the distance between a decision and trustworthy evidence about that decision.

3. They Match Engineering Effort to Risk

Not every change deserves the same ceremony. A copy adjustment on a reversible internal tool differs from an authentication change, destructive database migration, or payment workflow.

A practical review asks:

• How wide is the possible impact?
• Is the change reversible, and has reversal been practised?
• Could it affect confidentiality, integrity, availability, safety, or legal obligations?
• What evidence supports release?
• Who must understand or approve the risk?
• What monitoring would reveal failure?

NIST's Secure Software Development Framework is explicitly risk-based and intended to be adapted to an organization's needs, resources, and mission. Strong judgment is not choosing maximum process; it is refusing to treat unequal risks as equal.

4. They Communicate Decisions, Not Only Technical Detail

A design can be technically sound and still fail if the people affected do not understand the trade-off or their role in it. Communication is part of engineering because systems are built, funded, used, and operated by groups of people.

A useful engineering decision record can be brief:

• context and problem;
• options considered;
• decision and owner;
• important trade-offs;
• evidence and assumptions;
• review or reversal trigger.

For an incident update, the audience may need impact, current status, mitigation, next update time, and known uncertainty before receiving a detailed root-cause explanation. Clear communication does not mean removing technical truth; it means presenting the information needed for the next decision.

5. They Make Reliability and Security Part of the Design

Quality is not a final testing phase delegated to someone else. NIST groups secure development around preparing the organization, protecting software, producing well-secured software, and responding to remaining vulnerabilities. DORA likewise treats testing, security, observability, and deployability as connected capabilities.

A higher-impact engineer asks early how the system will be monitored, how access is limited, how dependencies are managed, how data is recovered, and what happens when a component fails. They do not assume that passing tests proves the absence of risk.

This habit is especially important under deadline pressure. A shortcut should be named with its consequence and follow-up owner, not quietly converted into permanent behavior.

6. They Create Conditions Where Problems Can Be Reported

The original version of this article made dramatic claims about bridge failures without evidence. The software-specific lesson can be stated more carefully: teams learn less when people fear blame for reporting a mistake, weak signal, or near miss.

Google SRE describes a blameless postmortem as a written record of an incident, impact, response, contributing causes, and preventive actions. Its purpose is learning and reducing recurrence, not pretending that accountability or individual choices never matter.

An engineer strengthens that culture by responding to a concern with investigation, separating facts from hindsight, sharing what was learned, and ensuring follow-up actions have owners. A postmortem with no review or completed action is only documentation.

7. They Leave the Team More Capable

Individual heroics do not scale. Higher-impact engineers reduce recurring manual work, document the parts that are hard to discover, make review easier, mentor without creating dependency, and design ownership that survives their absence.

This can look less impressive than personally solving every emergency. Over time, however, a team with clearer systems, safer changes, and shared context can handle more work without relying on one irreplaceable person.

The ACM's software-engineering guidance treats communication, professional responsibility, and public impact as core parts of the discipline. That is a useful correction to career advice that measures engineers only by technical cleverness.

A Seven-Question Self-Review

After a project or incident, ask:

1. Did we solve the stated task or the verified problem?
2. How quickly did we receive trustworthy feedback?
3. Was the process proportional to the actual risk?
4. Could affected people understand the decision and trade-offs?
5. What protected users and the system when an assumption failed?
6. What did we learn, and which follow-up action is owned?
7. Is the team more capable of handling this without me next time?

These questions do not rank someone as good or great. They turn an aspirational label into observable practices that can be reviewed.

Check Related Skills

The Leadership Style Quiz is an educational knowledge check covering leadership concepts and team decisions. It does not measure engineering seniority or determine whether someone is a good engineer.