Metadata
- Author: Charity Majors
- Full Title:: Should engineering managers be technical?
- Category:: 🗞️Articles
- Document Tags:: An Em Needs To Be Technical
- URL:: https://leaddev.com/personal-development/should-engineering-managers-be-technical
- Finished date:: 2023-04-08
Highlights
And since we’re always telling managers not to write code or do technical work – since what managers actually do all day is go to meetings, write emails, and other managerial things – shouldn’t it be management skills that are non-negotiable rather than engineering skills?’ (View Highlight)
inglorious history of treating technical skills as innately superior to other skillsets (and engineers as superior to other professions). (View Highlight)
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? (View Highlight)
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. (View Highlight)
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’ (View Highlight)
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 (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
Just remember that your primary job is to be interruptible and available, so as a manager, writing code is a luxury that comes last (View Highlight)