#49 - Stop Doing Things Challenge #2 - The Team
Plus: pros and cons of decentralized teams; engineering management books
Hi, all:
Most of us are now well and truly back into the swing of things; I hope you and your team are doing well.
Last time we talked about, as a manager, focusing on tasks with leverage (LeadDev also had a good article on leverage this week). Our main jobs are to support our team members and ensure the team works as effectively as possible; we’re principally multipliers, not makers and our tasks should as much as possible reflect that.
What about what the team as a whole is doing? What activities, if any, should the team stop doing? The steps are are straightforward enough, but doing them properly takes some work:
Look at where you want the team to be in a year - opportunities you want to take advantage of, threats you want to avoid.
Look at what the team is doing that is most valuable to your researchers and other stakeholders (funding, etc.)
Start dropping activities that are less valuable and aren’t actively getting the team where you want it to go.
The first, identifying opportunities and threats, is probably something you already have a pretty good idea about. Your boss will also have some ideas about directions to move or more away from, and this should be a conversation you have with them (at least one).
The second, finding out what the team is doing that’s most valuable to your user community, is something you have to go out and talk to your stakeholder and client community about. If you haven’t explicitly asked one of your clients or other stakeholders the question “what are the things we do that are most important and valuable to you” in the last six months or year, you definitely don’t know the answer to this question. I’ve never seen anyone go through this process with their community without being repeatedly surprised.
It’s generally pretty easy to arrange say quarterly one-on-one meetings with key stakeholders under the (true!) pretence of “status updates”; that gives you the opportunity to tell them what you’re doing that’s relevant to them, but then - more importantly - to ask them questions and advice about what their changing priorities are. For groups you work more closely with you can even do monthly.
If someone won’t take - or have someone else take for them! - a quarterly half-hour meeting with you where you’re telling them what you’re working on for them, that’s a pretty clear signal that the work you’re doing for them is not highly valued, and might not be worth the effort the team is putting in. These are almost certainly activities that can be phased out.
These first two steps are a pretty decent bit of work. They involve talking with a bunch of people - not as a one off, but continuously - and distilling the likely contradictory information down into an understanding of what your most valuable activities are - valuable current activities as seen by your community, or activities that are valuable for the opportunities they will unlock.
But it’s high-leverage work; it’s making sure your teams activities are aligned with needs and activities. The steps above are basically a mini strategic planning process for your team for the next year or so. For longer times and larger organizations it gets bigger and more comprehensive, but the basic approach is recognizable. It’s also a pretty good approach to your first 90 days of a new managerial job, for pretty much the same reasons.
So doing it properly will take some time - setting up and preparing for these meetings; but it’s really important if you want to make sure that what you and your team are putting all that effort into matters as much as possible.
The third thing is by far the hardest. Once you’ve collected all the data, and distilled it down, your team has to stop doing activities that are low value and not “strategic” (getting your team where you want it to go). The steps here are clear and simple, but a little intimidating, because not everyone is going to be happy:
Communicate with your manager to make sure they’re happy with the direction, if there’s significant changes
Communicate with your team - the why as much as the what
Start communicating with your community about what your team will be focusing on
Start saying no: phase out existing projects
Start preemptively saying no: where possible intervene early in the design stage of new projects to steer them in directions that make sense for your team, or talk about why you won’t be taking this project on.
This isn’t easy, especially this last part; but without frequently saying no to low value tasks that don’t get your team where it needs to go, you won’t have time to say yes to the tasks that really matter, for research and for your team.
Let me know if you have questions - this stuff isn’t hard, but can be intimidating - or feel free to share with the community some success stories about things that worked for you and your team. Just hit reply, or email me at jonathan@managerphd.com. And now, on to the roundup!
Managing Teams
In Bad Times, Decentralised Firms Outperform Their Rivals - Philippe Aghion and Isabelle Laporte, INSEAD Knowledge
Hold People Accountable (But Keep It Safe) - Dexter Sy, Tech Management Life
Having decision-making centralized can work really well for routine operations - but falls apart in times of rapid change, as the article by Aghion and Lahorte points out, summarizing a paper led by one of the authors including data on companies from ten countries.
Things are always changing rapidly yet we need that same sort of distributed decision making. Our goal is to have the right people on our team, those doing the work hands-on, making as many as possible of the decisions, with us only a “safety check”, making sure those decisions line up with larger-picture priorities and goals (and if not, sending them back to make a new decision, not overriding the decision with one of your own).
The article by Sy talks about how to do that, how to delegate responsibility to team members who have enough task-relevant maturity. This lets them be accountable to you for their decisions and mistakes they make, by creating the environment where they can make mistakes without it being a huge problem, and helps the team members grow in responsibility, confidence, and skills.
Maximizing Developer Effectiveness - Tim Cochran
This is aimed at software developers, but much of it would apply just as easily to other kinds of expert teams. Team members are effective if they’re quickly and frequently getting feedback - did this change work, does this solution meet the requestor’s needs - and not waiting for things or having their day chopped up into little pieces.
That means as managers it’s important to make sure we have the tooling and processes in place to get team members their results quickly, have things ready to show users/stakeholders quickly, and be respectful of their time. Because the pace of research is generally relatively slow and fitful, we tend in research computing not to make this a focus - but team members can only move at the speed of their tools and processes.
Recommended Engineering Management Books - Caitie McCaffrey
McCaffrey has gone from an individual contributor to a director running teams totalling 20 people over the past 3.5 years, and recommends these books, some of which have come up in the newsletter an some which haven’t. McCaffrey covers the books in much more detail, but an overview is:
The Manager’s Path, Camille Fournier - Focussing on the transitions between diferent roles and the mindset changed required
Thanks for the Feedback - Douglas Stone and Sheila Heen - Understanding how (and why) to receive, and implicitly to give, feedback well
The Hard Thing About Hard Things, Ben Horowitz - covers a lot, McCaffrey felt the importance of training your team members really came through
Accelerate, Nicole Forsgren, Jez Humble, Gene Kim - A classic DevOps but also high-performance computing team book
Dare To Lead, Brene Brown - The importance of daring (and vulnerable) leadership
Switch, Chip and Dan Heath - Understanding how to enact change by better understanding people
Atomic Habits, James Clear - How to enact change in yourself by building good habits and breaking bad ones.
Presenting virtually? Here’s a checklist to make it great - Tamsen Webster, The Red Thread
The downside of lacking in-person social cues of an “on-prem” conference is that virtual events, especially long presentations, can be easy to tune out. So presentations should be shorter. But there are other tricks too!
Here well known speaker and speaking coach Webster gives very concrete steps to take to make your virtual presentation as engaging as possible, whether it’s live or prerecorded. Many of the visual tips we’ve all learned by now (although the tip to stand was new to me), but the tips about making the talk sound engaging, and doing a better job of decoupling visuals from the words in the script, are things most of us in research could do better at, and are especially important when you’re “presenting” in one small window on someone’s screen.
Random
An open-source tool similar to Roam Research - linked note-taking - based on GitHub and VSCode; foam.