jonathan@researchcomputingteams.org
After over three years writing the newsletter and talking with RCD managers more frequently, the one thing I’ve changed my mind most about has been strategy and strategic planning.
It’s not that I now believe thinking about the big picture is bad - quite the opposite! I just think the dialog around “strategy” and “strategic planning” in our communities is is both badly confusing, and a distraction from what we actually need to be doing. (For what it’s worth I mostly blame University/Research Institute strategic planning processes for this, along with a number of really unhelpful books and online materials).
The problem with it being confusing is that overworked new or front-line managers don’t know what they should be doing except that they’re assured that this nebulous “strategy” thing maters. Since they don’t really know what to do about it, and none of the materials on the topic have any kind of internal consistency, they just sort of find other group’s strategy documents, copy the format, put in some words relevant to their organization, and hope for the best. All the while they’re stressed about it, and have a sinking feeling that they didn’t do “strategy” right.
And why is our talk about “strategy” and “strategic planning” confusing? Why don’t new and front-line managers know what it means? Well, it’s because strategy doesn’t really mean anything specific in our context. It’s a (let’s face it) pretentious word which covers a slew of activities and needs.
The individual activities are important! I’m a huge fan of each of them. But they are very different activities that serve very different purposes, and I’ve become pretty convinced that lumping them all together as “strategy” harms more than it helps. Maybe in some future world where managers and leaders of RCD teams have the training and mentoring they need it will be useful again to file all these activities under “strategy”, but that’s not where we are.
The kinds of activities that get tossed into this pile are:
Positioning: This is assessing and deciding on a team’s position in a wider landscape. What is this team/organization’s role in the local ecosystem? What role does it play? What role does it not play - what’s out of scope? How does it interact with other teams in the ecosystem, including commercial options? How does it differ from them? How would a research group decide to work with this team rather than another? How do we reduce duplicated effort, and avoid gaps? When “Mission/Vision” stuff is done well, it is positioning, except that we need to reposition ourselves every time the ecosystem changes materially, whereas we’re assured that mission and vision are enduring. (I’ve not yet found a “positioning for mission-driven organizations” book or reference that I like — let me know if you can recommend one!)
Prioritization and Planning: This is no different than the prioritization and planning good managers and leaders do every week, every day - it’s just the stuff at a modestly longer timescale. How long? Well, it depends, but trying to plan on timescales longer than a year or so in our line of work is unlikely to be successful. Like all of our managerial planning, these need to be revisited frequently and systematically - I like quarterly, just like our team member’s goals (#68). We can have somewhat longer term priorities, but even they need to be revisited and likely updated every time the needs of the community we serve and the scope of the technologically (or financially) possible change. Which happens a lot more often than every five years.
Oh, and don’t get me started on the claim that plans should begin from a desired “strategic objective” and work backwards, or so help me the newsletter will be 37,000 words long this week. We know how well the waterfall method works in our environment.
Problem Solving: You hear more about this in a corporate context, especially startups, where people talk about “pivoting”. But it’s universally applicable. The startup (say) is stuck, struggling to get to some next level or even just to survive, and something in its approach has to change for it to accomplish the impact it could have. This is “simply” problem solving — pondering the many tractable challenges we’re facing, making a judgement call on which one is most important and addressable, and then taking steps to address it. We’re very good at problem solving, if we let ourselves be! Rumelt’s books are very good on this.
Stakeholder Engagement and Communication: Our research communities are why our teams exist in the first place; our decision makers are how our teams exist. (Remember, we’re nonprofits - #164 - so we have primary and supporting clients). We need two-way pathways of communication to both groups. We have to know what their needs are, what’s working well in what we’re doing, and what’s not. We also need to communicate what we’re doing, and what we will be doing even in times of uncertainty. I like La Piana’s “strategic guardrails” for that last one.
Lumping all of these activities under “strategy” and suggesting that they’re something to be done all at once every N years is to both inflate and belittle their importance. By having it be some Big Deal that has to happen in one fell swoop, it makes the whole endeavour unapproachable, stressful, and funhouse-mirror distorted. And implying that once it’s done you just have to check in on it every now and then until the next time is to bafflingly disregard just how necessary these activities are.
These are vital activities, essential activities, but also routine and quotidian activities, tasks that ought to be a normal part of a manager and leader’s job. It’s a matter of tending the managerial garden (#146). Like other important tasks (working on the professional development of our team members, business development, developing collaborations…) these are items that need to be tended to, a bit every week, with time taken periodically to step back, check in and take stock.
So if I’m suggesting tackling all of these, how is one to know where to start? Well, all else being equal I’d start with stakeholder communications. Talking to your research community and decision makers (#159, #160) is always a good use of your time, and what you learn can inform everything else.
But there’s some tell-tale signs that gaps in one of the others is causing you immediate problems, and if you find yourself experiencing one of those, you should tackle that one first.
Next week in Part 2, I’ll talk about the other reason why I dislike so much of the talk around strategy, and something to do even before tackling one of these activities. If our operations aren’t yet effective, thinking about medium term “strategic” issues isn’t going to get us anywhere.
With that, on to the roundup!
Over in Manager, Ph.D. this week I talked about making managerial decisions coming from a research and scholarship background.
Roundup items included:
The importance of right-sizing your retro - Jouhné Scott
Scott recommends holding some kind of “retro” (what I usually call a postmortem here, to distinguish them between routine retrospectives) after every kind of incident:
Here’s my stance: the incident response process isn’t complete until a retrospective occurs.
But to do that, it means that the postmortem process should be scalable up and down - minor incidents, near-misses, and the like aren’t going to need the same scale of the post-incidence response learning process as a major failure.
Scott’s recommendations are:
But crucially, Scott tells us to make sure that they are useful to the team:
The goal of holding retros is to ensure your team captures the important takeaways that come out of every incident — not checking a box just to say you had a meeting. Treat retros as a designated time to allow responders to decompress, share lessons learned, and create action items to optimize your incident response plans and system health.
How To Survive Your Project’s First 100,000 Lines — Evan Ovadia
To me, one of key differences between (some) areas of research software development and generic “software engineering” is that such research software tends to be subtle, not merely complicated. That makes testing and debugging tougher.
But there are other areas of software that are like that - compilers are a great example.
In this article, Ovadia gives advice for how to survive the first 100,000 lines of code based on experience from the Vale compiler (and, to some extent, games development):
Maintainer Month - GitHub
I’m a little late to this - GitHub is having a Maintainer Month event (schedule) in May, with talks, resources, and an invitation (launch?) to join their Maintainer Community.
Is it enough to recommend tasks to newcomers? Understanding mentoring on good first issues - Xin Tan, Yiran Chen, Haohua Wu, Minghui Zhou, and Li Zhang, arXiv:2302.05058.
Interesting paper (surfaced by Greg Wilson on his very useful Never Work In Theory blog) by the authors on the effect of mentorship on newcomer onboarding and “Good First Issues”. Mentorship by experts on the issues is positively correlated with success, but negatively correlated with retention.
Newcomers are critical for the success and continuity of open source software (OSS) projects. To attract newcomers and facilitate their onboarding, many OSS projects recommend tasks for newcomers, such as good first issues (GFIs). Previous studies have preliminarily investigated the effects of GFIs and techniques to identify suitable GFIs. However, it is still unclear whether just recommending tasks is enough and how significant mentoring is for newcomers. To better understand mentoring in OSS communities, we analyze the resolution process of 48,402 GFIs from 964 repositories through a mix-method approach. We investigate the extent, the mentorship structures, the discussed topics, and the relevance of expert involvement. We find that ~70\% of GFIs have expert participation, with each GFI usually having one expert who makes two comments. Half of GFIs will receive their first expert comment within 8.5 hours after a newcomer comment. Through analysis of the collaboration networks of newcomers and experts, we observe that community mentorship presents four types of structure: centralized mentoring, decentralized mentoring, collaborative mentoring, and distributed mentoring. As for discussed topics, we identify 14 newcomer challenges and 18 expert mentoring content. By fitting the generalized linear models, we find that expert involvement positively correlates with newcomers’ successful contributions but negatively correlates with newcomers’ retention. Our study manifests the status and significance of mentoring in the OSS projects, which provides rich practical implications for optimizing the mentoring process and helping newcomers contribute smoothly and successfully.
The authors suggest that there may be a selection effect at play in the retention piece - e.g. those that go on to successfully get a PR merged without expert assistance are disproportionately likely to be able to succeed again, and that if you look at all retained users, almost 2/3s had expert participation:
Actually, among the newcomers who make further contributions, 64.4% of them have expert participation during the GFI resolution process
Software Engineering Practices in Academia: Promoting the 3Rs—Readability, Resilience, and Reuse - Connolly et al., Harvard Data Science Review
The authors advocate in this article for three qualities to be prioritized in research data science software - such code should be, above all else,
They explain by way of a couple of case studies.
They also distinguish between developing for three “scopes of use”:
These distinctions align pretty strongly with what I’ve written about the RCD technological readiness ladder (#91) and the evolution of software (or other digital infrastructure) from being a research output to a research input (#119).
How do you promote your organization? - Chris Blanton, Ask.CI forum
Nice discussion starting on the Ask Cyberinfrastructure discussion forum about how to promote research computing organizations. I agree! Our purpose is to advance research and scholarship as far as possible given our resources and priorities; we do that by attracting users and research groups.
Blanton has found these approaches work:
I should write more about this. Testimonials are gold (e.g. Ian Corden’s advice in #154) and easy to get if a little labour intensive; same with success stories. And once you have them you can use them in a lot of different ways!
The last lecture of Gilbert Strang, titan of linear algebra education, streams live on Monday. Learning from one of his textbooks in the 90s, I felt like I could almost see n-dimensional vector spaces and projections onto key subspaces. Happy retirement, professor.
Starting to realize that maybe my preference for certain kinds of computer tooling were influenced by early experiences - just found a (PDF) copy of the manual for my first “word processor” and slowly realized that it was basically vi + some troff-inspired formatting.
A list of programming languages that predate Fortran.
Like APL, wish there were a lot more parenthesis involved, and don’t much care how? April is a variant of APL that compiles to Lisp.
This is fun - Julia Evans has an “implement DNS in a weekend” exercise that walks one through implementing a working toy DNS server in scratch in pure Python.
Profiling Webassembly code compiled from any language - wzprof.
A dissenting twitter thread on the “No Moat” discussion from last week. FWIW I think both things can be true - there might be capabilities only possible on the largest scale of models, while still being a vibrant and exciting set of research and capabilities being continually created and iterated on at much more modest scales.
A walkthrough of the classic tech interview question, “what happens when you type a URL into a browser”.
Why prioritizing sequential I/O access can still matter in the age of NVMe - but in different ways and for different reasons.
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.
