#35 - Link Roundup, 25 Sept 2020
Pre-mortems; Project-based learning; Meeting everyone on a new team; Handling email calmly
Hi, everyone:
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.
In the meantime, on with the link round up!
Project Management
Use a Pre-Mortem to Identify Project Risks Before They Occur - Mike Cohn
We’ve talked a lot about the importance of psychological safety in teams - making team members comfortable expressing their opinions, including raising issues. Without that, you’re missing important input and potentially running into foreseeable (and foreseen!) problems.
Premortems give explicit encouragement to raise issues. I’ve used these to good effect in some project-kickoff situations - trying to get the team to see obstacles ahead so they can be avoided. With pre-mortems, one step is actually brainstorming ways that things can go wrong. This makes it much easier to chime in with foreseeable issues, and for you to get those insights that they might not be willing to share. And it’s a good way to get people comfortable raising potential problems. Cohn’s article is a good intro to the idea if you haven’t seen it before.
Enhancing software development through project‐based learning and the quality of planning - Marco Antônio, Amaral Féris, Keith Goffin, Ofer Zwikael, and Di Fan, R&D Management
We’ve talked about sharing knowledge across the organization before - whether through talks, pair-work, or other shared experiences (documentation, share, but not just documentation). In project management, “Project Based Learning” (PBL) is a number of techniques that builds into the project planning ways to make sure the things our team members learn from the project becomes shared knowledge within the team and organization.
This article talks about PBL in the context of software development, but the basic idea is more general than that.
This is a paper that shows that PBL works; it’s not just a good career and skills development practice (which it is) and not just a nice-to-have, but it actually measurably improves performance on future projects. The authors looked at 47 software development projects across three multinational organizations and found that the data supported all five hypothesis they tested; project based learning:
is positively associated with the quality of planning in subsequent softwa
re development projects.
in software development projects is stronger when uncertainty levels are high.
is stronger when team collaboration is higher.
is stronger when an organisation adopts a project-based structure (as opposed to matrix and functional structures).
is stronger under high time pressure.
Since research software development is generally under time pressure, is always quite collaborative, is normally organized into teams around projects, and is notoriously uncertain, this is quite relevant to us.
Managing Teams
Meeting everyone on a new team - Anna Shipman
Last time we talked about leaving a team, this time an article about doing one specific thing when joining a new team as a manager or director - speaking with every person in your new organization. Shipman describes having 30 minute meetings with each person in her new 50 person organization over the course of several months. Long time readers will recognize it as looking a bit like the first half of a weekly one-on-one; mostly listening, driven by the team member. Shipman made it clear that this was for informational purposes, and that she wasn’t intending to attach the team member’s name to comments, and structured the discussions around five questions:
I’d love you to tell me a bit about yourself – as much or as little as you feel like sharing
What do you think the most important things we should be doing over the next year?
What will get in the way of us doing that?
What’s going well, i.e. what should we make sure we don’t change?
Is there anything you think I should know about?
Managing Your Own Career
How To Handle Email Calmly - Lukáš Linhart
Email is the bane of all managers and so any article on handling email almost always gets a quick look.
Linhart’s first suggestion is something I follow that I only recently learned not everyone does - religiously keep multiple email accounts, and keep them separate:
Private communications - this is my “friends and family” account. This one you get notifications for.
Work/project emails - I usually have two, my persistent email account and whatever institutional email account I have at the time, which I mainly use for administrative tasks at that institution. Very very few contacts here get notifications
Giveaway email - for things likely to incur spam
He also suggests
Official bureaucracy email - like for banks, etc, which I have sitting uneasily in my friends and family email
I’d add that I also have “email addresses” associated with my RSS reader account that I use to sign up for long-form reading like newsletters - bringing them out of my inbox and instead routing them somewhere that I go when I’m actually looking forward to reading the contents.
Other suggestions:
Archive emails once you don’t have anything more to do with them
Inbox is not a todo list - this one took me forever to learn, but it’s super valuable. Mark them as unread once you’ve read them, and if there’s still something to do with them, add that task to your real todo list!
Process your emails from oldest-first - Again, just incredibly valuable tip
Set expectations - to yourself and to others. For me, emails should have an expectation of a next-business-day turnaround. That response might be “Hey, good question, I don’t know, I’ll get back to you”, (and then that task goes on the todo list). But you should respond by then, and it’s unreasonable to have much shorter (hours or minutes) expectations of responses.
I’d also add: Set your email clients to update every hour or so, not every couple of minutes. There’s no possible email that you need to have read within minutes of it arriving in your inbox. I’ve tried other tricks, but those are what have worked for me. How about you?
Random
Graduated beyond Little-Bobby-Tables style SQL-injection mischief in the “name” field of your various web accounts? Worried your service provider is storing passwords in plaintext? Maybe try choosing antivirus test strings as your password.
Relatedly, someone’s put together a DOS system for linux, so you can run your favourite MS-DOS commands from linux.
A nice style guide for SQL from the folks at kickstarter.
There’s a lot of really nice coding exercise websites out there. One I just found, exercism.io, has 118 exercises for… Tcl?