This question was recently asked in a local engineering slack organization and it got me thinking, what would the ideal amount of time spent on technical contributions be for me? When I first transitioned from a developer to a manager I didn't know how I provided value. I assumed that being a manager was largely the same as being a developer except now I had to talk to other developers and help them become better somehow. As meetings, writing more and more documentation, project planning, people planning and other managerial responsibilities started to pile up I started blocking the team on all of my technical tasks. What used to take me a day started taking three or four. Projects that I would have finished in a month stretched on for a quarter and the more technical work that I took on the less happy both my team and I was. I started to burn out and my team started to get frustrated with the way I blocked them on their own work. It took me over 18 months in this first management role before I figured out how I provided value as an Engineering Manager (EM) and started reducing my technical contributions.
So, how much time should you spend?
It depends! Your job as an Engineering Manager is to unblock your team and help your developers grow. Depending on the size and makeup of your team this can mean very different things. It can also mean different things at different times in your career.
If you have a really junior team, you may have to be more hands-on, mentoring them, and teaching them how to build software and grow as an engineer. This could take the form of pair-programming through different features and projects. You may spend more time reviewing pull requests or sitting down and walking them through architecting a solution. Time spent here growing their own engineering skills will hopefully help them down the road as they grow into more senior engineers.
If you've got a more senior team or a team of really strong developers your technical contributions may fall to nothing. Sure, you may want to review a PR or two to make sure you have a handle on how your team is doing. You may also want to unblock your team by taking small, one-off requests that come up but you shouldn't be taking on large features or complex tasks. Taking on this work will only block your team and take away opportunities for your team to shine.
But I love coding!
Me too! Being a great developer is often what gets us to the manager position in the first place and it can be difficult to give up something you enjoy doing. This is where it's important to know what you want to get out of your career and to find a mentor. Going from an IC to a Manager is a career change. This change can be difficult, especially if you weren't expecting it. Having someone to support you during this change and taking the time to really understand what you want from your career can help you let go of coding.
It's also important to find a creative outlet. Coding is a creative career and as you become a manager and your day-to-day changes you'll often find yourself yearning. Lots of Engineering Managers build side projects or contribute to open source projects after hours. This provides a creative release and also allows you to stay technical. Others take up a hobby like woodworking or photography. These kinds of hobbies provide a creative outlet and fill the hole left by coding.
How will my team know what I'm doing if I'm not coding?
One common fear of new managers, especially those that are now managing their peers, is the feeling that they're not doing real work. Because you're no longer hands-on with the code base and often have your schedules chock-full with meetings it's easy to worry that you'll be judged. One thing you can do is be transparent about what you're working on. This not only helps you stay accountable for what you're thinking about and working on but it also helps give your team insight.
Every Monday morning I like to post a quick message to the team about what I'm focused on for the week. These can be presentations that I'm preparing, meetings that I'm having, strategy documents, and conversations that I'm having. You do have to be careful to not talk about confidential things you're working on or things that may be sensitive to some people. These messages help inform the team of what you're doing and help provide transparency. They can also help if you're mentoring any of your engineers into a management position.
Final Thoughts
It can be difficult and scary to give up programming as a manager, especially if you've been doing it for a long time. As a manager, your job is to help your team grow into better engineers and build a team that delivers great software. Depending on your time size and makeup sometimes this means that you still need to code regularly, helping unblock your team. More often than not, your technical contributions will go down as you grow as a manager so make sure you find another creative outlet!
Top comments (0)