#181 - You won’t manage this team forever. What systems and expectations will you leave behind?

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:

• #152, “Feedback is Worked Examples”

• #153, “Work Of vs On The Team: Making Time”

• #154, “Growing Your Work On The Team: Taking Everyday Opportunities”

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 ([email protected]), or even have a quick chat with me about problems you have, or things you’d like to see!

You won’t manage this team forever. What systems and expectations will you leave behind?

My first role as a new leader of a new team started off as a disaster.

I wasn’t sure what I should be doing; I kept running around putting out fires. I didn’t like things being on fire, so as an overthinker perfectionist who didn’t know what else I should be doing, I insisted on being involved in each decision to make sure each decision was The Best Possible choice. And since people weren’t aware of any of the big picture stuff, only the very detailed tasks I had assigned them, more fires were starting every day.

Things were pretty grim. There were bad outcomes all around: the team members were stressed; they didn’t know what they should be doing; they felt disempowered, waiting for me to decide things; and I was super stressed, not feeling like I could step away or focus on bigger picture items.

Our workspace was frenetic with doing, but pretty devoid of accomplishing. And that was starting to become apparent to others. Like stakeholders. Like my boss.

If I were to have left that team then, other than a couple of hiring choices, there’d be very little evidence I had ever been there. There were no clear processes for getting work done. There was no structure in place at all for deciding what work to get done except “What Jonathan says.” No one had clear expectations for each other or for the effort.

I’ve talked to enough of us that I know this is a common position to find ourselves in early on. Our strong preference for collegiality, weirdly, can lead us into this situation where we’re constantly micromanaging and stressed. We worry about setting up stuffy bureaucracy or processes, so we don’t. But without an alternative, things go awry, so we intervene. We then end up too involved, and too reactive, so more things go wrong.

It doesn’t have to be this way.

We’re not just completing tasks, we’re developing a team of humans

People aren’t gears and sprockets, and our job isn’t just making sure that completed widgets are coming off the end of some conveyor line.

As leaders, we’re charged with responsibility for the team, not just the work of the team.

And a real team isn’t just a collection of folks with similar email addresses; they’re people who work together, have expectations of each other, and help each other reach common goals.

For people to be able to rely on each other, there has to be common expectations around work and how it gets done. In other words, there needs to be systems.

Systems help people get their work done

Coming from our background, we tend to recoil at anything that smacks “process” or “bureaucracy” or any top-down mandates about how things get done.

But how did work work when you were in grad school?

• If you worked in a wet lab, were there protocols you followed, or did everyone just YOLO their experiments?

• If you collected data or simulation results, did you just put that stuff wherever you wanted in whatever format you wanted?

• When you wrote papers, did you just kinda guess what should be there and who should be on the paper, and send it off somewhere?

Probably not. And it would have been worse if that was the way things worked, right?

Systems are nothing more than agreed upon known-good practices for getting stuff done, and clear expectations about what done means.

Good systems help people know what to do and what’s expected of them. They let people focus their creativity and intelligence on the things that really matter, instead of “how do I do this again?”

Systems help your team members work smoothly together

Our team members are work together on things. A team member’s work that’s not meeting expectations — because it’s late, because it’s poor quality, because it’s incomplete, because steps were missing — starts causing resentment.

But how is a team member supposed to know what “late” means, what quality standards are, what done looks like, if that’s not documented anywhere? Whether it’s a new team member being onboarded, or an experienced team member trying their hand at a new part of the team’s work, how are they supposed to get up to speed?

Systems — especially systems the team helped build and that are owned by the team — help encode team members expectations of each other. They add clarity and transparency, and make the team more resilient to someone being on vacation or someone needing to take on a new task.

It’s actually easier to change and adapt a documented system than one that’s just vibes

A common worry in our community is that systems become ossified bureaucracy, and start stifling work instead of assisting work. It doesn’t need to, and shouldn’t be that way.

If the processes are locked up in people’s heads — “Bill and Jane are the ones who usually do this, they know how it’s done” — it’s much more difficult for the process to change. Heck, it’s difficult to even know if Bill and Jane agree on how the work is done.

Systems that are written down and shared with the team can be reviewed and changed when they become out of date. An updatable documented system leads to having routine conversations around improving the process, which is pretty much the opposite of them being diktats from on high. Suggestions for change should be encouraged, and discussed frequently (and the change process itself is a system!)

Start with your own work

Getting started with systems is straightforward! Modest, incremental progress is not only easy but the best way to get started.

We’ve talked before about “always be leaving”[reference to past article] — to use every vacation you take as an excuse to think critically about your role in the team, about how the team would look if you stepped away. Now let’s adopt that even when we’re not going anywhere.

One key thing to remember is that you can’t set up a system de nihilo; you can’t systemize something that’s not been done before. You have to try things without a system first, find an approach which works well, then begin codifying it.

You can begin and gain some confidence by starting with processes that only involve you. Something that comes up repeatedly.

You probably already have an informal process to do this- next time it comes up, write down the steps while you do it. This doesn’t have to take much work; we don’t need pages and pages of beautiful prose. Bullet points work great! You can even record yourself and your screen while doing the thing, narrating the process as you go along, and use the transcript as a first draft.

This is already a huge win! You now have a process which you could potentially delegate (in whole or in part) to someone else if you were away or wanted to hand it off to someone else.

Even just having documentation you can refer back to when rusty after not having done it for a while (say a hiring or promotion process, or participating in quarterly reviews) is a win.

The next thing to do is to add text that makes the process safe to change. You don’t want these systems to be commandments carved in stone.

So date the document, and update the date when changed. And make sure the document includes the whys, not just the whats or hows. That means the goals of the process in the first place, why it needs to happen; why one way versus another when available. (This doesn’t have to be complete! You can always add to it later).

Having the when and whys written down makes it much easier to change the document over time. It’s often the case that there’ll be changes in the contexts — new tools become available, organizational changes happen. Knowing why the system was the way it was makes it much safer for people (including you in the future) to know when changes are needed, and justify the changes.

Once you’ve done this a few times you’re already building up a library of systems.

Now pick something together that comes up repeatedly on your team, and co-develop a system

Once you have some experience with setting up (and using) a few processes for yourself, work with the team to prioritize something to have a system around.

Trust me, your team has some ideas! If your team doesn’t have any real systems, there are certainly some commonly-done work steps that there’s unnecessary frustration around.

Bring this up in one-on-ones first to hear some ideas and gain some confidence, telling them it’ll come up in a team meeting.

Then in one of your upcoming team meetings, have as an agenda to prioritize one item to write up a standard operating procedure. You can work on it together in that meeting, or let people think about it a bit and come back to it the next.

There’s a bit of a balance on which item to choose first. On the one hand you want something where there’s a clear need for the clarity and expectation-setting a new system provides; but you don’t want to pick anything too contentious to start with. You want this to be a gentle introduction to co-designing a process. You can start with something as simple as how you run team meetings or prepare for external meetings, something that people often have questions about. Or for a task where new people are constantly being onboarded.

When hashing out a system, include and document the process for making changes. Maybe it’s as simple as making a suggested edit on a document and flagging someone in charge of the process, maybe it has to be an agenda item for a future team meeting, maybe it’s something in between.

Try the process a few times and schedule a time to see how it’s been going (retrospective meetings are awesome).

Even once you’ve been doing this for a while you’ll forget to do this, like I did with intern hiring (#86, The benefits of process). That’s ok! Aiming for perfection isn’t the goal; we’re just trying to continuously make things sustainably better.

Conclusion

Systems provide clarity and predictability for the team, and create a transparent way for them to have a voice in how work is done. By making institutional knowledge explicit, they make onboarding new team members significantly easier and faster. They reduce reliance on the manager for every single piece of information or decision, and create a framework for delegation making it safer and more effective. (Which means you can take less stressful vacations - #175, Helping your team succeed without you).

Starting putting systems in place is a great way to get out of our team members way and make time to work on our managerial gardening (#137) and big picture thinking — making time to work on the team rather than doing the work of the team. (#153, “Work Of vs On The Team: Making Time”; #154, “Growing Your Work On The Team: Taking Everyday Opportunities”)

Are there things holding you back from putting systems in place, or on the other hand things you’ve tried that have worked really well for you and your team? Let me know! Leave a comment or email me ([email protected]).

And now, on to the roundup!

Managing Individuals

The High Cost of Tolerating a Toxic Employee - Jenny Silver, Inside Higher Ed

It’s not super often I see good management articles explicitly written for academics or ex-academics; so when I do see them I try to highlight them.

The problem of tolerating “brilliant jerks” is especially acute in academia, where we tend to overvalue smarts. But the fact is, there’s lots of smart people out there capable of excellence. We shouldn’t tolerate bad behaviour towards our team members, stakeholders, or ourselves. A team member who is behaving badly towards others is not meeting the expectations of the team, and at the very least needs consistent feedback about this.

Don’t let thoughts of “but they perform well” confuse the issue. In our lines of work, teams perform; individuals contribute (#172). If they’re messing up the team, they’re hurting performance.

Silver has a good article describing the problem and some management practices to be consistent about so that these sorts of problems don’t take root:

1. Be crystal clear that behaviour [LJD: towards others] is a vital part of overall job performance.

2. Don’t let problems fester. [LJD: This is crucial. Addressing problems gets harder the longer we put it off]

3. Document—and then document some more.

4. Set the scene for constructive feedback.

5. Reward strong performance for others even if promotion is not on the table.

Using ChatGPT or Claude or local LLMs is a terrific way to practice the sorts of conversations this requires.

The secret to hard performance conversations - Claire Lew

Lew gives us three secrets about challenging feedback conversations:

• Everyone wants redemption - no one likes underperforming (and they likely know they’re under performing)

• The longer you wait, the worse it gets

• Your job is to be helpful [LJD: and to be kind], not to be nice

And urges us to remember these and practice.

Managing Teams

How Great Remote Teams Make Decisions - Marissa Goldberg

The title mentions remote teams. But as with so many other things, remote just amplifies a set of potential problems, it rarely creates new ones. Remote has the huge advantage that it forces us to be more intentional about interactions, and that intentionality is always valuable.

In this article, Goldberg points to some challenges in decision making (including pointing out some advantages of remote and/or asynchronous discussions):

Goldberg recommends focussing on clarity, accountability, and transparency in decision making, especially for remote teams - begin clear about what the process is, who owns the decision, and how and why decisions were made.

1. Establish a clear decision-making framework - Goldberg likes SPADE - Setting (context and scope), People (who owns the decision and who makes input), Alternatives, Decide, then Explain (communicating outwards)

2. Avoid decision paralysis - use time-based discussions, make decisions early if they’re reversible, create pre-mortems (which we’ve discussed here since almost the beginning - #35), and default to action

3. Use asynchronous decision logs describing the decision and reason (which has come up a few times here, and is useful even for learning from your own management decisions - #150)

4. Have a clear communication defaults

5. Increase visibility of the decision by communicating it.

Tying things into the LLM discussion earlier, LLMs can help with decisions a few ways:

• “Brainstorming” - LLMs are great at coming up with lots of options, and one of the ways sub-optimal decisions get made is limiting the number of choices too early on. Try posing the problem and constraints, then asking for a dozen ways to approach a problem, then a dozen more, then a dozen more. Then explain why some of those can’t work - constraints you hadn’t mentioned - then ask for more. (The process forcing you to be explicit what those constraints are is a valuable outcome) Then asking for possible combinations of the ideas above. A lot of the ideas will be bad, some will be quite good, the combinations may be worth more thought, or they may suggest other ideas to you.

• Premortems - again, LLMs can come up with lots of options. When you’ve got some promising ideas, asking for a dozen ways they might fail (and again, being explicit about what is and isn’t likely) can be helpful

• Communications - Getting some early rough drafts of the communications of the decision can save time; you can also ask for likely objections from some key stakeholders and use that to inform your communication.

Managing Your Own Career

One Approach to Beating Conference Stage Fright - Adrian Howard

Seven tips to help you succeed when presenting to executives - Art Petty

At some point we’ll probably get asked to present to important stakeholders, either external (customers, the community) or internal (executives). It’s never too early to get used to this!

We’re used to doing presentations, but an academic presentation is a very different thing. There, we’re presenting to fellow practitioners, experts in the field, trying to do two things:

• Describe our work in enough detail that a practitioner could reproduce it/continue with it

• Demonstrate with tonnes of supporting detail that you’ve done all the work properly and thought of possible confounding effects/errors/ etc.

This is very different from giving a persuasive presentation to a stakeholder!

Further, these are high-stakes presentations, and it’s easy to get nervous.

Howard points out that it can be useful to address the stage-fright aspect of this separately from worrying about the content of the presentation. Gradual exposure, or systematic desensitization, can help a great deal.

Howard’s example is about giving conference talks, but we can do the same thing with stakeholder presentations if we start planning for it. If over some period of time we can get ourselves invited to meetings with the stakeholder, occasionally ask questions, make the occasional comment… then giving the short presentation will be less intimidating.

Petty also suggests having a “cognitive circuit breaker”, something to think or say to yourself or do, to be ready for tense moments so you won’t get overwhelmed in the moment.

The rest of Petty’s article is about the content:

• Align with your sponsor - have multiple discussions with them about what you’ll be saying

• Learn your audience - make sure you understand what the audience wants as individuals (they aren't a monolith)

• Design, test, and tune your message, including a laser-focused core message and three or four key supporting points

• Bring your confidence

• Be enthusiastic if that’s authentic

• Use pictures and diagrams

Again, LLMs can be helpful for brainstorming (what will matter to the audience members, please give me five different ways to say this, what are possible objections), critical review (will this be convincing, is this piece necessary), and practice interacting (a dialogue where the LLM is playing the role of one of the executives who is very skeptical of a point).

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