Do we need clearer roles and responsibilities?

Why are people are still preaching that better, more clearly articulated roles and responsibilities will improve productivity? Provide a transparent environment where people have a clear understanding of what they’re working toward, and its value, and you’ll get better results.

As I write this, I’m sitting on a train travelling home. I’ve just been through the blog posts in my RSS feed. Three offer very similar advice about how to improve an individual’s productivity in the workplace. Their answer to this perennial conundrum is that we need to provide clearer objectives and roles and responsibilities on a daily basis. Given that the posts originate from people promoting Agile as a more enlightened way of working, I shake my head in wonder. Really, I do.

The value of roles

There are times when clear roles and responsibilities are essential – this post is not to suggest that their use be completely dropped. Consider the outcome of the incident now known as the Miracle On The Hudson; having just taken off from New York City’s LaGuardia Airport, a US Airways aeroplane, flight 1549, struck a flock of geese. Both engines failed. Some 3 minutes later, the Captain and his crew, a First Officer and 3 Flight Attendants, had performed an emergency landing on the Hudson River. In an air crash, speed, accuracy of trained response and calm are paramount. Although the First Officer had been flying at the time, the Captain took the controls, leaving the officer to go through a 3-page emergency procedure to restart the engines. The three flight attendants showed passengers how to brace themselves for impact and took control of evacuating the plane, even as it filled with water. The captain walked up and down the sinking aircraft to be sure no-one had been left behind and was the last person to leave. Each of the crew members was helped by their training and their knowledge of their specific, unique roles and responsibilities.

The difference for IT

The problem, is that few business teams – IT or otherwise – face the same kind of challenge as existed for the air crew. In IT, problems tends to require a creative response, one that cannot be considered in advance, which no training will prepare us for, but which must be invented anew each time. Strict roles and responsibilities don’t help with this. Indeed, they may hinder it because instead of thinking freely, people are prescribed. Control does not sit well with creativity, originality or motivation. Attempting to control an individual in a group setting reinforces a silo-based mentality to work. That means that the attempt to control an individual through a strictly defined role and associated responsibilities, affects the whole system. In my opinion it compels people to work within the boundaries that are set for them – intentionally or otherwise.

Do rigid role boundaries assist in speed?

In the air crash example, knowing who is responsible for each task helped speed. Proponents of clear roles and responsibilities suggest that decisions are made faster and are accepted with less confusion. Yet in my experience one of the negative results is a reduction in collaboration. The classic case of this, which I am sure we have all experienced, is somebody justifying their inaction with: “well, it’s not my responsibility”. I’ve known many cases where people fought NOT to take responsibility for an unpleasant job or fought over who TOOK responsibility for a prestigious job and the result was always that the product slowed or sometimes stalled as collaboration evaporated.

Individuals can always change the rules

So far I’ve focused on the work. But software development is ultimately a people-orientated endeavour. I was thinking about this as I sat with my son – a four-and-a-half year old, to do his numeracy homework. For some reason he was writing a lot of his numbers back to front. I kept on trying to correct him and at one point said to him “just write me five nines”. His response was to write the number 5 and 9. Perfectly, I might add. Some might say it showed intelligence. I’m inclined to say that he was being subversive. Either way, it was a proud Dad moment. But that’s one of the problems with the advice being offered: people don’t like being told what to do. They either do what they think is best at the time, or in a small amount of cases intentionally subvert the system.

Demotivating boundaries

When we’re children recognition from our dads and teachers motivates us, as we grow older the influence of our peers is what counts. I tend to perform best when I know I am there to make a defined contribution. To this end, a degree of definition of my role and responsibilities helps, but a rigid boundary is demotivating, because it constrains my ability to contribute as much as I could or would like to. This demotivation is exacerbated when people have to discover where their responsibilities lie. I’ve heard people refer to this as being knocked back – they’ve tried to do something which is perhaps of interest to them, or where they perceive there to be an opportunity, only to be told that their contribution wasn’t wanted.

Doing things differently

So what instead? As with all pernicious problems the first step is to observe what is happening. You might find people in a stand up talking about the piece of work they’re doing, rather than the work the team needs to do. Perhaps you see executives or departments becoming more rigid in role demarcation. A lack of vision or sense of purpose might pervade the organisation. Worst of all, perhaps no-one thinks making things better is any part of their ‘responsibility’. Cause and effect is difficult to establish in a software development scenario, but you should be able to state your observations and assumptions. Establish what effect an improvement might have. Test your assumptions with others – what’s their opinion? Don’t fall in to the trap that it is your role to change people. Remember, the way in which people behave is far more likely to be driven by the environment around them than anything else. Once there is agreement in the group about the perceived problem, consider what you might change to bring about improvements. Test whether these improvements have had the desired effect. Respond to the feedback you receive. Rinse and repeat.

I know that those advocating clarity of roles and responsibilities see the same problems in demotivation and wasted efforts as I do. The difference is that they believe more control is the answer, while I believe that less direct control frees people to create their own solutions. Those 5 crew members on US Airways flight 1549 worked as a team, each within their specialisms, and brought off “the most successful ditching in aviation history”[1]. Software development teams need to be more cross-functional in nature, but I believe that they too can perform their own miracles – as long as they have an environment that supports them rather than dividing them.

Thanks go to the inimitable Joshua James Arnold, Lady H of Edmonton (but of no fixed Twitter abode), and the sartorially precise Mark Krishan (50 shades of) Gray for helping me to improve this blog post.

[1] New York Post, 2009. Quiet Air Hero Is Captain America. [online] Available at: <http://www.nypost.com/p/news/regional/item_Goem4fAiUd2hsctASfAjGJ>. [Accessed 28 November 2012].