Main image of article 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.