#104 - 12 Mar 2022
AMAs return; Everyone's a great manager until they start; Management as skincare; The 30min rule; Run your day; Specializing your team
Hi, and welcome new readers! Some resources that might be useful:
The Rands Leadership Slack (a community of 20,000 managers and leaders in or around tech)
My “Help, I’m a Research Software Manager!” talk & slides from 2020 which covers in 10 minutes the basic approach I take in the newsletter and elsewhere.
Speaking of resources and online communities: thing that we did for a while in the first year of the newsletter was a recurring “AMA (Ask Managers Anything)” section. Readers would send in questions (anonymously, by default), I’d take a whack at answering in an issue and then we’d solicit answers from readers which we’d include in the next issue (also anonymous by default).
I think enough time has passed and we’ve got a critical mass of new readers, so let’s try that again. If you have questions you’d like to hear feedback on, give our community a shout! Hit reply (emails only go to me) or email jonathan@managerphd.com, and I’ll post your questions in the next issue. And of course if you have anything else you want to share with the community, or suggestions or feedback on the newsletter, please also send them along.
In the last issue, we were talking about the benefits of having worked in or around research in our line of work, and I talked about the basic mindset of research: “So while ‘growth mindset’ and ‘comfort with uncertainty’ seem like empty phrases to us, they are high-achieving traits in other parts of the world.”
A reader chimed in share their experience having seen the same thing:
Yes. It took me many, many years to realise that having a PhD marks me out as highly skilled in the majority of organisations. We think it is normal to be surrounded by high achievers – my own background is from CERN. We do not realise that many organisations have people who do quite mundane work.
There’s other examples of the strengths we bring from spending part of our career in and around research, too. Here’s an article from earlier in the year saying that having multiple areas of tech expertise is a “superpower”. It’s pretty common in our profession to have a research area of expertise and a tech area of expertise, and I think that’s a superpower too, for the same reasons given in that article. It improves communication, strengthens links between groups, helps us understand how the work connects to research, and helps find better solutions.
With that, on to this week’s roundup!
Managing Teams
Everyone’s a great manager until they start managing - Jonathan and Melissa Nightingale, Raw Signal Group
Four mistakes I made as a new manager - AbdulFattah Popoolah, LeadDev
What you give up when moving into engineering management - Karl Hughes, Stack Overflow Blog
When we see people do a different job than we do — especially when they do it very well or very poorly — it’s easy to think “that doesn’t look so hard”. Plumbing, graphic design, customer-facing roles; we watch for a while and figure “I could do that”. And you know, we probably could, eventually. Because it is way harder than it looks, for almost any value of “it”. Competence is hard-won. The people performing those roles are avoiding (or ignoring) a lot of potential problems we’re not aware of, with background knowledge we don’t have, deftly performing practiced tasks that we’d botch the first dozen times through.
It almost always takes us much longer than we imagine to claw our way up to a basic level of competence in a new field. In areas where the feedback loop is slow, it can take still longer. Absent prompt signals to the contrary, you can quickly get into Dunning-Kruger territory where you fool yourself into believing you’re doing much better than you are.
And, well, welcome to leadership and management. When I and others say “management isn’t a promotion, it’s a career change”, this is what we mean. It’s a whole ‘nuther job, where your experiences from your previous job help but also hinder you.
The Nightingales have a nice article that’s hard to summarize, but I like their section headers as an overview - “In theory it’s easy.” “In practice it’s hard.” And, crucially, “The management is in the doing”. Good management - assuming you’re in a reasonable situation where success is possible - is a learnable set of skills and behaviours, that have to be done and redone until they’re practiced. And then have to continue being done. You will keep developing mastery of those skills for as long as you keep working at it.
(In our line of work, Management isn’t the only “looks easy; after all, I’ve been on the other side of it and know what not to do” profession we get thrust into. Teaching and training is another set of extremely important activities that people spend their entire life studying and learning. And we get tossed into it with zero education or support.)
Popoolah talks about the big categories of mistakes he made as a new manager (which overlap quite a bit with the “Help, I’m a Manager” talk above. Fundamentally, he didn’t know what the job was, so he had trouble doing it. He didn’t have a clear vision for the team; he had trouble giving constructive feedback; the first departure on his team threw him for a loop; and he kept trying to be a team lead instead of a manager. It’s a good short summary of the problems a lot of new managers face.
Hughes talks more concretely about the things that are given up on the management path: focus time; short feedback cycles; conflict avoidance; making technical decisions; and staying up to date technically. It doesn’t have to be given up forever — I’m back on my third tour of duty as an individual contributor! — but those are just not part of the job of a manager.
Management Development As Skincare Regimen (Twitter Thread) - Angela Riggs
So how should you start learning the new skills you need to be a manager? Riggs has one way to think about it.
I’m always on the lookout for new analogies for management, leadership, and strategy. For management I personally like sports metaphors, but they’re so overused that every ounce of insight that can be extracted from those comparisons have long been exploited. I’ve always found war and combat metaphors distasteful and aggrandizing, and now especially. Our jobs are tough, but no one’s getting killed.
In #42 there was a pretty helpful comparison to TV show writing, which is another example of collaboratively creating something new. Here Riggs uses the metaphor of adopting a skincare routine. It’s not something you do all at once; it’s something you start with an eye towards the problems you’re trying to solve. You add and change products as needed. You test each change to see if it advances your goals, even though it can take some time to see the result. You have to unlearn old things (exfoliation!). And of course you get input from others trying to solve similar problems.
The Thirty Minute Rule - Daniel Roy Greenfield
We’ve talked a lot about having explicit expectations in your team, especially around communications. It’s been on my mind having changed teams very recently.
Your team does have expectations about how people work together. (You’ll find this out very quickly if a new team member starts behaving very differently from team norms!) The only question: do you have those expectations written down somewhere? Having expectations explicit makes it easier for new team members to spin up, and for experienced members to mentor juniors and trainees.
If you don’t have such expectations explicit, one good target to start with is: how long should someone wrestle with something on their own before bringing other team members (or stakeholders) in?
You do have expectations about this. If someone was spinning their wheels for two weeks making no progress because they were stuck on something someone else could have told them, you’d be annoyed. You’d also be annoyed if someone constantly asked on the #general channel on slack the second something came up they didn’t know.
Greenfield suggests a 30 minute rule; don’t let people get stuck because of something they don’t know for longer than 30 minutes. Maybe in your team, with the kind of work you do, it’s an hour, or a workday, or 15 minutes. It almost doesn’t matter. Pick something that feels right, and bring it up with your team at your next team meeting and see if they agree. Make changes as necessary. Then write it down somewhere and put it in your onboarding documents; from there you can build up to other shared team expectations.
Managing Your Own Career
Run your day, don’t let the day run you - Kahlil Lechelt
A manager or leads’ day in research computing is much busier and filled with a wider variety of demands than we’re used to as an IC. It’s vital to maintain some sort of control over the tasks you’re working on. Lechelt gives good advice:
Everything goes in a task list - email is not the place to store to-dos.
Have a small list of things you will get done today, leaving slack in the schedule for things that come up.
Have your calendar be the single source of truth.
You’ll slip somtimes. It happens. You’ll abandon your task list, get stuck in fire-fighting, stop putting work activities on your calendar. Accept it and start back where you left off.
The Painfully Shy Developer’s Guide to Networking for a Better Job - Sam Julien
Conferences are starting to happen in person again. A lot of us from the world of researc are pretty committed introverts. Being in a group of mostly strangers in person, or even online, can be challenging.
But meeting others in your work community and developing professional relationships is important. It’s not just about finding new jobs! It helps us find and share relevant ideas; helps us hone our craft; and helps build our community of practice.
Julien gives time-honoured advice that works for him; maybe it’ll help you, or someone on your team:
Make Other People Feel Welcome and Accepted - I find this approach really useful; I sometimes will pretend I’m the host, and then my sense of duty to making my “guests” feel welcome can override my sense of awkwardness
Give first, then give some more - Don’t make it about you; keep an eye out for things you can help people with, whether it’s making introductions (even to someone else you just met), problems you know something about, etc.
Don’t overthink - be genuine and have fun
Random
So I have a Windows computer for work for the first time since Windows 3.11. For those computers I actually type on (as opposed to those I ssh into) I’ve been using Mac since… 2006? On the new machine I can use Ubuntu via WSL2, a browser is a browser, and VSCode & Teams & Slack are all cross platform, so it’s mostly ok… except for the frickin’ keyboard shortcuts.
Oh yeah, and frickin’ paths. Here’s the history of how Windows came to use the wrong slash. It’s all DEC’s fault, stemming from how options were passed to commands for the TOPS-10.
An open-source microscope built using Lego bricks, 3D-printing, Arduino, and Raspberry pi. By IBM(?).
Make oddly soothing art with vector fields.
Using Google Sheets as a database to back a website using ROAPI and Replit for API hosting.
Literate programming/notebook style documents for the mechanized proofs that come out of theorem provers.
Small thermal models in the browser.
Here’s a C cross-compiler for the 6809 for those of us who had a TRS-80 Color Computer. To heck with those fancy kids with their Commodores.
Oh, fine. For you Commodore kids, here’s creating a Commodore C-64 cartridge with a Raspberry Pi Pico.
Quantum Computing from a statistical point of view (authors PDF).
That’s it…
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck in the coming week with your research computing team,
Jonathan