Research Computing Teams - Call to Action and Link Roundup, 14 Aug 2021
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.

Today’s is a bit shorter - the beginnings of a call to action. 

Because the fact is in research computing, our teams have enormous advantages over other kinds of work, which are can attract and engage the right team members.  We have inherently meaningful work (supporting many researchers pushing forwards human knowledge) like say nonprofits, while having high and reliable salaries and the ability to work on many different projects and with many different tools.  

Our teams - and we as managers - come with terrific advantages that in industry executives pay large sums of money to either train for or screen hires for: if you seek out jobs advancing human knowledge by supporting research, you have a growth mindset, the expectation that people can grow and develop new skills,  “baked in”.   You’re comfortable with uncertainty.  It’s you and your team vs the problem.

We have the benefits of a startup (defining the problem while working on the solution, everyone gets to do a little of everything, wide scope) with the mission-driven focus of a nonprofit with the (at Universities, say) large-institution benefits stable jobs, salaries, pensions, and tuition benefits.  

As a result of all this we attract some of the smartest, driven, curious, people around who are all eager to engage with hard problems.  We just need to help support them, lead them, give them opportunities to grow, and advocate for them - and ourselves.

We’re getting close to having a critical mass of readers here - almost 150 community members.  Some joined last week, some are here from a year and a half ago.  We’re almost at the point where we can start helping each other, sharing information within the community from member to member, and reaching out to peers elsewhere to offer them help and guidance. 

So I’d like to ask you for your advice.  What here has helped you, and how can we help other managers or leads together?

  • What problems have you faced, as an early manager/lead or now, which you think peers probably need help with?
  • What resources might help them?  Or you?
  • How can we contact other research computing team managers, leads, or those thinking of becoming one?   Should we collaborate on a “Ten Simple Rules” paper?  Give talks - where?  What kinds of materials would peers want to see?
  • What kind of community communications would you be interested in participating in so you’re hearing from others, not just me?  A slack or discord or Zoom meetings?  Slacks or discords?  Something new like Circle?

Email me - hit reply or email jonathan@researchcomputingteams.org - or set up a 15 minute call with me.  I appreciate the advice some team members have already given me, and I’d love to hear yours.  I’ll summarize results next week.

For now, on to the roundup

Managing Teams



“We need to talk”.  “Fine.”  These all messages or responses that would be very uncomfortable for us to receive from our boss; but when things are busy it’s pretty easy for us to communicate in exactly that way with our team members or peers.  Your boss (probably) isn’t a jerk, and neither are you, but when we have a lot of things on our mind it’s easy to not pay attention to how our words might seem.

In this article, Ayoub councils us to routinely put a tiny bit of effort into written and to some extent even video communication with our team members:

  • Put yourself in their shoes - how will this be received?  This is really easy to understand with a moment’s effort: before you hit send just read the message over imagining it was coming from your boss.
  • Mind the punctuation - a little “!” goes a long way to a “Thanks” or other message
  • Always respond - even if just to say that you read the message
  • Practice CATTE - make sure your response gives Context, Answer to the question, Timeline (does this need to be done now or is it for a week from now?), Transparency, and some kind of Emotion
  • Balance digital interactions - with whatever kind of face time is feasible

Of Ayoub’s recommendations, I’m personally the worst at always responding, even (especially) when I don’t have time to do anything about the message at the moment.  I need to get better at that.  I know for a fact that it makes my team members feel ignored (and why wouldn’t it?)

This stuff is especially important with us all being distant from each other.  When we switched to everyone working from home, I started putting a lot more exclamation marks in my emails, started using emojis a lot more in Slack, and added a lot of gushing to positive feedback and compassionate (but still firm) tones to negative feedback.  

You know how in silent films, it initially seems to modern eyes like the stars are overacting?  Compared to today’s movies, they lacked an entire channel of communication - sound - and so they had to make up for it in expression and body movement.  It’s not overacting, it was acting the appropriate amount to convey the intended meaning given the limitations of the medium.  

It was initially uncomfortable and unnatural for me to emote that way in text.  But written communications, unleavened by in-person interactions, is pretty limited.  You have to “over” emote to effectively convey your intended meaning.  Otherwise, people will imagine all kinds of things lurking behind your opaque words, and they are apt to latch onto the worst possibilities.