Stay updated on our latest
articles with RSS
I once applied for a job as a Training Manager in a dynamic and rapidly developing organisation. My application was successful and I was delighted to find out that one of my colleagues whom I got on with very well from my previous organisation (we occasionally had barbecues at one another’s homes) had also applied for a job with the new organisation and would be working alongside me. Apparently and unbeknown to one another, we had both applied for the same role as Training Manager. They had liked us both and as they were expanding rapidly, they employed both of us. They designated my role as “Senior Training Manager” and his as “Training Manager”. Over barbecue discussions, we both said how much we were looking forward to working together in this new and exciting environment.
A couple of weeks into our new roles, my colleague and I were starting to have some differences, which by the end of three months, had escalated to conflict. Why? We liked one another, got on well together both socially and as work colleagues in our previous organisation and shared very similar views on the role of the training function. The problem lay in the “how” the training function was to be managed – I had my views and he had his. Our new organisation had developed Position Descriptions for each of our new roles, but they were written in “input” terms – i.e., how we should do things rather than “output” terms, i.e.., what we were each expected to achieve. As a result, there was major overlap in role descriptions and so our disagreements became “role conflict”.
One of the real problems I find with Position Descriptions is that they are often written in Input terms (i.e. what people do) rather than Outputs (i.e. what people achieve). This is often sadly also true for PD's written in KRA (Key Result Areas) terms. The result? People can stick rigidly to what they are expected to do rather than looking at the bigger picture and what they need to achieve for the betterment of their team and ultimately, the organisation. In addition to the potential for role conflict, this can lead to other problems. For example, in larger organisations, particularly where there is a culture of "rigid hierarchy", use of PDs in this manner invariably leads to conflict and the PD being used as alibi paper when something that should have been achieved, slips through the cracks (even the best written PDs will not cover all eventualities, that is why the focus on outputs is so important). In smaller organisations, use of PDs written in input terms can lead to a feeling of being overworked or "this is not my responsibility" when the person has to do something that is not specifically written into their PD.
The answer to all of this, for both large and small organisations, is to use the PD and in particular the writing of the PD, as a process of agreement between people as to what their output areas are. It is the process of discussing and agreeing on output areas that is critical for effective working relationships, job design and ultimately organisation structure, not the piece of paper that the PD ends up on.
PDs should not be written in isolation by one person, nor should they be written by the HR Department. The HR Department's (or HR person's) role in PDs is to coach, train and facilitate the writing of the PDs by the people who will be doing the actual work.
How do you write effective Position Descriptions that are expressed in output terms? One way is to convert existing PDs. For example, look at the following list of duties from the Supervisor’s PD at a large main frame computer centre:
1. Supervise and direct the operations of the computer room in a large scale, multi-mainframe operations environment.
2. Provide on-the-job training aides for operating staff to ensure the standard operations procedures are maintained.
3. Provide assistance in the analysis and correction of systems hardware, software and production failures and/or notify appropriate personnel.
4. Maintain computer usage records and operational logs.
5. Deputise for the shift manager.
All of the above are expressed as “inputs” rather than “outputs” In output terms they could be written as:
1. Supervise and direct the operations of the computer room in a large scale, multi-mainframe operations environment.
Would be rewritten as . . .
• Mainframe down time is minimal
• Quality output standard of data is maintained
• All staff meet their performance standards
2. Provide on-the-job training aides for operating staff to ensure the standard operations procedures are maintained.
Would be rewritten as . . .
• Standard operating procedures followed
• Errors are minimised
• Problems solved within specified time and quality standards
You may like to try your hand at rewriting 3, 4 & 5!
As you do, you will notice that outputs start to repeat themselves fairly frequently. That’s because outputs focus on the results not “how “ the job is done. Although “how” is important, it can be stated in terms of standards that must be met and maintained – overstating the “how” and breaking it down to a small number of tasks, leaves people with no room for initiative nor decision making and often leads to role overlap or underlap which eventually ends in conflict.
How do we arrive at outputs? Very simply. Just add “ . . . so that” to each input and complete the sentence. Or, ask “Why?” of each input and keeping asking “Why?” until the answer becomes an output. For example, “Supervise and direct the operations of the computer room in a large scale, multi-mainframe operations environment . . . so that . . . Mainframe down time is minimal . . . so that . . . Quality output standard of data is maintained . . . so that . . . All staff meet their performance standards”
Most PD’s written in output terms will have no more than 5 or 6 outputs. For lower level roles, this can rise to as many as 8 – 10 (although be careful that none of these are or become inputs). The more senior the role, the less number of outputs a manager should have until ultimately the CEO has only one – “Stakeholder expectations managed effectively”
Remember as I said earlier, it is the process of discussing and agreeing on output areas that is critical for effective working relationships, job design and ultimately organisation structure, not the piece of paper that the PD ends up on. So make sure the people doing the work are involved in writing the PDs.
Oh, by the way, you may be wondering what eventually happened between my colleague and I. He applied for a role elsewhere in the organisation – his old role was not refilled. I and the organisation had learned about “outputs” by that stage.
Happy output development!
Bob Selden is the author of “What To Do When You Become The Boss”, a practical “how to” for managers. If you have a management challenge, visit Bob at www.whenyoubecometheboss.com/ to find an answer. Alternatively, you can phone Bob on +41 61 921 66 51 between 9 and 5 (GMT +1)
A couple of weeks into our new roles, my colleague and I were starting to have some differences, which by the end of three months, had escalated to conflict. Why? We liked one another, got on well together both socially and as work colleagues in our previous organisation and shared very similar views on the role of the training function. The problem lay in the “how” the training function was to be managed – I had my views and he had his. Our new organisation had developed Position Descriptions for each of our new roles, but they were written in “input” terms – i.e., how we should do things rather than “output” terms, i.e.., what we were each expected to achieve. As a result, there was major overlap in role descriptions and so our disagreements became “role conflict”.
One of the real problems I find with Position Descriptions is that they are often written in Input terms (i.e. what people do) rather than Outputs (i.e. what people achieve). This is often sadly also true for PD's written in KRA (Key Result Areas) terms. The result? People can stick rigidly to what they are expected to do rather than looking at the bigger picture and what they need to achieve for the betterment of their team and ultimately, the organisation. In addition to the potential for role conflict, this can lead to other problems. For example, in larger organisations, particularly where there is a culture of "rigid hierarchy", use of PDs in this manner invariably leads to conflict and the PD being used as alibi paper when something that should have been achieved, slips through the cracks (even the best written PDs will not cover all eventualities, that is why the focus on outputs is so important). In smaller organisations, use of PDs written in input terms can lead to a feeling of being overworked or "this is not my responsibility" when the person has to do something that is not specifically written into their PD.
The answer to all of this, for both large and small organisations, is to use the PD and in particular the writing of the PD, as a process of agreement between people as to what their output areas are. It is the process of discussing and agreeing on output areas that is critical for effective working relationships, job design and ultimately organisation structure, not the piece of paper that the PD ends up on.
PDs should not be written in isolation by one person, nor should they be written by the HR Department. The HR Department's (or HR person's) role in PDs is to coach, train and facilitate the writing of the PDs by the people who will be doing the actual work.
How do you write effective Position Descriptions that are expressed in output terms? One way is to convert existing PDs. For example, look at the following list of duties from the Supervisor’s PD at a large main frame computer centre:
1. Supervise and direct the operations of the computer room in a large scale, multi-mainframe operations environment.
2. Provide on-the-job training aides for operating staff to ensure the standard operations procedures are maintained.
3. Provide assistance in the analysis and correction of systems hardware, software and production failures and/or notify appropriate personnel.
4. Maintain computer usage records and operational logs.
5. Deputise for the shift manager.
All of the above are expressed as “inputs” rather than “outputs” In output terms they could be written as:
1. Supervise and direct the operations of the computer room in a large scale, multi-mainframe operations environment.
Would be rewritten as . . .
• Mainframe down time is minimal
• Quality output standard of data is maintained
• All staff meet their performance standards
2. Provide on-the-job training aides for operating staff to ensure the standard operations procedures are maintained.
Would be rewritten as . . .
• Standard operating procedures followed
• Errors are minimised
• Problems solved within specified time and quality standards
You may like to try your hand at rewriting 3, 4 & 5!
As you do, you will notice that outputs start to repeat themselves fairly frequently. That’s because outputs focus on the results not “how “ the job is done. Although “how” is important, it can be stated in terms of standards that must be met and maintained – overstating the “how” and breaking it down to a small number of tasks, leaves people with no room for initiative nor decision making and often leads to role overlap or underlap which eventually ends in conflict.
How do we arrive at outputs? Very simply. Just add “ . . . so that” to each input and complete the sentence. Or, ask “Why?” of each input and keeping asking “Why?” until the answer becomes an output. For example, “Supervise and direct the operations of the computer room in a large scale, multi-mainframe operations environment . . . so that . . . Mainframe down time is minimal . . . so that . . . Quality output standard of data is maintained . . . so that . . . All staff meet their performance standards”
Most PD’s written in output terms will have no more than 5 or 6 outputs. For lower level roles, this can rise to as many as 8 – 10 (although be careful that none of these are or become inputs). The more senior the role, the less number of outputs a manager should have until ultimately the CEO has only one – “Stakeholder expectations managed effectively”
Remember as I said earlier, it is the process of discussing and agreeing on output areas that is critical for effective working relationships, job design and ultimately organisation structure, not the piece of paper that the PD ends up on. So make sure the people doing the work are involved in writing the PDs.
Oh, by the way, you may be wondering what eventually happened between my colleague and I. He applied for a role elsewhere in the organisation – his old role was not refilled. I and the organisation had learned about “outputs” by that stage.
Happy output development!
Bob Selden is the author of “What To Do When You Become The Boss”, a practical “how to” for managers. If you have a management challenge, visit Bob at www.whenyoubecometheboss.com/ to find an answer. Alternatively, you can phone Bob on +41 61 921 66 51 between 9 and 5 (GMT +1)