"Outrageous" or "out-of-the-box" solutions are just very lateral solutions to a problem, and in an engineering context you can do this by questioning the assumptions of the problem until you've reframed it enough to allow these solutions to seem more "obvious".
Here's a very silly and simple example: you have an engineering task to search for an ID in a tree data structure. You may know several standard methods off the top of your head or you may look up the best performing algorithm online. Either way, the solution is the expected one.
But let's abstract the problem: Why do you need to search for an ID in a tree data structure? Do you need a tree in order to keep track of the path and the IDs you pass? If not, then why not scrap the tree completely and go with a hash map of key/value pairs? That solution is both faster and easier to implement, but it only occurs if you think about the goal of the problem instead of the problem itself. You can abstract it even further and ask whether IDs are required at all, and if they aren't what other solutions could be used to accomplish the same goal. This is a very, very simple example but the idea can be applied to varying degrees in any problem, and kind of comes to the idea of finding first principles in physics.
Agree with this approach. I had a manager tell me once that managers think differently than engineers and I asked him to explain. He gave the example of asking an engineer how to turn on a light bulb. The engineer (me) would/did say to flip the light switch. He said that manager would ask why do you need to turn on the light bulb? What is it in the room that needs to be illuminated? Maybe your real purpose is to figure out if there is a certain item in the room, and there is a better way to figure that out than turning on the switch.
As an engineer, I am aware that my mind often plots the shortest path from problem to solution, without ever stopping to question the problem definition. Sometimes reframing the problem is the best way to get to a more creative solution.
As an engineer, the thing I always prided myself on was always asking my customers/stakeholders ”Ok but what’s the problem you’re solving? Why do you need this?” before jumping to a solution to their initial ask.
Often they ask for a solution to the 3rd step in their process where they got stuck and it turns out the underlying problem is easier/faster to solve
Here's a very silly and simple example: you have an engineering task to search for an ID in a tree data structure. You may know several standard methods off the top of your head or you may look up the best performing algorithm online. Either way, the solution is the expected one.
But let's abstract the problem: Why do you need to search for an ID in a tree data structure? Do you need a tree in order to keep track of the path and the IDs you pass? If not, then why not scrap the tree completely and go with a hash map of key/value pairs? That solution is both faster and easier to implement, but it only occurs if you think about the goal of the problem instead of the problem itself. You can abstract it even further and ask whether IDs are required at all, and if they aren't what other solutions could be used to accomplish the same goal. This is a very, very simple example but the idea can be applied to varying degrees in any problem, and kind of comes to the idea of finding first principles in physics.