Friends of ours recently visited the Vasa Museum in Stockholm, Sweden. They told us the story of the Vasa, a warship that sank almost immediately after setting out for her maiden voyage in 1628. According to Wikipedia:

“Richly decorated as a symbol of the king's ambitions for Sweden and himself, upon completion she was one of the most powerfully armed vessels in the world. However, Vasa was dangerously unstable due to too much weight in the upper structure of the hull. Despite this lack of stability she was ordered to sea and foundered only a few minutes after encountering a wind stronger than a breeze. The order to sail was the result of a combination of factors. The king […] was impatient to see her take up her station as flagship of the reserve squadron […]. At the same time the king's subordinates lacked the political courage to openly discuss the ship's structural problems or to have the maiden voyage postponed.”

In contrast, this contemporary story from David Loftesness, as told in This 90-Day Plan Turns Engineers into Remarkable Managers:

“One new, thoughtful engineer asked [Loftesness, Twitter’s Director of Engineering] details about the background of the project, and a few hard questions about its objective. 'Up until that moment, this was the project at the company. It was going to save Twitter, so no one questioned it,' recalls Loftesness. 'But after the engineer’s questions, we realized we had built the wrong product and cancelled the project.'”

That engineer, at that moment, was not a “resource reduced to a discrete set of skills” (Erik Dietrich – Don’t Be a Human Resource), but the voice of reason, and he was getting heard.

The voice of reason isn’t always getting heard, but if you trust your engineers, you’re usually better off. Mind you, software developers aren’t always right. Make sure they have all the context (goals, constraints), and they’re mature. But in the end – if your developers aren’t trustworthy, your software product is doomed anyway, right?