One of the biggest difficulties in transitioning from a software developer to a manager is coming to terms with the realisation that producing code is no longer your primary objective.
Chances are, while you were a software developer, writing code was something that energised you. Your impact was measured by the quality of your code and the value you were able to unlock for your customers. So it’s understandable that you start feeling some amount of guilt and anxiety about your dwindling code contributions after becoming a manager.
To be considered impactful, how much code is an engineering manager expected to write?
A quick search uncovers a wide range of opinions from “not at all” to 30% to even 50%.
So, what’s correct? Unfortunately, as with many things related to management, the answer is very context dependent.
Instead of focusing on this question, let’s first take a look at a few** wrong reasons** to write code as a manager
1. I need to keep my programming skills sharp
As an engineering manager, you need to be able to gather context and understand the challenges your team is facing at a technical level. Doing this requires keeping your technical skills up to date.
A lot of managers use this as an excuse to continue contributing heavily to the codebase as a developer.
However, you can also accomplish this by,
- building tooling to make your team’s day-to-day work easier
- creating POCs to explore the feasibility of upcoming work
- cleaning up tech debt
- fixing bugs
- getting your coding fix outside of work
Continuing to stay technical is important, but this doesn’t have to come at the expense of you continuing to be a heavy code contributor.
2. I can do it faster. I have more context
Maybe your team is relatively junior. Maybe your tenure with the company has provided you with more historical context about the app and the domain than your team.
As a former developer yourself, it’s easy to settle into a place where you become the person everyone depends on to “build things the right way”. It feels good and it feels comfortable.
But, it doesn’t take much to realise that this way of managing a team is not sustainable or scalable. Not only does this come at the cost of your managerial responsibilities getting sidelined, but you are also building a toxic hero culture that creates an over-dependence on yourself.
Whenever you find knowledge gaps in your team, take the time to
- do knowledge deep dives (and record them for future team members)
- add documentation to your development wiki
- set up pair programming sessions to disseminate the knowledge
If you feel that your team needs to level up their technical skills in general, provide them with good resources to help them get there. Encourage them to add learning blocks to their calendars so that there’s dedicated time each week to grow and get better.
Put in the work now to invest in your team’s growth. It will pay off with interest in the future.
3. I need to maintain credibility with my team
As I wrote about in one of my previous posts, if you are a new manager who has joined an existing team, building trust and gathering context by coding alongside your team is very important.
But you don’t need to keep proving that you are still technically competent week after week. Once you are settled in, get off the critical path. Focus your energy instead on enabling the team to do their best work. You can still stay connected to the day-to-day by continuing to do pair programming, code reviews and being a part of technical explorations.
#coding #engineering-leadership #engineering-mangement #management #software-development
