#91 - 12 Nov 2021
Making decision making clear; Valuing ourselves; Owning the manager's authority
It’s been a good week here at RCT world headquarters.
First, our team finally published our paper describing our v1 platform at a high level - a mere 29 months after creating the first version’s Google Doc. The effort tied together years of not just software development and technical architecture but stakeholder engagement, privacy considerations, team building, and domain knowledge. Several co-authors were software developers who had never been on a paper before, were pretty new to the whole process, and hadn’t necessarily appreciated the “full stack” of the effort. It was fun to help them be part of the process not just of writing a paper but of creating a piece of the scientific record of humanity. Knowing they’ll be able to walk into many University libraries all over the world, for decades, and find a copy of it in the stacks, with their name on it, with authorship and citation records kept basically in perpetuity, is pretty cool.
Secondly, on a personal note, I spent some time at an arm HPC hackathon, which was both exciting (new tech! With many different systems to play with!) and surprising (Oracle’s cloud seems… pretty ok?). But more importantly it was really rewarding to see that after a probably eight year hiatus from day-to-day performance tuning of HPC codes, some of the names and tools may have changed, but a basic understanding of the tradeoffs at play and the techniques used to balance between those tradeoffs translate unscathed and can be put to use immediately. These are fundamental skills.
Both of these events drive home to me the breadth and depth of expertise we have in our profession, and how important it is for us to apply it.
And both breadth and depth are needed. Tech just learned a very expensive lesson with the Zillow Offers fiasco that we in research have known for a while - it turns out you need to have some domain expertise as well as technical expertise. It’s not just enough to know how to code or to run a computing system or manage a database; that needs to be paired with understanding of why the software or system is being used, or what valid data looks like in a field. And the problems we’re dealing with are subtle - they require deep understanding of the domains we straddle in our work.
What continues to baffle me is that while the nature and importance of the expertise we bring to bear on research problems is being increasingly appreciated in the rest of academia - and elsewhere, as the burgeoning job board indicates - too many of our own teams continue to underplay it. Groups underbid on projects, are timid in proposals, and try to be a little bit of everything to everyone instead of understanding and playing to their strengths. Teams discussing cloud computing in research computing continue to emphasize first and foremost arguments like “we’re cheaper”, and “we don’t pay inflated tech salaries” as if being the bargain-basement discount brand is our natural lot, or as if us scandalously underpaying our staff is a feature instead of a bug.
So far this newsletter community has helped at least one reader find a new job, helped another couple try new things in managing their teams, and has inspired at least one feature in a software project. We’re just getting started, and there’s a lot more to be done. If you have ideas, or questions, or want to help, just drop me a note at email@example.com.
For now, on to the roundup!
Voice or Veto (Employees’ Role in Hiring Managers) - Ed Batista
A common and avoidable source of frustration when making any high-impact decision - hiring a new team member or manager, but also any major technical or strategic direction - comes from not being clear ahead of time about how the decision is being made and by who. Do the team members get a voice, or a veto? What are the decision criteria?
There’s a lot of perfectly good answers to those questions, many of which the team members (or stakeholders, or..) would be ok with, but not making things explicit right at the beginning can make people feel like they’ve been fooled or not listened to.
Batista councils to be explicit about how important hiring decisions will be made before soliciting input, being clear about how the decision will be made (and by whom), and communicating clearly throughout the process.
Owning your power as a manager - Rachel Hands
Relatedly to being clear about decision making power: one of the common mistakes I see in new managers from the research world is an unwillingness to actually accept the fact that they now have a position of power. This is especially true when the new manager has been promoted to a manager of previous peers.
For a lot of people, suddenly having power is uncomfortable, and that’s ok (it’s way better than the other failure mode, of really relishing the newfound power), but you can’t just ignore it. “Ah but I’m still just the same person, you know?” Yes, you are, but now you can fire someone. And even if you choose not to see that power difference, those someones are exquisitely aware of it.
Hands outlines the role power that comes with being a manager, helpfully and correctly distinguishes it from the relationship power that comes with trust, and points out some specific real problems that come if you don’t acknowledge your power (my favourite: your power manifests in ways you didn’t intend) and what happens when you do.
Source code for a Commodore 64 MMPORG, Habitat.
This week I learned about the Kirkpatrick Model of training assessment - that assessments can be considered in layers from the most superficial (reactions) to increasingly meaningful and harder measures (assessing learning; assessing behaviour changes; and assessing overall results or impact).