The Dignity Of Work
organisation design
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.
Agile in Organisation Transformation
Recently I was involved in a project that uses agile methodologies and gave me the opportunity to deepen my understanding and see agile in action. Agile methods originated in software development.
In agile, I found a practical companion to change management.
In the organisation transformation and change management, I had often advocated for the importance of step-change to increase adoption and to ingrain change. In many instances however, I had seen organisations embarked on change programs with lofty ambitions only to let it frizzle out or stopped midway due to lack of funding, buy-in and/or change in focus, typically after spending a lot of money with no real evidence of benefits. And this is largely due to a lack of detail application of step change.
Take for example, implementing a personal development program. An organisation had decided to overhaul the people management program through its HR department. Once the team set out to shop for toolsets, it encountered a large variety of choices and methodologies. In an effort to create a holistic approach, the team worked on a blueprint of requirements that may include competency framework, balance scorecard, 360 feedback, review process and etc. Typically, it is followed by numerous RFP process to select the right vendors and consultants. Before long, it had become a huge project with large financial investments implications that would require further board and management approval who would raise concerns on benefits versus cost, investment timing, impact to share holder value. While the efforts were plagued with indecision and continual budget revisions, the next economic cycle would have hit and a new recession in sight., thus further pushing out the decision to more “suitable” times. Sounds familiar?
Perhaps the story is too simplified and a stretch from reality. Reality may not be far behind. In the best of instances, an organisation came out of a transformation process full of fatigue and unable to leverage on the changes for positive impact. In others, an organisation is so scarred by the process that any future change efforts is viewed with cynicism and resistance where necessary change do not happen until too late while more adaptable competitors change and overtake in market position.
It is easy to understand that step change is important, it is quite another to build out the details behind it. This is where I borrow some key terminologies in agile to lend some insights into the practicalities of step change.
Commander’s Intent – The objective of the organisation is expressed as its vision. This vision does not include details in “how”, it is only a view of the future state. In the example of a people development program, the intent should be what the company is trying to achieve and not the specific toolset. And perhaps, the program is only a building block and not the intent itself.
Minimum viable product – MVP is about creating the smallest product that is operable to test a hypothesis and learn from it. In the same example, it is important to define a problem statement that is top priority in achieving the vision. Then create the smallest potential solution that can either prove it is the right solution or if the problem statement is the accurate. There are 3 key steps in the process: build-measure-learn. It is important to decide early the KPIs and the intended learning.
Pilot or Prove of Concept – Both are ways to implement the MVP. In a pilot situation, the solution is deployed in a real scenario with a small set of users and prove of concept is where no real users are involved. Let’s say a competency framework is identified as key solution to assess accurately and create focus in personal development. An MVP is a small set of core competences and it can be piloted with a selected team or a specific group to test out usability. Alternatively, a proof of concept can be used to compare the competences with vendor options prior to purchase committments.
Short release and frequent release cycles – Shorter release cycles meant that the scope is reduced to MVP from idea creation to initial release. Small frequent releases follow for continuous build on the MVP or create other MVPs so that multiple products are released to complement each other. In the same example, the next release could be an extension of the framework to the pilot team and the MVP to other teams and continue simultaneously until the framework is being rolled out.
Feedback loops & Retrospective – Learning from the process is important for adaptive planning and evolving solutions to fulfil the vision. In some instances, the feedback is also used to converge initial ideas. Feedback loops complete a release cycle prior to the next release where KPIs are measured and applied. Retrospective refers to a critique on the process of roll out and people involved. It is key to ensure all environmental factors like buy in, communication, business readiness are reviewed and to provide learning required for continual process improvement.
Fair process – All change efforts have a people impact for success. Fair process ensures that all parties involved have a chance to learn about the intent, provide input and ask questions. Whilst the solution is not a patchwork of individual intents, the process allows for communication, creates understanding and encourages innovation in solution creation. It gives appropriate time for people to debate, question, consider and ultimately accept the changes to come.
Most recently, I had used the above in creating a new team including job profiles and competences necessary to build in-house capabilities to delivery a solution. It helped me frame the process to create a small enough team and feedback loop to add resources as required. The organisation chart was reviewed and built out through feedback and provided me with opportunity and time to coach and integrate new additions to the team.
A suitable consideration in using agile in organisation design is that whilst building a software where codes can be erased and redone, hiring and firing is not as easy. Thus, it is even more important to ensure the right team is created and built on without unnecessary expansion. Using options such as contracting, 3rd party becomes important, a topic I will discuss in the next post on Total Talent Management.
The Dignity Of Work 