jonathan@researchcomputingteams.org
I want to close our discussion that started way back in #176 about this flywheel we want to keep going, by going back to the start.
In #176, I talked about how key it is to nurture our best clients, the clients who:
Then we talked our way around the flywheel. In #177, we talked about doing the highest bang-for-buck work to maximize our research impact; in #178 we talked about how the bar for the services we offer researchers should be that they’d be willing to pay for them if they had to; in #179 we talked about how success stories from those high-impact projects are the best and most effective form of advocacy; and in #180 we talked about how doing all those things would help us with the first of the two big problems we face internally: fundability and staffability. (The second is our responsibility as leaders).
So how do we do more of this highest bang-for buck, high research impact work that researchers really value and will generate strong success stories?
Assuming we’re already doing some work like that for our best clients, the simplest way do to more isn’t to about internal operations of the team, it’s more outward looking.
The simplest way to get more of this high-impact, highly valued work is to find more work like we’re doing for our best clients. And that means finding more clients like those best clients.
Part of that means understanding those clients, and what our teams do for them. That means talking with them (#158).
One might think that we already know what we do for those researchers - our teams are the one doing it, after all! But the vast majority of teams I talk do don’t actually know what parts of that matter the most to the researchers, or why that is.
Understanding our best researcher clients and what we do for them means going to the outrageous length of actually talking with them. It means asking questions like:
Once you have the answers to those questions from a half-dozen of your best clients, there’ll start being some patterns that you can use to find more work like some of the best work your team is doing. Because “clients like those best clients” likely doesn’t mean “in the same sub-sub-discipline of chemistry as Prof X”. It means people who need similar types of problems solved.
If you’re hearing again and again that your team is the alternative to hiring a postdoc, then you can start communicating that working with you is a way to keep their trainees focussed on science, and you could start (for instance) approaching computational groups who are having trouble filling postdoc positions.
If you keep hearing that the alternative to working with you is doing less computational work, you can start communicating that “building out their computational research programme” is a key benefit of working with you, and approach groups that are doing a little but not much computational work currently.
If you’re hearing that the alternative to your services is a commercial service, you can try to get a talk about your services into a workshop on campus that talks about those commercial services.
If you keep hearing that the biggest help your group provided was faster “time-to-science”, you can start communicating that, and start targeting researchers in highly competitive fields.
And all of this communication goes much better if you use the actual language your best clients used to describe the benefit.
Here’s the thing. Identifying the groups you helped the most and choosing other people in that same situation is called “market segmentation”. Putting together some material - a talk, an email, a blog post - describing how you help that segment, especially while being aware of the alternatives, is called “positioning”. And finding out where people in that segment are and finding ways to communicate with them are the first stages of “marketing”.
These aren’t dirty words. They don’t describe tawdry activities that are beneath us and would sully our teams’ good name.
These are steps in finding out who we can best help, and communicating in ways that make sense to them that we can in fact help.
These are steps in making sure we’re having the most positive impact on research in our community as possible.
They’re also steps in improving our own performance in ways our best clients actually care the most about. If we could use some improvement in communications with our clients, but what our best clients actually care about is getting results quickly, spending project time writing up periodic status reports to send to the clients would actually hurt our most important feature.
(“But what if our other clients would really like those reports?” Look, we care for and respect all of our researcher clients equally as human beings. But our goal is to advance research in our community as far as possible given the constraints (including resource constraints) we face. That means optimizing how we do things for the work that has greatest impact. Different groups want different things, and we can’t make everyone happy. We owe it to research in our community to focus as much optimization effort on possible on the work we do that has the greatest impact.)
By finding out what really matters in the projects that have the greatest science bang-for-buck, we can do more of it, improve how we do it, and better communicate how we help to more people who have similar work. This makes success stories easier to gather, advocating for our teams easier, and makes communicating our value to the institution easier. It keeps that flywheel going around, faster and faster.
And it’s not hard. We just need to talk to people and be willing to change how we talk about the work of our team.
This is a long weekend holiday in Canada, so apologies for getting this out late and for being a little light on the roundup. If this was a long weekend for you, I hope you enjoyed it! If you have one coming up, I hope you enjoy that!
And now, on to the roundup!
Over at Manager, Ph.D., in issue #173, I talked about how to tell if you are you accomplishing things, or you are just busy.
In the roundup were articles on:
What causes new engineers to “sink or swim”? - Lizzie Matusov
We talk a lot here about onboarding, e.g. - making an onboarding plan (#141) as one of the early steps of hiring, and beginning hiring with the end in mind (#135) - and supporting our teams by finding out what they need in one-on-ones and then coaching them as needed.
In this article, Matusov summarized a paper that that took survey data from 104 participants of early career new software developers that had just completed onboarding. The results weren’t great:
Clarity in role or job assignment was critical to early engineer experience; 38.5% of engineers did not know what to work on during onboarding. The highest-reported impact of this was distress and decreased productivity. Management and team support was a top factor for onboarding success. 74.3% of engineers felt their manager was invested in their development, and 85.71% of engineers felt their team was invested.; 19.8% of engineers were not paired with a manager when onboarding. The top areas of improvement recommended by new engineers were training and work distribution and planning methods.
Hiring takes a lot of the team’s time, and it’s so disappointing to see teams fumble this task - arguably the most important thing a team does - right when it’s nearly over. Onboarding is part of the hiring process; I argue it should be one of the first things we figure out in the hiring process, because it sheds light on what skills are absolutely essential and what the new hire can be taught.
We want our new hires to succeed, and to feel successful, relatively quickly - don’t neglect onboarding!
How to invest an hour now to make next week a bit easier - Loleen Berdahl
Berdahl talks about spending some time at the end (or start) of the week to take things off our calendars by bowing out or cancelling things, making sure more of the things that stay on our schedule are productive, and stay in a bit better control. I particularly like Berdhal’s scripts for cancelling unnecessary meetings or “suggesting” agendas for meetings at risk of being unproductive time wastes. Definitely worth the quick read.
Visually Communicating Elements of Software Design - Rafael Mudafort, Better Scientific Software
Communicating Software Design- Rafael Mudafort
Mudafort writes about diagraming software design; the BSSw post is mostly about UML, which I have some feelings about, and Mudafort’s site below has a bunch of good links to diagraming tools (including diagram-from-code) tools. We’ve talked before about how documentation is information, not active knowledge (#149), but good documentation (and especially diagrams) make it much quicker to bring information into people’s heads where it can become knowledge. So knowing what diagraming tools are out there that can help with the visual documentation and communication of design is useful.
(BTW, is any one else really annoyed that here in the common era year two thousand twenty four, where we’re mostly using tools like VSCode as editors, we still have to draw ASCII art programs instead of embedding SVG diagrams in comments? Guess that’s a rant for another time).
The HPC Containers Survey - Containers Working Group
Interesting survey of 202 people, largely with some significant amount of container experience, on how they’re using containers in HPC.
The tools being used are overwhelmingly on HPC systems are either Singularity/Apptainer, Docker, or Podman, in that order. On people’s personal systems, however, Docker is the clear winner.
Even for people using singularity, it seems like Dockerfiles are how most people are defining containers, with Singularity a respectable second. A lot of people are using space or easy build in their containers.
It sounds like most people aren’t pushing images, just publishing recipes, which is a bit of a shame; of those who are, people typically use Dockerhub, GitLab or GitHub.
While containerization is mostly used for applications, it seems like a lot of people are also using them for developer environments, for the sort of thing people used to spin up vagrant VMs - that’s interesting.
There’s more people than I would have guessed who build containers for multiple architectures - a minority, but still - and more than half of respondents use CI/CD for containers, which I find heartening although the survey organizers were disappointed it was as little as that.
Use Cases for High Performance Research Desktops - Henschel et al, 3rd Combined Workshop on Interactive and Urgent High-Performance Computing at ISC 2024
(Disclaimer - my current day job is at a company that sells both GPUs and software for this use case amongst others, but this paper doesn’t really mention either so I don’t see much of a conflict of interest here)
There’s a few trends coming together - increasingly interactive and complex workloads, plus workloads that require large amounts of data and/or specialized hardware and/or control of sensitive data - which are re-igniting interest in different kinds of hosted desktops on high performance systems. AWS, for instance, is touting how easy it is to do exactly this with the NICE DCV protocol, aimed very explicitly at HPC-type applications, so they presumably see this as an area of growing demand.
But it would be nice if we could also do this on our own systems.
In this article, the authors talk about the various use cases for this kind of service, where it fits into an HPC stack, and some experiences. They talk about the pros and cons of using something like OpenOnDemand, They talk about some things they’d like to see, such as deeper integration of the HPC system scheduler into the desktop, nicer GUI tools, and the development of more of a community and open source tools.
Fortran at the edge with Fortran on Cloudflare Workers.
An interactive C/C++ preprocessor macro debugger.
Drawing circles with only integer shifts and adds.
When your cable management becomes creature management - sloth gets caught in server rack in Brazilian university data centre.
And that’s it for another week. If any of the above was interesting or helpful, feel free to share it wherever you think it’d be useful! And let me know what you thought, or if you have anything you’d like to share about the newsletter or stewarding and leading our teams. 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
About This Newsletter
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 154 jobs is, as ever, available on the job board.
