This is a useful skill to employ, though at the same time the frequent need of it is a sign of a dysfunctional system. Not always, but a lot of the time, I think. For one, many of these issues would be avoided if, for example, engineers were included in meetings with decision makers and designers during early phases of development, rather than introduce engineers to effectively tell them what to do now that all the decisions have been made absent any shared knowledge of how things can work under the hood. Not only could this result in reduced time spent, but it could result in less time performing re-iterations once engineering concludes that a request/feature is impractical. Impracticalities or better alternatives should be discovered as early in the process as possible, not later, because inevitably wasted time will be made up for via shortcuts and duct tape. Unless a company really cares about good craftsmanship and not releasing something until it's in an adequate state, quality will almost certainly be sacrificed.

Playing dumb, if you will, has served me well, yet it is also odd to me just how often it needs to be employed in the field of software.