What is expected of a Engineering Manager?

14 Oct 2020

tl;dr: the three things I expect from an engineering manager are:

Support the members of your team and help them grow.
Follow along the deliveries, setting quality standards, making sure the team has the support they need and upper management the feedback they need.
Keep a constant practice of creating, improving or eliminating team or company processes.

Every organization has its own way of working and your mileage may vary. I’ve collected a few points that I believe that are overall expectations.

Andy Grove on his book High Output Management defined a manager output as the sum of their team output and the teams under their influence output. He also recommends selecting activities producing high leverage: an activity he did as a CEO was an introductory talk to new employees, in which he explained the history, the values and the objectives for Intel. If he does this very well, this can generate great impact on every new employee.

A good example of a high leverage is partnering with other leads: being able to understand where the business is going and helping building a technical roadmap to facilitate getting there. Another high leverage is to guide each member of your team to acquire new skills so they can increase their scope and increase their impact on the organization.

People

Your team’s output is really dependent on your team members, so an expectation for engineering managers is to support the members of your team and help them grow.

A good way to think about hiring and growing your team members is to think that they can replace you. You can’t actually do that unless you know everyone really well. What are their strenghts and weaknesses? What are their goals and what motivates them? Which level they’re operating? What might need them to go to the next one?

1:1s play a big role here: it is your time to learn more about each person. It is a great time to establishes trust and build rapport. Another crucial factor on people is to set expectations: setting a clear expectation on what you expect from each person creates a more concrete notion on what they should and shouldn’t do and what level they should perform: recognizing when someone performed really well and giving constructive feedback when they haven’t reached your expectations. Feedback is a hard subject, but if you can back your feedbacks with examples, it will be much more clear on what you’re recognizing or you’re giving a constructive feedback: a good practice is to give continuous (a practice suggested by Camille Fournier on her book The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Changefeedback: on every 1:1 try to bring an example-backed feedback.

If you find yourself giving constructive feedback but you’re not seeing improvements, make it clear as early as possible. Dealing with underperformance isn’t an easy task, and sometimes we hope that with guidance they will improve, but making it clear that it isn’t working is part of your job and perhaps it is time to set more prescriptive actions and a timeline for improvement: a tool that can help is Personal Improvement Plan in which you set a clear expectations, actions that you think will help them you and an expected timeline.

A hard part of this job is that if someone isn’t performing even after this, you have to let them go. There is also behavior: if someone had an unacceptable behavior, it is part of your job to take action. Dealing with underperformance/letting people go is a tough subject (which I don’t have much experience): I highly recommend asking your HR Business Partner and your manager to help with that.

Your company will also count on you on performance reviews, which happens a few times a year and you can discuss with each person their actual performance along with career progression: if they’re doing really well, you can promote/make a case for their promotion to your peers and senior management. You can also use this time to set goals on what people need to improve and learn for the next cycle. Some companies use this period to set performance improvement plans for people below expectations. Performance reviews usually generate anxiety for everyone: if you’re working on giving continuous feedback every 1:1, it should be an easier conversation without surprises.

As a final recommendation on people expectations, I’d highly recommend learning more about delegation (without micromanaging): allowing people to have autonomy on how they should do a task will allow them to grow and also you can focus on exerting higher leverage. You can’t control every action and if there is a mistake, you have to guide people on learning from it: Ray Dahlio on his book Principles: Life and Work enforces that you should have a culture in which is ok to make mistakes and unacceptable to not learn from them. Google also researched a lot about psychological safety and they found out that in their best teams people feel safe taking risks.

Delivery

Another expectation on an engineering management job is delivery: your company expects that you follow along the deliveries, setting quality standards, making sure the team has the support they need and upper management the feedback they need.

This is where delegation plays its role: to exert leverage, you have to delegate the execution of a project to the team: delegating something doesn’t mean you can forget about that delivery, you need to make sure it is done (or explain why it isn’t) and support that delivery.

Andy Grove tells about 4 types of activities that a manager does: Acquire Information, Communicate Information, Decision Making and Nudging. When support delivering value, we perform these activities: we acquire information about what we’re delivering, we communicate back and forth, we nudge the team on decisions and when the decision has bigger trade-offs or when the team can’t make a decision, we need to make the decision based on the acquired information and communicate our reasoning to everyone else. If a decision is controversial, make it clear and explicit the controversial points and the trade-offs that were considered.

A recurrent is waffling a decision: when the team needs to make a decision and the discussions about it can’t converge: if a decision is a roadblock, it is your duty to understand the tradeoffs, discuss with all relevant parties and make a decision. If it seems complicated, it is because it is.

Communication is probably your most important tool on delivering: acquiring information, partner on generating a purpose along with your peers and communicate the problem being solved to the team and communicate the progress to everyone interested.

When a decision doesn’t seem big and only affects the team, I recommend delegating it to the team and discuss the trade-offs: if prefer one of the options but the other ones doesn’t have significant downsides, nudging is a good idea: telling what path you think it is best and why, but remember: your word carries a lot of weight and people usually expect that a manager makes all decisions.

Another important job is on setting a vision, a mission and objectives: a vision is a long-term objective something that with you expect to reach in 5 year, a mission is a short-term (6 months) and objectives are the guard-rails that will ensure you’re on path to the vision: OKRs is a very famous methodology to help with that.

Process

When teams and companies become bigger it is inevitable that rules, policies and do’s and don’ts start being created. As a leader for your team, it is expected that you keep a constant practice of creating, improving or eliminating team or company processes.

Since the agile manifesto with the tenet People and interactions over processes and tools, processes got a bad reputation: specially the ones more bureaucratic. But the process itself isn’t the problem, the problem is putting it above people and interactions.

I tend to say that the best process is a self regulating one, but I’m aware that it won’t be enough. Self-regulating a team backlog with a 2-3 person team might work, but for a 5-6 person team a regular weekly meeting to discuss and an organized kanban board can be valuable tools.

I tend to start with low or none processes on a new team and when a problem arises, I try to nudge into a process and make a working agreement that we’re going to experiment. With experience, it is likely we will find patterns and solutions we’ve seen elsewhere, but as every team and every context is different, rarely a process took from other team will fit perfectly into a new one.

And if it does not work, you probably need to re-discuss: it is not hard to become the rules cop and start complaining that the people does not follow a process. Instead, do a retrospective and learn what works and what not.

There might be a case in which a process comes from other team and your team is not happy. Your duty is to collect the pain points and bring the concerns to the other team. You actually don’t need to solve everything (and you can’t) but passing along the feedback and listening to the other team concerns as well helps.

Conclusion

I wrote this article as a first reading on someone interested in becoming a manager: I hope that helps you to understand. There are a lot of books and studies about these topics and you will find that improving your skills on them will significantly improve the quality of the work as a manager.

A common path that some companies take is to pick the most senior person on a team and promote them to manager but it takes a lot more than just technical knowledge to be a good manager: being able to communicate well and partner with other functions are other skills that help a lot.

To Learn More

I highly recommend Camille Fournier book The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change: it gives a comprehensible overview of each step on the management ladder.