Early in my career, I learned that if I wasn't sure how something was supposed to work, I needed to ask sooner rather than later, because it was unlikely to get clearer all by itself. No matter how ignorant it made me look.

I learned that too.

Then years later I learned that asking too many questions early on that people don't know the answer to gets me a reputation of being "awkward", "negative" or "not a team player". It's not "agile" to properly understand a problem before trying to solve it, apparently!

These days I limit the early questions to ones on which fundamental architecture and technology decisions rest. My estimates incorporate an "unknown unknowns" line.

A lot of problems worth solving have a long tail of 9's to chase down, i.e. 99.999%

Self driving cars is one of those projects.

It's not so much that high-value problems have a long tail to chase down.

All problems are like that; the difference for high-value problems is that working on the tail is worth doing, because the problem is high-value.

It's when the bits that were "unknown unknowns" start to matter.

exactly, usually it turns out the final 20% are actually >50%