When was the last time you read your “roles and responsibilities” description?
My guess is, it was about the time you applied for your current position. Of course, if your HR department, or agile coaches, have decided to change your description you might have read the new document but even then, did you?
My guess is most people remember little more then the job title.
Like so many documents, it goes in one eye and out the other. And the longer it is, the more detail the less you are likely to remember.
So it won’t surprise you when I say: I don’t think roles and responsibilities documents have much use.
And it might not surprise you when I say roles are pretty pointless too.
To my mind your personal sense of identity, your own idea of who you are and what you do, plays a much bigger role in the actions you take in work and the responsibilities you accept – and those you ignore.
If, for example, your business card says “Business Analyst” it is not because someone defines your work as a “Business Analyst” it is because you see yourself as a business analysts and your sought out a business analyst role. You are a business analyst because you see yourself as a business analyst. You are not a programmer because you didn’t apply for a programmers job because you are not a programmer.
Let me suggest that what you actually do has little to do with what it says in some document, rather what you do is determined by your sense of identity, your identity may well be entwined with a job title. Identity is a powerful motivator.
If you consider yourself to be a programmer, a software engineer, software developer or whatever, then you probably shun business cards altogether but the same idea applies: you are a programmer not because you read a job description and say “I like the sound of that”. You are a programmer because you like doing the things you think a programmer does.
Of course this can cause problems because different people see things differently. Things fall between the gaps – your manager expects you to update the user manual and you see that as someone else job. Or things get difficult because two people try to do the same thing: the programmers try to design the software and so too do the architects.
Things get more complicated when people – us consultants! – start trying to change things. Maybe we say “programmers should test the code they write” but programmers say “testing is a Testers job.” Its even more difficult when you try and remove responsibility for someone: “programmers are no longer responsible for updating the system documentation.”
This is why I despair when people tell me problems can be fixed by updating the “RACI matrix” – don’t ask me what R A C I stands for, it seems to be a tool where responsibilities are listed against roles. RACI doesn’t change identity.
But you know what? – I like the way the world is. I do not want a world were people do what is on their job description and don’t do what is not.
People who are doing what they think needs doing, and who are doing it with the aim of producing a better outcome are motivated.
People who are doing something because it is in a job description, or because they’ve been told it is now their responsibility are not so motivated. Job description documents are pretty useless.
Whether you agree with me or think that people “should” do what is in some document: simply stop expecting them to do what it says. Instead look at what they do.
Go further, if something is missing ask “Who would like to do this?”. Work with people who are motivated by asking them what they want to do.
Few, very few, people are truly disruptive and working against you – unless of course your final outcome is something evil. Work with them.
Delete the roles and responsibilities documents.
Like this post? – Like to receive these posts by e-mail?
Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”
Check out my latest books – Continuous Digital and Project Myopia – and now Project Myopia audio edition
