By Nick Nathan in
LeadershipDespite having the good fortune to be promoted into a management position very early in my career I wasn't really ready for the challenge. I made a ton of mistakes as I struggled to figure out what was expected of me, where I should focus my time, and how to know if I was doing a good job.
Over the years I have learned a lot about what to do as well as what not to do. Here are some of the most important lessons I've learned along the way.
As a newly minted engineering manager it's not always obvious what your job actually entails. Or more accurately, no one tells you what your job should entail.
For most people when they just start out they'll probably only be managing a small number of people and in most cases they'll have been promoted internally from an individual contributor role as a senior engineer or tech lead. This situation generally implies two things:
Because of these two facts there is always the temptation to step in and rescue your team whenever anything goes wrong. You're also more likely to take on large share of the individual contributor work as well in order to hit deadlines and ensure quality standards. Intervening in this way is especially tempting when your team is fairly small i.e. 2-3 engineers.
Constantly rescuing the team does not scale and eventually you will burn out.
The question becomes, "If my job is not to do individual contributor work, then what is my job? Where should I spend my time?" Team size is an important factor and if your team is small you may still be expected to contribute more code or take a more hands on approach. This is fine as long as you're still investing time in working on the team. If your team is larger however this should be your sole focus.
There are three components to working on the team:
The most important thing you'll do as a manager is work to ensure the success of individual members of your team. You are a steward of their career and their champion within the broader organization.
Their success is your success and therefore it is in your best interest to invest as much time as possible in their development and wellbeing. At the same time though, you are responsible for delivering product and meeting your commitments to the business.
Problems will arise because the developers on your team are not as experienced as you or they have less knowledge of the stack and company context. This means that at least in the beginning you will likely be able to perform tasks better or faster than they can. That's normal! You will have to resist the temptation to
Anything your team members do will be on a spectrum from non functional, to functional but poorly implemented, to functional but lacking best practices. Under the pressure of deadlines and your concern for the quality of the codebase and the application stability you will feel the urge to try and correct their work.
If you do this however you are missing out on an opportunity to help your team members improve. Does this mean that you work with them, iteration after iteration until it's perfect? No, you probably don't have that luxury and even if you did it wouldn't be worth the time. Instead focus on 2-3 big things and work with them to improve just those things.
A barrage of criticism is not only hard for your team members to receive from a purely emotional standpoint but it's also difficult to discern what to prioritize going forward. The result of this practice is an improved work product (although not perfect), and a more skilled team member.
Similar scenarios occur when your team members ask you questions which you know the answer to. Why not just give it to them? It's so much faster, right? Wrong. Whenever you solve a problem on behalf of your team member you are pushing work into the future. Sometimes, for expediency this is necessary however often it is not. It requires more work both from you and from them to instead take the time to coach them through the problem so that they solve it on their own.
These approaches prioritize your team member's learning and development and is critical over time. While it certainly feels good to be needed and to have expertise, the last thing you want is to become a bottleneck and train your team to be helpless whenever they encounter obstacles.
These two techniques are going to be the most powerful methods for improving your team. Even lecture style training sessions, while useful in some situations, are less effective than hands on experience working through challenging scenarios. The better you can become at coaching in realtime the better your team will become.
Your team works really hard for you and you have a lot of power over their most valuable asset, their time. It is critical that you respect this. Do not be cavalier in what you ask of them and ensure that you provide clear and direct instruction. This may require that you do extra work upfront to ensure you are clear about exactly what it is that you need and expect of them.
If your team members waste time doing the wrong things it is often not their fault. They do not have the full context that you have and usually must rely only on the direction you provide. Therefore you must invest time in clearly articulating what matters, what to prioritize and what success looks like.
It is your responsibility to protect your team from the leadership of the organization because you are their only representation. If there are problems that you cannot solve that are impacting your team it is your responsibility to communicate this upward. Most importantly, you must own the request. You are not just passing the message along, you are asking yourself.
If your boss is asking for things of your team that you cannot reasonably deliver you have a couple bad but easy options:
The first option is bad because what you're really doing is ignoring the problem and risking not meeting your commitments. The second option seems noble but ultimately comes at the cost of your time and therefore you are compromising your ability to support, train and develop your team. The third option is not sustainable and will damage the relationship with your team as well as lead to poor results.
So what do you do? You have to push back against your boss and protect your team. Even if your boss is irritated in the short term, in the long run you will be respected because you will always be able deliver what you commit to. Never shovel sh** down to them.
Finally, if someone on your team does something wrong that impacts a production system, affects a customer, or otherwise harms the business. It is YOUR FAULT.
The teams' failures are your responsibility.
As far as your boss is concerned and everyone else in the organization is concerned, you are responsible. Therefore the worst thing you can do is blame your team member. You do nothing but undermine your own position as a leader and discredit that member of the team. Instead, accept responsibility and move forward.
As a manager your job is not to build the applications you support but to build the team that builds the applications you support. You build the team, the team builds the product. All your decisions must take into consideration the impact on the team and its ability to be effective. You cannot be there to make every technical decision and monitor everything. You don't have time to code review every pull request and test every new feature. Therefore your time is well spent thinking about how to help your team:
The most effective way to accomplish these objectives without you being directly involved is by training and developing your team. No matter how good your team is though, each individual's locus of control is more limited and their area of focus more narrow. Therefore you will need to rely on systems and processes.
Too few processes and systems isn't good but too many can be just as bad. You must constantly be thinking about the tradeoffs between implementing new controls and the associated time cost.
In my experience systems and processes generally have two characteristics:
Risk Reducers are systems or processes set up to prevent bad things from happening. Examples of risk reducers are code reviews and unit tests. The whole purpose of requiring that your team members have another review their code is to ensure better quality code and reduce the likelihood of bugs. Requiring that your developers write unit tests serve a similar purpose.
Accelerators are systems or processes set up to increase the speed of work or the flow of information. A good example of an Accelerator is a continuous delivery system which automatically runs tests, builds code and deploys it to servers. Another lower tech example might be requiring that team members write documentation.
The best systems are both risk reducers and accelerators. Unfortunately, some processes and systems can reduce risk but decrease speed. Similarly, some systems that increase speed also increase risk. Your job is to strike a balance between the two. A common management practice is to implement a new system or process after every production incident. While this can be useful to prevent future issues, you must be on guard against systems and processes piling up. The danger is that either they are not adhered to and thus lose their value or they slow the team down and make life a bureaucratic hell.
Finally, processes which may have served an important process in the past may no longer serve you. You cannot be afraid to remove processes that slow down your team just because they've always been there.
As a manager your time scale inevitably changes. When you were an individual contributor you only had to think as far out as a particular feature or app. As a manager you have to be living in the present and the future. You must ensure that your team delivers on their project/feature commitments a couple weeks from now, ensure that your applications will be extensible and your architecture stable a few months from now, and at the same time ensuring that your individual team members have a multi year growth and development timeline.
There will always be tension between doing what is easy and expedient in the short term vs what's best for the long term stability of your applications and the health of your team.
This extends beyond merely the technology but also in the way that you relate to your team. If you fail to enforce your processes, let things slide, do not hold people accountable you are making things harder for yourself in the future. You always have to consider how your behavior and your actions today will impact your ability to lead in the future.
When you are an individual contributor you are generally only responsible for things you can directly impact. If you are tasked with building a new feature or application you will be able to control most elements of your work because you are the one doing the work. Once you have a team you will be responsible for more work than you could possibly do on your own. This means that you have to trust your team to be responsible for individual pieces and it is possible that they will fail to deliver as promised.
The gap between what you can directly control but are still responsible for can make new managers extremely uncomfortable.
How will I know if it's being done well? What happens if my team does a bad job? How will that reflect on me? The resulting tension you feel is a normal part of the chaos of managing a larger team. At some point the size of the team and the complexity of the project will make it impossible for you to have full control AND most importantly full visibility. There will be a lot of things happening that you will not be aware of and technological changes that you will not understand. You don't have time to read every new line of code.
Learning to be comfortable with the fact that you do not have control you only have influence is going to be challenging but is nonetheless a critical step. You must recognize the limits of your control, submit to the chaos, and go to work on the team.
The feedback loop in management is far slower than for an individual contributor which makes improving a challenge. Its harder to see the growth and development of your team when you're up close with them and all you can see are balls dropping and mistakes being made. Only when you take a step back and look over a longer time frame does it become easier to see their progress.
Your team members won't tell you where you're failing. Even if they really trust you they have very little incentive to tell you what you're doing wrong. You have to get creative about finding ways to solicit feedback in ways that make your team feel safe. You usually won't get good answers by just directly asking them. Would you ever give feedback to your boss and risk them not taking it well and damaging your relationship? No way! It's much safer to complain in private to your peers.
Because of this you have to find ways to measure team progress and grade yourself according to that scale. If your team is happy, engaged, excited and learning you are doing well but this won't always be obvious. While important, it's dangerous to evaluate your performance only on project delivery or application metrics etc. This is only half the story.
Most of what I've written here is based on what I learned making mistakes in my first few years of managing. A word of caution, while these ideas make sense in theory, learning to apply knowledge is something that takes practice. I am still trying to get better at applying them.
Just like writing your first programs and building your first applications you will make mistakes. You will have difficult conversations, your relationship with your team will have its ups and downs, projects will fail and you'll wish you could just go back to coding all day. Despite the challenges, I found that building teams and coaching individual team members has been one of the most rewarding experiences in my professional life.
Good luck!
If you liked this then you might enjoy my newsletter as well! I send out occasional emails covering interesting ideas I'm exploring, content I've enjoyed, and useful things I've discovered on my journey to become a better human.