Protocol
Decompose the role into tasks before naming your skills
Titles travel badly; tasks travel better.
When it fits
- Your career description is mostly a job title, vendor name or department label.
When to avoid it
- Do not erase domain expertise; decomposition reveals transferable parts and context-specific parts rather than declaring everything generic.
Why it matters
List the recurring tasks that create value: diagnose, model, negotiate, configure, analyze, write, teach, validate, coordinate or decide. Then map the knowledge and skills each task uses. This makes portability visible below the title and exposes which capability would survive a company or tool change.
Steps
- At least five recurring tasks can be described without relying on the current job title.
An example
'SAP consultant' becomes a set of tasks such as requirements clarification, data-model reasoning, workflow design, testing and stakeholder alignment.
Check your result
At least five recurring tasks can be described without relying on the current job title.
Keep this limit in mind
- Do not erase domain expertise; decomposition reveals transferable parts and context-specific parts rather than declaring everything generic.
Connected ideas
Use beforeSeparate domain knowledge, tool skill and transferable capability
Evidence and sources
The current O*NET database separates occupations into tasks, work activities, essential skills, transferable skills, knowledge and technology skills, enabling comparison below the job-title level.
O*NET is U.S.-focused and its taxonomy should be treated as a structured comparison aid rather than a universal occupation model.
O*NET 31.0 Database · Database content areas
OECD's 2026 brief on skill use emphasizes examining how skills are actually used at work, not only whether workers possess them.
Skill-use frequency is not the same as proficiency or labour-market value.
Putting skills to work · Abstract