# Don't Tell Engineers What to Do

DevFeed: [Don't Tell Engineers What to Do](<https://devfeed.tech/articles/don-t-tell-engineers-what-to-do-20519.md>)

Original publisher: [Read original article](<https://code.dblock.org/2025/07/30/dont-tell-engineers-what-to-do.html>)

Author: Daniel Doubrovkine (dblock@dblock.org)

Published: 2025-07-30T08:00:00Z

Content type: opinion

Language: en

Sources: [Daniel Doubrovkine](<https://devfeed.tech/sources/daniel-doubrovkine.md>)

Topics: [engineering-culture](<https://devfeed.tech/topics/engineering-culture.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>)

Tags: [advice](<https://devfeed.tech/tags/advice.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [management](<https://devfeed.tech/tags/management.md>), [people](<https://devfeed.tech/tags/people.md>), [software](<https://devfeed.tech/tags/software.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

This opinion article argues that managers should not simply dictate technical decisions to engineers. It uses the Challenger disaster and several software failures to illustrate the risks of sidelining engineering judgment, then distinguishes managerial direction from peer-level disagreement and commitment.

## Source excerpt

A famous example where telling Engineers what to do backfired was the Space Shuttle Challenger disaster in 1986. Engineers at Morton Thiokol, the contractor responsible for the shuttle's solid rocket boosters, warned NASA management that the O-rings in the boosters could fail in cold weather. The night before launch, engineers strongly recommended delaying the launch due to unusually low temperatures. Management, under pressure to proceed, overruled the engineers' concerns and told them to "make a recommendation based on data, not emotion." Eventually, management told the engineers to sign off on the launch, despite their objections. The shuttle launched in cold weather, the O-rings failed, and the Challenger exploded, killing all seven astronauts on board. This wasn't a software problem, but plenty of software engineering disasters are documented. The Knight Capital Group trading loss (2012), where rushed deployment caused a $460M loss, the Ariane 5 rocket failure (1996), where reused code not designed for the new rocket led to its destruction, the Therac-25 radiation overdoses (1985-87), where ignoring software safety warnings resulted in patient deaths, and the Healthcare.gov launch (2013), where ignoring technical advice led to a high-profile, catastrophic rollout. In each case, sidelining engineering judgment in favor of business or schedule pressures led to major failures. I bet you have your own disaster story. To quote you, "I told you so!". Yet, engineering managers continue telling engineers what to do every day. And not just engineers - all subordinates. Sometimes, it's time pressure. More often it is because managers are also engineers, and occasionally more experienced, so we think we just know better. Do we? I tell my direct reports that there's nothing I can make them do, but that there may be real consequences. I once refused to do something highly problematic my manager asked me to do, and instead said I'll think about it. It was a clever response,