Before we can understand the topic of the manager responsibilites, we need to take some time to look at the work of the manager first.
The Work of the Manager
- Hiring and termination
- Providing training for new hire
- Assigning mentor to new hire
- Coaching and developing career path for existing employees
- Resolving conflicts
- Performing 1-1 regularly to do expectation and goals setting
- Monitoring and tracking employee performance
- Conducting performance appraisals
- Handling poor performance problems
- Incentivize the top performance employee
- Aligning all personal goals to the company goals
- Promote healthy organizational culture
- Translating corporate long term goals into functional action plans for medium and short term goals
- Managing expenses and budgets
- Reporting employee scorecard results to senior management
Manager Responsibilities - FAQ
The biggest things employees should expect from their manager are regularly-scheduled 1-1 meetings, feedback, and resources for career growth. Your manager should be able to guide you through the ins and outs of your workplace, in order to help you get around roadblocks in your work, and they should know what resources are available for you to get training. Some managers will act as career coaches for their employees, but this is not always something that your manager can provide. Managers might provide technical feedback, and sometimes set the roadmap for projects for the team, but it’s not universally true that every manager you have will hold these responsibilities.
It’s pretty common for people to have bad managers. Managers who skip your 1-1s, or never even bother to set them up, are a particular pet peeve of mine. Some managers treat their employees like cogs, and spend all their time discussing project status without ever providing any feedback on how the employee is doing, whether they are performing well, or what they might need to do to get to the next phase of their career. And unfortunately, some managers are cruel to their employees, manipulating, micromanaging, or even bully them.
The #1 thing you can do is, as much as you can, choose your manager wisely. We don’t always have the power to choose our managers, but identifying people you want to work for in your workplace is a good idea. When you’re interviewing for a job, ask about the manager you would be reporting to and look for managers who seem to have a good reputation with the people who work for them. There’s no guarantee that you’ll get someone great, but it can help. You will notice that there are managers who have employees that follow them from job to job, which tends to be a good sign.
I also advise people to remember that ultimately, we’re all adults and responsible for our own destiny. That means that you should spend some time thinking about what you want for yourself, and what you want for your career. When you know what you want, you can go out and find it more easily, and you can ask your manager for what you want if you aren’t getting it. If they keep canceling your 1-1s, tell them that you would like to get on a more regular schedule. Ask them for feedback explicitly. Tell them what you are hoping to accomplish in your career, so that they can better help you.
If your manager turns out to be cruel or harmful, take care of yourself. It’s not easy to quickly get out of these situations, but I generally think that the best thing to do when you find yourself working for a bully is to find a new team or a new job, if at all possible.
I think that many people don’t realize that their job has changed when they get this role. Instead of focusing on writing code all the time, they now need to pick up a lot of other pieces of delivery, such as technical project management. And their managers often don’t really make it clear what it means to be a successful tech lead. In fact, many managers don’t really have a clear idea what a successful tech lead looks like, partly because it depends on the team and the projects that the tech lead will be dealing with.
When I’ve seen tech leads struggle, it has been largely with the change from heads-down 100% focused engineer to only doing that, say, 30-50% of the time. You’re pushed out of your comfort zone, and if your manager doesn’t help you understand what the new role needs, it’s very hard to know what to do. So you get people who stop coding entirely and become a full project manager. You get people who think they are the person who makes every technical decision for everyone on the team. You get people who start micromanaging everyone on the team. And of course you get people who take the role on but don’t actually change their day-to-day, and neglect everything but the code.
In general, every step into technical leadership means a change in your day-to-day job. You don’t really get promoted for doing the same thing you’ve been doing most of the time.
You may be the best person to do the job, but you may not be the best person to lead the team. The good news is that you can be trained to be a manager. You will need to attend softskills training in management, communication and leadership.
First, recognize that while you are the tech lead, that doesn’t make you the technical dictator of the team. Figure out which technical decisions should be made by you, which should be handed off to other team members who have more expertise, and which decisions should involve the whole team coming to a consensus.
Second, be careful of getting too obsessed with processes to solve problems that are related to communication or leadership gaps. Some tech leads think that the solution to every problem is a new or better process. While process can be useful, it can also be overdone, and it is rarely the one true solution for a dysfunctional team.
Third, don’t step entirely away from the code. As a tech lead, you should be writing code some of the time. It may only be 30% of your time, but that is enough for you to be staying in the mix of what it is like to write software on your team. For people who become engineering managers, staying technical is an important element to management success. While you will probably stop writing production code at some point in your management career, staying technical by reading code, writing scripts, debugging, and staying in touch with technology news and trends is a pretty critical part of successful technical leadership.
Absolutely. I think one of the nice things about the way most tech companies think about career growth is that there are usually two paths: one for management, and one for technical individual contributors. For people who have not yet chosen a path, the tech lead role can give you some idea of which career path might be more interesting to you. If you like the management elements of being a tech lead, great, but if you prefer the technical focus and system design and don’t want to think about the people and organization, you may decide to stay on the individual contributor path.
My personal advice for almost everyone is that you should be a tech lead once, even if you know you don’t want to be a manager. If you choose to remain an individual contributor, following that path requires you to exercise leadership and understand how to get teams rallied behind your ideas and executing well. So you want to learn these skills, but that doesn’t mean you have to become a career manager.
Spend time getting to know your new team as individuals. If you are coming in to manage a team of individual contributors, don’t just focus on understanding the projects and the tech. Ask the team members about themselves, how they like to receive feedback, what they’re excited about at work and what they’re struggling with. Get a sense of where they are with their career and what kinds of career goals they might want you to help them with.
The other advice I have for those just starting out as a new manager is to give yourself some time to figure out what the group needs most from you. Whether you’re new to management or new to a team or company, each situation is a little bit different. Some teams need more hands-on help from you, and you’ll find yourself very internally-focused on the day-to-day operations. Other teams may be operating well but need you to help them figure out the future strategy or advocate for the team’s projects with other groups externally. There is no formula to apply, so be flexible and look carefully for where your efforts will be most valuable.
Continuous feedback requires some work on the part of the manager. You have to be paying attention to your team in order to see things, and then get into the habit of regularly providing praise and constructive criticism. It helps to know what your people are looking for. What are their goals? What do they want to get better at, or stop doing? Get into the habit of touching on this feedback in your 1-1s, even if it’s a simple “nice work helping James debug that issue”.
You can get your whole team into a habit of continuous feedback by encouraging processes like regular retrospectives. This encourages the team to notice what’s going well and what isn’t going well, and talk about it openly. The easiest thing to start with is handing out kudos when people do things well. Regularly recognizing good work is a simple first step. But retrospectives are not just about what’s going well, and providing room to talk about the things that are less positive is just as important in creating a healthy team.
The balance is tough, and it changes as you grow to manage larger teams and organizations. In the beginning, as a tech lead, you are probably still writing code, but if you continue on as a manager you will eventually realize that you don’t have the time to write quality code and push it all the way through to production.
My advice is to make sure that you aren’t holding on to hands-on tasks just because they are the thing you find easy. It’s hard to make the transition to being mostly hands-off, but you do your team a disservice if you neglect your management tasks to focus on writing code. This is the time to practice the essential skill of delegation. You might love the technical details, but you need to train other technical people on the team to manage those details so that you can look at the broader picture. If you really find that you don’t feel ready to give up the technical work yet, then don’t follow the management path yet. It’s better to stay in an individual contributor role until you feel that you have achieved mastery than to jump off too early and wonder what you’re missing.
Finally, you don’t want to completely lose your technical edge. Stay informed by occasionally reading through code and doing code reviews, helping to debug systems that you understand well, asking engineers to give you deep dives on the systems they are writing, or even watching talks and reading blog posts.
Debugging slow teams can be similar to debugging slow systems. You need to have a sense of the various places you can inspect to figure out what’s going on. Usually, there are pretty obvious causes to the slowness. Too many alerts or incidents that are causing the team to spend a lot of time firefighting. Projects that are unclear or poorly specified, which means that you need to work on making the requirements clearer. Developer tools that don’t work well, slow builds, painful release processes, or other bottlenecks that slow down the act of writing code. All of these are problems that you can tackle by prioritizing work to stabilize the systems, speed up the processes, or improve the specs.
Sometimes though there’s no one obvious cause. In these cases you might need to dig deeper. Are there personality conflicts among team members that are causing tension? Is the team bogged down in a bunch of pointless meetings or bureaucracy? Do they feel like their ideas aren’t being heard and demotivated by a culture that expects them to just churn out code without listening to the team’s feedback on what they could be working on? These challenges take longer to solve. Take the time to talk to team members, sit in their meetings, and get a feel for the group dynamics, and look for ways to change the processes and interactions.
It can be easy to become a CTO or VP of Engineering- just be the technical co-founder of a successful startup! Of course, getting the title and holding onto it as the team grows are two different things. Whether you get the role by being in the right place at the right time, or by years of climbing the ladder, there are some common skills that successful leaders have to learn.
There’s a lot of factors that are different than being a successful tech lead or engineering manager. For one, you need to communicate with a lot of non-technical people, and that requires the ability to translate technical challenges into a language and format that non-technical leaders can understand. You need to have a sense of the larger business that you are working in, and understand what is important overall to that business, even when it is not purely technical. As a senior leader, your first team is not always the technology organization. Your first team is the other company leaders, and you have to think first about what will make the overall company successful, and only after that do you worry about what the technology organization might need.
However, just because you spend a lot of time thinking about the larger business doesn’t mean you ignore the technical side of things. You may be the person who sets the larger technical standards and culture for the company, and that means understanding what is really important for the technical team to value and making those values and standards clear to the team. You are also going to be the role model for the team. They will look up to you and pay more attention to the things you say and do than you might expect, so you must behave in a way that you want your whole organization to emulate.