#80 - 27 Aug 2021
Keeping team members, and seeing them off; Performance reviews; Improving explanations
Managing Individuals
The 3 Stay Conversations: The Best Way To Improve Employee Retention - Know Your Team, Clare Lew
The Final One-on-One: 7 Questions to ask When Offboarding Employees - Anita Chauhan, Hypercontext
After 18 months of pandemic, with everyone tired while tech industry employee demand and salaries are skyrocketing, incautious research computing team managers risk losing their most ambitious, high-performing, team members.
In the first article, Lew lists three sets of conversations to routinely have with team members during one-on-ones:
Clarifications about the team member and their work (what has motivated them, is it clear why what they do in particular matters, are there skills of theirs not being used)
Questions around team dynamics (do they wish they were interacting with another part of the team more, do they like the current level of interactions, how do they like to be recognized for their work)
Questions about organizational context (are there areas of the org they wish they knew more about, what has been confusing lately, is the vision clear).
These seem like great detailed questions to ask periodically. It might usefully be augmented by very frequent high-level open-ended check-ins. For instance, with manager-tools employee retention question - “Hey, overall, how’s it going?” - asked routinely in one-on-ones, as a way of detecting whether your team members have any issues or concerns which might lead them to having their shields down to other opportunities.
If people do leave, we should celebrate that - growth and development and moving to new roles is good and healthy - even if it’s a pain for us. In addition, a team member leaving can be a good time to get some unvarnished feedback if you’ve spent the time together building a good working relationship. Chauhan recommends some questions, including:
Is there anything we should be aware of as we take over your responsibilites?
If we could improve, how would we do it?
Did the job live up to your expectations?
What was the most enjoyable part of your job?
What qualities and skills should someone have to be succesful in your role?
Who do you feel is doing an outstanding job on the team?
Managing Teams
Performance Review: Build Your Process and Master Feedback Delivery - Gábor Zöld and Lara Hogan, Coding Sans
In my institution it’s annual review time - it’s a pretty lightweight process here. It might actually be too lightweight - a manager who isn’t routinely giving their team members direct feedback could easily skate through this review process with some platitudes and go an entire year without ever giving their team members any useful information about how they are doing. On the other hand, massive annual processes cause their own pain, if only through non-compliance.
In a field as quickly-shifting as most of ours are, setting goals annually requires unfeasible powers of prognostication. I like setting and reviewing goals for work, skill development, and career development every 3-4 months - our template form is here. New managers: you are not as limited by official HR processes as you likely believe! Your HR business associate would be delighted to hear that you’re setting goals and reviewing progress with your team members more often than the bare minimum enforced by policy.
Regardless - however you and your institution organize performance review processes, it’s important for the team for expectations setting, an important lever and responsibility for you as a manager, and a stressful time for your team members. In this blog post coming out of a podcast episode, Hogan gives a detailed walk through of her approach to the process; it’s a terrific discussion. She covers:
Getting input from stakeholders and synthesizing it
Provide what they need to make any improvements they need to make
What should go in a performance review - no surprises, super specific points, focus on behaviours, what would need to be changed, and why
How to prepare for giving the feedback
How to present the report
With a bonus of how to prepare to receive feedback when its your turn.
Hogan makes an important point early on - none of your feedback given in a performance review should ever be a surprise. You’re their manager - you can, and have the responsibility to, give them timely feedback as needed; the purpose of the review process is to synthesize and memorialize that feedback and make plans together as to next steps. She also emphasizes connecting the feedback to things they care about, such as career development goals.
There’s a lot of good material here, and it’s worth going through if you’ll be giving a performance review any time soon - or even if you’re not but you’d like to up your performance expectations conversation skills.
Managing Your Own Career
Demystifying Public Speaking - Lara Hogan
A lot of us who came up through research tend to no longer focussing on giving good presentations, because after all - we gave a million presentations about our work. We’re old hands.
But the presentations we’re asked to give leading research computing teams are very different than the extremely specific sub-genre that is academic presentations, which are mostly teaching people who are already experts about some new work we’ve recently done. We’re usually making cases for particular actions, or giving status reports, or training, all the while speaking to a very broad audience. Also - look, the quality/interestingness bar set for academic presentations is pretty dire.
Hogan’s book is a simple overview of giving more general-purpose presentations. Several sections of this book - choosing a topic and a venue, getting over pre-talk jitters, what to pack and bring on talk day - will in fact be old hat to veterans of the academic colloquium circuit. But sections 4 and 5 on crafting the structure of the talk, arranging post-talk resources, practicing and getting feedback before, and taking notes afterwards of what worked and what didn’t, are useful, especially for people who haven’t thought critically about this since grad school.
Check Your Work, Ask for Help, and Slow Down - Michael Lopp
Making decisions as a manager is scary, and it gets harder as your responsibilities grow. In this very sympathetic article for decision-makers, Lopp has some recommendations for you once you think you have a decision:
Check your work - are there aspects of the situation you haven’t thought about? Are there other options?
Ask for help - from the team, and from your peers
Slow down - most decisions are less urgent than they seem
What if I’m wrong - make sure you understand what will happen if the decision is the wrong one (it’s often not as scary as it sounds)
Patterns in confusing explanations - Julia Evans
We do a lot of training and other explaining as leaders - perhaps in presentations, as above! - and it’s important to have clear explanations.
Evans, who writes extremely clear explanations on a range of technical topics, often about things she’s recently learned herself, has seen a list of common anti-patterns in explanations she’s read on technical topics, and lists them here with some examples and better ways. I’ve paraphrased the list for stand-alone summary purposes:
Making outdated or internally-inconsistent assumptions about the audiences knowledge
Strained analogies
Mismatch between dry explanations and “fun” illustrations
Unrealistic examples
Meaningless jargon
Too many concepts introduced all at once
Starting out with abstractions or concepts before getting to concrete needs (we are terrible about this in academia and tech), but also
Explaining the what without the why at all
Unsupported statements
Explaining the “wrong” way without first saying its wrong - shreds trust of the rader
but if you’re at all interested in improving the explanations you and your team share in anything from documentation to presentations to downtime announcements to anything else, this is a good starting point.
Research Software Development
GitHub Discussions is out of beta - Evi Liu, GitHub Blog
GitHub Discussions is now officially generally available, and provides an entire forum - with Q&A and open discussions, pin announcements, enable moderation, grant higher permissions to frequent contributors, create polls, for your users, and more. You can convert issues into discussion topics, too.
Have any readers started doing this for their projects? It seems a lot easier than setting up a slack or something for community feedback, and a lot easier for a potential new user to participate in than filing an issue.
20 Questions a Software Engineer Should Ask When Joining a New Team - Thomas Stringer
This is written as advice to candidates to ask their hiring managers in interviews, but they are also a good set of questions for research software development teams should ask themselves and have ready as good answers (or unsolicited information) for incoming candidates before they start hiring.
Stringer’s questions cover working with the code, working with the team, working with the users, and the product(s) as a whole:
Working with the code - how do developers locally build and test the software, how is CI/CD setup
Working with the team - how is the team structured, what meetings and rituals are there, what communications tools do they use, who is available for beginner quetsions
Working with the users - how does feedback work, what support requirements are there, where is the documentation
Working on the product - what are high-level issues with the existing software, where are stakeholders focussed, what is the release cycle
A candidate who is given all of this information at once, before hiring or as part of onboarding material, would have a lot of confidence that they’re joining a team that has their stuff together.
Research Data Management and Analysis
The big-load anti-pattern - Daniel Lemire
The obvious and easy thing to do when processing a lot of data is to load it all in memory. Sometimes this is the only feasible approach unless you want to do a lot of work, as Lemire points out it scales poorly even if the machine you’re using has the necessary memory - with the simplest possible example, Lemire shows a slowdown of 3-4x going from 1MB to 1GB, and 1GB isn’t a tonne of data. All of the caching infrastructure of your system, from disk to RAM to CPU, works better and faster with processing small chunks of data at a time.
Lemire recommends:
make use of chunking that is almost certainly implemented in whatever readers you are using
split the data, by horizontal (rows) or vertical (columns) shards
make use of compression, and compress small chunks
Random
Datalog is having a moment. Datalog in Haskell, Datalog in bash (along with a datalog→bash translator) and Datalog in python.
Sure, playstation 5s look cool, but how about an even cooler gaming platform - DOS games, with 19 games released so far in the 2020s(!)
Huh - apparently a number of terminal emulators (iTerm2, Gnome terminal, …) have support for control codes which make URLs or link anchor text clickable. And if you want to know about accessibility with colours in the terminal, it turns out that the terminal game community (e.g. roguelikes like Nethack) have put a lot of thought into it.