5 Easy steps to kill the deadly PDI in your software team
/PDI or power distance index is deadly for your software team.
Don’t know about it? You must read up all about it from our article about the power distance in software teams. Here is how I define power distance in the software teams:
How likely is a junior programmer to tell a senior about an error in the latter’s code?
Teams with large PDI will end up with those errors not discussed and resolved and thus with a buggy and at the end of the day a failed software. Thus it is of utmost importance that PDI be reduced in a software team.
The big question is: is it possible to reduce PDI? A valid question since PDI has been shown to be tied with cultures. But it has been shown that with the right effort and plans the cultural hard wiring can be overridden and PDI can be reduced and lives saved as it turns out: in the case of Korean Air in late 90s.
Korean Air had more plane crashes than almost any other airline in the world for a period at the end of the 1990s. This trend was finally pinned down to essentially power distance in the Korean culture which makes co-pilots very deferential towards the pilot and effectively cutting off the check and balance in the cockpit. Korean Air completely changed the trend by recognizing that PDI exists and taking steps to counter it. The success can easily be seen by the sudden reduction of the air disasters from the early 2000.
Although no study has been done in Bangladesh on PDI, but I can tell just by knowing our culture (and also looking at PDI scores of neighboring India) that the story is bad. So we’ve been very careful to take steps to reduce our PDI here at Kaz Software. Over the years we’ve tried lots of things but I can distill them all down to 5 steps that I know works likes magic. Here you go:
1. Make your team aware about the risks of power distance.
The great thing about software team members is that they are uber smart. If you can make them aware of the risks of power distance and how it affects their work product it immediately has an effect. This is something we do at every chance we get – starting from the day someone joins us and continuing at almost all the team meetings and brainstorming sessions. The awareness gives the team members to speak out when they worry if speaking out against a senior might be being rude. Which takes me to the 2nd step.
2. Train your team to be rude!
Well at least train them to speak out. Being nice and well behaved is the worst things that a developer can do to his team! Train them to have a strong voice of dissent, of being not nice when it comes to reviewing code or software design. A big tradition at Kaz is to “introduce” a newbie to the fine art of saying “you are dumb” in multiple ways!
3. Make self-deprecating humor common
This is slightly more difficult. But if you can plot this with the seniors in the team this becomes the easiest way to break the ice. A common joke at Kaz is that seniors can’t code that well because they are slowly losing their grey matter. It’s brought up at every chance we get when we worry about code – and soon enough the juniors in the team start to use it.
4. Do events that break down the barriers
These could be during the ubiquitous “team building” events or events specially designed to reduce PDI. The aim is to create a feeling that we all make mistakes – so the goal is different from the usual team building event’s goal – different enough to make special plans for them. The idea is simple, setup a situation (in a game, a show, etc.) where juniors have an edge over the seniors or where the seniors intentionally make a fool of themselves for fun. At Kaz the team leads dressing up as dodgy looking ring masters of a game are a good example.
5. Make team structures as flat as possible
This is the most important one. It’s the strongest message that you can send to the team about your intentions of keeping the PDI low. The whole gamut of hierarchy and respect just doesn't work in software and the sooner you kill it the better.
