#149 - Get good at the work, then choose a tool
Plus: Selling our jobs in closing calls; we can't make people change their behaviours; encouraging healthy disagreement; your interview answer database; sounding less negative
Inspired by a reader question, my plan this week was to talk about managing small projects. But whenever I’m talking about this with a new researcher-turned-manager one part comes up so often that I want it to have its own post:
Whether it’s project management, organizing one-on-ones, hiring for open reqs, or anything else - don’t start by choosing a tool. The tool is the least important part of the whole thing. Get the work, then the process, right first.
We’re all experts, and while we were growing our expertise we probably grew quite fond of some of the tools we learned or developed. The problems we were wrestling with were tough, and these tools were useful and made solving them easier. They did the job well, we were familiar with them, and after a while there is something of a comfort to using them. “Ah, me and my old, trusty tool can handle this”.
So when we’re thrust into something we’re uncomfortable doing, there’s a natural tendency to find a tool to help us. If we just find the right tool, it will help guide us to the right way of solving the problem.
This doesn’t work.
If someone assigns us some new kind of work, we wouldn’t start by writing down and share a process for doing it. We’d work through it a few times and make sure we understand the tasks, and then start thinking about documenting it.
The work is what’s important.
A good process, which will depend on the work and the team doing it, is there to support the work. It’s a known-good set of steps for these humans in particular to use to successfully perform and coordinate the work.
A good tool is one which supports the process and the team executing it.
We can’t really come up with a good process until we know the work and how the team does it, and we can’t really choose a good tool until we know what the process is.
I say this as someone who’s been there, who has spent two weeks bikeshedding which project tracking tool to use before I knew what projects we were going to be tackling and who was going to be working on them. (I did choose one. We didn’t use it.) If I’m being honest, it was a way of postponing dealing face-on with those more ambiguous, more important, problems. And this is a pattern I see pretty often with other managers from our world.
It seems like a good idea at the time. We know we’re going to be “doing agile”, or reviewing and tracking candidates through a hiring process, or implementing a complex data pipeline, or what have you, so let’s just get a tool that does that and then everything will be easier. But there’s no single agile process (pretty much by definition), and heavens knows there’s no single hiring process or data pipeline framework that works universally well.
If you’re only going to be doing this work once, there’s no point in investing in a choosing a tool; and if you’re going to be doing this many times, get the process right so you can choose a tool that supports exactly that process well. Either way, the work is what matters. The process supports the work, and the tools support the process and the team.
So I always counsel to just start the work. Pay close attention to the steps taken, what does and doesn’t work well, and take lots of notes. Do a retrospective afterwards, even if it’s just you, and figure out some things to try for next time. Then do it again. Get good at the work, and have a repeatable process for doing the work.
Sometimes you do need some kind of tool, even the first few times. Just pick something, knowing full well its fate is to be disposed of after a few uses. My favourite suggestions:
Google/Office doc or sheet: The hardest part of almost all processes is not the technical piece, but the communication and coordination between people. There’s very few communication and coordination processes that can’t be prototyped surprisingly well with a shared document or spreadsheet. The nice thing here is that it’s clearly just a prototype for some later tool, so you won’t get too attached or go down a rabbit hole learning features.
The simplest thing that could possibly work: Maybe there’s a technical part to the work too, and you do need something. Would the obvious “smart” choices for the work take real time to ramp up on for team members, making it a big investment? Then don’t choose something smart - pick the dumbest, clearly hacky and prototype-y thing that could possibly get you started, and use that. Again, the fact that it’s so clearly a placeholder for something more sophisticated later is actually good here.
Whatever most other people in your org are using: Alternately, if it wouldn’t be a huge ramp-up, just pick whatever is the majority choice in your part of the organization. It’s probably not perfect - no tool is - but get started on the work, using the thing that you and the team can ask lots of nearby people about. Decide ahead of time to re-evaluate after some number of iterations of the work, or after some length of time. But for now, focus on learning to do the work well as a team.
The tool exists to serve the process for the work, and you’ll know what your team needs while doing the work better after doing it a few times. We’re experts, and we love debating the pros and cons of our tools. Don't get distracted! Get good at the work, and the right choice will present itself over time.
Does this help? Are there topics you’d like me to cover? Don’t ever hesitate to contact me - leave a comment, or email by hitting reply or at jonathan@managerphd.com.
And now, on to the roundup!
Managing Teams
How to be prepared and authentic on closing calls? - Abhi Shukla
From the research world, we’re kind of famously bad at selling - selling ourselves or our work, selling our company. But as hiring managers, it’s our job to recruit candidates, and that means a bit of selling - especially at the final stage of the process, when we have extended an offer.
Selling certainly sounds icky and uncomfortable, but selling is really just finding genuine matches between what a person wants and what you have to offer. (And if those matches aren’t there, good selling means being honest about that, too. No one wins if you succeed in convincing a candidate to come somewhere they won’t be happy).
Finding those genuine matches means knowing and uncovering what the person actually wants out of a job. What do they find interesting? Where do they want to go in their career? What kind of work environment do they want? Then, the author tells us, you just have to make the honest case that your job offers key pieces of that.
There’s some other good points in here:
Don’t take it personally when people say no (we from research should be used to hearing no, but it still stings)
Candidates want information before accepting an offer and opportunities to showcase their work afterwards, so if your team blogs or gives talks about their work, that’s a huge plus
If there’s a good internal-job-transfer system at your organization, you can de-risk accepting the job offer for them by highlighting that - it makes it easier to say yes if they can move around if they don’t like this particular job.
Dysfunctional without knowing: 5 signs that your team might have a problem - Tobias Mende
Creating Great Psychologically Safe Teams with Sandy Mamoli - Rafiq Gemmail and Sandy Mamoli
A lot of researchers-turned-managers I know (myself included) are a little conflict-avoidant by nature. But airing out disagreements in a healthy and constructive way is crucial to building a well-functioning teams. Mende points out a spiral into silent dysfunction that he’s seen on many teams:
Absence of Trust
Fear of Conflict
Lack of Commitment
Avoidance of Accountability
Inattention to Results
The absence of trust causes the fear of conflict, which in turn means people can’t come to agreements and lack commitment, and so on. Eventually you end up with a group of people each doing their own thing and not really paying attention to overall results - basically not a “team” at all, in any sense. He then points out signs that a team might be at risk of following this path:
People not having disagreements
Disagreements drag on forever without resolution
Decisions happen, but nothing change
No accountability
Disconnection from others, or from the work
Mamoli, in her podcast episode summarized by Gemmail, describes how to build psychological safety on a team to short-circuit this - to allow healthy disagreements and so build trust and shared working understanding. This quote from Mamoli is particularly relevant for some of our teams:
Conflict avoidance can be corrosive, even deadly, causing teams to miss opportunities and needlessly exposing them to risk. Members might recognize hazards but decline to bring them up, perhaps for fear of being seen as throwing a colleague under the bus… No matter how sensitive the issue or how serious the criticism, members must feel free to voice their thoughts openly—though always constructively—and respond to critical input with curiosity, recognizing that it is a crucial step toward a better solution.
A key thing we can do as managers and leaders is model the right behaviour by giving (and receiving!) feedback in a clear, helpful, constructive way, and after that pattern is established encouraging team members to have open conversations between each other.
Managing Individuals
Letting Go - Roy Rapoport
I get a lot of questions of the form “How do I get X to start/stop doing Y?” There are definitely nudges and forms of feedback and approaches that work better than others. But Rapoport’s quote he shares here is really important:
You can’t make people do good work. You can’t stop them from doing bad work. All you can do is share context and enforce consequences.
That’s it.
It’s not our responsibility — it’s not in our power — to fix how other people behave. And we can’t tie ourselves in knots trying to do so. This is true for our team members, and more broadly:
At the time, he was talking about how we deal with direct reports, of course, but I’ve found that this approach is critical to working with reports, bosses, peers, and … everyone we deal with at work. I can give you information. When it’s up to me, I can enforce consequences. Everything else — Everything Else — is up to you.
Managing Your Own Career
Tell me about a time documents - Sally Lait
As manager and leads, there’s lots of reasons why taking notes on what you’ve done, what went well, and what went poorly and what you learned from it, is a good thing. It helps you fight managerial sensory deprivation (#108), notice changes (#34), identify what works and what doesn't, and learn faster.
But there’s another advantage, too. Periodically reviewing what you’ve done and learned from it over the years as a manager and leader, and making sure you have concise ways of describing those in story form, is fantastic interview prep for behavioural “tell me about a time” questions. What’s more, you end up building a library of stories that will be useful throughout your career, whether for interviewing or for illustrating a point.
You don’t necessarily need to know the questions ahead of time - any one story will generally be useful for demonstrating a number of competencies.
Lait describes these “Tell me about a time” documents. She has a great (and long) list of potential prompts that you could use to start building out your own version of this document. If you don’t have a library of notes yet to start with, you can begin one by thinking up and writing down answers to some of these questions. Reviewing these stories before an interview - and making sure you have a story for responsibility and skill requirement in the job posting - is a terrific way to make sure when similar questions come up in the interview, you have good answers to hand. It’s less stressful and the followup discussion will be more interesting.
I’ll make one other note - STARL (situation/task/action/result/lessons), SOAR, and the like are great checklists to make sure you included key things, but they can make for stilted templates for many stories, especially when repeated. Just write the story up in your own words and go back and make sure there’s something there for each letter in whichever acronym you like.
How to Be Less Negative – and Still Be Yourself - David Dye
As experts, we have the tendency to come off as negative sometimes. A lot of how we did professional communication was via critiques of one form or another (paper/grant reviews, raising issues during early versions of papers or talks or..)
To people not from that world, that can come off as pretty negative and discouraging, even when that’s not our intent at all. And that can make people uncomfortable sharing ideas with us.
Dye suggests three pretty simple steps to cast exactly the same conversation (raising possible issues with a new idea) to come off as much less negative, even while we’re saying the same things:
Begin by positively affirming the idea: “Wow, that’s interesting, I hadn’t looked at it that way”, “I appreciate you thinking about how we can save money here”
Present the problems you see as opportunities: “That’s a great idea, here are three things we can do to make sure it succeeds.”
Pay attention to your own reactions during all of this.
Random
Implementing and variations on manager support groups. Would something like that be interesting for our community?
That’s it…
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck in the coming week with your team,
Jonathan