The following are difficult archetypes found among development managers:
In a large organizations, developers have to report to someone, and the people they report to then become Development Managers by definition. There are no specific requirements for being a development manager, but it is generally preferred for them to have written software at some point in their career.
These managers can be divided along two lines: those required to contribute software just as a developer would, and those who are not. If they do still write software, they can sometimes go by the name of Technical Lead or Architect. The job description of a non-coding development manager is to care for the developer’s needs. This includes activities such as approving timesheets, approving sick days, dealing with conflicts, and acting as a go-between with the Human Resources organization on issues such as compensation increases or demands for promotions.
Developers have strong personalities, and require an experienced hand to manage. They often can find a job at another company at the drop of a hat, can be temperamental, or even have a temper. If the development manager is still technical enough to write software with the developers, there is a chance they might be able to manage them effectively. If they no longer code – or worst yet have never coded – it is only a question as to what degree they will fail at effectively managing developers.
“If they no longer code – or worst yet have never coded – it is only a question as to what degree they will fail at effectively managing developers.”
I don’t agree with your assertion at all. I’ve seen very effective results from DM’s lacking direct coding experience, or at the very least possessing good theoretical knowledge of the subject matter domain.
So, as you have experienced/witnessed multiple failed attempts at effective management from DM’s that are not, or no longer technical “enough”, that is probably because they neglected the most important developer need – technical leadership!
Relevant technical leadership and support, guidance, goal setting and technical development / training doesn’t have to come directly from the DM in all cases. As long as there is an interface to a senior developer, or tech lead equivalent to help facilitate in those areas, then great things can happen.
Also, a DM holds multiple responsibilities and accountabilities, such as soft skill management, team formation, objective setting and motivation. Therefore, I found your description of the DM’s role in relation to their developers needs (timesheets, sickness, holiday and HR middle-man) very simplistic, and almost insulting.
Disagreement is not only allowed but encouraged – at least on my blog, which is the only tiny slice of the internet I control. I thank you for your comment.
All of my archetypes come with the caveat of “In my experience” (it would help if I wrote an intro at some point), and it’s impossible that my assertions are universally true – there are exceptions to every rule, especially when that rule is literally one person’s opinion.
Certainly it is not so simple as “if you’ve never coded you will fail as a manager of developers”, but in my experience if you lack the respect of the developers it is nearly impossible to lead them, and it is very difficult to earn the respect of the developers unless you have been in their shoes. There is a lot of leeway in the statement of “degree to which they fail” – a manager who never coded will not be able to coach developers on coding, which to me is a form of failure as that is a service developers can and should demand from their manager (especially junior developers). That is not to say they will be an abject failure, but certainly sub-optimal in my estimation.
I am working on a podcast series that complements the archetypes, the first of which is in the “Discussion” section on “The Incompetent”. I am not happy with the overly simplistic way I have to treat complex issues in the pursuit of defining concise, assertive archetypes, and the podcasts are my way of giving issues like you’ve brought up the thought and attention they deserve.
Thanks for your response. To be clear, I certainly don’t want to take away from all the great work you’ve done here at all. As you state, there is always a different angle and perspective to consider, and speaking from my relevant work experience, I have seen more than one non-technical DM succeed. Good luck with everything!
As a developer, I find inevitably issues arise with managers who don’t code (or no longer code) and yet assume their technical opinions about the architecture and solutions are equally or more important than the developers who actually do the work. These managers are sometimes put in charge of code review as well, despite never coding in that language or system. I have one right now that likes to “architect solutions”, but must send them to me anyways since he has no idea if his solution is feasible.