Fixing the machine at the factory can be quite complex, but you might have a technician in and out in a day or two to get it done.
Assembling 5,000 identical widgets is not complex, but it might takes you weeks or months.
Complexity and wall time occasionally move the same way on the graph (generally with wall time climbing much faster than our view of complexity), but they’re not necessarily or always so.
I tend to explain “complexity” more in terms of “at what skill level of employee would we stop seeing substantial gains in quality/speed/maintainability/etc when we assign this work out”.
Something that a senior could do substantially better/faster than an intermediate is “high” complexity. Something that the intermediate could do substantially better/faster than the junior is “medium” complexity.
Adding some fields to a form is low complexity—an intermediate or senior won’t do a substantially different job than the junior—but doing 10 fields versus 100 fields will change the amount of time it takes quite a bit. Architecting a new service will see gains to senior and beyond and is high complexity but may not actually take all that long.
Ultimately, this boils down to “how many decisions remain to be made”. Most tasks can be made lower complexity by making those decisions in detail. “Rearchitect this module” becomes medium complexity when someone turns that into “rearchitect this module following X pattern” and low when someone turns it into “move methods A, B, C into new class X and split method D into E and F along this line”.
This view of complexity doesn’t directly drive wall time, but _does_ very directly impact the variability of that estimate. The more decisions remaining and the more unknowns up front, the wider the range of possible outcomes. Reducing the complexity will reduce the range of estimates.