Role design
Separate must-have skills from skills people can learn
Call a skill essential only when the person must use it early, failure would carry a serious consequence, and the team cannot reasonably teach it in time. Treat the rest as trainable or preferred. Link every requirement to a role outcome, accept different evidence routes, and verify that managers can provide the learning support the brief assumes.
On this page
Start from early decisions
List the decisions and tasks the person must handle during the first weeks. Identify which require independent judgment on arrival and which can wait. A skill used once in the second quarter is rarely a day-one filter. This exercise prevents a complete future wish list from becoming the entry ticket to a role.
Use consequence and learning time
For each capability, ask what happens if it is initially weak, how quickly it can be learned, and whether mistakes can be reviewed safely. Work involving sensitive judgment or immediate sole ownership may justify prior depth. A tool, internal process, or sector vocabulary may be learnable if the underlying reasoning transfers and support is available.
Check the support claim
Teams often label a skill trainable without assigning a teacher, practice opportunity, or time. Name the person who can coach, the material or shadowing available, and the point when independent work is expected. If no support exists, either create it or be honest that the capability is needed earlier. Do not make a new hire carry an unowned training plan.
Accept multiple forms of evidence
Avoid demanding one employer type, degree, title, or industry as the only proof. Ask what someone could show from adjacent work: a decision they made, a system they learned, or a comparable stakeholder problem. Broader evidence can improve the pool without lowering the bar because the bar remains tied to the actual outcome.
- Used in the first month?
- High consequence if learned slowly?
- Underlying skill transferable?
- Named support actually available?
Calibrate with a concrete requirement
Illustrative example: a team marks experience with its exact planning software as essential for an operations role. Discussion shows the person will spend the first month learning internal workflows and can use a sandbox with a team lead. Structured problem solving and data hygiene remain essential; the exact software moves to trainable. Screening now asks for evidence of learning comparable systems.
Recheck after interviews
If almost every promising candidate misses the same requirement, examine whether the market is wrong or the requirement is a proxy. Conversely, if interviewers routinely overlook a stated must-have, the brief lacks credibility. Change the classification only through the role owner, document why, and apply the revised standard consistently to candidates still in process. After hiring, ask the manager which predicted gaps actually mattered during onboarding. Use that observation to improve future classifications, without rewriting history to make the decision appear inevitable.
Next step
Review every must-have in one open role and require a clear early-use case, consequence, learning limit, and evidence route before keeping it.