The Non-Technical

A Development Manager with no technical knowledge, and are therefore out of their depth when managing developers.



It may seem counter-intuitive that someone who has never developed software can have software developers reporting to them, but there are certain situations where this can happen:

  • When the decision is made for all project team members to report to a single manager.
  • When a development manager leaves the company, but there is no technical manager available to replace them, the developers must be made to report to someone.
  • When the organization does not see itself as a technical organization (as you might in a marketing firm), and therefore does not see the purpose or need for developers to report to a technical manager.

In order to effectively manage software developers, you have to earn their respect or run the risk of them not taking direction. A sure way to never gain their respect it is to have no appreciation for the difficulty of the work that they do. Where this appreciation is most critical is when developers must provide and defend their estimates.

Development managers often act as a check-and-balance to developers who are poor estimators. Project managers will often look to the development manager for approval when they feel an estimate does not seem appropriate for the work to be done, but only a technical manager can confirm the accuracy of an estimate. Conversely, if a developer’s estimate is undesirable to a Project Manager, only a technical manager can effectively defend the developer’s estimates.

Ultimately, The Non-Technical development manager is useless to the project. They do serve a benefit to the company in providing a human resources reporting structure for the sake of tracking work attendance, enforcing company policy, approving time sheets and vacation requests, but have no negative or positive effect on the project itself.


It is common for Developers and Project Managers to complain about non-technical managers when estimations come under dispute, but in reality they are just looking for an arbiter, and believe it is The Non-Technical Development Manager’s job to be that arbiter. As The Non-Technical Manager has no tangible impact to the project other than their inability to meet this expectation, the expectation simply has to be reset: The Non-Technical Development Manager simple cannot act as an arbiter in matters of technical dispute.

With expectations reset, we are then left to examine the two key characteristics of the Non-Technical development manager:

  • They are of no use to the project.
  • They do not harm the project.

Which results in the solution being to simply ignore their existence, regarding them only as a necessary part of an organization’s middle management.

7 thoughts on “The Non-Technical

  1. “Ultimately, The Non-Technical development manager is useless to the project. They do serve a benefit to the company in providing a human resources reporting structure for the sake of tracking work attendance, enforcing company policy, approving time sheets and vacation requests, but have no negative or positive effect on the project itself.”

    Again, I would ask you consider your wording in sweeping statements such as these. A committed DM, that cares for his developers and their interests, adds no value at all to a project if they are not technical themselves? I’m not talking about timesheets, or tracking holiday, or the operational necessities of a management role here. That is clearly rubbish.

    I understand this is your opinion, however it really does devalue the good, and necessary, work that non-technical Development Managers can and do undertake within software development teams. Especially those that work within a framework to ensure they estimate correctly, and offer technical support and leadership through other avenues within the team or wider company configuration.

    • While I do understand your concern, please understand that I hold this opinion for good reason. It bears mentioning – in case you have this concern – that I do not chose words idly, and do not attempt to “shock” people. That is not my nature. My nature is to make sure that people fully understand where I stand on an issue, but I do not expect (or even advise) that they agree with me. Indeed, disagreement is the cornerstone of intellectualism, and we have far too little intellectual debate in the world today.

      From my perspective, it is nonsensical to have a head-chef who doesn’t know how to cook, or a military general who had never been a soldier, or a lead surgeon who doesn’t know how to perform surgery. There are times in life when to hold a position, you must have requisite experience to justify being in that role. In the software industry, this basic truism has been lost, and has been replaced by a concept that “anyone can manage software developers.” This is patently false, and is symptomatic of non-technical development managers not knowing enough to know what they don’t know. Ultimately, if our job is to develop software, and your role is ostensibly to lead the software developers, you are of no value and very well can (and often are) be a hindrance if you do not have the requisite experience to lead your team.

      While this may be a bitter pill to swallow, and I do accept that I will not win your favor in holding this position, I cannot in good conscience say something I do not believe. I have been managed by non-technical managers, and by technical managers, and the difference is stark. I have many colleagues who have had the same experience. You simply cannot support a developer unless you know what it’s like to be a developer, and supporting developers is the most vital function of a development manager.

      I would give you this challenge, should you still feel strongly that my wording should be changed: Ask developers you know to post here about their relative experiences in being managed by non-technical and technical managers (the will have to have experience with both) and I will consider their experiences. It may very well be that my experiences and the experiences of my colleagues represent an anomaly, and I would like to think of myself as someone who has strong opinions that are loosely held in the face of contradictory evidence.

      • I disagree with this. Very little of what is necessary to be a good development manager involves understanding the technical aspects of the job your people are doing. You simply have to have trust in the people underneath you. This belief is why so many software companies have horrible management issues. Coding has nothing to do with managing a group of people effectively, and past experience can lead to problems. If a manager is an amazing manager and also has the ability to read and write code, they will probably be a better manager. On the other hand, people that are poor managers, but have a technical background can actually become even worse. I have worked for people that were technical that found it necessary to question estimates of developers on a regular basis because they believed that they had insight into the reasons behind the estimate due to their history. Effective management is all about making sure that your people can do their job, and not making sure that your people do their job. I don’t need to be a brain surgeon to understand that it is incredibly difficult, and if I trust my team I can ask them what they need to succeed in this difficult task.

        I’ve worked with both, and I’ll take an effective manager over a great developer promoted to the role.
        On a side note, why would project management have any say whatsoever in an estimate. If people are sandbagging it doesn’t take very long to figure this out, and once it is realized that the sandbagger has violated the trust of the team, they should be fired. Trust your development team to do the right thing. If you don’t trust them, get rid of them.

  2. Broadly speaking, you are totally right. Of course it is ideal for a DM to have walked the walk.

    My core point is this is not always necessary for a DM to succeed, if they find ways to support their people in areas where they cannot.

    It also depends how well a dev can communicate the technical nature of his work to these kinds of managers too…

    To repeat, I am simply pointing out your assertions these types of managers are ALWAYS useless to a project, or of no value to developers, are false.

    I care because it would be really unfair if developers reading this website completing rule out non-technical managers in the way you have. It can, and does work well in certain configurations.

  3. I’ve experienced both sides of the coin so to speak. One non-technical manager was good enough on a technical point to understand what we did and did a lot of legwork shielding us from company politics and other itema outside of our group. She also trusted us and as long as our estimates were realistic and supported she was good with them.

    The other one was completely useless and completely failed to earn rapport, trust nor respect with the team. We were pretty much on our own.

    Given a choice I would strongly choose someone who’s walked the walk so to speak but there are other considerations that would definitely be higher on my list all things considered equal.

Leave a Reply