jonathan@researchcomputingteams.org
I got asked a question building on the last post about taking on a new project, and the current top unanswered poll.ly question is “I’m starting a new job! What should I do to ramp up quickly?”
Let me answer a slight generalization of those questions: say you have taken on an existing responsibility. It might be being promoted to manager, it might be a new job, it might being put in charge of some effort that already has some history. (And in our institutions, every effort already has some history. There are no completely de novo efforts in our line of work). What should you do?
(Read on, or go straight on to the roundup).
It’s mathematically possible, of course, that someone in our roles taking on a new responsibility has clear guidance from their boss, and is receiving routine and helpful support and coaching on on their efforts, so that they feel like they’re in good hands. Yes, yes, stop laughing, I said it was possible.
For the rest of us, figuring things out on our own, there are two common failure modes: freezing, or doing too much too soon. It’s important to fight both of those instincts.
My guidance in these situations is to keep things moving steadily, gather all the data you can, report back to everyone, and only then - likely three or so months later - start building a library of small quick wins that, hopefully, solve multiple problems.
The big picture here, the guide star to follow, is that someone taking on a new work responsibility for things that will affect people has two and only two initial tasks. Task one is to learn what the heck is going on; task two is to build trust and respect with the people their efforts will effect. You can’t execute on your responsibilities unless you see them and the consequences of any actions clearly; and you can’t get anything significant and lasting done without the trust and at least grudging support of most of those you’ll be affecting. Everything else is tied for a dim and distant third.
First: Do no harm
So, congratulations! You’ve been dropped into some pre-existing human system, and are charged with executing on some new responsibilities.
Human systems are complex. Changes to complex systems always have multiple consequences. And the thing about complex systems is that unintended consequences are basically always bad. Until you know enough about the humans you’re dealing with and the related systems they’re part of, not only can you not guess ahead of time what the consequences of any changes will be, you won’t even know how to detect them when they do happen.
So your first job, while you’re learning things and building trust, is to keep the lights on, keep expected activities happening, and not make any changes yet. Learn what the steady state looks like first.
You might think (as I certainly did in an earlier role) that if you already have experience with this effort or this team — say you’ve just been promoted from IC to leadership — that you have the background knowledge necessary to skip this and the next step. I was, and you would be, very much mistaken. Indeed, I did and you would know just enough to be dangerous. There’s still a bunch of important context you’d be missing. Steady on.
There may be something that is obviously, dangerously on fire and leaving it alone for a while isn’t an option. My guidance here will be painful to hear for those of us with expertise and a desire to fix things. And yet. Unless you’ve been directed otherwise, do the smallest, most self-contained, most hacky thing that can possibly be done to keep the flames down to a containable smoulder for a while, make a note of what’s happening, and move on. You don’t know enough to fix this properly yet. You just don’t. Give the people around you some credit. If the fix was so obvious and easily done that someone just walking in could fix it, the thing wouldn’t be on fire right now.
Second: Listen, Listen, Listen
Your second job is to gather all the data you possibly can.
(I mean people data. We’re all experts here of one sort or another, so I’m not going to advise you to learn the relevant domain knowledge for this responsibility - we take that as a given, and frankly have probably already started doing that because we enjoy that part. I’m focussing on the messier, trickier, people stuff.)
If you’re part of a group of people, and there’s no practice of one-on-ones yet, start one-on-ones.
And start having one on one conversations with others. Create a list of key stakeholders, of teams you’ll be interacting with, of people your actions will affect, of people whose actions will affect you. Start working your way down that list, having one-on-one conversations with them.
In both cases, ask them questions about how the responsibility you’re now charged with has gone in the past, what’s important about it to them, what they worry about, what they think is under control, what kinds of interactions they’ve found valuable - keep them talking and take copious notes. Write down exact quotes of anything they say that illustrates a point particularly well.
Use all your active listening skills here - listen more, speak less; paraphrase what they’ve said for validation and clarification; ask followup questions; sympathize; don’t offer your own thoughts.
The task here is to gather all the data you possibly can. Fight against the temptation to interpret it right away – you can’t interpret a individual noisy data points. The work here is to gather lots of data points so that trend lines later emerge.
Remember that if a person says they experience a problem, they are absolutely correct about their experience. But anything else they offer (an assessment of the problem’s priority broadly for the community, a diagnosis of the underlying issue, or a proposal for a solution) is just their own interpretation filtered through their own perspective and likely lacks other important context, context you’re still collecting. If a number of people experience a problem in the same general area, there is obviously a very real problem somewhere around there that will eventually bear thinking about, but it might not be what they think it is. Collect the data impassively, gather it without interpreting it.
Third: Report Back
Report-back will be in a few different phases.
For external people you’re not talking weekly with, within a day or at most two send them a thank-you. Include with the thank you distilled and coherent notes from your meeting, ask them for feedback to correct or expand on anything in the notes, and invite them to follow up by email or another meeting if there’s anything else they’d like to cover.
This follow-up is absolutely entry-level professionalism stuff, but I’m continuously surprised by how uncommon a practice it is in our profession. Yes, it takes work. In my experience, distilling notes from a meeting into something other people could read and learn from takes roughly as long as the meeting did. But remember, the goals here are to learn what’s going on, and build trust. Sending lucid notes after your meeting and requesting feedback means organizing what you learned while the meeting is still fresh in mind, getting that validated by the person you learned it from, and communicating to them both that you took what they said seriously and that you follow through on conversations with them. That is what makes the meeting worthwhile (for both of you) in the first place!
If you’re working with a team, periodically report back distilled, anonymized versions of what you’re hearing from stakeholders. Making use of the direct quotes you jotted down is an extremely effective way of helping the stakeholders communicate a point. Once you’ve heard from all the team members, you can also summarize what you’ve heard from the team members back in an anonymized way. (Be careful with direct quotes in that context - people might recognize each other’s words). Don’t let the team react too strongly (positively or negatively) to what you’re reporting back, and don’t start making changes yet; the context here is that this is what people are saying, stuff to be aware of, and things to think about. Make it clear that this is part of an ongoing process, and as it winds up you’ll collectively decide what’s next.
When you’ve heard from all of the external voices, distill everything you’ve heard — still without interpretation or next steps — into an easy to read document. A slide deck works well for many, but it could be anything. As before, make generous use of (anonymized) direct quotes. Run it by your team if appropriate, and then send it individually out to everyone external you’ve spoken to, and then offer to schedule a time to walk through it with them and collect their feedback.
This has likely taken months. Ninety calendar days is a commonly cited length of time, enough to learn the lay of the land, and for people to start thinking “one of us” rather than “that new one who just started”. You now have a firm foundation to build from.
Fourth: Start building small multi-purpose changes
The first three steps are all about learning what’s going on and building trust. You build trust with people by listening to what they have to say, being seen to take it seriously, and following through on things. Those are all things you’ve started doing. Now you have enough background knowledge and trust built up to start getting some things done.
In the distillation of data you’ve done, some patterns have begun to emerge, and some likely priority areas taking shape. You’re already starting to see where systems interact, which people are affected by what area, and where the effects of small changes would have ripple effects.
What the next activities will look like will depend a lot on the nature of your new responsibilities. But in all cases, the goal is to identify some small wins. You’re still learning how systems interact, and still learning how to work with new people, so it’s baby steps first.
Find small changes that could be made that address more than one problem area, or more than one opportunity. You don’t want to start by making surface-level tweaks. Also, remember the law of unintended consequences! It’s likely that any change will cause its own downstream issues, and you don’t want to just shuffle problems from one area to the other. The goal is small changes that have noticeable effects on a few issues that a number of people have suggested.
Validate your proposed priority and approach with (at least) the affected people, and start making changes. Keep talking to people, and pay very close attention to how things are going. Once one change has been successfully made, and the consequences understood, report that around and begin with the second. Keep your lines of communication open, and start building lines of communication directly between stakeholders. Start building momentum.
Making things happen with a new responsibility is hard, but the key is to start with the foundation of knowledge and trust from other people. Put that work in, steadily and consistently, and big things slowly become possible. We too often overestimate what we can do in a week and underestimate what we can do in a year.
Some resources I really like for this topic (and if you’re familiar with them you will have seen their influence on what I’ve written above) include:
I’d like to emphasize that even if you’ve had a responsibility for a while, it’s never really a bad time to go through this process. You can always find some excuse — a new academic or financial year, an upcoming project kickoff or wind-down, a new hire or departure — to collect a bunch of data, have conversations with stakeholders, and start making some new plans and changes.
Any thoughts? Anything I’ve missed that you’d add? Let me know - just hit reply or email me at jonathan@researchcomputingteams.org.
And with that, on to the roundup!
Setting Direction: Create a Strategy - Chase Seibert
Siebert describes the basics of strategy, using 1997 Apple as an example and leaning heavily on Richard Rumelt’s “Good Strategy Bad Strategy” book:
He also selects a quote that is both correct and weirdly appreciated in our line of work:
Good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests. Strategy is at least as much about what an organization does not do as it is about what it does.
Everything is tradeoffs. Any strategy is necessarily some form of specialization along some dimension. “We do everything” is not, and never can be, a strategy.
Rumelt’s two books are really quite thought provoking. (They’re more filled with anecdotes than I care for, but others find that an extremely helpful part of the book, so.) If you want to read a book on business strategy, one of his are the ones I’d recommend. But our context, where we (unlike Apple) can’t just pivot to something completely different, is a more constrained than business strategy writing generally allows for. La Piana’s book, “The Nonprofit Strategy Revolution,” is starting to grow on me for an RCD team situation.
The Coach and the Fixer - Michael Lopp
Lopp talks here about the tension between being the coach/listener, and being the fixer/one who takes action. One or the other of those is likely more comfortable for us, depending on the situation. The problem is, we as managers and leaders need to be able to call upon both as needed.
Why are process gates the hellish spawn of evil you should avoid at all costs? - Jade Rubick
When something fails, the perfectly understandable first reaction is to impose more oversight on whatever that process was, and to require some sort of quality control between the creation of the next thing and its release.
This approach is seductive, because from a management or lead point of view it feels like we’re Doing Something. And, you know, there are some times when these kinds of gates are needed. If you’re going to be updating medical devices, you’d best make absolutely sure the new versions work properly.
But as Rubick points out, these stage gates multiply, slow everything down, erode the sense of ownership of team members (since it’s pretty clear they’re not trusted to do their job). Our jobs as managers and leaders isn’t strict oversight, it’s to build a team and processes by which good outcomes happen without our intervention.
As in Silverio’s article in #134 says, the key is to make sure any bit of process function has a clear purpose, and to constantly review them make sure they’re needed and that they’re the best way of achieving their aims.
Being an Introverted Leader - Matheus Tait, Thoughtworks
We’ve talked about this on and off since way back in #4, but it’s worth repeating. As a manager or lead at various times you’ll need to talk and to listen, to be assertive and to let others take the lead, to be detail-oriented and to see the big picture, to be people focussed and to be task focussed. There is no one whose default behaviours covers all of what’s needed, because different situations call for different and even conflicting behaviours.
Here Tait talks about his own struggle with being an introverted leader, and his first three suggestions could be just as easily applied to any personality trait:
Community Smells – The Sources of Social Debt: A Systematic Literature Review - Eduardo Cabllero-Espinosa, Jeffrey C. Carver, Kimberly Stowers, arXiv:2209.10671
This is an interesting paper where authors review the literature for issues with communities in charge of stewarding some technical work (here mostly software, but it could just as easily be a data resource or something else). They distill thirty or so identified issues down into four main causes (lack of context, poor communication, the wrong composition of teams, poor coordination) along with some lesser ones, and suggest a list of community and project management approaches that can improve things.
Software engineering practices - Simon Willison
Inspired by a twitter thread, Willison writes down some good practices that he’s found useful in software development teams.
The list is good, and I think it’s worth highlighting that the recommendations are all of the form “make it easy to do the right thing” (documentation alongside code, infrastructure for DB migrations, templates for new work) and/or automation (code formatting checks, test data generation, new dev environments, preview environments).
Ultimately, these support-the-team’s-progress sorts of practices matter much more than particular technical choices that we tend to bikeshed.
Rethinking Software Variants - Axel Hubel
Hubel lists some of the problems with the developer (and user) experience with software that has compile-time options to control functionality (e.g. turning on parallel support). Suggestions for improving things fall into two categories:
In the HPC world, where we assume everyone will be compiling our code, I think we let ourselves get a little lazy this way. Being more disciplined about how we enable code extensions while maintaining API stability (particularly for libraries) definitely matters! People will (hopefully) be building on our code and recompiling it, and maintaining ease of developer experience matters.
But it’s also increasingly straightforward to build in multiple functionalities at compile time, shipping binaries and handling functionality changes on different platforms at run time. (Think of all the e.g. math libraries that do just this). Not every package needs or is worth that level of more sophisticated development tooling, but the more we want our packages to be used, the easier we might want it to be for someone to download a binary that ‘just works’.
Data Management Planning for an Eight-Institution, Multi-Year Research Project - Kristin A. Briney, Abigail Goben, Kyle M.L. Jones, Int. J. Dig. Curation 17:1
This is a nice writeup of the hard data management work that usually goes unheralded and undescribed in big collaborations. Not only does that mean credit isn’t given, but we miss out on the opportunity to learn what others have done. Unsurprisingly, data management plans can and should be more than just compliance tick-the-box exercises. Quoting from the conclusion:
[..] First, the team used DMPs as living documents that were regularly refined to meet the project’s and researchers’ needs; if something in the DMP wasn’t working, it was changed. Second, the project leveraged multiple DMPs; each project phase had distinct data collection and analysis methods, making individual DMPs beneficial. Finally, the project’s DMPs were vital to coordinating work done by multiple people in different locations; the large and distributed project required consistent data handling and the DMPs facilitated this. The project’s four DMPs augmented the funding application, streamlined data collection, documented analysis workflows, and made data handling uniform, allowing researchers to focus on research instead of being mired in the data problems that can easily arise in a multi-site, multi-year research project
We’re going to see more and more laws and regulations - and even just community expectations - about prompt and full disclosures of breaches in our systems, and I think a lot of our community isn’t ready for that yet.
Handling WebAuthn over remote SSH connections - Matthew Garret
How Passwordless Works - Alan Parra, Teleport
I strongly suspect our community is going to see more and more use of WebAuthn, and that means we’re going to have to figure out how it interoperates with other login mechanisms. Garret an initial exploration of trying to get the two to work together, and Parra has a nice overview of how WebAuthn works.
A pastebin that you can netcat to from the command line - termbin.
You can play old video games I grew up with like asteroids, centipede, breakout, snake, and missile command in the web browser now, of course - including on the American Association of Retired Persons website. Just a click or two away from the “staying mentally sharp” page. sigh.
Grep pdfs with pdfgrep.
The old numerical-methods hand and number-theory dilettante in me really likes this: reals, a Python package for arbitrary precision arithmetic that only prints digits that are accurate, based on interval arithmetic and continued fractions.
In other cool python package news, a seemingly quite good tool for making modernization recommendations for Python code bases, refurb. The things you can do with static code analysis tools these days continues to impress.
Launch a docker container image as a (firecracker) VM with ignite.
Building a self-destructing USB drive.
Challenges with UNIX signals - the 15 year challenge to fix an old GDB user experience issue when signals are caught and the dangers of using signals in production when they’re not.
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
Research computing - the intertwined streams of software development, systems, data management and analysis - is much more than technology. It’s teams, it’s communities, it’s product management - it’s people. It’s also one of the most important ways we can be supporting science, scholarship, and R&D today.
So research computing teams are too important to research to be managed poorly. But no one teaches us how to be effective managers and leaders in academia. We have an advantage, though - working in research collaborations have taught us the advanced management skills, but not the basics.
This newsletter focusses on providing new and experienced research computing and data managers the tools they need to be good managers without the stress, and to help their teams achieve great results and grow their careers.
This week’s new-listing highlights are below in the email edition; the full listing of 207 jobs is, as ever, available on the job board.
