For years, you’ve been toiling away as a software development individual contributor (IC), and now your great work has been rewarded with a promotion to engineering manager. 

Now what?

Dylan Etkin has been an engineering manager for a good portion of his career, and now is a co-founder of Sleuth.io, a company focused on helping organizations continuously improve their software delivery through the use of metrics. He has seen it all, and lists five common mistakes these newly minted engineering managers make.

1. Don’t compare how you would work as an engineer to the team you’re supposed to be managing.

“There’s a change in how you understand value for yourself,” Etkin explained. “Let’s assume some sort of world where you’re a great IC, and you’re used to slinging code throughout the day, and let’s say you’re really, really good, and maybe you’re producing at a five … Now you become an engineering manager, maybe you’re managing a team of five ICs, and they’re all producing at a three, so you start to think about things in terms of 15. But you’re also not tangibly doing that; you’re not showing up each day and getting that satisfaction of personally having driven a five across the line. And that’s a huge mental shift.”

He went on to say that if you’re not taking satisfaction from that new part of the job, you might as a manager feel like you’re not doing something that’s important. “I’ve seen folks … that don’t take management super seriously. They don’t realize that if they adjust their thinking, like getting everybody who’s doing a three to do a four, and that’s suddenly a huge amount of more capacity,” he explained. “Instead, maybe they go off and hide in their IC habits, and the things that give them comfort. If you’ve been an engineer your whole life, and now you’re a manager, your fallback in your comfort zone is going to be engineering.”

2. Understand who you’re reporting to

A second mistake new managers make is not understanding who you’re reporting to and how they want to receive information. Etkin said an engineering manager is part salesman, in that you’re selling the work that your team is doing. But in the absence of the necessary information a new manager might not be delivering up to his managers, those higher-ups will naturally assume the worst, he said. “When I started doing the job, I was like, ‘Hey, my team is doing great. I’m focused down and across. And, everybody knows that I’m so good at things, so they will just assume that this team is going great.’ Yet lo and behold I hear through the sideways mechanism that people are very concerned about how this project is going. And I had to learn the visceral way that I need to be telling people what’s working and what’s not working, and what we’re trying and what we’re focused on and what the impact of that is. And that’s a very different mentality from when you’re an IC.”

That issue starts to get into the topic of value streams, which enables first-line managers to surface the real work in such a way that it can be zoomed out for the next higher levels of management to assess if the project is on time and if the correct amount of resources are being spent on the things the organization is trying to accomplish.

3. Understand the big picture

Another aspect of the role of the manager is to understand the bigger picture and learn the why behind what the organization is trying to do, and then enforce those things.”It’s not always easy. And sometimes, the worst part is when it’s just a terrible idea and you have to enforce it anyway,” Etkin said. Often, the manager will fight over the direction, and if the fight is lost, the manager has to go back to the line engineers to explain the decision. Etkin added, “If you’re a good manager, who’s always communicating to your team and letting them know what the thinking is behind a lot of these things, it makes it easier to deliver the bad news. As long as there’s transparency and communication, it makes it go down easier.” 

4. Understanding your team

Etkin advises to be adaptable to the team that you’re working with. Different people have different styles. “I have had engineering managers that work for me that are extremely pedantic,” Etkin said. “They have a super-manicured JIRA board, and their planning meetings are a walk through issue after issue after thing. And they have been extremely successful.” On the other side of the coin, Etkin said he’s had managers working for him that have very short planning meetings, who simply want to know what the team is doing that week. And once they are sure the engineers know exactly what they’ll be doing to get from here to there, that’s the extent of the meeting. “I think those are great examples of understanding the teams that are working for them,” he said. “So some individuals can work in that mechanism and prefer to do so, while some individuals can’t, and they require a little bit more structure.” 

5. Understanding yourself

And then there’s a balance of understanding what you need yourself, Etkin pointed out. “How much structure do you need, versus how much loosey-goosey units do you need, and then marrying that at the right level, between you and the people that are working for you, such that you can come up with a process that allows everybody to do their best work.”

But he said managers also have to take that a level up to their bosses, who will be on the spectrum of extremely right to extremely open and understanding, to see where the manager is in relation to that individual. “You have to adopt enough things to make sure that that person is satisfied with the way that your team is working too.”

To learn more about making development teams more productive, join us at the upcoming Improve: Productivity one-day virtual conference on Nov. 15. Registration is now open.