Non-Technical Development Managers Are Like Head-Chefs Who Can’t See, Taste, or Smell

I have made no secret of the fact that that I find non-technical managers useless in the delivery of software, but today while recording a podcast, I realize they have another fatal flaw: they can’t evaluate the performance of their team.

To a software developer, this may seem so obvious it’s not worth mentioning. Clearly, if you can’t read code, you can’t know if the code is good or not. To an executive, however, this realization is cause to get rid of all of your non-technical development managers.

It can be argued that the #1 responsibility of a manager is to evaluate the performance of their employees, as that his how promotion and termination decisions are made. If we were to remove this requirement of being a manager, they are nothing more than powerless babysitters serving only as a meaningless node in an org-chart. This is true of any manager – not just non-technical development managers.

If an executive worth their salt discovers that one of their managers is incapable of doing performance reviews on their employees due to a lack of competency, they will fire them. The speed with which this would happen is breathtaking, as it is one of the easiest decisions any executive ever has to make.

Historically, I have found it difficult to impossible to convince executives that a non-technical development manager is a clear and present danger to organizational effectiveness and efficiency. However, I now believe I have found an easy-to-understand analogy that helps illustrate my point a bit better. Admittedly, my past attempts were not that good, as I would default to talking about the relationship between code quality and business outcomes, which is highly theoretical and difficult to understand.

Consider a head-chef – with many chefs reporting to them – and consider that this head chef lacks the ability to see, taste or smell, and is therefore incapable of evaluating the food each chef is producing. There are two scenarios that will result:

  • The kitchen runs perfectly, because each chef holds themselves to high standards, and the chefs have self-organized into a collaborative collective. In this scenario, a head-chef is simply not necessary, regardless of if they can see, taste, or smell.
  • The kitchen runs sub-optimally, in which case no one but the customers would know, and if the customers complained about the food, the head-chef would be unable to find and fix the source of the problem – which will be the individual chefs responsible for the offending dish.

When a customer complains, the head chef who can’t see, taste, or smell will defend themselves by saying that no customer left hungry, as that is the extent to which they are capable of justifying their value. The fact that they are incapable of telling if the food is good, they argue, is of no consequence, as the customer doesn’t care if the food is good either – they only care that they get their caloric requirements met.

This argument of “my group of chefs is only accountable for making sure customers are not hungry,” is analogous to, “my group of developers is only accountable for delivering features on time.” Neither is true, but both share the same characteristic of being able to be proven easily by using simplistic metrics:

  • Are you still hungry?
  • Was the feature delivered on time?

“Yes” increments the count of things going well; “No” increments the count of things going badly. This is the limit of performance evaluation of head-chefs who can’t see, taste, or smell, and non-technical development managers, as they can’t read or comprehend code.

The prevailing industry argument is, “features delivered on time is the only thing that can be measured, so it’s the only thing that matters.” This mentality works well in manufacturing, where the sum of physical productivity can be used to calculate overall productivity, but utterly fails for industries dependent on cognitive productivity, as there are too many interacting variables for productivity to be measured simplistically.

If I sit a customer in front of a bad meal, they can tell. They may not be able to articulate precisely what is wrong with the meal, but they know they won’t be eating at that restaurant again. When the stakeholders of a software product view that product holistically – from user experience to ease of upgrades to cost of maintenance – they may not be able to precisely articulate what is wrong with the code, but they know they won’t be utilizing that software development team again.

Add your thoughts