Managing Managers

Welcome to the wonderful world of managing managers. At Capital One, I currently manage cross platform mobile and web teams. I had to learn how to manage multiple managers, how to get information form my skip-level reports, what it means to hold my managers accountable, how to hire new managers, how to manage first-time and experienced managers, how to cultivate my teams’ technical strategy and figuring out the root of organizational dysfunction.

This is my 7th post that captures my notes on Managing Managers Chapter discussed by Camille Fournier in her book The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change. This chapter highlights different strategies that I personally use on my day to day impediments and obstacles to successfully manage managers.

If you are interested in my previous posts on this book, please refer to one of the sections below:

  1. Management 101
  2. Mentoring
  3. Tech Lead
  4. Managing people
  5. Managing a team
  6. Managing Multiple Teams
  7. Managing Managers

This position is the first level in a much bigger game; The entrée into senior leadership and upper management, and that will require a large number of new skills.

The job expectations for managing managers are not that different from the expectations of managing multiple teams (See my previous post).

You are now responsible for several teams, for overseeing the health of those teams, and for helping them set goals. There are more projects and people than you could possible handle by yourself. Instead of managing a couple of closely related teams, you may manage a larger scope of efforts.

While managing multiple teams can be exhausting and daunting, managing managers adda a whole new level of complexity.

It’s easy to miss out on the details because you no longer engage regularly with all of the individual developers on each team. You’ll need to practice honing your instincts.

Let’s take the case of managing a team that is doing work outside of your skill set as it was the case for me when I started managing a mobile team (My background is Web). It’s tempting to let them roll and only step in if there are problems. However, on your first time, you are probably not going to detect problems until they’re far gone. You haven’t yet built up the disciplines or instincts to let yourself sense where and when to dive in deep, so you need to do so more frequently, even when things seem to be going well. You need to follow up on the little things until you figure out that you no longer need to follow up on.

The fallacy of the open-door policy

One thing managers have to keep in mind is that a part of their job is to ferret out problems proactively.

The open-door policy is nice in theory, but it takes an extremely brave engineer to willingly take the risk of going to their boss to tell him about problems.

When you manage managers, you ultimately evaluate them on the performance of their teams.

Part of the job is simply to make sure that your 1–1s have room for real conversations.

Skip-Level meetings

A skip-level meeting it’s a meeting with people who report to people who report to you. Their purpose is to help you get perspectives on the health and focus of your teams.

It’s a short 1–1 meeting, held perhaps once a quarter, between the head of an organization and each person in that organization.

It’s a personal relationship between you and everyone in your organization. It also gives individuals time to ask you questions.

Each person should come prepared to focus on what they are interested in talking to you about.

Skip-level meetings are one of the critical keys to successful management at levels of remove.

The purpose of the skip-level process, beyond maintaining trust and engagement, is to help you detect places in which you’re being “managed up” well, to the detriment of the team under that manager.

Skip-level meetings are a chance to hear the other side of the story, to get a reality check from the people on the ground.

Suggested prompts for a skip-level 1–1:

  • What do you like best/worst about the project you are working on?
  • Who on your team has been doing really well recently?
  • Do you have any feedback about your manager, what’s going well, what isn’t?
  • What changes do you think we could make to the product?
  • Are there any opportunities you think we might be missing?
  • How do you think the organization is doing overall? Anything we could be doing better/more/less?
  • Are there any areas of the business strategy you don’t understand?
  • What’s keeping you from doing your best work right now?
  • How (un)happy are you working at the company?
  • What could we do to make working at the company more fun?

If you have a larger organization, and can’t meet up with everyone on a 1:1, there are other ways to get skip-level time. Like holding lunches with whole teams a couple of times a quarter for each team. It doesn’t give you the focus to give career coaching to individuals, but it does help you get a sense of the group dynamics and get feedback directly from the teams. Skip-level lunches provide familiarity, which in turn generates more willingness for people to come to you.

Some questions that can be used to draw out information:

  • What can I, your manager’s manager, provide for you or your team? Anything I should be helping with?
  • Is this team working poorly with any other teams, from your perspective?
  • Are there any questions about the larger organization I can answer?

At this level, you’re constantly making tradeoffs between investing in expensive engagements, such as 1–1s, or casual engagements that are more efficient but provide less detailed information.

Manager Accountability

There is one universal goal for your managers: they should make your life easier. Your managers should allow you to spend more time on the bigger picture, and less time on the details of any one team.

This small piece of expertise — learning how to hold managers accountable — will be one of your biggest learning opportunities as you work at this level.

Common scenarios:

  • Unstable product road map: When the product organization is constantly changing goals, the manager should identify that the changes are causing problems on the team, and work with product to explain the problem and refocus on what’s important.
  • Errant tech lead: When the tech lead is down a rabbit hole, the manager has to bring that person out and work with him to figure out how to make the design process more transparent.
  • Full-time firefighting mode: If the team can’t do anything but fight fires, the manager should put together a plan for tackling the causes of these fires, and if necessary bring requests for hiring more people or adding more people to the team so that they can get the situation under control.

Despite the mitigating circumstances in ease case, the manager ultimately needs to take responsibility for pulling the team out of these situations and getting them move forward, because the manager is accountable for the health and productivity of the team.

Managers need coaching and guidance in the same way that individual contributors need coaching and guidance. You’ll need to help your managers:

  • Sometimes they don’t have the clout to push back against product and need your support
  • They may need your help finding other senior people to partner with their tech lead
  • You will have to approve requests for more people to fight fires

Your managers have done the hard work of identifying the problems, but you need to then help find the solutions or support the path forward.

This is what making your job easier looks like — not hiding information, but bringing you clear problems before they turn into raging fires.

Good manager, bad manager: the people pleaser

The people pleaser has deep aversion to ever directly making people they care about unhappy. If you’re in the group that they care about, they will always say yes. People pleasers often burn themselves out.

  • Their team loves them as a person but is increasingly frustrated with them as a manager.
  • They are more interested in a team that runs smoothly and avoids mistakes than really become excellent.
  • When they are feeling bad, they wear it on their face, and the whole team lose confidence.
  • They never push back work.
  • They overpromise and underdeliver.
  • They says yes to everyone and send contradictory messages.
  • They seem to know about all of the problems, but haven’t directly addressed any of them.

Types of pleasers:

  • The therapist people pleaser: can inspire huge loyalty, but unfortunately this can mean they amplify drama and negativity, and disappoints their team by making promises that they cannot possibly keep. A team pleaser fails by promising things that aren’t realistic, making the team bitter toward either the manager or the company for failure to live up to these inflated expectations.
  • The external pleaser: the one that wants to make their boss and their external team partners happy, and is terrified of revealing problems to their team. An externally focused people pleaser shuts down honest conversation by evasion.

If it happens you end up managing somebody in this situation, you can work on helping the person feel safer saying no and externalizing more decisions so they don’t take failure personally:

  • Providing strong partners who can take on the task of determining the work roadmap.
  • Creating better processes for getting work scheduled
  • Having a structure that specifies the requirements for getting promotions or accessing other opportunities, the people pleaser can rightly point to the process as something outside of their control.

One of the best things you can do is show the person that they are exhibiting the behaviour, and highlight the downsides.

Managing new managers

First-time managers need a lot of coaching, it will be an up-front cost that pays long-term dividends for your organization.

No book or training can replace you spending quality time asking your new manager how their 1–1s are going.

When people start quitting because their manager hasn’t give them a career path or isn’t inspiring them, it’s ultimately your responsibility. Use skip-level meeting to help out detect areas where you need to support your new manager fully.

A new manager who is working all the time is probably failing to hand off their old responsibilities to other people on their team. Make it clear that you expect the new manager to hand off some of their old work, and help them identify opportunities to do so.

Managers who neglect the job are bad, but managers that take to the job with gusto because they believe it’s the key to realizing authority are worse. A skip-level meeting will reveal their frustration that they have no ability to make decisions themselves. If your new manager is skipping your 1–1s or evading questions about what the team is working on, you may have a control freak on your hands.

The manager you are training should be ultimately making your job easier. Clearly set the expectations up front that you’ll hold them accountable for the team, and help them build the skills to achieve this.

If they truly don’t have the willingness to learn and the aptitude to become solid managers, they’re a big problem. Making the wrong person a manager is a mistake, but keeping them in that position once you’ve realized they are wrong for it is a critical error.

Managing experienced managers

The right experienced manager knows what needs to be done and does it without needing help from you to get there.

Management tends to be a very culture-specific task in a company, if you either work as a manager or hire a manager for a company that’s not a good culture fit, you’ll have problems.

First challenge is making sure this person fits in with the culture of your team. Often we overvalue expertise in product areas and allow it to blind us to cultural and process fit with our companies and teams.

You need managers who understand how to work with teams who ship software frequently, who are comfortable with modern development process best practices, and who can inspire creative product-centric engineers. These skills are so much more important than industry-specific knowledge.

Collaborate on areas of difference, allow them to teach you things, and take an active role in the process.

Hiring managers

Hiring for managers, is a multipart exercise. First, make sure that the person has the skills you need, then make sure that they are a culture match for your organization.

Critical elements to hiring a new managers: the reference check. Ask the references to describe the ways the person succeeds as well as the ways they fail. Ask them if they would work with or for this person again.

You can verify the latter by asking the people who would report to the new manager to interview them by asking them to help with problems they have right now, or have had in the recent past. You can role-play difficult situations, like dealing with an employee who is underperforming, or delivering a negative performance review.

A manager must be able to debug teams. Ask the manager to describe a time when then ran a project that was behind schedule, and what they did in that scenario. Ask them to role-play with an employee who is thinking about quitting. Describe how they have coached employees who were struggling.

Ask about their management philosophy. If they don’t have one at all, that might be a red flag. What’s the role for a manager? How do they stay hands-on, how do they delegate?

Speaking skills are useful for certain types of leadership but not all. Give them an abbreviated version of your standard technical interview.

To check for cultural fit, you need first to understand the values of the company around you. If you value servant-leadership and you hire a manager who wants to dictate exact marching orders to the team, there will be a bad fit. Similarly, if you value collaboration and hire a manager who thinks that the loudest voice in any conversation should win, you will also have problems.

Managers shape their teams to their culture. If you hire a manager who doesn’t fit culturally with the team they are managing, the manager will fail and you’ll have to fire them, or most of the team will quit and then you may still have to fire them.

Most new hires act in self-interest until they get to know their colleagues, and then they move into group interest.

Managing outside your skills-set

My background is in web engineering. However, I started managing cross-platform teams outside my skills-set. Below is some advice on how to do that well:

  • Apply the same mentorship mindset — Be very curious, ask a lot of questions, but in an open way.
  • Make it clear that your goal is to understand what people do so that you’ll be capable of appreciating it better.
  • Be prepared to devote significant time to the areas new to you.
  • Practice asking for details about those areas, so that you can start to learn and develop a sense for what the people in that team are actually doing.
  • Take time to get to know the manager and employees in the team using 1:1s with your direct reports and skip-level meetings.

Debugging dysfunctional organizations

The best engineering managers are often great debuggers. A great debugger is relentless in the pursuit of the “why” for a bug.

Managing teams is a series of complex black boxes interacting with other black boxes. These black boxes have inputs and outputs that can be observed. When the outputs aren’t as expected, figuring out why requires trying to open them up and see what’s going on inside.

So how do you figure this out?

  • Have a hypothesis: To debug a team, you need a reasonable hypothesis around why the team is having problems. Do this in a minimally invasive way as possible, to prevent your meddling from obscuring the problems.
  • Check the data: When you debug teams that are not producing fast enough, look at the records; look at the team chats and emails, look at the tickets, look at the repository code reviews and check-ins. What do you see? Look at their calendars.
  • Observe the team: Perhaps everything seems OK in all of these indicators. Now is the time to start doing some potentially destructive investigations. Sit in their meetings. Are the boring to you? Is the team bored? They may be a sign of inefficient planning on the part of the organizers. Good meetings have heavy discussion element, where opinions and ideas are drawn out of the team. Be aware though; The act of observing changes the outcome, or rather, causes an outcome to happen. Your presence might provoke hiding the problem you’re trying to find, at least for sometime.
  • Ask questions: Ask the team what their goals are. Can they tell you? If they don’t understand the goals of their work, their leaders aren’t doing a good job engaging the team in the purpose of the work.
  • Check the team dynamics: A bunch of people who never talk to each other and are always working on independent projects are not really working as a team. Professional and dynamic groups tend to have a degree of personal connection between the members.
  • Jump into help: It’s OK to jump in and help debug team issues as you see them, particularly when the manager in question is struggling. It can be an opportunity to teach the manager and help him grow.
  • Be curious: The pursuit of why when it comes to organizational problems is the thing that gives you patterns to match on, and lessons to lead with. We get better at debugging by doing it often. We become better leaders by pushing ourselves and our management teams to really get into the bottom of the organizational issues.

Setting expectations and delivering on schedule

One of the most frustrating questions that engineering managers get asked regularly is Why something is taking so long? Answering it is significantly harder when you aren’t embedded deeply in the details.

Sadly, we are often asked this questions in times when things are not taking any longer than the estimate.

You must always be aggressive about sharing estimates and updates to estimates, even when people don’t ask. You must be aggressive about getting estimates.

Estimates are often useful even if they aren’t perfectly accurate because they help escalate complexity to the rest of the team.

Not every project necessarily has requirements that change frequently, and it’s possible to do up-front work to drastically reduce the unknowns that make software estimation difficult.

Business want to plan and get ideas of cost for effort. Teaching your teams how to hone their instincts about complexity and opportunity is worthy goal.

Finally, don’t be afraid to cut scope toward the end of the project in order to make important deadlines.

Challenging situations: roadmap uncertainty

A common problem that managers at all levels face is the challenge of changing product and business roadmaps.

The reasons of these changes usually depends on the how big the company is:

  • Small companies: It’s hard to get people to commit a year in advance to the work that will be done for the next year.
  • Large companies: Changes in the market can lead to sudden shifts in strategy that cause projects to be abandoned and planned work to be cancelled.

Strategies for handling roadmap uncertainty:

  • Be realistic: Be realistic about the likelihood of changing plans given the size and stage of the company you work for.
  • Break down big projects: Think about how to break down big projects into a series of smaller deliverables so that you can achieve some of the results, even if you don’t necessarily complete the grand vision. Everything must be repeatedly re-examined with an eye toward what’s the most valuable right now.
  • Don’t overpromise a future of technical projects: This will get hopes up and then disappoint.
  • The 20% rule: Dedicate 20% of your team’s schedule to “sustaining engineering”. Allowing time for refactoring, fixing bugs, improving engineering processes, doing minor cleanups, and providing ongoing support.
  • Understand how important engineering projects really are
  • Pick your battles: Treat big technical projects the same way as product initiatives. Gather data to support yourself, and talk about what will be possible when the work is done.

Staying technically relevant

Strategies to remain technically relevant:

  • Oversee technical investment: You’re accountable for making sure the team is placing its technical best in the right places. You can see where the ares of greatest need or opportunity lie.
  • Ask informed questions: Having accountability doesn’t mean that you personally do the research to find potential investments. You guide these investments by asking questions. You need to know enough about the work to sniff out misguided efforts and evaluate proposed investments.
  • Analyze and explain engineering and business tradeoff: Understanding the business and customer goals, you offer guidance as to which technical projects can achieve those goals within reasonable time frames.
  • Make specific requests: You still need to have enough understanding of the technology in your organization to make specific requests without distracting the senior engineers with questions. Managers who don’t stay technical enough relay these questions on the team, and then relay the team’s response back up to management. This is not value-add role.
  • Read code: Looking over code reviews and pull requests can give you insight into changes that are happening.
  • Pick an unknown area: Ask an engineer to explain it to you. Have him pair with you on a small change.
  • Attend postmortems: In times of failure you can most clearly see where problems have built up.
  • Keep up with industry trends in software development process: Make time to learn about how other teams deliver software.
  • Networking: Foster a network of technical people outside your company.

Never stop learning!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store