#154 - Growing Your Work On The Team: Taking Everyday Opportunities
Plus: Recognizing and rewarding team members; Hiring playbook; Dealing with know-it-all peers; Why do they ignore my amazing documentation
Manager, Ph.D. is a newsletter and community which helps people from the world of research and scholarship make their impact as excellent managers. We’ve already developed the advanced skills to be exceptional managers; we just need help with the basics.
Taking Everyday Opportunities To Work On The Team
Last week we talked about how it’s principally our responsibility to work on the team - to help team members do their best work and grow professionally; and to help the team collectively consistently succeed together.
For a lot of us from the research world, this is a tough transition. We got to where we are by excelling at doing the work of the team. Focussing on “the people stuff” is pretty far afield from that precise, highly detailed work. We absolutely were successful parts of complex collaborations, but the actual work being done by the collaboration was paramount, with much less thought or effort typically going into developing or maintaining the collaboration itself.
So where to start?
The easiest way to make a consistent practice of this is to find small places for it in our everyday interactions and activities with our team. Getting started with small steps is easier for us, for the team, and it’s easier to keep it up over time - which matters, because these small steps compound over time!
If we keep an eye out for opportunities, we’ll quickly find lots of places where we could spend a little bit of extra time to take something that needed to be done anyway, and have it do double duty — as the task at hand and as growth for the future.
And yes, it does take that extra time, time we have to carve out of our schedule. Once that’s done, maybe following last week’s approach to incremental improvement, we can afford these small investments in time to grow our team’s capabilities.
When keeping an eye out for these opportunities, it can be helpful to think of growing our team’s skills in three key areas: improving individual skills; increasing scope and context; and knowledge building and sharing.
Improving Individual Skills
One of the most effective ways to develop your team’s skills is to provide them with guidance, support, and feedback that can help them improve their skills, performance, or behavior. This can involve:
Coaching a team member to find an answer rather than just giving them an answer. We’ve cultivated expertise for some time, and so we tend to want to just give the right answer. It’s understandable! And most of the time, it’s a missed opportunity. When time permits, being a guide while they solve the problem or figure out the answer helps develop their skills, knowledge, and confidence, and reduces the number of questions brought to you in the future. Lara Hogan’s list of questions in #139 is a good source of open questions to ask while coaching.
Giving team members frequent feedback (mostly positive, always rooted in behaviour and impact). It takes a little while to practice giving good feedback, but if you practice with positive feedback first (and you can achieve a lot with just positive feedback) it isn’t difficult. Then, taking a few moments to provide simple feedback on specific behaviour/output and its impact is a foundational practice. Feedback reinforces strong results, and nudges people towards better practices when needed. It doesn’t have to be — it shouldn’t be — a big deal; it can just be a steady source of small feedback so people know how they’re doing. (And people want to know how they’re doing).
Note that in both of these cases — and all the examples that follow — there’s extra time required of us at the beginning, but over time (if the team takes over certain classes of decisions, or a team member now represents the team in an external collaboration meeting) this can free up some of our schedule and our effort.
Expanding Scope and Context
Working in a team is all about collaboration and communication - especially when the team themselves are experts who like to focus on the hands on work. Some simple opportunities here:
Getting team members or the entire team involved in decision making. The decision has to be made anyway - you might as well make it do double duty. Bringing decreasingly routine decisions to the team can help them learn to apply their already strong judgement and decision-making skills to matters of greater scope in the organization than they’re used to dealing with. We can solicit their input on important issues or changes, involve them in setting goals or priorities, or delegate some decisions to them. The main things to keep in mind: provide all relevant context; explain what would be a good and bad outcome of the decision, and accountabilities for those outcomes; explain how easy or difficult it would be to walk the decision back; and make it clear what the decision making process will be (this will initially be you as the decider with their input, then giving them increasing degree of control over the outcome). Revisiting the decisions can be an excellent part of a retrospective (see below).
Inviting a team member to join a meeting or a project with another team or department or stakeholder. Whether bringing them along initially, or eventually sending them in your stead, external meetings are another way to help provide additional perspectives, context, contacts, and opportunities for a team member who has expressed interest in that work. Here again it’s important to provide lots of context before the meeting (people, background, previous work); discuss the goals of the meeting and the team’s desired outcomes; and debrief afterwards.
Hold retrospectives (#128). After completion of a project - or even just every so often - holding retrospectives on what is working well in the team and what isn’t, and brainstorming possible improvements, is an excellent way for the team to turn its attention from the work to how the work is done, and to find possibilities to improve how they work together.
Knowledge Building and Sharing
We typically lead teams of experts, people who value their knowledge and skill. Growing and sharing that expertise is valuable to the team, and in the professional development of the team members. There’s lots of opportunities to
Asking a team member to share their expertise or experience with the rest of the team in a workshop or a presentation. After a successful project, or a team member used a new tool or technique for a problem, or after a new team member joins - these are all natural times to try to organize some kind of knowledge-sharing session. The hard work has been done - people have learned something new! May as well make the most of it. The team member will practice their teaching skills, and the team members will learn something new. Bonus points if the session is recorded or the materials stored somewhere easily accessible, and it can be referred to in the future. After a few iterations it can be useful to share these sessions (with the team member’s permission) more broadly - to stakeholders in the organization, as public blog posts…. This will take some time for you to organize (especially the first time), some time for the team member to prepare, and some time for you both to debrief afterwards to discuss how it went and make notes to improve of the next time.
Help team members document repeated processes. In a team of experts it’s easy to find yourself saying things like this from time to time: “Ah, Kim is the person who always does this, and they’re not around this week, so we’ll have to wait until they get back.” Kim might well be quite happy to have someone else do that work from time to time! Finding opportunities to document team practices in some shared location (and, crucially, keep them up to date) speeds onboarding, reduces siloing of knowledge, helps find common sub-tasks, and supports streamlining or automating of parts of processes.
Finding opportunities for peer mentoring. Mentoring is good for both the mentee and mentor; it helps the mentee develop new skills, and it helps the mentor develop teaching skills and, frequently, see the problem or tool in a new way. (TA-ing intro physics courses in my first year of grad school was an eye-opening experience and greatly deepened my understanding of my undergraduate curriculum. Students routinely asked me questions I never would have thought to ask!). Finding matches between team members who want to learn something new with team members who would like to teach it — and the team members don’t have to both be on your team — is extremely useful. You’ll want to make sure both team members agree on the goals, and debrief periodically on how it’s going.
Many of the opportunities above, taken to their natural conclusion, lead to delegation — completely handing off some work you had been doing to a team member. You remain accountable for it being done well (not a surprise - you’re responsible for the work of the team in general), but they’re the ones who decide how to do it, and who carry it out.
Delegation helps the team members individually grow in directions they want to grow; it helps the team become more capable; it helps with engagement and retention, and it helps us grow as leaders.
You’ll have noticed that there’s some common steps in taking advantage of many of the opportunities above:
Chose the right task matched to the right person
Explain the task, context, and the expectations clearly
Provide the necessary resources and support
Provide the right level of oversight, which will depend on the current task-relevant maturity of the team member (#148); as the team member succeeds, that level of oversight can be dialled down
Evaluate the outcomes and debrief. Note that we have to be ok with “I could have done it better myself” or “I would have done it differently”, especially at the beginning. It’s not about us — it’s seeing the work done adequately well, and growing the team’s capabilities over time.
Everything above becomes a lot easier if you’ve adopted the practice of weekly one-on-ones. Investing some scheduled time on each member of your team, each week, makes knowing what people are interested in, what their skills are, where they need extra help, and how they already work with others vastly easier. It means there’s always a block of time available for providing context, discussing desired outcomes, and debriefing afterwards.
Some recent articles which are good on this:
How to Equip your Team To Problem Solve Without You - Luis Velasquez and Kristin Gleitsman, HBR. Focuses on the mindset shift necessary on our part, especially when the problems being solved are less routine.
The Best Managers Don’t Fix, They Coach — Four Tools to Add to Your Toolkit - Anita Hossain Choudhry and Mindy Zhang, First Round Review. Specifically about coaching rather than fixing. Describes four tools (focusing first on the outcome, exploring possible options, acknowledging a team member’s strengths, and uncovering limiting beliefs that are holding back progress) and when not to use coaching.
Now it's your turn. What are some of the everyday opportunities you have found or created to develop your team's skills? How did they work out for you? Share your thoughts and experiences with us in the comments below!
I hope this article was helpful for you; and if you think it would be helpful for colleagues, please share it:
And now, on to the roundup!
Recognition and Rewards at Work - Lara Hogan
Being thoughtful about what work we recognize and applaud publicly, and reward privately is vitally important. People respond to signals and incentives, and recognition and rewards are signals and incentives. Are we incentivizing the right things? Is what we’re signalling is important really what we care most about? How can we expand what we recognize and reward to better match what we actually want?
Brainstorm your options for recognition and rewards - public and private, for the team and for individual. These don’t have to be big things like spot bonuses - little things matter, too. You almost certainly have more options than you think.
Identify the behaviours you want to see
Make sure you’re not unintentionally rewarding behaviour you don’t want to be incentivized
Recognize what someone does, not who they are
Then figure out how to take advantage of those options for rewards and recognition and apply them to the behaviours and outcomes you want to see more of.
As you know, I’m a big fan of thinking of hiring as the entire process from the job ad really needs to completing onboarding (#126), and then mostly planning the process in reverse.
Hiring is always a bit of a bespoke process - every step of the way should be tailored for the job at hand. And every job you hire for is slightly different, even if they share the same title, because your needs are different every time.
Rubick walks through their steps in hiring - in this case for tech, but the steps are the same for our expert teams too:
Figure out what the role is
Determine what assertions you’re making - what the needs are
Create the interview format
Create an interview plan
Determine who will do the interviews
Work closely with the recruiter [or other relevant HR staff]
Set up communications channels
Do a hiring kickoff
Meet with the interviewers and customize it
Calibrate with the recruiter after hiring screens
Do a debrief after each final interview
Rubick also has a good recent article on candidate review meetings, where most of the discussions are about areas of disagreement. And Jesal Gadhia reminds us that a lot of common practices used in hiring for some sort of domain expertise like technical knowledge are actually demonstrably pretty terrible, emphasizing the importance of having a well thought out interview and evaluation process like Rubick’s.
Managing Within Organizations
How To Influence a Know-it-All at Work (Powerful Phrases For More Confidence) - Karin Hurt and David Dye, Let’s Grow Leaders
We’ve all had know-it-all peers. Heck, maybe we’ve gone through a phase where we were the know it all peer. (I certainly have. I was very young at the time, but it still makes me cringe to think of it).
Sometimes just having a few scripted phrases at our fingertips can help us say something that needs to be said. Hurt and Dye give us some suggestions of how to handle these peers, and great list of 15 phrases we can use, broken into three categories:
Sharing the impact of their approach (e.g. “How do you think the meeting went today? What did you notice about the others in the room?” and “I’m sure your intentions are good. And sometimes, when you tell me what to do, it makes me feel like you’re questioning my expertise.”)
Getting more voices heard (e.g. “Thank you for sharing your perspective. Now I really want to ensure everyone has a chance to share as well.” and “I know you have a lot of expertise in this area, and I appreciate your point of view. I could really use your help drawing others into the conversation. Do you think you could help me do that in the next meeting?” - I love this approach of enlisting them to be the solution to the problem they’re causing)
Getting them off your back (e.g. “I really appreciate your desire to help, here but I’ve got this.” or even just “That’s interesting, thanks. And if you’ll excuse me I need to run to another commitment.”)
Technical and Project Leadership
Why do they ignore my awesome design documentation - Slava Shestopalov
Above we talked about the usefulness of sharing knowledge and having a common findable place where process or technical information can be found. But that information and documentation is only valuable if it’s used. If it’s there but ignored, then it was a waste of time.
Shestopalov’s article is about design documentation, but it applies pretty generally.
Shestopalov suggests some ways this can happen:
The documentation came down from on high and was never really accepted by the team
The knowledge the documentation was accepted, but there was no feedback mechanism or obvious place to ask questions, so discussion moved elsewhere and lo and behold another “source of truth” came to be, disconnecting the documentation from what’s actually happening
The process for the documentation didn’t involve relevant other team members so had no obvious connection to their work
And some ways to fix it:
Share material as you go, as part of an ongoing process
Place it in context, and include it where relevant discussion happen
Let others contribute to the document or process (which is a lot easier given if the two steps above have been done)
Make sure it includes other relevant disciplines, functions, or areas of expertise
Document the right things - does this need to be a document in the first place?
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, or reply to this newsletter if you get it in your inbox.
Have a great weekend, and best of luck in the coming week week with your team,