(Crossposted from leaddev.com)
Last week someone asked me this question, ‘How important are management skills vs. the rest of it?’
I have thought long and hard about this; not least because our profession has a long and inglorious history of treating technical skills as innately superior to other skillsets (and engineers as superior to other professions). It’s as though simply learning to code well is some kind of wild card ability that makes you instantly better at everything else around you. My instinct is to say that engineering skills are non-negotiable and the managerial skills can be acquired later, but am I simply manifesting that same old snobbery?
I don’t think so. But maybe! I will make my case here, and let’s see if you agree.
I don’t think you need to be the best engineer in order to be a good engineering manager (EM). I wouldn’t recommend becoming an EM until you have been working as an engineer for at least five to seven years and are comfortably senior-level, but beyond that, I see little evidence that superior engineering skills translate into greater management aptitude or better engineering outcomes. I am actually a vocal proponent of offering management opportunities to middlingly-skilled engineers.
Management is not a promotion, it’s a lateral step to a parallel track
But management itself is less of a discrete skillset and more of a superset or an adjunct discipline. It’s a coaching relationship, a derivative role, one that leverages your existing knowledge of the discipline to help teams make decisions, resolve conflicts, and develop skills and processes. Therefore, managers need to have a solid grounding in engineering fundamentals before they can usefully help others grow as engineers. Managers may also need to go back to the well periodically and engage in engineering work to refresh their capabilities.
You can’t recruit a Starbucks manager to manage a software engineering team any more than you would recruit an NFL coach to coach your Olympic gymnastics team. If you want to coach a team, you gotta know the game.
Some of you are nodding along and thinking to yourself how obvious this all sounds. But this is actually a somewhat controversial stance. Every time this topic comes up, a sizable minority of those present begin strenuously disagreeing with the case I have just made, and always for the same reason: because they have worked for managers who were non-technical, and consider them the best managers they have ever had. Seriously.
‘I had a manager who knew nothing about technology, and they were the best manager I’ve ever had. They knew their limits, they never interfered, they always took my word for it and backed me up’; ‘The manager was always paired with a tech lead (TL) who they relied on for technical stuff, and they just supported us as people’; ‘Engineers mentored each other technically – we didn’t need the manager for that.’
This experience is surprisingly common, enough that it’s worth taking seriously. And I do.
Non-technical managers may be unicorns or a split-brain
Clearly, it is possible for non-technical managers to effectively manage engineering teams. I know it is possible – I have seen it done myself, once or twice. There are two scenarios where this can work.
In the first scenario, the manager is a truly unique individual, a unicorn of sorts, who compensates for their lack of technical ability with an almost uncanny empathic, intuitive sense for who to trust; when to trust them and for how far; and usually an extensive knowledge of the domain. They overcompensate for their lack of technical skills by being stunning in every other possible way. They usually climb the org chart fairly quickly, because the higher you go, the less relevant your hands-on engineering skills become compared to your strategic ability and your skill at motivating and influencing others.
These people exist, but they are rare. You cannot plan a hiring strategy that depends on you finding and hiring them, because they are exceptions to the norm.
In the second scenario, non-technical or less-technical managers are part of an intentional organizational strategy – usually due to some quirk of who the early employees were or the organizational philosophy of the founding team. Non-technical people managers are paired with highly technical tech leads, essentially splitting the brain of an EM in half. This strategy relies on those two staying in lockstep; it has rigid leadership dynamics that I’m not super fond of, but it does work. Note that it ‘works’ by designing the entire organization around compensating for this blind spot.
If the manager and the tech lead disagree, it’s bad news. The manager has limited ability to personally evaluate or review your work and they have to outsource their judgment to the tech lead. When faced with tough decisions, the manager cannot guide the team to explore the territory and arrive at a group consensus, so the tech lead generally makes all decisions.
It’s a rather fragile state of affairs, but when you roll the dice and get the right coworkers, it can work – especially for the tech lead. Tech leads in this configuration are extremely powerful; the manager basically defers to the TL whenever the TL thinks they should, which can be quite gratifying to a senior person. Most of the vocal proponents of this model are people who miss being that TL. They tend to talk longingly about how no one ever questioned their judgment or evaluated their performance and just left them alone to do engineering as they saw fit. And they say this like it’s a good thing.
A manager’s job is tuning sociotechnical feedback loops
These days we all work on, and from within, these incredibly complex sociotechnical systems and feedback loops that are so complex, there is rarely any problem that is purely ‘social’, ‘tools’, or ‘technology’. It is all entwined and interconnected. And if you are to have a hope of improving these systems and feedback loops, you need a full toolset. You need both social and managerial skills, and technical engineering skills. Furthermore, you need to learn to wield them together.
You need to be able to look at a team that isn’t shipping very fast and figure out whether it’s because of under-skilled engineers, legacy code, a weak product culture, a leaky CI/CD pipeline, or a team that has given up and lost confidence in itself. And then you need to start influencing people to do things that visibly and materially improve the system.
If you try to separate the social from the technical, and assign different domain owners to each, you are slicing up the ownership and responsibility lengthwise. You’re setting yourself up for squabbles about whose fault it really was, instead of making the lines of responsibility and accountability crystal clear.
Good engineering managers have both social and technical skills, and they take an interest in the personal development of their engineers (or support their very senior engineers). This is the ideal situation for a team: to have a technically-skilled manager who can weigh in but knows their boundaries, doesn’t hog all the decision-making for themselves, and lets engineers own engineering decisions.
It is not your job to make all the decisions now
But too many engineering managers mess this up by not letting engineers own engineering decisions. This is especially true if they are used to being the most senior engineer on the team and so they tend to clutch onto those decisions as a manager. This is deeply disempowering and frustrating for the people on their team. It creates the conditions for engineers to speak longingly about being neglected by their nontechnical managers. It is a self-inflicted wound. Don’t do it.
Much fuss gets made about managers needing to stop writing code and contributing. I think this is close, but not quite right. Managers need to stop writing code in the critical path. They cannot allow themselves to become a bottleneck, so they shouldn’t write key features or contribute to the really interesting parts. I think it’s actually a great thing for managers to keep their hands warm with bug fixes, low pri side projects, etc. Teams really appreciate it when their manager viscerally feels their frustration with them.
So go ahead, put yourself in the on-call rotation, keep your skills sharp, all this is good and worthy. Just remember that your primary job is to be interruptible and available, so as a manager, writing code is a luxury that comes last.
Some people eventually make peace with this, but many never do. No shame in that.
