#136 - Draft table of contents for hiring ebook
Plus: Starting a Summer Research Program; Too much responsibility causes burnout; Delegation Basics; Don’t pig out on 'comfort work'
The topic I get the most questions about these days is hiring. This is actually a great time to hire, with many private-sector firms freezing their hiring while economic conditions are uncertain.
This newsletter has covered a lot of hiring topics over the past (almost) three years, and I’ve gotten a lot of useful feedback - thank you!
I’d like to distill that material down to a single document that could be as useful to as many people as possible. I’ve started putting everything together into one PDF: so far the table of contents is below.
If you’d be interested in this material, or would send it to someone who would need it, could you go through the table of contents and tell me what you think? Is this what you’d want to read? Are there things missing, or (more likely) things you don’t care about that can be skipped? Would you be willing to leave comments on a first version of the material? I’d appreciate any feedback - just hit “reply” or email me at jonathan@managerphd.com.
Background
Avoid Common Meta-Mistakes
Hiring Is Always Strategic
The Goal is To Build a Team That Succeeds Together
Aim To Get To “No” Quickly
Hiring is Onboarding
The Process
Step 1: Begin with the End in Mind
Create Your “Hiring Advisory Committee”
Get Agreement on What the Job Is For
Define A Successful Hire Together
Develop An Initial Path To Success
Step 2: Define the Onboarding Process
Take an Inventory of Onboarding Resources
Get Feedback On The Lists
Put Together An Initial Plan
Step 3: Define the Evaluation Criteria
What must haves does someone have to onboard successfully?
Technical skills are easier to learn than team skills
Step 4: Define the to Evaluation Process
You’re looking to disprove the hypothesis
Only ask questions that have disqualifying answers
If you can’t evaluate against a criterion, the criterion needs to change
Define interview process
Work samples
Technical interviews
Team skills questions
Behavioural questions are your friends
Step 4: Write Up the Candidate Packet
First version of job advertisement
Description of the team
Why this job matters
Support you’ll get
Success plan
First version of interview process
Step 5: Figure Out Where To Find Candidates
Understand the personae you’re trying to reach
How can you reach your candidates?
Who do you have in your networks who are relevant to the search?
First direct contacts - “do you know anyone who would be interested…”
Incorporate Feedback
Step 6: Write The Official Job Posting
Fill out the horrible HR form
Post your ad on your team webpage
Polish the Candidate Packet
Step 7: Actively Recruit
Mass emails don’t work: directly contact individuals
Find new candidates via LinkedIn, etc.
Solicit help from others
Find out about institutional resources
Step 8: Running The Hiring Process
Draft rejection emails
“Phone” screens
Get specific feedback and recommendations after each stage
You owe the candidates prompt and useful responses
Save the interview notes for the successful candidate
Step 9: Running The Onboarding Process
Create the full, personalized onboarding plan
Onboarding continues through to success
Offboarding unsuccessful new hires
Continuing with one-on-ones
Collect feedback on the hiring and onboarding process
Review interview notes; what signals should you amplify/dampen for next time?
Making Things Easier The Next Time
Build on What You’ve Done
Run a retrospective: what worked, what didn’t
Save your Worksheets and Documentation
Keep everyone involved
At performance review time, sketch out job definitions for other team members
Develop a Bench: Grow Your Team’s Professional Network
Have a shared list of potential colleagues of interest
Use conferences, etc to find people of interest
Always Be Recruiting
Consider An Internship Program
Hiring more often = Hiring better
Make the internship as valuable as possible
Alumni are part of your team’s professional network now
Build your team’s external visibility
Conference talks
Blog posts
Short Videos
Appendices
Job definition worksheet
Onboarding template
And now, on to the roundup!
Managing Teams
Split Your Overwhelmed Teams - Thomas A. Limoncelli, Operations and Life, ACM Queue
I’ve mentioned before that in other fields, people learn a lot about people systems from case studies. We don’t generally get opportunities for that, so I like to include anything like a case study wherever possible.
Here, we have something of a case study. A service reliability (SRE) team — cross-cutting technical software/operations experts charged with keeping a service up and running both preventatively and in the case of outages — had high attrition and the people were unhappy.
His SRE team was suffering from low morale. People were burning out. Attrition was high. People leaving often cited high stress levels as the reason.
There’s two lessons we can take from this article that are very applicable to our teams.
The first is: If you take smart, driven people who want to help, and make them responsible for an infeasible range of work, they will burn themselves out, even if the workload itself isn’t that bad:
People were stressed because they felt incompetent. Six major areas of responsibility meant that no matter how good you became at one thing, there were other areas that you always felt embarrassingly ignorant about. In simple terms, the team was feeling overwhelmed. […] When I talked with members of the team, I often heard phrases such as “I feel stupid” or “At my last job, I was the expert, but I’ve been here a year and I still don’t know what I’m doing.”
The second is that “not enough funding” or “not enough people” is a problem everyone faces. We tend to think of it as a uniquely academia problem. It’s not. There is no team, in any sector, who couldn’t accomplish more and bigger things, worthwhile things, if they had a bigger budget and larger headcount. But they don’t.
Hiring more people is [one] solution, not a problem. By restating the problem as one of morale and stress [LJD - or too large a scope for the team size], we open the door to many possible solutions.
Not as much funding as you could make effective use of, not as many staff as could be kept busy, isn’t itself a problem. It may well be part of the cause of other, more specific, problems. Focusing on the specific problems increases the range of solutions available. More money or staff might help; another approach is to scope down, focusing one’s effort where one can have the highest impact, and get very very good at that work.
Ten Simple Rules for Running a Summer Research Program - Joseph C. Ayoob, Juan S. Ramírez-Lugo
Slack: How Smart Companies Make the Most of Their Internships - Jessica Wachtel, The New Stack
As you know, from the newsletter (and the hiring ToC!), I’m a huge fan of internship programs. They’re an important mechanism for us to train and develop junior folks and so disseminate knowledge. They also help us improve our hiring and onboarding skills by letting us iterate quickly on them. And they help our team develop a larger professional network, with direct connections to people we wouldn’t otherwise necessarily reach.
Ayoob and Ramírez-Lugo look at starting a summer research program from scratch, in the context of an academic department. But their approach makes just as much sense for technical interns:
Fundamentals (Rules 1, 2, 3): Get a leadership team and funding support together, define the focus, and commit to evaluating the program
People (Rules 4 & 5): Recruit (and train!) a range of mentors, prioritize diversity of recruitment and selection
Onboarding (Rules 6 & 7): Build a long pre-program onramp, and have programming for participants once they start
During (Rules 8 & 9): Be prepared to make changes, and be paying enough attention to the students to kow if that’s neede
Afterwards (Rule 10): Don’t end the program on the last day
Wachtel interviews Eman Hassan at Slack, who sees the same benefits to internship programs as I do; Hassan focuses more tactically on the individual projects for an intern, and sees success requiring:
Defining a well-scoped project, with opportunities for creative work with a well-defined outcome
Defining a clear set of short-term milestones
Setting up systems of mentorship and communication
Delegation - Azarudeen
Delegation is one of the key practices of our job. Like a lot of things, it’s that delegation is hard to do well, but it’s easy to mess up. The author give the four key steps:
Explain why you chose them
Give them a chance to say no
Explain the job clearly.
Explain what and how(quality) the output should be.
And the three most common failure modes:
Trust issues between you and your team member - This will never work if there is a trust issue between you and your team member.
You failed to explain clearly.
You wouldn’t fully let go of the task, and so didn’t get out of the team member’s way
I’ll just add that delegation is much more like to be successful if you have a practice of one-on-ones with your team member. Those will help you build up that trust, learn what directions they want to grow in, and align these delegated tasks with areas they want to grow. It also requires that you are able to give them effective feedback, to keep nudging them onto the right track in a way that maintains trusts and helps them develop skills.
Managing Your Own Career
Reminiscing: the retreat to comforting work - Will Larson
Pairing well with the delegation article above, Larson talks calls out snacking on “comfort work”, retreating from ambiguous and stressful work in our current roles by doing clear and familiar work of the sort we used to do. Maybe ship a little code and close some tickets, or clean up a system image, or “help” with that email to the user community, or analyze some data a few different ways to make just the right figure for that presentation..…
As Larson makes clear with his analogy, a little bit of snacking isn’t necessarily terrible! But it’s a detour from the “nutritious”, real work we’re hired to do. It’s a distraction.
The antidote is to be focussed on what matters:
To catch my own reminiscing, I find I really need to write out my weekly priorities, and look at the ones that keep slipping. Why am I avoiding that work, and is it more important than what I’m doing instead? If a given task slips more than two weeks, then usually I’m avoiding it, and it’s time to figure out where I’m spending time reminiscing.
Random
Our working conditions can be awkward, sure, but - welcome to brr.fyi, the blog of a lone research IT support staffer in Antarctica.
A nice introduction to genomics for software developers.
An embedable graph database that uses datalog as a query language - cozo.
That’s it…
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck in the coming week with your team,
Jonathan