Managing Research Software Projects: Human Resources

<div align="center" style="padding-top: 2rem;">
  <p>Managing Research Software Projects</p>
  <h1>Human Resources</h1>
  <p>
    <img src="../files/codebender.svg" alt="logo" width="20%" />
  </p>
</div>

---

## Hiring

- Different from <a href="../newcomers/">recruiting new contributors</a>
  - Though what you do once someone is hired may be very similar
- People do lots of simple things wrong [<a href="../bibliography/#Behroozi2020">Behroozi2020</a>]
- Ask Human Resources for mentoring
- *Always post positions*
  - One person's "I know a guy" is another's "I wasn't even invited"

---

## 1. Legal requirements

- Every jurisdiction has rules about hiring people
- Institutions often have union agreements or contractual obligations
- Jess talks to Aaron in Human Resources *before doing anything else*
  - Even if you've gone through this before, rules can change

---

## 2. Contact

- Pay attention to details
  - Do they have or need work authorization?
  - Are they willing to relocate?
  - Do they actually have the right skills for this job?

<div align="center">
  <p><em>Please <a href="../hr/programmer-competency-matrix/">explain your classification</a>.</em></p>
</div>

- Responsiveness
  - Acknowledge all communication
  - Give them timelines (and updates when timelines change)

---

## 3. Preparation

- Interview scheduling
  - Use [Calendly][calendly] or a similar service
  - If you have to reschedule, give candidates several days' notice
  - If you have to reschedule twice, you're telling them you don't want them
- Hiring criteria
  - Describe the process and the kinds of questions they'll be asked
- [Automattic][automattic-hiring] is a good model
- [Canonical][canonical-hiring] is not

---

## 4. Interviews

- Make sure interviewers stick to the advertised process
  - Role-play a practice interview if you can
- Interviewers' knowledge
  - If you don't know enough to judge the candidate, find someone who can
- Make sure they pay attention (rather than answering email)

---

## 5. Hearing back

- Status updates
  - Give candidates a timeline and regular updates
  - Don't try to hide the fact that you're interviewing other people
- Give feedback *if the interviewee asks for it*
  - "You're on the right track, but need to have more experience with time series data"

---

## 6. Offer and negotiation

- Let Human Resources handle this

- You *did* publish a salary band, right?

---

## Firing

- Sometimes people have good reasons for poor performance
- Sometimes they don't
- This is the hardest part of leading a project
- But keeping someone on the team who shouldn't be there is bad for morale as well as productivity

---

## 1. Legal Requirements

- Every jurisdiction has rules about firing people, too
- Again, talk to someone in Human Resources before doing anything else

---

## 1. "Legal" Requirements

- <a href="../governance/">Governance</a> of every well-run open project spells out:
  - Criteria for being a project member
  - Who gets to decide when that privilege is revoked
- *You can't wait until you need these to write them*
- Review them before going any further

---

## 2. Check With Someone

- Hard to work with someone you dislike
  - But not liking someone isn't sufficient reason to fire them
- Talk to someone outside the project
  - More likely to be objective
  - Less likely to let something slip
  - Less likely to feel pressured to take your side because you're the boss

---

## 3. Create a Transition Plan

- It's awkward to fire the only person who knows the password to the production server
  - And risky as well
- Suddenly asking someone to document their work is a give-away
- Better to ask everyone to do it all the time
  - Which helps keep roles and responsibilities up to date

---

## 3. Create a Transition Plan

- Write out the steps you'll take immediately after breaking the news
  - Change passwords on servers
  - Remove from GitHub group
  - Remove from mailing list
  - Return loaned hardware
- All of this needs to be done when someone leaves voluntarily
  - And helps you realize just how much "stuff" your project has

---

## 4. No Surprises

- If someone is surprised they're being fired, *you* have made a mistake
- If it's for poor behavior:
  - They should know what's in the Code of Conduct
  - And you should have given them warnings for minor violations
- If it's for poor performance:
  - You should have told them that they weren't meeting expectations…
  - …given them a chance to explain…
  - …and given them an opportunity to improve
- You will feel pretty bad if they've been missing deadlines because of a family illness

---

## 5. Delivery

- Write out what you're going to say
  - Keep it short
- Practice it a few times
- Then get straight to the point
- Don't get drawn into discussion of "what if"
- Stick to the practical matters you identified in the transition plan

---

## 6. Tell the Team

- Make sure the team hears the news from you
  - Before rumors start to circulate
- Keep statement brief and to the point
- Do *not* discuss details
  - The person you fired has a right to privacy
  - And you don't want other team members worrying that you'll say something about them some day

---

## 7. Keep a Record

- It's hard for people to think clearly when you're angry or hurt
  - And they may not act in good faith
- Communicate by email
- If they insist on a call:
  - Ask to record it and give them permission to do the same
  - Or have a third party present

---

## It's OK to Cry

- This is the hardest part of management
- Many of the other things we've discussed are to prevent it being necessary
- "You can't save everyone."

---

## In Between

- Regular performance reviews
  - At which *you* bring up salary
- Career development plans
  - "Where do you want to be in two years?"
  - "How can I help you get there?"

---

## Giving Feedback

- Structure makes difficult conversations less difficult

<table>
  <tr><th colspan="4">COIN</th></tr>
  <tr><td>Context</td><td>What you want to discuss and why</td></tr>
  <tr><td>Observation</td><td>Specific, factual description of what happened</td></tr>
  <tr><td>Impact</td><td>How the issue affects others in the team</td></tr>
  <tr><td>Next Steps</td><td>A clear agreement on the changes</td></tr>
</table>

---

## How to Be Fired

1. Read over <https://third-bit.com/rules/#being-fired>.
1. Which of these things are you doing right now?
1. What does that tell you about your job?

---

## Career Development

1. Where do you want to be in two years?
1. What are you doing now to help you get there?
1. Who should be helping you get there?
1. Who *is* helping you?

---

## Team Evaluation

Look over this <a href="../hr/evaluation/">teamwork evaluation rubric</a>.

1. What five questions would you put in a section titled "Technical Skills"?
1. Which five question would you remove from other sections to make room for these?

[automattic-hiring]: https://automattic.com/work-with-us/how-we-hire-developers/
[calendly]: https://calendly.com/
[canonical-hiring]: https://third-bit.com/2021/09/13/iq-and-personality-tests/