As a software engineer, I associated my value directly to lines of code and number of git commits I could churn out in a day. I struggled with a feeling of not accomplishing anything real because I was no longer delivering features on a regular basis. The coaching and mentoring from peers and supervisors helped me recognize that there are other means of contributing value. Specifically, helping my teams remain focused on their goals, removing friction, clearing out roadblocks, and mentoring engineers to level-up, all add tremendous value. These days, I primarily tie my success to the success of the teams I oversee.
I agree with Brice’s conclusion that moving from Engineer to Manager requires a shift in an understanding of self-worth and value at work. Goal-making and roadblock clearing are very important for the success of a team and a department.
I disagree with Brice’s conclusion that a Manager can and should devote 20% time to programming with their team. This is a mistake for a few reasons.
- You are assuming your team wants to code with you!
A software team is largely flat in organization even when veteran and junior programmers are mixed together. The code review process is a peer review process. A manager by definition is no longer a peer on the team. Your presence and opinions hold different weight now, and so you risk making your engineers uncomfortable contributing and giving feedback the way they would normally.
- Your value is not in clean code anymore. Stop trying to add value there.
The engineers on your team should be building and maintaining an environment for clean code. Your job is to remove obstructions to that end. If a production team member is taking valuable time with pointless meetings, you can work with that person to unblock your engineers. If two of your engineers are not working well together, you can resolve that people problem and unblock your engineers.
Don’t be mediocre at two things. Be really good at one thing!