jonathan@researchcomputingteams.org
Parent categories: Technical Leadership
Other tags: | Becoming A Manager: Conflict/Difficult Discussions | Becoming A Manager: Feedback | Becoming A Manager: Managing Individuals |
We Have to Have a Talk: A Step-by-Step Checklist for Difficult Conversations - Judy Ringer There’s one thing I’d add as a preamble to this article. If things have advanced to the point with one of our teammates where we’re going to have the sort of conversation we need to brace ourselves for, it is almost always our fault, at least in part. We didn’t have to let things slide this long. Giving consistent feedback about small things, even if uncomfortable, will allow you to...
Continue...Other tags: | Becoming A Manager: Delegation | Becoming A Manager: Managing Individuals |
Create space for others - Will Larson One of the hardest things about a transition to leadership, either on the people-manager or technical-leadership track, is stepping further and further back from directly making contribution and spending more time making room for others, nurturing their contributions, and gathering their input. In this article, Larson describes how that works at the Staff+ Engineer level at large tech companies.
Continue...Other tags: | Becoming A Manager: Delegation | Managing A Team: Documentation/Writing |
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: | Managing A Team: 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: | 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: | Strategy: Project Management |
Get unstuck on your infrastructure choices - Fred Ross A good reminder that there are a lot of perfectly good technical solutions out there and worrying about which one is “the best” probably isn’t worth your time: Decide based on the following criteria: Has your company already standardized on one of these? Use what they do. Do you already have experience on one of them? Use what you know. Do you have a friend or colleague that knows one of them and who will help...
Continue...A Checklist For Evaluating New Technology - Gustav Wengel In a similar vein as the above, a pragmatic way of looking at a possible new tool or technology or even methodology to adopt. The checklist items most relevant to us: Does it solve a problem you’re actually having right now? Is it easily replaced? Can it be evaluated quickly? Is the project/technology popular and well maintained? How mature is it? Can it be maintained? Of all of them, I think “Is it easily replaced” is...
Continue...Other tags: | Working With A Research Community: Communications Tools | Managing A Team: Documentation/Writing |
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: | 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: Systems: Incident Handling |
How to create an incident response playbook - Blake Thorne, Atlassian This is a really good starting point for putting together an incident response playbook, and includes links to Atlassian’s own playbooks and a workshop on incident communication. This is something we’re working on in our own team. We’re not there yet, but we’re getting there. On the other hand, colleagues-of-colleagues of mine were involved in a major incident recently in an organization where there were lots of security policies in place about keys and...
Continue...Other tags: | Managing A Team: 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...Other tags: | 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: | Strategy: Product/Service Management |
Product for Internal Platforms - Camille Fournier This is an article written for tech companies about how easy it is to go off the rails developing the enterally-used tech platform for developers. It holds a lot of lessons for research computing (software, systems, or data) though. The traps you can fall into are the same, because you are developing tools for a small, captive audience. It’s too easy to lose track of what a broad range of “customers” need to succeed: When platform teams build...
Continue...Technical discussions are hard; a few tips](http://gael-varoquaux.info/programming/technical-discussions-are-hard-a-few-tips.html#little-things-that-help) - Gaël Varoquaux The challenges of maintaining community software as seen by a well known neuroscience and machine learning software developer and manager at INRIA. Varoquaux discusses maintainer’s anxiety, contributor’s fatigue, the difficulty of communication. Varoquaux also describes things he’s found that helped: Hear the other: exchange Foster multiway discussions Don’t seek victory Convey ideas well: pedagogy Cater for emotions: tone Give your understanding
Continue...Other tags: | Becoming A Manager: Meetings |
Architecture Jams: a Collaborative Way of Designing Software - Gergely Orosz Proposals and Braintrusts - Nathan Broslawsky These two articles both describe approaches to usefully open up architectural or other proposals to input from a group. The first, an “Architecture Jam”, is sort of half-brainstorming, half-architectural white boarding session; it can work remotely, but is definitely synchronous. The second is more asynchronous - writing up a proposal, and sending it off to a group of people whose job is, explicitly, to improve the proposal. Either...
Continue...Other tags: | Becoming A Manager: Coaching | 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: | 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: 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: | 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 |
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...Other tags: | 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...Never Skip Retros - Tim Casasola, The Overlap In his new newsletter, Casasola argues that one of the most fundamental team meetings you can have are regular restrospectives, because: They disrupt the habit of anticipating the future, They are low hanging fruit, and They put teams on the path to continuously improve. He goes on to suggest tools like Parabol and Fun Retrospetives as tools to help with the retrospective process. This isn’t exclusively a software development (or even computing) practice; it’s widespread in project...
Continue...Other tags: | Strategy: Project Management |
Use a Pre-Mortem to Identify Project Risks Before They Occur - Mike Cohn We’ve talked a lot about the importance of psychological safety in teams - making team members comfortable expressing their opinions, including raising issues. Without that, you’re missing important input and potentially running into foreseeable (and foreseen!) problems. Premortems give explicit encouragement to raise issues. I’ve used these to good effect in some project-kickoff situations - trying to get the team to see obstacles ahead so they can be avoided. With pre-mortems, one...
Continue...Other tags: | Strategy: Prioritization |
Limiting Work In Progress - Daniel Truemper A trap research computing managers fall into fairly frequently (including me) is seeing the big picture, seeing all the things that need to get done, and trying to start them all at once. After all, we know about parallel computing, a wider pipeline can mean higher throughput, right? But human beings don’t work like that. You get more done by diligently limiting the amount of work in progress, which has the advantage that it requires prioritization.
Continue...Other tags: | Managing A Team: Documentation/Writing |
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: | Strategy: Other |
Write Five, Then Synthesize: Good Engineering Strategy Is Boring - Will Larson Focus enable strategy - not only what you’ll be doing, but how you’ll be doing it. Developing a software development strategy for a team allows you to focus on the important parts of each project rather than bikeshedding the same decisions again and again. You can’t develop such a strategy for executing projects if each project is completely different. Larson’s article is an argument in favour of grounding such a strategy in the...
Continue...Other tags: | Managing A Team: Other | Becoming A Manager: Other | Managing Your Career: 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: | Strategy: Product/Service Management |
The 10 Attitudes of Outstanding Product Owners - David Pereira Tactfully rejecting feature requests - Andrew Quan Because of the funding structure of research our training has taught us to think in terms of projects, but in research computing we’re mainly managing products - long lived things that other people use, and don’t typically have clear start or end dates. That means thinking in terms of differentiation, strategy, speeding the learning process, priorities, and alignment, rather than or at least in addition to thinking of...
Continue...Other tags: | Technical Leadership: Software Development |
Managing technical quality in a codebase - Will Larson This article is about the steps in improving code quality over time from an initial messy code base; the idea is marching up a ladder, solving increasingly high-level issues. This is particularly relevant for research software development. Successful research software marches up a technical readiness/maturity ladder from proof of concept to prototype to community use to production research infrastructure. As code marches up that ladder, the tradeoffs change, and the needs for code quality change with...
Continue...SLO — From Nothing to… Production - Ioannis Georgoulas We’ve talked about Service Level Indicators/Objectives/Agreements (SLI/SLO/SLA) in the past as ways to focus operations effort in ways that are visible to users. Service Level here often means “availability” under some specific measure (the indicator) but it could just as easily be a wait time (jobs in the queue, emails awaiting responses, waiting list for training), disk space, or almost anything else (time until a new user successfully runs a nontrivial job?). The indicators are the...
Continue...Other tags: | Technical Leadership: Software Development | 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: | Strategy: Project Management | Strategy: Product/Service Management |
Creating a Risk-Adjusted Backlog - Mike Griffiths Here’s an example of a concept that I think research software development teams probably “get”, if implicitly, more than teams in other environments. Research software development spends much more time further down the technology readiness ladder; we spend a lot more time asking the question “can this even work” than we do “when will this feature ship”. The risks are higher, because most promising research ideas simply don’t pan out. So we spend a lot of time prototyping,...
Continue...Other tags: | Strategy: Project Management |
Estimating your way to success - Rod Begbie, LeadDev Estimating gets a bad rep because our estimates… aren’t very good. The future isn’t knowable! But Begbie reminds us that the purpose of estimation isn’t to get perfect duration predictions but to structure initial conversations about what is to be done and what needs to be done to get there; and then to learn from the estimates to do better the next time. Begbie’s estimation rules are to keep tasks estimated duration between a half and...
Continue...The resilience of mixed seniority engineering teams - Tito Sarrionandia An ongoing if unintended theme of the newsletter is that when managing teams, many useful things - like everything involved in having the team move to distributed work-from-home, giving feedback, having quarterly goal-setting - come down to making things more explicit. That requires a lot of up front work, more documentation, change of processes, and a little more discomfort for the manager initially - but then make a lot of other things better and easier...
Continue...Other tags: | Technical Leadership: Software Development | Technical Leadership: Code Reviews |
Those pesky pull request reviews - Jessica Joy Kerr Can pair programming replace code review? - Jonathan Hall Kerr’s blog post in late March kicked off a series of posts in the software-dev blogosphere on whether we should still be doing pull reviews. There’s too many posts to list here, but these two by RCT roundup regulars, cover much of the range of views. Kerr’s pretty firmly on team get-rid-of-’em. My summary of her argument: There’s a reason why no one likes getting or giving...
Continue...Other tags: | Technical Leadership: Software Development |
Dos and Don’ts of Pair Programming - Study Suggests Togetherness and Expediency for Good Sessions - Bruno Couriol, InfoQ Two Elements of Pair Programming Skill - Franz Zieris, Lutz Prechelt, arXiv:2102.06460 Couriol has a good summary of the work of Zieris and Prechelt on pair programming. That work, which was accepted to ICSE 2021, looks at two features which they claim determines whether pair programming succeeds as a practice: a combination of “togetherness” (whether the pair can successfully establish and maintain a common mental model...
Continue...Other tags: | Strategy: Project Management |
Guiding critical projects without micromanaging - Camille Fournier However, as a senior manager, at some point you can make it harder for your managers to succeed when you give them very little structure to work with. It’s tempting to say “I don’t care how you do any of it as long as it gets done.” But that doesn’t help people figure out what is important to you, so they have to guess at what they share, when, and how. It’s tough to strike a balance...
Continue...Other tags: | Strategy: Project Management |
Focus: assign multiple engineers to the same task - Dawid Ciężarkiewicz We’ve talked here quite a bit - starting way back in #13 - about pull requests as asynchronous pair programming, and the benefits of pair programming - not merely for quality control but for knowledge sharing in both directions. In this thought-provoking article, Ciężarkiewicz argues in favour of routinely having two (or more!) team members assigned to a task, so that rather than a code review at the back - or even before pair...
Continue...Other tags: | Technical Leadership: Software Development |
Software Development Waste - Greg Wilson, It Will Never Work in Theory Software Development Waste - Todd Sedano, Paul Ralph & Cécile Péraire, ICSE 2017 Wilson briefly summarizes a paper by Sedano, Ralph, and Péraire, who looked at eight software development projects at Pivotal, a software development company, for 2 years and five months, interviewed team members, and analyzed retrospectives. They identified nine broad categories of wasted time and/or effort in the projects: Building the wrong feature or product Mismanaging the backlog Having to re-do...
Continue...Other tags: | Managing A Team: 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 |
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...Demo-driven development - Jade Rubick From earlier in the year - Rubick describes his method for introducing stories and planning into software development, by starting with routine demos, backing from that into introduction of user stories by structuring the plans for the next demo, and then from there moving out into routine planning. What’s nice about this is that it keeps the important thing - always be delivering something useful - in the forefront.
Continue...Other tags: | Technical Leadership: Software Development |
Well-researched advice on software team productivity - Ari-Pekka Koponen, Swarmia Management is hard, management of something as complex and ambiguous as software development is especially hard, but that doesn’t mean we don’t know anything. There has been a lot of research on what works for making teams work well, and recently particularly in the area of software development. It doesn’t mean there are cookie-cutter solutions for anything, but we do have good guidelines. Koponen walks us through several well-supported (and in some cases ongoing) reports,...
Continue...Reframing tech debt - Leemay Nassery, Increment A Rubric for Evaluating Team Members’ Contributions to a Maintainable Code Base - Chelsea Troy Once a software product is high enough on the technical readiness ladder - once it’s actually being used by communities - technical debt becomes an issue. The problem isn’t awareness - we all know code should be maintainable and well documented, etc. - the issue is the people systems to support individual developers in deciding to put time into activities that support that....
Continue...Other tags: | Becoming A Manager: Meetings |
A guide to quarterly planning (plus a template) - Nicole Kahansky, Hypercontext Kahansky gives an outline for a quarterly planning meeting. Quarterly is an excellent cadence for planning (and even performance reviews) for a lot of research computing teams; long enough between meetings that meaningful amounts of work can be done, but short enough to be able to react to our always-changing environment and needs. Kahansky outlines a five-point agenda: Retrospective on last quarter Brainstorm on what could be done to make a significant difference...
Continue...Other tags: | Strategy: Product/Service Management |
Great engineering teams focus on milestones instead of projects - Jade Rubick Scatter-Gather - Tim Ottinger One recurring issue with research computing is that we typically get funded for projects, but we’re really building products — tools, outputs, and expertise that will (hopefully) outlast any particular project. For different reasons, Rubick strongly recommends that your team focusses on milestones rather than projects, but this change in focus can help be an intermediate stepping stone between project-based thinking and product-based thinking. He recommends defining progress in...
Continue...The Boring Technology Checklist - Brian Leroux Is the technology you use boring enough? I really like Dan McKinley’s 2015 talk, Choose Boring Technology, especially the bit where he recommends frugally and reluctantly allocating “innovation tokens” to use in part of a solution. Using shiny newness is expensive. It means constantly fighting against the unknown and solving problems you didn’t know you were going to have. It’s swimming upstream. This is especially true in research computing! The researchers are solving a new problem, using a...
Continue...6 ways staff engineers help reach clarity - Alex Ewerlöf Being at the Staff/Principal doesn’t mean knowing everything. Ewerlöf describes a number of other roles they can play in helping people find answers, with “knowing the answer” being probably the least valuable case: The Go-To: you have the answer The Rubber ducky: you’re the coach/mentor that helps them answer their own question The Catalyst: you know the people who have pieces of the answer The Detective: you know how to find the answer The Communicator:...
Continue...Other tags: | Becoming A Manager: Diversity | Managing A Team: 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: | Becoming A Manager: Meetings |
How to run a Retrospective - Chase Seibert Siebert writes this in the context of sprints, but this short and solid how-to for running retrospectives applies to any project. (A sprint is just a a mini-project, after all - it has well-defined objectives, along with a beginning, middle, and end). Siebert probably feels that actually following up on the retrospective is out of scope of an article on how to run the retrospective meeting, which is fair. Don’t take that as a sign that the...
Continue...