Reducing the configuration "max degree of parallelism" to half or a fourth of number of the cores may be a good idea. If nothing else, it prevents a single user from monopolising all cores.
Many people also recommend raising "cost threshold for parallelism", but I am not overly keen on that. Yes, the value is low by modern standards, but then again parallelism gives you better performance most of the time.
Sometimes it does not, for instance because of mis-estimations (which could be due outdated statistics), which causes SQL Server to for a parallel plan with more brute force than it would have applied in a serial plan. Or the data is incorrectly partitioned
among the threads, so one thread does all the work.
When things like this occur, it is often a token that not everything is well with the queries, but they need some tuning. Either by being re-written or by getting better index support. So do to a real good job, you need get your hands dirty and start to
track down poorly performing queries. This is a lot easier if you are on SQL 2016+ and can use Query Store.
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se