#39 - 23 Oct 2020

The role of a technical manager; leading those more senior; embracing tension; the power of the paraphrase; risk plans

Oct 23, 2020

Hi all -

The folks at Raw Signal Group’s latest newsletter points out that while a lot of bosses are managing to keep the big things going, a lot of us are dropping balls these days especially on the little stuff. There’s a lot to handle.

When I get busy I tend to lose discipline at exactly those things that keep me focussed and productive - prioritization, todo lists, staying on task, - and that leads to dropped balls. In the last week or so I’ve managed to claw my way back up from that and have got things going pretty smoothly again - but it took a while. So I hope you and your team is doing ok and that you’re spending the time you need on keeping yourself well.

With that, on to the link roundup:

Managing Teams

What is expected of a Engineering Manager? - Rodrigo Flores

Flores, a manager of managers, has a nice article on what he expects of his managers. In priority order:

Support the members of your team and help them grow.
Follow along the deliveries, setting quality standards, making sure the team has the support they need and upper management the feedback they need.
Keep a constant practice of creating, improving or eliminating team or company processes.

Note the order.

A recurring bit of advice from people who have been good managers is to focus on managerial activities that scale, that have high leverage. Yes, delivering what you said you’d deliver is important. If you roll up your sleeves and spend 20 hours doing that piece of the project that only you know how to do to get the next release finished in time, that’s good and all but there’s no leverage there.

If instead you spend say 40 hours working with one of your team members to get it done with them and teach them how to do it, well, you’re a little late on this deliverable, but your team is now stronger because someone else now knows how to do The Thing - every future deliverable will be a bit easier.

A job posting from Lever - Lever.co

So I skim a lot of technical job postings for the newsletter, and I often see things we could all be doing better from the best of these postings. Jobs at Lever aren’t really suitable for the job board, but look at this job listing - it includes detailed 1 month/3 month/6 month/12 month expectations.

Now sure, in our line of work looking 12 months into the future might be a bit much, but how many groups in research computing have even thought the job through in this much detail, much less had the transparency to post it in the job ad? (Answer - a few, but not nearly enough) And how can we possibly make intelligent hiring decisions if we don’t even have clear, written out expectations we need them to meet?

Leading People With Experience - Mark Wood

A common issue - one in retrospect I’m sort of surprised didn’t come up in the recent “Ask Managers Anything” round - is what to do when you’re placed in a position of managing or even being team lead someone with more experience in the job that you have.

This happens all the time, and it especially worries new managers or team leaders who haven’t quite understood the role yet - in a software developer team they might think of the manager as “top programmer” who makes the technical decisions, in which case managing someone who is an even better programmer (say) seems impossible. But that’s not what managing research computing teams is about! It’s a bit closer to the truth for team lead positions but even there that’s not the goal.

Wood has four areas of advice

Fight the impostor - yes, you can be an excellent manager or team lead of someone more technically experienced than you.
Recalibrate your expectations - understand what is and isn’t your job as a manger or team lead, and why you don’t need to be the top programmer to be an effective lead
Talk about the elephant in the room - don’t pretend the age and maybe technical skill differential doesn’t exist, but don’t obsess about it either
Bias towards coaching - perhaps you can’t mentor the skilled hire in a technical area (although is it true that they know everything better than you?) but you can coach them on applying their skills, or in career development, working as part of this team on this project, etc.

4 Tips for Addressing—and Even Embracing—Tension - Holly Bybee & Lauren Yarmuth

Tension between ideas is good and healthy and normal in technical teams, and Bybee & Yarmuth talk about how to address it and harness it constructively.

Observe the dynamic
Give it a name - call it out
Just start making - Don’t try to sort out the tension on some abstract plane, start doing something to make things concrete
Assume good intent - Keep in your and your team member’s minds that it’s not idea X vs idea Y, it is the team members vs the problem that you are trying to solve.

Managing Your Own Career

No More Misunderstandings Paraphrasing - When, Why, and How - Padmini Pyapali

A reminder of a powerful technique for communicating with anyone - your boss, your team, or stakeholders. Double check understanding, constantly, by asking questions about what the other person has said, paraphrased in your own words. Paraphrasing is a great approach but the more fundamental method here is being aware that you may not have understood what was meant by the other person.

Product Management

What Is & How To Create A Risk Management Plan - Emily Luijbregts, Digital Project Manager

Most of us in research probably started off on fairly small and well-scoped projects where risk management wasn’t a significant factor; or the risks were well-understood enough that everyone knew how to deal with them so there wasn’t a need to separately track and manage the risks. If you get involved with larger and longer projects, though, especially ones that bring together a number of skills, it may be useful to explicitly keep track of risks - it might even be a funder mandate.

Luijbregts does a good job of demystifying terms like Risk Registers, RAID logs, and related concepts in this article, and provides templates as well. Like so much of management, dealing with risk is not rocket surgery; it’s just a matter of thinking things through systematically and applying some structure.

The first step is just to create a document where you’ll keep track of things that could risk your projects success - a risk registry. You can do this with your team; “pre-mortems” like we discussed in #35 are a great way to do that. Then prioritize them and come up with ways to mitigate the risk, or how to proceed if the risky event does happen.

For large enough projects there might be some pseudo-quantitative ways to prioritize the risks or different ways you might find helpful to categorize the risks, but the basics are there above. Think things through, write them down where people can see them, revisit periodically; that’s the heart of risk (or project, or people) management.

Project Management

Limiting Work In Progress - Daniel Truemper

A trap new managers fall into fairly frequently (including me) is seeing the big picture, seeing all the things that need to get done, and trying to start them all at once. After all, we know about parallel computing, a wider pipeline can mean higher throughput, right? But human beings don’t work like that. You get more done by diligently limiting the amount of work in progress, which has the advantage that it requires prioritization.

Random

JuliaMono - a monospaced code font with a lot of unicode support for e.g. greek letters for variable names, and with some modest ligature support (but not too much).

You’ve probably heard of the “You are not expected to understand this” comment in v6 UNIX. Well, part of the reason it was hard to understand was that it was wrong.