If you’re managing managers for the first time in your career, here’s how to set yourself up for success.
Congratulations! You’ve been promoted or hired to manage managers for the first time. Get ready though, because you’re about to find yourself in a whole new role.
At some point in the past, you’ve probably moved from an individual contributor to a manager role, and had to learn a whole new set of skills and behaviors. You’ve survived and thrived in one transition, so how can you do the same this time?
One big change is that while before you were managing teams directly, now the teams are no longer yours to manage in the day to day. Instead, someone who reports to you will take care of that, and your main job is to take care of that someone. But don’t relax too much: you’re still responsible and accountable for the success of the teams.
A key challenge is learning how to grow the individual managers who report to you, and make them stronger. You’ll also need to learn how to manage relationships with your skip-level reports, which will be very different to the ones with your direct reports.
In this article, I’ll break these challenges down, and share some ways to set yourself up for success in your new role.
Helping your reports to grow into better managers
In your previous role as an engineering manager, you were already helping your reports to grow. But while you were looking for areas where folks could improve as individual contributors, you’re now looking for ways they can grow as managers.
A crucial part of your job is to identify what strengths exist and what areas will need work in each of your reports. It’s all about identifying which tools you need to help them add to their toolbox.
A report’s skill level will depend on their experience and the path they’ve walked to get here. We can assume (and hope) that they have at least some level of natural leadership skill if they’ve been hired as a manager, but as you know, there’s a lot more to management than that.
To identify areas where you can help your reports grow, sit down with each person and discuss the below points. The goal is to understand where they already shine and where they don’t in four key areas: managing themselves, people, processes, and products. You can then use your own experience, and the vast amount of resources available online, to find ways to fill the gaps.
Managing themselves:
Time management:
Are your reports drowning in meetings and tasks? If so, there is no way they’ll be able to grow.
You will need to help them understand which meetings to attend, which to drop, and which to change in frequency, and how to categorize urgent vs non-urgent, and important vs unimportant work.
Help them to understand that adding management tools to their toolset is extremely important. Actually, learning more skills frees up time, simply because trying to unscrew a screw with a hammer takes a long time, so they’ll need to procure a screwdriver.
Admin duties:
Management involves a lot of paperwork, from writing up pay reviews to approving annual leave. Are they on top of this work? Help them to understand that doing this in a timely fashion prevents attrition and anxiety, for them and their reports.
Managing their people:
1:1s with their reports:
Do they understand how to run a good 1:1? Do they have an effective template and list of questions?
People development:
Are they focusing on making individuals better? This should include coaching, which is a wide discipline, and the more they get into it, the better. They can start by looking at the GROW model. People development should also involve giving helpful feedback. Whether positive or negative, good feedback is golden. Finally, they should be having regular career conversations to help reports focus on longer term goals and opportunities.
Performance management:
These processes can vary wildly from company to company, but one thing stays the same: facts and examples are important. Are your reports preparing for performance reviews effectively by gathering evidence of their own reports’ work?
Do they understand that promotions should be the result of a walk on an agreed path, and not a surprise? Are they helping their reports to perform consistently at the next level, so they can put them forward for promotion?
Are they confident in managing underperformance? If not, help them to understand that performance improvement plans are painful, but they shouldn’t shy away from them. The alternative of allowing an underperformer to keep underperforming is much more painful.
Hiring duties:
If you have any open headcount, hiring should be the top priority for your managers, and you need to make this priority clear.
Do they know how to create attractive and balanced open job specs? Are they trained and experienced in hiring processes? These should be unbiased, repeatable, and fair. Using hiring rubrics helps. Do they understand the process for making a hiring decision? The manager should own the decision, and aim for the candidate’s success in the team, not for consensus from the team in the decision.
Creating a positive team dynamic:
Taking care of individuals is great fun, but ultimately your reports are managing teams. Can they read and manage the team dynamics so folks can perform well? Are they creating a team culture built on psychological safety and trust?
You might want to share a couple of useful models on team dynamics, for example, Tuckman’s stages of groups development (i.e. forming, storming, norming, performing), and the five dysfunctions of a team, by P. Lencioni.
Team planning:
Are your reports planning for their teams with balance in mind? Are they balancing seniority and energy in staff, product knowledge and engineering rigor, and quick delivery times with engineer wellbeing?
As part of their planning, have they identified and communicated a team mission to help drive people forwards?
Advocating for their reports:
‘If a tree falls in a forest and no one is around to hear it, does it make a sound?’ In the engineering management world, it simply doesn’t matter: if no one hears about a piece of work, it hasn’t happened.
Help your reports to understand that a big part of their work as managers is to make other people aware of the value their teams are producing. Communicating success gives their reports an opportunity to build relationships with important stakeholders, which might help to grow their careers in the long run.
Managing their processes
Your reports need to understand the processes within your organization, and train their teams accordingly. We won’t go into details of best practices for software engineering, but here are a few things you need to make sure your managers are aware of.
Agile processes:
Do your reports have a documented Agile process in place? How prescriptive you want to be here depends on you and your company. Many teams succeed with simply either Scrum or Kanban, but there are many other flavors out there if those don’t work for you.
Code release processes:
Are they making sure their teams are continuously deploying and integrating new code and features? Shipping code often and continuously reduces rates of errors. Is their team’s code stored in a versioned repository (e.g. git), with defined rules around how to branch and develop code, and how to merge new code into the main branch (e.g. code reviews from peers)? Depending on the scale, they could also consider processes such as green/blue deployments, or feature flags, or both.
Managing exceptions:
Make sure your reports have well-defined processes for the following:
- Bugs management
- Incident management
- Security vulnerabilities
It would be nice if we could just develop features and immediately push them to production, but this isn’t the real world. Make sure your reports are prepared to manage things that go wrong.
Metrics, metrics, metrics:
Are your reports comfortable finding and using meaningful metrics? Work with them to track key indicators, and visualize the metrics through quick summary dashboards which allow you to detect when there is a problem. If you identify that a problem exists, don’t jump to conclusions before talking with your reports.
Decision-making:
Are your reports confident and capable when it comes to driving decisions forward? Teams rarely make decisions easily with consensus, and frankly if you see that happening too often, you should worry that there isn’t enough diversity of thought in the teams.
Some decisions are urgent, some less so. Some carry a big risk, some are easily reversible. Your managers should be equipped with a model that defines what to decide, when and how.
Managing their products
This section is about assessing your managers’ skills when it comes to building software, both from a pure product perspective and from a technical perspective. The details will be different for different companies and products, but many of the principles will remain the same.
Understanding the product:
Engineering managers are and should be part of product decisions, which means they should understand the product they’re building at least as well as a user. Are your reports clear on what represents value for a customer, and how to express the outcome of their team’s work in terms of customer value? This will give them a distinct advantage in their ability to execute their job.
Understanding the product management process:
When the product manager isn’t present, either temporarily or structurally, your reports should be able to step in and play that role.
Are they familiar with the product roadmap itself? Do they understand what should come next, and why? This not only helps in terms of execution, but also in motivating the team.
Understanding the technical aspects:
Engineering managers are responsible for guiding their teams to deliver maximum value to customers. Customers don’t just buy products for their explicit value, but also for their implicit value, or what we could call ‘non-functional requirements’.
My opinion is that your reports should aim to have a broad, rather than deep, understanding of the technical aspects of their products: do they understand the architecture and technologies well enough to be able to take part in technical conversations, and break a tie if there’s indecision between team members?
Do they understand the implicit or explicit agreements your company has with our customers on the non-functional requirements, such as security, availability, reliability, and all the other ilities?
Lastly, are they comfortable managing the internal efficiency aspects, such as monetary costs, and how the complexity of the system affects onboarding and maintenance?
Managing, supporting, and building relationships with skip-level reports
Skip-level reports are the people who report to the people who report to you. You are still responsible and accountable for their work and wellbeing, but at the same time, you have to remember that you’re not their direct manager. As much as possible, you need to work to make sure that their relationship is stronger with their direct manager than with you.
Skip reports are your best source of info about what’s happening on the ground and within the teams, meaning you absolutely need skip-level 1:1s. These meetings should be regular but, obviously, not as frequent as direct-level 1:1s. Find a cadence that works for you, but once a month is a good place to start.
They should also have a very different structure to direct 1:1s, because you’re not their manager! Without going into too much detail, you need to understand whether everything is working well in the team, and in their relationship with their manager. So, after the standard, ‘How are you?’, and, ‘What’s on your mind?’, I advise to go always for the same set of questions:
- What’s your relationship with your team members?
- How do you think your team is doing?
- Is your manager taking care of you? Do you discuss your career goals? Do you discuss your daily and weekly work?
- Do you have any feedback on your manager that I should be hearing?
- What can I do for you?
- Do you have questions for me around what’s happening in the company?
- Is there anything I should hear and report upwards?
Every now and then, you can also remind them that your role allows you to seek different opportunities for them in case it is not working with their team. It’s natural for people to want to change, so let them know they can change if need be.
Remember that one comment from one skip report doesn’t represent the mood of the team, but if you hear the same thing over and over, you have to consider it as confirmed information.
Lastly, it’s important to resist the urge to act on any comment you hear, whatever comes back. Instead, speak to your direct report, and try to understand the context. If necessary, you can then work with them to help them to course correct.
Reflections
Becoming a manager of managers for the first time is exciting. You’ll be leaning on many of the skills you learned as an engineering manager, while also gaining new experiences and perspectives. It takes a change of mindset to go from helping folks to grow as engineers, to helping folks grow as managers, and taking on the new responsibility of supporting skip-level reports, but it’s rewarding work. I hope this article will help you to create impact in your first few months. Now, go have fun!
