I have been running an experimental program for engineering managers with Kellan Elliott-McCrea. This program (ineptly named "Engineering Management Program" or EMP for short) is an attempt to strengthen local tech communities by creating a network of managers across companies, and having those managers learn from one another as well as from me and Kellan.
The interesting thing about this program has been developing its focus. We know that the value we have to provide is not in generic management training. Your HR department can provide that, and there are many people out there who run classes, seminars, and sessions for helping people learn how to manage. No, what we're trying to do is engineering management training. Which means that we need to get technical, and talk about technical topics and the issues that are specific to our craft, not generic management but engineering leadership.
It's interesting that it seems to me the pendulum of what people think about in management has swung over the past few years. For a long time engineering management was either looked down upon or seen as a necessary evil for being promoted. Lately we've shifted to celebrating the people management and team-building skills that good managers bring to the table. However, I worry that we've lost sight of the technical, strategic, and leadership elements that are necessary for good management in an engineering organization.
If you are managing an engineering team, part of your job is the job of translator. You have, on the one side, engineers, who are focused on code and systems and technical details. On the other side, you have some sort of business or product, the thing your company does. In the middle is you, the engineering manager. You are accountable for the success of your team. If they make bad technical decisions and can't deliver needed product features, you are accountable. If they burn out because they have no breathing room between product features, you are accountable.
You need to be technical because you have to be able to sit in the balance of these two areas and keep either from tearing the other apart. Your tech leads will not always have the best sense of urgency for product features, or the total context for the business and product details that are likely to come in the future. The business/product team will not have the sense of how small tweaks add up to big technical problems, and what the engineering group needs to do to keep things running smoothly. Neither is likely to have the context for the strengths and gaps on the team itself, who will thrive on which types of projects, and compromises that you may have to make to keep the team engaged. You are the person who juggles the high-level sense of the business goals, the technical difficulties, and the personalities and strengths, and using this context helps to guide decisions across each of these areas.
The technical side of engineering management is a combination of being able to quickly identify technical patterns and pitfalls, being able to guide technical decisions by asking the right questions, and knowing which corners are safe to cut. Technical skills are what give you the credibility needed to ask hard questions of your tech leads and sniff out the bullshit in their answers. It isn't about making a lot of technical decisions yourself, but you have to be able to guide them, to help everyone put them into the right context for the team and business, and you just can't do that if you aren't technical enough to understand the implications of the tech on the business and the business on the tech.
I advise people not to go into management until they feel what I call "mastery" of some part of technology. You might call this feeling "fluency." The knowledge that you can step away for months at a time and drop back in to a skill without significant pain or the need to relearn basic elements. The anxiety you feel about losing your technical edge when you are in management never really goes away, but if you have underlying mastery you can ground yourself in the confidence that you can drop back into writing code should you need to do so.
You may not be writing code anymore, or designing big systems, but your job is still technical in nature. Don't underestimate the value of those skills in being a good manager, you couldn't do this job at all without them.
Until Next Time!
PS: The book is going well, and I am hoping to have it done for a very early 2017 release. Stay tuned!