Getting your team of managers to solve their problems together
I often say that being a manager of a team can be a bit lonely sometimes. Sure you can and should share with your own manager but she isn’t doing the same job as you anymore is she?
How do you decide how to deal with a uniquely stubborn employee or how should you think through a very specific bottleneck you’re seeing in your dev process? I’ve found working on fostering safe, guided sharing among peer groups of managers can create a positive impact for your organization.
One technique I like to do with my managers I call Case Study. I learned the basics of this technique by being part of an Engineering Leadership cohort put together by Gary Chou at Orbital NYC.
- Someone needs to bring a case to study. This is a problem they are looking to solve. It could be about a direct report, a challenge with a stakeholder, improving a team dynamic or process- really anything.
- (4 mins) The presenter explains the problem in as much detail as needed. Often names or identifying information will be omitted to protect the confidentiality, prevent bias, or simply to avoid distracting from the heart of the problem.
- (5–10 mins) Now everyone else takes a turn at asking 1 question to the presenter about the problem. This allows the group to get as much context as they feel they need. This will take more or less time based on the size of the group.
- (10–12 mins) The group now discusses the problem at hand. The presenter isn’t supposed to speak now or participate in any way other than attentively listening and taking notes. The group isn’t necessarily “solving” the problem for the presenter as much as giving perspective, ideas, approaches, and things to look out for.
- (2–3 mins) The presenter now reflects back to the group what she heard and how she took in the conversation. She may choose to mention her next steps if she knows them at this point.
- I recommend the group checks in with the presenter on an established timeline, maybe 1–2 weeks later.
So all in all, you can have one of these sessions in about 30 minutes if the team is used to doing this. For the first one, I’d definitely recommend more time. You could aim to do one of these a month in place of, or as part of, your weekly manager staff meeting.
- The presenter is drawing upon the collective knowledge of the group. Managing people, processes, and projects is hard and it can take a long time to have “seen it all”. If you’ve drawn together a diverse (in every sense of the word) group, you are going to hear different perspectives. If you are lucky some members of the group might even disagree on an approach to the problem.
- Likewise, becoming a senior manager requires getting in lots of “reps”. Everyone in the group is learning in these sessions, not just the presenter. Less experienced managers are getting a free rep.
- Just like your engineers use formal code reviews to ensure high quality, safe code, and generally good outcomes, a Case Study can serve as a way to improve the work and decisions in and around the presented problem.
- You can consider this a very light version of peer accountability. Some people avoid hard problems, but the group can help ensure they don’t. The group can ask “how is it going?”, “do you want more ideas?”, “have you had that hard conversation yet?”.
If you can get this to work well for your team it can increase your managers’ job satisfaction and engagement. It can foster a “1st team mentality” and help your managers feel more supported.
- You need to ensure your team feels safe together before trying this. Do they frequently reach out to each other without you? Is there clear evidence of comradery already? If not, use the time on team building instead.
- Relatedly, if your team is new, recently added members, has a problem member or is in any way in flux, hold off for a while so they can “storm, form, norm” first.
- Consider if you should be there or not. There are pros and cons to either. If you are there you can learn a lot about your managers from watching and listening and you can ensure things stay on-topic, healthy, and productive. But by being there some people may hold back fearing your judgment- all the more reason to create a true learn-from-failures safe environment for your team. Also, the problem presented might be you.
- Make sure no one is dominating the conversation. One simple technique to employ here is what I call “Step up, Step back”. At the beginning of the session ask the group “Are you the kind of person that speaks more than others? If you are, I’d like you to ‘step back’, and if you aren’t I’d like you to ‘step up’.”
- Make sure everyone takes a turn at being the Presenter. Some people want to project an “I’ve got this” attitude and others want to avoid being in the spotlight. It’s only fair if some are going to be vulnerable presenting their problems, everyone should have a go.
- You might want to prescreen The Problem before the meeting to make sure it’s worth the investment by the group but I’d hope you’d trust your team on this.
- I’ve done this with groups sized between 5 and 10. I think it might work with a smaller group but it would likely break down above a group of 10.