#33 - Link Roundup, 11 Sept 2020
Never skip retros; Supporting informal remote communication; Calling out racism; When team members should ask for help; Huddles for team knowledge exchange
The newsletter is nine months old now. As the list of resources covered here grows, and we see where the gaps are for topics our readers need to be discussed, my plan is over the coming weeks to trim down the number of links covered each week and to focus on a bit of writing on topics that aren’t widely covered. That would mean things like grant writing for research computing, research community building and the like. That will probably also include interviews with research computing leaders.
What do you think; what would you like to see more of, and what do you think the newsletter could do with less of? Hit reply and let me know.
For now, on to the link roundup -
Never Skip Retros - Tim Casasola, The Overlap
In his new newsletter, Casasola argues that one of the most fundamental team meetings you can have are regular restrospectives, because:
They disrupt the habit of anticipating the future,
They are low hanging fruit, and
They put teams on the path to continuously improve.
This isn’t exclusively a software development (or even computing) practice; it’s widespread in project management generally, and I think any time there’s a natural place to take stock and look back, doing some kind of a “what went well, what should we take a look at for next time” meeting is well worth the time for the potential improvements.
GitLab has long been an all-distributed company, and this section of their handbook on running distributed teams is dedicated to setting up channels for informal communications in those environments.
A couple of the suggestions in here are very simple because they involve taking advantage of meetings you likely already have. Encouraging informal conversations in retrospectives, for instance, where a bit of brainstorming and riffing off of things is just part of the meeting; or starting meetings early to give people who want to join early a chance to chat.
Other suggestions include taking advantage of communities outside of work to connect people - sending people to conferences (not super relevant right now) or having team members bring back ideas from relevant events, virtual or otherwise, that they attend.
Other examples are a wide library of social gatherings you may have read about elsewhere - talent shows, coffee chats, co-working calls, trivia nights, pizza calls.
How to Call Out Racial Injustice at Work - James R. Detert and Laura Morgan Roberts, HBR
At the beginning of the summer there were a flurry of articles on addressing racial or other systemic injustices in the workplace. Unfortunately those have died down a little bit. This HBR article discusses how to call out racial injustice at work - it could just as easily be used to address issues of gender inequality, or dealing with any systemic issues.
The steps Detert and Roberts suggest are:
Use allies and speak as a collective.
Channel your emotions (but don’t suppress them!)
Anticipate others’ negative reactions. (“If your request evokes a furrowed brow or a crossing of arms across the chest, start asking questions: `These seem like appropriate next steps to me, but perhaps they feel problematic to you. Can you help me understand what you’re thinking, and why these may not seem right to you?’”)
Frame what you say so that it’s compelling to your counterpart. (“We are evolving together” rather than “I am revolting against you.”)
And finally, and maybe most crucially,
Follow up. A single conversation isn’t going to be enough.
As managers in research computing, most of us are white, and many of us are white men, and so don’t really have to deal with steps one and two when we see issues - we can speak up when we see issues and our voices will be heard and taken seriously without having to have safety in numbers or modulating our emotions. Indeed, we have an obligation to do so. Even so, where applicable it would be best to connect with those most directly affected and make sure we’re advocating for the right things, and lending our voices to theirs.
As a bonus, this framework is a very useful one for raising any difficult topic with higher-ups in an organization.
Dev huddle as a tool to achieve alignment among developers - Mario Fernandez
This is notionally about software development, but these kinds of “huddles” could be useful for knowledge exchange in any team.
Fernandez describes how to organize huddles for software developers. The huddles are somewhere that developers can raise ideas about new tools the team should consider, interesting techniques they read about, or make decisions about how they’ll be handling needed development work. They can be lightweight and self-driven, and serve as a method for building alignment between the developers and sharing useful information and knowledge.
Incident updates, interruptions and the 30 minute window - Dean Wilson
One management skill I wrestle with is the tension between giving my team members, who I trust, the freedom to solve problems as they see best (this is the easy part for me) while staying informed enough to make related decisions and make sure no one is falling down any rabbit holes (this is the tougher part). Wilson’s article is just a nice story about a previous boss who would consistently, gently, but firmly interject “just enough” during an incident to make sure they knew what was going on so they could communicate upstream, and to keep people on track, while letting the team do their thing.
Managing Your Own Career
A 4-Step Process For Avoiding Burnout - Madeleine Evans, The Path Forward
Last roundup there we talked about the emotional resilience report which covered a lot of really good background on burnout. This is a much more tactical article outlining specific steps:
Do a reality check - how often do you find yourself agreeing with questions like “I feel burned out from work”, “I have become more callous towards people lately”, or disagree with statements like “I have accomplished many worthwhile things lately”.
Identify your biggest risks - things that cause burnout at work are high demands, unfairness, lack of control, and things that help fight burnout are enough time to rest/recharge, support, good match with your values and the work you’re doing, and reasonable recognition/reward for your effort. Which of those things are the biggest issues?
Have templates and strong habits for the things which replenish you in the areas above
Plan ahead and review your progress each week on doing concrete things to help avoid burnout.
I wouldn’t say that last week’s article is a prerequisite for this one but I think it’s very helpful for establishing the insidiousness of creeping burnout and gives context to the steps above.