#12 - Link Roundup, 17 Apr 2020
Improving remote communications; Coaching is about who's thinking; Onboarding remotely
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:
Managing Teams
Improve Your Team’s Remote Communications Now - Paige Meekison
We’re all settled into our new largely-remote routines now, but not so settled that bad habits are ingrained yet; this is a good chance to take a look at communications in our teams and make sure things are going well or see what can be tweaked.
In this article, Meekison talks about push vs pull communication. I’ve written before about how we should be encouraging push, especially remotely - this can be quite asynchronous, which works well. People can write up short design documents describing their decisions, they can report on their work via slack or email, etc. It works well for structured communications (like stands), and now can be a good time to revisit expectations about such work.
Pull is more or less necessarily synchronous, but it has its place too. You don’t want to tamp it down too much - you don’t want people toiling away on problems other people could have helped them with. Meekison suggests a “30 minute rule”, something we’ve seen here before - there should be clarity around how long people should struggle with something before asking coworkers.
Who’s Thinking? - Alex Martynov
I’ve written earlier about the benefit of coaching employees — not just giving them answers to problems (which is a hard reflex to suppress given that we’ve gotten to our positions by being knowledgeable and having answers) but coaching them to find the answers themselves. They’ll probably find better answers (they’ve been wrestling with their problems for longer than you have and understand the nuances better), you’re developing their problem-solving skills, and you spend less time doing other people’s jobs.
This article makes the same argument, but casts it in a very simple light, to maybe help make it clearer whether you’re answering questions or coaching them along:
So the distinction is: are you as a manager thinking or is the other person thinking.
A guide to onboarding remote employees - Ashley Priebe Brown, Zapier
I’ve mentioned before that we’ll be onboarding a new trainee entirely remotely for the first time in May; many of us are likely in a similar situation. So this article seemed particularly timely. Brown’s four recommendations, which she expands on in the article, is:
Give everyone a buddy
Asynchronous communications (including short courses for the new employee to come up to speed on key topics! I wonder if that would work for our team..)
Check-in early and often
Ask for feedback
We have a really long 90-day onboarding checklist for new hires that includes some of this - the frequent checkins, the asking for feedback (especially at the end of the 90 days — it’s their job to make suggestions to update the process and to prepare the checklist for the next new hire) so I think we’re ok on the last two items, but we really need to up our game in the first two - getting everyone a buddy (or a slowly rotating list of buddies), and provide more materials that they can read at their own pace.
I think combining that with the earlier push-pull approach (and giving them an expectation that they have ~30 minutes of wrestling with a problem before asking for help) will put us in a good position, if not for this hire than for our next.
Developer First Tech Leadership Conference - June 10-12
Finally, in June there’s a (not free: $250 USD) conference specifically on technical leadership - primarily in the tech industry but many of the issues apply equally to research computing (arguably more so than enterprise computing). You can see if there are sessions that would be of interest; the schedule is available here.
Random
Via the always interesting RSE society slack: increasing the width of integers being printed in an error message caused automation tasks to shut down in two data centres supporting the north american power grid. It turns out NERC publishes these Lessons Learned incident reports and they’re both really interesting and a good model to follow if you don’t have one already.
A really cool setup for single-sign on for SSH, with short-lived SSH certificates. Secure and convenient!
An argument that urban planning, not architecture, is the right model for large scale computational systems.
A short twitter thread with several perspectives on when software becomes “legacy”.
I used to work at a place where I had to print forms out, sign them, and scan them back in and send them to finance/HR/wherever because digital signatures “just weren’t the same.” Now, I could never condone a flagrant flouting of such vital and sacred rules, but just FYI there’s a tool for adding a signature to a PDF and degrading the quality so it looks like it’s been scanned.
A tmux replacement “with a smaller learning curve and more sane defaults.”
ArtStor, a resource of images for educational and scholarly use, has a nice collection of images and artwork suitable for Zoom backgrounds.
Are you tired of matching regex’s with single-purpose command line tools or programming language libraries like a sucker? Don’t you wish you could see if “my-us3r_n4m3” matched “^[a-z0-9-]{3,16}$” by abusing the file system interface, just testing to see if a “file” “/m/y/-/u/s/3/r//n/4/m/3” existed after compiling a regexp to a FAT32 driver like a boss? Well, I’ve got fantastic news.