#52 - Defining requirements for hiring
Plus: Importance of writing skills; The talent myth; Finding mentorship
I hope you’re having a good week. Below is the continuation of our discussion on hiring, stemming in part from the more formalized pipeline that we’re working on; you can also skip to the roundup.
Last week I started with the basic premise - you have a hypothesis that you’ve found a good candidate (and they have a hypothesis that your team would be a good match for them). Then, as scientists, the job is to disprove the hypothesis.
If you accept that the hiring process is about both sides being able to detect a mismatch as early on as possible, a lot of next steps fall into place. The single most important thing we can do to ensure a good hire is to have a really clear, unambiguous description of what the job requires and what we’re looking for - so unambiguous that you could hand it off to someone else and they’d end up with basically the same post-interview short list of candidates that you would.
A clear description of what you need will help people who would be good for the job find it and self-select by applying, build agreement with your current team members around what you are collectively looking for in a new hire, and help you separate out those who would be good additions to the team from those who wouldn’t as early on in the process as possible. And sitting down and hashing out with your team the job description and requirements is a great way to have an open conversation about work in the team - both as one-on-one conversations and then collectively with the group.
Like so many things in managing, putting together an internal job description and list of requirements isn’t rocket surgery, it just requires thinking things through carefully. The most common issue I see with job descriptions, especially for technical fields, is that they are way too prescriptive about time spent using particular tools not nearly specific enough about anything else.
When we’re hiring, we’re hoping to choose a team member who will contribute in a number of ways to the work of the team over at least a few years, and our job requirements should cover what it will take to be successful over that period of time.
To counteract this tendency to focus on technical details, it’s useful to imagine having a successful candidate in the job three to six months later that’s working out really well, and back your way out from there what you’re looking for. This will help you and your team focus on what the person will be to work with, what kind of gaps you currently have.
It will also usefully tend to downplay the requirement that they “must have three years of [tool X] experience”. No one is going to be fully productive in a new role in the first few months - even tool X experts will take some time to learn your particular workflow - and this gives someone who has demonstrated related skills a couple of months to learn tool X passably well. Do you really see yourself hiring someone who isn’t broadly capable enough to pick up enough of some tool to start contributing in three months if they’ve done related things with different technologies in the past? If not, why make tool X a hard requirement?
Manager Tools has a podcast episode on writing simple job descriptions which is very useful. They suggest starting with five questions (tweaked here for context):
The reason the [team] created this job was
The most important ways a person doing this job should spend their time are
The 2-3 most important duties of this job are
What this job takes to be successful is
The simplest, easiest way to see if this job is being done well [in three months] is
I find it helpful to make explicit in the job description the team skills: in our context that might look like
The person interacts with the team by:
The person interacts with researchers/users/the community by:
The person brings the following skills/knowledge/background to the team:
These last questions, especially the first and second, are about cultural fit. When cultural fit is just used to vaguely mean “like us”, it can be a huge source of bias in interviewing. But when it’s clearly and explicitly defined, it is useful for both sides as a way to clarify expectations about how people work together on the team. (We’ve gone so far as to start an evolving slide deck on how the team works together - it needs work in sections, but the discussion around the slides has been very useful!)
The needs of your jobs and team are going to vary, but in research-flavoured environments we often have cultural expectations around collegiality:
Willing to pitch in
Willing to respectfully disagree on methods and aims, while also
Willing to let others have ownership of their part of an effort
and about independence:
Willing to learn what needs learning, and/or get help from someone who knows what needs to be known, do the job at hand
Able to take high level objectives and constraints, suitably described, and flesh out the necessary steps themselves
Willing to initiate communication with others as needed for input
Willing to take external input into account and change or correct their approach
These expectations are neither objectively good nor bad, low nor high, to have of team members, but they are common. People who work very differently - who expect very well scoped tickets to work on in disconnected chunks of work, or to be able to toil along on in their own in a corner without interacting with others - are unlikely to enjoy or succeed in environments with these expectations, and vice versa. It’s best to have your teams working expectations extremely clear at the outset for both your clarity in evaluating the candidates and for transparency to the candidate about what the job entails.
Once you have understanding of the requirements for the role, you can start prioritizing them into “must-haves” and “nice-to-haves”. It’s important to be ruthless about pulling items out of the “must-haves” list! It limits your job pool unnecessarily, and divides your focus when deciding on applications in too many directions. Is your team really unable to support a new team member with related skills as they learn about tool X and platform Y?
You can now distill the activities and requirements into a job description. This document is now starting point for discussion with whole team, and other stakeholders who would be working with the new hire. Do they see requirements you’ve missed? Do they have different priorities for those requirements than you initially thought? Are there areas of disagreement that must be understood and resolved?
The next step after having agreed-upon requirements is to think about how to evaluate them; that will come next week.
And now, on to the roundup!
Speaking of non-technical skills being underrepresented in technical job descriptions… Communicating well is absolutely essential part of a job in any interdisciplinary endeavour like research computing, and written communication is becoming absolutely vital as teams go remote. That doesn’t necessarily mean particularly good grammar or vocabulary - we’re an international community, many in our community are ESL, and those are things that can be cleaned up with tooling support afterwards. But being able to logically make a point, express an argument, or describe a process is essential.
In this twitter thread, Orosz lists a number of resources attempting to convince the reader of this point, and other resources that he feels can be used to help improve written communication skills.
Talent is largely a myth - Avishai Ish-Shalom
In research we’re pretty good at understanding that people grow in capabilities over time, and we typically avoid the tech company trap of talking about “Hiring the Best Talent”. But when we focus our job searches for people who can solve our immediate technical problems when they walk in the door, which is easy to do if we’re not careful, we can backslide into this mentality.
Ish-Shalom reminds us that:
Talent is multidimensional
Talent isn’t static
Talent isn’t linear
and if we’re trying to hire “the best” candidate during our job search we don’t pay enough attention to our team’s abilities to help the candidate grow and for their strengths to develop.
Managing Your Own Career
Maximize your mentorship: search and secure - Neha Batra
I don’t think it’s controversial to suggest that as research computing managers we are given precious little guidance, or useful advice. If we want those things, we have to seek them out ourselves.
Like with putting together a solid list of job requirements, the steps for finding and recruiting mentors to give us some advice aren’t surprising or challenging - there’s no “One Weird Trick for Getting Mentorship”. You just have to figure out what you’re looking for, who you’d like to talk to, and approach them seeking some advice.
People, even busy people, are generally pretty open to having occasional short conversations with and giving advice to people who are earlier in their career path and have questions. And in other contexts, we know this - those of us trained in academia generally wouldn’t think twice about contacting a more senior author on a paper we were interested in, or a colloquium speaker, to ask some questions about how they did the science. But we’re so weirdly conditioned around management not being real valid work in academia that we’re pretty reticent to approach people seeking advice on those topics.
Batra goes through the steps of figuring out where you want mentorship, prioritizing potential mentors, an initial ask for a discussion, and asking for another conversation in a couple months.
Degrees of Success: The Expert Panel on the Labour Market Transition of PhD Graduates, by the Canadian Council of Academies, is an interesting and in-depth look at the labour market outcomes for Ph.D. students in Canada; different countries will have different (but probably not wildly different) results. Very interesting for trainees and those working with trainees.