The correct response to complexity is probe, sense, respond

In complicated domains, you sense, analyze, respond. Gather information, apply expertise, pick from a set of good practices.

In complex domains, you flip it: probe, sense, respond. Why flip it? Because Software development is complex, not complicated.

Probe: small controlled experiments. Not random changes. Intentional tests. Ship a small feature. Deploy to a subset. Make one architectural change and watch what happens.

Sense: observe. The system will have adapted in ways you couldn't predict. Maybe response time confuses users who expected to wait. Maybe a new feature collides with platform changes you didn't see coming.

Respond: only now do you decide what to do next, based on actual evidence rather than a plan you made before you had information.

This is how science works. This is how engineering works when it's honest about uncertainty. And this is definitely how successful software gets built. This is only viable because Agile practices only make sense when iteration is cheap. This wasn't always possible—see Slow feedback loops and expensive computing forced optimization for machines over people.

For product engineers specifically, this means accepting that your guess about what users want, how the design should work, whether your architecture will hold up... all of it might be wrong. The question isn't how to eliminate uncertainty. It's how to organize work so you discover mistakes quickly and cheaply. Understanding this mindset is key to The increasing in uncertainty drove each era of software development practices.