#128 - Management 101 = individuals; 201 = the team
Plus: Long- and short-lived Group dynamics; The leaders journal
I get a lot of questions about both hiring and communicating expectations/performance management. I’m trying to compile and clean up some of what I’ve written on those topics (e.g. #57,58,59,60) in an ebook like I put together for one-on-ones at the beginning of the pandemic.
There’s two big topics left on the topic of communicating expectations; they both touch on the current top un-answered question on the last AMA poll:
How can I get better at receiving feedback from my team?
A lot of what we see about expectations management and feedback is about managers providing feedback to individual team members. It’s an important topic! A hesitation to give routine feedback (frequent, mostly positive, always rooted in behaviour and impact) is the biggest gap I see among new managers of research computing teams. This is a vital “beginning as a manager” 101-level skill. It’s also one scandalously overlooked and under-appreciated in most of the institutions we were trained in.
But it can’t stop there. The 201-level of management is to start thinking in terms of the team collectively as a system, one that has its own momentum and dynamics. As an IC in research work, you built machines which did things — theoretical constructs or data analysis pipelines or software…. As a 101-level manager you support and direct individual machine-builders, maintaining individual relationships with them, and supporting their professional growth. (And to be clear — in my experience a solid 101-level manager is already comfortably in the top 1/3 of managers). Your 201-level skills build on the pairwise manager-team member relationships you build and maintain with management 101 skills. As a 201-level manager you are are growing, nurturing, and tending to an organization which consistently and reliably builds the right things well. You’re developing a self-sustaining team of machine-builders.
There are both 101 (individual) and 201 (team) level components to getting feedback from your team-members. In both cases, the feedback is valuable for both effectiveness reasons, and for modelling the response to feedback you want to see.
(An aside; there are excellent management resources which say that you can’t get feedback from your team members in the same sense that you give feedback to them. They mean something quite specific about feedback, which includes a requirement to change a behaviour. You can require things of team members in a way they can’t of you, because of the power difference and because you have work responsibilities other than to them. This is all completely true! I just don’t find it particularly fundamental. You want to constantly be soliciting input from your team members, and from the team as a whole, and incorporating that input into changes wherever possible. By all means call the input you collect and the process by which it’s given something other than feedback, if that works better for you. I’ve not found reifying the distinction with different terminology to be useful. Your team members are already well aware that there’s power and scope differences between their role and yours.)
Working with individual team members and asking for their feedback consistently is important for developing the working relationship, and for modelling the feedback process for them. Your team member will, reasonably enough, initially be extremely uncomfortable offering you any kind of constructive feedback (and maybe even positive feedback, for fear of not wanting to sound like they’re sucking up). As in Hogan’s article about getting good feedback from peers last issue (#136), the key is specificity and consistency. Repeatedly asking in every one-on-one about something you’re working on for a few weeks, or a new process you’re trying, is a good way to get started. “For the next few weeks, I’ll be working on improving how I run our meetings. Do you have any feedback for me about those meetings - things that work well when I do them, things that could be better?” When they, inevitably, say “No, everything’s fine” the first few times, respond with something along the lines of “Ok, well if you think of something, let me know over slack, or we can talk about it next week”, and then follow up next week. Keep asking exactly the same question a few weeks in a row and following up.
Ed Bautista also makes a great point about asking for feedback even in the process of giving challenging corrective feedback to team members. If this is something that’s come up before, and change isn’t happening, it’s worth asking “Is there anything I’m doing that’s part of the problem, or something I should be doing to help you with this change?”. From his article:
[…] behavior is adaptive, and when we encounter behavior we view as problematic we should get curious about what the other party is adapting to–it may be us. So even in a conversation in which critical feedback has been accepted without defensiveness and amicable agreement has been achieved, it’s worth including this step in the process.
Again, this is important both for the relationship, for modelling receipt of feedback, and for your own effectiveness.
When you do finally get feedback for you from the team member, this is a cause for celebration! Now we need to make sure we’re modelling the behaviour we want to see, and behaving in a way so that we’ll get more of it. The key steps are:
Thank them effusively and sincerely,
Repeat what they said in your own words, and double-check that you understand it,
Ask any clarifying questions, particularly about the impacts they’re seeing (rather than what they think is the cause),
If it’s a request for something to change, and if you are 100% sure that this is a trivial thing that you can easily change (a number of things will be!), talk with them about how you could change it, otherwise:
Thank them again, tell them you’ll take this seriously and let’s talk about it next one-on-one (and then do so).
Do not get defensive (which can be hard), start justifying why you can’t change the thing (even if you can’t), or for heaven’s sake telling them that they’re wrong. The goal here at the individual level is for them to bring up problems to you readily, confidently, and promptly, and for you to model the receipt of feedback. Remember that if they see a problem and bring it up to you, there probably is a real problem, even if it might not be quite what they’ve identified. Dig in, give what they’ve said real thought, and be prepared the next time you talk to talk about mitigations even if the cause they present is something you can’t or won’t change. Work with them on at least some way of addressing the issue.
Doing this a few times, even if the changes made aren’t exactly what they raised, will demonstrate that you take their input seriously, even if you can’t always do what they ask. This builds a level of trust that is difficult to develop otherwise.
Once this is established at a one-on-one level with your team members, building a culture of feedback at the team level is the next, 201-level step. There’s two big levers for - team retrospectives, and encouraging team members to give each other direct feedback.
Retrospectives - time set aside for the team to think about the performance of the team as a whole - are as foundational to 201-level management as the one-on-one is to 101-level. Your team members can’t put careful thought into working on the team while they are are busy working in the team, focussed on the details of their individual work.
The team (including you) needs to be able to establish its own internal expectations. The team needs to be able to set and improve team processes so that work gets done effectively and well. Team members also need to learn what holding other team members accountable for shared expectations looks like. (I can not emphasize this enough. A team is a group of people that rely on each other, which necessarily means that they hold each other accountable. That reliance and accountability is what turns a group of people with the same departmental mailing address into a team). Retrospectives is where work on the team happens. As the manager, you have an vital role to play facilitating that work! But the more that the work is driven bottom-up by the team members, the more likely it is to become self-sustaining.
Some kinds of work, like software development with short (few-week) sprints, lends itself to frequent retrospectives. Other kinds of work may not present natural opportunities for retrospectives other than the occasional completion of big projects. In that case you’ll have to make the opportunities — which can be a simple as a periodic recurring agenda item at staff meetings.
Either way the approach is the same. Once you’ve established two-way feedback trust with each of the team members, you’ll make use of that trust to get genuine input on how team-wide things are going, what should be changed, what’s working well and shouldn’t be changed, where there’s unnecessary friction. At the beginning, the input will likely be safely and superficially procedural (“can we skip standups on days where we have the staff meeting?”). which is fine. It’s a start, and procedural issues need tending to. Initially, these will be comments on processes that you set up. As with the individual level feedback, how you respond, and the team discusses and responds to these issues raised will build trust. And you’ll get to build your meeting facilitation skills, helping the discussion progress without driving it or necessarily even contributing very much.
Over time, the retrospectives will start to touch more on shared team expectations. Things like ticket or pull request response times, what’s needed for an adequate a code contribution or data curation task. The sort of expectations that team members can hold each other accountable for. As consensus builds around these things, they should be documented somewhere the team can refer to and update. This is not only something the team can hold itself to, it will be an important resource in onboarding new team members.
The other team culture of feedback lever you have on your disposal will come up in one-on-ones. Not all the feedback you get will be about you; you’ll start to hear how another team member didn’t meet some (collectively or individually understood) team expectation. Generally this is not something that benefits from your direct involvement (e.g. #55 on “triangulated feedback”); this is an opportunity for you to coach the team member on giving the feedback directly to the other team member, and debriefing on how it went. Having modelled this already for your team members will support this, as will team discussions in retrospectives.
None of this is easy - it takes time, and requires building multiple layers of skills on your part. Skills include individual-level feedback skills, meeting facilitation skills, and a lot of listening, empathy, and governing any immediate reactions you may have to feedback that you receive about your own work or processes you’ve set up. But the reward is a team with its own momentum and increasingly self-sustaining culture,
What do you think - where have you seen this team-level accountability work really well, and where have you seen it struggle? Anything you’d want to add or share for the other readers? Let me know - just hit reply, or email me at firstname.lastname@example.org!
And now, on to the roundup!
Group Dynamics: The Leader’s Toolkit - Ed Bausta
Very apropos to the discussion above, Bautista covers some of the levers available to you for shaping the group dynamics of a team:
Logistics - the various rhythms and rituals of your teams interactions (meetings, how much of the teams work is asynchronous, etc)
One-on-ones - again, everything at the group level builds on your work with the individuals within the group
Group facilitation - your role as someone who facilitates the groups discussions and deliberations
Group observation - things like retrospectives
Group composition - making sure the group (in the broadest sense) has the right collections of skills, behaviours, expertise, experience, and influence
Bautista has a lot of very useful links to his own writing here, broken down by those topics, it’s well worth digging into if you want to learn more. Much of what Bautista writes is for higher-ups, rather than managers of ICs, but the team and individual management issues he covers are the same at all levels; we’re all just people trying to get our work done together and have an impact.
Bautista points out that “the group” under consideration at any moment may not be the same as “the set of people who have you as their manager”:
In an ideal world, everyone who reports to you is a member of the team, and every member of the team reports to you–but organizational life isn’t always so neat and tidy.
which leads us very nicely into the next item.
Task Forces - Aviv Ben-Yosef
Our work is often collaborative and multidisciplinary. That means that we often tackle work that needs expertise and people from different places on the org-chart, assembled for some ad-hoc purpose. I personally hate terms like “task forces” (or, heaven help us, “tiger teams”), but we need to call them something, and talk about how they should function.
Ben-Yosef advocates for keeping them tightly scoped, running them professionally, and keeping the formal managers and teams connected to the task force members:
Have a clear scope of work (a “definition of done”)
Have a clear scope of time (“should rarely take on something longer than a quarter”)
Keep having one-on-ones both with formal manager and the matrixed task force lead
Those managers should stay in sync
The formal manager should still be giving feedback and growth coaching for things they see
Task force members should stay in contact with their original team (standups, team meetings, etc) so they can easily reintegrate
Managing Your Own Career
The leader’s journal: Become an inspiring leader in ten minutes a day - Ofir Sharony
How to Learn From Your Failures - Jeremy Adam Smith
Retrospectives aren’t just for teams!
I’m not sure if “becoming an inspiring leader” is necessarily something we need to aspire to, but Sharony is exactly right about the need to take notes and reflect constantly as a manager:
We make dozens of decisions every day, but rarely get immediate feedback on them. Unlike developers, who can write code and see its effect on users within minutes or hours, leaders rarely see the consequences of their actions until weeks or even months after a decision is made.
To give us some way of learning in the sensory-deprived environment (#115) of management, we need to record what happens so that weeks or months laters as things do play out we have some hope of connecting that to our actions. We don’t get ticket systems or version control or architectural decision records anymore to faithfully record what we’ve worked on; instead we have to do it ourselves.
Sharony suggest setting aside 10 minutes towards the end of day to take some notes on creations, decisions, insights, and challenges from the day ending, and how to make the most of the next day, and to review and reflect on those periodically.
And Smith suggests spending some time to reflect, at some emotional distance, from things we’ve done that haven’t worked, put that in some context, and build from that. The article has a number of research-based recommendations for doing that constructively, without beating yourself up over it, including by focusing on learning as the goal.
By the way - learning from failures is important, but we know (#104) that for teams at least, learning from successes is just as important; teams that focus retrospective time on both things that went poorly and well learn faster and do better. So pay attention to mis-steps, but to successes as well!
The northern hemisphere academic year is starting back up, plus there’s more events then there was this time last year or two years ago. Introverted and feeling dread? Here’s a collection of articles to help.
The last person in the floppy disk business; apparently business is good!?
A couple “weirdness of large deep learning models” items:
Distance in high dimensional spaces, text-to-image models, and macabre ghosts in Stable Diffusion. (Heads-up: This thread is interesting and mathy, but the Supercomposite thread it quotes has some disturbing images if you follow it down a while).
Deployed models like GPT-3 can be told to ignore the instructions they’re to follow: welcome to prompt injection.
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,