Hi, everyone!
I hope you’re having a good weekend, and that the past week was good for you and your team.
I’m working (with some help) on tidying up and improving the material from the hiring and performance management series from the newsletter at the start of the year; I’d like to turn those into expanded and more coherent writeups that can help other research computing team leaders (or those interested in becoming one). Other topics that came up when last I asked for suggestions were:
Strategy
Product management
Peer mentorship
Levelling & promotion in research computing
Let me know if there are others you’d like to see, or questions or input you have - just hit reply, or email me at jonathan@managerphd.com.
And now, the roundup:
Managing Individuals
Why “start bringing solutions, not just problems” doesn’t work - Lara Hogan, Wherewithall
We’ve talked often about why it’s best for you and your team members for you to avoid trying to solve problems directly for them, and instead help coach them to find a solution yourself. But how do you do that well, in a way that makes them comfortable coming to you raising issues?
Hogan has some suggestions for questions to ask:
What could we try?
If you could wave a magic wand, what one thing would you change?
What, deep-down, do you truly want?
What do you need?
What’s in the way?
What’s holding you back?
and suggests giving feedback on approaches if that doesn’t work. She also cautions against trying to help the team member come to a solution if they’re just venting about something; venting is natural, we all do it sometimes, it’s even good in a way if they’re comfortable venting with you, so you want to allow it but without necessarily letting it spiral out of control or happen regularly.
Hogan also includes some approaches for if your manager tells you something similar, including looking for other people to raise the issue with.
Managing Teams
Good Meetings - Sara Drasner
The purpose of the meeting is clear
There’s an agenda (we’ll dive in to the complexity of this in a moment)
There are the right people in the room. Not too many where communication is overly complicated, not too few where the people you need to move forward aren’t there.
There’s some order. People aren’t dropping in and out, talking over each other, or being generally inconsiderate
There’s a clear decision, outcome, and next steps at the end
Some points Drasner makes that I think are particularly useful in our context include the fact that purpose isn’t the agenda, the agenda is a tool that serves the purpose; that different kinds of meetings need to be run different ways; that too many people in the meeting is a common failure mode; and that respectful conflicts are good, and that people not saying things that need to be said are bad.
She also suggests meetings can be started and finished with sentences that sum up:
The shared purpose
What you’re doing about getting to that outcome
Who is owning what
How
When, what are the timelines
Three Core Ideas to Make Remote Work, Work - Cate Huston
Huston has been working remote for over five years, and for those of us getting ready to continue working remote for real and without a pandemic driving it, suggests three key approaches:
Embrace async.
Enable autonomy.
Build connection.
Crucially, these are all team-enhancers for in person teams, too:
Even for team members all going to the same office, meetings can be hard to schedule, unnecessary meetings are bad, and having written documents outlining how decisions came to be are good and helpful
Autonomous teams where individuals have significant control can respond faster and more robustly, especially where there’s documentation to support that
Office culture helps build connection but even there being intentional about how its done makes the connections stronger
Random
In praise of the underappreciated architecture which greatly influenced both DOS/Windows and UNIX systems - the Vax.