#28 - Link Roundup, 7 Aug 2020
Mentoring junior staff responses; Starting difficult discussions; Making space for others; Turning around disengaged team members; Managing your managers perception of progress
Hi!
Last week’s “Ask Managers Anything” question was “How are you making sure that junior staff get access to mentoring when everyone is working from home?” I got several replies back; paraphrasing them for anonymity:
I don’t have any junior staff as direct reports, so it hasn’t been an issue
We’ve been leaning heavily on white boarding tools like Mural or Miro to have conversations about how things work, and asking our junior staff to either present back or write up the discussions as documentation to make sure they’re learning
Our team has experimented with giving new junior staff small but increasing stretch assignments with lots of contact-hours for asking questions and getting feedback
We’re struggling with this too, look forward to hearing what others say!
We’ve standardized on VSCode so we use Liveshare, along with Teams for chat/teleconference, to run pair programming sessions; it’s not perfect but it’s worked for us.
Thanks for your answers! I may try a couple of these myself
This week’s top question is, “How do you start difficult conversations with team members?” My own answer (which echos an article in the roundup list this week) is to try to reduce the need for them by having less-difficult (but still difficult) small conversations early. And when they are necessary, I try to think it through and then start the conversation, with a pretty firm view about what a desired big-picture outcome looks like but with an open and questioning mind about what the underlying issue is and how to address it. I … don’t always succeed, but I’ve gotten noticeably better/less bad at both the early and later conversations over time.
How about you - do you have any advice for our question asker or the community? How do you start difficult conversations with team members? Do you have a go-to phrase that helps or a process? Let me know (just respond to this email) and whether or not I can credit you by name and I’ll include it in the roundup. And feel free to submit more questions.
Managing Teams
Handling difficult conversations - Rachel Hands, Managing Equitable, Effective, Teams
As above, difficult conversations don’t get easy, but they do get easier. And once you’re a manager, as Hands says,
It’s imperative that you, as a manager, initiate tough conversations when the need arises.
There’s no way through but through, though, so Hands recommends identifying what’s making you uncomfortable about having the conversation so as to defuse it a little bit, and then to focus on the (very specific, observable) issue at hand and that you’d like to start addressing. Then during the conversation, listen a lot, be open to solutions (or even restatements of the problems), and don’t get sidetracked.
None of that makes it easy, but focussing on future outcomes and being aware of what’s making you uncomfortable helps.
Hands points to similarities with the feedback model she advocates, and I’ll just add as above that giving frequent, specific, early feedback can greatly reduce the number of Big Conversations like this that you need to have. Many short slightly difficult conversations » fewer very difficult conversations.
Create space for others - Will Larson
One of the hardest things about a transition to leadership, either on the people-manager or technical-leadership track, is stepping further and further back from directly making contribution and spending more time making room for others, nurturing their contributions, and gathering their input. In this article, Larson describes how that works at the Staff+ Engineer level at large tech companies.
How to Turn around a Disengaged or Underperforming Employee - Lighthouse
Tactical Challenges In Hiring Junior Engineers - Cindy Sridharan
These two articles benefit from being read together. The topics are quite different but they both speak to the need for managers to invest time in new and/or struggling team members.
In research computing we tend to both not reassign or remove employees who aren’t good matches and not invest enough in employees who are struggling. It’s a bad combination, it hurts team morale, it hurts the struggling team members, and it hurts the research we’re trying to support.
The first article talks about what’s necessary in coaching an underperforming team member. It’s a lot of work, for both you and the team member. I think the blog post lays it out well, and if the topic interests you you should read it. The only things I’d add are:
You can often - not always, but often - avoid going through this process by providing small frequent feedback earlier, rather than waiting for things to become A Big Problem.
This process will not always be successful. I really like Roy Rapoport’s article on five conditions that have to be met for improvement to occur.
The second article is very upfront about what’s involved in hiring junior team members:
I strongly believe that if a team isn’t willing to invest at least 1–2 years, they shouldn’t be hiring junior engineers.
This is especially true in research computing, Our junior staff tends to be straight out of undergrad or coming from a couple of years in industry; our senior staff tends to be out of Ph.D. programs/postdocs. Not only is there a gap in experience, but there’s huge cultural gap. The process and mindset of doing research will be completely new to them. It’s good that they’re bringing in new mindsets and approaches! We don’t want to quash that. But the cultural difference will have to be bridged to make sure communication works and and expectations are clear.
Managing Your Own Career
How to make your data science team faster (and speed up progress) - Gregg Detre, Making Data Mistakes
I’ve got this under manage your own career because the article is really about having tough conversations with your own manager about your team’s (perceived) progress. When talking with your manager, like any other stakeholder, the reported symptom (your team isn’t going fast enough) may be pretty different from the actual underlying problem, so the key is to not get defensive and to not jump to conclusions about what you interpret the problem to be but to dig in and get more information about what the specific cause for concern is so you can address it better. Feedback is data, but data is generally noisy and incomplete; sometimes you need to collect more data before you know what the right next step is.
Random
Scientists rename human genes to stop Microsoft Excel from misreading them as dates - this was such a pervasive and recurring problem that scientific nomenclature was changed to avoid the problem.
Using travis, and travis secrets and encryption to deploy via ssh.
A fork of make with tracing and a debugger.
Migration stories are always interesting. Here’s the story of how LinkedIn rewrote its messaging infrastructure while keeping it up and running the whole time.
A nice story on the 60-year history of algorithms for multiplying very large numbers, and the recent proof of an n log n algorithm (but not a lower bound!) involving FFTs.
Termpdf.py, a PDF file viewer for the terminal.
A couple neat open source tools from Dropbox - a non-dumb password strength estimator and Broccoli, a blocked compression algorithm optimized for file syncing.
Shournal - ever used script to record a terminal session, or history to reconstruct what you did? This records not only shell history across sessions, but also (using fa-notify) what files were touched (even if they don’t appear explicitly in the command line) for improving reproducibility of processes.
Herbie, a really neat web service for rewriting floating-point expressions to improve accuracy.
Parabol, with free plans for up to two teams, looks like a useful tool for retrospectives.