persona

So you hate job descriptions, how about personas?

I was torn. One of the biggest debate I had encountered when presenting in agile tours was the concept of job descriptions and competences. In an auto-organised world of agile, why do we need job descriptions? Isn’t that too limiting and will be outdated? While I agree that HR tools are traditional and lack innovation, I stand by the need for a point of reference. But I had left the conferences with a heavy heart.

How can we not do something for the sake of doing it? And how can we look past it’s ugly form today to see it and use it for what it is?

Let’s take a step back. A job description has 2 main functions, 1) for recruiting 2) for a summary of the job. If we take away job description, then we had to assume that a job title says what it does. So when we recruit a scrum master, we would assume that all scrum masters are the same and does the same thing. Hardly. Otherwise, all scrum masters would be cookie cut and replaceable by another seamlessly.

How do I hate you, let me count the ways.

So what do we hate about job descriptions? There are so many things to hate about it. The endless list of requirements that only a superman can fulfil and maybe not. Some of the qualifications are so ridiculous, I would have to cross breed spiderman’s ability to climb walls, superman’s ability to fly and then that wouldn’t be enough, because we would want that person to be resistant to kryptonite too. Then, the description of the job itself would either be too general that it seems anyone can do it or so specific that no one could have done all that and then be immune to kryptonite. And after all this, the person may still not be suitable because there are cultural and environmental factors not considered.

Different as night and day

Let’s look at the scrum master role (non-cookie cut version). In broad sense, the scrum master is the person that helps to identify and removes obstacles for the team to achieve a release in the time and budget allocated repeatedly. The success of this person will depend on his / her ability to resolve issues and motivate team forward. The difference is, every company has different issues and different team dynamics. Some simple, some complex. Some stable in agility, some still adopting agile.

Personas

In agile, personas are used to address a segment of users / customers. It is a fictional character / profile who has needs and wants and display characteristics and behavioural. We often give this person a name, age and income and we describe the problems we want to solve for this persona. We can create several personas who would be potential customers for a product.

Personas as Job Descriptions

In recruitment, the best recruiters and head hunters will usually as the hiring manager, “what kind of person are you looking for?”. And here’s where a persona began to make more sense. Some job descriptions already look like this but let’s take this a step ahead and call it a persona.

3 types of information

Scott the Scrum Master

We are looking to hire “Scott the Scrum Master”. He doesn’t have to be called Scott or be a man, but let’s call him Scott first. He should be in x age group with about x years of work experience. (Let’s tackle legal issues later, e.g. age gender etc). In this area, we use only basic information.

Scott’s personal traits and behaviour

Here, let’s describe this person in terms of behaviour and characteristics according to the demands of the environment. It would also include what the person must know. Here, we would include competencies that will help to describe Scott as the kind of person to succeed in the environment presented.

Scott’s goals

This area describes Scott’s critical success factor, what he is expected to do in the role. We can include a vision of success, what Scott would have done to be considered successful in the role.

A rose by any other name? 

So am I just changing the name of job description to persona to please the agile community or sound innovative? In my mind, a job description has always been a point of reference to hire and induct the person into their job, even if it is for internal hire. The purpose and use is the same.

But in working and debating with agile teams, I think a Persona takes on a very different form than a job description. In a persona, the cultural aspects and critical behavioural traits are emphasised whilst skills and specific knowledge are added as required. The significance is that even if we have 2 rocket scientists considered for the same job, we will be able to know what kind of person we want and choose the person who most mirrors the behavioural traits. And more importantly, we can also consider a non-rocket scientist for that job as they as they can achieve the goals described.

What then?

Persona in itself will not be enough. If we do so, we fall into the same trap of a job description, using it as a form of checklist to hire. When it comes to hiring, there is a  simple law of 3.

– creating the persona to describe the person desired and what success means in the job. Be clear but keep it simple. Remember, the person shouldn’t have to climb walls, fly and still be immune to weaknesses.

– creating a list of competences that make sense to include in the persona. Eg. if spiderman is to climb walls, then he wouldn’t need to fly like superman. Or maybe we don’t care about flying or climbing, what we want is to get to the highest or lowest place in the fastest way possible.

– creating a list of questions to qualify the person. If we want a person who can work in a complex political environment, we must know what it takes and ask the person to describe how they had worked in previous similar environments or how they would act in this situation.

There is much to be done in the way we look at HR tools. But let’s start here. Let’s recognise that a job is more than a job title and a person is more than his collection of job titles and certifications.