At my current company (small startup) I wanted to convince people to talk through the issues and write things down or write down at least something. Think of user stories, requirements, personas, product vision, company vision, sprint goals.
In my opinion, writing things down helps to clarify your thinking and lets others understand how you think. It also reduces the risk of the devs implementing something that doesn't fix the users' issue.
They think writing things down is overhead, too much "process", too much time. What they (IMO) don't see is that discussing requirements, assumptions before developing a feature (or even prioritizing a feature) helps to establish a common understanding of the issue and the proposed solution.
Finding a way to show them might be difficult, but rewarding.
(unsolicited advice) What I've learned in working on that skill; avoid coming from a position of supremacy, and rely on actions/results to communicate most of the message. Also, a lot of acceptance and patience.
I like to write a lot of pseudo code before real code, gradually digging down into lower level implementation details, so as to not waste time worrying about syntax while making higher level decisions.
However, it's taken me a long time to develop what I have of that skill; to feel out the different layers decisions will be made, then write pseudocode with the intent of eeking out and resolving most of them.
Doing so, things end up feeling more like trade-offs than compromises.
In my opinion, writing things down helps to clarify your thinking and lets others understand how you think. It also reduces the risk of the devs implementing something that doesn't fix the users' issue.
They think writing things down is overhead, too much "process", too much time. What they (IMO) don't see is that discussing requirements, assumptions before developing a feature (or even prioritizing a feature) helps to establish a common understanding of the issue and the proposed solution.