Growing Managers

Every team needs a manager, and most engineering managers got the job because they were good engineers and someone needed to run the team. That's a reasonable place to find candidates and a terrible way to prepare them: the skills that made someone a great engineer aren't the ones the new job rewards, and nobody tells them. Growing managers well means being deliberate about who moves, what they're told, and how they're supported.

A Different Job, Not a Promotion

I treat moving into management as a career change: a lateral move onto the other track of the career ladder, where a staff engineer and an engineering manager are peers in level, pay and influence. If the only way to a raise is managing people, you get managers who wanted the raise. Charity Majors makes the case well: management is a change of profession, and the best technical leaders often move back and forth. Trying it isn't a one-way door, and staying an engineer isn't a lack of ambition.

Who Should Move

When someone asks to become a manager, I ask why, and listen for the answer that predicts success: they care about the people and the system around the work, and already do some of it. They mentor unasked, notice when someone's struggling, run the retro that actually changes something.

The answers that worry me:

• "It's the next step." It isn't, and if our ladder made them believe it is, that's a problem to fix in the ladder.
• "I want to make the decisions." Managers make fewer technical decisions, not more. The job is helping the team make good ones.
• "Nobody else will." Sometimes true, and sometimes a good reason, but it needs to come with genuine interest, or it becomes a resentful year for everyone.

Before anyone moves, I give them a taste: run a project end to end, mentor a newer engineer, lead hiring for a role. Most people learn quickly whether they like it, and either answer is a good outcome.

What Changes

Output now comes through other people. A new manager's best day used to be shipping something; now it's a week where the team shipped three things without them. That feels like doing nothing, so new managers cope by staying on the critical path, writing code that blocks a release or being the reviewer every PR waits on, which caps the team at their own throughput. The job is leverage: hiring well, clear direction, removing obstacles, growing people, a team that works when you're on vacation. Stay technical (design reviews, pairing, incident reports) but off the critical path.

The feedback loop changes too. Code compiles or it doesn't, today; whether you handled a hard conversation well shows up in months. New managers need someone telling them how they're doing, because the job won't.

The First 90 Days

I give new managers a plan, because "figure it out" is how bad habits form.

• First 30 days, listen. Start 1:1s with every report in the first week. Ask what's working, what isn't, what they'd change, and what they need from a manager. Learn the systems the team owns and its on-call reality. Change nothing structural yet.
• Days 30 to 60, find the one thing. From what they've heard, pick the one or two problems that matter most to the team and fix them visibly. Early credibility comes from solving something people already complained about, not from a new process.
• Days 60 to 90, set direction. Write down how the team works, what it's for this quarter, and how they'll know it's working. Give the first round of real feedback, positive and corrective, so it's normal before it's ever hard.

Throughout, I meet them weekly about their first difficult conversations, where their time goes, and what they're avoiding.

Managing Managers

Once you manage managers, you see the work through them, filtered by what they think is worth telling you. Two habits fix most of that.

Skip-levels. I meet regularly with my reports' reports, not to go around their manager but to hear how the team actually feels. The rule I hold myself to: I don't solve problems in a skip-level that belong to their manager. I bring the theme back to the manager and help them solve it, or the team learns to route around them.

Coach the management, not just the results. In my 1:1s with managers, I ask about their people: who's growing, who's stuck, who might leave, what feedback they've given lately. I ask to see a performance review draft before it goes out, and I'll role-play a difficult conversation with them before they have it. Managers rarely get feedback on their 1:1s or their feedback skills because nobody else is in the room. I make a point of asking their reports how those are going, in skip-levels, and passing it on.

Hiring Managers

Hiring a manager from outside follows the same principles as any hiring loop: define the bar first, structure the interviews, and test with something that looks like the job. For managers, the job is people and judgment, so the work samples are different:

• A people scenario. A strong engineer's performance has slipped for two months. Walk through what you do. Listen for curiosity before conclusions.
• A prioritization exercise. Three urgent requests, one team, and a reliability problem nobody's prioritized. What happens?
• A technical conversation deep enough to tell whether they'll earn the team's trust on design reviews, without requiring them to out-code the team.
• References from their reports, not only their manager. How someone treats the people below them is the thing you most need to know and the hardest to see in an interview.

Promoting from within is usually less risky, since you've seen the person work, but managing former peers is hard, and I talk it through with them before they start.

The Pendulum

Some people try management and discover they miss building. That should be easy and celebrated, not a quiet admission of failure, and the engineers who come back usually come back better: they understand why decisions get made, explain trade-offs more clearly, and are more patient with process. Equivalent levels make it real, so going back costs neither pay nor title; saying out loud that it was a good call does the rest.

Failure Modes

The ways new managers struggle are predictable, so I watch for them:

• The hero. Still the best engineer on the team, and acts like it. The team learns to wait for them.
• The shield. Protects the team from all context. Feels kind, leaves the team unable to make good decisions.
• The friend. Avoids feedback to keep the peace. Small problems grow until they become performance problems nobody saw coming.
• The process builder. Answers every problem with a new meeting or template. Ask whether the problem is real first.
• The absent manager. Cancels 1:1s when things get busy, which is exactly when they matter most.

None of these are character flaws. They're the default behaviors of a smart person in a job they weren't trained for, and the fix is the same each time: notice early, name it kindly, and coach.

References

In practice

• Charity Majors: The Engineer/Manager Pendulum, management as a change of profession rather than a promotion, and why the best technical leaders often go back and forth between the two