As staff engineers go through the transition to manager, they need to realize they've accepted a new job.

What worked as a staff will not necessarily work as a manager. Dealing with legacy systems can be messy, but working with people is always a delicate dance. You need to develop a new set of skills.

In the two years that I've been a manager, these 3 challenges have shaped me and forced me to adapt to that new reality. I hope they can reframe some of your experiences and help you navigate this transition better.

Learning to delegate tasks

It is such a silly thing, but when people asked me something in a private Slack message, I assumed they wanted me to solve it, personally.

In reality, they were asking my team to do something about their problem. I usually didn't want to bother my team members, to protect their focus time. And so I little by little took on more than I could manage.

No one seemed to appreciate the sacrifice as it was mostly invisible. When my team members would not stay focused and pursue side quests instead, I would become very frustrated. But that was on me.

I had a team and it was my job to drive it to get the results the organization expected—I had to delegate clearly and follow up. Give ownership, not instructions.

Managing former peers

If you stay within the same team (which seems to be quite a common situation from anecdotal experience), it can be difficult to exert authority when you all used to be peers or still consider yourselves as peers.

Everything becomes a negotiation of sorts. You need to prove the value you bring to the team as a manager so that they may start considering giving in on some things. Even if you have the last word institutionally, that's not how you can inspire your team to do better.

What I found to work great in my case was putting extra attention on 1:1s. It's often something managers struggle with, and so any value you can provide there is unexpected and pays off disproportionately to the effort. Example topics of discussion:

• career goals and aspirations

• good feedback on something they've done well

• exploration of areas where they could improve

You show you care and want them to grow.

Balancing personal work and team management

As a staff engineer, I had (and still have) a lot of context about our systems.

It's always very tempting to be hands-on when I see a problem that I know how to solve. It's familiar, a reminder of what I used to do every day. A nice distraction from my current duties.

But it's almost always a terrible idea.

The corresponding Jira ticket ends up stuck, because I'm quickly reminded I should be:

• removing blockers,

• making sure the team is working on what matters,

• and sharing my knowledge to grow and empower team members,

and not:

• make a bottleneck of myself,

• increase my workload unnecessarily,

• appear distracted (while wanting the team to focus).