Becoming a Manager of Managers

I often get the question from managers on my team about what it takes to become a manager of managers. Putting job titles aside for now, I have had experience with many managers who have made this role transition, and I can share a few of the less obvious new challenges that arise.

There are many obvious changes involved when moving from managing a direct team of experts (e.g. an Engineering Manager, managing software engineers) to managing managers, such as the fact that your management scope expands to multiple teams, each with its own leadership structure. You also get to start having “skip-level 1:1s” or other meetings that will now involve multiple levels of reports, all of whom are on your team.

Less obvious are some of the differences in how it feels to be a manager of managers, most of all in the day-to-day. What does it feel like to be a manager of managers, on any given Monday, Tuesday or Friday? Of course many things will depend on function, profession, company and so on, but using modern tech companies as a starting point, I have three observations that may help shed some light.

1. Problems

The nature of problems escalated from your team that you deal with as a manager of managers is quite different from that of a first-line manager.

First, the problems that are escalated to you from within your team—usually from a manager reporting to you—are, by nature, more difficult to solve. As a first-line manager, you were well-equipped to solve many problems that arose on the team, and you did so quickly and diligently. But when you ran into a problem that you couldn’t solve on your own or through obvious collaboration, you escalated that problem to your manager. Now that you are a manager of managers, because there was probably an initial delay while the first-line manager attempted to solve the problem, by the time it gets to you, it’s been lingering for longer and a solution is often more urgent.

Next, many of the problems escalated to a manager of managers are not problems that live within a single team context, and are much more likely to overlap with the problem domains of other teams, including those outside of your scope, or your manager’s scope. This means that ad-hoc partnership, collaboration and influence often need to come into play to resolve these problems. You must build your cross-team and cross-org relationships in anticipation of these problems so that you can call on a fellow manager of some other team at 4 PM on a Thursday with some hope of getting their help to solve your team’s problem by end of day on Friday. The clock is still ticking on your problem and your colleague is likely busy too, which can lead to further delays and more urgency to resolve.

In addition, when you are handling an escalation from a manager who reports to you, and especially when you are partnering with another manager on another team (because you don’t want to waste their time by prolonging the engagement), it is very easy to step on your manager-report’s toes and start to micro-manage the response on your manager-report’s team. This is especially true when you feel the urgency that has built up on this problem and you just want to see it solved quickly to unblock one of your teams. There is a balance between adding an additional delay, but giving more autonomy to your manager-report, versus pursuing a quicker resolution, but incurring potential fallout from bypassing or overriding them. You will work on trying to strike this balance every week for the rest of your career. Sometimes you might even achieve it.

Lastly, when you are solving these escalations for your several teams, you will notice that a lot more time is passing while solving each problem. And because you have several sources for escalations—several teams reporting to you instead of just one—there will be a good number of these escalations. In a typical week, you might be faced with two, three or even four of these problems, each with its own complexities and solution path, and each with its own drawn-out timeline. Instead of spending maybe 10–15% of your time on escalations as a first-line manager might on a high-functioning team, you may find yourself spending 20–30% of your time. This difference is palpable after a while, especially at 4 PM on a Thursday after a very long week of escalations.

So it sometimes feels difficult to be a manager of managers, when you are constantly helping to solve problems for your teams.

2. People

Obviously, when you start managing managers, you will be managing, well, managers. You may also still be managing some individual contributors, but they are usually the easy reports, because you’ve done that before. What’s less obvious about managing managers is that you are also still a manager: you have the same job as your manager-reports.

Of course, your role is now higher level and includes multiple scopes. But fundamentally, you and your manager-reports are fulfilling the role of manager of a team. What’s weird about that is the line between “your area” and “my area” becomes…fuzzy. With a group of individual contributors, it’s easy: they do the work and you support them doing the work. With managers, you support them doing support of doing the work. Which is just about as messy as it sounds.

First, because there is no obvious boundary for who between you should do what exactly, you have to be much more explicit about who is expected to do what. This is as much for you as it is for your manager-reports, so you all know what to expect from one another. For example, as manager of managers, it’s unlikely that you will want to be involved in the day-to-day happenings on any single team, for lots of good reasons like avoiding micro-management. But when an issue arises, or you need to draw on knowledge about that team, you must now work through and with your manager-report to understand what is happening on the team, and quickly. You’re going to need some shared expectations of engagement in order for this to go smoothly and feel good for all parties.

Also, due to the nature of problem solving (described above) and planning with other teams and organizations, you will need to build more and stronger relationships outside of your team as a manager of managers. A significant amount of your time and emotional energy beyond what you already spend with your own teams should go toward getting to know and build trust with your fellow managers of managers, their managers and manager-reports, et cetera. For those of us who do not gain energy from building new social relationships, this will be exhausting, never-ending work, even if it is rewarding and useful in the end.

So it sometimes feels difficult to be a manager of managers, when you are constantly setting and resetting boundaries, and building myriad relationships.

3. Time horizons

One of the least expected changes among the managers of managers I’ve worked with has been the shift in time horizons when it comes to making changes on their teams. It does start to make some sense when you think it through, but most people do not anticipate what it will feel like to have their efforts stretched out over longer time periods before they can “feel a win.”

As a first-level manager, you can choose to change how your team works with very little time and effort. On a healthy team, you would just take notice of something that could improve, talk to your team about it, agree on one or more changes to attempt, and then attempt them. From the moment you notice until you have a fully integrated process change on your team might be 2–3 weeks at the outside, assuming you have to experiment a little. It feels good when you get a change in place that works well, for you and your team.

As a manager of managers, you might first think that it would only take slightly longer to implement such changes. But instead, I’ve found it’s more often an exponential increase in the time to get fully implemented changes implemented on teams. The reasons for this seem to be: feedback cycles and standardization.

If you notice something that could improve across your teams, you could bring it up with your manager-reports. Each of them likely has their own interpretation and opinions about the severity of the issue, likely solutions, and how much it fits something they see on their team. So each of them could go talk about the issue with their teams, discuss whether or how it affects them, agree on one or more potential changes to attempt, then bring those back to you via each manager. Due to differing team cadences and urgency of their projects, this first feedback cycle is likely to take 2–3 weeks. Then you and your manager-reports can look at the suggestions together and decide what makes sense to try, and on which teams, based on the results.

Suffice it to say that sometimes a second feedback cycle is needed, often you make changes on just one team to see what happens, then you must bring results back and decide how to standardize and integrate the chosen solution across all of your teams. End to end, this can easily take 2–3 months on typical teams that are focused on normal day-to-day priorities and for whom these team changes are unplanned and not top priority. If you stack up a few sets of issues like this and try to make team changes in parallel, as a manager of managers you are often waiting weeks or months at a time before you “feel a win” on any given team.

It is also fairly common to be interrupted by a strategic change from your manager or someone else in leadership or from another function, whereafter the changes you were trying to make need to be remade in a new context after the change in strategy. This can add further delays and feedback cycles with your teams, stretching out both your chance of feeling success and your ability to point to any specific change as something you personally created.

Some people are patient, persistent, and ready to wait for those increasingly rare wins on their teams, and are untroubled by the diffusion of authorship of such changes. Others find the drastic slowdown in the cadence of successes to be demotivating and dispiriting. It usually takes some actual experience with the effect to tell who is whom, and a good deal more experience to notice patterns in the problems and to become aware of levers and shortcuts to implementation that can make such work more successful if not more rewarding.

So it sometimes feels difficult to be a manager of managers, when you are patiently waiting for a win, for weeks or months on end.

Conclusion

There are many things that can change when becoming a manager of managers. Hopefully this peek into three unique aspects of how it feels in the day-to-day, month-to-month aspect of the job is enlightening and might help you make better decisions for your own career path.