I was trusted first with engineering manager responsibilities just a few years into my career. I wasn’t explicitly told I was going to be an engineering manager and no one at that small company had such a title. Instead, I was just asked to ‘watch over’ a few other engineers and make sure they had everything they needed, unblock them and ‘lead’ the direction of the project we were working on. That experience lasted a bit over a year or so and you would not find it in my resume as a ‘management’ role because I was very much still spending most of my time coding and, quite frankly, at least back then I found the notion of being a manager somewhat silly and embarrassing.
The second time around I already had six years of software engineering experience (enough to be called ‘senior’ at most places) and I was explicitly asked if I wanted to take on the role of engineering manager. I hesitated a lot because I enjoyed writing software and did not want to spend my time in more meetings, but this was presented as a ‘promotion’ and it was worded in a way that indicated my day to day would not change ‘much’ other than a few more meetings. I did not know better, so I accepted. No training, no guidance and no coaching beyond informal talks here and there with my manager back then (in retrospective, I realize he was winging it as well and I don’t blame him). This time around however at least I read some blogs here and there and tried to understand the basics of what I should be doing as a manager. However, it was still not something that I considered worth my full time and attention. Over the next 6 years I learned a lot of things by doing many mistakes while growing a few teams head count. There were mistakes as well that I did not recognize as such until my third role as a manager at another company where for the first time I was spending my full time in a leadership role and where management was taken more seriously. The right kind of serious.
I’m sure my experience is not unusual and a lot of good engineers out there find themselves managing teams without the training and tools to do it effectively or even knowing if that’s what they want to do. I am writing this post as a way to reflect on what I wish I had known back then and what I now try very hard to teach new engineering managers.
This is a new role
This is an entirely new job. Forget the notion that is an “additional set of responsibilities”. For very small teams and companies that may hold true for a while, but it is also very likely to change quickly and without notice. Your performance is also not measured anymore solely by your individual contributions but rather for the whole team output, even when you do not have direct control over their actions.
Although this blog post is framed as advice to new engineering managers, it can also be used by aspiring engineering managers. It’s even better if you read this advice and the resources I linked here before you make the decision to take on an engineering manager role.
A fantastic resource if you’re considering the engineering manager path is this youtube talk from John Riviello: https://youtu.be/hMz6QDURQOM.
For whatever is worth (it does align roughly with my experience though), Gallup has an article about the importance of selecting great managers and goes on to describe some of the talents that make a great manager. These are a few good questions to ask yourself given you may need these skills to excel at your role:
- Motivate every single employee to take action and engage employees with a compelling mission and vision.
- Assertiveness to drive outcomes and the ability to overcome adversity and resistance.
- Create a culture of accountablility.
- Build relationships that create trust, open dialogue and full transparency.
- Make decisions based on productivity not politics.
Serious kool-aid aside, some of these skills are actually interesting traits to develop and that I concur are important traits to aim for, even if you never get fully there.
A more immediate concerns is that you should take a minute and consider how your new role affects the relationship with your team, specially if you’re going to be managing the same team you’ve been part of as a developer before. There is a pre-existing relationship that will change to some degree. Remember you’re no longer their peer. You’re also not their ‘superior’ (I dislike that common word used in some contexts), however there is a very real power imbalance because you now have a direct influence in their career growth, compensation and overall job satisfaction. You need to consider you’ll learn more about them in some areas and will not be involved anymore in others. Being their ‘friend’ may become trickier or more ambiguous than before and is best avoided because you will need to still deliver objective feedback about their performance, nudge them about tasks or projects and other activities that not everyone feels comfortable with right off the bat doing with a friend. You also do not want to send a message of favoritism to your team if you’re spending a lot of time out of work with someone from your team. You’ll have to learn to deal with those situations and establish respecful professional boundaries that allow both you and them to be happy at work and have a healthy team culture.
Take it easy
One of the great things about starting your first role in engineering management at the same company you were a developer before is that you can take it a little easier. You’re often already familiar with all the tech stack and services and may be even have the same team members. Rest assured people that offered you the opportunity to step into this role has worked with you and they know you can perform well. A little bit of impostor syndrome is normal but in general is best to relax. Avoid at all costs making the mistake of wanting to perform both your previous IC (individual contributor) responsibilities on top of your new management responsibilities. As explained before you’re in a new role. Unless your manager is delusional (in which case what are you even still doing there?) they expect your development output to be reduced at least 50% if not more. This of course depends on how the role is defined at the company, the size of your team, etc. You may still enjoy the luxury of some serious coding with a small team (2-4 members), but it may depend on other aspects as well, even with a small team if there are a lot of of growth and/or inter-team dependencies as is often the case in a large company, may be even that is not realistic. The point is, you cannot be expected to be performing your old role responsibilities nor should you try. Be sure to talk to your manager about these expectations, ideally before you start on the new role.
You should not take on critical tasks from your board or you’ll become the bottleneck real quick and that will just add to the pressure you have about performing in your new role and you’ll end up committing subpar code at odd hours of the day (or night) and make your team miserable during PR time if you’ve been out of the loop with important implementation details or practices. It’s best to start taking tasks where some delay can be tolerated without a fuss. I often would take tasks that the team had been postponing for example because they were not glamorous, but once done everyone was happy someone had finally done it and made their lives better. From time to time you may indulge yourself doing interesting work as long as it’s not critical. You should be wary of not doing a lot of this because your team members are likely also eager to tackle that interesting work and giving it to them is part of their job satisfaction and career development.
Manage your time
When you’re an IC, you should have very little time spent on meetings (if you have a lot of them is time to talk to your manager) and it’s more straightforward to know how you should be spending your time. Once you transition into a management role, your calendar will become a much more important tool than before to prioritize your time. You need to start making a lot more decisions around where to spend your time and which meetings are worth the time attending and which ones aren’t. Moreover, what do you spend your time on is likely to change depending on the stage of maturity of your team and the projects you’re working on.
These are a few key anchors that can help you guide where you should be spending your time on. I am not suggesting specific allocations for each as those can vary wildly depending on your own personal and team development stage but at least I tried to prioritize them according to what I believe is more important:
Know the team. This may sound easy if you are managing the same team where you used to be a developer, but in those cases it just presents different types of challenges because you’re no longer their peer (see my explanation before about this). You should allocate time for 1:1 meetings with all your team members on a regular basis. Get to know them, what their interests are and start understanding where they want to go with their career. Sometimes they don’t even know themselves, and talking and asking questions is one way to help them discover it. Allow them to provide feedback and never get defensive about it, even if the feedback makes you uncomfortable, you should be approaching feedback with a genuine interest in understanding their point of view and improving yourself and/or the organization.
Know the tech. You should be on top of the work all your team is doing, reviewing some pull requests, collaborating in architecture sessions, etc. Not all of those activities all the time, but some. Use your engineering experience, business and team context to advice the team whenever needed, but without meddling on the details or stripping your team from their autonomy. You need to be a guide. You need to learn to drive decisions by consensus most of the time and only use your ‘authority’ to break ties if consensus is taking too long or cannot be reached (team members disagree strongly about the technical approach for example). At some companies you may not even hold any ‘authority’ to break ties and you need to rely solely on consensus. The signals may be hard to read, but with experience (know your team and product), you will be able to do it. I’ve found very often teams will prefer having an assertive leader that is able to unblock a gridlock, explain the reasoning for making a decision and moving on than someone who cannot make a decision or drags the process too long when the team fails to reach one and has a fully democratic approach to every decision. This is to be balanced carefully as you don’t want to become a dictator, or worse, a dictator and out of touch manager.
Know the product. This one means knowing the product beyond the tech and implementation aspects of it and get much more intimate with product areas beyond your immediate responsibility. You should get knowledge about how the product is used, who are your top customers and why, what are their more important use cases, etc; In most organizations you should have a product owner (or manager) or some other business person that can help you with this sort of information and they will usually be delighted to have an engineering lead partner with them and think of the business side together. Part of your role after all is helping translate business requirements into a feasible engineering plan and execute it on time. Although product owners are there to help you make trade offs, don’t assume they know everything and always stay curious.
Know the company. More than ever you should build relationships with people outside your immediate team. Think of other key stakeholders and grow an interest in what they and their teams are doing and share what your team is up to as well. Be an advocate in the organization for your team. Stay informed and share information. You should even request 1:1 meetings with some people outside your team to learn about them and their team’s work (e.g may be you have one or more teams you have a strong tech dependency with and that could be a good starting point). You are a connector now. Knowledge about the company and the people than runs it will help you when making decisions and providing your team with the tools and opportunities to do their best job.
You should manage your time and invest it in the areas above. If you increase your knowledge of all 4 areas it will help you make decisions and create a long term strategy for your team.
Learn to delegate
Up to this point you have been successful largely because of your individual contributions, which often means you’ve been very good at taking on tasks on your own. You may have shown initiative to ‘just do it’ yourself rather than talk too much about it. Although those continue to be good instincts to have, you need to learn new tools to get them done. You do not scale as an individual. There’s only so much work you can accomplish on your own, but if you learn to leverage your team wisely you can, and should, increase the output of all of your team members. Yes, sometimes you may know a specific subsystem so well that it’d take you a lot less time to do a specific task yourself than letting another engineer do it, but these are the opportunities you need to provide to your team members for career growth and knowledge sharing. Do not rob them from those opportunities. For senior engineers in your team it will be particularly important to start delegating to them ‘ownership’ over projects as opposed to just the design and implementation of the work they do. As engineers grow in the technical career ladder at most companies they’re expected to learn how to run projects. Yes, that means some project management skills such as tracking dependencies and risks (e.g other teams consuming your APIs or APIs you need from other teams and their team timelines), distilling requirements, formulating and executing a plan to deliver the project whilst having you there to provide coaching and assistance whenever needed.
You can watch the following video that talks more about this topic and the resources I link below also cover delegation extensively: The new manager death spiral
Remember you’re now on a different career path. It’s a related path but still different. You can try it and decide is not for you and eventually go back to being an IC (I did that once, and may be at some point I will again). The skills that got you here are not the same skills that will make you successful in your new path. Be open to learn these new skills. Learn to take it easy, manage your time to invest in the right areas and build trust by delegating to your teammates and you’ll definitely be off to great start in what can become an incredibly fulfilling career as an engineering leader.
Management 101. If you read this series of blog posts you will be 100x better prepared than I was when I started on my first management role. The book from
is a deeper dive on those topics and highly recommended after you read the blog posts.