Build a shared skills taxonomy with operations leaders

Teams often use one title for people who perform different work. A senior technician in one location might diagnose faults and complete service records independently. The same title elsewhere might describe a person with longer tenure who still asks a lead for help with those tasks. A talent solutions consultant helps operations and HR replace loose labels with shared skill definitions. Those definitions support hiring conversations, development planning, internal movement, and succession discussion without pretending a title proves capability.

Begin with one role family. A workshop covering every job across an organization soon turns into a debate about names. Choose a role where leaders need clearer language for staffing or development. State the practical purpose at the start. For example, a service operation wants to identify which technicians perform controller diagnosis without direct support. A narrow purpose helps participants decide which detail belongs in the taxonomy and which detail belongs in another project.

Invite people who see the role from different angles. Include an operations leader who assigns work, an experienced employee who performs work, someone responsible for training records, and an HR partner when HR uses the definitions. Each person brings a different view. The supervisor sees output and handoffs. The employee sees hidden steps. The training owner sees what records capture. Your workshop needs those views, yet no participant should treat a job title as proof of every skill.

Prepare a simple starting sheet with columns for task, work context, observable result, verification owner, and evidence source. Do not fill the sheet with guessed skills before the conversation. Bring existing role descriptions, course names, or procedure documents only as discussion material. Ask participants where each source helps and where each source fails. A course completion record might show attendance at training. A supervisor observation might show task performance. The taxonomy should name each difference.

In a fictional practice workshop, consultant Clara meets a field supervisor, lead technician, training coordinator, and HR partner. Clara says, “We are defining work within the technician role family. We are not ranking people today. Which tasks separate an independent technician from a person still learning?” The supervisor replies, “An independent technician diagnoses a controller fault and completes a service report without calling our office.” Clara writes those as two separate tasks rather than one broad label.

Clara asks, “What does a completed diagnosis look like from your view?” The lead technician says, “The technician identifies the fault, follows the local procedure, and records the result in the service report.” The training coordinator adds, “Our records show controller courses, yet our records do not show diagnosis performance.” This distinction matters. The group should not convert course attendance into a statement of demonstrated diagnosis. The worksheet now carries a task, a result, and a gap in available evidence.

Ask for examples from recent work without recording unnecessary personal detail. A supervisor might describe a controller fault from a fictional service visit. “The display showed an error, the technician checked approved steps, found the related connection, and entered the result before leaving.” Clara asks which parts represent a defined skill. The group separates reading an error, following procedure, identifying a fault, and completing a report. A broad phrase such as “handles controller work” hides each decision a manager needs to understand.

For every task, ask where work occurs and which conditions affect performance. A technician might diagnose a controller inside a service bay, at a customer location, or during an overnight response. Those settings sometimes require different procedures, records, or support. Context belongs in the definition when a manager needs such detail to understand the task. “Using approved Site A procedure” gives needed detail when procedure use separates work from a general label.

Avoid rushing into levels such as beginner, intermediate, and expert. Such labels often invite arguments about status. First define observable tasks. Then ask when an employee completes each task independently, when direct guidance is expected, and who verifies performance. A role family might need two levels for one task and no levels for another. The work decides the structure. A taxonomy earns trust when people recognize daily work in the language.

Verification needs an owner and a method. “Manager approval” lacks enough detail for future use. Ask who has direct knowledge of the task, how they observe or review work, and where the result belongs. In Clara’s fictional workshop, the lead technician reviews a completed service report after an observed diagnosis. The training coordinator records only agreed status after receiving verification. HR receives the definition for role discussion, not a claim about any individual without relevant evidence.

Different sites often use different tools or procedures. Do not force one local task into a universal label when work context changes. Add context to the definition. “Complete controller diagnosis using approved procedure for Site A equipment” holds more meaning than “controller diagnosis.” If a second site uses another system, gather examples there before merging language. Shared language should make differences visible, not erase them for a tidy spreadsheet.

Test every definition with people who do the work. Read one draft aloud and ask, “Would a new supervisor know what to observe from these words?” Then ask an employee, “Does this describe a real task, or does an important step sit missing?” Resistance often points to a missing boundary. An employee might say, “My title does not show work I do during overnight calls.” Ask for the task, context, result, and verification route. Add a concrete definition after operational owner review.

Keep the workshop focused on language and evidence, not employment decisions. A taxonomy offers a shared description for discussions. Operations leaders and authorized specialists retain responsibility for staffing, training, performance, compensation, and other decisions. State this boundary once at the beginning, then keep the group working on definitions. Repeating role boundaries after every example distracts from useful work describing tasks clearly.

After the session, send a short draft back to participants with visible questions beside unresolved definitions. For example, “Controller diagnosis. Does this definition need a distinct procedure reference for Site B?” Ask an operational owner to approve wording for tasks under their oversight. Keep a note of workshop date, participants, sources reviewed, and open questions. A future reviewer then sees how a definition entered the taxonomy and which areas still need local input.

For practice, select one title from a fictional client organization and interview two people connected with the role. Ask each person to name five tasks, then mark shared tasks on your sheet. For one shared task, write the context, observable result, verification owner, and evidence source. Give the sheet to an operational owner and ask them to mark one phrase likely to confuse a new supervisor. Replace the phrase with task language, schedule a ten minute review, and have the owner read the revised definition aloud before marking a decision beside each open question.