jonathan@researchcomputingteams.org
Hi everyone -
A quick request before we get started.
I’m thinking of refactoring the newsletter a bit, pulling some things out into a separate email. It’d be an experiment that would play out over a couple of months. I have some ideas for how that would work (I’ve even played with something as a test), but I’d like to hear from you. These emails are pretty long! What would best serve you if I was planning to rearrange things a bit? Let me know - hit reply, or email me at jonathan@researchcomputingteams.org.
Let me finish up the last in the series on running good recurring meetings.
In our time in academia we probably have not seen a lot of well run meetings, and we certainly weren’t trained how to run one effectively.
And that’s a real shame, because meetings at their best are collaborative work sessions for alignment, problem solving, decision making, and driving momentum. They are important tools! Meetings that don’t waste their potential is a missed opportunity. And our team members’ and colleagues’ time is too precious to squander on poorly run meetings.
On the other hand, if you get a reputation for running meetings well (especially in an environment where that’s not usually the case), that will get you noticed, and may well get you invitations to meetings you wouldn’t normally get a chance to attend. Running a meeting well is a leadership skill even if you’re not the leader of the group you’re meeting with.
Now that we’ve leaned about meeting purposes (#152) and to take into account what the attendees will get out of the meeting (#153) we’re at what for many of us is the hardest stage - actually running the meeting effectively. That takes a more directive approach than we’re are probably used to. As with the earlier issues, we’ll talk about this in terms of recurring meetings, but these approaches work for any meeting.
There is different kinds of work involved in running a meeting:
These roles exist and this work is done for every meeting, but the responsibilities might be shared between people, or one person might have all roles. In a one-on-one, for instance, you as manager have the responsibility to facilitate when necessary, but both people probably “own” their parts of the agenda and take their own notes.
In larger meetings, having the roles be more explicitly defined and assigned becomes valuable. For a very small meeting, the chair can probably also facilitate and take notes. The meeting getting paused because the chair has to catch up and write a note about something - “hold on, I just have to write that down” is a sign that this is starting to break down and a separate note taker becomes needed.
So assigning a note taker is very valuable. This tends to pull someone out of active participation, so it’s best to rotate this role, with everyone taking a turn, and possibly having someone else take notes during a section where the person who is taking notes needs to contribute.
It’s worth talking about what notes should look like.
In academia, we tend to take notes like it’s class, and everything that’s being said might be on the final exam. For some kinds of meetings, like discussions with stakeholders to identify needs and their current experiences with the work of the team, that’s a pretty good approach - write everything down, distill it later.
But for (say) a team meeting, the sort of meeting that has an agenda, that’s not usually helpful. Usually in your meeting notes circulated afterwards, you just need:
So a note taker only has to record in the moment things that would likely show up on that list. That means a very high-level listing of points being raised. The note taker should feel comfortable breaking in and asking for clarification/repetition if necessary.
Notes should be circulated very promptly after the meeting, and ideally posted somewhere widely visible. Meeting notes should be quite public as a default; transparency is our friend here, it helps people know what is going on and reassures them that they can know what’s going on without being invited to the meeting.
It becomes obvious when we need a separate note taker - either the notes are bad or the meeting discussion suffers.
The need for a separate facilitator, on the other hand, doesn’t necessarily have such a clear warning sign. That’s a problem! In a meeting much past five people or so, it can become very difficult to be an active participant in a discussion and to be paying attention about who is and who isn’t participating, and how, and to take action to bring in others. And if no one is doing the facilitating, there’s probably people who are systematically not contributing, which is demoralizing for them and a waste of their potential input for you.
The facilitator needs to:
This means being fairly directive.
If this meeting is with your team, and you’re the manager, it is much easier for you to be the facilitator than to ask one of the team members to facilitate their peers. That would mean you’d have to participate directly a bit less; if that’s an option for the topics being discussed, I strongly recommend it, at least for enough meetings to have modelled what you would like facilitation to look like. You’re the boss, you can contribute your opinion on a topic any time you like. Getting the other attendees to contribute effectively to the discussion is a priority.
Even as managers, it can be a little awkward redirecting someone’s contribution when they are running long or time is running short. I like summarization as a technique (“Thanks, X, I just wanted to make sure I understand - it sounds like you’re saying A then B, because C, is that right? Ok, great; what do others think on the topic? How about you, Y?”), which also helps the note taker. Or simply “Thanks for that, X! I want to make sure we get a chance to hear from everyone affected by this. Y, what are your thoughts?”, or “Terrific, let’s take a note of that. Right now we’re discussing D though, and we’re running short of time. Y, what’s your input on D?” Sometimes it may take a couple of iterations of this to get someone to wind up, but a bit of gentle firmness works wonders.
(What are your favourite techniques? Shoot me an email).
It helps the facilitator and chair a lot if the agenda has two things:
Durations are clear enough; it’s much easier for the facilitator to keep a discussion to time if the time limit is written there in black and white.
The “Other topics” agenda item is intentionally a catch all, and its purpose is to keep earlier discussions on topic. When someone inevitably goes off on a tangent, the facilitator or the meeting chair can use that time slot to say “not now” rather than “no”. They can suggest saving that topic for the other topics agenda item, rescuing the earlier topic.
The Facilitator owns the process of the discussion; the chair owns the content, either of the whole meeting or of a particular agenda item. They’re responsible for making sure appropriate material was circulated before hand, for assigning to do list items afterwards, and for any decisions being made.
In a way this is the easiest of the three roles. Here the job is simply to make sure the most important points being raised are highlighted (which makes things easier for the participants and the note taker), to own and be clear about the process for decision making, and to crisply define followup tasks and make sure they’re assigned. The chair, owning the content, is the decider of what discussions are on and off topic, and so they’re the ones who should propose items get moved to “other topics”.
It is really important - especially if you’re the chair and someone else is facilitating - for the chair to defer to the facilitator about issues of time or winding up so other people can speak. That’s why it can be really valuable for you to facilitate and partly recuse yourself from charing where possible, at least for long enough to model the behaviour of a well-facilitated meeting. And when you’re chairing and someone else is facilitating, modelling that deference to the facilitator is vital.
Again, retrospectives (#137) are the key to getting better as a team. Quarterly or so, have team meeting retrospectives in your recurring group meetings, and get input on what works and what doesn’t. Maintain a list of what you decide collectively as ground rules, have them posted in the meeting agendas, and include them in onboarding materials. This shouldn’t be Robert’s Rules, just a concise list of things your group does to have good meetings. There’s no one set of ground rules for meetings that makes sense for every group - it depends on the humans involved and the kinds of discussions they need to have together.
And that’s it. None of this is rocket science. Our teams and their work are too important to squander their time in poor meetings, and it’s unnecessary. Good meeting practice takes being a bit more directive than we’re used to, and requires constant tending to. But choosing meaningful meeting purposes, having agenda items that are valuable to the attendees, and then running meetings in a way that visibly respects people’s time and their work makes for vastly better meetings and happier teams (actually true, we have data on this). Being known as someone who runs meetings well will help your reputation; and as you let the roles rotate between team members having them run meetings the same way, it’ll build their professional skills and reputation.
And with that, on to the roundup!
RCT Interviews: Ian Cosden, Director of RSE For Computational & Data Science, Princeton - Ian Cosden & Jonathan Dursi
In #145, I shared a paper by Ian Cosden, describing the organizational approach of the Princeton RSE group that he founded. Last month I spoke with Cosden to learn more. The model is obviously working very well, there’s a plan to hire 11 more RSEs!
The interview is linked above. Some key takeaways for me were:
The importance of establishing clear expectations with everyone how hiring an RSE works:
So there’s a proposal process to become a partner and upfront we have some of these documentation to start, but we’ve since settled on a plan where we have a letter of intent. So a research group, consortium, research department say, “Hey, I’m interested in an RSE as part of your group. And that’s about the extent of it. So they’re going into it knowing what they’re signing up for, what it isn’t. Some things we’ve had to say, “Look, this is not a postdoc. This is not a grad student. This is a professional. These are some of the things you can expect from a professional. These are some of the things you cannot expect from a professional.”
The effectiveness of qualitative researcher testimonials:
The number one most successful way that we have gotten support from our central administration is from researcher faculty testimonials. So it would be that we say, “Hey, that’s great. Can you go tell our Dean for research, the Provost and say this is valuable to your research”. And that at Princeton, at least that is the way that they say, “Oh, we’ve heard this now three different places from three different people. there must be something here. Let’s explore it at some more. “ In terms of expanding beyond HPC I will credit to our CIO who came up with a lot of the funding too, of saying, “No, I’m not just supporting HPC. I want to have this be bigger and broader. So let’s see what else is out there.” […] I would trying to come up with, you know, speedups, we’ve got a factor of 12 speed up and they can do this now, but in the end it’s, “ This person has transformed the way we do research in the building.” — those are what really drives interest and attention.
And the need to make space for knowledge sharing and team communication within the RSE group:
I felt very strongly in having team activities. Even though a lot of the cases they’re kind of independent consultants and they’re working on researcher projects and that’s their team. But we carved out time to make sure that the RSE group was interacting, was having team meetings, was helping each other. So setting up the Slack channels, creating a culture of it’s okay to ask questions, it’s okay not to know. That helped everyone else grow as well, because we didn’t have senior RSEs who’ve been here 20 years who could show ‘em the ropes. So we had to sort build that as a cohort together.
Finally he discussed how HR was willing to work with him on a career ladder (very challenging for the broad range of expertise spanned by people who share the title “RSE”!) after the demonstrated need by rapidly growing the team of this very specialist role, and sadly losing a couple to attrition when there wasn’t senior IC levels:
[…] I don’t think we could have done it sooner if that makes sense, that we had to have shown that we’re growing, we had to have show through this growth that this was a thing that they could no longer ignore and try to pigeonhole into something else.
Great people management is more than 1:1s - Flora Devlin
Devlin talks about the regular connection points, at different cadences, that build good working relationships with team members. Three of them will be familiar to RCT readers:
Devlin mentions a fourth one, though, which is interesting - regularly working with team members:
Bi-weekly work sessions: These are your space to work through problems together - whether that’s white-boarding new designs, understanding metrics and data, preparing for a board meeting. There’s a lot of work that happens where collaboration is invaluable.
Maybe for work- and results-focussed people like our community, it almost goes without saying that there’s value in touching base on the work of the team itself, not in a reporting status sort of way but on the work itself. But I think there’s value in calling it out as part of the regular rhythm of a successful manager-team member working relationship, and Devlin is making a good point I don’t see made elsewhere.
How often this happens would depend on the type of the work, but it’s interesting to look back and think of my most successful working relationships with team members, how many of those had the hands-on work time happening fairly regularly…
Were All These Layoffs Inevitable? Perhaps, But Here’s How It Happened - Josh Bersin
Despite Layoffs, It’s Still a Workers’ Labor Market - Atta Tarki, HBR
I’ve spoken with a couple of managers who are watching tech layoffs closely, and hoping that this means hiring for our own roles will be easier.
I don’t think that’s how it’s going to work. Firstly, as Bersin points out, big tech companies’ layoffs are typically only bringing them back to roughly 2021 staffing levels — and I don’t remember 2021 as being an amazingly easy year to be an RCD hiring manager.
Secondly, the roles that overlap for the skills we are looking especially hard for - those that combine mathematical modelling and software dev skills, or AI/ML/data science skills, or HPC positions, or devops roles - by and large aren’t the ones being pared back en masse.
Finally and most importantly, most tech jobs are not at Big Tech firms. We don’t typically lose out to FAANG (the now slightly out of date acronym for Facebook, Apple, Amazon, Netflix, and Google)-type companies for our candidates; rather it’s the vastly larger number of roles of tech roles in “regular” businesses which are our biggest competition, if only because there’s vastly more of these jobs.
Tarki walks us through recent labour market numbers in the US, pointing out that despite the headline grabbing numbers of these layoffs, layoff numbers are actually quite low economy-wide (at least in the US).
“Quit factor”, or How the industry lulls itself to sleep with “bus factor” - Alexey Makhotkin
“Quit factor”, “burnout factor”, “bored factor”, heck, “vacation factor” - Makhotkin is right here. There are lots of reasons why it’s a bad idea to have all the knowledge for a key technology/product/project/process tied up in one person. Talking about it in terms of less likely events like the person leaving or getting in an accident downplays those other issues.
In our smaller teams it’s an easy trap to fall into, but it’s worse in some ways. We are leading teams of experts. Not building robust mechanisms for sharing and distributing knowledge means we’re not growing as much as a center of excellence (#133) as we could be.
Interesting that microscopy is apparently having a moment similar to RSE or genomic bioinformatics a decade ago. As technology continues to grow and skilled experts are becoming both more important and harder to find, there’s a push for more of an online community of practice, meetups, open standards, specific funding, workforce development, and more.
US-RSE Group Leaders’ Network - US Research Software Engineer Association
Uplevel your managers with Mini-M support groups - Jade Rubick
US-RSE is starting a group leaders’ network, with monthly Chatham House Rule meetings, and periodic mentorship opportunities:
The primary membership is for those who currently lead a team and have, or are actively in the process of hiring, at least one direct report; additional members may be invited, such as those who have been in leadership positions in the past. This is to ensure that members have a network of peers in similar situations who are facing similar challenges. […] In both cases, membership is open to all US-RSE members. As with other US-RSE activities, the RSE-GLN will be US-focused, but those from other countries are welcome.
If that group is relevant to you (US-RSE membership is free), I’d encourage you to join! Rubick describes how important these communities of practice for managers can be; at New Relic they are called Mini-Ms, but they exist in other organizations under other names, too:
A Mini-M is a group of managers that meet weekly or biweekly. The meeting is a combination support group and working session. In each session, managers share challenges they face. The other participants offer support and help problem-solve. […] many managers claimed Mini-Ms helped them grow more than anything else.
Managing is hard, it requires skills we didn’t learn or have good models for in academia. Peer support is extremely helpful! It’s useful to learn from what others are doing in a similar context, and to share our experiences.
Software Engineering Skill Framework - Practica
Practica, a company that sells training and coaching, lists a general-purpose software engineering career skill framework for tech firms. Prerequisites are defined generally at associate, regular, senior, staff, principal skill levels (and levels for managers and directors) along 4-5 factors in each of four dimensions:
The intention isn’t that any team or organization would just use those verbatim, but having a filled-out starting point is a good way to think through what would be appropriate for one’s own situation. These are pretty concise and clear, and if you’ve been thinking about career levels for RCD roles in your own organization (or the discussion with Cosden inspired you!), it’s worth looking at these.
The Code For Thought podcast covering RSEs and RSE topics is two years old now; Peter Schmidt writes in to say:
On 12 January 2021, two years ago, the first episode called ‘And so it begins…’ of the research software engineering (RSE) podcast show Code for Thought went live at https://codeforthought.buzzsprout.com/. Since then we, Selina, Jacalyn and I, produced over 50 episodes covering a wide range of areas that touch on the work and life of research and software engineering. […]
Indeed, the community of RSEs has grown significantly over the past few years. But still there is a lot of work to do in terms of recognition and funding. And so, after two years of Code for Thought, we’ll continue our work and will bring you further stories, reports, interviews and showcases of RSE work across the wide range of areas and countries we work in.
Ideas, comments, or suggestions for Schmidt are welcome via email.
Community consensus on core open science practices to monitor in biomedicine - Kelly D. Cobey et al., PLOS Biology
Open Science is a classic case of positive externalities. No one really doubts that having more code, data, and other research inputs more widely available would be a significant productivity win for science, and thus for society.
But the benefits of open science for any individual project or paper are hypothetical and diffuse, while the costs are very clear, in the present, and borne by the people doing the project/paper. So the overwhelming tendency is to free ride on other people’s open work while publishing work in the traditional way, with very little sharing.
Shifting expectations will take time. Several communities (particularly new ones like genomics) already expect a certain degree of shared code and data (the latter possibly with approval for PHI uses). In other communities, it will take some sustained effort. The carrot side of behavioural change will involve research grants paying for OA journals, data cleanup work and depositions, etc.; the stick side will involve hard requirements of grants and by institutions.
But having requirements mean knowing what they are. In this report by Cobey et al, community experts in biomedicine report their consensus recommendations for what institutions and funders should first monitor and require reporting of, as a first step towards setting standards as requirements.
Official MathWorks MATLAB kernel for Jupyter released - Mike Croucher
If you have Matlab licenses, this may make delivering Matlab sessions to users somewhat easier: a Matlab kernel for Jupyter, meaning that existing Jupyter Lab (say) infrastructure can be used for matlab.
Some early experiments using GPT to provide a chatbot based on online documentation. It’s definitely not turnkey yet…
Ordering numbers that can be floats or integers can be surprisingly tricky.
Two spaces after a period is faster to read, at least for other two-spacers. Crucially, this means we two-spacers can communicate faster with each other and so get a jump on the one-spacers when the typographic revolution comes.
This video about what to do if anything when you get bad coffee in a café is a better tutorial about giving feedback to organizationally distant peers than half of the management and business material out there.
You know how you’ve always wanted to sync a pendulum clock to a Caesium time source to create the worlds most accurate grandfather clock? Dr. Daniel Baluch at CERN has some ideas.
Really odd looking alternate characters in C/C++ code from back in the day when ASCII wasn’t something you could take for granted.
One of many neat things about an embedded DB is that you can potentially couple it quite closely to your code base; here’s how to write custom C code for SQLite.
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
About This Newsletter
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 164 jobs is, as ever, available on the job board.
