Blog

How to succeed as an engineering manager

July 11, 2022
How to succeed as an engineering manager

Author: Darko Ilić Šikelj.

It’s hard to be an Engineering Manager (EM). 

You’re responsible for a team delivery without ownership over product, process, or technology. You’re not an individual contributor. You depend on the product side for the vision and engineers own technical decisions.

You are not a star. Engineers are stars. Product Managers are stars. You’re not. You’re just somebody supporting the team.

I feel you!

For me, the most challenging thing in the engineer-to-manager transition was getting used to delayed impact. As an engineer, you write code and see it work. As a manager, you influence, support and coach, and then a couple of months down the road, you hopefully see the impact. But if done right, the reward is worth the effort.

In this article, I’ll share what I found in my ten years of performing in the role of Engineering Manager / Team Lead. I’ll talk about four big areas you need to focus on, and inside those areas, I’ll provide practical and meaningful advice.

Let’s get started.

4 THINGS YOU SHOULD FOCUS ON TO BE A GREAT ENGINEERING MANAGER

1. Set your engineers up for success

When you become an EM, it’s not anymore about you; it’s about your team. So, your goal should be something like this – to lead a high-performing team where engineers enjoy working and making an impact.

To achieve that, you want skillful and proactive engineers who take the initiative and accept the responsibility. Because engineers are creative people, you want your engineers motivated, not obedient. You want them to proactively suggest what they think is the best solution for all product, process and collaboration challenges. Not just to work on the task list by specifications. 

Because engineers are creative people, you want your engineers motivated, not obedient.

So how do you do that? How do you motivate engineers?

I find that these few things in combination move the needle for most people:

  • Manage personal development and match it with team or project goals. Overlapping individual career development and team/project goals is a strong motivator in itself. When people see the opportunity for themselves to grow on a project, it automatically becomes more than “just another project.”
  • Find opportunities for your people. Find the right project where people can actually achieve those personal goals. “The right project” means something challenging to drive people out of their comfort zone but not too challenging to put them in the panic zone. That spot is called the learning zone.
  • Give trust. You want to give your engineers a certain degree of freedom and trust. On some level, that means not telling them how to do their job, how to lead projects and how to implement features. You let them come up with solutions. You can challenge solutions – everybody in a team should discuss and openly challenge each other. But do not micromanage and over-control them.
  • Give support. That includes direct mentoring, coaching or casual advising. Do it yourself or arrange the support within the team or from another part of the organization.
  • Provide feedback. Follow up on the progress continuously and provide feedback regularly.

Now, let’s put it all together.

With every team member, you build a personal development plan where you agree on the growth areas – for example, leading a certain type of project. And you find the right opportunity that matches that growth area. 

Then you’ll want to follow the progress on the actual project to make sure the people are moving in the right direction. This is where the right combination of trust, support and feedback is essential

You need to adapt your approach both to the situation and the person. More junior engineers and people further away from their comfort zone need direct know-how and specific steps. As for more experienced engineers, you can support or coach them more indirectly. That can be anything from helping them prepare documentation, actively supporting them in project meetings or advising them on collaboration or process topics. Throughout all those activities, you’ll also cultivate the feedback on their performance to further drive and adapt personal development goals. 

Basically, it’s a continuous process of spotting opportunities and providing feedback while fine-tuning your approach according to the situation. That is called situational leadership, and I highly recommend digging deeper into this topic.

If done right, you’ll have people who are building their careers while making an impact. They’ll have an environment that supports them and receive constructive feedback regularly. Their manager will entrust them with responsible work and provide room for their creativity. That’s when engineers get motivated and take ownership. 

2. Create a team development vision 

Working with individuals and helping them become better engineers is not enough. You’re here to set up your entire team for success. 

Think about how you are going to scale a team. What happens when software or processes become so complex that individuals can’t handle so much cognitive load? And if you hire more software engineers, will the team require other roles, like QA engineers or designers? 

Maybe you’re not responsible for hiring in all the roles, but it’s your job to make sure you’ve aligned hiring plans with other managers so your team will have all the support they need.

You need a hiring plan. Whether your company has a formal hire planning process doesn’t matter. In either case, you’ll want to look at it as the opportunity to share your ideas, get feedback, secure the budget and ensure all the support you’ll need in the execution phase. 

Let’s see who can help you do that:

  • Your manager. I suggest starting by talking with your manager because they probably have more information than you. Then, use every opportunity you have to update them with new information or ideas you’ll have after talking with all other relevant people in the organization. Your manager is the one who can help you the most if you run into a problem, and also the one who will approve your hiring plan in the end.
  • Product Managers. I’ve already mentioned the link between the hiring plan and the product roadmap. You need to know what your team will need to build so you can assess what skills or resources they might need. Also, ensure two-way communication by sharing your thoughts and plans with PM. You might receive valuable feedback.
  • Your team. Individuals from your team might not have all the information, and their perspectives might be biased. But often, their input is valuable to you as a manager. Even when you disagree with them, this is the opportunity to share your plans and communicate your vision to them. You want your team to know, believe and support the hiring plan because they’ll play a significant role in the entire process – recommending, evaluating and onboarding new hires. Another thing to consider is that hiring plans can impact personal development plans and vice versa. Even if there’s no conflict between the role of planned hires and personal development plans, your team members might think there is, so make sure to address any such concerns. 
  • Your peers. Sometimes you’ll have to talk to them because they are responsible for hiring in other teams and roles that your team depends on. And sometimes you’ll have to discuss work distribution between teams. But even if you don’t have obvious reasons, you might consider sharing your plans to inform them or get advice. Maybe that information is important to them, but you are unaware.  
  • HR. HR usually has the most experience in hiring planning and can give you the best advice. Explain to them all the factors you calculated and encourage them to challenge your plan. They are the ones who will work with you on the execution, so you want them to understand everything, from job descriptions, priorities, team and culture-specific requirements – anything that can help them optimize the process from sourcing to onboarding.

Hiring planning is a complex iterative process, but it is essential for managing the team development vision. Without it, you’re not a leader. You’re simply an administrator.

One more aspect of the team development vision is managing the organizational change. You need to plan the future organizational landscape and how it will impact the software architecture, processes and collaboration. 

There is a strong correlation between software architecture and organizational structure. One of the people who described that correlation is Melvin Conway in an adage known as Conway’s law – “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure“. Today, most modern organizational theories and best practices take into account Conway’s law implications. The general advice here is to plan your organizational structure to support the evolution of software architecture. The details about how to do that are out of the scope of this article, but of course, books have been written on this topic, so I’ll point you to the one I consider to be the best – “Team Topologies” by Manuel Pais and Matthew Skelton.

Plan your organizational structure to support the evolution of software architecture

3. Make sure your team is focused on the right things 

We covered personal and team development. But we still haven’t talked about purpose or results. What is your team building? Why? Are they making an actual impact?  

Some teams focus on technology goals. And that’s ok – you want to encourage the continuous process and tech improvement. But it’s not enough – technology serves to solve real-life problems and achieve business and product goals.

You are usually not directly responsible for those product goals as an EM. Product Managers are. But in reality, you have an important role to play – you want to ensure an alignment between technology and product. Because then you’ll have the entire team motivated to do what’s best for the product and best for the users. That’s how you maximize the impact of your team.

Here’s some advice on how to do that – how to help your team focus on the right things.

  • Make sure the entire team participates in product discussions. This doesn’t mean everyone participates in all the meetings. But it means that everyone is engaged and motivated to find the best way to achieve product goals at their contribution level. It shouldn’t be something reserved for the product managers only.
  • Focus the team on understanding “why”. What is the purpose of the features in the roadmap? Encourage the team to find that out. Ask engineers to think about how they can support the “why” while planning, building, testing, shipping or supporting the users.
  • Measure a lot. Create a team habit of thinking about how each feature’s impact can be measured. Focusing on metrics can result in productive discussions and can do miracles in terms of aligning product and tech.
  • When possible, expose your team to users. Seeing the impact software has or could have on users can motivate and inspire the entire team.
  • Make time for creativity. Sometimes teams need time to experiment, brainstorm, have a workshop or go to a good conference for a few days. Make sure they have it.
  • Encourage events such as retrospectives and lessons learned.

This is far from a complete list of your activities. It comes down to doing everything you can to get a shared understanding and collaboration. You might need to challenge the team or specific individuals. Or escalate some problems. Or ask the hard questions and insist on dealing with the elephants in the room. You don’t get to avoid conflict or to say “not my job”. Everything around your team is your job. And creating a team mindset with a focus on purpose, results and users is the key to building a successful team.

4. Build a supportive culture  

The final big thing you need for your team is a good and healthy culture. Culture as a concept might be a bit vague. It has many aspects, but I want to focus on psychological safety and a safe-to-fail mindset. Those two concepts are one of the prerequisites for other things like healthy relationships or a good friendly environment. At the same time, they directly support the result-driven mindset we talked about previously. 

Psychological safety is a shared trust and belief that a person won’t be punished or embarrassed for making an unintentional mistake or for simply speaking up. 

It is a prerequisite for getting engagement and commitment from everyone, especially when engaging with more reserved individuals. 

You can do many things to support psychological safety and encourage engagement. Let’s go through some of the stuff.

  • Encourage participation in regular team activities. If your team estimates features on planning sessions, you can start by using a simple tool such as planning poker. It’s a gamified technique that teams use to estimate the effort of project tasks. The important thing about this technique is that it ensures the engagement of every individual on a team. 
  • Perceive incidents and mistakes as an opportunity to learn and improve. This is easier said than done. Some basic emotions and instincts can kick in in the heat of the situation. But remember, you’re dealing with engineers – they want to make things right. So you want to be constructive and shift focus on improvements. You can utilize tools like retrospectives, Root Cause Analysis or 5 whys.
  • Set an example by discussing your own failures openly. Walking the talk is the best way to shape the culture. Exposing yourself to the team sends a powerful message of trust and allows others to learn without making mistakes on their own. 
  • Be honest and encourage honesty. When you don’t know how to do something – say I don’t know. Ask for help. Consult. And expect the same from the others. 

Of course, there’s more stuff to do and things to consider. But this should be enough to get you started, and you’ll figure out things on the way.

If you’ve read this far, you now know how to build a team of motivated individuals growing together, both as a team and as individuals, working in a supportive and healthy environment and delivering results. Easy-peasy, right? 🙂 


Conclusion

I talked so much about the challenges of the EM position that you might ask yourself why would anybody take such a job?

Well, working in software development for almost 15 years, I can tell you that for me, it’s the most challenging but also the most rewarding job in the industry!

That feeling when the team you nurtured builds something you’re all proud of, and people thank you for helping them get there… That’s something to remember!

And one more thing – If you’re going to try it out, make sure to do it in the right organization. Well, you guessed it – Microblink is the company and now is the time! 🙂

We are hiring in multiple departments and we’re looking for both experienced leaders and engineers ready to take the challenge and make a transition. Check out our open Engineering manager positions here and here and if you’re curious about these opportunities, you can shoot me a message at darko.ilic.sikelj@microblink.com

Best of luck!