You’re Not a Manager of Multiple Teams, You’re a Leader: Tips for Leading Multiple Teams | by Lee Fischman | Jun, 2023

If you don’t approach multi-team leadership as its own beast, everyone is going to suffer. Not just the ferrets.

You’re in charge of several teams because they have something in common. You may facilitate unanimity through a well-grounded, practical, unambiguous vision statement. Careful about the vision, though. In groups created around a specific mission, vision tends to be tighter and easier to follow. In groups created by accretion, a vision could be great for some teams while irrelevant for others.

Lack of two-way communication is the root of all evils. It’s how wars and divorces get started. Communication also has to be tended to, like your flower garden. Some things you can do:

• Institute “skip meetings” where folks can directly talk to their boss’ boss.
• If you have product managers, lean on them. I’ve found that PMs maintain their own comms rail, almost like a backchannel messaging platform.
• Slack, Symphony and Teams channels are a great democratizer, if they get used by everyone. I’ve seen executives make the most of these channels, participating and so letting everyone see them. I’ve also seen executives in the same role who did not do this, and so were invisible.
• Stage regular all hands sessions that give teams a chance to tell their story. Keep the focus on just 1 or 2 teams per meetup.

Novel things get dropped between the boundaries of individuals’ responsibilities, so stay aware. Things I’ve seen:

• Sometimes the division of responsibility between project managers, product managers and business analysts isn’t clear; call it The Three-Headed Responsibility Monster.
• Sometimes someone is designated to be the “contact person” with a major customer. This is done with the best of intentions, because customers like having a single point of contact. Nonetheless, I’ve seen wires get crossed, usually when the product manager doesn’t work through the designated contact, going to the customer directly.
• Within development teams, who does the unplanned work, such as support? It’s helpful for engineering teams to establish a rotation where developers take turns being on point for this stuff.

The sum is often greater than the parts, right? That applies across teams too, provided that you lubricate relations. Encourage sharing between teams with regular meetups (mentioned earlier), ensuring team leads talk with each other, and by keeping your antennas up for where inter-team cooperation makes sense.

I’ve seen some teams starve while others thrive. Oftentimes there’s a story behind this such as, “We can’t even satisfy our own work in progress, let alone support you.” One way to approach this conundrum is through the notion of marginal benefit. For example, without a resource, one team may be fully blocked while another team is merely inconvenienced. Marginally, it makes sense to give the blocked team enough support so they can move on. You also can have designated floaters. In software development these are often the designer, architect, documentation specialist, or developers with specific skillsets.

That’s your job, right?

• Synchronize all your sprints to insure that monitoring occurs at the same cadence across teams, which also permits them to better coordinate work. At the same time, grant some flexibility into how individual teams operate: some don’t need daily standups, others prefer Kanban over Scrum, etc.
• Agree on a metric. Story points may be developers’ preferred tactical metric, but they aren’t standardized. Is a story point equal to an “FTE day” or something else? An “ideal” story point definition permits common reporting upward, becomes currency in cross-team discussion, and makes velocity across teams even roughly comparable.
• T-shirt size is developers’ go to metric for their bigger stuff. Again, there’s no standardization around it. Crowdsource a standard and stick with it.
• Qualitative monitoring in a standardized report insures regular insight into what teams are doing. It can be as simple as Wins and Challenges for higher level execs, or Done and Next for regular divisional updates. Reports should be readable by a lay audience and not a rehash of JIRA cases.
• Regular 1:1s with team leads are the only way to unearth some information.

You’re not a manager of multiple teams, you’re a leader. Leaders impart direction and focus. Leaders don’t micromanage. They trust their teams to execute. You keep the pulse on teams in order to empower and support them. Some other leadership notes:

• While you are not a direct contributor you still can be a muse, contributing ideas and acting as a sounding board.
• The personality of teams may vary, requiring different approaches. Some teams do not like surprises, while others are more flexible. Some teams are very focused on their core goal, while others are more sensitive to users. On bigger teams, there may be differences between members; perhaps some have longer critical projects, while others don’t. To learn a team’s personality, get involved in their ceremonies to the extent possible without imposing.
• Approach your dealings with integrity, including admission of mistakes.
• Force yourself to smile. I’ve dealt with managers who were taciturn, which made dealing with them that much harder. Smiles create smiles.
• Keep folks focused. Keep track of what teams are up to, as they can get into ruts. There are often good reasons behind teams churning, but you should nonetheless regularly examine whether a teams’ current work queue is critical or whether higher impact work can be slotted in. Sometimes its as simple as people being unaware of the higher marginal benefit of alternate work.
• Some people believe in friendly competition between teams, but I don’t. I think explicit competition makes losers in addition to winners, and there is implicit competition between teams anyhow.
• Empathize. Ask about people and share about yourself. Without social connections we are just cogs in a machine.
• Keep people happy. Reassign and rebalance to let folk learn new things, get new exposure (such as with customers), receive new responsibility, and be relieved of grunt work.
• Beyond everything above, Chris Weil provided this great thought about leadership, “Leadership is making something happen when you are in the chair that wouldn’t have happened if you weren’t there.”

I had a supervisor who never complimented me, even though I was doing good work. It was demoralizing. Software development is above all about people, and leadership should be in service to that idea. Recognition also makes good business sense because it not only makes people feel good, it motivates them!

Give recognition freely. Let’s say someone has a great idea; sure that’s their job, but does recognition cost anything? A team hits a target; sure that’s their job, but does recognition cost anything?

Keep a constant pulse on both your teams and individual contributors. Elsewhere I mentioned 1:1s, which are a great way to uncover issues. Also, try and step back from the noise of sprints into broader views that give a sense of what’s happening with teams; have they had enough wins, are there too many blockers, and so on.

In pursuing answers to what’s going wrong with individual contributors, talk directly to them. Are they not getting good direction, do they not have the right skills, are they being distracted, is their work hampered by outside factors? Engage people so they don’t fear telling you the truth, though after you’ve spoken with them, you might talk with the team’s lead to get their perspective.

“Mad/Sad/Glad” is commonly used in sprint retrospectives. I was first exposed to the “Mad/Sad/Glad” board by a colleague, when it was used to resolve an inter-organizational conflict we were having. The origin of the board is unclear, but the concept of categorizing emotions into basic categories has apparently been used for many years in psychology and counseling.

“Mad/Sad/Glad” really draws stuff out, enabling true continuous improvement. It makes everyone’s thoughts tangible and thus actionable, and I believe this device should be used more!

Never select any of those autopilot switches. Constantly circle around the camp and check on everyone. Don’t make the mistake of mostly talking up, or just talking to leads. Make sure people know about each other. You are there for everyone.

No ferrets were harmed in the production of my thoughts.