jonathan@researchcomputingteams.org
All categories: Resources by category
Subcategories: Career Ladders, Data Teams, Documentation/Writing, Interns, Knowledge Sharing, Other, Team organization
Other tags: | Hiring: Other | Managing A Team: Interns |
Intern Onboarding Checklist - Research Computing Teams Here’s a 159 item checklist for onboarding, working with, and off boarding a semester-long intern. A good process will have to adapt itself to the work of your team, but this can be a starting list for your team to modify and evolve. A process that’s documented can be iterated on and improved!
Continue...Other tags: | Becoming A Manager: Delegation | Managing A Team: Other | Becoming A Manager: Coaching |
An Engineering Team where Everyone is a Leader - Gergely Orosz A reader wrote in referencing this article saying that it was useful particularly in the context of a growing research software team supporting multiple projects - providing a structured way to delegate while promoting the team member’s development and responsibility. And it is a great article! The idea is that, rather than as the team leader you run all of the projects in your team, you tap your team members to run them, with...
Continue...Other tags: | Managing A Team: Other | Managing Your Career: Other | Becoming A Manager: Delegation | Strategy: Prioritization |
Scaling yourself as an engineering manager - Sally Lait When our responsibilities grow, we need to grow too. That means focussing on the truly important, not doing the things that simply don’t make the cut of the priority list, getting the help you need. Not discussed in this article, though it’s at least as important, is delegating tasks and efforts you know how to do well and were doing previously to your team members, helping them grow as well. This article also gives some time...
Continue...Other tags: | Hiring: Other | Technical Leadership: Software Development | Managing A Team: Career Ladders | Hiring: Creating a Job Description |
Research Software Engineers - Job Descriptions - Aalto Scientific Computing Group The Scientific Computing group of Aalto University has text for their job descriptions of a simple three-step (RSE1, RSE2, RSE3) progression for software development in their institution. It’s not a formally recognized ladder by HR yet but it guides their hiring decisions. The whole thing is just a few paragraphs long, but it’s very clear and is a lot more than most institutions have. The other internal documents they have on the page are...
Continue...Other tags: | Becoming A Manager: Feedback | Managing A Team: Other |
Tough Love for Managers who Need to Give Feedback - Lara Hogan Stop Softening Tough Feedback - Dane Jensen and Peggy Baumgartner, HBR Both Hogan and Jensen & Baumgartner’s article tell us not to soften our critical feedback. If we’re not frankly telling our team member how they’re not meeting expectations, then how can we possibly expect anything to change? And if we’re not trying to change future outcomes - by learning that the expectation wasn’t reasonable, or by having the team member meet the...
Continue...Other tags: | Strategy: Alignment | Becoming A Manager: Feedback | Managing A Team: Other |
A Manager’s Guide to Holding Your Team Accountable - Dave Bailey A lot of research computing team managers - especially those of us who came up through the research side - aren’t great at holding the team accountable. It’s pretty easy to understand why - the whole idea of being accountable for timeline and scope is a bit of an awkward fit to that world. Something took longer than expected, or someone took a different tack than they had committed to earlier? I mean, it’s...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Feedback | Strategy: Managing Up |
Managers should ask for feedback - CJ Cenizal Cenizal makes what should be an uncontroversial - but relatively uncommonly followed - point that managers should be routinely asking for input on their own behaviours and leadership from their team members. This is much more easily done if there are routine one-on-ones, if the ask for input is also routine (not necessarily every one-on-one, but frequent), and the manager has a habit of demonstrating that they take such input seriously and are comfortable talking about their...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Conflict/Difficult Discussions | Strategy: Alignment |
Don’t Assume Consensus In The Absence of Objection - Candost Dagdeviren Most people don’t like the conflict that comes with disagreement, and people especially don’t like disagreeing with their boss. Not hearing objections, particularly objections to something you’ve said, does not mean there’s no disagreement. It just means there’s no voiced disagreement. So as Dagdeviren points out, you have to go out of your way to elicit disagreement. “What are things that could go wrong with this approach”, “what things does this miss”, “what are...
Continue...Other tags: | Managing A Team: Documentation/Writing | Strategy: Marketing |
Blogging your research: Tips for getting started - Alice Fleerackers, ScholCommBlog Fleerackers’ post is aimed at researchers but works equally well for us in research computing. It starts off with an important point - not every blog post needs to be a 1500 word feature. It could be a summary of a paper or conference session, a Q&A/interview post; anything that makes the audience more informed about your groups work than it was before. The decision for where to blog is normally easier for our...
Continue...Other tags: | Managing A Team: Data Teams | Strategy: Working across an organization | Strategy: Working with Stakeholders | Strategy: Working with Decision Makers |
Ten simple rules for starting (and sustaining) an academic data science initiative - Micaela S. Parker, Arlyn E. Burgess, Philip E. Bourne, PLOS Computational Biology Many research computing centres are trying to figure out how to launch or scale up a data science core facility or research institute. Creating anything new within an organization is a challenge, even when the winds are in your favour. Parker, Burgess, and Bourne offer some very sage advice on not just starting up a data science effort in particular,...
Continue...Ten simple rules for running and managing virtual internships - Johannes Werner, Debora Jeske, PLOS CompBio REU Participation Encourages Students to Pursue Graduate Degrees - Burçin Tamer, Computing Research Association Working effectively with short-term trainees is tough; it takes a lot of additional planning, clarity, and careful communications. Working with virtual staff is tough; it also requires a lot more intentionality around planning, clarity, communications. And so virtual short-term trainees requires all that and more. The good news is that if you have an ongoing...
Continue...Other tags: | Becoming A Manager: Delegation | Managing A Team: Documentation/Writing | Technical Leadership: Other |
A thorough team guide to RFCs - Juan Pablo Buriticá We’ve written before about design documents architectural decision logs (e.g. #33) and using collaboration around documents as a form of asynchronous meeting (e.g. #49). Usually the thinking is that someone in charge has initiated the document. Buriticá writes about team member-initiated requests for comments as a proposal for a change or the creation of something new, which can then go through a comments phase like a PR, and an approval phase where whatever decision making...
Continue...Other tags: | Becoming A Manager: Feedback | Managing A Team: Other |
The lettuce pact: The ultimate hack for giving difficult feedback - Brennan McEachran, Hypercontext If you’re struggling to figure out how to improve your team’s frank but kind feedback to each other, McEachran has a suggestion. Riffing off a discussion from the Radical Candor team, the suggestion is to make things concrete, with a personally embarrassing but minor situation like someone about to give a talk with spinach between their teeth. They clearly have a right to be told, and there’s clearly better and worse...
Continue...Other tags: | Strategy: Making Decisions | Strategy: Working with Stakeholders | Managing A Team: Other |
The Decision-Making Pendulum - Candost Dagdeviren Our Role in Effective Decision Making - Kathy Keating Everyday Decisions, Done Dirt Cheap - Matt Schellhas Dagdeviren talks about the decision-making pendulum, the spectrum of decision-making processes ranging from authority (“Because I said so”), through advice and consent, to consensus decision making (“So say we all”). The processes at the extremes aren’t great for either the teams or the decisions that likely result (I don’t agree with everything Manager-Tools says, but I think they’re 100% right about consensus...
Continue...Data project checklist How should I structure my data team? A look inside HubSpot, Away, M.M. LaFleur, and more A lot of organizations are setting up data science teams - these teams are analogous to other sorts of R&D computing teams, but these efforts are (a) everywhere and (b) involve both a lot more money on the line and a lot less institutional inertia than is the case when we’re setting up or managing an HPC centre. While the answers some organizations come up with...
Continue...Re:Work: Five keys to a successful google team I think this was circulating again because of a new article of something related that Microsoft did ( In a Recent Study, Microsoft Found That the Most Successful Teams Share These 5 Traits ), and it’s not hard to refactor the five traits from one into something that looks like the five factors from the other; these are fairly basic things: Psychological safety: Can we take risks on this team without feeling insecure or embarrassed? Dependability: Can...
Continue...Other tags: | Managing A Team: Other | Technical Leadership: Other |
On being “technical” as an engineering manager, Sean Voisin How technical do you have to be to be a technical manager? I think this blog post has the right answer; ”enough”, where enough will depend on what your team is doing and what your role is on the team. You have to be able to make sure the team’s doing the right work and progressing satisfactorily, but that’s a different kind rather than a different amount of technical knowledge necessary to actually do the work. For us it will require...
Continue...Other tags: | Technical Leadership: Software Development | Managing A Team: Knowledge Sharing |
On Pair Programming, Birgitta Böckeler & Nina Siessegger A great description on the hows and whys of pair programming, a technique I don’t see very often in research software development (though giving how subtle some pieces of what we work on are, it might be useful). There’s two big advantages of pair programming - knowledge transfer/collective code ownership (at least two people know how some piece of code works), and code quality (two people’s input is better than on). (It can have advantages for helping the team learn to work together, but...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Conflict/Difficult Discussions |
The Subtle Signs Your Team Is in Trouble - Rachel Muenz, Laboratory Manager An older article that Laboratory Manager sent around on twitter this week. It’s written in the context of laboratories, but carries over very clearly to research computing teams. They mention two opposite signs to look out for: Lack of conflict/disagreement - I think this is a great one, and easy to overlook. If you have a bunch of technical people in a room and there isn’t some steady level of (healthy, respectful)...
Continue...Other tags: | Technical Leadership: Systems: Other | Technical Leadership: Runbooks | Technical Leadership: Automation | Managing A Team: Documentation/Writing |
Tracking Toil using SRE principles - Eric Harvieux, Google Cloud Blog Writing Runbook Documentation when you’re an SRE - Taylor Barnett, Transposit “Toil is the kind of work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” These two articles came out in the same week, and they work very nicely together. One of the under-appreciated advantages commercial cloud organizations (or other large operations) have at scale isn’t about hardware - it’s that they...
Continue...Jeremy’s Notes on Fast.AI coding style A bracing reminder (ternary operators! 120-character lines!) that there aren’t “correct” coding styles; the purpose is to make sure teams reduce internal barriers to collaboration by picking one style that works for them and sticking with it.
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: One-on-ones |
Building trust — with people and software - Tal Joffe Tal uses technical analogies to management-of-humans concepts. I’m not sure that’s necessarily a good idea! but the basic concepts are important enough that it’s worth trying a lot of different approaches to reach different audiences. Here, he addresses one of the key goals of one-on-ones; building trust with direct reports. The analogy is between say testing your alignment and agreement on a number of topics in one-on-ones with running tests on code bases; in both...
Continue...Other tags: | Technical Leadership: Other | Managing A Team: Other | Strategy: Project Management |
Premortems: The solution to the Preventable Problems Paradox - Shreyas Doshi on Twitter This is a great twitter thread, which I assume is a summary of one of the author’s presentations, giving very specific advice on how to run a pre-mortem before starting a project to identify potential issues before they arise. It’s so easy for people to see potential issues and not say anything; it could be because they’re not comfortable speaking up, but it could just as easily be because they assume someone...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Conflict/Difficult Discussions |
Buster Benson on the art of productive disagreement - Buster Benson, Brian Donohue Why We Need to Disagree - Tim Harford We’ve talked before about the lack of disagreement on a team (especially a technical team!) being a bad sign, and about how Google’s Project Oxygen found that psychological safety (which is very much about being willing to express disagreement) was one of the most characteristic features of successful teams. Tim Harford article emphasizes the importance of disagreement, and points out that some of the...
Continue...Creating a Slack Writing Etiquette Guide for Your Workplace - RC Victorino, Slab This is a great overview on using Slack well in a workspace. Like so much, whether the tool is used effectively or not comes down to setting clear expectations, and it’s our job as manager to set and communicate those expectations. The points the article makes strike me as dead on, although it took me a while to come to these realizations myself (in particular I hate hate hated Slack threads when...
Continue...Other tags: | Technical Leadership: Software Development | Managing A Team: Data Teams |
How to Grow Neat Software Architecture out of Jupyter Notebooks - Guillaume Chevalier This is an older blogpost which just became a recent talk. I’m coming around to the point of view that computational notebooks have real problems - obvious ones like hidden state, and maybe less obvious ones like the structure of notebooks actively discourage reasonable software development practices like unit testing or even version control. People even study this. But in research computing lots of things have problems and we are kind of...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Feedback |
Feeling Recognized at Work May Reduce the Risk of Burnout - Lab Manager The headline says it all; this reports on a study that reports the titled result. There’s a lot going on right now, and your team members are feeling a lot of pressure from a lot of directions - make sure to honestly recognize their work and their accomplishments. And right now, working at anything approaching normal productivity is an accomplishment.
Continue...Other tags: | Working With A Research Community: Communications Tools | Managing A Team: Documentation/Writing | Technical Leadership: Other |
Google’s Technical Writing Courses - Google Some of us, particularly those of us who were trained in engineering departments, got technical writing training — but most of us didn’t, and the training we did get was focussed more on reserach papers (which let’s face it is a terrible model for almost any other form of writing besides research papers). Google has made available two of their internal courses on technical writing. The first course is sort of “Strunk and White for people who work with...
Continue...Other tags: | Technical Leadership: Other | Managing A Team: Documentation/Writing | Working With A Research Community: Communications Tools |
Design Docs, Markdown, and Git - Caitie McCaffrey Azure Sphere Security Services used a Word/Sharepoint workflow for drafting, circulating, refining, and approving design documents wasn’t working, so they trialed a move to using markdown and git for their design documents. It was a success, and here they write up their approach. Not every design document corresponds to just on repository’s worth of code, so they chose to have one single repo for design documents for their organization organization, to support discoverability and large/unconstrained multi-codebase architectural...
Continue...Other tags: | Technical Leadership: Software Development | Technical Leadership: Code Reviews | Managing A Team: Knowledge Sharing |
The Communicative Value of Using Git Well - Jeremy Kun I’ve mentioned before several of Chelsea Troy’s articles on code review as a sort of asynchronous pair programming, with the benefits both of better quality code and knowledge transfer. In this article, Kun talks about crafting code changes into meaningful commits and PRs exactly to enhance that communication and knowledge transfer.
Continue...Other tags: | Becoming A Manager: Other | Managing A Team: Other | Strategy: Working with Decision Makers |
Success Factors in R&D Leadership - Gritzo, Fusfeld, & Carpenter, Research-Technology Management This is a paper from a few years ago which took a look at leadership development data from 47,000 respondents; both managers and those evaluating them, in R&D and outside of R&D, and compared the two. They found - well, it’s hard to read it any other way than R&D managers were generally worse managers than non-R&D managers: When the results were consolidated, R&D managers were rated more favorably than their non-R&D counterparts...
Continue...Other tags: | Managing A Team: Team organization | Managing A Team: Other | Becoming A Manager: Coaching | Becoming A Manager: Feedback |
How to Get Your Team to Challenge Your Ideas - Dave Bailey We’ve talked before about the importance of having your team being comfortable to disagree with you and offer alternative suggestions. One thing I like here is two sets of suggestions, depending on whether you tend towards over- or under-assertiveness: For the typically over-assertive Adopt the question reflex. Aim for balance in hearing everyone speak. Avoid generalization. For the typically under-assertive Over-prepare. Learn some facilitation techniques/helpful phrass Be vulnerable. Confusingly, I tend towards a...
Continue...Other tags: | Managing A Team: Other | Technical Leadership: Other | Becoming A Manager: Other |
The Engineering Manager Event Loop - David Loftesness via Chris Eigner This isn’t new, but I really like the idea: what a generic tech software development manager should be thinking of daily, weekly, and monthly on people, projects, processes, and themselves. It’s not quite right for research computing - thinking about recruiting and hiring on a daily basis is to put it mildly not the regime we’re normally in - but a lot of the other items hold up. What other changes would we have...
Continue...The New Science of Building Great Teams - Alex “Sandy” Pentland, HBR “Bursty” Communication Can Help Remote Teams Thrive Christoph Riedl and Anita Williams Woolley, Behavioural Scientist These two articles circulated independently this week, expressing related ideas about how communication works in high performing teams. The first emphasizes how communication works between team members. It’s worth reading, but two key points: Everyone on the team talks and listens in roughly equal measure, keeping contributions short and sweet. Members connect directly with one another—not just with...
Continue...Other tags: | Technical Leadership: Other | Managing A Team: Other | Becoming A Manager: Meetings | Becoming A Manager: Remote |
Remote brainstorming for regular humans - Bartek Ciszkowski Whiteboarding and brainstorming are harder to do when the team is distributed. Here are some suggestions for Ciszkowski on how to do distributed brainstorming: Do it in ~20 minute chunks with 5 minute breaks Use a simple white boarding tool (Ciszkowski suggests excalidraw which I hadn’t seen before) or even just a screenshared google doc to record responses. That way people can visualize connections between ideas to trigger new ideas. Periodically restate to your objectives to keep...
Continue...Other tags: | Technical Leadership: Software Development | Managing A Team: Knowledge Sharing |
7 practices you should follow for a successful code handover - Nicolas Carlo Programming as Theory Building - Diogo Felix These are interesting articles to read back to back. Nicholas Carlo has his usual pragmatic information about legacy code - in this case, avoiding code becoming legacy code by executing a handoff between an outgoing developer and a new one. The key ones, I think, are: New dev writes the docs, reviewed by old dev Keep old dev engaged Jointly write more tests to share...
Continue...Other tags: | Managing A Team: Team organization | Managing A Team: Data Teams |
Bioinformatics challenges in multidisciplinary research - Mina Ali The reason I prefer to talk about Research Computing as a whole rather than research software development/systems/curated databases/…, or breaking things out into bioinformatics/data science/simulations/… , is that the same issues come up over and over again. We’ve had articles in the roundup before about setting up a data science team in an organization and the challenges of having it be its own thing (and thus isolated) vs having team members scattered and individually embedded (and so...
Continue...Other tags: | Technical Leadership: Software Development | Managing A Team: Other |
Today was a Good Day: The Daily Life of Software Developers - André N. Meyer, Earl T. Barr, Christian Bird, and Thomas Zimmermann Interesting study of how 5,971 software developers spend their day in general, and how they spend it on days they feel were good days and typical days; the idea is that this could be used to help managers have their developers make more good days. It’s an interesting and short read. I walked away with two big points, but there’s others in...
Continue...Other tags: | Becoming A Manager: Coaching | Technical Leadership: Other | Managing A Team: Other |
You Might Not Be Hearing Your Team’s Best Ideas - Michael Parke and Elad N. Sherf, HBR We’ve talked about the importance of disagreement and input before, and how important it is that people feel ok speaking up. This is another article on the topic, and it breaks the steps down into managing what people are saying but also managing the silence, what people aren’t saying, which I think is a useful way to think about things.
Continue...Other tags: | Technical Leadership: Systems: Other | Technical Leadership: Automation | Managing A Team: Documentation/Writing |
The Runbooks Project - Ian Mieli In an effort to help get people started with runbooks for operations, Ian Miele of Container Soltuions has started an opensource set of runbooks, the Open Runbooks Project, starting with their own. Worth checking out as a set of templates, and keeping an eye on as more get added.
Continue...Other tags: | Technical Leadership: Other | Managing A Team: Other | Becoming A Manager: Coaching |
Making Space to Disagree - Meg Douglas Howie I know I keep hammering on this, but it’s such an important topic, and people keep writing good articles about it. In our line of work our team members are generally experts or becoming experts in various areas, and if they’re not comfortable speaking up and disagreeing — with each other, or maybe more importantly, with us — not only are you losing incredibly valuable input, you’re also running the risk of eventually losing them. There’s a...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Managing Individuals |
Active Listening for Managers - Rachel Hands Why you Can’t Just Ask Why - Lorin Hochstein As a manager, learning to be a better active listener - drawing information out of people, helping them reach their own conclusions, digging deeper, restating the speaker’s thoughts in your own words to make sure you understand - is really valuable. It’s a useful skill for talking with your teammates, but also stakeholders and your own manager. And it really helps me to focus on conference calls - when...
Continue...Other tags: | Managing A Team: Documentation/Writing | Working With A Research Community: Communications Tools |
4 ways to improve your writing and communication in your free time - Jessica Thiefels Written communication is remote work super power - Snir David Asynchronous Communication Builds Respect and Trust - Dexter Sy, Tech Management Life A lot of us in research and computing ended up here because we preferred working in math or code over writing. But writing is an incredibly useful skill to hone — it helps us communicate with our team now, and with our stakeholders; and it helps develop our...
Continue...Other tags: | Technical Leadership: Other | Managing A Team: Documentation/Writing |
Design Documents at Google - Malte Ubl Code only says what it does - Marc Brooker Malte Ubl’s article is a nice overview of how design documents are done at Google, and how they are used - to communicate not only an end goal but the why’s - the context, the tradeoffs intentionally made in design, and the alternatives considered. As Marc Brooker’s article points out, code is great and can be “self documenting” at what things actually do, but not why they are done...
Continue...Other tags: | Technical Leadership: Software Development | Managing A Team: Other |
What Predicts Software Developers’ Productivity? - Murphy-Hill, Jaspan, Sadowski, Shepherd, Phillips, Winter, Dolan. Smith & Jorden Transactions on Software Engineering (2019) Interesting paper I just came across: we designed a survey that asked 622 developers across 3 companies about these productivity factors and about self-rated productivity. Our results suggest that the factors that most strongly correlate with self-rated productivity were non-technical factors, such as job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance. Compared to other knowledge workers, our results...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Diversity |
Managing for Neurodiversity - Anjuan Simmons This is a short and useful discussion from an experienced tech manager about managing team members who are expressing behaviours that might suggest neurodivergence: They simply receive information about the world and process it in different ways. In fact, no two people see and respond to the world in the same way. We all need to make accommodations for these differences whether we’re talking about introversion, extraversion, autism, or dyslexia. The thing I like about this article is it...
Continue...Other tags: | Becoming A Manager: Other | Managing A Team: Other |
Don’t Create Chaos - Stay SaaSy How to Lead Decisively when you Don’t Know What’s Next - Karin Hurt and David Dye, Let’s Grow Leaders Making Decisions with Others - Deepak Azad “Great leaders vacuum up chaos” - The Stay SaaSy post uses this as a nice way to describe one really important function of managers. We have to be entropy-fighters, reducing chaos and uncertainty about how a project will go forward, what priorities should be, what are good next steps for a team members...
Continue...Other tags: | Managing A Team: Data Teams | Managing A Team: Team organization | Strategy: Working across an organization |
Collaborating on Research Data Support - Christina Maimone This is a short and useful “what worked well/what was challenging” overview of three initiatives at Northwestern where Research Computing and the Libraries collaborated on research data support. Both entities have a lot of experience and a lot of resources around research data management, and have greater or lesser amounts of reach with different parts of the University community. Even though your research computing team and your library may be quite different, I think there’ll be a...
Continue...Other tags: | Becoming A Manager: Conflict/Difficult Discussions | Managing A Team: Other | Becoming A Manager: Managing Individuals |
Models for conflict resolution – choose the right one for you - Andy Skipper, CTO Craft Leading Through Conflict - Scott D. Hanton, Lab Manager These two articles cover how to deal with conflict in the technical or laboratory workplace, each with several resources to follow up on. (Disagreements are not themselves conflict! Technical people of any field in any team should be cheerfully, respectfully, disagreeing with each other all over the place.) Both start, sensibly, with the fact that conflict comes from somewhere -...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Conflict/Difficult Discussions | Becoming A Manager: Managing Individuals |
Handling difficult conversations - Rachel Hands, Managing Equitable, Effective, Teams As above, difficult conversations don’t get easy, but they do get easier. And once you’re a manager, as Hands says, It’s imperative that you, as a manager, initiate tough conversations when the need arises. There’s no way through but through, though, so Hands recommends identifying what’s making you uncomfortable about having the conversation so as to defuse it a little bit, and then to focus on the (very specific, observable) issue at hand and that...
Continue...Other tags: | Technical Leadership: Other | Working With A Research Community: Communications Tools | Managing A Team: Documentation/Writing |
Drawing good architecture diagrams - Toby W, (UK) National Cyber Security Centre A nice overview of drawing architecture diagrams. The article makes the point that the diagram is about communicating, and if it doesn’t communicate the key points of the system to the readers, then it’s not succeeding. I like this advice: Start with a basic high level concept diagram which provides a summary. Then create separate diagrams that use different lenses to zoom into the various parts of your system. Having multiple diagrams of...
Continue...Other tags: | Managing A Team: Other | Technical Leadership: Other |
7 Ways Leaders Can Ask Better Questions - L. David Marquet One of the things I continue to have trouble with is remembering that as a manager my off-the-cuff remarks can sometimes have an importance given to them way out of proportion than what I had intended. In particular, questions from managers are incredibly powerful, and that cuts both ways - they can help show interest and help you learn things about your team members and their work, or they can cause a flurry of...
Continue...The documentation system - Divio The Divio page is a nice set of pages talking about a systematic way to think about various kinds of documentation - tutorials, explanation, reference, and how-to guides - as documents meeting different needs, along two different axes: when studying vs when working, and providing practical vs theoretical knowledge. For our systems, our software, our curated data sets, really all of the outputs of research computing, we need these kinds of documentation, and it’s not enough to provide one of...
Continue...Other tags: | Technical Leadership: Other | Managing A Team: Documentation/Writing |
Why write ADRs [Architecture Decision Records] - Eli Perkins, GitHub blog We’ve written before on the importance of recording the why’s of architecture decisions. Even the best self-documenting code or infrastructure can only describe how it works, which is different from why it was implemented this way rather than another. Without that context, it’s very difficult to know, when something changes, if the architecture should be reconsidered. Perkins does a good job in a short article describing three good classes of reasons why to write...
Continue...Other tags: | Managing A Team: Other | Strategy: Prioritization |
A simple framework for software engineering management - Andrei Gridnev This post describes a nice simple approach to structuring thinking about software development management; three categories of responsibilities People management - hiring, team member career development, ensuring people are content and engaged with their work Delivery leadership - execution on delivering new work or changes Technical system ownership - maintaining the technical systems under your stewardship and then labelling priority areas under each responsibility with issues - things that need to be changed ok -...
Continue...There’s a big difference between a team and a working group - Tim Leslie The distinguishing feature of a real team is mutual accountability. This 10-word quote nicely summarizes the article. A team isn’t just a collection of individuals with related tasks; it’s a group fo people who feel they can rely on each other’s contributions and hold each other accountable to that. When that is set up and working well, the team is an entity in and of itself. My own managerial style tends...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Managing Individuals |
Simple Burnout Triage - Ben McCormick McCormick suggests one simple question for your team members to make sure they’re not edging towards burnout: If you take the pace & quality of the last 2 months of your life and repeated it again and again, how long would you be able to sustain it? If you get an answer ranging from “I could make this work, but..” to “I can’t go on like this”, then that raises increasingly serious red flags. The only non-worrying answer to...
Continue...Seven technology leadership lessons from TV show writing - Daniel Jarjoura, TLT21 The community has built a lot of analogies between software development and engineering, but engineering isn’t the only discipline where people have to work together to build complex and intricate stuff under tight deadlines and shifting requirements. Jarjoura tells us seven lessons from successful show runners that he believes carry over to computer systems or software development teams They know their show and tell everyone what it is - there’s a common, shared,...
Continue...Data Cleaning IS Analysis, Not Grunt Work - Randy Au, Counting Things Au’s article can be summed up in one pull quote: The act of cleaning data is the act of preferentially transforming data so that your chosen analysis algorithm produces interpretable results. That is also the act of data analysis. Again, professionalism is doing things deliberately. I think we tend to get sloppy about things that are “just” data cleaning or “just” having decent uptime or “just” putting together a script - but these...
Continue...Other tags: | Becoming A Manager: Diversity | Managing A Team: Other |
Do Your Employees Feel Safe Reporting Abuse and Discrimination? - Lily Zheng, HBR If we want to support our employees, especially team members who experience sexism or racism, we need to make sure they have opportunities to report that abuse and discrimination. Although our teams are typically small, we’re often in large institutions which have mechanisms that can help, such as employee assistance plans (EAP), explicit offices for EDI or that handle sexual harassment or racial discrimination complaints, or ombudsman offices. It’s our responsibility to...
Continue...Other tags: | Managing A Team: Documentation/Writing | Technical Leadership: Other |
Getting Big Things Done - Marc Brooker Architecture Decision Records - Upmo Brooker, who leads development on AWS’s Lambda product, writes about his approach to getting big things done and done well; his approach is outlined below: Is it the right solution? Is it the right problem? Engage with the doubters, but don’t let them get you down Meet the stakeholders where they are Build team(s) The builders The stakeholders Be willing to adapt This maps pretty straightforwardly to research computing work too. Key to...
Continue...Other tags: | Managing A Team: Other | Managing A Team: Documentation/Writing |
Write Down Your Team’s Unwritten Rules - Liz Fosslien, Mollie West Duffy It’s very likely that my team is going to grow significantly over the coming months. That’s a huge opportunity but also a challenge - we have a pretty good team culture now and we don’t want to make any unintentional changes to that. In addition, we’ve had a few discussions recently where it’s been clear that expectations I thought were clear - about learning, contributing to others’ work, working hours - were not...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Delegation | Becoming A Manager: Coaching |
End Micromanagement: 6 Signs You’re a Micromanager (And What to Do Instead) - Dara Fontein The Most Important Management Concept You’re Missing: Task Relevant Maturity - Lighthouse Relatedly, one of the big questions new managers have is how much managing is too much - you don’t want to micromange. In research computing the default is to come down on the side of way, way too little managing. These two articles read together I think help clarify things. Fontein’s article outlines common micromanaging signs, and I...
Continue...Other tags: | Becoming A Manager: Feedback | Becoming A Manager: Managing Individuals | Managing A Team: Other |
Say “No” to Triangulated Feedback - Esther Derby This one hits a little close to home this week. Derby’s article talks about the perils of “triangulated” feedback - team member A tells you something about team member B and you bring it to team member B. A team is a group of people who are accountable to each other in working to a common goal. By being a cut-out in these accountability conversations we short circuit these needed conversations, eroding trust, and give ourselves a...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Other | Managing Your Career: Other | Technical Leadership: Other |
Tech Lead Management roles are a trap. - Will Larson When I was asked at my SORSE talk if it was possible to be both lead developer and manager, I replied that anything was possible but it is really, really hard. The most stressed I’ve been in the last couple of years was when I’ve had both significant technical and managerial responsibilities - they are completely different skillsets requiring your mind to be in different kinds of places. Bouncing between the two is definitely playing...
Continue...Other tags: | Managing A Team: Other | Managing Your Career: Productivity |
Productivity Is About Your Systems, Not Your People - Daniel Markovitz It came up in our discussions of some “measuring developer productivity” articles last year that, especially in research, teams are productive, not individuals. And to make teams productive you have to spend time (leveraged!) time of making sure your team processes are working smoothly. That means ensuring good communications, making work visible (we’ve been pushing towards Jira and Confluence - it’s been a slog bug we’re starting to see the benefits) and clarifying communications...
Continue...Other tags: | Becoming A Manager: Diversity | Managing A Team: Other |
Building neuro-diverse team culture Here’s an evolving collection of resources which may be of use to managers to support current or future team members with ADHD, Autism, or Dyslexia.
Continue...Other tags: | Technical Leadership: Code Reviews | Managing A Team: Knowledge Sharing |
Two Kinds of Code Review - Aleksey Kladov This is another good article of a number we’ve seen here on the topic of code review as asynchronous pair programming, a way of sharing knowledge both ways - about the code itself but also about expectations and goals of the team. From the article: “One goal of a review process is good code.” “Another goal of a review is good coders.”
Continue...Other tags: | Becoming A Manager: Offboarding | Managing A Team: Other |
Your Star Employee Just Quit. Will Others Follow - Art Markman, HBR Maintaining a strong team isn’t an activity that ever stops. We need to actively, constantly, be building the team - by supporting team members development and career goals, by giving them new challenges, and by bringing in new team members or developing and keeping an eye on a “bench” of possible candidates. It’s not necessarily indicative of a problem by itself that the member is leaving - it’s good and healthy for people...
Continue...Other tags: | Technical Leadership: Software Development | Technical Leadership: Other | Managing A Team: Other | Becoming A Manager: Other |
Questionable Advice: “How do I feel Worthwhile as a Manager when My People are Doing all the Implementing?” - Charity Majors> The Non-psychopath’s Guide to Managing an Open-source Project - Kode Vicious, ACM Queue Majors’ article is a good reminder for new managers that it’s really hard to recalibrate job satisfaction or the feeling of accomplishment when you’ve moved into management. All you can do is focus on the big, long timeline stuff while still taking joy in the little moments, and make sure that...
Continue...Other tags: | Managing A Team: Documentation/Writing | Working With A Research Community: Communications Tools | Becoming A Manager: Managing Individuals | Managing Your Career: Other |
Writing Is One of the Best Things You Can Invest In, as a Software Engineer. The More Experienced People Become, the More They Tend to Realize This. - Gergely Ortoz Speaking of non-technical skills being underrepresented in technical job descriptions… Communicating well is absolutely essential part of a job in any interdisciplinary endeavour like research computing, and written communication is becoming absolutely vital as teams go remote. That doesn’t necessarily mean particularly good grammar or vocabulary - we’re an international community, many in our community...
Continue...Other tags: | Managing A Team: Other | Managing Your Career: Productivity |
Engineering Productivity Can Be Measured - Just Not How You’d Expect - Antoine Boulanger, OKAY A while ago we had a flurry of “measuring developer productivity” articles, mainly pointing out that the idea was a bit misguided. There’s a management book, “How to Measure Anything”, which I think of as “Error Bars for Business Types”. Fine book as far as that goes; not really for us as an audience. But one point that book made stuck with me - as managers, the purpose of a...
Continue...Developers spend most of their time figuring the system out - Tudor Girba, feenk Writing good code by understanding cognitive load - David Whitney ARCHITECTURE.md - Aleksey Kladov Girba points us to a recent article: Xia, Bao, Lo, Xing, Hassan, & Li (2018), **Measuring Program Comprehension: A Large-Scale Field Study with Professionals*,* IEEE Transactions on Software Engineering that looked at 78 professional developers during over 3000 hours of their work and found that 58% of their time was taken up by comprehending a code base;...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Remote | Becoming A Manager: Conflict/Difficult Discussions |
Virtual “Storming”: How to Work through Tensions with New Teams - Nobl Academy A lot of heist movies have really clear depictions of Tuckman’s four stages of group development. Forming is the initial “the team is brought together” sequence, where a group of individuals comes together for a common (nefarious) purpose. After the initial honeymoon phase, when the hard work begins, comes the Storming phase - the individually brilliant but mismatched group initially has conflicts as they try to figure out how to work together....
Continue...Other tags: | Managing Your Career: Productivity | Technical Leadership: Software Development | Managing A Team: Other |
The SPACE of Developer Productivity - Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, ACM Queue We’ve covered several times the challenges of measuring developer productivity, particularly individual developer productivity. Forsgren et al walk us through recent literature on the subject, disabusing us of some common myths and encouraging us to instead, as managers of developers, keep an eye on the SPACE dimensions of how well our team is doing: Satisfaction and well-being - employee satisfaction, developers having the tools...
Continue...Other tags: | Managing A Team: Documentation/Writing | Working With A Research Community: Communications Tools |
Writing in the Sciences (Coursera Course) - Kristin Sainani Writing is one of those things that many of us got into science or computing to avoid. But written communication, especially to stakeholders and the public, is vital for effective product management in research computing. Sainani has what looks like a pretty good short course on writing for within research communities and to the public: Topics include: principles of good writing, tricks for writing faster and with less anxiety, the format of a scientific manuscript, peer...
Continue...Other tags: | Becoming A Manager: Offboarding | Managing A Team: Documentation/Writing |
Why a Positive Offboarding Experience Matters More Than Ever - NOBL As a rule, people won’t retire from their jobs with you. It’s always good to be prepared for any given team member to leave (make sure everything’s always documented, use one-on-ones to have a good understanding of what everyone’s working on, use techniques like pair programming/PR reviews or talks and demos to disseminate knowledge. The post on NOBL makes the following suggestions: Make sure your off-boarding checklist still makes sense in a post-pandemic world...
Continue...Other tags: | Becoming A Manager: Other | Managing A Team: Other |
What Good Leaders Do When Replacing Bad Leaders - Andrew Blum At some point in your career, you’re going to step into a role as a leader where the previous leader made a hash of it. They weren’t necessarily a bad person or incompetent, but for whatever reason what they were doing wasn’t working. Blum talks about how to manage that transition. A key point for me is an early sentence: Good leaders create a separation between the past and the future. Creating that rupture...
Continue...Other tags: | Managing Your Career: Other | Managing A Team: Documentation/Writing |
Always be quitting - Julio Merino If we knew we were quitting (or just going on a long vacation) in two months, what would we be doing differently at work? Probably documenting a lot more, making sure people were coming to meetings so that they could take our place when we weren’t there, training up people to be able to take over parts of our role for us. But those activities are key and routine parts of being an effective manager or technical leader. Merino...
Continue...Other tags: | Becoming A Manager: Remote | Managing A Team: Other |
Three Core Ideas to Make Remote Work, Work - Cate Huston Huston has been working remote for over five years, and for those of us getting ready to continue working remote for real and without a pandemic driving it, suggests three key approaches: Embrace async. Enable autonomy. Build connection. Crucially, these are all team-enhancers for in person teams, too: Even for team members all going to the same office, meetings can be hard to schedule, unnecessary meetings are bad, and having written documents outlining how...
Continue...Other tags: | Managing Your Career: Other | Managing A Team: Documentation/Writing |
Writing is Networking for Introverts - Byrne Hobart This is an older (2019) article that recently started circulating again, and I really like it. Relationships are a key part of being an effective leader, and for building your career. Trust speeds collaboration, and we trust people we already know and have interacted with. Increase the circle of people who trust you (and you trust) so you can have more effective and frequent collaborations requires building your relationship network. “Networking” has come to sound like a...
Continue...Other tags: | Becoming A Manager: Remote | Technical Leadership: Software Development | Managing A Team: Knowledge Sharing |
Easy Guide to Remote Pair Programming - Adrian Bolboacă, InfoQ Bolboacă walks us through the how and why of remote pair programming, and InfoQ helpfully provides key takeaways (quoted verbatim below): Remote pair programming can be an extremely powerful tool if implemented well, in the context where it fits. You need to assess your current organization, technical context, and the time needed to absorb change before rushing into using remote pair programming. There are useful sets of questions for that. Social programming means learning easier...
Continue...Other tags: | Becoming A Manager: Managing Individuals | Managing A Team: Other | Working With A Research Community: Communications Tools | Managing A Team: Documentation/Writing |
Words Matter: Is Your Digital Communication Style Impacting Your Employees? - Samantha Rae Ayoub, Fellow “We need to talk”. “Fine.” These all messages or responses that would be very uncomfortable for us to receive from our boss; but when things are busy it’s pretty easy for us to communicate in exactly that way with our team members or peers. Your boss (probably) isn’t a jerk, and neither are you, but when we have a lot of things on our mind it’s easy to not pay...
Continue...Other tags: | Becoming A Manager: Offboarding | Managing A Team: Other |
Three ways to lead effectively when you fire somebody - Sarah Milstein, LeadDev If you aren’t communicating effectively with your team, that won’t stop people from thinking and talking about the meaning behind actions; it’ll just encourage that thinking and talking to go somewhere farfetched and ugly, unburdened by facts. We don’t like to talk about firing, and it doesn’t happen often (enough?) in academia or R&D but it does happen; that relative rarity makes it all the more dramatic. Even someone who chooses to...
Continue...Other tags: | Managing A Team: Other | Technical Leadership: Other | Strategy: Change Management |
The culture of process - Cate Huston The defining transition between hobbyist and professional, between someone in research who codes a little or does a bit of sysadminning and running a professional team providing research computing and data services, is that you no longer just focus on mean quality but also variance. You’re no longer trying to just get good results, but consistently good results. That means, painful though it might be, introducing some process. Huston has a few ways to think about process as,...
Continue...Other tags: | Managing A Team: Documentation/Writing | Technical Leadership: Other |
Making World-class Docs Takes Effort - Daniel Stenberg Documentation is incredibly important for a product’s adoption and use - whether the tool is software, data products, systems, or (increasingly) a combination of the three. It takes a lot of work, but that work pays off later with more adoption and less support effort per user. Stenberg highlights what he’s found to be important for documentation: that it be: Stored with the code, for convenience and so updates are kept in sync, but Not generated from...
Continue...What Makes a Good Changelog - Zeno Rocha, Herbert Lui, WorkOS A very pragmatic about documentation for developers. The most important thing about changelogs is that they exist. And the easiest way to ensure that’s done is to have simple, clear, and non-onerous expectations of what they should look like. Rocha and Lui specify: They should be clear In images, highlight changes Spotlight the people behind the product Consistent formatting of versions and dates, and… Teams should dedicate real technical staff time to them
Continue...Other tags: | Technical Leadership: Data Resources | Managing A Team: Documentation/Writing |
Datasheets for Datasets Template - Audrey Beard Datasheets for Datasets - Timnit Gebru et al, arXiv:1803.09010 Beard provides a LaTeX template for Gebru et al’s suggested “Datasheets for Data sets”, a human readable high level description of a dataset - not a data dictionary, but describing the reason the data set exists, how data was collected, what preprocessing/cleaning/labeling was done if any, how or if maintenance will be done, what uses the dataset has been put to, and more.
Continue...Other tags: | Technical Leadership: Code Reviews | Technical Leadership: Software Development | Managing A Team: Other |
Ship / Show / Ask - Rouan Wilsenach We’ve talked about pre-commit vs post-commit reviews in #34 - post-commit being something of an alternative to PR review. Changes that past CI testing get committed, so that developers aren’t blocked by waiting for review, and commits are reviewed later. (Obviously this incentivizes a large test suite!) Wilsenach suggests that you don’t have to have a culture where it’s either/or. In the “Ship/Show/Ask” model, changes can be simply made without review (Ship) or post-commit review (or at...
Continue...Other tags: | Technical Leadership: Software Development | Managing A Team: Other |
Guides for Managers - Software Sustainability Institute This is a resource I hadn’t seen until Better Scientific Software pointed it out - a collection of guides for research software development managers, including starting and improving a community for your product, recruiting a champion or student developers, funding software and developers, and more. The guides are short and come with links to other resources. They take a “focus on the basics” approach that readers of this newsletter would likely appreciate. Overlapping sets of guides for researchers,...
Continue...Other tags: | Managing A Team: Career Ladders | Technical Leadership: Software Development |
Senior level RSE career paths (with an s) - Daniel S. Katz, Kenton McHenry, Jong S. Lee In the spirit of Shmitz et al.’s call for a career path for RCD individual contribitors, Katz, McHenry, and Lee describe a career progression for research software developers, starting with associate, staff, then senior research software engineer (RSE). Then there’s a bit of a step change to Lead, which I think is pretty well described here: Some of these roles can include some mentoring and leadership, and at...
Continue...Other tags: | Becoming A Manager: Delegation | Managing A Team: Other |
Delegation is a superpower - Caitlin Hudon, Lead Dev It’s true! But, superpowers sometimes take some practicing to use effectively. I personally am pretty good at the mechanics of delegating when I think to do it, but too often find myself taking on a responsibility so as not to bother anyone else with it, or because only I can do it (well, yes, if no one else gets a chance to learn how to, I guess I am the only one who can do it)....
Continue...Invisible Output: Measuring the Behind-the-Scenes Work of a People Manager - Samantha Rae Ayoub, Fellow One of the problems of being a manager is that the work we do is pretty invisible. Our teams’ accomplishments are pretty clear, but the work we do to support that can be hard to point out. That means it’s hard to point out to our bosses - but even more importantly, to ourselves - the good work we’re doing, and where we need some support. Ayoub tells us it...
Continue...How to make accountability a core part of your workplace culture - Hiba Amin We’ve talked before about how what makes a team a team, as opposed to just a bunch of people with logins to the same slack, is mutual accountability. Team members job satisfaction is heavily influenced by being able to rely on their fellow team members, and good team members are happy to be able to be relied on. Amin summarizes some areas to focus on to increase the level of mutual...
Continue...Other tags: | Strategy: Project Management | Managing A Team: Data Teams |
Don’t Make Data Scientists Do Scrum - Sophia Yang, Towards Data Science On the one hand, research computing and data projects, especially the intermediate parts between “will this even work” and “put this into production”, often map pretty well to agile approaches - you can’t waterfall your way to research and discovery. On the other hand, both the most uncertain (“Will this approach even work?”) and the most certain (“Let’s install this new cluster”) components are awkward fits to most agile frameworks, even if in...
Continue...Other tags: | Becoming A Manager: Feedback | Managing A Team: Other |
The 3 Ways Leaders Can Create Feedback Culture At Work - LifeLabs LifeLabs has a very short illustrated ebook to view or download - there’s a button to give your email address but you don’t need to do so to look at or download the PDF. (As a general rule I don’t recommend even pretty good resources that end up with you on a mailing list) This ebook talks about the benefits of leading with feedback, and modelling the desired behaviour. The key piece, on...
Continue...Other tags: | Managing A Team: Career Ladders | Technical Leadership: Software Development |
RSE Group Evidence Bank - UK RSE This is an interesting collection of job titles and descriptions from a number of UK RSE groups for job levelling (junior/RSE/senior/head of RSE), soe articles on setting up RSE or data science institutes. Very interesting if you’re thinking of starting an RSE group. Hopefully it continues to grow.
Continue...The Cone Model for Teams’ Support Network - Shy Alter As managers and leaders we develop, and are responsible for, a team, not a list of individuals. A team is a group of people that support each other and hold each other accountable, not just a set of people with similar email addresses who report up to the same manager. And yet an awful lot of management training and writing focuses solely on interactions between the manager and each individual team member. That’s vitally important,...
Continue...Other tags: | Technical Leadership: Systems: Other | Managing A Team: Career Ladders |
Building an SRE Career Progression Framework - Ethan Motion Whether it’s for research software, systems, data management, or data science, a lot of groups are trying to figure out formal or informal career progression pathways for individual contributors. As a manager, you can work with individuals in their one-on-ones to find out where they are interested in and ready to grow, and give them opportunities at that intersection. But how do you start thinking about career progression at the whole-team or multi-team level? Motion describes...
Continue...Other tags: | Becoming A Manager: Diversity | Managing A Team: Other | Technical Leadership: Other | Technical Leadership: Software Development |
The pushback effects of race, ethnicity, gender, and age in code review - Emerson Murphy-Hill, Ciera Jaspan, Carolyn Egelman, Lan Cheng, Comm ACM 2022 When we’re assessing the technical merits of a code contribution, and by extension assessing letters of reference etc about a candidate’s technical merit, we need to be aware of these effects - non-white, non-male, and older colleagues get significantly higher pushback for PRs, controlling for number of lines changed, readability, and other effects.
Continue...Other tags: | Technical Leadership: Systems: Other | Managing A Team: Other | Managing A Team: Documentation/Writing |
Making operational work more visible - Lorin Hochstein In the f-string failure article in software development, I pointed out that log and error handling code was under-reviewed and tested. There’s probably a bigger lesson one can take from that on the undervaluing of supporting or glue or infrastructure work compared to “core” work. And sure enough, one of the huge downsides of operations work is that when everything goes well, it’s invisible. Above, Granda walks us through writing up an incident report and sharing it...
Continue...