#93 - 27 Nov 2021

Delegation superpowers; Manager goals; Managing up; ICs and Academics learn to product management

Nov 27, 2021

Managing Teams

Delegation is a superpower - Caitlin Hudon, Lead Dev

It’s true! But, superpowers sometimes take some practicing to use effectively.

I personally am pretty good at the mechanics of delegating when I think to do it, but too often find myself taking on a responsibility so as not to bother anyone else with it, or because only I can do it (well, yes, if no one else gets a chance to learn how to, I guess I am the only one who can do it).

The ending year is a good time to reflect on things you’ve spent time on to see if they could usefully be given to someone else as a welcome growth opportunity. Hudon encourages us to see a task being delegatable by default:

Is this task something that only I am uniquely able to do [because of the role power of my job]? - Ok, fine, I can’t delegate it
Do I need to perform this task because of a limiting constraint (for example, you’re running out of time or only you understand the context)? - Do it this time, but start laying the groundwork to delegate it next time
Should I be the person responsible for this task, or is there someone better suited? - Delgate it

Managing Your Own Career

Invisible Output: Measuring the Behind-the-Scenes Work of a People Manager - Samantha Rae Ayoub, Fellow

One of the problems of being a manager is that the work we do is pretty invisible. Our teams’ accomplishments are pretty clear, but the work we do to support that can be hard to point out. That means it’s hard to point out to our bosses - but even more importantly, to ourselves - the good work we’re doing, and where we need some support.

Ayoub tells us it doesn’t need to be that way; we can set clear goals, and even some quantifiable ones, for ourselves. We managers just need to:

set measurable goals for ourselves, not just goals for our teams
measure outcomes and impacts, not just count inputs or outputs
be personally measured on overall effectiveness, not just team performance

On goal setting, Ayoub urges us to set goals for ourselves, not just for the output of our team, that focus on overall outcome or impact - whether that’s internal (like staff engagement numbers) or external (more collaborations or partnerships) - not just input activities. That will help focus our activities on what matters, not just activities for their own sake.

Ayoub also tells us to make sure we’re including team member metrics - things like retention and rate of promotion - but those are less relevant in our world, where job tenure is generally quite long.

Managing Up - Lessons From Scaling Teams at Credit Karma and Lyft - Matt Greenberg, Valerie Wagoner, Dor Levi, Anne Lewandowski

Managing upwards isn’t that different from managing our own team members; and it’s very similar to managing relationships with peers and external stakeholders like collaborators, situations where we also lack the ability to be directive.

Greenberg, Wagoner, Levi, and Lewandowski suggest focussing on three areas:

Aligning your and their goals — making sure you understand their goals so can find areas that align;
Developing a strong relationship, and having an empathetic approach to working together — ask lots of questions and don’t make assumptions; and
Presenting your problems in a way that makes helping easy for them — concisely present the context need, frame the request in a way where it’s clear what they need to do, ask for something immediately doable in the short term, or ask for help getting the problem so well defined that this would be possible.

They also talk about three common failure modes that can cause problems when working with your boss, in the short and long term

When you don’t realize you’re missing context: so keep asking questions and be aware of your assumptions
When your timing is off (possibly because of the above lack of context, or just because of mis-prioritization): so keep staying aligned on goals
When your delivery of a solution or problem is off compared to what they want to hear, perhaps souring your manager on a perfectly good idea: so tailor your communications to the audience (especially around use of data, level of detail, and communications style)

Product Management

An IC’s guide to roadmap planning - David Noël-Romas, Increment

A good introduction to product roadmapping, aimed at a software developer IC tying to figure out how to contribute to product planning. It applies just as well to research computing, whether systems, software, or data products:

Clarify your [product’s] opinions - I like the framing here of “opinions as hypothesis”, and the distinction between the opinions of the product and those of the individual team members. I also like the insistence on having opinions, rather than trying to be all things to every possible user.
Understand the process - being clear on what the process is for your team, and up to date with what’s going on in different parts of the processes (backlog, prioritization..)
Identify stakeholders - customers (users), leadership, team members, and possibly others
Talking to customers (users)
Making an ordered list of priorities
Advocating for underdog ideas

42 things I learned from building a production database - Mahesh Balakrishnan

Relatedly - I really do think R&D at Big Tech, or the work of startups, is pretty close to research computing. It’s certainly a lot closer than University IT! They’re working on things that may or may not work, firming up their understanding of the problem at the same time that they’re developing solutions, and reading (and writing) papers as they go.

Here an academic, Balakrishnan, describes what he learned building a production database (Facebook’s equivalent of Chubby - a central state store which is a key piece of infrastructure that other foundational services depend on). They are classic product development lessons, broken down into categories of customers, project management, design, code review, strategy, observability, and research.

Random

A free undergraduate cryptography textbook - the Joy of Cryptography.

Relatedly - latexrun, a latex runner for use within build tools/workflows that handles multiple running, cleanup, etc.

Most of us in this game have had to absorb a lot of background information about open source licenses without realizing it, and the differences between contracts, IP, etc… but if you have a new team member who’s less familiar, this is an unusually good and comprehensive primer, written by actual technologist lawyers.

Nice from-scratch introduction of transformers, a recent (2017) deep learning architecture used for e.g. translation.