Taming 50 Shades of Micromanagement

I recently opened up a pull request from a team member and started to do a code review. It was a relatively simple change, adding a logo to a page and styling it. Nevertheless, I cringed. It was just not right. I started to comment on lines of code, then stopped myself.

Back up a second. Was it really wrong?

One of the hardest things to learn as a technical leader is that there are different degrees of wrong. All of the following are likely to feel “wrong:”

  • Something that simply doesn’t work.
  • Something that works but doesn’t match the current coding style.
  • Something that works and matches the coding style but isn’t the way you would have done it.

All of these will feel wrong and will induce some level of cringing. That doesn’t mean they should all be changed, though. Micromanagement is micromanagement, and technical micromanagement is just as bad as human micromanagement. If we don’t want to be micromanagers of the code, we have to learn to draw distinctions between different kinds and degrees of wrong.

Let’s look at that list again, and what we should do about it:

  • If something doesn’t work, it clearly has to be changed. That one’s easy and relatively unambiguous.
  • If something works and doesn’t match your company coding style, that constitutes grounds for a discussion. It’s likely that it should be changed, but if the person violated your company coding style for a good reason, maybe it’s the coding standards that should be updated. After all, coding standards need to be maintained, and sometimes that will mean changing them.
  • If something works, matches the company coding style, and isn’t the way you would do it, then you as a technical leader need to back off. If the only thing “wrong” is “I would have done it differently,” then it’s still a perfectly acceptable solution. Asking to change it to your style will only produce resentment and legitimate complaints of micromanagement.

Code reviews are great for technical management. They provide lightweight oversight and regular, structured opportunities to improve the technical skills of every member of the team. Just be sure your technical management doesn’t turn into micromanagement.

2 Responses to “Taming 50 Shades of Micromanagement”

  1. While I accept the categorization, I think you missed a few points.

    1) For non-stylized code, under time constraints, as nice as it would be to update, you often can’t afford to change the style and meet your deadline….skip the changes, but maybe add it to your TO-DO list.

    2) If code is “correct” but not the way you would do it, if it causes confusion as to how it’s done, it justifies having a discussion. If the person who wrote it is gone, it could justify re-writing it to get it back synchronized with the way people who remain think about how to solve a problem and if the way it’s written confuses everyone, then I wold recommend updating it.

    3) Sometimes things change in the industry and, I supposed, this could go back to your stylization point and reviewing updated styles or even new coding features that can reduce chances of other errors in complex bits of code (of course, while potentially introducing new errors when updating the code.)

  2. Dave Anglea

    Just RANDOMLY came across this and it hit home because today I was put in the position of being forced to let go of a development project to a person we fought to hire – and I am to be the technical lead.
    I have got to come to grips with issues such as this fast.
    Hope I adapt.

    Dave Anglea