Commentary: How to keep coding as a technical manager, to cause maximum pain
The output of the team is more than your output
Original post: How to keep coding as a technical manager to cause maximum pain
Every company has a layer of managers who are technical (former programmers), but their primary job is not coding. Smaller companies tend to have player/coach technical managers, but as they grow, there is a line past which a manager only commits code that helps the overall team: tools, configuration files, etc. They aren’t writing code every day.
In many companies, this difference is between Tech Lead and Tech Manager, and when promoted to a more managerial role, many of us struggle. The line can be seen at other companies once people actually “HR-report” to you. Becoming this type of manager is a career restart.
This is because of these facts:
You enjoy coding and are good at it.
It is better for your employees if you understand coding at a detailed level. People are happier when their manager understands their work.
Being a manager involves focusing on everything but writing code. Your job is not to write code but to ensure the right things happen.
Your coding messes up the dynamics of your team.
Most of us fall into accidental coding too often because #1, #2, #3 are obvious, and #4 isn’t.
Why your excellent code messes up your team
You aren't a member of the team when you have a direct influence on who is and isn't on the team. Having people report to you pushes you outside the team. You are now responsible for the team's output but aren't a part of it. People laugh at your jokes, don't criticize you, and assume things because they don’t want to ask them.
Things like: “Why are you working on this feature instead of me? Did I mess something up? Do you not trust us to do it?”. The team assumes that you will work on The Most Important Thing to help them, so your grabbing coding assignments sends a double-edged message to the team: there aren’t enough manager things to do, and they need help writing software. If a project is late, or there is some critical bug, and you prevent the team from solving it themselves, instead coming in to Save The Day, this message is much louder.
You want the team to have a high sense of ownership, so you must be delicate in how you intervene in their day-to-day work. As a manager, you should get furniture out of the way but let your team dance. If you continue to dance all the time, it prevents their growth. Yes, you should use your extensive skill and expertise in coaching the team when they need help, but you should do this carefully and with the team's interests trumping your ego or interests.
How to stay technical without messing up your team
But at the same time, if you drift away from coding for years, this can make you an unhappy person and a less technical manager. If you feel you must be involved in some things, you have a few choices.
Work on the things that nobody wants to work on, things that don’t teach, like the build and deployment pipelines.
Work a bug every once in a while when the bug count is high (make sure to share what you learned)
Code outside work
Read all the check-ins
Participate (carefully) in code reviews
Caveats and It-Depends and Common Objections
“But I'm such a brilliant programmer! My work is so much better than theirs!”
If your team is very junior and you are very senior, you might need to turn up the volume on your influence. Do more direct coaching, write code as examples, etc.
Also, are you a brilliant manager? Can you raise the quality of their work without doing the work? If not, maybe go back to coding. If not, follow your brilliance. If you are good at both and want to do both, move to a team lead position or work at a smaller company.
“I code all the time, and it doesn't seem to cause any problems”
Is this a blindspot? Do you match the criteria above in that you are expected to be a manager and not a player/coach? Sometimes, a programmer is given a title they don’t do as a reward. What are your peers with the same title doing? You might need to ask yourself a tricky question: what would happen if you moved off the team? Six months later, would the existing programmers take on more or less responsibility?
Common mistakes for new managers will become a newsletter theme, so look for more advice over time. Unfortunately, a lot of what ails software teams can be laid at the feet of or viewed through the lenses of poor leadership.
See Library for Subscribers for book recommendations on better technical leadership.