Roles, Jobs and Capability Requirements
5 min read
Lesson objectives
- Distinguish task, responsibility, role, and capability when describing work.
- Build role elements from purpose, outputs, relationships, and decision boundaries, then derive required capability.
- Convert vague traits into observable, job-related criteria while considering fairness.
From “we need someone” to a role that can be understood and assessed
Once the work need is clear, the organisation must describe what will be delivered and who carries which responsibility. A task is a specific activity, such as reviewing a sample of cases. A responsibility is an ongoing obligation, such as maintaining service quality and identifying patterns of failure. A role brings together purpose, outputs, responsibilities, relationships, and decision boundaries. Capability is what a person needs to perform the role: relevant knowledge, skill, professional behaviour, or experience. Organisations may use the words “job” and “role” differently, so operational clarity matters more than the label.
Start with outputs and decisions, then derive capability
A useful role description does not begin with vague phrases such as “dynamic person” or “works well under pressure.” It starts with: Why does the role exist? What observable outputs should it produce? Which recurring or critical activities create those outputs? Who does the role work with? Which decisions can it make, and what must it escalate? Capabilities can then be derived and assessed. This connects selection and development criteria to the work rather than to impressions about personality.
When role requirements are designed, one broad professional principle helps reduce bias: keep qualifications, skills, experience, and other criteria connected to the job requirements. ILO material on non-discrimination emphasizes job-related qualifications, skills, experience, and requirements, and notes that discrimination can be direct or indirect. This is a general design principle, not a substitute for definitions or duties in applicable local law.
| Role element | Design question | Service-quality example |
|---|---|---|
| Purpose | Why does the role exist? | Improve consistency of service quality |
| Outputs | What observable result should be produced? | Regular pattern analysis and actionable recommendations |
| Tasks | Which activities produce the outputs? | Review samples, classify observations, discuss patterns |
| Relationships | Who must the role work with? | Service supervisors, data analysts, and operations teams |
| Decision boundary | What can it decide and what must it escalate? | Proposes improvement and escalates risk; disciplinary authority is not assumed |
| Capability | What knowledge or skill is required? | Simple analysis, feedback, and understanding service standards |
Separate essential from preferred requirements
An essential requirement is genuinely needed to perform the role or must be present from the start for a valid work reason. A preferred requirement adds value but can be learned or is not critical on day one. For a quality role, the ability to analyse patterns in case data may be essential, while knowledge of one internal system can be learned during onboarding. This does not mean removing safety-critical or genuinely necessary requirements. It means justifying each criterion through the work and avoiding unnecessary barriers.
Lesson summary
A useful role description starts with purpose, outputs, tasks, relationships, and decision boundaries, then derives required capabilities. Observable job-related criteria support better selection and development while reducing reliance on vague traits or unjustified requirements.