#50 -The change management of stopping doing things
Plus: Your star employee just quit; Saying no to stakeholders
Hi, all!
This is the last part of the stop doing things challenge - the change management of actually stopping doing something.
The hardest thing about stopping doing things, of course, isn’t the identifying what things to stop doing, but actually stopping and staying stopped doing them.
There’s really only three major steps to managing any substantial change, whether to something you’re doing or your team is doing - communicating the change, implementing the change, and monitoring the change. For stopping doing something, implementing the change is mostly trivial - just don’t do the things! The other two steps are things that you have to continue doing, until well past the time you feel confident that the change has “taken”.
So for stopping something, the steps will look like:
Communicate individually
Finalize the plan, along with how you will monitor the change
Communicate in a group/publicly
Monitor the change
Repeat communications/monitoring well past the time you think is necessary.
The first phase is to speak individually with each of the people who will be affected by the change - your boss, stakeholders who were making use of what you were doing, and if applicable, team members who were part of doing that thing. The framing is that you have a plan for the coming year, and you’re getting input on the plan. Walk them through a pretty thorough proposal of the change - why you’re doing it, how it will happen, and alternatives for them.
If your research software team is pivoting to more data-science and data-engineering activities, you might explain that this is where the institution needs most support right now, that it aligns with the research strategic plan, and that you’re happy to continue to bolster and support training so that their trainees can take on some of the basic software development your team used to do, or to recommend nearby teams for those tasks.
If your systems team is decommissioning a less-used compute platform with no plans for a replacement, communicate how this will allow the team to focus more on the high-needs area and provide better support there, and suggest alternatives or ways to port the workflow.
If there’s an information-sharing meeting you used to run and coordinate that you’re going to stop doing, offer to help someone else run it, or to set up some other information sharing forum like an email list.
Throughout this conversation, genuinely seek input and feedback. These conversations are a pre-emptive way of saying no to stakeholders, an opportunity to align you and them to the same sets of goals. The input doesn’t necessarily have to be positive, and that’s ok. You’ll find stakeholder problems you hadn’t anticipated, which you can then make plans to mitigate; you’ll find things you thought would be problems that in fact aren’t, so you can make your plan a little simpler. You might also find some people who are just dead-set against what you’re proposing, which you’ll likely have to discuss with your boss.
Having these individual conversations serves three extremely important purposes:
It communicates your intent,
It makes people feel that you’re soliciting their input and take that input seriously, which is vital for trust-building; and
It collects important feedback to improve your plan.
You can greatly improve the effectiveness of these conversations by sending the person you spoke with an email fairly promptly after each conversation, with your notes on what you heard from them in your own words, what steps you’re planning to take based on their input, and asking them to let you know if you’ve missed or misstated anything, or if they have anything to add. This significantly strengthens all of the intent, trust-building and feedback-collection purposes of the conversation.
Depending on how serious some of the objections are, you might have to make nontrivial changes to your plan, in which case a second round of individual communications might be useful to keep them up to date. That also has the huge advantage of showing that you take the feedback you are gathering seriously.
(I’m embarrassed to say that I used to completely skip this step and leapt straight into detailed planning and public announcement of the proposal, which is a completely unnecessarily and unnervingly efficient trust-shredding exercise, to say nothing of being, frankly, arrogant. Pre-wiring the group communication, is an old idea that I first heard from Manager-Tools, and although it sounds a bit obvious in retrospect, it was a revelation.)
Once you’ve gathered the input and updated your plan, the next step is to choose a simple way to monitor that you are in fact stopping doing the thing. The biggest thing you have to worry about is backsliding. People who used to do certain tasks will tend to revert back to what they know, even if they know intellectually your team isn’t doing that any more. “Just this last time”, “I wasn’t doing anything this afternoon anyway”, etc. That goes for you as well as your team members!
A simple way to keep on track is to have some kind of monitoring system, which both communicates that the change is something that matters and sets up a process whereby backslides are visible and so people (maybe you!) are accountable. Metrics don’t have to be hard or technically complicated; you can start by just, even manually, counting the things you care about. You can count the number of data science projects the team is currently working on, and the number of “off-topic” projects, and publish them - watching the numbers track up and down, respectively. You can show the number of jobs on the system to be decommissioned, and watch it trend downwards as decommissioning nears and alternatives are found.
The data can be manually collected, and they can be communicated manually - at your weekly team meetings say; the point isn’t to have a flashy dashboard, the point is to have a simple, visible indicator which is going the right or wrong way.
Once those things are lined up, public announcements and tracking can start. You’ll have to keep communicating, and you’ll have to keep tracking, but with the foundations of individual communication and simple indicators in place, the likelihood of the change taking root and persisting are much greater.
And that’s it! Now off to the roundup.
Managing Teams
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 to move on into other roles. We should be actively helping people prepare to take on more responsibilities, including new roles!
But when a key team member leaves, it can have cascading consequences. Workload goes up, a trusted peer is gone, and remaining team members now feel uncertain about a workplace that previously felt pretty solid.
Markman recommends doing a thoughtful exit interview with the outgoing team member. It’s a valuable opportunity to get perspective of what you and the team can do better, from someone who can afford an extra bit of candour as they leave. It’s also important to assess if they were “shields down” to other opportunities for reasons that we could have influenced.
Then he recommends doubling down on things we should be doing at some level all the time anyway:
One-on-ones with the other team members, to take their pulse, seen how they’re doing;
Focus on the future and the goals of the team, make sure everyone’s aligned on what’s next - make the future seem less uncertain; and
Provide career development opportunities for the remaining team members, not just for them to fill in for the departing team member but for them to grow their own capabilities as individuals.
Key people leaving is one of many bad things that it’s best to have some kind of contingency plans for. I’m thinking of building a list of scenarios like this and emailing/tweeting them out weekly as a desktop planning exercise - helping research computing managers ensure they have plans and playbooks laid out for various contingencies. Catastrophe-as-a-Service sort of thing. Is that something you’d be interested in?
Job Interviews Don’t Work - Farnam Street Blog
Traditional interviews are pretty crummy for identifying good candidates for jobs - we miss too many potentially good matches and let too many potentially poor matches too far along the pipeline, wasting their time and ours. The blog post points out in some detail some of why that is:
Discrimination and Bias
The map is not the territory - how someone performs in the interview isn’t necessarily a reflection of how they’ll perform in the job
Gut feelings aren’t accurate (see the first point)
Experience in the job isn’t the same as expertise in interviewing for the job (see the second point)
We actually know a lot about how to make interviews better; the article suggests:
Structured interviews - Uniform questions
Blind auditions - Separating evaluation of information about/output from the candidate from evaluation of the candidate
Competency-related evaluations - which requires careful thought about what competencies you’re hiring for (is it really important that they have intermediate knowledge in programming language X, or is it more important that they are capable programmers in something, learn quickly, and collaborate well?)
Project Management
How to Manage Multiple Projects at the Same Time - Elizabeth Harrin, Girl’s Guide to PM
Many of us in research computing are managing multiple projects/efforts simultaneously; Harrin’s post reminds us we’re not alone, and that most (59%) of project managers lead 2-5 projects. Typically our projects are part of a program - a portfolio of projects that are complementary to each other - which makes some of the people things easier, in that the teams overlap and see common goals.
The four big areas Harrin sees to keep an eye on are:
Managing your own tasks/priorities across projects
Managing team member’s efforts across the projects - getting people from project A to chip in on project B
Managing the individual projects - having regularly (Harrin has weekly) status update meetings for each project; many of us also have team-wide meetings where we talk about the state of all efforts.
Managing expectations - although this is the same whether you’re managing 1 or 10 projects, there’s just more expectations to manage with 10.
Harrin doesn’t offer any silver bullets for these areas, because there aren’t any, and what works best for you will depend on your preferences and situation.
For managing your own tasks, I keep a weekly priority list by my desk of things to keep an eye on, with categories for “issues” (efforts I have to actively manage) and “monitor” (efforts that are going well and I want to make sure they don’t become issues) to keep myself honest and not neglect the tending to the “monitor” areas.
Similarly, moving people’s efforts across projects is tricky, for us and for them, and again there’s no real silver bullet here, but it helps that our work usually complements each other across different efforts.
Product Management
5 Tips for Saying No To Stakeholders - Roman Pichler
User power, not power users: htop and its design philosophy - Hisham H. Muhammad
You can’t keep focus on your goals and priorities without saying no to requests. We’ve covered articles on this in the roundup before, and alluded to this in the stopping things advice at the beggining of the newsletter, but it’s an important topic! Pichler emphasizes:
Don’t feel bad about saying No
Empathize with the stakeholder
Reframe the conversation - around the problem to solve and the project goals
Don’t rush the decision (but don’t procrastinate saying No, either)
Try to find common ground but don’t split the difference
All of these things are important in both individual and group communication of changes, whether preemptive (“We won’t be doing this any more”) or reactive (“No, I’m afraid we can’t do that.”)
A nice example of this in a software development context is Muhammad’s article on saying no to a feature request for htop (which is a lovely package). htop had a very specific vision, and user requests contrary to that helps clarify the vision if it’s taken as an opportunity to say no, rather than muddying and compromising the vision through indiscriminate yeses. The story in the request is a pretty good illustration of all of five of Pichler’s points.