Mitigation
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.