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.

Simple/clear domain: best practices exist. Categorize the situation, apply the known best response.

Complicated domain: good practices exist. Expertise matters. There are right answers if you analyze carefully enough.

Complex domain: only emergent practices. You can't categorize what comes next because the system changes each time you interact with it.

This doesn't mean nothing matters. Some patterns produce better outcomes. TDD. Continuous integration. Small batches. Fast feedback. But these are patterns discovered through iteration, not rules you install and forget. These patterns emerge through The correct response to complexity is probe, sense, respond. These are what Methods, methodologies and mindset calls emergent practices, not prescriptive methodologies.

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 increasing in uncertainty drove each era of software development practices.