If you’re writing an all time top five list of controversial engineering management topics, I can almost guarantee that the question of whether managers should be coding will find a place on the list. I’m very firmly in the camp of managers who do, and believe they should, code but it’s entirely understandable why so many people come down on the other side of the issue.
According to a recent study published by Harvard Business School, employees are happier when managed by someone who can do their job. To borrow from an old NASA engineer’s rules “Capabilities drive requirements, regardless of what the systems engineering textbooks say.”. When teams are building new software they’re operating in the margin between the possible and impossible, and that margin is entirely defined by the capabilities of the people and technology in play at the time. The further a manager gets from the underlying technology (or the further the architect gets from the people) their strategic thinking is weakened by the loss of of an intuitive sense of one half of the capability dynamic.
The backlash against managers who code is largely driven by the incredibly common phenomenon of new managers screwing up their promotion by burning out doing their old job instead of learning how to do their new job. Managers should keep coding but they must not keep doing their old job, and it’s easy to mix up those two things without the right framework to decide which code to write and how to write it.
Source: How (and why) Should Managers Code?, John Barton, https://medium.com/hackernoon/how-and-why-should-managers-code-323751799664