Assistant Orange Peelers

My father is a commercial airline pilot. He’s been flying since around the time I was born, 32 or so years now. He’s flown everything from light aircraft through 707’s, 767’s right up to the latest 747-400 - the ones with the winglets and beds for the 2 crews, enabling them to fly non-stop Sydney to London.

Pilots must undergo medical and practical examinations each year in order to maintain their rating on a specific aircraft and apart from actually flying, he has at various times been a training captain working out of Boeings Washington base. From there he teaches and re-trains pilots on simulators to either attain accrediation on an aircraft they haven’t flown before, or simply to renew their existing accreditation. Obviously he has lots of stories to tell but by far and away the most interesting group of pilots he’s ever had to train were Russian commercial airline pilots.

Back in the bad old cold-war days, defections to The West were common place and of great concern to Russian authorities, especially when it came to pilots. You can imagine that it wouldn’t take much for a commercial airliner to continue on to Japan or parts of Northern Europe. So, no doubt in an effort to counter this, and also possibly to give as many people as possible a job, Russian commercial airliners would sometimes have as many as 6 crew members in the cockpit with each one assigned and trained for a specific task. My father used to joke that they would have a Navigator; Radio Operator; Flight Engineer; Pilot; Co-Pilot; Orange Peeler; and an Assistant Orange Peeler. Re-training them on aircraft that require at most a 2-man crew was challenging to say the least.

This kind of “siloing” occurrs all too often in IT shops as well where each person has a specific task: The GUI Guy; Miss Middleware; Database Dude; Build Master; Application Deployer. Not such a bad thing at first glance I suppose - it’s always good to have someone in the team who knows about these things. For example, if you ever need to know something about how the Object-Relational-Mapping works, go see Billy Bob.

Another argument put forward is that by concentrating responsibility and accountability it removes the “burden” from the rest of the team. In practice though, this approach seems to lead inexorably to demarkation disputes further resulting in much finger-pointing and scape-goating. Cries of “Can you fix that, it’s in your code” or “Who’s been making changes to Blah.jsp without asking me?” can often be heard. What’s worse is how this can materially affect the productivity of the whole team - “She’s not in today so we’ll have to wait until tomorrow to make those changes” or “You’ll have to wait until the Build Master gets back from lunch before we can do another drop for you.”

It seems odd that a modern software developer cannot or is unwilling to become multi-skilled. The days of being solely a JSP guru or COM expert are gone and have been replaced with collective code ownership and the idea that moving people around is a good thing.

Or perhaps it is management worried about losing control? Perhaps a team who’s members have become self-reliant may decide that they can make it on their own and “defect”?