There are no best practices in complex systems

This is uncomfortable and I think organizations resist it instinctively. Because Software development is complex, not complicated, best practices can't exist in the traditional sense.

In simple/clear domains, best practices exist. The relationship between cause and effect is obvious, allowing for a best practice to be described regardless of context.

In complicated domains, good practices exist. There may be a clear relationship between cause and effect, but discerning it requires expert analysis. With multiple right answers, one can only define good practice, not best practice.

In complex domains, only emergent practices exist. The relationship between cause and effect can only be determined in retrospect. Practices cannot be "best" or "good"; they must be discovered through trial and error, experimentation, and study. In this way, practice is emergent.

This doesn't mean nothing matters. Some patterns produce better outcomes. TDD. Continuous integration. Small batches. Fast feedback. These patterns emerge out of understanding that The correct response to complexity is probe, sense, respond.

I think this has implications for the product engineer role. The uncertainty on the product side (what should we build?) and the uncertainty on the engineering side (how do we build it well?) are the same type of uncertainty. Both require probe, sense, respond. Both resist upfront specification. Splitting them into separate roles assumes clean handoffs that don't exist. This realization is central to The increase in uncertainty drove each era of software development practices.