Architecture decision records (ADR) are an excellent way to show managers that work is proceeding, and that research is necessary, structured, timeboxed, and transparent.

https://github.com/joelparkerhenderson/architecture_decision...

This is a good answer.

What managers dislike is a lack of transparency. "Research" is very vague. How can anyone tell what you were researching, or what the result of it was?

A very clear spec doc is a useful tool - almost like writing an essay - to demonstrate what your research uncovered.

Agreed on the structure part: structuring research is incredibly helpful for guiding the research itself, knowing what’s left to do, and the nice bonus of also making it easier to share the results, both incremental and final.

Research is in many ways naturally more unstructured than other dev tasks and people don’t get too much practice at doing or delegating it, so it can be fertile ground for organizational misunderstandings. Structure agreed upon up front can help all that.

I think they key word in my post wasn't "structured" but "shows". Even if the occasion calls for 100% unstructured research (let's spend some time in the sandbox to see what we can do with some new software) it's a critical skill to be able to communicate what you learned during that phase with other people, even people with different job titles and backgrounds.

I suggested formalizing and structure as words because new features/products/projects are a common enough occurrence that we have standard procedures for it.

definitely needed this, thanks!