Programmers and Micromanaging
Everybody hates managers who are fond of micro-managing. I suppose even the micro-managers realize this to some extent. So why do they keep doing it and not leave the rest of us alone? Well, one reason is that in the short run,
- Bad programmers exhibit better quality and productivity if they are micro-managed.
- While good programmers continue to produce acceptable levels of quality and productivity.
OK. So let us take this apart. In addition to their lack of skill, bad programmers suffer from distraction, sloth, and lack of knowledge. They operate below their potential (which is low in the first place). The manager spending more time with them can, at the very least, bring them to deliver what they are capable of. The oversight can be a motivator (through shame or fear) for them to be more careful about their work than is usual, resulting in better quality. This doesn’t mean that they achieve “high” quality or “high” productivity, it just means that the quality or output is “higher” than in the absence of oversight. There is a point beyond which more oversight doesn’t improve things, but the initial bar is so low that there is quite a lot of room for improvement.
To give an analogy, take students who have poor grades. Some of this is directly attributable to intelligence, but much has to do with environmental factors and lack of effort. You can improve the student through intensive training to get them closer to the average. Same for the bad programmer: with some intervention, you can move them from disasters to manageable situations. (I am operating under the assumption that you cannot or will not fire them. More later in the post.)
Micro-managing is generally tough for good programmers, because it takes the freedom out of their work and forces them into the thinking of the manager. But a programmer who understands and writes good code is not going to knowingly start writing bad code or introducing errors. There will be a fundamental level of quality that a good programmer will not regress beyond. What will be sacrificed are deep analysis and design/testing work that will harm the project in the long run. These are not problems that are evident to the micro-manager.
My point is that micro-managers, looking at the short-term results, think that their mode of working is effective because it has lifted the floor of quality and productivity, and perhaps even improved the mean and median. What is not visible is that the peaks of quality and productivity have been decimated. The good programmer, now with less time and motivation, is working full-time to satisfy the reporting needs of the manager. She doesn’t have the luxury to analyze a module very carefully or spend more time to research and write code that will be highly efficient or maintainable. She will still do what she can, but less than previously because of the new manager demands.
What is the solution? Micro-managers initiate such tactics when poor programmers cause problems with the project. They think their methods are effective when they see the gains in the input of those developers after their micro-managing techniques have been put into place. One way to blunt this thinking is to avoid hiring bad programmers and replace them soon if there was a mistake in hiring. This will get most of the team working at high output levels, this obviating the need to introduce more management measures. Or if they are introduced, such measures will demonstrate insignificant (or negative) levels of improvement.
Sometimes, it is not possible (for a variety of reasons) to fire a poor performer. In such instances, it can be useful to relegate micro-management measures to only the bad performers (such as how students who need extra training are handled). That way, their level of competence can be worked on while the rest of the team is untouched.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)