#48 - The Stop Doing Something Challenge Part #1 - Start With Yourself
Plus: embedding staff question; nudges; product ownership
Hi!
Happy New Year, everyone. I hope you had some time over the holidays to rest and recuperate. A lot of us have discovered that it wasn’t enough - we’re still dragging - but we’re less tired than before, research needs us and our teams, and so we’re back into it.
An awful lot of early January writing always advocates for people to start something new - develop a new useful habit, start learning a new skill, make time for other important activities.
Those can be great! But we only have so much time in the day, and to add something useful to our routine we have to drop something else, especially with our and our teams energy levels still low. To add a new high priority effort we need to de-prioritize - possibly to zero - something else.
Stopping doing things is difficult, because we’re all smart people and presumably all the things that we used to do that have zero benefit have already been chucked. So we’re left with things that do have some kind of benefit to someone; they all have a justification.
But that doesn’t mean all of the things we do are equally valuable, and the low value things we do - or the things we do that could just as easily (or more easily) be done by someone else - take time away from doing other things that would be better for our clients, our team, and ourselves in the long run.
It’s important to routinely cut these lower value tasks out of our to-dos. Even if we’re used to doing them, even if they don’t take long, even if it’s not that bad or even kind of fun to do them and cross them off the list, even if someone likes that we do them - these are time sucks that take us away from the most useful things we could be doing.
So I want to encourage you and your team to stop doing some things. This month, ideally this week - let’s find something to stop doing and get it off our desk, either by delegating it to someone else (and helping them to drop one or more lower priority things) or, ideally, stopping the activity entirely.
Tasks that aren’t aligned with priorities, or that don’t have significant leverage, can and should be ruthlessly dropped. That can be at the team scale, activities your team as a whole is doing, or at the individual scale, things you are personally doing.
Hopefully you have a pretty good understanding of your team’s or organization’s strategic priorities. What are the things your bosses and stakeholders need, that your team can provide best, and that there aren’t alternatives for? What are the things you can be doing that will enable research to happen that wouldn’t happen otherwise? Are there areas that your team needs to grow - or grow in visibility - to open up the opportunities you see ahead? These are strategic goals, and it’s difficult to make good decisions about what to take on and what to drop without them.
If you don’t have a clear set of strategic goals, there’s no shame in that – I’m working with a team that doesn’t, and am working to help them discover them – but it’s time to start thinking about what they should be. I’ll write more about that later.
As a manager you can also develop a pretty good sense of the leverage of any activity. Anything you do that helps your team execute on future tasks faster, or on new kinds of tasks, is an activity with leverage. Like a lever, it helps your team move rocks they wouldn’t have been able to move before. It helps your team develop develop capacity and capability, and it so is higher priority than doing than any individual task.
Not everything can be top priority, and some low-leverage tasks have to get done. You’ll have a portfolio of activities - as a team, and yourself as an individual - with high and low alignment to strategic priorities, and high and low leverage.
But your team will have more impact, collectively and as individuals, if you as manager routinely drop the low leverage or low-priority tasks in favour of those with align with priorities or have higher leverage. And your team members will have more clarity, and less uncertainty, about what they’re supposed to be accomplishing and how to prioritize their efforts if you are routinely, repetitively clear about why these tasks are being dropped and are consistent about taking on the more important efforts.
High priority tasks should be pretty clear - once you know what your priorities are as a team. What do high leverage tasks look like?
Work spent recruiting and hiring great new team members directly builds the capability and capacity of your team;
Time spent developing your team members skills or your skills as a manager - doing online courses, attending online conferences, knowledge exchange within the team or across teams - also builds capacity and capability;
Delegating tasks to a team member - giving them more responsibility and showing them how to use it - is a form of team member development;
Work spent - continuously - on improving team processes and communications will speed up execution of future tasks and is almost always more valuable than getting any particular task done a little faster;
Time you spend talking individually with team members keeping them on the same page, forestalling conflict or wasted work, can avoid much more lost time down the road;
Similarly, time spent talking with your bosses, stakeholders, or clients to communicate what the team is doing and finding out what they need can avoid even more lost time.
The frustrating thing about these high leverage tasks is they’re not “one-and-done” - keeping people aligned, building people skills, improving team processes are all ongoing processes and take modest amounts of time continuously.
So what does all this mean for you as a research computing team manger?
Almost all of your personal activities can be high-leverage. You’re a multiplier, not a maker, and by virtue of your role you have a lot of responsibility for keeping the team aligned to high priorities, improving team communication and performance, and going back and forth between the team and bosses/clients/stakeholders to make sure you’re working on the right things.
That doesn’t mean you can’t spend any time on more technical duties, but if that same hour could be spent helping your 5-person team be 0.1% more effective this year, that’s one person-hours worth of effort expended that could have produced 10 person-hours worth of benefit.
You’re not the only one who should be performing high-leverage tasks; team members can be encouraged to share knowledge, communicate within and outside the team, contribute to improved team practices, and the like. Supporting them doing that is another high-leverage task for you.
So what am I going to do?
Our team has been pretty ruthlessly focused on our strategic priorities - we’re all about connecting private genomic data, so we’ve avoided non-strategic efforts like model organism or microbial genomics (not private) or building single-node versions (not “connected”). So there’s not much to drop there - but within our activities I haven’t been very good at maintaining focus on the top priorities, letting “nice-to-haves” slow us down on the way to our “need-to-haves”.
But I haven’t been very good at focusing on high-leverage activity. So I’m going to stop:
Writing routine materials. I’ve been responsible for some time in our team for generating some kinds of documents - meeting notes, external communications - because I was the one who had the whole-team picture. That has extended well beyond where it makes sense; it’s actually a problem that I’m the bottleneck and that others aren’t routinely speaking for the team. I’m going to start delegating those tasks, which will take more time to begin with but will save time and strengthen the team over the coming months
Creating common things from scratch. Between processes and templates I’m going to semi-automate a number of things I have to do (some onboarding processes, some emails, etc.)
Attending some meetings, and attending others as often. Most of the meetings I attend are useful and well-run (we’re lucky!) but there are one or two I’m just not needed at and have notes circulated that I could scan afterwards instead; others I should be at but I’m going to advocate for them to be less frequent.
I’m hoping I can continue stopping through the year, and will keep a to-not-do list to make sure they stay stopped. How about you, reader? Is there something you can stop doing or do less of? I’d love to hear from you and share it with the newsletter as an example. As always, just hit reply or email me at jonathan@managerphd.com.
And now, the roundup!
Managing Teams
How to Be an Even Better Leader - Karin Hurt and David Dye
A different kind of new manager checklist: The 4 essential questions to ask yourself as a leader - Claire Lew, Know Your Team
Two short checklists on upping our manager games.
In the first, we’re encouraged to
Slow down and revisit the fundamentals
Teach new managers - for any of us who went to grad school, we’ve probably had the experience of thinking we knew the undergrad material, then really learning it when we were forced to teach it as a TA. Teaching is a powerful way of learning
Learning new techniques yourself first
Letting your team know what you’re working on - to model learning new things, and to be accountable in what you’re trying to learn.
In the second, there’s four questions recommended that we periodically ask ourselves:
How can I create an environment for people to do their best work?
How can I create as much clarity and coherence about what needs to get done, and why?
How can I personally model the behavior I want to see in the team?
How can I see things for what they are, instead of what I want them to be?
I have trouble with the last two in both lists.
Hidden Lenses: What to do when your intention is misread - Padmini Pyapali
Driving Cultural Change Through Software Choices - Camille Fournier
These two articles emphasize the importance of communicating not just the “what”, but (in the first case) the “why” and (in the second) enabling the “how” to make sure what really matters is being communicated.
In Pyapali’s article, we’re reminded that our intention often doesn’t come through in our communications, so it’s important to communicate your intent. Without this, it’s too easy for others to misinterpret your intent, often resulting in hurt feelings - or, more often but maybe worse, misunderstanding the why, so they do the wrong things in the future. If you communicate the “why”, the intent you’re trying to achieve, not only will it help with what you’re communicating at the moment, but it will help your team member be more aligned with what that intention in other activities or decisions they make. This is one of the reasons it’s so important to include mention of impact when giving feedback, whether using the Situation-Behaviour-Impact model or the Manager-Tools model.
Fournier’s article focusses on the importance of “how”s - trying to ensure that doing the right thing is easy. If you want to make sure that developers write tests, make sure there’s a library of existing tests for them to base new tests off of. If you want to make sure that deployments happen quickly, ensure there’s automation which makes that happen. You can communicate the “what” all you like, but making the “how” for doing the right thing easy will have much more impact.
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 expectations.
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.
Product 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 often we’re mainly working on 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 deadlines, roadmap/gantt charts, and execution.
Pereira’s article is a good crash course into that line of thinking. Quan’s emphasizes one particular part of this, and is particularly relevant to the thinking about strategic priorities for the year. You should say yes to new feature requests sparingly; but “no”s don’t have to be negative. You can use your “no”s to align stakeholders to your strategic goals - and to validate those strategic goals to make sure they’re the right ones.
Random
A post-incident review of the events of the movie Home Alone.
Every year technical leader Anil Dash (of Glitch, Stack Overflow, and many other companies in the past) does a personal digital reset - deleting apps, unfollowing all accounts, and then only adding accounts and apps as needed.
Manage your (Chrome) browser tabs as a (in my case, very large) file system.
Love Comic Sans, but thought you spent too much time in the terminal with monospace fonts to be able to make more use of it? Great news.