#95 - 11 Dec 2021
Retrospectives of wins; Diverse teams; Building accountability; Reviewing your year; Milestones, not projects; Grassroots (architecture) decisions
There seems to be something in the air - in the past week I’ve had or heard a number of conversations around leadership and managmement.
Leadership vs management is a fun conversation to have in the same way that “is a hotdog a sandwich” is a fun conversation; it can clarify your own thinking but is unlikely to change too many minds.
Still, I think the basic outlines are clear and well agreed on. Management is a specific set of skills and activities particularly useful in particular jobs — people management especially, but also product or project management. It’s a woefully under-appreciated set of skills and behaviours, especially in academia-adjacent areas, and that means that you you can get significantly better at it than most peers pretty easily. By caring enough about it to subscribe to a newsletter, gentle reader, you’re already comfortably in the top 50%.
Leadership is broader; it is a set of skills that enable getting stuff done when a number of people are required. And almost anything of any import at all requires the contributions of a number of people.
In this newsletter, we tend (naturally) to think of leadership within our teams. That’s good and useful, essential to helping those teams perform effectively. But as we get ready to face the opportunities 2022 brings, it’s worth thinking about external leadership, the leadership that our teams can exert within their organizations.
Leadership is at its most basic a catalyst to getting things done.
This newsletter began because we who come from research can become powerful and insightful leaders and managers, if we’d just give ourselves a chance by learning the basics. Our research background gave us a lot of skills, including being able to look at the big picture and the details simultaneously, and to communicate with colleagues. That helps us get things done in organizations, and see what should be done next.
Managing up, making convincing cases to senior leadership and stakeholders, are important skills not just for our careers but for the betterment of the larger organization and the impact it’s trying to have. Yes, sure, we deserve to have our voices heard, but our organizations deserve to benefit from our insights. So I’ll be spending some time next year writing about how to make sure we have the skills we need to be leaders beyond the scope of our teams.
On that note, this will be the last newsletter of 2021; we’re all super busy to get things wound up before the holidays (which is why, I’m afraid, the last three issues have been late) and to get the new year off to a good start. It’s been terrific hearing from so many of you over the past year, who have taken the time not just to read these newsletters but also to write back. Feel free to let me know what you’d like to see in 2022, anything you’d like changed in the newsletter, questions you’ve been wrestling with, or anything else you care to share. Just drop me a note at firstname.lastname@example.org.
For now, on to the last roundup!
Learning from Success and Failure - Robert I. Sutton, HBR
The end of the year is a time of reflection for teams, and it’s always good to think about how to do this constructively.
This is an old article, but I think timelessly relevant. We tend in retrospectives - either after a sprint or at the end of a year - to focus on and try to learn from the things that didn’t go well. That’s good and useful. But it’s not all we should be learning from.
Sutton reports on research specifically from US Army teams, but the work has been reproduced elsewhere (firefighters, companies including tech companies like Cisco, and more), on retrospectives. Crucially, teams that do retrospectives on both events that went well and that went poorly, and focus equally on both, learn faster and do better.
This makes sense - there’s a million ways things can go poorly, and only a few that can turn out well, and if you squander the opportunity to focus on what went well then you’re throwing out tonnes of useful data.
From one of the papers:
Then, two months later, these same two companies went through two days of navigation exercises. The results showed that, although substantial learning occurred in both groups, soldiers who discussed both successes and failures learned at higher rates than soldiers who discussed just failures. Soldiers in the group that discussed both successes and failures appeared to learn faster because they developed “richer mental models” of their experiences than soldiers who only discussed failures.
Hiring (and Retaining) a Diverse Engineering Team - Gergely Orsoz, Sarah Wells, Samuel Adjei, Franziska Hauck, Uma Chingunde, Gabrielle Tang, and Colin Howe
Hiring a diverse team, especially in research computing, is not the default. As empirical evidence, I offer… *gestures widely*. Therefore, default processes won’t get you there.
With that the case, and because there’s moral and effectiveness imperatives to making sure you’re not excluding good candidates from opportunities on your team, then you need to change how the processes play out, which means change management. And the thing about change management - like anything in management, really - is that it requires sustained effort and attention to the basics.
In this post, Orsoz hands the keyboard over to six leaders who have built successful and diverse teams. Their stories aren’t easily summarized, and many of them apply to larger organizations than our own (although could easily be adopted by our institutions), but the basic idea of having a goal, making sure the steps you are taking are consistent with that goal, and maintaining that sustained effort are key.
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 accountability within your team:
Lead by example, holding yourself accountable first (honestly, a lot of research computing team leads and managers I’ve seen are quite good at this, probably better than in other sectors)
Set team goals (also generally pretty good)
Give good feedback (this is where things get dicier)
Create a culture of two-way feedback - to you, and to fellow team members (dicier still)
Make accountability a habit
Keep track of your commitments, holding each other acountable
Use an accountability framework so you know who’s responsibile for what
Managing Your Own Career
How To Do an Annual Reflection to Get The Most Out Of The Year Ahead - Ashley Janssen
Your Calendar = Your Priorities - John Cutler
As with reflecting back on the work of your team, the end of the year is a good time to reflect back on what you personally have seen and done. But while we know to do this in a structured way with our team, it can be easy to turn self-reflection into a lazy rehashing the same old events. Janssen suggests a more structured approach - actually collecting information from your calendar, email, plans/goals/reviews, and what have you over the past year, evaluating what actually matters, and viewing them through some questions you care about. You can then use that processed information to make some concrete goals, instead of just ruminating and vowing that next year will be different.
Maybe most importantly, Janssen councils to do that with some kindness to yourself - it’s been quite a year.
Going a little more specifically, Cutler points out that our scarcest resource is time. There’s a saying in policy circles “Show me your budget and I’ll tell you what your priorities/values are”; in research computing managerial work, where our budget is typically pretty constrained, it’s our time which reflects our implicit priorities. Those implicit priorities may not be what they should be! Looking at your calendar (and making sure your calendar reflects what you actually do - e.g. blocking off time for working on things) is one of the most powerful tools you have to make sure your effort is being focussed where it should be.
Great engineering teams focus on milestones instead of projects - Jade Rubick
Scatter-Gather - Tim Ottinger
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 terms of milestones which are small, high-quality (e.g. not proofs of concepts), understandable, and independently valuable. His definition of milestone might a bit smaller (1-3 weeks) than makes sense in our line of work, but even 1-2 month milestones, when something can be delivered (whether it’s information or working integrated code) can be a really useful transition from focussing on the requirements of any given project to building a long-lasting product.
Ottinger focusses on a different problem with long-lived projects - work gets farmed out “scatter-gather” in a way that is hard to integrate, can lead to silos (“front end” vs “back end”, for example), and its hard for team members to see how their work contributes. Instead, Ottinger recommends a similar approach - delivering output in small unified chunks that involves significant subsets of the team working together.
UBC’s excellent “Data Science, a First Introduction” course Jupyter notebooks are now up on Binder, and so are interactive.
On the bioinformatics/comp bio side, materials for a comprehensive looking course from Harvard is online.
Sadly, because I’ve sent this newsletter out late, you may have missed your chance to see Excel wizards battling it out esports-style on ESPN3 and live on youtube in the Financial Modelling World Cup.