#13 - Link Roundup, 24 Apr 2020
Remote 1:1 tuneup; Maker vs Multiplier; Checklist for difficult conversations; Prioritizing your own work; Driving change; Long-term planning
In our own careers and throughout our organizations the next stage of pandemic response its and consequences is going to require a new focus on prioritization, identifying where we can have the most impact, and what gaps need filling to make that impact as effectively and efficiently as possible. That’s the focus of this week’s roundup.
To make this more explicit, I’ve added a new section to the link round up on managing our own careers, as well as helping develop the careers of our teammates. The Jobs section has always been partly aimed at that, but there’s a lot more to developing our own careers than just keeping an eye on job ads; in this section I’ll include information about upskilling as a professional manager and making sure that our contributions gain the recognition they deserve.
On to the roundup!
In the spirit of “the end of the beginning”, I think we have to prepare for the fact that many of us will be working from home - or at least not from our regular office - for a very long time.
Lockdowns will start to relax; in my home province we now have a target amount of spread in the community at which point restrictions will be loosen (with a very close eye kept on those numbers in case they have to be tightened again). But people who can work away from other people are going to be strongly encouraged to do so for a very long time. We may be able to see our team members again in person, which will be good! But spending every day working shoulder-to-shoulder with them remains a long ways off.
The conversations Hicken describes about having with their team members are very good to have. These sorts of big picture, “Let’s look over the past [X time]” ,”Let’s talk about where the team is going over the next [X time] and what we think your contribution should be during that time” are badly needed, and should not be happening only one per year. Our team has them quarterly, which might still be a little too seldom (I say that because it’s still A Big Deal to plan for them and I think it’s stressful for the team members, which I don’t like). Monthly might well be good.
But these should absolutely not take the place of frequent, shorter, less structured one-on-ones with your team members. Going an entire month without your team member having a scheduled time where they can share any concerns or anything they’re especially pleased about, and a slot where you can give feedback and coaching, is not a good idea.
I don’t have a lot to add to these - we’re all feeling this right now (whether you use Zoom or something else) and you probably don’t even need to read the articles to list off a number of reasons. Video conferences give you energy-drain of having to be “on” for a meeting without giving you (or at least you extroverts) the energy gain of being around people.
It’s vitally necessary to communicate with your team and outside of your team during this time, but it doesn’t all have to be videoconferences (and it shouldn’t). Now that you’re settled in, it’s a good time to up your teams asynchronous communications game - sending longer design documents around for comments, talking through code choices through issue tracker discussions, etc. Save the synchronous, video chats — which can be very useful! — for where they are necessary.
Maker vs Multiplier - Pat Kua
There’s an old joke about becoming a 10x developer by spending your time helping ten other developers become twice as effective. I think this article is a nice way to distinguish between the contributions of individual contributors and those doing “glue work” like us managers (not that you have to be a manager to be doing multiplier-type work).
There’s one thing I’d add as a preamble to this article. If things have advanced to the point with one of our teammates where we’re going to have the sort of conversation we need to brace ourselves for, it is almost always our fault, at least in part. We didn’t have to let things slide this long. Giving consistent feedback about small things, even if uncomfortable, will allow you to avoid say 80% of Big Talk situations.
But that still leaves 20%. And while these are hard times for everyone to some extent, that doesn’t absolve us from having difficult conversations if we need to. This article presents a good checklist of things to think about before those conversations. In the preparation, Ringer makes two points to consider I think are under-appreciated, especially by technical folks:
What assumptions are you making about this person’s intentions?
What “buttons” of yours are being pushed?
We are not disembodied creatures of pure reason, and we lack any special powers to peer into the souls of our team members to perceive their intentions. When preparing for these conversations, we mustn’t work ourselves up by imagining “attitudes” that may or may not exist, nor be oblivious to our own reactions. Focus on behaviours and outcomes wherever possible, and leave unknowable internal state out of it.
The four steps for actually having the conversation - inquiry, acknowledgement, advocacy, and problem solving - are solid. The article is worth a read, as are the references.
Managing Our Own Careers
How to Prioritize Your Work When Your Manger Doesn’t - Amy Jen Su, Harvard Business Review
If you’re reading this newsletter, you probably care about managing your team well — but that’s pretty rare in research, which means there’s a better than even chance that you don’t get the kind of communication, feedback, and career development from your manager that you try to provide for your team.
This is a pretty simple article about prioritizing absent that sort of guidance; about trying to find where you and your team has the greatest impact (“provides the most value”) and where you are passionate about the outcomes. Aiming for the impact is a no-brainer; but doing that sustainably, in the absence of external direction, is going to require internal motivation too.
Many of us have highly technical training and so we’re always looking for things to optimize; when we move into working with lots of people we keep doing that, and initially we often find it mystifying that our suggestions for doing something in a clearly better way get turned down!
But change involving people is a lot of work, so change takes a lot of buy in. And people systems are and high-dimensional, so local optimizations may violate constraints we’re unaware of. This article talks a bit about that, and the importance of talking to people to make sure you’re solving the right problem (as above) as well as making sure your’e solving it right.
I’m still sheepish about the fact that when I first learned about “prewiring” proposed solutions or changes it was a revelation. Apparently the idea that I should, you know, talk to people who would be affected before proposing a “better” approach to something was an eye-opener to myself not that long ago.
Long-Term Planning - Tom Sommer
“For teams that act as enablers — such as my infrastructure team — this can be a bit tricky though. Although we have customers… our impact is really hard to quantify directly.”
Sound familiar? Unlike salespeople (“your numbers are down 10% this quarter!”) the teams we’re likely on have a hard time quantifying goals — and the numbers that can be easily measured (number of time your software was run; utilization of the cluster) are meaningless measures of inputs to research, not outcomes.
But that doesn’t mean there can’t be goals we hold ourselves to and we can’t make meaningful plans. It does mean we need to put more thought into it. This short article suggests three steps:
Review current focus areas
Draft a released statement
Identify high leverage work
The “Draft a statement from the future” approach, the middle point, is surprisingly effective. Putting aside questions of how you’d get there — what do you want the future to look like, and then back out from there the steps you need — can work really well. Again, you have to prioritize what actually matters and find the most effective way to get there. There’s no short cuts but it’s what’s necessary.
How Unix Pipes are implemented. I’m always really amazed to go through old Unix system programming books and see how clear and compelling the designs were of fundamental features. (I have a friend who teaches intermediate shell concepts that way.)
SELECT wat FROM sql - SQL is a powerful and mature lanaguge which almost by definition means that its behaviour in some cases is kind of.. well.. WTF.
But bash is like that too. Redirecting output to, e.g. $((i++)).txt works once, but not twice.
A great set of open data on Government of Canada IT projects - 70% of projects under $10M were successful, compared to 35% of those over $100M, consistent with results seen elsewhere. Big-Bang IT projects are almost never a good idea.
A GPU-accelerated terminal emulator, in case you want your monospace fonts rendered faster and don’t care about battery life.
How the pandemic has affected Stack Overflow searches.
Prepare yourself for requests to support R 4.0.0, with reference counting, matrices now supporting array operations, and, for frickin’ finally, stringsAsFactors = FALSE by default.
Deploying hobby projects cheaply with Google Cloud Run.