Managing Managers: A Lesson in a Mindset Shift

Problem

When a first-line manager gets an opportunity to step up and become a senior manager or director and have other managers reporting to them, they will have to let go of many things they did before. They will no longer run Scrums, define the requirements, write code or even go through code reviews. Nevertheless, they will still be responsible for providing the status, guiding the team and tracking progress. In a nutshell, their accountability will remain the same, but the way they will get their work done will change completely. That will require a distinct mindset shift that will allow them to scale themselves and focus on new responsibilities while giving people on their team room to grow and become good managers.

Actions taken

When I got the opportunity to become a manager of managers, I was initially overwhelmed with concerns -- I knew how I would do something by myself but I was wondering how should I approach other people and tell them what to do, what level of detail I should be engaged in, what should I expect from them, etc.

The first thing I did was to make an inventory of all the tasks a manager (not a manager of managers!) must do. I listed around ten things; for example, doing code reviews, sitting in design discussions, running i.e. what I did as a manager. Scrum, collaborating with external stakeholders to unblock the team, running one-on-ones, doing project planning with the team, doing retros, creating presentations on status, etc. In addition, I created a list of things I have to do as a manager of managers that I didn’t have to do before as much; for example, fully responsible for hiring, talking to senior leadership, providing them regular status updates, being aware of incidents and status for all streams of work, being involved in technical discussions, etc.

Then I looked at the first list and identified the things I was personally accountable for. For example, I was personally responsible for hiring and firing and I couldn’t delegate that. Then I looked at the tasks I could delegate; for example, I could delegate running Scrums -- I could still be part of, but not running them. The same applied to code reviews. However, I felt that there were some aspects of software development that I should be involved in like upfront design and architectural decisions.

After that, I had to figure out how to do status checks and which ceremonies that previously were not part of my responsibilities I had to attend. As a manager of managers, I was responsible for five teams whereas as a manager I was responsible only for one team. I had to introduce separate one-on-ones with my managers to learn about statuses and blockers, but also do a group status meeting with all five managers.

I realized that hiring and firing were the most critical aspects of my new role and I decided to be the sole owner of hiring for my team. As a manager, I would take part in the interviewing but I didn’t interface with HR or Talent Acquisition. As a manager of managers, I had to keep tabs on how many candidates are coming in, what was the throughput of the candidate, what was the quality of the candidate, what were the questions we were sending to recruiters to screen on candidates, etc. I also had to be able to address pain points between HR and Engineering -- was Engineering not interviewing fast enough, was our feedback sufficient, etc.

I also stayed involved in select activities in software development. I was very involved in design discussions that were required upfront, quality checks, testing, incidents, etc. That way, though I stayed away from the code, I remained close to the team.

Lessons learned

• Don’t be afraid to make mistakes. I hired a number of wrong people and I dragged my feet on making firing decisions. I failed to provide clear directions or set clear goals that created confusion on the team. But I learned immensely from all of those mistakes. Making any kind of decision will inevitably result in some mistakes -- don’t be afraid to make decisions and don’t get paralyzed. Making mistakes is the only way to learn.
• Be clear in your direction. People will be looking up to you for direction. This is something I initially failed to do and for a while, I believed people knew what to do. But I was getting consistent feedback that I need to be more clear and tell people exactly what I wanted them to do.
• Managing up became increasingly important. Making the leadership understand what we were doing and what was being done or what were the challenges and what were the blockers became essential.
• I had to learn to articulate Why to the team. It is not enough to tell people what to do; you should provide them with background and context but also explain why something is important and how it is connected to the business.
• The main difference between managing managers and managing ICs is in the level of detail you are involved in. As a manager of ICs, you have to figure out how to get things done whereas as a manager of managers you are focused on what things have to get done and why.