There are several really good software engineering people that I know who have moved into more of a management or product ownership role. The thing that causes me to lump them in one bucket is their ability to get things done in their more advanced roles while clearly stating a desire to get their hands dirty in the low level details. I think a common thread is “man, I’d love to jump in the code with you guys, but I have this meeting.”

I think that changing roles naturally results in this feeling. When you have different or higher priorities, you must deprioritize other things.

I think these managers yearn for the simplicity of having just a technical problem to solve, now they are thrust into solving the hardest problems of the organization and doing this by coordinating resources they have never previously needed to worry much about. For managers who have been “out of the game” for longer, there may be a bit of nostalgia for the thrill of coding and having a clearly defined problem to work on. There are the war stories that drive experience but then they realize it has been ten years since they had that experience.

One reason I find this interesting is that I have a much higher esteem for people in this group as opposed to someone who does management-ish activities but does not have a technical background. I think there is a mutual respect because I know that the engineers know what is going on and can help solve tough problems that come up. They have been in the trenches and have seen some gnarly stuff. The fact that they can also manage the project is an added bonus. There is probably more empathy on both sides. I sense what it would feel like to want to jump into the gory details and not be able to. And they have been in their coworkers’ shoes.

Engineering managers have one foot firmly grounded in the technical world and the project or problem domain. They know how to debug the driver issue you just ran into, and can wax philosophical about their strong opinions, weakly held.

The other foot uses those problem solving techniques and applies them at a grander scale.

Tips

So what can an engineering manager do? There are a few ways I can think of to deal with wanting to dive into the details.

The first is thinking of programming through processes. I almost envision higher level engineers of this sort “programming” by moving cards around in Trello or having a weekly meeting with the heads of four groups or having one-on-ones with their coworkers. It is not programming in the traditional sense, but more along the lines of solving important business problems with analytical thinking and processes. I think this plays to the engineering manager’s strengths while giving them more leverage.

For example, instead of coding something for four hours, they have a fifteen minute discussion with someone on their team about it. Magically, the module is coded the next day. That is 16x leverage, aligned in what is likely the right direction.

A second mentality to have is to realize that you are working on solving arguably the most important problems. While you are skilled and competent in solving small technical problems, the organization has a greater need for the work that you can do. Again, this goes back to leverage. Why influence the outcome of one module when you can influence the architecture or institute best practices that will increase the efficiency of your team? You have the ability to see the forest and the trees, and not everyone does or does yet.

Third, keep your skills sharp. Have small side projects to evaluate new and upcoming tech. Stay involved in the code by fixing one thing a week, working on tooling or deployment automation, reviewing code, and helping others with their problems. Be one step ahead of the issues that your organization will have.

You are not going to forget how to code, and you will learn other things as well. You may not remember the exact order of arguments for an obscure API, but you know how to figure it out. You certainly won’t forget what you know overnight, so relax. :)