jonathan@researchcomputingteams.org
Hi!
I keep hearing from leaders and members of teams where retention is a big problem. It starts small, with a single person leaving, and then a steady cascade of other people follow.
Worse still, there’s a worrying asymmetry between what I hear from the team members at these institutions, and the leaders and managers.
The managers seem convinced that industry’s salaries can’t be competed with, so there’s nothing that can be done.
But when I talk to the team members, salary is only one of a list of problems that come up. Team members talk about:
Retaining our team members is something we can do a lot about.
It’s easy to focus too much on things we can’t control (like salary bands). That leads us to the very convenient hypothesis that “there’s nothing we can do”. As people of science, we should reflexively be skeptical of our hypotheses, especially those that don’t require anything of us. There are teams in very similar situations that do retain their team members: indeed, team members enthusiastically recruit others to join. It’s in our power — it’s our responsibility — to create the environment that leads to such teams.
Most people who want to work in research are more interested in the work itself than the salary. Just because people leave and the job they got has a higher salary doesn’t mean they left for the higher salary. People who are interested in large salaries have typically self-selected out of research some time ago.
We can improve retention by focusing on things that matter to team members, like meaningful work and career growth
We know what people are looking for in jobs! Take a look at Understanding Factors that Influence Research Computing and Data Careers (#133) or the charts in How To Drive Your Own Career Growth In These 6 Easy Steps (#141). Regardless of field, people want:
We can improve retention on our teams by focusing on things that matter to team members. Improving retention helps us, but more importantly it gives the team members the work environment they deserve.
This Means Focussing on the Basics
How do we know what matters to our individual team members? How do we make sure they’re given stretch opportunities that are meaningful to and feasible for them? We start with the absolute basics - one-on-one meetings. That’s the data collection pipeline which will build relationships, alert you to issues, and help you know what each individual team member wants.
Address the issues they raise
Your ability to change things isn’t limitless, but you’ll (re)build trust with team members faster when you show that you take their input seriously and address what you can.
If one of the issues raised is impending burnout, do something about that now. If your team members are close to burning out, that’s entirely on you. Managing your team member’s workload is a key managerial responsibility. This may mean your team will have to stop doing some things, and focus solely on the areas where they have the highest impact or are otherwise highest priority. So be it. You’ll have to do the hard work of pushing back on community members who are demanding that other work to be done. No one said our job was easy.
Help your team members grow in directions that matter to them
With some of the immediate fires put out, we can use what we hear in our one-on-one conversations to start proposing some work for team members that lines up with directions in which they want to grow. Give them stretch opportunities that are feasible, that line up with work that needs to be done, and give them the support in the stretch opportunity to help them succeed.
The right amount of attrition of team members is not zero.
None of this is to say we don’t want anyone to ever leave our team.
It is good and healthy for team members to leave when the time is right for them. We want to see our team members move on to new opportunities that are right for them, even if that means leaving us.
Some turnover is actually an opportunity in fairly stable teams like ours; it allows for fresh perspectives to come in. But when people leaving becomes a cascade, that’s a symptom of management debt, of issues that have been left to fester in the team for too long. The departures cause further problems, hurting morale and leading to overwork for the people that stay.
It takes a lot to make people leave a stable job doing work they care about; once that barrier has been crossed, it takes a lot of work to rebuild relationships back to the point where people are staying not out of inertia but because they want to be there.
But the work is the usual work we should be doing anyway. Having proper one-on-ones to build individual relationships; giving clear goals and objectives; providing adequate resources; giving regular feedback; and finding work that matters to your team members. This is bread and butter management 101 stuff.
Resources I like for this
Any thoughts on putting out attrition fires? Do you have any questions you’d like to ask, or would you like to be one of the first team managers or leads interviewed for RCT? Email me at jonathan@researchcomputingteams.org, or arrange a quick call.
With that, on to the roundup!
Hack Your Bureaucracy - Marina Nitze and Nick Sinai
This book is definitely going on the very short Official Research Computing Team Book List™ that I recommend to people new to our line of work.
Nitze and Sinai have assembled a compendium of techniques for getting things done in large organizations. It is super tactical, almost to a fault, full of specific tips for getting things moving and enacting lasting change.
I’m not going to be able to summarize everything that’s in here, but there are several common themes. I’d sketch them out something like this:
These are people who have effected real change repeatedly in large complex organizations, and it shows. It’s a terrific book. It’s also very aligned with this newsletter’s point of view, which is that doing important work (like managing our teams) is doable, and doesn’t take a particular personality type, off-the-charts charisma, or particularly profound insights into the nature of humanity — but it does take some thinking ahead, attention to people’s needs, and sustained, persistent effort.
I hope a second edition expands on a couple of sections. In a section about knowing how your organization really works, mentioned for a scant couple of pages is the idea of building a personal “stakeholder map”, documenting the undocumented web of power and influence and priorities in your organization. Putting together one of those is the sort of thing one could profitably write (or read) an entire book about.
Why Feedback Hurts (and that’s optional) - Roy Rapoport
A good reminder for those receiving and giving feedback: one way feedback can unnecessarily hurt is when it sounds like it’s about the person itself, rather than some behaviour they demonstrated.
When we get feedback that hurts, one way we can take it better is depersonalizing it, and making it about some action performed rather than us as a human. And when we give feedback, we can usefully remember that focussing on behaviour and impact, regardless of feedback model, can avoid unnecessary hurt.
Navigating power dynamics as a manager - Pat Kua
Something new managers frequently have a tough time understanding is that they are now The Powerful One in their relationship with their team members. It’s especially hard to wrap your head around this when you’ve been promoted within your old team; you’re still just that same person, right?
Well, wrong. You’re now the person who can fire others, or at least write poor performance reviews. Everyone else is exquisitely aware of this, even if the new manager is kind of oblivious to it for the first while. That means others start behaving differently - deferring to your opinions, less willing to contradict you.
Navigating this means changing your own behaviours. Kua’s article gives five important ways to do this, and why:
How to run an effective retrospective - Gregory Witek
As I’ve mentioned before, retrospectives are to Management 201 (managing the team as a whole) as one-on-ones are to Management 101 (managing individuals). They are the fundamental tool of having a technical team improve how it works together.
Witek has thee key principles for running retrospectives that work:
and has very concrete, simple recommendations for how to run them, tools to use, agendas, and choosing what to work on improving.
Speak Up to Get Better Feedback in Your Next Performance Review - Karin Hurt
Hurt has some great advice if you get some infuriating feedback (or lack thereof) from your manager again around performance review time: some examples are
In each case, she gives three or so specific scripts for how to proceed.
The underlying techniques are great worth highlighting. Some are about coming into the review with specific areas you want feedback in and being politely insistent on getting it (“Thank you! You know, one area I’m really working to improve on is __. What is one suggestion you have for how I can be more effective in that arena?”). Others are about explicitly but politely stating your unhappiness and possibly making an ask (“I’m a bit surprised by this feedback and would like to take some time to digest it. Let’s set up a follow-up in a week to talk a bit more.” or “Oh, wow. That must have put you in a difficult situation. And, I’ve got to tell you, that makes me feel really ____” or “I’d like a chance to better understand this issue. Who do you suggest I talk with to learn more?”)
And of course we can use this article as a checklist of things not to do in performance reviews with our team members.
The Helmholtz Association, which runs 18 research centres across Germany, has set a policy which makes open science a requirement:
The Helmholtz Assembly of Members adopted the Open Science Policy in September. This policy stipulates that scholarly articles, research data, and research software be published openly. Open science thus becomes the standard for publication practices.
Functional programming is the future, just like it has been for the last thirty years.
How did Télétel, the French internet of the 1980s, work?
Decker is a retro-feeling HyperCard inspired no/low code tool, but with modern tools like easily deployable via static HTML, data query languages, and more.
Shell of a New Machine is a client-server dotfile manager.
Best practices for managing your BibTeX bibliographies.
It shames me how often I have to look up SSH tunneling options for non-trivial situations; maybe this visual SSH tunnel cheat sheet is just something I can print out and leave up somewhere.
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 research computing team,
Jonathan
(Cover Photo in twitter card by Nick Fewings on Unsplash)
Research computing - the intertwined streams of software development, systems, data management and analysis - is much more than technology. It’s teams, it’s communities, it’s product management - it’s people. It’s also one of the most important ways we can be supporting science, scholarship, and R&D today.
So research computing teams are too important to research to be managed poorly. But no one teaches us how to be effective managers and leaders in academia. We have an advantage, though - working in research collaborations have taught us the advanced management skills, but not the basics.
This newsletter focusses on providing new and experienced research computing and data managers the tools they need to be good managers without the stress, and to help their teams achieve great results and grow their careers.
This week’s new-listing highlights are below in the email edition; the full listing of 188 jobs is, as ever, available on the job board.
