#147 - Build Buy-In Before The Meeting
Plus: Doing more with less; Aligning strategies; Project retrospectives; Building a relationship with your boss; Your leave document; Behavioural interviews
Hi, all - and Hi to everyone joining from over at Research Computing Teams.
As I get into the rhythm of publishing Manager, Ph.D. material in this new way, it’ll take a little bit for things to settle into a routine. I’m going to aim for Manager, Ph.D. to go out close to the start of the week, shortly after Research Computing Teams at the end of the previous week.
As you’ll see below, there’ll initially be a lot of roundup material from RCT- but there’ll be less and less as I get a sense (guided by your input) for what goes where.
I’ll be depending even more than usual on your feedback to let me know what works, what doesn’t, what might be useful to try. For instance, there’s (public) comments on substack newsletter posts - but there’s also subscriber-only chat, unfortunately only available on the smartphone app. Do either of those seem like they’d be useful? Let me know! Hit reply if you’re reading this by email, or send me an email (or comment!)
Last issue we talked about identifying issues that aren’t entirely in your power to fix because they originate outside the team. Addressing them would take getting number of people to agree on what to do, and chip in to do it.
It was apparently timely; a reader had a problem along those lines, an idea for a solution solution, and a meeting scheduled to discuss it. They asked about next steps.
My advice was pretty simple - build the buy-in before the meeting. This is a lesson that took me an embarrassingly long time to learn, it’s another thing that our research background kind of messes up our instincts about, and the reader hadn’t heard the term “pre-wire” before, so let me share a version of the advice here.
In the world of research, our usual way of operating is that we have a great idea, we go off and do the novel thing, and come back with a more-or-less completed effort which we then show off and get feedback about.
It doesn’t always work out great!
Reviewer #2 hates it for poorly-thought out, knee-jerk reasons. Reviewer #3 wants to like it, but our presentation of the results left out one key piece of the argument that would have made it really easy for them to accept. Reviewer #1 is enthusiastically positive - too much so. Awkwardly, they got the wrong impression about something, and they’re encouraging us to add some text that actually takes the conclusion too far.
Presenting fully-formed proposals to a group of people all at once has well-known drawbacks. Our own presentation of the argument will be imperfect. People don’t deal well with surprises, reacting overly negatively or positively. Some people need some time to think about it.
For some kinds of research work, we’re more or less stuck with the “Ta Da!” model. There’s a variety of reasons why we can’t always show off half of an experiment or 3/4 of a proof or the first few responses from a study.
But this isn’t a research project, and we’re not subject to those constraints.
So for important efforts, we spend some time building buy-in on our ideas by meeting one-on-one with the people involved, showing a rough version of our proposal, getting feedback, making changes accordingly, and then doing another round of discussions. You’ll sometimes hear this called prewiring a meeting, but it’s just making sure you have buy-in well ahead of time.
Like a lot of management, this is a little labour-intensive: it requires some foresight and communications time - but it’s not rocket science. The basic approach is simple:
We make sure we have a clear mental model in our head of what the problem is we’re solving, and why people would care.
We can clearly state our proposal - it doesn’t have to be fully formed (it might even be better if it’s not), but we should be able to describe the big picture and the first few steps.
We talk (not email, talk) with key people - people who would be supporters, blockers, or who would need to contribute; give them a brief overview of what we’re thinking, and ask for their feedback.
We don’t react to that feedback in the moment - we ask a bunch of followup questions and thank them profusely.
Then we process the feedback all at once. We start to put together a new proposal - maybe just an improved version of the original, maybe something quite different - that takes all the feedback into account. The goal here isn’t to make everyone enthusiastic supporters! We want a solid proposal that will work, that shows everyone that we listened, and where we will have at least one champion who will actively support it, and no one who will adamantly oppose.
Repeat once; if it is going to take more than two iterations it may take a re-think.
If this is done successfully, the meeting where the proposal is discussed becomes a place for fine-tuning a decision that’s largely already been made, because we’ve put in the work. People aren’t taking about yes versus no, but “maybe we should also look into X”.
Putting this effort in isn’t easy! But if we’ve done any agile project management work, we know the benefits of delivering and demonstrating a little bit at a time to key clients and decision makers. It helps us get more feedback early on, which lets us know as soon as possible whether we need to go back to the drawing board or where we can start improving. It helps the people we’ve been talking to feel engaged and heard, meaning that even if they aren’t in favour they’re less likely to actively oppose.
Have you seen “prewiring” a meeting work well, for yourself or someone else? Any pitfalls you’re concerned about? What other methods have you used for helping larger groups in your organization move forward on big efforts? Leave a contact or send me an email.
With that, on to the roundup!
Managing Teams
30-60 Days in a New Leadership Role: Run Experiments for Change - Lara Hogan
How to Announce Organizational Change in your First 90 Days - Lara Hogan
As people from the world of research, we’re pretty good at experimentation! We tend to use those skills only on the content of our work, not on the process of work. But being able to come up with a testable hypothesis and an experiment is a real strength, and we can use it well in our work as a manager.
Hogan recommended that the first 30 days in a role are purely about listening and learning, and changing nothing. After doing that, you will have seen a number of things that might be useful to change.
That listening and learning should continue, but now Hogan suggests taking what you’ve learned and crafting two experiments that could be successfully done and evaluated in 2-3 weeks, and rolled back if unsuccessful. That doesn’t rule out thinking about larger changes:
You might be stumped: what if the change you want to make would take longer than 2-3 weeks, or worse, it’s an irreversible change? Think about the process to make this change from start to finish: how can you run an experiment on one of the early steps towards the change?
but as you’re still learning, it’s best to start small and reversibly. Maybe these are obvious potential quick wins, or maybe there’s some urgency to changing something. Either way it’s best to be clear what success looks like ahead of time, communicate that, and try the experiments. Ideally, the results should be publicly available as the experiment is tried.
Once one or even a few of these rounds of experimentation has taken place, it’s time to communicate what you’ve learned, and start thinking about permanent changes. Hogan recommends a pretty thorough communications plan for the change, and I can’t agree enough. I have seen so many ambitions for change stymied by insufficient communication either before, during, or after the change, and sometimes all three. We all tend to have knee-jerk negative reactions to change that will affect how we work, and so that needs to be planned for.
Hogan has a nice list of topics that any change communication will need:
What’s changing (and what’s not)
Who will be affected
The timeline for the change
Why the change is being made - why it matters
Concerns or tradeoffs that you’re acknowledging, and maybe risks you’re mitigating
What you’ll be monitoring as the change happens and afterwards
How to follow up
Doing More With Less (Webinar) - Clare Lew
Our teams of experts are pretty much always small, and often pretty chronically under-resourced compared to what we’d like to accomplish. And yet a lot of the managers I speak with still need help with not trying to do everything.
If we’re going to have the maximum impact with finite resources, we need to be almost monomaniacally focussed on doing the work that makes the biggest difference, and getting really good at it. Doing a little bit of this and a little bit of that won’t cut it. It fails to maximize impact in two different ways - it doesn’t focus the effort where it can do the most good, and it means our team can’t improve and grow as quickly as they can when we’re focussed on one area.
Lew’s talk on this - not just focussing but on scaling that focus - is great. About half the talk is about dealing with the possible morale fallout from a sudden big change like tech layoffs; the rest is evergreen:
Question “More” - do more of the most important things
Framework & Feedback - make sure people know how to think about priorities so they can make the right prioritization decisions autonomously, and give feedback on how they’re doing
Scale the mindset - make sure managers know what is expected of managers, are doing 1:1s, giving and receiving feedback, are communicating the priorities, and are coaching
Project Management
Asking Your Project Team to KISS (Keep/Improve/Start/Stop) - Mark Warner
As you know, just as one-on-ones are key for managing or leading individuals, retrospectives are absolutely key to managing and leading effective teams (#128). Here Warner talks about retrospectives particularly in project work. Constructing lessons-learned documents at project closeouts is part of this, especially if there are other teams that could benefit from what your team has learned, but Warner points out this should be a continuous, ongoing process.
Warner uses the K/I/S/S formulation for brainstorming these sessions, but there’s many such frameworks for getting input, and it can be beneficial to cycle between them to keep the meetings fresh (#53).
Warner emphasizes the importance of documenting what comes up and presenting results, especially on changes made in response to people’s suggestions. This helps make team members feel heard and will encourage more contributions, and so faster improvement in the team’s work.
Warner also lists two other caveats:
Expand the list of participants - for project based work, having stakeholders or clients contribute their input is really important, whether it’s at closeout or separately
Make sure you hear from everyone, not just the loud voices - give others ways to contribute their suggestions
Managing Your Own Career
Building a Great Relationship With Your Boss - Paulo André
We’re often experts, leading a team of experts, managed by someone who isn’t an expert in our area. The good news is that we’re often given a lot of autonomy to run our team’s work as we see fit. But it also means that we can become quite detached from our bosses’ goals and needs, and by extension that of the organization.
It is really important, if we’re going to get the support we need from the larger organization and in particular our boss, to line up our team’s work, at least in part, to support our bosses goals. That means, amongst other things, knowing that they are!
André gives some advice about developing a great relationship with your boss, even if right now you don’t talk to them much. He gives four pretty good questions that we really should know the answers to (and the answers will change over time):
What keeps my manager up at night?
What is success for them now and in the long run?
What pressures are they subject to? Where do they come from?
What do they expect from me? What do they hope to have from me?
How to write a great extended leave document - Ben Balter
In #123 we talked about the usefulness of vacation as a way of practicing delegation if you’re not doing it already. Here Balter shares his template “going on leave” document, a short document that you can keep maintained and then share if you’ll be going away -
Dates
Contact preferences
Points of conteact
Regular meetings
Rolodex
Stuff being worked on
Other important
What else would you keep on this document? Are there other things that could be usefully documented here? Let me know - just hit reply or email me at jonathan@managerphd.com; I think an MPHD template for this could be really useful.
How software engineering behavioral interviews are evaluated at Meta (from an ex-Meta manager) - Lior Neu-ner
Behavioural interviews are underrated in our line of work, where we focus on expertise. But behavioural interview questions are great ways to have people demonstrate how they used that expertise in real situations.
The key for these being useful, however, is to (a) have good and relevant questions that would give some signal as to how candidates might succeed or struggle in the actual job, and (b) to have a good rubric ahead of time, with agreement about what would and wouldn’t be a good answer.
Neu-ner describes how at Meta they ask behaviourial questions to assess motivation, ability to be proactive, ability to take ownership in an ambiguous situtation, perserverence, conflict resolution, empathy, growth, and communication. And crucially they have expectations for junior, senior, and staff-level answers to thees questions.
Not all of this will apply directly to our teams, but I like the breadth of questions here and levelling. One thing I’d add is that you’ll get better answers if you let people know why you’re asking and what you’re looking for - e.g. not just “Tell me about a time when you wanted to change something that was outside of your regular scope of work,” but “Our work here means that people get pulled into a wide variety of work, and so it’s important that our team members are comfortable tackling new challenges. Tell me about a time when you wanted to change something that was outside of your regular scope of work.”
I’ll also add that it can be very useful to share the questions ahead of time - you’ll get better and more relevant answers. The real value in the question is not the immediate answer, but in the followup questions and back and forth as you dig into how they did that thing, and why they decided to do that over something else. If people know the questions, you can go faster straight into the meat of the interview, those followups.
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