Glass with water

I found a new (at least for me) metaphor: people are like water. The cool thing about this metaphor is: When you manage people you can use it to learn from the engineers building channels and dams. So here are the things you can learn:

If you want to stop a certain behavior, build a dam not a wall. A wall, i.e. a single action won’t change the behavior very much. A hundred years ago dams where basically thick walls. In case of a flood, waves would crash against the wall and destroy it fairly fast. Nowadays dams have long slopes. Waves run up these slopes, loosing all their energy, without doing damage to the dam.

How does that relate to people? Ever tried to convince the employees of a company to do anything by writing a single e-mail to all@yourcompany.com? Had any success? Probably not. If you wan’t to change behavior, you have to work on that change everywhere and all the time. With small but constant force. You need trainings, presentations, reviews, e-mails and the communication at the water cooler, until it slowly sinks in that the change is not just the weird idea of a single person, but the new company policy.

If you build a channel water will run fast. Make sure this is really what you want. Rivers with a bed make a river easy to handle and predictable under normal conditions. But they are also considered cause of many floods, because the water of the river can’t escape the channel and rushes forward until it finds a weak spot.

Many process systems look very much like such a channel. They are build for everyday work, to make it as smooth and fast as possible. But what happens with your processes, when the environment changes? When you suddenly face twice as many customers? Or only half of the normal load? Or if a real big customer comes with very special wishes? Do all employees, when to look left and right of their daily routine, in order to find creative solutions to new problems? Do they understand why the processes are the way they are? They will need it in order to change their behavior without breaking the system.

If you keep water from going one way, it will find another way. I see this ignored very often when it comes to prioritizing tasks. Some people seem to have the illusion that the simple fact of attaching a high priority to a task will make it happen fast. This results in task lists, where almost everything is high priority. Obviously this means some things are set on a high priority that really don’t belong there. So, what would water do? Imagine a flooded area, where you want to protect certain buildings with dams. Of course you could build a high dam around every single building. This will cost a lot of money and effort. And it will also reduce the space where the water can go, thus the water will rise higher, eventually flooding all the high dams. If you instead build only high dams around the really, really important stuff, medium dams around the important stuff and small dams around the not so important stuff, stuff will get wet, but the really important stuff will stay dray for much longer.

A small rupture in a dam will get bigger … fast. This is really the old broken window thing. If things change in a way you don’t like, make this clear immediately. Otherwise after a short time, the new way will be the accepted way.

All the analogy considered the water (people) as an enemy, which is really a stupid thing to do. Water is tremendously important, so are people. If your let run water as it wish, it builds beautiful rivers, finding its way to the sea without any help. And if you really want to change its path without constant watching, monitoring and dam building, make the new path the easy one. Want your developers to properly use a version control system? Make sure it fits their needs. This means: It must be easy to obtain a repository for a new project. It must integrate with the IDE. It must be cool, at least to an extent that other people at a conference don’t laugh at you or worse pitty you when you mention it.  Do you want every issue to be tracked in a issue tracking system? Make it easier to use for them then the alternative (Excel, Notepad …). Sure all the 100 little details, that some systems can track might be interesting for management, but they won’t help you if the user only add issues when they absolutely have to.

• Employees get extra pay for work on billable projects. Undesired result: If an employee is finished with her work she benefits from claiming to still work on the project instead of announcing availability for new tasks.
• Employees get extra pay for the ratio of positive feedback from customers. Undesired result: Negative feedback gets hidden, but the negative feedback is the one you really need to know about.
• Employees get extra pay for the success of their department. Undesired result: Fights between department about who is ‘owner’ of a project; Information hiding between departments.

So should we scrap all key figures? No, I think they are actually quite useful, as long as you never try to tie any kind of automatic action on a key figure that goes beyond some kind alarm, triggering somebody to look into the situation. It also makes the selection of key figures much easier. You don’t have to find a key figure which is fail proof (which you won’t find anyway). Another example: Key figures for Software Development. The aim is to get an indicator when something in the software construction phase is going astray. I propose the following key figures:

• Lines Of Code per man month
• Code Coverage in any of its flavors
• Toxicity

Of course it is a bad idea to base any kind of payment on the lines of code produced. Employees would use cut and paste instead of avoiding duplicate code. The inverse is equally bad. People would probably stop working at all. Yet if you find that one team produces half the lines of code than all the others it is worth a second. Maybe they creating extremely crisp code or they are just lazy, or encounter serious problems. Almost the same applies when code coverage or toxicity deviates from the usual values. If all three numbers evolve as you are used to from other projects, development probably evolves as you are used to. And if something unusual happens it will probably show in the numbers pretty soon.