The Formerly Technical

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.


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:

  1. Require that they code, measured by their actual contribution to the codebase (see “The Wants-to-be-Technical” Development Manager)
  2. 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)
  3. Have them bow-out of the technical decision making process by demonstrating their lack of technical knowledge.

2 thoughts on “The Formerly Technical

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

Leave a Reply