Not directly answering your question; but this is the advice I wish someone had told me 30 years ago.
1. Logical arguments. No one wants to be interrogated by a courtroom lawyer. Sometimes it is necessary for very high-stakes scenarios where everything must be exactly right. But nobody likes it. This is the same reason why "waterfall" gets a bad name. If the specifications were correct, waterfall won't get such a bad reputation. The reason why specifications are never correct is that nobody actually sits through and takes the time to logically define in excruciating detail what they want. The only part of logical argumentation I have found useful is agreeing upon common terminology; in any non-trivial document, you should always have a terminology section where you specify this is what you mean by X. I have witnessed massive pushback against the common definitions like what a database is or what a system owner is.
2. People problems. I would argue 20% of tech problems are people problems which are really communication problems. e.g. business people don't know how things work and what is involved in performing Y. In their minds, what they are asking for is very simple. What they don't realize is they are asking you to integrate three different pieces of software created by different vendors that are completely incompatible with each other. When the developer tries to explain the technical complexity, they think you are lying.
3. Political problems. I would argue 80% of tech problems I have encountered at work is pure power politics. This is war in the non-violent sense. People have lied to me repeatedly and actively tried to sabotage my reputation and my projects. Not to mention to accuse me of wrongdoing for things they were actually responsible for. In this land of where everything is a lie, people go with their "gut". This is where psychology is useful. It turns out their "gut" is nothing more than past biases and cognitive short-cuts. The ability to read the room is the most critical ability here.