#40 - 30 Oct 2020
Getting big things done; architectural decision records; writing unwritten rules; hearing impairment and zoom; ask for feedback
Most of us have made so many half-plans about the future after COVID (“In a couple months, when this blows over..”, “By August, we should be able to…”) we’re a little wary of putting time into deciding on next steps.
But planning for the future is part of the job. Earlier this week I wrote up my thoughts on what academic research computing specifically is likely to look like after the pandemic is fully controlled, but it’s worth thinking about more generally.
There’s a few things I think we can take as givens that are going to shape the near-term future. First, a lot of communities are now pretty comfortable with remote provision of technical expertise. Organizationally, two quite different things have happened: institutions are very over-spent, and the best teams have learned to communicate and operate even better than they were before, while others have just sort of muddled through.
I think those things are going to have some pretty clear consequences in 2021 and beyond. Budgets will stay flat or drop. We’re almost certainly never going back to 100% work-from-office, which means ever more virtual support. That plus likely budget cuts makes consolidation of teams extremely likely.
I’ve talked a lot and shared a lot of resources in this newsletter about upping our game with team members - that’s vital, because without a capable engaged team nothing else matters. But there’s been a lot less about communicating our value to our bosses or other stakeholders, partly because there’s precious few resources out there on those topics to share.
Given the lack of other resources, I’m going to spend some time putting together some material on what groups can do to better make our value clear to those above us and to be more indispensable and less interchangeable. If you do have some resources that have been valuable to you on those topics, share them with the community! Reply to this newsletter or just email me at firstname.lastname@example.org and I’ll make sure our fellow readers get them.
And with that, on to this week’s roundup:
One Rubric Changed Box’s Engineering Performance — Here’s How - First Round Review
A nice description of how the ex-leader of Google Docs now running the technical organization at Box set up performance management. It was guided by five principles:
Have clear standards for performance.
Have an opinion on the role of managers early.
Have a process for evaluation and reward. - In our case it doesn’t have to necessarily be financial or job title changes
Don’t be soft on low performance.
Be consistent - have process - without losing speed.
The first is the most important; without clear expectations about what performance looks like - and that probably means goals and pretty high-level standards about things like how self-directed (say) they are. Those goals are work to set up and the high-level standards are hard to evaluate, but that’s really the only kind of tools at our disposal; we can’t monitor performance on how many widgets per month they produce.
From that they describe creating rubrics for various roles which can be used to evaluate performance, can be used in job descriptions or ads for clarity, and which can be use to guide promotions (probably less something we can take less advantage of in research computing where teams are small and structures are pretty flat).
But without that clarity of expectations around performance there’s not much else you can do.
Brooker, who leads development on AWS’s Lambda product, writes about his approach to getting big things done and done well; his approach is outlined below:
Is it the right solution?
Is it the right problem?
Engage with the doubters, but don’t let them get you down
Meet the stakeholders where they are
Be willing to adapt
This maps pretty straightforwardly to research computing work too.
Key to Brooker’s approach, I think, is the centrality of writing a document in the early stages, both for communicating the problem and proposed solution to others (and having something concrete for them to give feedback on), but also to clarify his own thoughts and realize where gaps or problems lie.
This lines up even with smaller decisions; we’ve talked about architecture decision records before as a way both to flesh out an idea and communicate it, both in the present and to the future (“here’s why we did it this way - the tradeoffs and constraints we faced”) so that future knows the why’s and so therefore when it would be worth revisiting.
Write Down Your Team’s Unwritten Rules - Liz Fosslien, Mollie West Duffy
It’s very likely that my team is going to grow significantly over the coming months. That’s a huge opportunity but also a challenge - we have a pretty good team culture now and we don’t want to make any unintentional changes to that.
In addition, we’ve had a few discussions recently where it’s been clear that expectations I thought were clear - about learning, contributing to others’ work, working hours - were not at all clear to some team members, because it wasn’t explicitly stated anywhere.
As a result of both of these things, we’ve started writing up a “culture deck” to make explicit what our expectations are, and by extension what we would look for in new team members. So this article by Fosslien and Duffy comes at a good time to check that effort against. The basic idea of the article is summed up nicely in the title; by making team norms and expectations explicit (and having the team members contribute to the document!) you not only communicate them widely but make it much easier to maintain those expectations and norms.
Of course, then you have to make sure both you and the team behave according to those expectations, and provide transparency or feedback when (inevitably) you or a team member slip.
Another reminder that our sudden working from home doesn’t affect all team members in the same way. Keast, who is profoundly deaf, relies on lip reading for verbal communication in person; but that works much more poorly over videoconference where there’s a lot less information.
This article is a good reminder that while many people require various accommodations, and many of those accommodations “work”, they are still a lot harder than not needing the accommodation. In Keast’s case, he’s been relying on live auto captioning, but those tools are still pretty poor. The whole team, to their credit, chipped in and tried tools that might work - Zoom + Otter, which had decent accuracy and kept history but lagged well behind the conversation; and Google Meet, which was after but didn’t keep history.
The whole team tried using the call with sound off and only captioning a few times, and quickly got a very hands-on understanding of the challenges Keast faced with these tools. And team members have changed their behaviour, watching captions of their own speech to make sure it’s getting it “right”, defaulting to Google Meet, and generally being more understanding (and using written communication more).
Managing Your Own Career
Own Your Feedback (Part 1): Receive Better Feedback by Asking - Padmini Pyapali
We’ve talked about giving feedback to our team members, but we need feedback, too - from our managers, or researcher’s we’re supporting, or other stakeholders. Pyapali makes some specific recommendations for getting good feedback from others. They all involve asking, and how to ask:
Be Timely and Specific - you’ll get better feedback if you’re asking soon after the thing you’re asking about, and if you ask specific questions
Provide a Reason - people will be more willing to answer if you provide a reason - e.g. you’re working on some skill or behaviour
Prepare the Feedback Giver - don’t surprise them with the ask, by either giving them a heads up or…
Persist - if you keep asking for feedback - and receiving it well - people will become increasingly willing to provide good feedback.