#137 - Tending the management garden
Plus: Peer 1:1s; Leader as shock absorber; Get straight to the point
One of the things I wrestle with a bit with the newsletter is trying to cover the range of topics that managers need to think about without being overwhelming.
But we have genuinely challenging jobs, that span a range of concerns. I gave a presentation about this earlier in the year, but I haven’t quite talked about it the same way here.
We have three main areas of concern which we have to make sure we’re paying attention to - the people in our team (individually and collectively), the work output/products our team produces, and the processes by which we operate. All of those need careful tending to, both for the future (nurturing growth and development), performing regular maintenance care, and dealing with occasional urgent matters. And they’re all essential; people firing on all cylinders but held back by incoherent processes and working on the wrong outputs aren’t going to have the impact they could.
I like a gardening metaphor for this, because it reflects the fact that nurturing growth takes sustained effort, where as blight and weeds can spread with shocking quickness if allowed to do so (and takes much more effort to fight back than it does to prevent). It’s also true that if the teams, processes, and products are healthy and vigorous, they can make it hard for a weed to find purchase.
In steady state, we want to be spending most of our time in the top 2/3 of the diagram - nurturing our people and team, maintaining lines of communication, and making sure our work outputs are those that have the most impact. In any given week, we want to make sure we’re spending much of our ongoing work on maintenance efforts across all three columns, and putting some effort into targeted nurturing.
If we’re spending a lot of time putting out weed or blight outbreaks, that’s normally a symptom that there’s not enough maintenance care happening. Sometimes the urgent issues have an external source, of course; we’re being roiled by some outwardly driven change. But more often they’re internal. And the under-maintenance isn’t necessarily coming from the column where the outbreak is happening. The process issue may be an issue of the team not communicating well together, or the problem with product quality may stem from processes.
I spend most of my time writing about the people column, and I think that’s appropriate. People are the area probably least familiar to many of us who were trained in highly technical areas. And strong teams of people can better handle (or fix!) poor processes or work product focus, while excellent processes or products can’t counteract people problems.
In the last year or so I’ve been writing more about products in the sense of strategy - what is the most impactful work we can be doing? What are the most important work products we can be producing, and how do we decide which to drop and which new ones to start on?
Whereas I don’t really write nearly enough about processes. They’re important, even though as researchers and technologists we tend to downplay them.
We shouldn’t be creating process for its own sake, of course. But this isn’t about creation so much as ongoing development, just like people and products.
We have countless unwritten processes in our team, and we can’t really improve them in any meaningful way until we document them. This is just like wet lab protocols; if you haven’t recorded the steps you took, how can anyone reproduce them? How can others be onboarded into doing that work? And how can the processes be incrementally made better, or compared to other approaches?
Process is the mechanism by which craft work becomes professionalized, becomes automatable, becomes something that can be handed off. The first few times your team does something, it’ll still be in the mode of searching for a good way of doing things. Once it’s found an initial good way, that’s something that can be usefully turned into a process, and documented with not just the steps taken, but the goal of that process, and why this way works. Checklists work.
On the technical side, we as a community tend to pretty good about making sure everything’s documented, that there are scripts for automating tasks, etc. But for more people-oriented processes we’re often not great. If we find ourselves saying things like “Francis isn’t here today, and they’re the person who handles that; we’ll have to wait”, that’s a pretty good indication that there are important undocumented processes. It can be a work task, or how meetings are run, but processes bring clarity.
One failure mode is that unless they’re documented alongside why things are done via that process and what a good result is, they can become ossified.
But when that context is included with the processes, and permission is given to try doing things different ways and see if that’s better, then it becomes a key piece of continuous improvement. There are really mature tools for thinking about, developing, maintaining, and updating processes - many come from the world of project management (or program/portfolio management), and we can learn from or use them.
What do you think - are there areas where too little (or too much) process have hindered your team? Are there project management tools or approaches you use for keeping track of multiple processes “in flight” in your team? How do you handle documenting not just factual knowledge but procedural knowledge in your team? Let me know - just hit reply, or email me at jonathan@managerphd.com.
And now, on to the roundup!
Managing Teams
Peer One On Ones: How To Unlock Great Collaboration Across Teams - Lighthouse Blog
One-on-ones are a fundamental tool for developing trusting working relationships with direct reports.
But regular meaningful conversations can always build trust and strengthen lines of communication, regardless of reporting relationship.
Peer one-on-ones are a great and simple way to develop effective professional relationships and communication channels with peers on other teams. Feel free to call them something vague like “check-ins” or “sync-ups” if you prefer.
The Lighthouse blog gives some suggestions - they don’t have to be weekly, for one, even every four weeks or longer is a lot better than nothing. And there’s a great list of possible topics:
What’s one thing we could change about our processes that would help your team?
Is there anything my team does that your team really likes? Why do they like it?
What’s the hardest thing about working with me or my team? Why?
What do I not know about your job that I may have an impact on?
What’s your biggest challenge right now for you and your team?
How can I help make your job easier to do?
Are there any interpersonal issues between anyone on your team and mine I should know about?
What could we do together without having to use much budget or other people to improve things for our teams?
(This is a timely article, because I just advised someone who was having some issues with a peer in a different reporting structure, and who wanted to give them feedback. Feedback works much better if there’s already a working relationship and communications. They will take the feedback more seriously, and you can express the feedback in terms they are more likely to care about, if you’ve already had several working conversations. Since this will be an ongoing working relationship, and the feedback wasn’t time sensitive, I advised starting peer one-on-ones with the colleague, and only after a couple of those raising the issue).
Leader as Shock Absorber - Ed Batista
Maybe a couple of decades ago, the idea of a manager or lead as a “sh*t umbrella” became popular; it probably came from a good place, an urge to protect team members from the vagaries of the larger organization.
There’s a pretty widespread understanding now that this just isn’t a good mental model. It’s infantilizing; it is fundamentally built on a lack of transparency; it models the rest of the organization as an uncontrollable, exogenous, force that randomly produces excrement to be handed down; and if the manager or lead guesses wrong about what the team needs to know, it leads to bad and preventable surprises.
Batista’s analogy of a shock absorber, I think, captures the well-intentioned pieces of the umbrella analogy but without the problems:
A shock absorber cushions the blow; it doesn’t prevent the flow of force but redirects it.
A shock absorber pushes back in both directions
A shock absorber is resilient, not tough.
This plus being a chaos vacuum (#34), reducing chaos and replacing it with clarity, makes for a much healthier picture.
How to stop firefighting and start working proactively - George Sudarkoff
Tying nicely into the management garden discussion, Sudarkov talks about the problems caused by being in constant fire-fighting mode. He also alludes to one of the causes: it feels good and important to be putting out fires, and fire-extinguishing (since it’s so visible) can often be respected and rewarded in a way that running a quietly effective organization too often isn’t.
But fire fighting is exhausting, and it takes energy away from investing time and energy into growth and sustainable development.
Sudarkoff urges us to spend the time to stop fires from happening:
If the fire-fighting is self-inflicted, fix the process problems [LJD: could also be a people problem] lighting the fires
If the fire-fighting is externally inflicted, fix the (external) boundaries issues that leads to others causing fires for you.
Neither of those is necessarily easy to do, especially while your energies are still being taken up with conflagrations! But the alternative is to keep spending energy on firefighting.
Managing Your Own Career
If you are a native English speaker who uses Microsoft Teams for internal meetings, I highly recommend turning on Speaker Coach. That feature gives you a report after scheduled calls, flagging repeated or filler words (it turns out I say “you know”, “uh”, and “cool” a lot), talking too much during a meeting (something we managers need to look out for), flat speaking tone, and other speaking issues.
I can’t honestly say it’s been enjoyable to go through Speaker Coach reports, but it has been extremely valuable, and having those nudges and data after every meeting makes improving much easier.
Note that Speaker Coach currently only works in English, and I don’t know how well the word recognition functionality would work for people who have accents in English that come from speaking other languages too. (I imagine the flat speaking tone and speaking-too-much functionality would work, however)
Get straight to the point - James Stanier
Many of us were trained in academia, or have been in academic circles long enough to pick up some habits of thought.
That explicit or implicit academic training serves us well in a lot of ways! But not when it comes to communication.
The very stylized (and verbose…) form of communicating in scholarly journals and research presentations is an active hinderance when we’re trying to get things accomplished communicating with busy people.
I like tools like Hemmingway App to help me tighten up my text and make it more readable. But that can’t help with the structure or organization of what I write.
Stanier urges us to get straight to the point, with three clear recommendations:
Make it clear up front what you want
Make the next steps obvious
If you already have a recommendation, say it
None of this has to come off as assertive or obnoxious - it’s just how you structure and order the information and request. It’s a matter of kindness to the reader - giving them what they need to provide an answer immediately (and get the email out of their inbox) if that’s possible.
When you’re not making a request but just communicating information, the Minto Pyramid is also a good approach.
Random
A computational biologist just won the Great British Bake-Off, for those who doubt the transferrable nature of research skills.
Meta demonstrated Galactica, a promising-sounding AI large language model for searching/summarizing the contents of a large library of scientific papers. It didn’t go well.
Why we call it boilerplate code.
Key chain fobs are ok, and apps for your phone are fine I guess, but wouldn’t you rather have your TOTP multi-factor authentication token generator running on a Commodore 64?
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