>Usually, this isn't because your developers don't understand "the rules" and / or don't like you—it's because they know what the organization values, and those values are in conflict with your "rules," and they're trying to deliver that value.

I'm bailing out here. Tautological statements that your actions already represent your desires are a rhetorical tarpit.

After the unnecessary effort to work backwards from what was originally communicated, it will become one of:

A) A narrow message presented as a wide message

B) a motivating lie meant to reinvigorate people into working on second order desires

C) an unnecessarily bold proclamation that the process of change is complicated (and you might be setting yourself up for failure)

D) obviously incoherent and unfounded rubbish which ought to be ignored

> There's a military axiom—"You can dictate results or you can dictate process, but not both.

This certainly doesn't apply to the domain of critical-systems software engineering. I realise the emphasis of the article is meant to be agile methods, but the claims made seem quite categorical, and they don't hold up.

The most well-known coding-standard of this sort is MISRA C. NASA has one too, as does the Joint Strike Fighter project, and there are plenty of others. When these standards are taken seriously, developers aren't permitted to treat them as mere guidelines.

Plenty of organisations may be sloppy with their enforcement of coding standards. It's also possible for bad standards to be actively counterproductive. That doesn't mean they're always misguided and always impossible to enforce.

> The problem with abandoning the fear of failure is that it requires trusting our developers, a lot.

I defer to an excellent article on critical-systems software development: [0]

> the culture is equally intolerant of creativity, the individual coding flourishes and styles that are the signature of the all-night software world. “People ask, doesn’t this process stifle creativity? You have to do exactly what the manual says, and you’ve got someone looking over your shoulder,” says Keller. “The answer is, yes, the process does stifle creativity.”

> Real software quality is not a set of shared rules, but a set of shared values.

There's a reason avionics software development does not share this contempt for rules. Of course, there's far, far more to building life-and-death software than just following a coding-standard, but still.

[0] https://www.fastcompany.com/28121/they-write-right-stuff