For the next few days, I want to talk about why research computing teams, and managing those teams well, is important — and why it’s meaningfully different from managing technical teams in other areas.
Those differences, and its importance, make research computing teams and management something worth thinking about, and getting better at, in its own right; one of the recurring themes in the next few days is that we can learn a lot from what is done in other areas, but we can also learn from what each other is doing. One of the things I want to start doing with his newsletter is to try to start creating a space for that exchange.
These next emails, especially part 2 and 3, are written in particular for an academic audience, where the distinction between a product as a research output and “in production” aren’t as clearly made. As aways, I look forward to your feedback about what is interesting for you and what doesn’t - or approaches you’ve taken to some of these challenges the we can all learn from.
Research in all fields is rapidly becoming more compute- and data-heavy - including fields that until quite recently did not not rely on computers. And as quickly as research has always moved, computing is changing even faster.
That means that today, the biggest impediment holding back most research from taking advantage of new computing and data approaches and using them to their full potential isn’t a lack of huge new computers, or that there’s a dearth of shiny innovation hubs. It’s a lack of people with experience in both the world of research and that of computing; and lack of teams of those people that working as effectively as they can together, routinely and successfully launching new tools while growing their own technical and field-specific skills.
Right now, today, one of the most important ways people with both research and computing experience (or interest in gaining same) can advance science is to work in research computing. There is so much low-hanging fruit — so many practices or procedures that can be improved, so much cross-field knowledge exchange that can happen, so many potential new approaches going unused — that a single dedicated person can have a impact through research computing in a way they likely can’t as a trainee or even junior faculty.
And as we get more senior in this field, one of the options we have, and one of the ways we can best support both those staff and our community’s researchers, is to move into research computing management. By taking on this very different role — and make no mistake, management isn’t a promotion, it’s a career change — we can advocate for our teams; we can connect their work more directly to the work and needs of research communities; we can make sure our teams are working together as effectively as possible, on the most important things; and we can take active steps to make sure our team members are growing all of their skills while doing meaningful work. For more senior research computing staff, becoming a good research computing manager is one of the most meaningful ways we can contribute to science.
But we can’t just copy-and-paste our approaches from the technology industry, or from other research-supporting teams like those in wet labs.
So we need to combine approaches from many fields to do our jobs; but we’re researchers, and we know how to try new approaches and evaluate them. Research software development has started to professionalize in the past few years; and we’re getting to the point where research computing management is established enough that we can start sharing best practices form inside and outside our community.
For the rest of the week (until the Friday link roundup) let’s talk about these things that make research computing management important and meaningfully different from other kinds of management.
Talk to you soon,
Jonathan
