Krishna Kumar is a software development manager from New Hampshire. He writes on topics related to software development, programming, project management, and business management. Krishna is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Programmers and Micromanaging

01.18.2011
| 4268 views |
  • submit to reddit

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.

 

From http://www.thoughtclusters.com/2011/01/programmers-and-micromanaging/

Published at DZone with permission of Krishna Kumar, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Josh Marotti replied on Tue, 2011/01/18 - 12:17pm

As a manager (not a micromanager) there is something to be said of the types of employees.  There are really 4 types of technical employees, and it revolves around two traits: Knowledge and Drive.  It also usually follows a path.

Low Knowledge, High Drive (LKHD):  A student fresh out of school.  He can program, but has no experience (low knowledge), but is excited to get into the business, so he's always looking for the next project to jump into.

Low Knowledge, Low Drive (LKLD): "Spinning his wheels" on problems enough, and his drive disappears as he comes to the self realization of his lack of knowlege.

High Knowledge, Low Drive (HKLD): After time, experience developes, but he is still not confident in his skills, so he doesn't like to take on the heavy projects.

High Knowledge, High Drive (HKHD): Once he gains confidence, he's a force to be reckoned with.  Can handle anything that comes his way.

 

There is a different management style for each.  Micromanagement is usually needed in the first two. 

For LKHD, you need to hand-hold and make sure he doesn't put too much on his plate.  He needs to be slowly adapting to the business so when he gets to the next stage, he doesn't sink too low.

For LKLD, you need to really be a good manager.  It's a combo of hand-holding, but allowing him to learn on his own (so he doesn't become dependent in his knowledge).  There is also a big 'cheerleader' role needed to keep him going.

For HKLD, what is needed is a cheerleader.  You need to encourage and keep them going.  Sometimes that me 'placing' them on harder projects so they can succeed in them.  Sometimes it means being a shield for them when they fail.

For HKHD, what you need is to get out of the way and knock out any road blocks in his way.  To have a team of these guys gives you a lot of free time ;)

 

Honestly, once you are in the business for 5-10 years, it's usually just a rotation of HKLD, HKHD.  Our personal lives flucutate, projects can cause highs and lows, but once you have a team with knowledge, micomanaging should be removed from them, unless they have such low drive that they don't want to do their job.  Even then, micromanaging is unneeded, just transparency of work (daily scrums are a great way to find this out).  But micromanaging is a necessary evil for younger or newer developers, just to get them into the business and up to speed with the rest of the team.

Andy Leung replied on Tue, 2011/01/18 - 6:16pm

Josh, I know you are saying, usually but if you were my manager when I belonged to LKHD, you wouldn't get anything but my resign letter. The reason is, it depends on the enthusiasm of a developer. I was enthusiastic enough to even complete everything on hand and worked ahead of projects where my IT manager didn't realize the existence and benefits it brings until UAT. But again, as you say usually, there are always exceptions :)

Milan Agatonovic replied on Wed, 2011/01/19 - 3:16am

Nice article, but...

why would you keep LKLD person in team at the first place?

Milan

Josh Marotti replied on Wed, 2011/01/19 - 11:37am in response to: Milan Agatonovic

Read how it comes to being.  These stages could be years long, or weeks long.  The person may have the domain knowledge, but lack the coding skills... they are good learners and just need coached.  I'm not the type to just drop someone I've invested in if I know they are capable of being great.

Josh Marotti replied on Wed, 2011/01/19 - 11:39am in response to: Andy Leung

Well, there are good managers, bad managers... but there is also good management teams and bad management teams.  Bad managers 'think' they know tech, but the last time they coded, it was in COBOL.  They make promises and know what is best for developers.  There isn't any good way to deal with these people unless you can educate them.  So even with my discussion, there are bad situations you are best to simply avoid.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.