#63 - 23 April 2021
Hiring for teams, not individuals; better meetings
Hi, everyone!
I have a somewhat short newsletter for you this week; exciting things are happening at work with product adoption and hiring, both of which are taking up a lot of time but are unmistakably good. In addition, we’re having increasingly lovely weather, dear friends are getting vaccinated, and actions and decisions made months ago are are finally appearing in outcomes that are beginning to come together in a pleasingly coherent manner. I hope you, yours, and your team are doing equally well.
For now, on to the roundup!
Managing Teams
Don’t hire top talent; hire for weaknesses - Benji Weber
Why you should invest in undervalued people - Joe Emison
We need to talk about your Q3 roadmap - Wherewithall
The path to management from academic research tends to lead to a common mistake in hiring. We’re used to looking for the “smartest”, “best”, “greatest promise”, “top” of the applicants, whether for postdoc positions or new senior devs.
That arguably wasn’t a great approach then, and for us now it definitely isn’t the right approach. Maybe you are supervising a collection of individuals who will each do independent work. Mostly though, we hire individuals to build a team. For that we need to hire at least in part for gaps in and weaknesses of the team as much as for strengths of the individuals. Or as Weber says:
Instead of “how can we find the smartest people?” think about “how can we find people who will make our team stronger?”
I don’t agree with everything in Weber’s article - we still do need consistent processes, and to look for did-not-demonstrate-needed-skills. But the basic idea of building the team rather than a portfolio of “top” individuals is a vital one. Some of the basic skills you’ll be hiring for will change over time as your teams gaps and weaknesses shift.
The good news about this approach is that it makes it easier to see areas that can be filled by still-junior people, as advocated for by Emison; in #60 we talked about the work it does take making for more resilient teams, but also it’s a move in the direction of equity as well as being, frankly, significantly easier to hire undervalued staff.
But the suggestion that we should be hiring for gaps sits a bit uncomfortably with this week’s reminder from the Wherewithall newsletter that, as we heard last week in #62, there are going to be a lot of people leaving or at least taking extended periods of time off as soon as things start getting back to some kind of normal. The adrenaline has long since worn off, and people are looking for change after an exhausting year.
It’s a bit more work to be prepared to hire for gaps when your list of gaps might change suddenly if people leave. Your “intermediate openstack administrator” or “senior research data curator” or “junior research software developer” positions won’t be cookie-cutter, fungible people. The roles will have a consistent set of base-level requirements to be a successful and productive member of your team but a shifting set of skills and behaviours you need to make your team stronger. Understanding your current team’s strengths and gaps, and the full package of what each of your current team members bring to the team - and documenting all of this! - will help you be ready.
How to have meetings that don’t suck (as much) - Danielle Leong
More and more collaboration occurs asynchronously these days, but meetings are vital for coordinating that collaboration. Meetings are also routinely done really poorly, and academia is (or should be) famous for how poorly they’re done. Whether we’re having a meeting to make a decision, solve a problem, gather input, share information, or point everyone in the same direction, Leong calls out some things that should be crystal clear:
Who is leading this meeting?
Why are we having this meeting?
What is the purpose?
What is the agenda?
What are the action items?
The middle item, “what is the purpose”, is badly under-used. I used to think that having an agenda was enough; but having a really crisply defined purpose, especially for recurring meetings, is in the long term even more important. You can’t evaluate whether a meeting was effective or not unless there’s a goal or purpose in mind. An agenda should serve the purpose, and it often implies the purpose, but having it explicitly stated makes it much easier make a meeting better.
Having a purpose also makes it clear when a meeting should be multiple, smaller meetings. If a meeting turns into a grab-bag of purposes, it should be split up. Leong has a list of suggested (short) lengths of times for many different kinds of meetings.
There’s a lot of other stuff in Leong’s article, including links to other good resources like designing useful meetings.
Random
Not a big surprise, but jobs in tech are increasingly being offered as remote-friendly - roughly 1/3 of devops jobs in one sample are being offered as remote - and if we hope to compete we’re going to have to figure out how to do that too (at this point, for many of us the institutional barriers are the problem).
Written communication is a huge part of what we do in research computing and in managing teams. Coursera has a writing course which people seem quite happy with.