“Every time an engineer becomes a manager it is a loss to the company,” said a manager on my team as we discussed moving one of his engineers to management – and he wasn’t wrong.
Engineers build things. Individual contributors, at least in a research and development shop, contribute to that research and development. Managers are overhead, and grappling with this fact was the hardest part of moving from engineering into management. I used to finish every week with a list of accomplishments. I could point to some new behavior in the product, a new API, or an icon that didn’t appear in that spot when you did that thing. I was doing stuff and it was great.
After I finished my first two weeks as a manager, I couldn’t tell you what I had done. I talked to people, sure, and those people did things, fine, but I hadn’t produced anything of concrete value myself. To be honest, that was really hard for me. My ability to create something out of nothing more than an idea was a part of my identity, and now it was gone.
It took me time to understand the worth I was bringing to the team. I think it was about 3 months in that we shipped our first small feature after I became a manager, and that was the first time that I really felt like I could point at something and say “that probably happened better with me being involved.” By that point there were plenty of actions that I had taken as a manager, but it wasn’t until code actually shipped that I could feel comfortable that those actions were actually, in sum, leading to an improvement for the team.
When I became a manager, I spent some time talking to other managers at the company I was working at, asking them what they did, and how they managed that same transition. One of them told me he used to look at TFS (our ticket tracking system) to see what he had gotten done over the week, and now he looks at Outlook. That helped a bit, at least there was a place where I could see an accounting of the actions I took as a manager, but it doesn’t hit quite the same as seeing completed work in the product. The problem is that outlook can tell you some of the actions you are taking, or at least some of the conversations you are having, but not the results those actions have produced.
This lack of sight into the value you bring is compounded by the fact that when you start out, you probably won’t be adding much value at all. Now you are taking your first step into a new job. You probably didn’t launch straight into your first development job, straight out of college, or a graduate program, or a coding boot camp as a master of the craft. You should not expect to be a master of management on day one. In many ways, becoming a manager is starting all over again.
So why would someone move from a job as a productive member of a software development team to being overhead? Why did I make one of my engineers a manager, even though the loss of her work as an engineer was absolutely a loss to the company? It is because there is a job to be done as a manager, and doing it well can be a multiplier on the work done by the team. A good manager can coach and mentor and raise the skill of their team. They can guide the team towards adopting processes to run more effectively. They can provide the right information to the right person at the right time, allowing for better decisions and allowing engineers to safely ignore irrelevant details, knowing that their manager will remind them if they become important. They can help focus the team on the most important problems so that the work being done is the most valuable work that could be done. In short, there are many ways in which a manager can increase how productive each member of their team is, even if they themselves produce nothing.
Leave a Reply