Skip to main content

Expand your knowledge

See our powerful product innovation solution in action.

Your Path to Work and Resource Management

Humility for Development Managers

Humility for Development Managers

In his book The Inmates are Running the Asylum, Alan Cooper asserts that developers such as myself were nerdy children who were bullied by less nerdy children (such as he, I assume), and therefore need to take revenge on our extroverted childhood torturers now that, as highly educated and overpaid technologists, we have the upper hand, because we can bully them into submission around points of software construction.

I’m not making this up.

As offensive as this idea is to the average developer, it has a grain of truth in it. No joke is funny if it isn’t partially true.

The relationship between Developers and Product Managers tends to suffer from this asymmetry. Developers can do things that most Product Managers cannot. The job of a Product Manager, to guide the software development towards a goal valuable to customers, is on the surface something that most Developers understand. Most Developers can speak, and some of them can speak to customers. Most Developers can vaguely understand that human beings use the product, and can and want to think of improvements.

Some Product Managers, on the other hand, may never have written a computer program, and may not even understand some of the terms used by the Developers.

It is therefore possible for Developers to indeed bully Product Management, and I believe it happens. For example, one can overhear developers saying, “We can’t do things that way because it isn’t a robust approach” or “We absolutely have to migrate to the latest system” or “We need to completely rewrite that system” or “We can’t consider that change because it would be too costly.” Who has the authority to question such a statement? Even a CEO can be powerless before such mysterious statements, because how can she judge their veracity? When a medical doctor tells you have to have your liver removed, you can at least get a second opinion. Where can a software executive turn for second opinion?

However, rather than ascribing this alleged intransigence to the worst possible motive, revenge, I prefer to adopt Napoleon’s maxim:

Never ascribe to malice that which is adequately explained by incompetence.

Developers are not guilty of aggression; they are guilty of poor judgment. In twenty-nine years of paid programming, I have never personally encountered an example of a developer intentionally lying to management for selfish reasons, and I have never met a developer who was not capable of self-deception. Developers are “human, human, all too human” in the words of Nietzsche. Our enthusiasm and prejudices and limited experience always cloud our judgment. The fact that we are well-intentioned may make it worse; everyone knows the best con-men are those who believe their own con. Self-deception leads to misrepresentation, misrepresentations lead to bad decisions, bad decisions lead to failed projects and, ultimately, failed companies. Therefore, clear and honest interaction between Developers and Product Managers is not a luxury, but rather a fundamental need of the modern company.

The best Developers and Development Managers are therefore humble. There are Four Humilities that are particularly important:

  • Humility of Purpose: Development must accept that Product Management has the final authority on WHAT the product does. HOW it does it is up to them.
  • Humility of Communication: Development must diligently labor to clarify trade-offs. It is never acceptable for a developer to say “Just because I say so”, or, equivalently, to shroud an answer in jargon that her audience doesn’t understand. That adjusting one’s language to the audience takes extra work is a responsibility that Developers must accept.
  • Humility of Status: Developers must strive to keep project status as clear as crystal. To fail is a shame, but to surprise management with a failure is shameful. Executives should demand to hear bad news as early as possible, and create an atmosphere in which bad news leads to rational decision making rather than fear. When projects go better than anticipated, the developer must make this clear, and not expend the saved time covertly.
  • Humility of Verification: Developers must verify their abilities and progress as realistically as possible. A developer may think he is the next Leonardo da Vinci, and more power to him — but a project’s success must not rest for long on a developer’s untested judgment. Before a project begins, no one has a right to tell me that I can’t accomplish some task in some amount of time. Once a project has begun, everyone has a right and responsibility to ask me to prove that I am making whatever progress I claim. Verification may mean testing the correctness of the program, testing the progress of the project, or even the fitness of the solution for the purpose in question.

I believe that executives should hold their Development Managers accountable for these Four Humilities. These will not ensure success but they will deter many common organizational failures.

Related Posts

Robert L. Read
Written By

Robert L. Read attended Rice University and the University of Texas, where he received a PhD in Computer Science. Rob was a Principle Engineer at and is now a Director of Product Development at Planview. He is the inventor of two patents and is the author of the essay How to be a Programmer. Having served on the board of Esperanto USA, he speaks Esperanto fluently. He is very slowly attempting to construct a device to allow human-powered thunniform swimming.