#3 - Link Roundup, 14 Feb 2020
Working with remote laboratory teams; Building trust - with people and software; Saying "no" to customers
Happy Valentine’s Day!
We’re roughly at the middle of February - thanks for following along with the Manager, PhD newsletter! Next week things will start in earnest..
As when the link roundups were getting started, I’ll be leaning heavily on your feedback to guide me on what’s of interest and when I’m missing the mark; hit reply to any email and let me know what you think.
Managing Teams
Working with Remote Laboratory Teams - Bernard B. Tulsi, Lab Manager
One area where I think teams from the research world have a lot to teach other communities - especially with remote work being increasingly common - is how to have effective teams that are split between multiple sites (and even multiple institutions). Here, speaking with managers from the Multidisciplinary Drifting Observatory for the Study of Arctic Climate expedition (where there is a truly remote site - an Arctic icebreaker!), the Joint Centre for Energy Storage Research, and the Charles River Laboratory the author highlights the advantages of such work - sometimes part of the team just needs to be somewhere else like where the data is being collected, or the advantage of being able to access talent and expertise from around the world. Some of the techniques those managers of dispersed teams highlighted as being important were:
Consistent training for common procedures - make sure the whole team functions in a uniform way
Meeting face-to-face where possible (in my own team we’ve found a yearly all-hands face-to-face, with opportunistic meetings of smaller subgroups through the year, to be absolutely invaluable)
Clarity of measures of what successful team functioning looks like (data collection, users with requests satisfied, papers output, whatever makes sense)
Clarity of roles - a given multisite project should hav a clear lead
Routine videoconferencing (I’ve found weekly ‘peer one-on-ones’ with counterparts at other sites extremely helpful for staying on track and avoiding miscommunications over email/slack)
It’s important to point out that the issues underlying all of these suggestions - strong communication, trust, and shared motivation - are an issue for all teams, and that distributed teams don’t add anything new exactly; but routinely bumping into people in the halls or at the coffee machine can sand down the edges of a lot of issues which instead require conscious and deliberate attention in distributed groups.
Building trust — with people and software - Tal Joffe
Tal uses technical analogies to management-of-humans concepts. I’m not sure that’s necessarily a good idea! but the basic concepts are important enough that it’s worth trying a lot of different approaches to reach different audiences. Here, he addresses one of the key goals of one-on-ones; building trust with direct reports. The analogy is between say testing your alignment and agreement on a number of topics in one-on-ones with running tests on code bases; in both cases, the trust people have grows as the inputs are frequent and consistent, which is easier if they are small and lightweight. It is much better to have weekly 30min one-on-ones with people on your team than to have quarterly 4-hour meetings - in terms of building trust and finding out if something is wrong quickly.
Maybe a more successful use of that sort of analogy is an earlier article of his on Microfeedbacks - breaking the monolith. Here the comparison is between monolithic code and modular or micro services code on the technical side, and on the people side, yearly or quarterly performance evaluations versus lots of small frequent feedback. Again, lots of small inputs is much more valuable - and easier! And less stressful! - than waiting three or twelve months and having a Big Deal conversation.
Related to the micro feedbacks post - this isn’t new but it was recently pointed out to me - a very short but effective set of google slides on the importance of small frequent feedback, Some Ad-Hoc thoughts about PIPs by Roy Rapoport who writes well on these topics. I wish there was a similar example for positive feedback, which is at least as and arguably more important than negative. A more serious responsibility of a team leader than catching mistakes on any particular task is helping your team members excel and grow. One important way of doing that is, when someone does something well, giving immediate positive feedback with enough detail that they can do it well again. People learn do get really good at things through guided practice; it’s your job do provide some of that guiding through positive feedback.
Product Management
6 Tips on How to Say No To Customers - Sharon Moorhouse, Intercom
We work closely with researchers, and that can make it hard to say no to a feature request. This article walks through the process, which is normally pretty routine but can run the risk of leaving hurt feelings. The tips most relevant to us are:
Explain why
Involve the (researcher) in finding another solution
Focus on the job to be done, not the `no’
Understand both sides
It’s ok to lose a user
Of course, to say no (or even worse, yes!) to a change request from a user can really get you in trouble if you don’t have a clear picture of where the product is going, what its purpose is, and what is in and out of scope. Mathais Meyer writes about drafting such a strategy when coming in to a team for the first time; there are also approaches for more rigorously deciding what decisions to take with data and experiments. Whether it comes from those approaches or from an original product vision, saying yes and no to suggestions is a lot easier when you know where you’re going.
Random
Want to see how the NSA teaches Python programming? It’s disappointingly mundane.
I remember being surprised by what one could do at the command line with cut and join; it turns out xsv will let you do simple SQL operations like join on CSV files as John Cook reminds us.
Today I learned that Intel’s Clear Linux apparently performs really well even on underpowered AMD hardware, not that I’ve ever been much of a Linux on the laptop type.