When you're designing a real-world engineering project, the entire specifications are defined legally (through national, state and local laws) and technically in manuals/books. Many engineering specifications will describe the work done to a T before you even need to think about it i.e. "water main shall be constructed of 12'' coated DIP at depth no less than 2 ft". A lot of the challenges are managerial and logistical.
All of this is on purpose. "Traditional" engineering disciplines are more mature and have the constraint of being safe for the general public. There isn't much room at all to creatively deviate from what's already specified.
I've found software design to be a lot more technically demanding in regards to designing and building things. There's a lot less precedent, more moving parts and many different ways to do one thing.
And I'm not blaming anybody -- for one thing college math is often badly taught, and there's a pervasive message that you won't use any of your math or theory after you finish your degree. And then we get them so busy with CAD and bureaucracy, that they forget a lot of their school stuff.
But anything requiring calculus or above, goes to a handful of "math people" in the department, who accept those tasks in return for avoiding the CAD and organization stuff. (I'm one of those people at my workplace, my degree is in physics).
To make it a bit harder, virtually all math these days is done with computation, which means a person has to be good at both math and programming at some level.
Some of the engineers who attract quantitative work are people who came from outside of the mainstream engineering training, such as scientists and math people.