A Development Manager who was a software developer as some point in their past, leading them to believe their technical opinion in still relevant with today’s technology.
- Can mutate into: “The Wants-to-be-Technical” Development Manager
- Dangerous when coupled with: “The Rockstar” Developer
- Likelihood of fixing: High
- Danger to project: High
Problem
Technology changes so rapidly, that over time former software developers will quickly find their skills obsolete. Development Managers are often former developers, in which case they fall into one of two distinct categories:
- Development managers who still code.
- Development manager who no longer code.
Development Managers who no longer code are The Formerly Technical, but often are in denial as to this fact. This denial leads them to believe that their opinions are still relevant in technical decision making, when in fact they can be completely out of touch with the current technology landscape.
The Formerly Technical Development Manager does the most damage when they choose to exercise their authority in the following areas:
- Deciding the system architecture.
- Choosing technologies for the team.
- Determining which technical skillsets to hire for.
Each of these areas have the same characteristic: The negative impact of their decisions take a long time to be noticed by non-technical decision makers. The negative impact on the software developers, however, can be instant, and can directly result in developers leaving out of frustration.
Solution
Top software development companies require that their development managers regularly write code, to ensure that they do not become The Formerly Technical. Unfortunately, many development managers became managers in order to escape coding (see “The Aspiring Manager” Developer), resulting in the typical definition of a development manager being that of someone who used to be technical.
There are three different solutions that will solve or mitigate The Formerly Technical Development Manager:
- Require that they code, measured by their actual contribution to the codebase (see “The Wants-to-be-Technical” Development Manager)
- Remove them from the technical decision making process by top-down edict, relegating them to a pure resource manager of questionable value (see “The Non-Technical” Development Manager)
- Have them bow-out of the technical decision making process by demonstrating their lack of technical knowledge.
If it was that simple… being one myself, I believe all this greatly depends on the size of the development team and nature of the product being developed. I question your assumption new technologies/programming languages require necessarily new skills that would make a former dev opinion obsolete but that’s not the most important. being a former dev means you can at least speak the same language and understand the design and architectures proposals from your team, which should include an architect. basically if you need manager that codes a lot, do you really need a manager? it’s perfectly fine for a functioning small team not to have one and adopt a more flat/agile organization. if you need one, and there are many cases where you do because development is not all about rocket science algorithms, then having one that at least understand what dev are saying is a plus. Managers are or should be decision makers like any other lead role, and a good decision maker does a synthesis or proposals and does not dictate his choices based on his ego…
So while tempting, your reductive description and categorization is only so relevant.
Actually you could argue that former dev that become managers and still can’t let go of coding pose many problems as well to the organization, being more gurus than leaders and potentially badly influencing decision way more than former technical ones.
anyhow, too much to say, interesting topic for sure and not one that can be summarized so quickly IMHO.
Agree, at least we start to discuss these aspects. Most of these are just a mental model that helped in discussion and could be mix with other characteristics or rise in the particular scenario. Size of the team, type of the company, industrial domain could be varied and thus it is never possible to cover it all. For example, a company only hiring senior dev is another catastrophe, but it is not saying they are all bad, there is a ratio. IMO, situation or timing is another demon in details. Anyway, I’m pretty enjoy these topic. Thanks a a lot!
“The Formerly Technical” is just one of several personality profiles that have a confusing name. Generally, having a development manager who used to be technical can be very desirable. In fact, it would be my preference that every development manager have a development background, whether they currently code or not. A clearer name might have been “The Technical Authority Abuser”, which implies that the development manager using their authority to force their opinions on the people that work for them even though their opinions are no longer relevant from an industry perspective. This, too, is the key aspect of “The Formerly Technical” – in order for them to be a problem, their opinions have to be invalid and/or irrelevant. If a formerly technical development manager has relevant, valid opinions, by definition they cannot be “The Formerly Technical” problem development manager archetype. Another name might have been “The Technical Knowledge Relevancy Delusional” but that might have been too long.
thanks for the additional clarification, I think we’ll all agree in the end with more and more nuance added, your articles are anyhow good starting points for interesting discussions!