Hi!

A reader from a U15 research institution [Canadian research-intensive universities; think Russell Group in the UK, or R1 universities in the US] writes in to describe expanding their research computing team with unconventional roles:

First, a grant advisor, specifically to assist PIs in writing sane tech inclusions in their grants. You may have reviewed grant proposals where the medical science, particle physics, quantum chemistry, etc. is very clear, and then the explanation of the computational aspects and the equipment justification sounds like Dilbert’s boss wrote it. That is precisely what this position is intended to improve, but also sitting on internal panels that judge Innovation Fund proposal maturities before they’re allowed to apply, etc. Second, a Communities of Interest Coordinator, who will foster and support research communities of like-minded graduate students, PDFs, etc. around research fields making use of computation—bioinformatics, AI, digital humanities—or around digital research tools—R, Julia, MATLAB, Gaussian, etc. By supporting communities of interest, these groups can become shared knowledge hubs, where newbies can find guidance or “the ropes” and experienced but stuck researchers can find inspiration or “an ear” that might enable them to unstick. Both positions have been filled internally and start in December. More traditional ARC job descriptions are being written up now as part of a further expansion.

I love this! It’s a long-standing tenet of this newsletter that research computing is much more than just technology. It’s teams, it’s communities, it’s product management - it’s people. Connecting researchers and their more directly to the computation, software, and data resources that can advance their work — whether that means in grant writing or capacity building within a practitioner community — is very much part of the our broad remit in research computing and data.

Hi, everyone:

It’s been a good week here at RCT world headquarters.

First, our team finally published our paper describing our v1 platform at a high level - a mere 29 months after creating the first version’s Google Doc. The effort tied together years of not just software development and technical architecture but stakeholder engagement, privacy considerations, team building, and domain knowledge. Several co-authors were software developers who had never been on a paper before, were pretty new to the whole process, and hadn’t necessarily appreciated the “full stack” of the effort. It was fun to help them be part of the process not just of writing a paper but of creating a piece of the scientific record of humanity. Knowing they’ll be able to walk into many University libraries all over the world, for decades, and find a copy of it in the stacks, with their name on it, with authorship and citation records kept basically in perpetuity, is pretty cool.

Secondly, on a personal note, I spent some time at an arm HPC hackathon, which was both exciting (new tech! With many different systems to play with!) and surprising (Oracle’s cloud seems… pretty ok?). But more importantly it was really rewarding to see that after a probably eight year hiatus from day-to-day performance tuning of HPC codes, some of the names and tools may have changed, but a basic understanding of the tradeoffs at play and the techniques used to balance between those tradeoffs translate unscathed and can be put to use immediately. These are fundamental skills.

Hi, research computing team managers and leaders:

In our team there’s been a lot of passages lately - a paper for our original work is (finally!) coming out, as our new version is (finally!) coming together; we’re gearing up for a new batch of co-ops as our current co-ops are starting to document and getting ready to present their work; a project manager is joining the team for the first time now that the effort has reached a size and scope that it needs one (well, it needed one a year ago, but here we are).

These passages - and especially the influx of new people, new tasks, new scope - are really important for a team’s well being. Stasis isn’t stable; systems, including systems of people, are either growing or stagnating.

In academia sometimes it’s far too easy for groups to become very comfortable with “the way we do things”, and set in their ways. As Boulanger points out in the first article in the roundup, that can quickly lead to problems not being addressed - or even really noticed any more - and eventually people both within the team and “clients” of the team starting to drift away. In fact, I was talking to a colleague this week about one group’s services becoming ossified to the point where consumers of those services started moving to those of a different and newer group - the first group didn’t take feedback or feature requests seriously, and now there’s a real chance it will simply be disbanded (or, maybe worse, left go on indefinitely with less and less actual purpose).

Hi!

At least one other research group has also taken to providing some interview questions ahead of time. In response to the discussion in last issue, Titus Brown wrote in on twitter:

Hi!

So, two final aspects of our recent hiring situation that I haven’t had room to mention earlier: we’re giving out interview questions ahead of time, and interacting with peer teams is still hard in this hybrid/remote world.

The first of the two is likely more surprising and/or controversial. We’ve changed a bit how we’re hiring, including sending out some key interview questions ahead of time. This was initiated by a team member, interviewing co-op students. I was initially pretty skeptical, until I attended the resulting interviews; the discussions were so much better, and went so much deeper, that I wanted to keep trying it. Our initial attempts with interns went well enough that we’ve hired our first contract staff member using this approach too (and sent a pretty detailed ).

Hi!

I wanted to give you an update on the co-op hiring mini-fiasco from last week.

Even with the chaos, we still managed to get 3 of our top 4 candidates, because we still have a great team, a sensible set of interview questions, we contacted candidates (just!) before the interview, and followed up afterwards.

Let me tell you about a mini-fiasco this week that was entirely my own doing.

In our team, we routinely hire students for semester-long co-op positions. It happens three times a year - I think we’ve taken part 12 times over the past five years. It generally works out pretty well, for us and the co-op student.

The process is pretty uneventful generally. Our tireless administrative staff, without whom the place would fall apart, lets me know that it’s time again; we post our usual job ad; we interview some students and submit a ranked list. We’ve lately been pretty good at having projects ready for them on day one.

We had a couple more potential student supervisors with projects this semester, which is good. In the past year we’ve been upping our game at hiring full time staff, and part of that is better job ads; so we wrote a much better job ad for the co-op position this year and that resulted in fewer candidates but who were overall better matches for the team. Win-win!

Happy October!

There’s a couple of articles in the roundup this week on professional development and career paths for those in research computing & data - and one of them even emphasizes professional development for managers.

We have a long way to go, but there’s widespread recognition that our profession needs to grow, and slowly growing recognition about the resources that will take. Even, finally, for us managers or team leads.

The weird truth is that the research world greatly undervalues training - it’s just expected that everyone will learn on their own. But from what resources, for research computing and data management? And when are we supposed to take the time to learn? We still need some help.

Hi - I hope your week has gone well!

I’ve been prompted by a few things to think about activity versus accomplishing lately.

Falling into a trap of doing stuff, and so feeling busy and industrious, but not actually getting anything meaningful accomplished is certainly a trap that individual contributors can get ensnared in. We’ve all worked with someone (“or been someone”, he said sheepishly) prone to bike shedding or yak-shaving or some other flavour of spinning around in a rabbit hole without making forward progress. (Whenever I have to explain yak-shaving to someone, is the youtube video I point them to). It can like work to the IC, but to an external observer it’s pretty clear they’re stuck - they were tasked with doing the thing and they are very visibly not taking the direct route towards doing the thing.

Hi!

We’ve talked here in several issues about the “great resignation” that many companies are seeing as the pandemic starts to wane a bit. I think this is playing out differently in our world; there are definitely people leaving, or making new work arrangements, but it’s less en masse. Rather than having trouble with people leaving, instead, it seems to be more of an (even bigger) problem bringing people on.

On the there have been academic positions open since late winter, some that have been re-posted an uncomfortable number of times. That’s for manager positions; I’m also hearing from a lot of people that hiring ICs is getting almost impossibly difficult.

Research computing and data is increasingly a single discipline, a single area of practice. It’s a complex one, too; one which includes the support of first tentative steps which themselves may be research activities, all the way through to production operations of routine infrastructure.

You can read more, or go straight on to the roundup.

There was a on twitter (it happens) about software as a facility, as a tool for enabling research rather than merely as a research output itself.

Quick: what’s your team’s specialty?

Your team’s specialty is its reputation for what it’s good at. Not what you think your team is good at; what matters is what specific thing your stakeholders (funders, clients, institutional decision makers) think your specialty is. What they recommend you for to peers, what they recommend funding you for to decision makers.

In the post-pandemic world, researchers are used to getting their support remotely from anywhere. To compete, your team will need well-defined specialties; and “HPC” or “research software development” isn’t a specialty.

Hi, everyone:

I hope that as the start of the academic year approaches in the northern hemisphere, those of you who are going back to campus are comfortable doing so, and supported by administration.

Thanks to community members volunteering, we have a small core of 4-5 people who will start helping with resources for the community making suggestions to guide the newsletter. If you have suggestions, or want to take part, just hit reply or email me.

Thanks, everyone, for your responses last week.

I’ve been thinking a lot about strategy in other contexts lately - some of you will have noticed that I’ve been back on my nonsense on twitter, about the importance of having a focus. The very insightful comments and suggestions you sent last week about how we can help more research computing teams were very on point, and I think combine to a feasible strategy.

Because within this newsletter community we’ve built together, we have a number of strengths:

Hi, all:

So the last newsletter resonated quite a bit (welcome to new members of the Research Computing Teams community)! It was a bit of a cri de coeur about research computing’s inferiority complex that comes from unfairly comparing ourselves to both research and tech industry computing, and - to my mind - explains why we don’t advocate as well for ourselves as we could, support each other as well as we could, and why too often we don’t hold ourselves to high enough standards. It’s easy enough to see some of the results; poorly supported and run teams, not enough of institutional backing, demoralized team members, people leaving or checking out.

Research computing and data, as a community, has an inferiority complex. And it’s a problem.

This week I saw yet another press release - I won’t link to it, there’s no point in calling out this University or team in particular, it’s not like they’re sole offenders here - about how their new HPC cluster would “transform research”. Look — no it won’t. What would that even mean? Transform it into what? A biscuit? Rugby?

The infuriating thing here is that by all accounts, this was a good and useful procurement. Not only did it increase capacity (even if not to the “capacity knows no bounds” limit specified in the press release) but also the range of capabilities, with heterogenous nodes and a more flexible scheduler. That mean the existing researchers will have access to more resources, and it looks like it’ll be easier to provide support to a wider range of researchers, including those whose needs weren’t being met before.

Hi there:

We’re going into a long weekend here in Toronto - the second-to-last one of the summer - and it’s very much needed. We have a number of pretty ambitious efforts we’re working on, and it’s been a long year already. I hope that you and your team are taking care of yourself, and that you in particular as manager or team lead are taking some time off. There’s an article below on the importance - both for you and your team - of you taking some time off, to recharge yourself and give your team the opportunity to step up.

Also, there was some interest in the AWS ARM HPC hackathon that was in the roundup last week. I know that a number of readers are, like me, in the genomics space right now. Let me know if you think you or your team might be interested in participating in a similar week-long hackathon for ARM specifically around genomics; as always, just hit “reply” if you get this in your email, or email jonathan@researchcomputingteams.org if you want to talk about that or about anything that comes up in the newsletter.

And on to the roundup:

Hi, all:

Success as a manger is defined by a lot of hard work and tough conversations that will pay off over very long timescales. It’s way less immediately gratifying than deploying a new feature or making the CI/CD dashboard lights all green again.

Success or possible success for me this week week: I think I managed to convince some stakeholders to not make a bad and limiting data-related decision which would have limited the scientific effort of a four-year effort; and I’m coaching some team members to take on increasing planning and coordination responsibilities, with an eye towards gauging their interest and current ability towards being leads themselves, over a process which will likely take months. Small steps, tough conversations (there’ll be a lot of feedback conversations about effectiveness in the new responsibilities - many giving positive feedback, but not all), long term payoff.

Hi, everyone:

I hope you’re doing well.

I’ve neglected the “managing your own career” section lately, which I’m going to try to fix; we spend a lot of time here talking about helping our team members develop their skills, which is good and we certainly have an important role to play there, but we have to look after our own careers as well. Luckily in the past week several very relevant articles have crossed my browser, and so I present for you this week an attempt to bring that back into balance a bit.

Are there particular things you’re doing to track your own career progress, or get ready for future next steps? Are their particular gaps you’re not sure how to address or questions about how to progress? Please feel free to email me at jonathan@researchcomputingteams.org or just hit reply, and I’ll answer as best as I can and with your permission ask the newsletter readership to chime in, too.

Hi, everyone!

I hope you’re having a good weekend, and that the past week was good for you and your team.

I’m working (with some help) on tidying up and improving the material from the hiring and performance management series from the newsletter at the start of the year; I’d like to turn those into expanded and more coherent writeups that can help other research computing team leaders (or those interested in becoming one). Other topics that came up when last I asked for suggestions were:

Hi, all!

Here our team is continuing to make post-pandemic plans for how work will work.

Others are further ahead. This week Apple confirmed their very office-centric plans, and similar plans came up again. Apple, which is very much a product company relying on close integration of the work of software, hardware, industrial design, and even materials science teams, very dramatically doubled down on its office-based approach - with a surprisingly flexible (for Apple) approach of allowing up to two days a week remote for some teams, and an unsurprisingly (for Apple) inflexible approach of firing people who leaked internal Apple discussions to the world. Asana is requiring even more on-site time, 4 days a week (the 5th day being their long-held tradition of no-meetings Wednesdays), but with increased flexibility in working hours and conditions.

Hi there, everyone!

It’s been a busy week here of contacting recommended potential job candidates, building consensus among stakeholders, debugging code, and juggling finances - a normal set of activities in research computing management land, where if we’re very lucky we got some training in maybe one of those things.

I’m starting to see some out-of-office notifications in response to newsletter issues, which genuinely delights me - it’s been a long 16 months and we all deserve a break. I hope that those who haven’t managed to take significant time off in a while get the opportunity over the summer or fall.

I also had a very nice conversation this past week with one reader; we’re looking into one possibility for a community forum (which might make unnecessary a revisit of the “Ask Managers Anything” feature from last year), and toying with the idea of community video chats. I’m pretty excited about how a couple of those things might work.

Hi!

I’m back and refreshed from my mini-break from the newsletter; there’s a lot of optimism in the air here as COVID-19 numbers continue to drop and projects are moving forwards.

I don’t have a lot else to add right now, so let’s go straight to the roundup!

Managing Teams

Hi, everyone!

Mainly taking the week off from the newsletter this week (for positive reasons - some family celebrations); things will return to normal next week. But there were some things I wanted to share with you.

First, on the discussion from last week of planning for hybrid distributed/local work, we heard from long-time reader Adam DeConinck about what he’s learned:

Hi, everyone:

We have several items this week about post pandemic management and continuing to manage a distributed team.

It’s hard to hire and retain excellent staff in research computing, particularly (but not only!) in academia. We can’t offer FAANG-type salaries or perks, and if we’re even trying to compete on those terms we’re doomed. Our only option is to play to every advantage we do have: challenging, meaningful work; flexibility in work (which has always been a perk of academic environments); strong benefit plans; stability of employment; ability to support wide ranges of interesting projects; and clear and up-front staff salary bands (making wide disparities between people hired into the same jobs less likely). And we can play to those strengths while doing our best to attract the kinds of candidates want to have real impact on research, feel part of a research and education community, value learning new things and working in new areas, and who intend to occupy a job long enough that the benefits we do often offer (like pensions) matter.

Hi, all:

I think I helped a team find the courage (and the organizational support) to say “no” to things this week.

Strategy for research computing teams is hard. I’ve sort of given up on trying to find strategy articles for the roundup that are suitable for us; most are for either large organizations with many moving parts which make no sense in our context, or for tech product strategy. The product strategy ones start off okay, but they really imagine being able to pivot products to very different markets, and that doesn’t work well for our super-specialized tools. We’re not normally going to be able to take an unsuccessful piece of software for geophysical applications and pivot it into a digital humanities platform. We work as part of the research “market”, not outside of it, and “finding product-market fit” for our individual products isn’t the problem.

Hi, everyone!

This week’s RCT Newsletter is a little slow going out; the reason ties into something I’ve been meaning to write a bit more about, usual research funding grants vs nonprofit grants and what research computing and data teams can learn from that. (Or you can go straight to the roundup).

Any funder has things they want to accomplish, and the goal as a potential fundee is to find something in the intersection of “work that helps the funder accomplish their goals” and “work that we are able to do and that is aligned with our goals”. Excellent work that isn’t in that first set won’t get funding. Money attached to work that isn’t in the second set is at best a distraction, at worst drains your teams’ credibility.

Hi, all:

I got an important question and comment from longtime newsletter reader Laura Kinkead at University of Zurich:

Do you have any recommendations for online management or leadership courses? My manager has given me the go head to take a course or two, and I’m wondering if you have any recommendations for what may be more or less relevant to the research environment. If it would help to be more specific, an area that I’d like to focus on is coaching and giving feedback.

Hi, all:

I hope you’re enjoying the change of seasons. The end of April here brings an onslaught of deadlines, meetings, and events, but things are settling back down now.

Details of the basecamp fiasco continue to come out. As the raw signal folks , discomfort as a leader isn’t inherently bad or a signal of a problem. It’s not our lot as leaders to be comfortable about everything. Listen to your team, even - especially! - when you don’t love what you’re hearing.

Hi, everyone!

If you paid any attention to tech management twitter at all in the past week, you heard about how Basecamp started the week by announcing - in a public blogpost! - a new internal policy about how all committees in the company including the new DEI committee was disbanded, and how politics was now forbidden from discussion inside Basecamp or on official accounts, and how it ended the week with 30% of their 50-some-odd company leaving.

I swore I wouldn’t get drawn into that morass for the newsletter, because “managers behaving badly” isn’t the beat I want to be on - it’s depressing, plentiful, and frankly there’s precious little new to be learned from any given episode. There’s a million ways that managers can do things poorly, with many fewer to do things right, and helping managers do things right is where I want this newsletter to be.

But the actual underlying story of what ended up being being so mundane, so petty, and such an easy trap to fall into I kind of feel like it’s worth addressing.

Hi, everyone!

I have a somewhat short newsletter for you this week; exciting things are happening at work with product adoption and hiring, both of which are taking up a lot of time but are unmistakably good. In addition, we’re having increasingly lovely weather, dear friends are getting vaccinated, and actions and decisions made months ago are are finally appearing in outcomes that are beginning to come together in a pleasingly coherent manner. I hope you, yours, and your team are doing equally well.

For now, on to the roundup!

Managing Teams

Hi, everyone:

Thanks for your comments about earlier hiring and feedback posts. I’m taking those responses and getting some help pulling those together, incorporating the input, adding more material, and putting into some kinds of coherent wholes that can be made more widely available (like the getting started with one-on-ones material). As always, I appreciate your comments, questions, suggestions, and feedback - please always feel free to hit reply or email me at jonathan@researchcomputingteams.org at any time.

For now, the roundup!

Hi, everyone:

I hope you’ve been well; I’ve had a short week with a 4-day Easter long weekend. Between being recharged for the weekend, and finally having a couple of days of work where I could focus on high-leverage activities - hiring discussions for our team and pushing forward a hiring process at an organizational level; writing a document useful in itself but also that will be a model for team members to write others in the future; getting two teams aligned and getting them to find a really good solution to a shared design problem - it’s been a really good week.

It took me a long time to re-orient myself to understanding what “a good day’s work” looks like for a manager. Everything is so much more direct and quicker-feedback as an individual contributor; the thing works or it doesn’t. As a manager, quick wins are few and far between - and you can only be really sure you made the right decision months after making it. So having two or three good managerial days in a row is a nice feeling and a good way to wind down a week.

I hope you’re having similar success.

Hi there - if this is a long weekend for you, I hope you’re enjoying it.

Last time we spoke a little bit about expectations, and routine feedback to team members and peers when those expectations are met or not met. This time, let’s consider - or skip to the roundup.

Feedback is a mechanism to align expectations with your team members in the moment, and to encourage meeting those expectations in the future. Sometimes those expectations were explicit; other times, they were implicit and it’s a helpful way of making them explicit. This is a simple, extremely useful and scandalously underused tool, particularly in research environments. What’s more, your team members want feedback. Do you want more feedback from your manager about how you’re doing? Why do you think your team members feel differently than you do?

Hi, all!

Last issue, I left you with a couple of models for giving feedback. We had Situation-Behaviour-Impact:

“When you presented the proposed plan at the project kickoff meeting, the material you presented had a really good balance of just enough relevant context and case for the plan overview. That helped ensure the discussion afterwards was well informed and not sidetracked into irrelevant details.”

The Manager-Tools model:

Hi, everyone:

This week I want to talk a little bit about giving routine feedback to team members; or you can skip to the roundup.

I mentioned that I find thinking about team members performance in terms of expectations clarifying. That’s more obvious when talking about longer-term goal setting or performance reviews - here are our expectations for the next quarter/year, and then those expectations were met, or not - but I think it’s especially useful when thinking of more immediate on individual tasks.

Hi, everyone -

Here in Toronto we’re enjoying the traditional season of “False Spring”, where a burst of warm weather and blue skies lures the unwary into putting away winter coats - but even so it’s cheering and encouraging, and spirits everywhere are notably lifted.

I’m going to write a little bit about performance management in the next three newsletters. I have a brief introduction to my preferred philosophy of performance management below (or skip to the roundup); in the next issue we’ll talk a bit about short-term performance management (feedback) in the following we’ll talk about longer-term performance (goal-setting and review), and finally we’ll talk about what happens if people are or aren’t consistently meeting expectations.

Hi!

It’s been a big week here - we finally got a long-awaited paper submitted, attended one virtual conference, and are gearing up for another.

I hope you and your team has had successes this week too - are there any you want to share? If so, or if you have any feedback, suggestions, ideas, or questions, let me know - reply, or send me something at jonathan@researchcomputingteams.org.

For now, on to the roundup!

Hi, all!

Thanks for your responses to last newsletter. Readers who responded were broadly pretty happy with the all-in-one newsletter, even if gets a little long; topics that were of interest for future write-ups were (in order of number of votes):

• Performance management

Hi, everyone:

I hope you’re doing well! I have two questions for you.

This week kind of got away from me - it’s been an exciting couple of weeks, with two new team members joining and our project getting ready to take on new responsibilities - but it means that the final instalment on research computing hiring will be delayed until next week.

So I’ll ask two question that I was going to ask at the end of the series.

Hi!

So you’ve got a list of hiring requirements written up - the next step is to think about how to evaluate candidates against the requirements. That’s next, or you can skip ahead to the roundup.

Once you have a pretty clear list of job requirements and a sketched out job description that the team members and other stakeholders have agreed on, the next step, before even a job ad, is to figure out how you will evaluate candidates against the job description.

Hi!

I hope you’re having a good week. Below is the continuation of our discussion on hiring, stemming in part from the more formalized pipeline that we’re working on; you can also skip to the roundup.

Last week I started with the basic premise - you have a hypothesis that you’ve found a good candidate (and they have a hypothesis that your team would be a good match for them). Then, as scientists, the nob is to disprove the hypothesis.

Hi!

The good news is that my team, and the larger organization I’m a part of, is going to be growing substantially in the coming year. That’s also the bad news. We have to hire.

Hiring team members is a time-consuming, exhausting job - and probably rightly so, since it’s the most important thing we do. A lot of planning, organizational, and process mistakes we make as managers can be mitigated if we’ve helped assemble a terrific team; on the other hand there’s only so much pulling on those same levers can help us if we’ve made poor hiring choices. Your research computing team members are the people who do the work of supporting research with working code, data curation/analysis/systems, or computing systems. Putting that time and effort into hiring that makes it time consuming and tiring is absolutely appropriate.

Hiring, like anything else in management, is a practice that you can improve on by having a process you go through that you learn from and improve each time through. That means being a lot more deliberate about hiring (or really any other aspect of management) than we usually are in academia-adjacent areas. It’s also, to be honest, more work. But hiring is the most important decision you’ll make as a manager. Decisions you make about new team members will last even after you leave. A good hiring choice will make everyone’s job easier, and a poor hiring choice will make everyone’s job worse.

Hi, all!

This is the last part of the stop doing things challenge - the change management of actually stopping doing something. Or you can skip straight to the roundup.

The hardest thing about stopping doing things, of course, isn’t the identifying what things to stop doing, but actually stopping and staying stopped doing them.

Hi, all:

Most of us are now well and truly back into the swing of things; I hope you and your team are doing well.

Skip to the roundup

Hi!

Happy New Year, everyone. I hope you had some time over the holidays to rest and recuperate. A lot of us have discovered that it wasn’t enough - we’re still dragging - but we’re less tired than before, research needs us and our teams, and so we’re back into it.

An awful lot of early January writing always advocates for people to start something new - develop a new useful habit, start learning a new skill, make time for other important activities.

Those can be great! But we only have so much time in the day, and to add something useful to our routine we have to drop something else, especially with our and our teams energy levels still low. To add a new high priority effort we need to de-prioritize - possibly to zero - something else.

Congratulations, everyone; we did it.

If you’re at a University, 2020 is now or is soon to be officially at a close. For the rest of us, while there is some work remaining to be done, things are winding down. We made it to the end of 20-frickin’-20.

I started this newsletter together with you in January, which seems like a decade ago. It’s been a hard year for our teams, and a hard year for managers. We’ve had to keep things together and moving with the world falling apart; help team members through incredibly tough times and keep the research and researchers who depend on us going.

We’ve done incredible work, and because of what we’ve done as managers our teams are going to come out in late 2021 stronger than when this started. The trust we’ve built with our teams by seeing them through the tough times will make the team work even better together. Our improving and making more intentional our team communications, necessary for the abrupt move to all-distributed, will be of benefit in the years to come. Our upping our management and prioritization skills will help our team through whatever future challenges come our way.

Research Computing Teams Link Roundup, 11 Dec 2020

Hi, everyone!

I don’t have anything of my own to share with you this issue, but it’s been an interesting week in research computing and so there’s lots of nuggets in the link roundup.

As always, if you find anything particularly interesting, or if there are topics you’d like covered, please let me know! Feedback is a gift, and even though I’ve been shamefully slow getting back to a couple of readers this week I really value your thoughts. I enjoy getting email back, even about things that you don’t like or disagree with.

Hi, everyone:

There were two big stories in the news this week about what’s possible with sustained research infrastructure funding and what happens when research infrastructure isn’t sustained.

In the first, you’ve probably read about AlphaFold, Google Brain’s efforts to bring deep learning to protein folding. It did very well in the 14th annual Critical Assessment of (protein) Structure Prediction (CASP) contest. Predictably but unfortunately, Google’s press releases wildly overhyped the results - “Protein Folding Solved”.

Hi!

I wrote a few weeks ago that, post-pandemic, we in research computing teams are going to have to work to make our value clear to administrations, funders, researchers, and our team members.

A lot of the link roundup items I’ve pointed to over the past year have focussed on our team members, which is crucial - we can’t support research without an excellent, motivated, aligned team doing the work. But there’s a lot less material out coming out on communicating research computing teams’ value to funders and administrators - what are we for, why should this team in particular continue to be here, why are the right team to take on this new, strategically important, project?

Hi, all:

Sorry for the late issue. Between some stuff going on at my end and me still figuring out what a revamped newsletter will look like, this week’s newsletter is both a little late and a bit of a hybrid between where I’d like it to go and what it has been. (As always, suggestions for things you would like to see change to change or would like to stay the same are welcome - just hit reply or email me at jonathan@researchcomputingteams.org)

The big news of the past week has been Apple’s new . Don’t worry, this newsletter is going to degenerate into the cliched HPC/research computing blog writing solely and breathlessly about various new CPUs/network cards/SSDs and endlessly comparing speeds-and-feeds. The M1’s specs in and of themselves aren’t what’s interesting. Rather, the M1 is an example of how CPUs are going to get more different as time goes on, and that will have impacts on research computing teams. The M1 going to be a trial run for a future of more diverse computing architectures that we’d do well to get ready for.

Hi!

This is email #50, and a good time to think about what’s next. It helps that events of this week - the US election, Pfizer’s vaccine - make thinking about the future much less discouraging.

I wrote last week that post-pandemic challenges that research computing teams will be facing include:

Hi!

I’ve had to have a few different difficult discussions around our project this week, and while they were exhausting it’s been great to clear the air. And as far as I can tell they’ve strengthened rather than weakened the working relationships.

I also sat through a meeting with peer who essentially ran a denial-of-service attack on the meeting through his need to talk at length about anything even tangentially related to the topics at hand. It (almost) killed any chance that the meeting would accomplish anything. I’ve been trying to push myself to talk less and ask questions more during conversations; some days are better than others, but that experience has encouraged me to redouble my efforts.

It’s been a long seven days for a number of us, for a lot of reasons. I hope the week has been good to you and your team.

Hi!

Most of us have made so many half-plans about the future after COVID (“In a couple months, when this blows over..”, “By August, we should be able to…”) we’re a little wary of putting time into deciding on next steps.

But planning for the future is part of the job. Earlier this week I wrote up my thoughts on what academic research computing specifically is likely to look like after the pandemic is fully controlled.

Hi all -

The folks at Raw Signal Group’s latest newsletter points out that while a lot of bosses are managing to keep the big things going, a lot of us are dropping balls these days especially on the little stuff. There’s a lot to handle.

When I get busy I tend to lose discipline at exactly those things that keep me focussed and productive - prioritization, todo lists, staying on task, - and that leads to dropped balls. In the last week or so I’ve managed to claw my way back up from that and have got things going pretty smoothly again - but it took a while. So I hope you and your team is doing ok and that you’re spending the time you need on keeping yourself well.

Hi, everyone:

I had a couple of good talks with fellow research computing team managers (in title or de facto) this week resulting from either the newsletter or the SORSE talk last week.

The problems each were wrestling with were tricky and stressful, and it was a reminder of how lonely management can be. I hope this newsletter - and the AMAs (Ask Managers Anything) section we had for a while, and will have again - helps cut through that a little bit. I also I hope we can find or build more forums for exchanging knowledge, advice, or even just sharing the victories and defeats in research computing.

Hi, all:

As I write this, the jurisdiction I live in (Ontario, Canada) is almost certainly about to start additional COVID-19 restrictions - 4-8 weeks later than it should have. The predictable, and predicted, second wave is reminding us that we’re going to be dealing with the pandemic for some time to come.

This time has been hard for some of us, and extremely hard for others. I hope your team is doing well. I do think we will come out of this experience better managers - more deliberate about finding out our team members needs and in our communications, more thoughtful in our planning - but it’s challenging and tiring, and I hope you take some time for yourself.

The roundup follows:

Hi, all:

It’s been a good week here to remind me of the breadth of skills we need as research computing managers. I’ve had to meet separately with several groups of research stakeholders, and with a legal team on topics of licensing and privacy, helped a team member debug a service, clarifed the scope of multiple tasks, put together a budget for a project that might never be, helped configure some authentication, give a presentation, and coached a team member on presentation skills.

One of the things I’d like this newsletter to grow into in year two is a bit more of a community where we can exchange tips, best practices, and knowledge on the dizzying number of sills we need to have at our command. To put it mildly, my training as an astrophysicist did not prepare me for this.

But it was nonetheless a great week! The team continued on without me with zero issues while I was away for two days (an experiment I’ve been needlessly hesitant to try since the pandemic started), progress is outstanding, and efforts with other stakeholders started months ago are starting to pay off. Our skills from our previous careers do carry over, and we can be successful - sometimes it just takes more trial-and-error than it would have if we had a bit more of a community of research computing team managers.

Hi, everyone:

Sorry again about the slightly irregular time, and the lack of much of a preamble - heavy deadlines these past two weeks, and I’ve been thinking about directions we can steer the newsletter in the coming year. But the deadlines are past now and it’s back to normal.

As always, share your thoughts with me - just reply to this, or email me - about directions you’d like to see this go. There’s so little out there specifically for us research computing team managers that there’s a lot of things we could usefully do! I’m always interested in direction from the community.

Hi -

Sorry for sending the newsletter out somewhat late today. There’s a lot of good material in the roundup - noticing change, understanding why your team is doing things you don’t think they should, Rust in science, transferring knowledge, telling stories with video, HDF5, a better tar, and underwater data centres.

As always, reply or email me (jonathan@researchcomputing.org) if there are things you’d like to hear more about, stories or topics you think our readers would like to read, or any other feedback.

Now on to the roundup!

Hi, all!

Just a short introduction this week - there’s a full set of links to round up this week, with a lot on communicating with teams, watching out for burnout in ourselves, academic communities, and

The newsletter is nine months old now. As the list of resources covered here grows, and we see where the gaps are for topics research computing team members need to be discussed, my plan is over the coming weeks to trim down the number of links covered each week and to focus on a bit of writing on topics that aren’t widely covered. That would mean things like grant writing for research computing, research community building and the like. That will probably also include interviews with research computing leaders.

What do you think; what would you like to see more of, and what do you think the newsletter could do with less of? Hit reply and let me know.

Hi!

Our last AMA (Ask Managers Anything) question was:

For non-embedded teams, what do you do to keep researcher clients / stakeholders up to date on progress of work?

Hi!

Our AMA - Ask Managers Anything - last time was “How are you keeping morale up during these challenging times”? We got a couple of answers:

I’ve been doing basically the same communications work I did before but more of it - focussing on the big picture vision (which the team really cares about), lots of listening in one-on-ones and keeping an eye on slack. Early on we tried some team lunches (ordered delivery for everyone) and a couple team happy hours, and they were fine I guess but didn’t seem to move the needle.

Hi!

Our AMA (Ask Managers Anything) question last week was:

Hi!

Our question last week was about having difficult conversations with your team members. I got two responses from managers:

Haven’t really needed to have difficult conversations in my team; I have peers who do, but my use of has been effective. “May I give you some feedback? When you are on your phone during the staff meeting, it appears as disengagement and others can find that rude. Can you change that for the next meeting? Thanks.” Positive:negative feedback is about 8:1 or even more.

Hi!

Last week’s “Ask Managers Anything” question was “How are you making sure that junior staff get access to mentoring when everyone is working from home?” I got several replies back; paraphrasing them for anonymity:

• I don’t have any junior staff as direct reports, so it hasn’t been an issue

Hi, everyone!

“How are you making sure that junior staff get access to mentoring when everyone is working from home?” was the most popular question on our first go at Ask Managers Anything.

I’ll give my answer, and please send in yours (with indications as to whether I can use your name or not). I’ll collect them and include them in the next roundup - help our entire community learn from what you’re doing.

Hi everyone -

I hope it’s been a good week for you. On our side we’re setting up our first Jira sprint on a project I’m really excited about — and we have a really great PM helping us, shoring up one area where I personally am not great. Between the team, the project, and getting some help for a managerial area I’m weak in have me really eager and optimistic about how this is all going to go.

In terms of the newsletters, I’m gearing up to try the Q&A and the interviews that wee suggested.

For questions, the first version of the Research Computing Teams AMA (Ask Managers Anything) is up . Please post (they’re moderated for spam) and upvote questions! Top questions will get posed to the community every week with results summarized.

Hi, everyone:

I got a number of responses back from last week’s question about interviews or Q&A people were interested in both, at least trying it out.

The interviews will take a little while to line up. If you have suggestions for research computing managers you’d like to see interviewed, please send the suggestions along. And if you are interested in volunteering, please do volunteer too! I’ll build a list and then start asking people. And for Q&A I’ll set up an online question box.

And with that, on with the roundup! There’s a bit of a writing and hiring theme this week, as you’ll see below:

Hi!

Well, the move across institutions happened, which meant for one glorious moment I was at inbox zero on my work email. Other than that, the move was unremarkable, largely due to our insanely capable administrative staff.

In other news, this roundup now marks exactly 6 months of the RCT roundups; we’ve done 26 of them now, as well as a daily sequence for a week which didn’t work very well, and a quickstart on doing remote One-on-Ones once our offices all started closing. I’ve really enjoyed it and learned a lot.

Now that I think I’ve got the hang of the link roundups, I think it would be good to branch out. Two ideas that have come up a couple times are:

Hi, all:

Half the year has passed, it’s Canada Day week here, and it’s the last day at our teams organizational home for the past four years before moving to a neighbouring institution. It’s been a good opportunity to take stock, and our team has some suggestions for what we should do differently starting afresh next week.

And I’d definitely welcome input from you, too! A reminder that all tracking is disabled on this newsletter — I rely on the old-fashioned approach of you emailing me to tell me what is interesting, what isn’t, what you’d like more of, and what you could do without.

So with that, on to the — somewhat shorter for the holiday week — link roundup!

Hi!

As we get ready to move our team from one institution to another, we’re taking the opportunity to reconsider how we do things on our team and reset expectations about how we operate and what we’re aiming to achieve - as a team, and as a project.  The switch to working from home was an earlier opportunity to clarify and reset, too.

In Canada, 77% of IT organizations say that expectations around everyone going to the office everyday have been changed probably irreversably by the pandemic.  With universities, hospitals, and research institutes constantly tight on space, I have to think that a lot of our organizations are having similar conversations.  In the jobs section, there’s a first for the newsletter - a manager position listed a remote position.  At your org, are people discussing having work from home being a serious option in the future?  Is anyone considering operating as a fully- or mostly-distributed team indefinitely?

Hi, everyone!

It’s been a weird couple of weeks here at RCT Global Headquarters. Our entire team is moving institutions, following our boss, and so there’s been a flurry of paperwork, both helping coordinating offers and then arranging for the resignations once those were out.

Coordinating a mass resignation wasn’t quite as fun as it sounds. And it’s funny to see how invested we are in our teams; I actually had to suppress a momentary gasp of dismay when I received the first email with Subject: “Resignation Letter”, even though I (a) asked for the resignation letters and (b) provided the template, both less than an hour before.

The work won’t change at all, but we’re moving to a much larger institution, with more peer technical teams to interact with. So I’m looking forward to “being at” our new workplace, even virtually. Now there’s just the barrage of new hire paperwork and elearning orientation modules to go through. (And if you’re curious - even our boss, who’s moving into a C-level position, had to diligently work his way through those. HR processes will simply not be sidestepped.)

Hi!

Sorry for the late roundup this week - the week kind of got away from me.

But there’s been lots to talk about, so on we go!

Managing Teams

Hi, everyone.

Many people in our community — and in the broader research community we serve — are in pain this week. There’s another video of another Black man, George Floyd, begging for his life while being murdered by a police officer in Minneapolis. Here in Toronto a Black woman, Regis Korchinski-Paquet, died when what should have been a routine call resulted in a mystifying number of police officers showing up. With only police officers present in her apartment, she went over her high-rise balcony to her death, with her last words being, repeatedly, “Mom, help”. This is all taking place during a pandemic which is disproportionately killing and incapacitating Black people, Indigenous people, and people of colour because they have less access to jobs that can be worked from home, and are more likely to be living in overcrowded multi-generational homes.

So with news and social media being dominated by consequences of systemic racism, anti-Black violence in particular, and in reaction to anti-police-brutality protests, a lot of people are feeling despair and anguish.

Hi, all:

Some jurisdictions are starting to make plans for people returning to offices. For those of us who can readily work from home, that return may not be for a while; but planning is still worthwhile.

Return will likely look like “split offices” for a while - a few people going in in “shifts” while others work from home. The challenge then is to get the best of both worlds, convenience of WFH and serendipitous interactions, rather than the worst of isolation and cliquing up.

Hi!

I asked last week about your team’s productivity and how it is holding up. Here and on twitter you sent me the full range of answers; it was a rough 33% split between up/the same, down, and it’s complicated. Two factors out of our control caused much of the variation: personal circumstances of team members and the type of work done. But there are some things readers have done that have helped. Scoping work tighter than before, communicating explicit expectations ahead of time, and more frequent status reporting all seem to have worked.

Hi!

I asked last week about onboarding; people who responded last week said they weren’t bringing on student interns or new hires at all at this point in the pandemic. It sounded like at least our research computing team managers had succeeded in avoiding layoffs in their teams, sometimes despite an unfavourable - in one case very unfavourable - pre-COVID-19 environment, but several were not bringing on research students, either because of complexities on onboarding, that they just didn’t have the time, or because schools had stopped their placement programs.

A question for this week - how are work hours and productivity going in your team right now? There’s that after an initial dip, productivity has actually risen; but I think it’s more complicated than that, especially for research computing teams. has seen more hours worked (and more variable hours) but it’s not clear that total number of PRs or commits has gone up - people are working longer but not necessarily getting more done.

Hi!

Winter/spring semester is here, and our team is onboarding (completely virtually) new student interns. For the student working most closely with me, we’ve been very careful to spell out very specific goals for the first month or so, and scheduling lots of one-on-one chats with the whole team. So far it seems to be working well, but it’s definitely slower than the usual onboarding process! I’ll report back how it goes - are you bringing on interns (or new hires) now? What approaches have you been taking?

On to the roundup:

Managing Teams

Hi!

The newsletters have been getting kind of long lately, which makes them unwieldy to read. In this issue I’ll keep things much shorter (fewer items, and fewer words per most item).

Let me know (just hit reply) if there’s other approaches you’d like - like being able to subscribe just to certain sections of the newsletters, and/or having smaller more frequent issues.

And as always, please do give feedback on anything that you like or don’t like about the newsletter. Research Computing Teams doesn’t have any analytics - no creepy single-pixel trackers or link redirection to track link clicks - so the only way I know if links were popular or uninteresting were if people email me back to let me know. So do let me know!

Hi everyone:

Watching the research computing community respond to the pandemic has really been remarkable. We’ve seen centres all over the world make their systems available for COVID-19 research, and even individual desktops by the tens of thousands contributing via folding at home; teams have scrambled to update software and support new users and install newly freely-available software to support those users. We’re seeing a really gratifying flurry of which research computing teams are supporting, reams of truly open data being made available, and rapidly assembled collaborations starting work.

Hi, everyone:

We have articles below on us and our teams - how to onboard, communicate, and develop our team members - our teams and their place in our institutions, maintaining software, filesystems, and a lot of upcoming training and conference events.

There’s several recent papers, not just blog posts, in this roundup, thanks in no small part to a reader and co-worker’s recommendation to get started with Zotero, so that my “to read” papers are now sitting somewhere more organized than browser tabs or in Notes (thanks, Aman)!

So, onwards:

Hi everyone:

The past weeks have enormously increased awareness globally of some issues we in the research computing world face. The vital importance of data, the importance of sharing data, and yet the messiness of data and the fact that columns labeled “cases” or “deaths” in tables from two different sources don’t necessarily mean the same things. The importance of understandable, maintainable software, and yet the limitations of analyses and modelling.

It has also really highlighted importance of research, and research computing has shone brightly. The diversity of research computing brought to bear on COVID-19 is really an amazing demonstration of how broad the field is. You’ve probably read the “supercomputers do big simulations of spike protein” stories more than any other - HPCs gonna HPC, and those big systems have big press offices - but the much wider and honestly much more relevant research computing stories have been about high-throughput model-based screening of possible antibodies, careful , , economic modelling, , secure ..

Hi!

Every single week I wonder if there’s going to be enough material to send out a meaningful link writeup, and each week I end up leaving a bunch of material out.

Still I still wish there were more good sources of specifically research computing materials I could include; if you know of any, please let me know!

Hi!

It’s been quite a week. Research computing teams across the world are contributing to the effort against COVID-19 by prioritizing support, computing access, data analysis or software development. A number of vendors of cloud infrastructure or proprietary software have waived their fees and teams are rushing to make them available to their researchers.

If you’re working somewhere where you can help out in those ways, it can be great to feel like you’re contributing to those very timely efforts - that you’re doing something to help.

On the other hand, if you’re not in that position, it’s easy to feel like you’re on the sidelines while important, urgent work is going on somewhere else. But that’s not the case.

Hi, everyone:

Sorry for the off-cycle email.

A lot of us are trying to figure out how to manage our teams now that we’re not all working in the same space. I’ve written about one-on-ones before; if you’re already doing them, they will help you stay connected with your teammates over the coming weeks.

If you aren’t, I’ve put together a one-week plan to get started doing one-on-ones with your newly-remote research computing team. For each weekday, there’s about 20 minutes total of reading plus homework to do to get you started doing one-on-ones with your team starting one week from when you begin. There’s follow-up activities in weeks two and three to take stock, make tweaks, and start thinking about tools that will help.

Hi, everyone:

Even with stay-at-home orders and mandated social distancing, we’re very fortunate in our line of work. Much of our research computing efforts can be done remotely; and here in Canada, as well as elsewhere, research funders have made it very clear that they will provide as much stability as possible, and that they’re prepared to be sympathetic to hitches in research plans. While it’s hard to know what the future holds, even with massive government deficits it’s hard to see there being much of an appetite to slash science funding in the next couple of years. The same stability which can be infuriating when needs are growing and we can’t hire or procure at the speed we would like gives us a lot of protection in tough times; colleagues and friends in other industries aren’t as lucky.

But that doesn’t mean what we’re doing right now is easy. Even if no one we know is directly effected by COVID-19, we’re trying to keep research moving as a manager under really challenging circumstances.

Hi everyone -

Sorry for the lateness of this roundup. Like many of us, my team switched to into pure-remote mode this week; a move that has a lot of positives (No commute! Coffee we actually like!) but real negatives too (Last minute scrambles; juggling family and work commitments; increased pressure on us to manage effectively in this new environment).

In research computing, we’re better positioned than most to handle a push to remote. And as disruptive as shifts like this can be, big changes at work can create a moment for us to try new things and reset expectations. If you’ve been toying with the idea of doing one-on-ones, giving more consistent feedback, delegating more tasks and decisions, or making other changes to how your team works, this can be a good time to make one or two of those changes. In the next week I’ll put up a blog post on getting started with one-on-ones; if people are interested I might even do a webcast.

But most of us have read more than enough on remote work or COVID-19 in the past weeks, so let’s make the rest of this late and somewhat briefer link roundup a remote and coronavirus-free zone. The theme that seems to have emerged is productivity - managing our own time, our external communications, and even some of our computing more productively and with higher performance.

Hi!

This week the COVID-19 saga is starting to have a big impact in the world of research computing. Conferences are being cancelled or switched to videoconferecing, and institutions are considering work-from-home policies.

Working from home works well for many of us in research computing. But it has management challenges that I’ve talked about before in the context of distributed teams. Without the opportunities to bump into each other in in the office, it takes more deliberate effort to keep lines of communications open. Maintaining good working relationships, staying on top of work done, and giving useful constructive feedback becomes harder.

That means that you or your team mates working from home does not absolve you of management tasks like having one-on-ones or providing helpful performance communication. Just the opposite, it makes it important! Remote one-on-ones work extremely well — when travelling or people are away I quite happily use Zoom or Slack (paid slack with their steep academic discount is worth every penny, easy to apply for, and their video calls works pretty well). Here’s one post I like on doing .

Hi!

Last week’s roundup was a little link-heavy, and I’m hearing that it ended up in some people’s spam filters; sorry about that. If ever you don’t get one of these emails, you can check out the archives - it wasn’t my intention to maintain an archive of these posts, but people have found it useful.

Interesting week this week - building team members up, breaking legacy code down, and SQL takes an unexpected turn. Read on!

Hi!

Thanks for following along through the week. I don’t think this first round of through-the-week emails worked as well as I had hoped, so I’ll pause that for a week or two until I find a format that works better - thanks for your patience and, as always, any feedback.

On the other hand I feel like the link roundups are coming out pretty well, so I’ll certainly be continuing them. This week: exploding rockets, strangle old code, and how to improve your technical skills in just three horrifying steps.

Onward!

Part 4 - Challenges of Managing in Broad, Rapidly Changing Field

One final challenge of research computing is the breadth of what we’re expected to know and be able to respond to.

“Computing for questions that haven’t been answered before” is a pretty broad remit. Even in pretty tightly-scoped efforts like the one I’m working on in genomics, I’m routinely expected to have opinions on and possible approaches for any random thing a researcher could possibly want to do with health genomics data.

This is a problem that comes with a field’s success; when I began in research computing in the mid-90s, the problems that were amenable to the computing of the day were a fewer and less heterogenous. You could call a person a “research computing expert” and it would have a plausible and well-understood meaning - it probably meant familiarity in a Unix environment, with numerical methods knowledge, programming skills in both C FORTRAN, and probably some domain-specific expertise in partial differential equations for some discipline.

Part 3 - Challenges of Managing in an Academic Environment

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, stuff.

Part 2 - The Cutting Edge, and Moving It (Carefully)

In research computing, we’re always building at the cutting edge of something - whether that’s the technology, the use case, or the methods being implemented.

What part of a project is on the cutting edge will vary from effort to effort. It might be using well established methods and technologies but trying them out on a new problem (say applying existing statistical methods to data from new kinds of devices); it might be testing a new method for a familiar problem, using established technologies (trying emerging simulation techniques to get higher fidelity results in an area of fluid dynamics); or it might be trying to apply a completely new technology to a standard method for an existing problem to try to gain new capabilities (like the case of building cloud architectures for the analysis of archival wether simulations we saw on Friday, or taking advantage of NewSQL databases for curating field data in the environmental sciences). But something will always be new; implementing mature methods for well-understood problems on stable technology is enterprise IT, not research computing.

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.

Part 1 - Research Computing Management is Different, and Important

Happy Valentine’s Day!

We’re roughly at the middle of February - thanks for following along with the Research Computing Teams newsletter! Next week things will start in earnest - I’ll start having additional emails through the week, along with the weekly link roundups.

The regular shorter emails will generally follow a theme for the week, with the link roundups remaining a grab bag. Likely themes so far will follow below; they’ll likely tend to alternate between the people side and the technical side of our profession.

Hi!

It’s been an interesting week online for research computing; we have relevant news ranging from managing people to managing workflows at global scale.

Managing Teams

- Rachel Muenz, Laboratory Manager An older article that Laboratory Manager sent around on twitter this week. It’s written in the context of laboratories, but carries over very clearly to research computing teams. They mention two opposite signs to look out for:

Hi; I hope you’ve had a good week!

This week, Clayton Christensen died.  He was most famous for his book on The Innovator’s Dilema, which has more going for it than “disruptive innovation”; and for his influence on Andrew Grove, who turned around Intel in the 80s(Grove then wrote a book, High Output Management, which remains extremely widely recommended in tech circles for those who want to improve their management and leadership skills; it advocated quite early on for regular one-on-one meetings, for instance).

But Clayton Christensen was also beloved by students at Harvard Business School for the genuine interest he took in teaching, and he felt :

Hi; I hope you’ve had a good week!

A reader chimes in on the link roundup comments on one-on-ones, from the perspective of a director of research computing embedded in a larger unit. I’m sharing it with their permission:

Absolutely right on the one-on-ones (or O3s, as we call them). Our whole [unit] picked up the habit from , and we had the founders come onsite years ago a couple of times to deliver their Effective Manager and Effective Communicator training. Having O3s with my Research Computing staff weekly and a weekly staff meeting allows us to move forward with work and not spend time running up and down hallways. They know they have 30 minutes with me and no distractions.

Hi:

I hope you’ve had a good week!

These were the resources that I saw circulating this week (might not necessarily be from this week) that I think our community might be interested in.

Hi:

Even though the newsletter won’t start in earnest until mid-February or so (January is packed with deadlines), I’ve decided to start sending the link roundups. There’s a lot of interesting stuff going on in the world of R&D computing and teams, and neither letting it all go by un-heralded nor sending you one huge link dump full of then-stale information in February seemed right.

So I’ll start the Friday link roundups now; this will give you a chance to send me feedback about what you find interesting and what you don’t, and me a chance to get used to sending the newsletter, before things start in earnest next month. Also, if you don’t mind, I may take the opportunity to experiment on you over the next couple of weeks with a couple of different newsletter emailing services (I’m currently choosing between the stripped-down Buttondown and the less configurable but fancier with nicer authoring options. This one is sent with Buttondown.)