Normative Ethics for Engineers: A Working Team's Primer

A working engineer rarely has time for ethics. They have deadlines, postmortems, and a queue of ambiguous tickets. Yet the judgments their system makes in unanticipated cases will come from somewhere — and that somewhere is, implicitly or explicitly, a normative commitment. This primer distills four traditions engineering teams actually reach for into three heuristics each, written so a team can paste them into an internal doctrine document and start arguing from them on Monday morning.

Consequentialism

Consequentialism fixes attention on outcomes. It is the tradition most familiar to engineering organizations because it shares their vocabulary: maximize, minimize, weight, discount. Its weakness is that some of the things we care most about are not aggregable; a decision that protects a small number of people from severe harm is not always made better by one that protects a large number from slight harm, and the metric cannot see the difference. Used honestly, however, it forces the team to ask, before shipping: who is harmed, by how much, and for how long?

• Optimize the worst-off stakeholder, not the average.
• Estimate second-order effects on trust, lock-in, and downstream reuse before shipping.
• Weight long-tail harms of edge-case users at parity with median users in your test cohort.

Deontology

Deontology fixes attention on what kinds of acts are permissible regardless of outcome. It is the tradition most familiar to legal and compliance teams because it shares their vocabulary: rights, duties, inviolable categories. Its weakness is that it sometimes refuses to act when the world insists; a deontological guardrail that cannot be overridden even in a case where every tradition would agree it should be is a guardrail that will eventually be removed by someone in a panic. Its strength is that it gives engineers a clear refusal vocabulary when they need one.

• If a stakeholder cannot validly consent, default to exclusion.
• Treat reversibility as a hard constraint: do not deploy what you cannot walk back.
• Document the duties you are declining and why — silence is not consent from you either.

Virtue Ethics

Virtue ethics fixes attention on the kind of agent that is acting. It is the tradition most familiar to people who have spent years in a profession and learned, by accretion, what a good practitioner does. Its weakness is that it does not, on its own, give crisp answers to hard cases; a virtuous agent who has never faced one will discover, at the worst possible time, what they actually believe. Its strength is that it produces practitioners who defend their reasoning — not just their results — under pressure.

• Ask what the engineer you most respect would do here, then write the design doc to that bar.
• Cultivate the discipline to refuse ambiguous work — character is built by what you decline, not what you ship.
• Treat craftsmanship as a moral act: ship code you would be willing to maintain for years.

Care Ethics

Care ethics fixes attention on relationships, dependency, and the particular stakeholders a system touches. It is the tradition most familiar to on-call engineers and customer-facing teams, because their work is sustained rather than one-shot. Its weakness is that it scales imperfectly — particular obligations are hard to generalize, and care can quietly justify exception creep. Its strength is that it adapts to relationships that consequentialism cannot enumerate and deontology cannot audit, and it keeps the team honest about who the system is actually for.

• Map who depends on the system — and on whom those dependents depend — before optimizing throughput.
• Preserve continuity of care across releases: do not strand users on deprecated paths without an active hand-off plan.
• Treat sustained, attentive support — not one-shot launch fixes — as the default obligation.

No tradition alone is sufficient. The serious engineering choice is rarely between traditions and never between one tradition and “no tradition”; it is between a tradition the team can argue from and the implicit, undefended defaults the engineering culture happens to carry. Heuristics are how a team starts that argument on a real artifact.

These heuristics are not a doctrine. They are the start of one. The real work begins when a team argues, against a particular decision on a particular incident, whether the heuristic on the wall still holds — and rewrites it when it does not.