Stepping up from line management to being a manager of managers is a daunting business. You've learned how to run a team, how to delegate effectively, how to manage junior and senior ICs and develop their careers. You've put a high functioning team together, and people across the company know what they're responsible for and some of what you've achieved.

The job now is different. You need to empower your managers, and give them the freedom and flexibility to lead in their own authentic way. You need to trust them but still ask questions; you need to verify what's getting done without micromanaging.

You're still responsible for everything your teams do, but are now a step further away: the job is leading without direct control.

At the same time your other responsibilities have increased. At smaller companies you're likely called Director now, at bigger ones perhaps there's an intermediate Senior Manager role. Either way, you are responsible for more of the total engineering output.

You need to deliver but also to strategize. You're looking beyond individual software projects and into Initiative-sized deliverables, spanning your teams and others, with timelines stretched over several quarters.

Technical and procedural bottlenecks have a much higher cost, and solving them has greater rewards. At the same time getting those changes made requires more people, more time, more buy-in from other senior folk. Your role is increasingly to sponsor and influence the right projects, and to create an environment where your senior technical staff feel empowered to suggest those things to you.

As you grow from line management into senior management you have both the authority and the responsibility to make sure your org maps to needs of the company. Think of this a bit like that Japanese gameshow where walls fly down a conveyor belt with vaguely human-shaped holes in them. Contestants contort themselves into the right shape to fit through the hole before inevitably being knocked flat. The contestant is your org; the boxes are software projects; the increasing difficulty level is the changing needs of the business multiplied by your technical debt. As the leader you’re free to CRUD teams, re-align people’s roles and sponsor re-platforming as you see fit (knowing that these things are very disruptive and expensive, so do them sparingly).

What you want is:

1. Clear lines of ownership. In an ideal world incoming work maps perfectly to your team structure. In the real world you need to look around the corner to see what’s coming next. If every new thing feels like an awkward box-packing exercise, consider making structural changes.
2. Understand the state of the business to give you the right incentives and vocabulary to plan a re-org, and this includes technical platform changes. Base them on new lines of business, cost savings, improving performance, internationalization - whatever the overarching strategies are. “Improving speed of delivery” is table stakes and not sufficient to justify such a big lift. Committing to team changes or a technical re-platforming because your tech leads are grumpy will correctly receive short shrift.
3. Plan it out, you don’t have to do it all at once. The first span of control document I wrote was a hiring plan, and basically described the organization I was going to build and the systems they’d run. This was a great introduction because it’s a lot easier to debate on paper, and I got to implement it over 12 months (mostly gated by hiring speed). As a result I was able to spend time preparing people with their new remits and introduce them to the business piecemeal. This was unusual - you’ll often need to act faster - but the point is these things don’t need to be rushed. Cascading dependencies exist between people, systems ownership and domain expertise and making too many changes in parallel can be overwhelming. Take a little time and plan it, create champions and get your leads working with you.

When you first become a manager to other managers you might wonder what it is you should be doing all day. You want to trust your managers to operate their teams their way and not interfere. The most obvious direct action to take would seem like being responsible for a lot of the interviewing and hiring. Which is helpful, but if that’s all you do you’ll find yourself going between 1:1’s with your managers, being hands-off in their world so you just get their problems of the day, then putting that together for your manager. You become a very highly paid therapist and recruiter.

Managing managers is no different than managing engineers, you need to be involved and hands-on in their work. But the amount you’re building into the future has changed, your span of control has increased, so you have more to go between. This is the job now, representing a group of teams, understanding each of their areas and how they make sense together, and building out farther in your business domain.

It’s easy to underestimate the blast radius of a bad manager, especially if you’ve been lucky and never had one. There’s a pretty well known phrase, “people don’t leave bad companies, they leave bad managers.” It’s exaggerated for effect but there’s truth there. Your managers are responsible for productivity and morale, just the same as you were, and no-one is capable of doing more damage at the team level. It’s all about incentives again - managers have the levers to reward and punish, so they hold a particular power.

When you manage managers your responsibility to trust and verify increases. The best source of information is your more experienced ICs, who may have previously been your direct reports.

Have skip level 1-1s (not too frequently, perhaps monthly) and listen to what they tell you. People in this situation will naturally compare styles and may critique based on that, but different isn’t bad: a range of leadership styles can be a strength. As with many things, your best information will be in the form of stories: in a given situation, what happened, how was it dealt with, what were the outcomes. Take these stories and run any concerns by your managers (you may choose to anonymise the examples).

This might feel like micromanagement but it’s not; skip level 1-1s are partly for this specific thing. Over time you should expect to hear fewer concerns as the new manager builds trust with their team.

If you’ve promoted someone into a managerial position for the first time, your job is to train them.

Skip levels with your senior ICs are a very good idea, but in this case you want to stay closer to the day to day so have them more frequently. You want to push your new manager into the non-technical side early, as it’s a good tell for whether they’ll be successful. They need to be curious about the business, keen to meet people in different roles, get used to presenting well to senior audiences, interested in the value of their software to the company above how it’s built, or how well it runs. And get them to read our guide on being a new manager!

One thing to think hard about when making managers is emotional maturity, and a little bit of selflessness. They will fail if they don’t care about their team, individually and collectively, at least as much as they care about themselves. Their team’s collective success is their success, and new managers need to understand and buy into that entirely.

In our industry there are a lot of very smart, very capable people who see their careers as kind of a game. The game is won by maximizing personal income: working on the right things, in the right teams, knowing the right people, moving on when forward progress isn’t happening. This leads to top performance scores, promotions, salary increases via company moves. Given pay scales and the way tech companies incentivize, this is inevitable.

Be very cautious not to put people who think this way into management positions. They can be outstanding ICs but make terrible people managers, as their primary success metric is always their own position and compensation.