Decided to take a detour today in my blogging thoughts (it is Friday, after all), and opted to revisit the issues of managing a technical team (MaTT); today’s topic: Entropy.
en·tro·py
/ˈentrəpē/
Noun
- A thermodynamic quantity representing the unavailability of a system’s thermal energy for conversion into mechanical work, often…
- Lack of order or predictability; gradual decline into disorder.
Simply put, processes decay over time. A good manager will recognize this, and learn to intervene when those processes begin to break down. In contrast, code lives on forever (unless someone steps in to change it).
Let me give an example; about a year and a half ago, I implemented Kanban as a method of managing our workflow in the production environment. My team quickly adapted to it, and it became very easy to see exactly what people were working on, and what was getting accomplished. I thought “my job here is done”, and moved on to other things, occasionally touching base with the Kanban board to see what was going on.
This week, I realized that the process had degenerated; sure, my team was still using the board to report what they had done for the day. However, they’ve gotten in the habit of solving the problem, and then creating the card in the Done pile. Entropy. I am no longer able to predict or measure what is being done or what needs to be done.
I’m out next week (hoping my son is born by the end of the week), but when I return, I need to intervene and work toward cleaning up the process. While I firmly believe that I should trust my team and encourage them to make the right decision, part of the management process is learning when to intervene in order to shore up a process that is decaying.
You make a good point. Changing behaviour is so hard to do when people feel like “it’s always been this way”, even if that is not true.