jonathan@researchcomputingteams.org
I got a question from a reader this week which I’m surprised to see that I haven’t addressed before, and that I’m sharing with permission:
I have several years experience [as an IC in research computing and data team]. With some changes coming up here in the next year or two there will be at least one manager job opening up. I’ve been reading your newsletter for six months, and it’s been really helpful! Do you have any suggestions for what I can do to be ready as a good candidate for the job?
Below is the advice I shared, and I’d welcome any other suggestions you have. Is there anything else this reader should be doing or thinking about? Let me know and I’ll pass it along, to them and (with your permission) to other readers!
Congratulations! Our community needs more new managers with enthusiasm for doing the job well. And I’d say that you paying enough attention to your team’s broader context to see this coming and be thinking about the consequences is already a good sign.
The first thing I tell people who are thinking about this kind of transition is to make sure that they are consistently doing their current individual contributor work reliably and well, even as they develop new skills. In a way, this is weird advice! The role you’re thinking of has very different work, requiring very different skills, and being quite good at your current work doens’t necessarily correlate particularly well with being quite good at a lead or manager role. But it’s vital to be seen as someone who reliably gets things done. Ideally, you want your manager, their manager, and related stakeholders to be thinking “when I give X a task, it gets done and I don’t have to worry about it.” People will give more responsibility to people who they have confidence in executing their current responsibilities. You don’t need to be the most highly skilled data scientist/software developer/sysadmin/research facilitator on the team; but you will need to be someone that gets your things capably and reliably done.
So on to the question asked. There’s rightly two parts to the question – how can I get ready, and how can I be seen as a good candidate – but there’s a lot of overlap between answers to the two. If you’re ready to start experimenting, and have some flexibity about the tasks you can take on (which is pretty commonly true in our teams, and one of their huge advantages), you can start practicing some of the pieces of a lead or management role to build your skills and to be seen as someone who will step up to do this work.
The first step is to discuss what you’d like to do with your manager, in your one-on-ones with them if you have those, or as part of some other conversation if you don’t. Depending on your situation and relationship with them, you may not want to come out and say that you’re interested in the possible upcoming manager jobs. That’s doubly true if you’re not 100% sure that’s what you want just yet! But you can absolutely talk about being interested in taking on more responsibility, and what kind of opportunities would there be on the team for that.
(Note that I’m generally pretty cautious when giving advice to earlier career people about conversations with their managers or other stakeholders. Hopefully most will be warm, supportive, and encouraging! That’s generally been my own experience. But not everyone has a manager like that, and a manager that starts feeling threatend can make a team member’s job pretty unpleasant. So I always advise starting conversations like these with baby steps and seeing how they react. If you have a strong relationship with your manager or have had conversations like this before with them, then by all means adjust my advice accordingly.)
Broadly I’d say there’s three important areas where it’s often the case that a senior member of an RCD team can often start playing a role, that would both develop skills and visibility necessary to being thought of as a potential leader:
(Others may arise, depending on your team circumstances: if your or a peer team is going to be hiring someone, for instance, being involved in that process would be extremely helpful.)
If you are able to take on some of those tasks, then the skills you can actively work on include:
So once you’ve had your conversation with your manager, keep an eye out for opportunities to take on those kinds of tasks. With your manager’s support, or at least acquiesence, find one that’s not too big a lift for you, take it on, and spend some time to get good at it. Only then start keeping an eye out for second opportunity to grow your role. It’s way too easy to let enthusiasm get the better of us, and overwhelm ourselves with new kinds of work! Develop one set of new skills at a time; growing in new directions doens’t happen overnight.
Taking on some new responsibility for communicating with stakeholders can be a pretty easy way to get started. If you’re not already doing it, there’s probably opportunities to onboard new researchers, present results, connect one stakeholder with another with a similar interests. A very valuable exercise during those activities or stand-alone is to find out the needs and gaps experienced by those stakeholders, current and anticipated, learn the language used by those stakeholders for describing them, and report back to your team using your team’s own language for them. The ability to consisely describe issues and possible solutions, in the ways that matter most to the audience you’re speaking to at the time, is valuable as part of any leadership task.
Take a role in supervising efforts larger than your own can certainly mean being made officially responsible for a project involving contributions from someone else other than yourself. But it can also just mean being more mindful and taking a bit more initiative in coordinating your own work with related work within the team or in a different team. Depending on the situation, this can mean becoming more aware of and communicating what related work is going on, initiating conversations looking for coordinating efforts, keeping track of efforts, letting peers know how it’s going (possibly with peer feedback), and communicating results.
Mentoring someone else’s career development is really something that can only be done if that person wants your mentorship. If someone comes to you for help repeatedly, you can offer to meet with them regularly to offer help, or you can offer to be someone’s onboarding buddy or support somone in another team. Either way you can not only help them but practice your coaching and mentoring skills. Mainly that involves making sure you’re asking a lot more questions than giving advice, finding out what they’re looking for, and facilitating them getting the support they are looking for. That doesn’t mean you’re on the hook for personally giving them that support, it could mean you double-opt-in introduce them to members of your growing professional network that can advice them on what specifically they’re looking for.
(Of course you can and should be looking for advice as well as you do this work; others in your institution and context will be able to offer more specific suggestions than I can in an email. Don’t worry about looking for A Mentor specifically; look for people whose advice in your situation would likely be helpful, and ask them for their advice. If they are particuarly helpful, ask them another question again after some decent interval.)
If you are already doing these kinds of tasks and really want to test-drive being a manager, and it makes sense for your team and the situation, being a supervisor for an intern or summer student is really a full immersion into the work. Working with an intern or student is the whole lifecycle of working with a team member wrapped up into a semester; figuring out what work has to be done, hiring, onboarding, managing work and performance, giving feedback, handoff of work, and off-boarding.
In some working with a student is it’s even harder than managing a staff member; pretty much by definition they’re much more junior and require more hand-holding. In some ways it’s easier, though – it’s time-limited, and the student is probably going to be doing some very well-defined pre-specified work.
A few months ago in #120 I gave some advice about hiring a intern - including a 159-item checklist for onboarding, managing, and offboarding them which some readers have found useful. The advice there is still good. It’s a pretty clear opportunity to develop your feedback-giving skills, being clear and specific while being supportive and not overly prescriptive. That’s a real challenge for almost everyone. It’s also a pretty clear opportunity to build coaching and mentoring skills; again, the challenge there is to help people grow and learn while letting them decide on and do things themselves.
One last thing that I’d suggest is to spend the next year+ paying attention to your own reactions to the different kinds of work you’re doing. Many new managers really struggle with letting go of hands-on work, with its very quick feedback on what you’ve accomplished and how well you’re doing. Moving towards much longer-term efforts, supporting people as they do the work, can be very demoralizing. As you take on some of these new duties, notice how you feel about them. Do you primarily get satisfaction from delivering some code, analysis, or getting a job running? Or do you also find supporting people’s growth and watching them deliver the work satisfying? Be honest with yourself; there’s no right answer here. The more satisfying you find watching the work be delivered even without your your direct involvement, the more likely you are to be able to find happiness in a lead or management role.
What do you think, (other) readers? Did I miss something, or would you have given different advice? Let me know by hitting reply or emailing me at jonathan@researchcomputingteams.org.
With that, let’s move on to the roundup! It’s a bit of a short one due to a busy week.
Resource Hubs - Lara Hogan
Hogan, whose material frequently appears here, has put her own materials up into several resource pages:
Which of those areas are particular areas you’d like to see more material here on, for our particular context - let me know!
Be critical or be corrupted - CJ Cenizal
A weird feature of human nature is that work we do repeatedly becomes in our mind an end in itself.
When we focus our attention on something long enough it feels necessarily important.
This means, far too easily and commonly, the repeated task itself becomes what we think about instead of the outcome the task is meant to achieve. The means becomes the purpose. Measurements about the task supplant assessments of impact of the work.
I don’t generally put this as strongly as Cenizal does, but they’re not wrong. Focussing too long on the task itself corrupts, and an absolute focus on metrics about the tasks corrupts absolutely.
We have to actively keep the impact we want our team have in mind, and actively make ourselves question the means by which we’re working to achieve the impact, if we’re to avoid falling into that trap. For an example which immediately leaps to mind, it’s super easy for me to obsess about number of subscribers or word count or number of issues of this newsletter when none of those numbers matter in and of themselves. What matters – the only thing that matters – is that some RCD managers get some ideas and support and encouragement they wouldn’t otherwise get. Everything else is implementation details.
Cenizal suggests some things we can keep in mind as technical leaders about the processes we have some responsibility for:
Why four scientists spent a year saying no - Amanda E. Cravens et al, Nature Career Column
OPP (Other People’s Problems) - Camille Fournier
One of this newsletter’s two recurring themes is that it is essential for us to focus our personal effort, and our teams efforts, on where we can have the biggest impact we’re looking for.
For our team’s efforts, this is a question of effectiveness. It comes in various related guises – impact, specialization, processes, automation.
For our own work as individuals, there’s another consideration, too. This isn’t a nice thing to hear, but it’s completely true: our institutions, and the research endevour, will burn you out, replace you, and never think of you again if you let them. Saying no personally and prioritizing our own efforts is about effectiveness, true, but also about maintaining healthy boundaries around work we’ll take on.
We’re often much better saying no to new work for our team, defending them against overload, while needing practice saying no to tasks ourselves personally.
In the first article, group of four mid-career environmental PIs formed a peer group to encourage each other to say no to requests that didn’t advance the highest priority impacts they wanted to have. In a bit over a year, the group succeeded in collectively declining 100 work-related requests. They found that the peer group was extremely useful in supporting them no, and that keeping track also helped.
But it’s still hard! Even with peer encouragement and a goal in mind, they still found that they weren’t saying no quite often enough to the right things:
We declined too many little things — such as reviewing journal articles — and not enough big tasks
The authors had a set of critera by which they judged the tasks no-worthiness; an important and often overlooked one struck me:
Am I uniquely qualified to fill this need?
This applies to us individually and our teams. Even if we or our teams could do something, if it’s not something we particularly are particularly well suited to do, that’s a good sign that the people asking should look elsewhere. That includes outsourcing tasks from our teams as well as declining tasks personally.
In the second article from a few years ago, Fouriner tackles a related issue. Sometimes the problem isn’t others asking us, sometimes the issue is us taking on responsibilities for things that are not ours to fix.
This is hard to spot, for some of us is super challenging to avoid. We’re in this line of work because we want to help, we want to make things better, to make things go more smoothly. So we look around, see broken things and problems, and things that could be improved, and we want to fix them.
[…] you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad […] That kind of grinding frustration can wear you down over time. I know, because I’ve been there. I left a cushy big company job because I saw too many things I felt powerless to fix. When I got into management, I figured that I would have the power to make things right. Then I thought that when I became the leader of all of engineering I could do it. Then I thought that when I became an executive I would be able to do it. Chasing that dream of being able to fix all the things contributed to me feeling exhausted, and dare I say a bit burned out, when I finally decided to leave my CTO gig.
If that sounds at all familar, you might want to read Fournier’s article.
How to Disagree with Someone More Powerful than You - Amy Gallo, HBR
As technical experts and leaders, sometimes the most valuable thing we can do is speak truth to power. An important PI needs to hear that a proposed approach needs to be reconsidered, or the Office of the VPR should know that a stated goal can’t be met with the provided means. And there may be non-technical issues which need to be addressed, such as raising issues of workplace diversity, equity and inclusion.
These are fraught conversation. In the wrong environment, it can hurt your career. And a lot of us are in those wrong environments.
Many of us aren’t, and our relationships with those decision makers are strong and trusting enough that we can have those conversations frankly and productively. But if you are even a little unsure of whether you’re in that happy situation, Gallo has some advice in this article from a few years ago which caught my attention recently.
Gallo’s advice will strike some of you as overdone. That’s ok! But some people are in environments that are less welcoming to disagreement, or may for other reasons of their own be and feel less safe offering a dissenting view. Hopefully this article will be a useful resource for those readers to safely disagree.
Gallo advises:
If you’re proceeding after those steps:
Real-time bioinformatics with Nextflow and Kraken2 - Sarah Griffiths, EPI2ME, Oxford Nanopore
We’ve mentioned before (#134) how scientific and in particular bioinformatics pipelines and workflows solve similar problems as data engineering worfklows you see in tech for data engineering, but in a different regime and context and so need different tools.
Still, the problems being solved are analogous. In tech, there are a number of well established tools for batch processing of data, and the last decade has had a flourishing of tools for stream data processing of incoming data in something more like real-time. In the regimes they are solving those problems, these stream processing piplines can be fiendishly complicated.
So it is fantastic to read Griffiths’ work using an existing scientific workflow tool (Nextflow) to process streaming data as it comes out of nanopore sequencers. Griffiths describes her work using existing Nextflow functionality (and that of a bioninformatics tool, Kraken2) to process data in flight, allowing researchers to see results sooner and even to adjust the sequencing process.
That this functionality was already partially available was news to me, and I’m really interested to see how this work proceeds.
jq is a very useful JSON-munging tool, but its use is famously kind of cyptic. jqp is a TUI playground for playing with jq.
The unix ‘rs’ command for reshaping a line of items into a table.
To support their training and software development efforts, along with other things, the open mainframe project has a new mainframe that can be used, and has launched a COBOL use study. Honestly, I’m not even going to snark here, if you want a good steady well-paying job where your technical work affects millions of people, you could do a lot worse than going into the mainframe ecosystem.
Using a Windows laptop for work, I’m surprised by how capable Windows Subsystem for Linux (WSL2) is. It can’t do absolutely everything, but it’s mostly just a functioning Linux box. And good news(?!): now systemd will be supported.
Building a PCMCIA wifi card for a Windows95/DOS laptop, like you do.
Emulating PalmOS, like you do.
An oral history of the much-maligned Clippy, and its unusual partial come-back.
A lovely article about ARM’s first CPU – the ‘Acorn RISC machine’.
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
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 follow in the email edition; the full listing of 205 jobs is, as ever, available on the job board.
