Becoming a leader of engineering managers is as big a jump as transitioning from engineer to management. You find an endless stream of tasks and solitude, and no one tells you what it means or what it takes to be successful.
In the latest episode of the Level-up Engineering podcast, Karolina Toth interviewed Andras Fincza, VP of Engineering at Emarsys, to discuss leading engineering managers compared to managing developers. He shared real insights and brutally honest moments from his experience as a tech leader to compare leading vs managing.
From this podcast episode and blog post, you will learn:
You may lead a group of 6-8 people, but being responsible for another one hundred is the difference. There are a lot of similarities between managing and leading, it's the way you work that's different.
This is similar for managers and leaders, it's just more important for the latter. Managers shouldn’t micromanage their developers either, but micromanaging can be a dealbreaker once you become an engineering leader.
When managing managers, you should rely on other techniques to direct your people and to show them the way.
It’s a good sign to be dispensable both for managers and leaders.
This means you've built a self-managed team that can be fully autonomous and work without your constant watch. To get there, you need to have succeeded in making space for people to challenge the processes and to come up with alternative solutions. This is the sign of psychological safety in a team.
I learned this from my missed opportunities and mistakes.
I'll tell you a leadership story.
When I was a team leader, no one challenged my way of running the team. I wasn't unpopular, it was comfortable for everyone, but I was the go-to person for anyone outside the team. I attended architectural or product-related meetings because I wanted to move everything out of the way of my people so they could be efficient.
Doing this, I made myself a dependency for the team.
I only realized this was a mistake when I saw one of my engineering managers create an autonomous team, and I was jealous of him for that. Anyone from his team could represent the entire team in any meeting. He inspired me to do the same with my team of engineering managers.
The real differences are in the ways you make improvements for the people you’re responsible for.
As a team leader, it’s easy, but as an executive leader, you need to get support from everyone you’re responsible for to make a big decision. This means you have to convince everybody, especially your engineering managers, so they represent the decision to their people.
As a manager, I used to sit with my team and partake in everything they did. After I became an executive leader, I didn't have the privilege to sit down with all the people in my organization. I had an overview of the company, but that meant indirect information, so I couldn’t trust it.
I concluded that to be a good executive leader, I had to be on the field to get information.
Now, I keep up many connections with people. I proactively reach out to people beyond my team of engineering managers. I talk to developers, system engineers, and anyone I am responsible for indirectly.
I like to do skip level meetings. When you talk to engineers directly, you can get to know your people better.
Good team leaders have to know their people. Learn their mood and their behavior, which allows you to make better decisions. As an executive leader, you can’t do this because there are too many people.
Knowing everyone’s name by heart is a must for me, even with a team of more than 100. I made it my goal to have anecdotes of everybody in my department. I think it helps them as well because these are usually shared stories, which may be a joint effort to solve a problem or just to have a beer together.
Even if I can’t do this with everyone, making the effort helps me build stronger human relationships with my people, so I can make better decisions as an executive leader.
The best thing for an executive leader is to find the time to sit with your teams and to spend a couple of days with them. You can do your usual work, but you get to see how they work and what problems they have with your own eyes. It’s hard for me to find the time for this, but I try, and I encourage my engineering managers who run 2-3 teams to sit with each team to better understand them.
I knew it was going to be a roller coaster, like any time you transition from one role to another.
When I became head of Engineering, I felt I was successful with my team. I felt that I understood my engineering managers, I knew enough, I didn’t get in their way, I delegated, and everything went well. But if something goes wrong, it can derail everything.
It may be a change you make, a process you introduce or moving people around from one place to another because of tensions. The reaction you get from the organization can surprise you. Sometimes, you can't convince people, or you won't have time to convince everyone before implementing a change.
When people don't buy into your decision, your reflexes kick in to move fast and survive. Instinctively you start to micromanage, which is the worst thing you can do. You will be disappointed with the results, but it happens to everyone, and all you can do is to learn from this and try to avoid it next time.
It’s essential to realize in an executive role that you can’t make everyone happy. You have to live this, but it's hard for me personally. I think I was prepared to deal with this, but I still had to learn to control my feelings about it.
This surprised me; I didn’t see it coming.
Solitude is common for an executive leader. When you move from engineering management to leadership, you lose the close connection to your team that managers have.
When I had been head of Engineering for half a year, I felt that I was just one step away from total burnout. I knew there was a problem, but I couldn't identify it.
I felt overwhelmed. I felt I couldn't finish anything. I didn't feel safe making decisions.
One night, in the midst of my agony, I started to write down all my duties, tasks, initiatives, and everything I couldn't finish. There were hundreds of items, and I put them into 20 categories and 80 subcategories. Then I buried my face in my hands, and the only thing I could think was, "What am I doing?"
It was insane.
I grabbed the list, and the next day, I reached out to my boss and mentor and asked to go out for a coffee or beer. He saw that I was upset, and I threw everything at him. The list, my feelings about it—I told him I was thinking of resigning because I couldn’t handle the pressure.
Only afterward did I realize how good a leader he was. He remained silent until I finished ranting, and then he asked me, "Why do you want to solve all this by yourself?"
I objected. "I delegate as much as I can, but the teams and managers are overwhelmed. There is no one else to do these tasks. I could throw out some to shrink my list, but I can’t do them all.”
This was the moment I realized how lonely I was in my role and how it paralyzed me. In turn, it also hurt my managers and their developer teams too. I also realized I didn’t have to be alone with my decisions.
Then I came up with the best idea I've ever had: I needed a team.
I had engineering managers, we did 1-on-1s and all that, but it wasn’t a real team. I needed a team that breathed together and made decisions together. The idea was to create a team of my managers.
I dropped my list and started with a blank page. I laid down the ground rules and organized meetings. We were trying to figure out what would be good for the company, and every member was excited to work together and share information with each other.
We’ve kept these processes ever since. We have a 90-minute meeting every week, where we share all the information about mood, people, culture, everything. We throw it all into the same bucket, then we choose some of them to focus on and make the decisions together.
This way, my managers can have a direct global impact on the organization. I’m responsible for their time, and I don't want to take too much away from their reports. But they have to represent themselves in these meetings while they help each other move forward.
Since then, I feel safe making decisions. We have less organizational stress, and my decisions are backed up by my engineering managers. Additionally, I have arguments and reasons coming from C-level management, and the people they’re responsible for, so I can represent the entire organization better.
I don't know if there is a happy story of an engineering manager transitioning to leadership. I struggled a lot, but it was worth it, because I also learned a lot, especially about myself.
I don't have a checklist, but I can give you some guidelines.
Avoid solving things early on. It's hard, because when you move into a leadership position, you want to prove yourself.
Stop instead, watch, learn, and feel the heartbeat of the organization or the lack of it. Don't visualize the best company or the perfect processes, but look at the existing culture. You need to forget your previous experiences, especially if you come from another company, and start understanding your current environment.
In the early days, you have to learn how things work around you and find the right areas to focus on. Whatever change you implement early on will be based on your previous experiences, and it’ll likely be counterproductive, especially if you push your decisions on people.
You need information to be able to do your job well. You have to create communication channels and build up your social network in the organization. I like skip level 1-on-1 meetings and sitting with the teams for some time.
Another crucial step you have to focus on, especially in the first days, is gaining trust. It’s key for an executive leader.
You need to earn the trust of your engineering managers, which also means you have to give them trust.
Doing 1-on-1s with your team is a good way to lay the foundation. A 1-on-1 meeting can be the place where you show the person behind the boss. You get to know the human side of your report, and you can share feedback as well.
It’s a safe place to ask for feedback, to give feedback, and to hold them accountable for things they said or did. You should also emphasize you’re accountable for what you say and do as well. A good 1-on-1 is a safe place for you both.
Building trust with the entire department is harder than doing it with your team of engineering managers. If you’re new to the company, it’s even harder. One thing you should certainly do is be honest in your every action and speech, and be transparent.
I regularly speak at town hall meetings (aka company-wide open space meetings) to share up-to-date information about the changes the managers want to do. We have discussion groups where people can freely ask questions, and I have an open-door policy so anyone can walk into my office and ask questions. I make myself accountable in these situations so they can criticize me if they want to.
I like to write engineering management newsletters. We’re doing this to emphasize one or two things every week and to keep up the information flow in the department.
Making yourself vulnerable and talking about your mistakes in front of a larger audience can help you build trust on a wider scale. I’ve had a lot of initiatives, about half of them have been unsuccessful, and I openly talk about my mistakes and ask for help from others. So, if my people have ideas, they can reach out to me.
I encourage people who get into tech leadership roles to read books and to use any available resources, like the Level-up Engineering podcast. Learn about leadership soft skills from great leaders and put effort into mastering them. It’s valuable.
If there’s one essential trait for engineering managers, it’s consistency.
You have to know your values and align them with the company values. Sometimes, you have to make hard decisions and say no to requests, and you have to be consistent with this.
Once I had to say no to approving a new programming language. On the one hand, we are proud that we allow our engineers to try new tools and to bring them in, but on the other, I must keep the problems caused by a broad tech stack in check. If you make this call once, you must do the same for similar requests as well to stay consistent.
I'm still open to these requests, but I expect my people to convince me with professional arguments and proof that the task they want new technology for would be nearly impossible with our current stack.
Another important trait is determination, but it must come with compassion.
I have to be responsible for what I say or do. If I say no to something, I must be transparent and honest, and I need to explain why I, or the management, made this decision.
Sometimes, it may mean that you have to make hard decisions, even against professional reasons in favor of the human side. For example, when a team needs more developers, and you have another team that’s overstaffed, you may still keep the latter team together because of personal reasons. They may be extremely efficient together, which might override professional reasons.
The ultimate trait for engineers, managers, and tech leaders is self-reflection.
It’s important because if you have self-reflection, you continuously inspect yourself and the impact you have on others. This is a great way to learn, and it is similar to getting feedback. But it's hard to ask for feedback, but you can practice self-reflection all day.
I just sit down at the end of the day, think of what I did all day, and ask questions like, "What was the impact of what I said?" It’s often painful to face all the mistakes you made in a day, but with great self-reflection, you can improve with less feedback from others. You still need feedback though, because your perception can direct you the wrong way.
You’ll always need a reality check from others, but self-reflection is an essential trait.
The first thing you have to do with your people as a leader is to discuss expectations. What can you expect from them, and what can they expect from you?
As an executive leader, I talk a lot about these expectations with my team. We aim to be honest and straightforward, so these are passionate discussions. It’s important to discuss it together and to clarify the expectations towards upper management.
Our developer teams have weekly retrospective meetings. You can do this with any team, and you should do retrospective meetings with engineering managers as well. Everything can be solved with good retrospective meetings.
I dedicate at least one full day to a workshop every year to iterate our roles, expectations, and practices. It’s a great way to improve ourselves.
Usually, they reach out to me when they have problems. I do the same thing my leader did to help me, which is to listen carefully.
Listen to them, ask some questions for clarification, and let them come up with a solution. Don’t force your ideas on them, because they learn more if you let them find a solution by themselves. It’s key that they have ownership of the result.
Engineering managers often struggle with decisions. They cannot decide on A or B, and they need help to figure out what to do next.
They tend to be overwhelmed, and usually, it’s because they want to solve everything by themselves. I advise them to build up a team and to rely on them. My engineering managers are responsible for 2-3 teams, so they can build a team of their team leaders.
I encourage them to shrink their tasks and to propagate the idea that you have to let fires burn. It's useful to focus on one thing, and it's okay to let some tasks go. I help them prioritize, and I encourage them to focus on the most important task.
Measuring performance is the hardest thing for tech leaders. I’d love to have the perfect metric for measuring the performance of an engineering manager.
If you want to stick to numbers, you can attribute the product delivery rate to your managers. You can assume that the trend of changes in delivery rates from quarter to quarter are caused by your managers. It's not a definitive metric, but they have control over this, and most of their job is about making sure their teams deliver.
I don't have exact numbers; instead, I gather feedback about my managers and carefully look at whether they have ownership of that.
In skip level 1-on-1s, I try to see if the engineers tell me their manager is a trustworthy person. Also, if I see my managers know what's happening in their teams and with their projects, and if they have an answer for everything I need to know, I'm satisfied.
If you carefully watch the mood of the organization, you can find red flags.
For example, if the engineering management introduces a new process, it can be a negative experience for people. It's up to me and my team of managers to show the opportunity in the change and convince the organization it’s for the best. So, if concerns stick around, it may signal performance problems for a manager.
This is how I measure the performance of my engineering managers.
We start a discussion about it to understand each other’s point of view. Sometimes, we don’t see the same things as problems. I'm open to listening to their reasoning, so they can convince me that they’re doing it right.
If I see that they have ownership of what they’re doing, and they’re passionate about a solution, I let them do it their way. Sometimes, they’re right, and they deliver great results; other times, it doesn’t work out. Then I expect them to learn from it and avoid it the next time, and since they have ownership, they’re sure to learn.
I give them space to come up with solutions and to make the mistakes that come with it.
It’s similar to the way I measure the performance of my engineering managers.
I attribute my work to the delivery of the teams, so they can make me accountable for what I did, and I gather feedback on it. I use self-reflection; it’s always a good tool to measure your performance and success.
Often, it can be obvious to have success as an executive tech leader. The hard part is that you don’t see it because everything you do impacts the organization indirectly.
Anything the engineering management does, whether it was your idea or you just allowed your managers to make their ideas happen, you have to learn to attribute these to yourself too. Both the good and the bad.
Look at the success of the people around you, and find little things you can connect with. It’s essential to keep yourself sane. This is what I suggest to those who are in a similar role and unhappy about their performance.
Andras has a master's degree in IT and started his career as a freelance engineer. Later, he became the co-founder of a fast-growing web development studio. He switched to Emarsys, went back to software engineering, and learned about its engineering culture.
He became part of senior leadership, and he’s currently VP of Engineering at Emarsys. Because of this, he doesn’t attend stand-up meetings holding a baseball bat anymore.
As an executive leader, his mission is to take care of the emerging culture and to keep the development processes agile to improve efficiency and overall quality. To fulfill this mission, he’s leading a group of engineering managers, and he's passionately working on Emarsys Craftlab.
👉 If you are serious about becoming a great engineering leader, you should take a deep dive into the State of Engineering Management 2022 report.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.