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
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.
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.