If like me you're wondering how a problem can be "wicked" and scoured the summary with a growing sense of futility: it turns out to be a term in social planning that means a problem that's difficult or impossible because of incomplete, contradictory, and changing requirements.<p><a href="https://en.wikipedia.org/wiki/Wicked_problem" rel="nofollow">https://en.wikipedia.org/wiki/Wicked_problem</a>
I've seen something like this in B2B consulting. The decision makers (our customers) have a difficult time parsing all the complex variables and wind up making really bad assumptions that turn into a vicious cycle of broken expectations and even more complexity. I think the basic human flaw here is impatience.<p>The opposite experience was had in semiconductor manufacturing. Not a soul in those engineering offices would hazard the remotest assumption about a problem until many hours of confirmation occurred first. No one wanted to be the reason something got even more complicated.
Interesting intellectually, but sort of self-defeating as a field of inquiry. The delineation between wicked and non-wicked problems is itself effectively arbitrary and artificial. It is odd and somehow amusing to see the 'academic' (analysis-paralysis) lens focusing on perception failures in the (bias toward action/fail fast/fail forward) field of 'entrepreneurial' activity.<p>Compare to received startup wisdom: reduction is fine, often 80:20 is good enough, and failures are expected. You miss all the shots you don't take. Sometimes moving in the right general direction with wrong perception is the best path to progress. Learning is a goal.<p>The percentage of failed ventures which can be directly attributed to reduction-related problems of founder perception is probably very small.
It's quite possible these people charging into these wicked problems don't understand they are charging into a wicked problem.<p>Nearly every problem involving people or the environment is going to become a wicked problem. The problem space is just so big and you can't really test at the scale you'll have to implement on.<p>And it's hard to know what works and what doesn't. Because sometimes things can get better due to something else and your solution just happened to be implemented while that was happening. And it's not like you can isolate either.<p>Essentially, you're always testing in production.
Test case based problem solving. Write some hilariously simple test case scenarios, solve those, ship it! I have yet to find a workplace that doesn't suffer from this bias towards simplicity in inherently complex problems. How do you explain to non-technical folks "its not that simple" without looking like a sandbagging son-of-a?