Behind every great engineering team is an engineering manager helping team leads and ICs.
Their role is especially important when engineers aim to grow, get a promotion, or when they reach the point in their career where they have to choose between pursuing an IC or a management path.
What are you supposed to do as the manager coaching engineers through these difficult decisions?
Somer Esat, Senior Engineering Manager at Blizzard, talks about the role of engineering managers in engineer coaching and career development. He also shares advice on helping developers choose their own career path.
This post covers:
The engineering manager role has different incarnations depending on the company. I’ve seen engineering managers who served as managers and technical leads at the same time.
Other engineering managers put more emphasis on the human side of their role. They focus less on the technical or product ownership, and more on coaching their team.
There are different schools of thought around structuring a team. Some even suggest that a team requires no structure at all, you can just let individual contributors self-organize, and they will make things work.
The Engineering Department at Overwatch isn’t a small team: it consists of about 65 people, so we need a well defined structure to manage it effectively. We have the engineering manager, the engineering leads and the technical director as the leadership group of the Overwatch engineering team.
We have various teams focusing on different areas of the game, such as the gameplay, the engine, tools, reliability, server or UI. Within each of the teams, there’s a lead and some ICs (individual contributors). We refer to the leads by the areas they manage, for example, we have a tools lead, a server lead, and an engine lead.
As an engineering manager, I work with the engineers, team leads and the technical director to help them function well together. I make sure things get done, people feel supported, and their needs are addressed in terms of their career development.
It’s a supporting role. It feels like my success hinges on the team’s success; if they do well, then I do well.
Engineering managers also take part in the recruiting process. At Blizzard, we’re always looking for talented people, and we have lots of open positions. It’s a lot of work to find the right employees, hire them, and onboard them effectively. Our recruiting department helps out, but it’s also a part of my responsibilities.
Engineering management and the role of an engineering manager is important, yet it’s underutilized in the industry. If you have an engineering manager in your company who’s focused on the factors that make your teams stable and happy, you’re doing your team a big favor.
Building stability and connected teams isn’t only the engineering managers’ job, however; you also need a strong vision and good values to make your company a great environment for people to work at.
Bringing more awareness to what an engineering manager does, training engineering managers, and showing them why the role is important and how it complements the existing leadership group could be helpful.
My role’s main focus is talking to people, hearing their achievements and their concerns, and understanding what they need in order to be successful in their role.
The key is that you’re working with people; they’re not just resources. People have things that happen in their lives, within and outside of work as well. Both are important, because they determine how they feel.
You must be ready to manage your team’s feelings. They’re humans, and sometimes they’ll be more excited to be at work, and other times, they’ll be more focused on their personal lives. Engineering managers can ensure that the team is able to talk about these feelings.
If you’re not mindful of that, you might as well have robots working with you.
It’s important to approach the people you manage with empathy. Take their feelings and considerations into account, and try to help them with anything they need. They might be comfortable sharing their problems with their leads, but having an engineering manager they can turn to provides an additional layer of support.
I spend most of my time in meetings and one-on-ones.
I gather information that might be useful in terms of managing and leading the team, and I share it with the lead. Some information might be useful for the technical director for a more strategic level of thinking. Other pieces of information can be helpful to share with the broader team's leadership as well.
When someone is getting up in front of the team to talk about the work that they’re doing, whether it’s about their challenges or asking for feedback, everyone is welcoming. It’s a valuable practice, because it connects people, shares knowledge, and brings cohesion to the team.
These rituals can be broadly discussed. Someone might mention them to me during their one-on-one session, and I can share that with the particular sublead, so they know that their team’s efforts are appreciated by others.
To ensure that the department runs well, you have to be able to pinpoint what works, and encourage it, while also finding areas for improvement. Don’t forget about the small things: if certain rituals make people excited to be at work, and make them feel more comfortable and happier to contribute, encourage that behaviour.
It’s also part of the role to create a reporting structure where everyone is comfortable to share information. For example, an engineer might be frustrated with the way their lead is doing their job. If they report to them directly, they might not be comfortable discussing this issue.
If they have to report to the person who may affect their career progression, they’re likely to hold back and not share their concerns, which leads to feeling isolated.
To avoid this issue, all the engineers report to me, not their lead. I don’t report to the leads or the technical director, either, but to someone who’s responsible for department managers. This gives engineers the freedom to share their concerns with either me or their lead. It also allows me the freedom and flexibility to openly express my feedback to the technical director and engineering leads.
Being an engineering manager involves a partnership with engineers, with leads, and with the technical director. At each level, there’s a shared commitment to a successful outcome. There are different aspects to consider, but the theme is the same: "How can I help people in achieving their goals within their role?”
When I chat with an IC, I focus on helping them with their day-to-day goals, as well as their longer term career goals.
With the engineering leads, the focus is on helping them lead and manage their teams effectively. I focus on one subteam each week.
When speaking with the TD, I support them in managing the leads and the engineering department overall.
Make sure that new hires understand the expectations of their role, and that they’re aware of the different levels they can reach as they progress through their career. Define these roles, and clarify them when needed, so everyone understands them and acts accordingly.
It’s important to give feedback and assess each employee’s work continuously. Pay attention to what they’re capable of, what they’re comfortable and uncomfortable with, and where they are in their career development.
Some people, especially juniors, want to know how they can get to the next level in their career. They can be driven by career development. It could be for various reasons, such as recognition, the title, or the raise. Others are less concerned about advancement, and they’re just excited to be part of the team and do their assigned tasks well.
Understand individual differences, and try to understand each person’s unique set of motivators.
We always encourage people to take ownership of their career. They should initiate career development discussions. If they’re not comfortable doing that, that’s also fine. We recognize when someone is growing, and we reward them for the progress they’ve made.
During the career development discussion itself, we take a look at the principles of the role and check the expectations of the next level. It’s not a checklist but a general definition of what differs between the responsibilities of an IC, a manager and a lead. It helps them see where they’re at, and they can see how they’re progressing towards their desired level.
I do this in partnership with the lead, because they have the ground-level awareness of how people are doing on their team. If we have a clear picture of someone’s progress and we have the necessary data supporting it, it’s a straightforward discussion.
There are trickier situations where an engineer may disagree with the way we perceive their career development.
They might feel they’re ready for the next level. We approach these conversations carefully. We take time to understand their viewpoint and figure out a solution together.
We make sure we’re equitable in our approach, and we’re fair to everyone in the team. It also means not promoting someone too early, because it might set them up for failure. If the expectations of the next level are significantly higher than what they’re capable of, it can be hard for them to manage.
Promotions can take time. Even if we’re sure we want to promote someone, there are processes to be adhered to, so we all need to be patient. It’s hard, because some people rely on this type of reassurance, and we might have to wait to be able to give them that.
As an engineer iterates their way of completing tasks, they’re able to solve the problems that concerned them previously. They incrementally move forward and get to the point where they exceed the expectations of their level, and they feel confident and comfortable taking the next level.
We have clearly defined levels within our organization, and we check if the engineer meets the expectations of the next level before we promote them. It doesn’t have to be every single thing, but they must be able to perform the tasks of the higher level to a reasonable degree.
They have to be able to demonstrate they have the necessary skills, such as being able to estimate how long it takes to finish a certain task. This type of skill is hard to teach, because it requires knowledge of the code base, self-awareness, and being able to evaluate possible drawbacks.
If an engineer progresses well but still needs to work on a few areas, such as soft skills or estimating, an engineering manager works with their lead to recognize those areas and share them. The next challenge is to figure out how to improve these skills with the help of the lead.
After engineers have done some work, it’s important to dedicate some time to look at the processes retrospectively. What went well? What didn’t? What can be improved next?
It’s an opportunity to explore new solutions and to set up some action items if something in their process needs to be improved.
This iteration can not only focus on game development but their own growth as well. As engineers iterate processes to create the perfect game, they also master certain skills and they’ll be able to take on more and more challenging tasks.
Engineers need to have a supportive lead who pays attention to what they’re doing, so they can discuss their progress in retrospective meetings. This should be an honest conversation between the engineer and the lead, and it can be an opportunity for some engineer coaching from the lead as well.
People may worry that they won’t get credit for an achievement unless they do it alone. That’s a misconception; feel free to tap the brain trust of the room. Encourage the mindset that there are a lot of smart people on the team, and they’re willing to help.
We don’t want to build a production line of engineers.
We want people to be imaginative and creative and to use their own judgment. We encourage them to come up with their own solutions to problems, and we don’t force one possible way of doing things. Different ways may bring the same success.
These can be engineering-related problems, but engineers need to do other things as well, such as collaborating with others or managing their workload to reach deadlines, and those problems also need a personalized approach.
There isn’t one correct way to solve problems.
For example, the estimates for a task don’t play out well. There can be various reasons behind it: maybe the team has discovered work to be done along the way, maybe they didn’t fully understand the feature, or maybe it was just a rushed estimate and they didn’t think it through.
Because making the wrong estimates can happen due to many different factors, there isn’t a one-way approach to universally solve the problem. What the team can do is evaluate how to improve their approach. They can ask for a senior engineer’s feedback who’s familiar with that code base, and get their perspective on their estimates.
It takes time to build capability in the workplace. As you become more confident in your role and your team, and as you gather a comprehensive knowledge of the codebase, you become familiar with your environment. That’s when you’re more confident to experiment with different approaches, more complicated work, and you become more flexible.
This applies to ICs, managers and leads alike.
Junior engineers aren’t sure how to approach things yet, so you must provide specific guidance. It shouldn’t be to the point of micromanaging, but pay more attention to help them out, review their code more often, and help them understand why you make certain decisions.
As juniors grow, they have role models around them. It’s important to learn from more experienced colleagues. They can see how they approach different aspects of their role, and it can serve as a basis for juniors to understand the expectations.
When people first start out in their career, you must provide a supportive environment for them. Instead of throwing them in the deep end, focus on giving them guidance, frequent victories, and help them build their confidence. Recognize what they’re especially skilled at, what they need to improve, and build on it.
As they become more senior, their perspective broadens, and they not only consider their personal tasks, but they examine what’s going on in their team and how it contributes to the bigger picture, so they get better at making decisions overall.
In terms of climbing the software engineer career ladder, there’s a principal track and a leadership track that engineers can choose from. For most people, it isn’t a big dilemma: they will be sure about which path they want to take.
Engineers who choose the principal track remain ICs on a bigger scale, while people on the leadership track become managers and leads.
When someone doesn’t have a strong sense of which track they want to pursue, you might have to ask them more questions and understand their motives:
It’s also helpful to describe to people what the future looks like in each of the tracks and what the main focus is. If they’re interested in that, you can start exposing them to different aspects of the role.
To a certain degree, leadership is similar to engineering. As an engineer, you make features, you retrospect on them, and you look for areas to improve. You do the same thing as a lead as well: you talk with leads and managers, you ask questions, and you figure out what to do differently next time.
The difference is that leadership deals with managing humans, so each situation will be unique and different.
As a lead, patience and empathy are the most important, followed by strong technical knowledge. If someone becomes a lead after being an engineer, it’ll be easier to understand what their team is going through - they can relate to their challenges through their own personal experience.
Leads and ICs can both feel a sense of accomplishment when helping others. But if someone is more excited to deliver a solution as opposed to helping another person deliver a solution, then maybe they’re a better fit for the IC track. A lead is not always involved in solving technical problems.
A lead enables their team to do work and to meet their goals rather than doing the work with them. That’s challenging for some leads, because they might feel like they don’t add value if they don’t have a tangible output.
A lead’s work can be hard to recognize. But if they perceive the team’s success as their own success, they can overcome their doubts about the value of their work. If you get things done as a team, then you are all successful.
People interested in the leadership track could spend time with their lead in areas that they aren’t normally involved in, such as planning or attending meetings to see the day-to-day tasks of leads.
There are also different kinds of training that give a taste of leadership. They can attend them and learn about different challenges of the lead. Sometimes, people will attend leadership training, and they realize that being a lead isn’t for them while others get reassurance that they want to go on that track.
When a person becomes a lead for the first time, they may have many questions and concerns. They have to give instructions to the people they used to be peers with, and they must advise engineers and come up with solutions for their team on their own.
It can be difficult, so we provide leadership coaching for them. For potential leads, after the training, we give them the opportunity to mentor a junior engineer. Not only will they transfer knowledge, but they’ll also experience guiding and helping someone in their career development. It’s usually a rewarding experience for potential leads.
When a person becomes a new lead, they might be uncertain about themselves, and this can be stressful to experience. They are overwhelmed if they make a bad decision and the team reacts poorly or if they don’t approach something well.
As an engineering manager at Blizzard, you work together with the new lead and their team to support everyone involved. Make sure engineers treat the new lead with patience and empathy, and they may turn to you if they have any concerns about their new lead.
I encourage new leads to write down their successes and mistakes so we can discuss them in our one-on-one sessions.
Bringing the leads together is also a good idea, because some of them are more experienced, and they can be a good source of empathy, advice or support to each other. Sharing their leadership challenges can add great value to others’ learning experience.
It’s also useful for more senior leads, because they may realize they’re not alone in the problems they’re facing. Just knowing that others went through the same problems, for example, with a challenging employee, can be extremely helpful, because they will know who to turn to if they need advice.
Somer has been an Engineering Manager at Blizzard for almost nine years. Currently, he’s responsible for the Overwatch team at Blizzard.
After receiving his computing degree, he worked as a software engineering consultant in the Australian government, where he experienced different roles and types of software at different departments and has developed a passion for consulting.
Thirteen years later, he joined Blizzard, where he first worked on Corporate Applications. He then applied for the engineering manager position on the Overwatch team. For the past seven years, he has been helping his team in their day-to-day work and in their career development.
Before shipping Overwatch, the Overwatch team shared an early version of the game internally to get feedback from employees. When I first played it, I fell in love with it, so I was motivated to get involved: I wanted to do whatever I could to help them.
They were looking for an engineering manager, so I applied. At the time I didn’t know anyone who was developing games or working on a game team. I didn’t know how game developer teams functioned, and I didn’t have anyone to seek advice from.
I went there with good intentions and good faith, and my experience behind me. It was a long process. There were twelve interviews, because I spoke with most of the leadership on the team: the engineering leads, the technical director, the production director, HR, and so on. I understood that the team recognized the role as impactful, and wanted to make the right hiring decision
As I was taking part in the interview process, I learned a lot about the Overwatch team’s expectations, structure, and values. I had interesting discussions.
I wasn’t really able to prepare much, because I didn’t have anyone coaching me or helping me through the process, and although I had experience in management, leadership, career development and recruiting, it was a new ground for me because the team was organized differently, and I wasn't knowledgeable about the game development process. It was out of my comfort zone, and that was good. I enjoyed it, and after all these years and learning so much I still enjoy it. I’m particularly proud of all the engineers and leads I helped to grow their career.
👉 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.