For those of us in or adjacent to academic institutions, the R&D efforts we are charged with - developing new computational supports for research from a large number of potential proofs of concept - are a bit of an awkward fit.
Academic departments have, naturally enough, a culture of focussing on open-ended questions, and much less of a focus on routine successful execution. This percolates down to hiring practices, management styles, and how efforts are funded, which causes us a few challenges - how to manage, hiring and developing our team, tackling ambitious projects with small teams, and on funding.
Most directly, it can be really hard to find good mentors or examples for learning how to manage in an academic environment. Academia highly values hands-off collegiality, and words like “management” or “administration” are spoken with disdain when they’re mentioned at all. But if we’re going to get work done with other humans, we need to learn to develop trusting working relationships with them, understand their strengths, weaknesses, and what motivates them, and help them develop their skills and careers - all that, you know, management stuff.
I’ve argued before that academia can give you the advanced skills for great management, but you’re on your own for the basic skills to become a good manager first. The good news is that those basic skills are the easiest to learn, they translate well between fields, and there are increasing numbers of resources from the world of business or the tech industry on how to use them; and increasingly a community of research software developers and research computing managers who can exchange best practices.
Harder to find simple answers to are questions around funding. Money for our efforts typically comes from project-based grants, which is an awkward fit to trying to support ongoing efforts. Such funding is also easier to find for the early stages of an effort, when the work is more easily cast as research in and of itself; it’s much harder as it nears maturity. We’re still rubbish at funding shared research inputs, or research infrastructure of any sort, for groups larger than individual departments. Important databases, computing infrastructure, software supporting research, all routinely scramble annually to find funding. There are hopeful signs of change at some funders, both public and private, but things continue to move quite slowly. Some groups have developed real business models around research computing as a service, and I find those successes fascinating - because absent some significant changes in the research funding landscape, that’s the only path I currently see for routine sustainability of research computing products.
For those of us that are grant-funded, our teams are somewhat more like those at nonprofits than say in tech companies. We have small teams; because of academic job structures there is typically very little room for promotion of staff, so we typically lack “career ladders” which help both with retention and clarity of expectations. We have to work harder to make sure our team members have opportunities for other kinds of progression (taking on more responsibilities, developing new skill sets), and we need to hire people who are comfortable taking on quite different roles in the team from day to day. That isn’t all bad; there are people like that looking for meaningful, challenging work, and our fields have no shortage of it! But it makes our hiring different from that in other areas or sectors.
Having small teams affect our own work, too. We’re not going to have dedicated product, product, or community managers; leading our efforts through different phases — experimental development with new tools, engaging with the research community, product management of an increasingly mature and stable product — will to some extent all fall under our responsibilities. That means we need to develop a pretty broad set of skills.
The funding advocacy, management, product lifecycle skills by and large aren’t going to be things that we learn through mentorship in academic departments; we will have to teach them to ourselves, in communities like this one and hopefully others.
Best,
Jonathan
