A Development Manager with no technical knowledge, and are therefore out of their depth when managing developers.
- Can mutate into: “The Extreme Underestimator” or “The Extreme Overestimator” Developer
- Dangerous when coupled with: “The Cheerleader” Project Manager
- Likelihood of fixing: None
- Danger to project: None
Discussion
Problem
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.
Solution
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.
Typoin: The do no harm to the project.
Fixed!
“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.
> military general who had never been a soldier
This isn’t the best analogy as most militaries have separate officer and enlisted tracks, and so it is true that nearly all military generals have never been an enlisted soldier.
To the main point, I agree that not everyone can manage software teams and having some sort of technical experience should be a requirement, but I don’t believe managers should still be coding once they start leading teams.
While the military does have separate officer and enlisted tracks, officer cadets initially receive the same training as enlisted recruits. In addition junior officers don’t just give orders to their subordinates but they also perform the same work as them. For instance a platoon is usually led by a lieutenant (junior officer). During a mission the lieutenant does fight along with his soldiers so he/she is not just a “manager” but also a doer.
Higher ranking officers usually don’t fight but in order to become a senior officer you must first be a junior one and the junior officers do fight. So the bottom line is that in order to become an officer you must be able to do the work of the enlisted men. For example if you can’t fight as an infantry solider you would never be put in charge of an infantry platoon.
I am been a software developer for over 10 years I started at middle school programming in visual basic , javascript, REACT,C# and even swift . and I truly agreed of what is been said.
I had non-technical project managers, software managers and even code review done by a non-technical person .It is just so ironic that I get asked questions as what is an IF statement by a manager . That is a wasted of my time . because our job is so hard by itself just to add more effort trying to explain something to a non-technical person that chances are dont understand.
I also , have worked with technical managers that I look up to , asked for advice a better ways to do things. and it feels amazing.
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.
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.
As there were a series of thoughtful, valid objections to my characterization of Non-Technical development managers, I added a 1 hour 16 minute podcast in the “Discussion” section that hopefully explains why I hold the views that I do more thoroughly than a brief write-up can. The challenge with text is that there is a lot of pressure to be concise, but with audio it easier to dig deep into a topic and explore nuances, and the value of a Non-Technical development manager to delivering software is a highly nuanced topic. My goal in the podcast is not necessarily to persuade anyone that I am right (what is “right”, after all?), but instead to provided the full background on why I maintain my position in the face of valid objections.
Hey Neil, nice article.
As a developer for over 10 years, here are my two cents:
I’ve worked for both ex-developer managers and non-developer managers and I prefer the former.
While a non technical manager can work, it can only work if they are a truly humble person. There is NOTHING worse than the arrogant, buzz-word spewing pseudo-technical manager that thinks they know it all, yet can do NONE of the work. They don’t know what you really need, they can’t tell who is actually good at what they do and they can’t really appreciate any of the hurdles that are faced.
I’ve had a good non-developer manager in the past, but they are exceedingly rare and seem to work only if the person truly has humility and knows their place.
For those disagreeing with you: IN WHAT UNIVERSE is someone who can do none of the work/has limited knowledge of said field, and is essentially pretending, beneficial when overseeing a team?
The answer is, almost never. This only flies for a field such as computing because it’s easy to masquerade. It’s easy to abuse acronyms and ignorantly give orders. None of that is hard. Writing code and fixing problems is hard.
You will never gain respect this way. Using your military analogy, the sergeant will never have the respect of his squad when he is the weakest marksman, the most cowardly and the worst soldier.
“Go storm that bunker you guys, I’m gonna hang out here and drink some coffee. Oh, and get it done by end of the day, thanks”
Non technical managers usually do not appreciate the skill/talent/intelligence required to solve technical problems. “It’s easy, just knock it out”. Then you get dinged in performance review for not just “knocking it out”.
I’m a senior developer and I simply don’t work with non-technical managers anymore. If, during an interview, I notice my future direct manager is non-technical I run for the hills.
Non-technical managers generally have no clue what they are asking for. They will throw you under the bus when something goes wrong and take sole credit when something goes right. They will make promises on your behalf to their bosses that are impossible to keep without 80 hour weeks.
Stay away from these types of managers.
Great article. I 100% agree with you
In my opinion software development managers, either technical or not, have very little to absolutely no impact on the work the developers are performing.
Developers work either on a project or on a product and the non-technical aspects related to their work is managed by project managers, program managers and product managers. So from this point of view there is no need for a software development manager at all when you have the Managers already managing these aspects.
At the technical level developers are managed by more senior developers who serve as technical leads/technical architects/software architects. The Software Development Manager could manage developers at the technical level only if he is also a developer.
In my opinion software development managers should be removed completely as they are useless. More junior developers should have as direct managers more senior developers, while the highest level developers should report directly to a Director who may or many not be technical.
The managerial duties of the senior developers should be limited to purely technical things as such hiring, training, mentoring, providing technical leadership and assessing the performance of more junior developers. The Managers should take care of the rest of the management aspects of software development including the politics involved.
I had a non-technical manager ask “Why do you need Git?” in regards to tooling. Developers were already on Git for some time already and we wanted to create a new repository for qa automation code. She did not last very long at the company (less than 3 months).