5 ways to quickly fail as a new engineering manager

If you’re an engineering manager, you have likely followed a path similar to mine and many others. You’ve been a software engineer for many years. You’ve earned a senior title and probably became a tech lead. You may have been fighting the promotion to be a manager for some time because you didn’t want to do less coding and lose your skills.

You might have been also afraid that you wouldn’t do as well in the new role. But finally, somehow, you were convinced to take the chance to shift from senior engineer to junior manager. How will you succeed?

I’m not here to pretend that I have the secret to success. But I do know a few ways that can guarantee you’ll fail.

1. Continuing to code

Your company may expect you to be a manager and an individual contributor at the same time. In my experience, though, that usually fails.

You won’t be able to consistently give the attention that either role requires, so you’ll fail at both. But if you’re lucky, the company you work for is like mine, where I practically signed an oath saying I wouldn’t code.

Even if some coding is expected of you, it certainly is no longer your main purpose in the company. What I’m really talking about is when you fall back into coding because you aren’t sure what the heck to do in your new role. You return to what you know because that’s where you’re comfortable.

This might provide short-term benefit to some projects and make you feel good, but I can guarantee that you won’t achieve your primary objectives. You’ll hurt the long-term output of your team, and you’re also not growing in your new job.

I don’t think any of us want to simply give up on our valuable and hard-earned technical experience. So read this article for some good options if you want to keep your coding chops.

2. Focusing only on the work, not the people

As a manager, you have two important duties: to grow the team and to deliver value to the business. I’d argue that you should prioritize them in that order.

The typical idea of delivering value is completing projects, shipping features, fixing bugs, etc. This often results in you acting as a project manager or taskmaster, focusing on assigning tickets, tracking metrics, asking for status updates, leading design discussions, and so on. In short, you’re focused on the work of the team. You can check things off the list each day and feel like you’re getting things done.

But this is the easier half of your role. The other half is harder – it involves helping individuals do their jobs well, both in terms of their technical skills and productivity, as well as listening, coaching, and having one-on-one meetings with your team members. If you ignore this part of your job, you’re leaving a lot of value on the factory floor.

The effectiveness of the team, along with the ultimate value it produces, starts with the members themselves, not their work.

3. Measuring your value by your output

Back when you were an individual contributor, it was easy to quantify your output or value. You tell yourself: “I finished two stories today,” “I figured out that crazy bug,” or “I’ve got all the tests passing.” These were tangible units of work, easily tied to the team’s deliverables. And those commits have your name on them.

But now, much of your impact is seen in second-order effects. It’s harder to draw the correlation of your work to that of the team’s. Adding to this confusion is the fact that your work is no longer neatly defined by well-prescribed tasks. You might not even be really sure about what work you do.

As a new manager, you tend to grasp at the few concrete tasks you have and use those to get a feeling of accomplishment. In truth, your work is reflected in the work of the team. Having them accomplish their goals is your goal. Your value is ultimately measured by their success.

4. Leaving the team out of commitments

5. Avoiding hard conversations