Here’s a conventional view of roles within a small-to-medium tech company:

Department Also Called What It Does
Marketing Awareness Making people aware of who you're trying to help and how
Sales Adoption Getting people from "this looks interesting" to "we're using it"
Support Success Removing roadblocks and providing help
Human Resources Community Peer support and gathering feedback
Product Management Translate user pain into feature lists
Project Management Who should be working on what right now and what's stopping them

Here’s another way to look at them:

Department What Risk It Addresses
Marketing People don't know we exist or how we can help
Sales It's too hard to start using what we build
Support It's too hard to keep using what we build
Human Resources We don't have the right people to do the work
Product Management We're building the wrong thing
Project Management People aren't working on the right things or aren't working well together

The second formulation seems to be more compelling, especially to researchers and programmers who haven’t worked in structured organizations before. They tend to regard anything that isn’t science or coding as “overhead”, but that’s as inaccurate as calling the regulatory parts of your genome “junk DNA”. Explaining those coordinating roles in terms of the disasters they prevent seems to make them more palatable.