#7 - Link Roundup, 20 Mar 2020
What lies ahead; hold on before giving advice; managing one-on-ones; slack etiquette; managing remote teams
Even with stay-at-home orders and mandated social distancing, we’re very fortunate in our line of work. Much of our efforts can be done remotely.
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.
You’ve probably already gotten over the first hump. Most of us are working remotely now to the extent possible; and we’ve gone through the initial period of adjustment with tooling and home office setups, and are starting to regain some productivity. But now that it’s becoming clear that this is going to be the new normal for a little bit, the recognition is setting in that it’s not just about tools, but about culture and process too.
We know now we probably can’t just wait for us all to be back into the office to make that big architectural decision around a whiteboard - we need to figure out how to do some of these things purely remotely. It’s not just big things, either; just to keep the team working well together we need more explicit and more frequent communication (not always super comfortable for those of us trained in the research world), more deliberate approaches to team activities and meetings (ditto), and to rely on long-form written communication a bit more (which actually does suit many of us just fine). In addition, some of our team members are finding the uncertainty very hard, or have family members who are directly effected, and need some extra help.
Our responsibilities extend beyond our own team, too. Communication with our, communities, stakeholders, and bosses needs to be tended to in the same way; frequent communication to let them know what’s going on is needed, while being understanding if our questions and needs maybe aren’t their top priority right now.
The good news is that the skills and habits we’re building now are going to make us even more capable managers and leaders. I’ll do what I can to help, by curating advice here in the link roundups, and writing a bit more; Monday I’ll preview to newsletter subscribers a blogpost on getting started with remote one-on-ones right away.
If you do find yourself having lulls in this newly-remote work — or just need a break from the increased communications demands of managing in this environment — there are a lot of opportunities right now to get caught up on learning about new tools and technologies for research computing, along with learning about new research computing projects. I’ll update those here; several now-virtual conferences are having their attendance opened up, and lots of training materials are being released early.
So with that, let’s get started:
One trap that’s really easy to fall into for those in either technical roles or in research — and so doubly easy for those in research computing — is rushing to give answers or advice to our team members. We got where we are by being experts in stuff, and so it’s very easy to just naturally give answers to people who are hitting issues.
Stanier has recently written a book (the Advice Trap) on this issue, and has given a number of interviews on the topic. He points out that there are three big problems with rushing to give advice:
We may not actually be solving the real problem they have; e.g. the “XY problem”. (Worth remembering when consulting on any issue: if they could concisely state the exact problem, they’d probably already have most of the answer).
Even if we got the problem right, our answer’s probably not great. The thing we just thought of five seconds after hearing the problem is likely a pretty unsophisticated answer to the issue they’ve been wrestling with for a while (and let’s face it, they’re unlikely to tell us that).
Even if we got the problem right and the answer right, it’s just not good management. Shouldn’t we be teaching them to find the right answer themselves - for their own development and so we have to solve fewer problems?
Stainer has a pretty pragmatic approach to avoiding this trap - just don’t be so quick to give advice, even when asked. Instead, stay curious about the problem and their approaches so far (attempted or conceived). Keep asking questions and digging deeper, find out what they’ve been trying, and congratulate them on ideas they have that seem like a good approach. Crucially, even if you theoretically could have come up with a better solution, theirs is still probably the best approach if (a) it develops their problem solving skills and (b) it was come up with by the person who is going to implement it, so they’re fully committed to making it work.
How to manage one to ones - Dan Moore, Letters to a New Developer
I’ve shared several posts here about one-on-ones from our point of view as a manger; this one is written as advice to someone starting out as an initial contributor, focusing on what they should be aiming to get out of a one on one. Whichever side of the conversation you’re on, it’s worth spending some time thinking about what the other person should be aiming to get out of these conversations! One-on-ones are about the direct report, and this gives some idea about what they might want to be hearing. Really it’s not too hard to identify with the points made here; they’d be pretty much exactly what we’d want to be covering in one-on-ones with our boss if we had them.
Creating a Slack Writing Etiquette Guide for Your Workplace - RC Victorino, Slab
This is a great overview on using Slack well in a workspace. Like so much, whether the tool is used effectively or not comes down to setting clear expectations, and it’s our job as manager to set and communicate those expectations.
The points the article makes strike me as dead on, although it took me a while to come to these realizations myself (in particular I hate hate hated Slack threads when they were first introduced, and in my dotage it took a while to get used to emojis, as reactions or otherwise). The point about not using on Slack for synchronous communications as opposed to ephemeral communications I think is exactly right and wildly non-obvious.
Make sure your messages are well written and have needed context
Don’t use it for synchronous communication - use it for ephemeral communication (stuff that doesn’t need to be kept) but asynchronously, like quick emails
Use channels well - have channel descriptions and purge no-longer-used channels regularly
Be sparing with group DMs - are you sure none of this conversation would be useful to someone else? You can always create a channel and purge it later
Use threads so as to not derail a channel
Have one or more non-work channels to keep the other channels work-focussed
Use reactions as acknowledgements
Use emojis to make up for lack of body language/facial expression
A Guide to Managing Remote Teams - Know Your Team
Approximately seventy-eleven thousand articles have been published on doing remote work in the last week or two. This 60 page ebook (no email required, although they do politely ask for one after the download) was one of my favourites, just because it was relatively comprehensive; there’s also a one hour workshop version of this material. Some of the sections aren’t relevant for us in this situation - compensation in remote teams, for instance - but most of the other material is quite relevant. The bit on the importance of onboarding is going to be very relevant to our team quite soon - we’ll be onboarding a long-term intern in May and it looks very much like they might start as a purely remote employee.
Sometimes we need to display interactive graphs or calculations, but standing up a Jupyter notebook on Binder or Google Collaboratory, standing up an RShiny app, or writing some D3.js code seems like ridiculous overkill. The new Idyll language might be a good solution.
If someone you work with is having trouble getting a handle on Zoom, Jennifer Polk wrote a great 16-page primer on Zoom as a Google Doc. Polk publishes a lot of great information on out-of-academia career advice for grad students on her site and on twitter, so she may be a source of resources for other people in your circle as well.
NIST has a relatively new Federated Cloud Reference Architecture whitepaper out. It doesn’t really have much to do with cloud in particular; as multi-institution data and computation research projects become more common, though, the issues here become something more and more likely for us to come across. This sort of thing is my day job, and the document is quite good and clear on the issues.
I’m always on the lookout for organizational tools - Roam is kind of a… mind-map / wiki hybrid? I don’t know how to describe it. It seems to be the sort of thing that people either love or literally can’t come up with a use for.
Just a reminder that in remote communication, things go a lot more smoothly if you Assume good intent, Clarify any doubts, and Express yourself clearly (ACE).
There’s a good recent post on the importance of useful writing by Paul Graham, and he gives a good four point formula to make sure what you are writing is useful - that it’s important, novel, correct, and strongly written. But in my experience, in research computing our model seems to be the journal article and so I think we hold ourselves to too high a standard of usefulness, rather than too low. That means we don’t share blog posts, etc., often enough, even when we do have useful things to say that could save other people time.