#175 - Helping Your Team Succeed Without You
Plus: Giving the right amount of context; Effective feedback nudges behaviour; We need respectful disagreement; Project management mistakes; Proposing action Debugging management
Manager, Ph.D. is a newsletter and community which helps people from the world of research reach their full potential managing teams and enacting changes. We’ve already developed the advanced skills to be exceptional managers; we just need help with the basics.
If you’re new to the community, drop me a note! Some past issues from the archive which you might be interested in include:
Plus of course the one-on-one and feedback guides.
And whether you’re new to the community or not, feel free to email me, or even have a quick chat with me about problems you have, or things you’d like to see!
Summer is coming, and with it thoughts of vacation.
Taking proper vacation time is important for managers, and we don’t do enough of it. It’s important for two very different reasons.
The first is the obvious one: you personally need to recharge.
Managing is hard work. You’re bouncing between stewarding the technical work of your team, using one set of skills and knowledge, and leading and coaching and encouraging your team members as individuals and collectively, using a completely different set of skills. Done well, even with a lot of experience, it can be both intellectually and emotionally exhausting.
Sure, it can be really satisfying too: watching good work being delivered; seeing a team member develop new capabilities and grow professionally; knowing what’s happening behind the scenes when what used to be a group of individuals starts to come together to solve problems as a team.
But all of the nudges and worries and oversight and assistance and advice and mentoring that made that happen comes at a real cost. We need time away from it — completely away from it — if our jobs are going to be sustainable.
The second is deeply under-appreciated. You need to step away periodically for your team: or more specifically, the team you want them to grow into.
Going away for anything longer than a few days gives us a needed perspective change. It gives us the opportunity to ask some really important questions about what you want your team to look like without you.
Because you won’t be the manager of this team forever.
What systems, what shared expectations, what resources, what priorities do you want to leave behind? Are they in place yet? Is your team poised to keep succeeding without you?
It’s not important that the team make the same decisions you would, or do things the way you personally would. What is important is that the foundations are coming together for them to confidently make principled, defensible decisions and execute on those decisions in a way that are sustainable and likely to succeed. It’s also important that they have existing lines of communications to the other teams and stakeholders that depend on their work so they can get needed input and feedback.
Now, listen. We’re all overachievers here, so reading this, I know full well your tendency is now to try to get everything set up and perfect before your next vacation. That isn’t possible. It’s not necessary. It’s probably not even a good idea.
It’s good for us — for a bunch of reasons! — to take many vacations away from work. We can use those to incrementally try putting the systems and shared expectations in place we think are needed, and learn from how they go. You likely haven’t really much seen your team work without you before, and you aren’t going to know all the right things to have in place without some results from experimentation. You don’t want a bunch of unnecessary deadweight processes, and you don’t want huge gaps either. This is an excellent thing to be doing incrementally over time.
And note that as you start putting some of these things in place, you can use this approach not just for when you’re on vacation, but when you’re busy with other work. You can be using this to delegate — temporarily or permanently, as long as it’s clear — responsibilities while you’re still around to watch how things go and give feedback.
In the newsletter, we’ve covered articles which do great jobs of giving very tactical advice for how to do this:
Always Be Quitting (#70 )
Multitask by doing less - Taking advantage of your upcoming vacation to delegate ( #123 )
Combined, they have great tactical advice:
Understand and document what you and the team are working on
Understand and document current and near-term priorities, and make sure stakeholders are on that same page
Document expectations you have of how work gets done, and how the team works together
Share these documents with the team for feedback well ahead of time, and encourage them to point out things you missed or they think should be otherwise. Be prepared for surprises.
Document things you know that others don’t (you’ll 100% have huge gaps here the first time you do this, we all assume that things we know are common knowledge), and points of contacts for other teams.
Start making sure that there are team members routinely involved in meetings with stakeholders, and debrief them afterwards about what was important that happened in the meeting and what was less relevant
Make sure those stakeholders know to expect questions from the relevant team members
Make it clear what the decision making process is in your absence - which decisions to hold on until you come back, which to make and act on, and how those decisions are to be made
Ask your team to keep a collaborative set of notes. This lets them share information internally, and gives you one briefing document to catch up on
Turn on your Out of Office Alert - directing correspondants to the relevant people
Do not reply to your email or voicemails
Carve out 2 hours in the morning when you get back to get caught up
These are all good pieces of advice.
But what I want you to think about over time as you practice these handoffs are the underlying expectations and systems and priorities you want to inculcate in the team and leave behind in your absence (temporary or, eventually, permanent). Then you can start emphasizing them even when no vacations or absences on the horizon.
Part of growing as a manager is that your team is growing to the point they need you less and less for the day-to-day. Vacations are wonderful opportunities for you to step back and let the team handle things for a bit, and for all of you to learn together from how things go. It’s a testbed (for you and the team) for delegation, it provides growth opportunities for team members individually and collectively, and it’s a way of measuring your team’s progress in coming together.
Speaking of all of this, a heads-up: A few issues from now, I’ll be taking time off of the newsletter for July and a good chunk of August. I’ll be doing something new this time - enough of you are new to the newsletter, and there’s enough of a back catalog of issues now, that I’ll queue up some “best of” issues to go out.
And now, on to the roundup!
Managing Individuals
How I give the right amount of context (in any situation) -
,The context of Kao’s article is managing up, but it applies equally well to any communications with someone at work, whether it’s a team member, your own manager, or someone in an external team.
We all suffer from the curse of knowledge, especially us experts. We have all this information in our head, and unless we stop and think about it, we just kind of assume everyone else has that information too, so we tend to leave stuff out. Or, and just as bad, we’re so deep in the weeds that we’re thinking about a million details and we share them because we’re thinking about them, even though the person we’re talking to doesn’t need to know any of that.
Kao gives some very specific advice about how to provide the right amount of context:
Remind them where you left off.
Be specific about what you need.
Mention if it’s an FYI [or there’s something they need to do]
Avoid being too detailed in the wrong ways, not detailed enough in the right ways. [What are you trying to accomplish with this information, and what details are needed for that]
Consider these variables to give more or fewer details.
Mention your criteria and assumptions.
Aim for the minimum viable backstory.
Main point at the top, context below.
Give a concise answer, then offer to elaborate.
Ask yourself what your manager will likely ask you.
It’s a good article, definitely read it. The way I think about this is: I’m engaging in this communication to accomplish something. Maybe it’s to keep someone updated, to give them a heads-up that something is coming, to ask them to do something, whatever. What context do they need for my mission to be accomplished and for them to be confident and happy with the result?
Zhuo gets right to the heart of what’s important of giving feedback:
Did you give helpful feedback?
The litmus test is simple: did your feedback result in the other person taking action in a way you and they feel good about?
The purpose of feedback isn’t to get something off your chest, or to offer praise or criticism. The purpose is to make the future better in some very concrete way - that they keep doing the awesome thing, or that they know that the way they did something is suboptimal and to change it.
That’s it.
For that to work, we need to be clear and we also need to make sure we’ve offered the feedback in a way that they can absorb it, and at a time when it matters. Critical feedback makes people feel defensive, and so they’re likely to reject feedback. Being thoughtful about how you say things, and making sure you’re also offering (at different times) lots of positive feedback.
Managing Teams
How to build a DOA product: Humane AI Pin founders banned internal criticism - Ron Amadeo, Ars Technica
Conflict -
,Great writeup from Ars, zooming in on the essential element of an NYT story. The Humane AI Pin, was a product which flopped harder than any consumer product I can think of since the Juicero. How did it fail so hard? Well, one way had to be the way that any internal disagreement or criticism of product directions was, it was made VERY clear, completely unwelcome.
When we’re talking about individuals, we talk about feedback and how it’s important. We need to know how we’re doing, and whether we’re meeting expectations. We can’t possibly know everything ahead of time - feedback is a way of offering worked examples (#152) of things going well and poorly. Effective negative feedback requires trust, and it’s often not a lot of fun to receive or offer, but it’s important, and we all deserve to know how we’re doing.
At the team level, team members offering feedback to the team as a whole requires psychological safety. People need to feel safe offering feedback. They need to know that there’ll be no repercussions, sure, but they are also putting themselves out there making these observations - they need to know that it’s worth it. They need to know that such input is valued, and that it’s taken seriously. (That doesn’t mean that every single observation gets acted on; but it does mean that enough things are acted on that they see that team input is valuable).
Retrospectives are a great way to start introducing practices of team feedback into a group - retrospectives are the Management 201 equivalent of one-on-ones (#128). It’s a way to model respectful
Fisher talks a bit more about the respect side of things. For psychological safety to be maintained, there are expectations on the feedback we have to enforce. It has to be respectful, it has to be about the work and not about the person.
Fisher also very usefully distinguishes between cognitive conflict, relationships conflict, process conflict, and goal conflict. It’s important to surface these conflicts early and often! But we have to be mindful of how it’s done. It’s a good article and well worth reading.
Project Leadership
Ten project management mistakes EMs make: Part 1 and Part 2 -
,Poor Communication
Scope Creep
Inadequate Planning
Ignoring Risks
Micromanaging
Lack of Flexibility
Overloading Team Members
Insufficient Stakeholder Engagement
Neglecting Team Development
Poor Time Management
Project management is a systematized way of communicating and coordinating within a group humans to get something successfully finished.
It’s systematized because in decades (arguably centuries or millennia) of trying to get groups of humans to successfully finish things, we’ve seen a set of tediously common way for projects to fail.
And yet, fail they do. Vaughn talks about ways she’s seen technical managers fail to manage projects. This is what I see with STEM PhD managers, too, with only really one small caveats.
We typically don’t do a lot of 3., inadequate planning, (e.g., Action Brings Clarity #174) except when we’ve assumed we already know how the project will go and what could go wrong - so usually when I see inadequate planning, the root cause is some 4., ignoring risks, or not talking to enough people.
Everything else? Applies dead on within our community. We make a plan and get too attached to not just the plan but how it’s done (5, 6); we don’t talk to enough peopler give and get frank feedback (1, 8, and this is almost always what’s going on with 2); we get tunnel vision on the work and don’t see the opportunities to grow our team members (9); and we assume everyone else are capable of what we are (another cause of 9, but also 7 and 10).
Vaughn’s articles describe the issues with these things, how to see if they’re happening, and what to do about them or to avoid them in the first place - strongly recommend.
Managing Your Own Career
Debugging Management - Aviv Ben-Yosef
Ben-Yosef works with executives, and one of the issues he works with them on is the managers below them.
The issues he describes:
Not autonomous enough
Misaligned
Not speaking up
Too hands-on
You don’t trust them
Too techie
Poor risk management
These are a very valuable checklist for you to go through, thinking about how your manager sees you. It’s even a good starting point for a one-on-one with your manager about how you could grow.
But it’s also a good lens through which to think about how your team members are working, and in what directions they might usefully grow.
Ben-Yosef talks about detecting these issues, and some things you can start doing to improving them with your team members; some of them would also be good ways to start working on your own skills in those areas.
Managing Within Organizations
1-measure-3-1 - Anna Shipman, JFDI
Shipman’s article is a good bookend to Kao’s article about the right amount of context to give.
We’re used to giving academic presentations. The purpose of an academic presentation is to get a new idea or result or method accepted by a group of peers into the canon of our field.
We do this by speaking for an hour, delving into the details of what work we did, what others have done in the field, why this matters, and (finally) what the results were. We do it this way so that they could go off and start to reproduce the results if they wanted to, and to demonstrate our grasp of the matter to give us some credibility.
In the context of academic results, that’s fine.
But this is a terrible way to present material if you want decision makers to take action on something. It doesn’t even work for decision makers in academic decisions. Because what we’re trying to achieve is different, and what the listeners care about is different.
People want to know why they should care, what they could do, and what you think they should do.
In Shipman’s very clear and useful article, a really nice formula is given for what to provide:
One problem to solve/opportunity to grasp (1)
A measure of how we will know it’s solved/met - metrics, outcomes, etc (measure)
Three options, of which one may just be “do nothing” (3)
One single recommendation (1)
By all means, come prepared with additional background material. In a presentation, have bonus slides at the end, in a written proposal have appendices or links to the material.
But we’re not trying to prove our smarts here. We’re not trying to teach them how to derive some lemma that we found useful. We’re proposing that something needs to be done, demonstrating we’ve considered a few options, and recommending a single one with some mechanism available to see if it works.
That’s It…
And that’s it for the week! I hope it was useful; Let me know what you thought, or if you have anything you’d like to share with me about how a newsletter or community about management for people like us might be even more valuable. Just email me, leave a comment, reply to this newsletter if you get it in your inbox, or schedule a quick Manager, Ph.D. reader input call.
Have a great weekend, and best of luck in the coming weeks with your team,
Jonathan