Team Members, Be Predictable!

In my earlier blog post I Follow My Rules, You Follow Yours I wrote that team members don't necessarily have to follow the same rules and practices. And in Why Should I Follow Your Rules? I wrote about the subsidiarity principle, which says that rules and practices should be established at the lowest possible level in a hierarchy. But in those earlier posts I have left one question unanswered…

Why do we follow rules and practices?

Why do I always keep to the right side of the road when another car is coming up from behind? Why do I place the forks on the left side of my guests' dinner plates, and the knives on the right? Why do I always check in my source code at the end of the day? Why do I give those who arrive in a meeting much too late the evil eye?

Following rules and practices is about preventing problems and decreasing risks. And at the same time it is about increasing predictability. I want my position on the road to be predictable for others, so that they don't run into me. I want the placement of forks and knives to be predictable for my guests, to prevent embarrassment. I want the availability of my source code to be predictable for my team members. And I want the starting times of my meetings to be predictable for those who attend. Not being able to predict how other people behave, leads to collisions, communication problems, wasted time, increased risk, etc, etc…

Yesterday I was driving from Rotterdam to Brussels. I was in the second lane of the highway, and ready to overtake a car that was in the first lane. But suddenly the other car switched lanes and I found it right in front of me, for no apparent reason whatsoever, as there were no other cars in the vicinity. I hit my brakes, invented and uttered some new curses, and signaled with my head lights until the suicidal maniac moved back to the first lane. (A quick angry glance sideways confirmed my suspicions of the type of driver in the other car, but let's not venture in that direction.)

People follow rules in order to be predictable

You must be able to predict how the work of your colleagues interfaces with your own, or you will have a hard time working together. When I expect and assume that someone is going to give me requirements in the form of user stories, and she gives me use cases instead, I would be extremely annoyed. Not because user stories are better than use cases (or vice versa), but because I suddenly have to hit my mental breaks, and switch my internal processes to another type of input. Sure, it is always wise to stay alert. But having to act to prevent a problem, only because someone else didn't stick to a rule, is a needless waste of time and energy.

As I said in my previous posts, this doesn't mean that people have to follow the same rules and practices. I am perfectly content to accept user stories from Sue and use cases from Charlie. As long as Sue and Charlie both stick to their own practices in a predictable way, then I have no problem switching processes and contexts to face whichever person I'm working with. This is because we humans are actually very good at changing our own behavior, to match the people we're dealing with.

Having to switch lanes is no big deal. But having to hit the breaks is!

On the road I can deal with some people sticking to the first lane, and some other people sticking to the second lane. As long as their behavior is predictable, I can safely pass on either side. It only gets dangerous when, at 140km/h, they suddenly decide to plant their fat ass right in my face.

So please… Follow (some) rules. Be predictable. And drive safely.

Follow me on Twitter – Subscribe with a reader – Subscribe by email!

Latest, greatest and favoritest posts:
4 Top Posts on Discipline in Software Development
Why Should I Follow Your Rules? (The Subsidiarity Principle)
I Follow My Rules, You Follow Yours