Safety Culture

Engineering Ethics Case Studies in General Terms

Common engineering ethics dilemmas such as schedule pressure, conflicts of interest and unwelcome test results, walked through as general patterns with questions to ask.

On this page
  1. Why use patterns instead of famous cases
  2. A simple way to work through any case
  3. Pattern 1: Schedule pressure
  4. Pattern 2: Conflict of interest
  5. Pattern 3: An unwelcome calculation or finding
  6. Pattern 4: Pressure to overstate
  7. Pattern 5: Knowing something is wrong, but it is not your area
  8. Using these in a team

Why use patterns instead of famous cases

Ethics is easier to learn from a story than from a rule. But real, well-known cases are often complicated by legal findings, disputed facts and the emotions of those affected, and it is easy to repeat a detail incorrectly. This article instead describes recurring patterns, using short invented scenarios. They are illustrations, not accounts of real events, and any resemblance to a specific organisation is coincidental.

A general note first. Professional codes of ethics, laws and licensing rules differ between countries and industries. Many engineering bodies publish codes that put public safety first, but the details vary, and these examples are not legal or professional advice. Where you face a real dilemma, consult the code and the qualified people that apply to you.

A simple way to work through any case

Before the scenarios, here is a short set of questions that fits most dilemmas:

  1. What are the facts? Separate what is known from what is assumed.
  2. Who could be affected? Include users, the public, colleagues and the environment, not just the client or employer.
  3. What obligations apply? Think about laws, standards, contracts, professional codes and company policy.
  4. What are the options? There are usually more than two, including ways to buy time or ask for help.
  5. What could go wrong with each option? Consider harm that is small but likely and harm that is rare but severe.
  6. Who else should be involved? A mentor, a senior engineer, a safety officer or a professional body may offer a view.
  7. Could you explain your choice openly? A decision you would be uncomfortable describing to colleagues or the people affected deserves a second look.

Pattern 1: Schedule pressure

Scenario (invented). A team is preparing a product for release. A verification test shows a component behaving at the edge of its allowed range under hot conditions. Re-testing would take two weeks. The launch date is public and a manager suggests the result is probably a one-off and that the test should be quietly repeated until it passes.

What is going on. The pressure is real, and wanting to meet a date is not unethical in itself. The problem is repeating a test until it gives the preferred answer, which hides information rather than resolving it. A result close to a limit is a reason to look at design margins, not to look away.

Reasonable responses. Record the result honestly. Investigate whether the cause is the part, the test setup or the conditions. Present the manager with options, such as a limited release, extra monitoring or a short delay, along with the risks of each. If the concern is serious and unresolved, escalate through the proper channels. Safety-related decisions are the kind that should not rest on one person’s quiet judgment.

Takeaway. Schedule pressure often arrives as a series of small requests. The ethical question is whether the information that decision-makers need is reaching them intact.

Pattern 2: Conflict of interest

Scenario (invented). An engineer is asked to recommend a supplier for a critical part. A relative of the engineer works at one of the candidate companies, and that supplier is not the strongest on technical merit but is competitive on price.

What is going on. A conflict of interest exists whenever a personal interest could reasonably appear to influence professional judgment, even if the engineer believes they would stay fair. The appearance matters because others cannot see inside the engineer’s head. Sound component selection depends on trust in the process.

Reasonable responses. Disclose the relationship early, before the decision is made, to a manager or the relevant compliance contact. Let someone else lead or at least review the evaluation, and document the criteria used. Many organisations have a policy for this; follow it.

Takeaway. Disclosure is usually far easier than explaining a hidden connection later. The test is not “am I honest?” but “could a reasonable person doubt that the decision was independent?”

Pattern 3: An unwelcome calculation or finding

Scenario (invented). A junior engineer checking a design notices that a key calculation by a respected senior colleague appears to use the wrong unit. If corrected, a margin would shrink noticeably. The junior engineer worries that raising it will seem presumptuous.

What is going on. This pattern mixes hierarchy, social pressure and the possibility that the junior engineer is the one who is mistaken. Both a wrong calculation and a wrongly accused colleague carry costs.

Reasonable responses. Re-check first, since simple sanity checks on the numbers and units may resolve it. Then raise it as a question rather than an accusation: “I may be misreading this, could you help me understand how the units work out here?” If the colleague is unreachable and the issue affects safety, use the team’s review process. Handling such moments well is part of raising safety concerns in a way that is respectful and effective.

Takeaway. Staying quiet to avoid awkwardness shifts the risk onto others. Asking a polite question costs little.

Pattern 4: Pressure to overstate

Scenario (invented). A sales team asks for a specification sheet to describe a product’s capability in the best possible light. The tested performance varies from unit to unit, and the strongest numbers were seen only in ideal conditions.

What is going on. Presenting a best-case figure as if it were typical misleads customers who may rely on it. It also touches technical honesty more generally: clear technical specifications should distinguish typical behaviour from guaranteed limits.

Reasonable responses. State figures with the conditions they apply to, and give worst-case values where customers could depend on them. Offer marketing alternative wording that is accurate yet appealing.

Takeaway. Honest communication of limits is part of the engineer’s job, not an obstacle to it.

Pattern 5: Knowing something is wrong, but it is not your area

Scenario (invented). While visiting another team’s lab, an engineer sees a safety guard removed from a machine and a hand-written note saying “don’t bother, it slows things down.”

What is going on. There is a temptation to assume that someone else has noticed or that it is not one’s place to comment. Bystander reluctance is common.

Reasonable responses. Mention it to the people working there, and if it is not fixed or if you are unsure of the standing rules, tell whoever is responsible for safety on site. Report it in line with local procedures.

Takeaway. Responsibility for safety is shared. Acting does not require certainty, just reasonable concern and a proper channel.

Using these in a team

Short invented scenarios like these work well in team discussions. Read one aloud, ask each person to note their first reaction, then talk through the questions above. Differences of opinion are useful, and it is fine to leave some cases without a single agreed answer. The purpose is to rehearse the thinking so that it is available under real pressure.

The complete guide to safety culture

Safety Culture in Engineering Teams
Read the guide

Keep exploring

Guides from other topics

All topics →