jonathan@researchcomputingteams.org
Sorry for today’s issue being late - I’ve just gotten back from my first trip since Feb 2020, a long-delayed trip to visit family. Travel was… fine? Other than the usual “travel to the east coast of Canada during winter” logistical problems caused by weather. We were extremely careful, and it seems like we made it back without getting sick, which is particularly important for our household.
In other news, thanks to everyone who’s already offered some feedback on a quick writeup on feedback. I’ve incorporated some of those changes, and now have a draft I’m happy to share (even though it will continue to need updating); if you’d like to see it it’s available on the newsletter webpage here. If that’s something you’d like to try out and work through, let me know - just drop me an email.
But the main thing I want to start talking about is something that’s bad everywhere, but especially in our line of work: meetings.
We’ve all sat through excruciating collaboration meetings, glancing at the time, waiting for it to be over. Someone won’t stop talking, the person nominally in charge of the meeting letting conversation wander all over the place - or the meeting actually seems fine, but there’s no real reason for us in particular to be there and we have other things to do.
Meetings are hard. Like everything management related (or really, just working-with-people related) they take forethought and effort and cultivation to be effective. It’s no wonder why Shopify recently decided to cancel all recurring meetings with three or more people. By default, meetings aren’t great.
But they don’t have to be that way. When managed effectively, meetings are a powerful collaboration tool. I like good meetings! They’re a much faster way to brainstorm, come to agreement, or collaboratively solve problems than emails pinging back and forth. Done well they can be energizing and rewarding.
Synchronous discussions like meetings are great for things that need high bandwidth and low latency communication. They can help with agreement - developing a common understanding, alignment - getting everyone pointed in the same direction, building relationships and social connection, learning, and collaborative problem solving. They can also help drive momentum with demonstrations of progress.
On the other hand, broadcast/multicast of information, routine status updates, and the like don’t benefit from synchronous communication. They literally “could just be an email” (or google doc or slack bot or…) We want to use everyone’s precious time wisely, so it’s important that our meetings align with the things synchronous communication is good for and that other needs are supported in other ways.
In the next few issues of this newsletter, we’ll be discussing meetings and how they can be better. And a good meeting starts with a clear purpose. Today I want to talk a bit about how to think about the purpose(s) of your recurring meetings in particular.
A lot of our large meetings are recurring - team meetings, standups/huddles, project status meetings. Because they happen again and again and involve a number of people, it’s especially important that they are run well.
These recurring group meetings are tough. They often have a bit of a “catch-all” nature to them. That’s not necessarily bad; from an efficiency point of view it can make a lot of sense to have one slot used for several things as opposed to constantly creating ad-hoc meetings involving the same people.
That doesn’t absolve us from having purposes in mind, though. Unfortunately, even though these meetings happen repeatedly, expectations and goals are often left implicit or are not thought about at all. That’s not great. How can you tell if a meeting is successful if you can’t even succinctly describe what it is for? And how could you possibly know how to improve it?
It’s great that in the last few years the importance of having an agenda for a meeting has caught on. It’s a genuine improvement. But it isn’t enough. It’s worryingly easy to fill an hour’s worth of agenda with topics that seem worthwhile, without actually accomplishing much.
I want to emphasize that an agenda is not a purpose. Instead, agenda items serve some purpose, or have some purpose.
A meeting should have one or (in the case of “catch-all” meetings) a modest number of clear purposes. This will shape the agenda, attendee list, what should be done during the meeting, and the follow-up afterward.
Team meetings may have a number purposes such as alignment on short- and medium term goals, team building (and collaborative problem solving) by encouraging team members to ask for help on things they’re stuck on, practicing giving short presentations and collecting feedback on those presentations, pushing forward on projects by demonstrating results.
I encourage managers I speak with to look at their recurring catch-all meetings and critically assess each standing agenda item for its purpose. Take a common one like the checkpoint, where each team member reports on what they’re doing. Is it just a status update? That can be sent ahead as email. But maybe there’s other goals you’d like to achieve with it:
You may even want to achieve multiple goals with the updates. That’s ok! Whatever’s the case, it’s much easier to achieve your goals for an agenda item if you’re explicit about them, if they’re listed with the agenda (per item if necessary), and you set (and evaluate) the structure of how the agenda items are discussed and followed-up on with those goals in mind.
We can get a little lazy with recurring meetings - we set up a repeating calendar invite and have a standing agenda, so it’s pretty easy to just let it run on autopilot. But just because the meeting repeats doesn’t mean the agenda or attendee list has to be the same.
It’s certainly important to get in the habit of being thoughtful about the agenda items. But a lot of managers could benefit from giving some thought to making the attendee list more dynamic.
For instance, in a weekly team meeting, when you’re getting ready to or in the process of hiring, the hiring process will be on the agenda a lot. Would it make sense to invite your HR business partner to the meetings? Or a finance contact when you’re considering purchasing something? In the middle of some collaborations with a team across campus, would it be useful to have a contact from that team attend? They don’t necessarily need to sit through the whole meeting if it wouldn’t be valuable to them, but at least for their items?
A weekly team meeting is really for and about your team, but your team interacts with a lot of other groups. It can make a lot of sense to have some of them attend, too, when it’s mutually useful.
Once there’s some more clarity about agenda item purposes, a good occasional agenda item for a recurring meeting is a meeting retrospective. Are the items achieving their purpose? What went well, what could go better, what should we start doing, what should we stop? The discussion can touch on what happens in the meeting, but should also touch on follow up.
Giving agenda items purposes makes it much easier for you and the team to evaluate their success, experiment with changes, and iteratively improve the meetings.
Recurring meetings need clarity on purpose(s) in order for them to run efficiently and effectively and ensure that everyone’s precious time is being used wisely. By having clear purposes for the agenda items on those meetings and making sure that everything from the agenda to the follow-up supports these purposes, and working on iterative improvement, meetings can become reliably better. Given the dismal state of meetings in general, it doesn’t take much for them to be much better than average.
Did this asynchronous communication serve its purpose? Is it helpful for you in thinking about your recurring meetings? Is there anything I missed or got wrong, or should cover in an upcoming issue, or you’d like to talk to me about? Email me by hitting reply, or at jonathan@researchcomputingteams.org.
For now, on to the roundup!
Shaping Your Authenticity - Subbu Allamaraju
There’s a lot of talk about “authenticity” in leadership, which is good, and yet there’s a bit of a trap lying in wait there for new managers and leaders.
There’s no single “authentic” Jonathan. I behave very differently visiting my parents than I do spending time with my closest friends than I do at a funeral than I do as a manager. None of those are less or more me; different situations just call for different behaviours, and all of those behaviours are learned.
Sometimes those behaviours don’t come easily; beginning to be more directive as a manager, or starting an exercise regime during the pandemic, were very much awkward and unpleasant-feeling at the time. But they weren’t inauthentic; they just weren’t what I was used to doing.
Managing - really, doing anything - with integrity is important. Authenticity in the sense of not violating core values or who you are as a person is absolutely a reasonable requirement!
But authenticity can be a bit of a slippery slope from “maintaining my personal integrity” to “doing what I like to do”. Allamaraju has a great quote from Herminia Ibarra’s The Authenticity Paradox:
Because going against our natural inclinations can make us feel like impostors, we tend to latch on to authenticity as an excuse for sticking with what’s comfortable.
As people in the world of research, we should know to rigorously test our models, and especially our favoured models. Any mental model about our work that leads to convenient conclusions like “I should just keep doing things the way I like to do them” deserve the utmost scrutiny.
Allamaraju talks about authenticity and growth, and how as we grow new skills and more comfortable in wider situations, we can expand our toolbox of handling different situations without ever being “inauthentic”.
What Great Sponsors Do Differently - Herminia Ibarra and Rachel Simmons, HBR
Building Growth Plans with Mentees - Dan Abel
The same Ibarra, and Simons, write about sponsorship - going beyond mentorship to actively create opportunities for the person.
As leaders we sponsor team members of course, finding situations where they can grow in directions they want, but even trainees or junior peers are people who might want us to sponsor them. And as we develop in our own career, more sponsorship possibilities present themselves.
As with so many things in management and leadership, sponsorship isn’t rocket science: it’s a matter of continually attending to the basics. Ibarra and Simons identified five key practices of great sponsors:
Abel’s article focusses on the professional development side of the mentoring or sponsoring relationship - helping grow the junior member grow their own path.
It’s a useful article. I like how it starts:
Abel then talks about different ways of helping team members grow:
The Cost of Saying Too Little - Daniela Blei Winter, Stanford Social Innovation Review
Manager from or in the world of research tend disproportionately to be introverts, and for we introverts under-communication is kind of a way of life.
But under-communication from managers or leaders is more widespread than that. We have a lot going on, and tend to take it for granted that people know that we’re thinking about them and their work. Sadly, they don’t! From Winter’s article:
“Silence signals lack of attention, lack of interest, and ultimately, lack of care—the thing that, I believe, we most expect from leaders.”
Blei discusses interview the authors of four studies, and other researchers. The studies demonstrate that most managers communicate much less than their team members want, and that people routinely project onto that lack of communication a number of negative assumptions - that the manager isn’t engaged, doesn’t care, isn’t empathetic.
This is consistent with what we’ve seen in the newsletter before, such as Google’s Project Oxygen finding that great managers and great managers have “Good communication and they listen to the team” while poor managers are “spending too little time managing and communicating”.
The good news is that one-on-ones are a straightforward way to ensure that there’s some baseline level of communication occurring with each of your team members, as is feedback - including lots of positive feedback.
Don’t Underestimate Your Influence at Work - Vanessa Bohns, HBR
If you’re like most people, you chronically underestimate your influence over others
This is particularly true for people in the world of research, who have developed significant expertise in one or more areas. People actually do pay attention to what we say, and would be much more willing to help us and agree to collaborate with us than we think.
Bohns summarizes some research demonstrating this, and then recommends we test it out. Stretch a smidge outside your comfort zone - ask a peer for help on something that wouldn’t quite rise to the level that you’d normally set for bringing in someone else. Pay attention in a fairly objective way (pretend to be an outside observer - it’s surprisingly effective) to how people react to what you say in meetings - not just in the moment but afterwards. Are people repeating the words you used?
We have more impact than we think.
What does it mean to be a cost center? - Will Larson
In #127 I talked about the downsides of being seen as a utility versus a professional service firm. One’s a commodity, a necessary service but replaceable as soon as one comes along that’s 5% cheaper; the other is a partner.
Another way of talking about the same idea is, as Larson does, talk about being considered a cost center rather than a core function. As Larson quotes, businesses see cost centres as:
… a department or function within an organization that does not directly add to profit but still costs the organization money to operate.
In research institutions, such a cost centre would be any administrative function which, while necessary, isn’t core to the teaching or research missions.
The more we allow ourselves the comfortable choices of being generalists, helping all comers, and focussed mainly on efficiency metrics like utilization, the more we are communicating ourselves to be a replaceable cost center. Obviously we should aim to be efficient, but we and our institutions need us to communicate the impact we’re having on research, on how we’re a valuable partner, on how work is getting done that wouldn’t be possible without us. As Larson says,
Anyway, optimization metrics are very important to running your organization well, are terrible for reporting upward, and don’t forget to focus at least as much on what the team is doing.
Your tech stack is not the product - Mike Wakerly
The closer we are to research, the less we need this reminder; but as we stay longer in the world of technology, it becomes easy to forget.
The tech stack doesn’t matter. The only thing that matters is the research problems getting solved. That can become hard to hear, because we spend a lot of time working on our technology stack, and developing our skills in it! We just need to remember which is the means, and which is the end — especially when planning, and communicating outwards.
The product is the process by which the researchers get their problems solved. Yes, there’s some technology involved, but the technology could be different technology and it all could still work. The tech stack is implementation details. The product is how your team and researchers use it to advance human knowledge.
“Did you miss my comment or what?”: understanding toxicity in open source discussion - Miller et al, Proceedings ICSE’22
Discussions on open source software projects can quickly become toxic, but in a different way than in, say, social media. This paper reviews the state of the literature and goes quite deep, identifying triggers for toxicity, and relating them to the nature of the toxicity and the person involved. Only a small fraction of the toxicity comes from drive-by interactions, sadly.
This is interesting - IceCube, the South Pole neutrino observatory, has sponsored a Kaggle competition to improve the reconstruction of neutrino events in their detector.
The underestimated benefits of partially or incompletely automating something.
Researchers Present Vision for HPC Fusion Data Gateway - Oliver Peckham, HPC Wire
A Vision for Coupling Operation of US Fusion Facilities with HPC Systems and the Implications for Workflows and Data Management - Smith et al, Smoky Mountains Computational Sciences and Engineering Conference
FAIR data repositories are increasingly important, not just in new fields like health data, but for what were traditional big-metal HPC simulation fields.
Peckham reports on Smith et al’s paper on the rapidly growing needs for fusion simulation datasets; as large first-principles calculations are done, they are increasingly valuable for re-analysis, but also for informing integrated HPC or AI simulations of fusion systems. These datasets are expected to grow to petabyte scales shortly, from their current terabyte scale.
Many of the needs called out by researchers will be instantly familiar to those working in research data management in other contexts:
But with HPC characteristics:
the large sizes of the datasets and how they’ll be used makes high-speed access from large-scale systems a key requirement.
Random one-on-one question cards.
Fascinating walk through of a 1960s-era Soviet mechanical analogue computer for displaying the global positioning of the Soyuz spacecraft
Nice argument about why it rarely works to make use of something already written in code for another purpose - e.g. generating architecture diagrams from CF or terraform scripts: because the abstractions we need to use for the first thing are rarely the same as what we need for the second thing.
How a neural network learns binary addition.
A new parallel framework for deep learning - neural fortran. I’m genuinely curious to see how this goes, no programming language has better native support for math on distributed multidimensional rectangular arrays than Fortran.
Cursed C++, volume 7314 - printing text even though main() is empty.
A pseudo-3D first person shooter in the terminal, written entirely in gawk.
Using GPT3 to support Q&A against your documentation - there’s starting to a number of tools with quite different approaches for this; for those of us with large knowledge bases for users, at some point this could become quite useful.
In praise of prolog. Relatedly, a tar creator and extractor in 130 lines of prolog, and a browser-based visual IDE for prolog.
A video encouraging us to write readable code - from 1975.
Dotfile and OS config file tracking with git.
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 161 jobs is, as ever, available on the job board.
