#55 - Final step in getting ready to hire - the job ad is an advertisement
Plus Experiments and your team; Software leadership communities
Hi, all!
Thanks for your responses to last newsletter. Readers who responded were broadly pretty happy with the all-in-one newsletter, even if gets a little long; topics that were of interest for future write-ups were (in order of number of votes):
Performance management
Goal setting for managers
Strategy
Product management
Peer mentorship
Levelling & promotion in research computing
I appreciate all feedback; please don’t hesitate to email me with any questions, comments, suggestions or other - just hit reply if you get this by email, or email me at jonathan@managerphd.com.
Now for the last article on getting ready to start hiring.
Once you have an internal job description, prioritized list of requirements, know how to evaluate against the requirements, you’re ready to start working on the job ad - which is different from the job description.
In research we’re used to thinking of jobs like postdoc or faculty positions as rare; so you just post an ad on wherever and candidates will do the work to figure out what the job listing means, and start preparing their applications.
Other jobs… are not like that. There are roughly 1.7 bajillion jobs posted at this very moment, and your job is just one. Writing a good job ad, paying to put it somewhere, and describing in some detail what the process will be once the candidate applies is more or less the bare minimum to make sure you get a reasonable number and cross-section of candidates.
The job requirements, and the job description as a whole, is an internal document. It should be available to candidates, and you’ll use what you’ve determined and written up in the job ad, but the job ad is an entirely different document. It’s first and foremost an advertisement; you are selling your job to the candidates, demonstrating why they’d want to find out more about your job and your team and how it might be relevant to them.
It’s possible that your institution may have very rigid rules about how jobs get posted on their website; there may be a lot of boilerplate, or it may have to be precisely the formal HR-specified job description. The title of the web page may have to be exactly the job title, and in a lot of our teams, those titles are utterly meaningless. I get it; my own current institution has just appalling HR-mandated job ads.
It’s ok though, because none of this stops you from posting your own good job ads elsewhere that direct people to the incredibly uninspiring institutional job posting. Most organizations will allow you to do have different job ads elsewhere as long as all applications go through the god-awful HR website and job ad.
So what should go in your job advertisement? While you’re certainly going to have a listing of what you require for a candidate for this position, that will come a little later in the ad. First off, you’re going to have a very high-level view of who you’re looking for, which you already have a good sense of.
Then you’re going to want a list of things that are plusses of the job for the person you’re looking for. Highlight the cool work of your team, and its impact on the organization and more broadly. The person you’re looking for loves that, mention it! What will the candidate get to do every day that may be exciting to the person with the capabilities you’re looking for, that distinguishes this job from making twice as much improving web ad click-through rates?
Ideally, there should be a description of what the hiring process should look like. That can be part of the job ad, or it can be something that’s sent to candidates once they apply. It helps clarify the process for you and your team members, and gives the candidate some indication that your team is professionally run and that their carefully honed application isn’t just swirling into some black hole.
We’ve had a number of articles in the roundup about making sure the job ad doesn’t turn away candidates. There’s tools like Gender Decoder that can check your ads for exclusionary language; it’s a very blunt instrument, just based on word lists, but tools of that sort can make sure you’re not saying anything unintentionally.
Another big problem is that many people from groups that are not-overrepresented in technology fields will self-select out if they don’t meet a couple of your requirements; hopefully we’ve reduced that risk by being pretty focussed on only having requirements we actually care about, so that the requirements we list are actually requirements and so candidates don’t have to guess as to exactly how required they are.
Another potential turn off is having overly swashbuckling descriptions (“disruptive!” “ninja!” “rockstar!”), but that’s less often a problem in our field. Since we presumably care in our teams about respectful collaboration, thoughtful inquiry, and learning, including those in our job ads as plusses will help our job ad reach as many candidates as possible, including those who have left jobs in the past because they weren’t respectful, thoughtful, or good learning experiences.
… and that’s more or less it! You’re now ready to start the hiring process. Good luck!
And now on to the roundup.
Managing Teams
Leading your engineering team with ‘experiments’ not ‘processes’ - Cate Huston, LeadDev
One of the recurring themes of this newsletter is that those of us who have worked in research for a while have at our disposal the advanced skills needed to manage teams and projects to support research, but that no one taught us the basics.
Sometimes, the basics just mean applying the same rigor and processes to our new work that we did in our old: lab notebooks become one-on-one notes; thinking about the complex systems we were modelling becomes thinking about the complex people systems we’re part of; and hypothesis generation and experimentation in our work becomes hypothesis generation and experimentation about our work.
Huston’s article suggests reframing changes in team processes as experiments
Now, instead of ‘process changes’ I talk about ‘team experiments’.
and that has several advantages:
Experiments dispel the fear of the process monster
Experiments improve buy-in
Experiments reframe solving problems as learning
We’ve gone through a lot of experiments in our team. In some, the hypothesis ended up being soundly rejected and we moved away from the experiment, but others have taken on a life of their own and changed how we worked for years.
In some ways, the experiments that we roll back are even bigger successes for two reasons - we’ve learned something, and the team members see that their feedback is taken seriously when we try something that doesn’t work for them.
By the way - I often reference a transition from a research career to a career managing research computing teams. I hope I’m not inadvertently suggesting that this is the best, or only, career path to get to this work! It’s just a common one, and the one I know the most about, so it tends to be what I use for context.
Managing Your Own Career
Software Engineering Leadership Communities - Pat Kua
It can be lonely being a manager, especially these days when there’s a lot fewer opportunities to communicate with peers across the organization (and for some of us in academia, even within the organization there are precious few peers doing the sort of work we are doing). There are a few online management communities where people can ask for advice, take part in conversations about best practices, etc. Kua lists four slack communities:
CTO Craft Community
Engineering Managers Slack Group
LeadDev Slack
Rands Leadership Community
I’m part of Rands (which is very active), LeadDev (which isn’t), and am going to try Engineering Managers. When our own community with this newsletter gets larger, would it be worth trying to create some channels on one of those communities, or put together something of our own? What would be useful to you with your team and your questions?
Random
Interested in playing with RISC-V, but not enough so to buy some hardware? Here’s a docker image of an emulator you can ssh into, run with QEMU.
Last week’s newsletter (admittedly shorter than the previous few) would weigh at least 875 picograms, according to fileweight and IBM.
If you’ve really want to understand how compiled programs become code executing in memory, some recent links give you the whole process - a two-parter on writing an assembler to generate an ELF file, followed by the detailed readme (and the code) of a hobby project to build an extremely fast linker, and then a 15-part(!) series on writing an executable packer.
Relatedly, separated mainly by 62 years, Booting the IBM 1401: How a 1959 punch-card computer loads a program.
The physical, on-disk steps involved in performing an SQL transaction.
The rest of the world is discovering what a lot of people in big research collaborations - remote work has a lot of advantages.