I've found that in tech, a common way for a successful programmer to move up the corporate ladder is to step into a management role. There seem to be more roles in engineering management than there are higher level programming roles such as Staff or Principal.
When a software engineer steps up it is often because they were great at writing and contributing to code. Should these experts continue code in a management role? Industry standards are wildly inconsistent, but I think the answer is no!
Why Manager's shouldn't code!
When I had people reporting to me, I tried to avoid writing code, and here are a few reasons why.
- Differing Responsibilities: A people manager has different responsibilities than a programmer. This could include things such as 1:1s, professional development of their reports, running team meetings, building out a roadmap, reporting to higher ups on the team progress, and helping build a stable roadmap. Check out my post on a typical day for me as manager. There was not enough time for coding to be my focus
- Power Imbalance: Because the programmers on a team report to the manager on the team, there is an inherent power imbalance. A manager can make the lives of their reports difficult, or easy. A manager also has input into things like performance reviews, promotions and raises. Will the programmers be willing to push back on the manager, knowing the power they hold over them?
- Objectivity: This is an extension of the power imbalance. What happens when the programmer doesn't get the raise, or promotion they wanted? What if they don't get put on the projects that interest them? Was this because they disagreed with the manager in a PR review? What happens when the developer who green lit a PR with a "LGTM" does get that promotion, or bigger bonus? Is one person being favored over the other? Or is there retaliatory action? A manager must always present the image of being fair and treating all their reports equally. Part of the management job is to create a level playing field for all team members. They need to remove the impression of bias. By working on the same tasks that the team does, these objectivity waters are muddled.
- Micromanagement: I think that a manager contributing to code is the epitome of micromanagement. While it is important to understand the type of work your team is doing, it does not instill confidence, or autonomy, with the team that you need to jump into their domain.
- Trust: It all comes down to trust. The manager must trust their team to take care of the tech work, to determine a good architecture, and to make good decisions. I'm fine with a "Trust, but Verify" approach. It is perfectly okay for a manager to ask decisions about the architecture, and understand the ramifications of those decisions, but the devs should be laying out the path forward, and living with the consequences.
When is it okay to code?
Is there ever a time when it is okay for a Manager to code? I'm cautious to say yes. I work for a very large conglomerate with clearly defined roles. I imagine that in startups or very small companies managers who code may be a necessity. If the the "CTO" is also a founder and bringing on a team for the first time, it makes sense they'd be mentoring and teaching the new team about the code base.
If a manager must code, I feel it should never be a mission critical project, because other responsibilities always shift focus. Small unimportant bugs are a good choice.
Final Thoughts
My favorite leaders are the ones that came up as programmers and are passionate about code, and good code practices. But they should leave that behind as they step into the new role. They should foster a culture where good code practices can thrive, but they should not be involved in the day to day evolution of code.
What do you think?
posted by Jeffry Houser in
Management, Professional
| 0 Comments
