jonathan@researchcomputingteams.org
This resource first appeared in issue #94 on 01 Oct 2021 and has tags Managing A Team: Career Ladders, Technical Leadership: Software Development
Senior level RSE career paths (with an s) - Daniel S. Katz, Kenton McHenry, Jong S. Lee
In the spirit of Shmitz et al.’s call for a career path for RCD individual contribitors, Katz, McHenry, and Lee describe a career progression for research software developers, starting with associate, staff, then senior research software engineer (RSE). Then there’s a bit of a step change to Lead, which I think is pretty well described here:
Some of these roles can include some mentoring and leadership, and at some point in technical progression, this becomes a key capability. For the purpose of this post, we’ll call this the Lead RSE level.
At that point the proposed ladder goes through a hypothetical fork into Product Manager, Principal RSE, and Group Leader, although the authors don’t actually have PdM or Principal RSE roles at their institution, so the discussion becomes less concrete at that point.
What I like about this article is the recognition of the desirability of separate product/people/technical leadership paths past a point, and discussion of a couple of anonymized case studies - but topping out before Lead.
A gap, as with much of the RSE discourse, is the focus on software as a silo completely disconnected from data or systems - certainly by the senior RSE level this would start to come into play.
Something else kind of discouraging: even a great and storied institution (NCSA) that knows the importance of research computing takes too unseriously training and mentorship around leadership and management. There is no training plan for management or technical leadership, not much recognition that that’s a problem, or even a suggestion of what that might look like. A group leader might get 20%(!!) of non-project-funded time to do everything not-directly-chargable, including management, and we’re not told how much a lead would get for technical leadership but it would presumably fall in the somewhere between 5% and 20% time that has to go to anything not directly chargeable to a project.
If you take your ICs time and skills seriously, a vital way to invest in them is to give them managers who know what they’re doing, and have the time to do it!
