Role Design Guide (with Job Family Reference)

1. Purpose

This guide provides a practical, organization‑wide method for designing roles that are clear, outcome‑driven, and aligned to the approved Job Families and Levels. It translates governance (policies/SOPs) into manager‑friendly instructions so every new or redesigned role is consistent, fair, and easy to approve.

1.1 Why this guide exists

• Eliminate ad‑hoc, title-heavy, task-dump JDs by centering roles on measurable outcomes.
• Ensure every role maps to a Job Family and Level from the Role/Level Architecture.
• Create comparability across departments (titles, levels, bands).
• Speed up approvals by standardizing what “good role design” looks like.
• Improve employee clarity on accountabilities, scope, and growth paths.

1.2 Objectives & expected outcomes

Objective	What “good” looks like	Evidence/Output
Outcome-first role definition	3–5 business outcomes stated (not a long task list)	“Key Outcomes” section in the role draft
Architecture alignment	Clear Job Family and Level mapping	Role header fields completed correctly
Clarity of scope & accountability	Concise Purpose, Core Responsibilities, Reporting	Role design checklist satisfied
Fairness & comparability	Title/level consistent with peers; band within range	HR validation passes without rework
Approvals without friction	Fewer loops with HR/Finance/Leadership	First‑time‑right rate ≥ 85%

1.3 What this guide is not (non‑goals)

• Not a policy (rules live in Workforce Planning Governance Policy).
• Not an approval workflow (that’s the Role Creation/Change Approval SOP).
• Not a compensation manual (pay bands live in Comp/Rewards artifacts).
• Not a generic job description library—it’s a how‑to for designing roles correctly.

1.4 Where this guide fits (sequence in HR system)

1. Use this Guide to draft/reshape the role (Purpose → Outcomes → Responsibilities → Family/Level).
2. Run Role Creation/Change Approval SOP to get role approved (HR → Finance → Leadership).
3. Once approved, use Talent Acquisition SOP to hire into the role (if required).

1.5 Success measures (for adoption)

KPI	Target	Owner
First‑time‑right role drafts (no rework)	≥ 85%	Dept Heads / HRBP
Average approval cycle time (role design stage)	≤ 5 business days	HR
% roles with correct Family/Level mapping	100%	HR
# of escalations due to vague/overlapping roles	0 per quarter	HR / Leadership

1.6 Quick definitions (used throughout)

• Role Purpose: One‑paragraph “why this role exists” linked to business value.
• Key Outcomes: 3–5 measurable results the role must deliver within a horizon (e.g., 6–12 months).
• Core Responsibilities: 5–7 enduring accountabilities (not granular tasks).
• Job Family: Grouping of related roles (e.g., Development, Sales, HR).
• Level: Career stage within a family (Associate → Consultant → Senior → Manager → …).

2. Scope

This guide applies across the entire organization whenever a role is being designed, re-designed, or validated. It is intended as a reference tool for managers and HR, not as a replacement for policy or SOPs.

2.1 Applicability

This guide must be used by:

• Department Heads & Hiring Managers – when proposing new roles or redesigning existing ones.
• HR Business Partners (HRBP) – when validating role drafts for alignment with Job Families and Levels.
• Finance – as a reference when checking compensation bands against role levels.
• Leadership – to ensure role drafts presented for approval are structured, fair, and comparable.

2.2 Use Cases (When to apply this guide)

• New Role Creation – drafting roles that have not previously existed in the organization.
• Role Modification – redesigning or refining roles due to scope expansion, level upgrades/downgrades, or reporting changes.
• Succession Planning – clarifying expectations for future-ready roles or critical positions.
• Role Benchmarking – ensuring external hires are slotted into the correct family/level and not over-titled.
• Cross-Family Movements – when an employee transitions from one family to another (e.g., Developer → Project Manager).

2.3 Exclusions (What this guide does not cover)

• Hiring into approved roles – governed by the Talent Acquisition SOP.
• Role approval workflows – covered under the Role Creation/Change Approval SOP.
• Salary banding and compensation design – managed through Compensation & Benefits policies.
• Performance appraisal or promotion processes – defined in the Performance Management Policy.

2.4 Linkages to HR Lifecycle

This guide is an enabler within the HR lifecycle:

• Before approval → ensures role design is solid and aligned.
• During approval, → provides structure and reference for HR validation.
• After approval, → serves as a standard reference when drafting job descriptions for hiring.

3. Role Design Principles

All roles must be designed following a set of non-negotiable principles to ensure consistency, fairness, and alignment across the organization. These principles apply to every role draft, regardless of department, level, or function.

3.1 Outcome-Focused Design

• Roles should be defined in terms of what they deliver, not just the activities they perform.
• Each role must specify 3–5 measurable outcomes that link to business goals.
• Example: “Improve system performance and reduce downtime by 10% in the next 12 months” (outcome) vs. “Maintain servers” (activity).

3.2 Clarity in Responsibilities

• Role responsibilities must be specific, enduring accountabilities, not vague task lists.
• Avoid ambiguous language such as “assist,” “help,” or “support.” Instead, define ownership.
• Responsibilities should be 5–7 key areas that remain relevant even if day-to-day tasks evolve.

3.3 Alignment to Job Families & Levels

• Every role must map to an approved Job Family (e.g., Development, Design, Sales, HR, Finance).
• Every role must be slotted into an approved Level (e.g., Associate, Consultant, Senior, Lead, Manager, Director).
• Titles must follow the organization’s naming conventions to avoid duplication or inflation.

3.4 Career Progression Visibility

• Each role must clearly indicate its next potential step within the career path.
• Growth paths should be visible and logical, e.g.: Associate Developer → Consultant Developer → Senior Developer → Lead Developer.
• Roles must not create “dead-end” positions unless explicitly marked as specialist tracks.

3.5 Consistency Across Departments

• Titles, levels, and outcomes must be comparable across departments.
• Example: A “Consultant” in Design should be equivalent in scope and expectations to a “Consultant” in Development or Sales.
• Prevents title inflation and ensures fair performance and pay benchmarking.

3.6 Simplicity & Clarity of Language

• Role purpose and responsibilities should be written in clear, plain business language.
• Avoid jargon, acronyms, or over-technical phrasing unless essential to the role.
• Anyone reading the role (employee, HR, Finance, Leadership) should immediately understand what it entails.

3.7 Compliance & Governance Alignment

• All roles must adhere to the Workforce Planning Governance Policy.
• Role design must not contradict approved headcount limits, budgets, or reporting structures.
• HR is responsible for validating compliance before a role proceeds to approval.

4. Role Design Checklist (for Managers)

This checklist is the mandatory template that all managers and HR must use when drafting or modifying roles. It ensures consistency across departments and reduces back-and-forth during approvals.

Every role draft must include the following sections:

4.1 Role Header Information

• Role Title – Must align with approved naming conventions (no custom/unofficial titles).
• Job Family – Select from the approved Job Family list (Development, Design, QA, PM, Sales, HR, Finance, Operations, etc.).
• Level – Assign the appropriate level (Associate, Consultant, Senior, Lead, Manager, Director, VP, CXO).
• Location/Work Arrangement – Specify on-site, hybrid, or remote, and geographic location.
• Employment Type – Full-time, part-time, contract, or internship.

4.2 Role Purpose

• A one-paragraph statement that explains why the role exists.
• Must be linked to business needs or organizational objectives.
• Example:
• “The purpose of this role is to design, build, and maintain scalable backend systems that ensure customer platforms remain reliable, secure, and high-performing.”

4.3 Key Outcomes

• List 3–5 measurable results expected from the role within a 6–12 month horizon.
• Outcomes should be quantifiable (e.g., “reduce churn by 5%,” “deliver 3 client projects per quarter”).
• Avoid vague outcomes such as “support company growth.”

4.4 Core Responsibilities

• Define 5–7 key accountabilities that remain consistent over time.
• Each responsibility should begin with a strong action verb (e.g., Design, Develop, Lead, Manage, Ensure, Deliver).
• Example:
  • “Design and deliver user-centered interfaces in line with brand guidelines.”
  • “Manage client relationships to ensure project satisfaction and upsell opportunities.”

4.5 Required Skills & Competencies

• Technical Skills – tools, platforms, frameworks, or certifications required.
• Behavioral Competencies – communication, problem solving, teamwork, leadership.
• Minimum Education/Experience – if essential (avoid inflating unnecessarily).

4.6 Reporting Line & Stakeholders

• Specify who the role reports to (by title, not name).
• Clarify key stakeholders the role interacts with (internal and external).
• Example: “Reports to: Lead Designer; Key stakeholders: Product Managers, QA team, Clients.”

4.7 Career Progression Path

• Indicate the natural growth path for the role.
• Example:
  • Associate → Consultant → Senior → Lead → Manager.
• If specialist track applies, mention:
  • Senior Engineer → Principal Engineer → Architect.

4.8 Role Classification & Compliance

• Ensure the role:
  • Maps to an approved Job Family/Level.
  • Falls within budgeted headcount.
  • Aligns with Workforce Planning Governance Policy.

Output Format (Role Draft Template)

Section	Content Example
Role Title	Associate Backend Developer
Job Family	Development
Level	Associate
Role Purpose	Build and maintain backend APIs that ensure reliability and scalability.
Key Outcomes	Deliver 2 successful API integrations per quarter; Reduce server downtime by 5%.
Core Responsibilities	Design APIs, Write unit tests, Optimize DB queries, Collaborate with frontend team.
Required Skills	Python, Django, SQL; teamwork & problem solving.
Reporting Line	Reports to Senior Developer
Progression	Consultant Developer → Senior Developer
Compliance Check	Fits Development family, Associate level, Budgeted HC approved.

5. Job Family Reference

The following Job Families serve as the structural backbone of the organization. Every role must be mapped to one of these families and slotted into the correct level as defined in the Role/Level Architecture Document.

This section provides managers with a reference view of families and sample progression paths so they can position new or redesigned roles correctly.

5.1 Core Service Delivery Families

1. Development (Engineering)
   • Levels: Associate Developer → Consultant Developer → Senior Developer → Lead Developer → Engineering Manager → Director of Engineering → CTO
   • Includes: Backend, Frontend, Fullstack, Mobile, DevOps, Cloud, Security, Data Engineering.
2. Design
   • Levels: Associate Designer → Consultant Designer → Senior Designer → Lead Designer → Design Manager → Director of Design → CDO
   • Includes: UI, UX, Product Design, Visual Design, Brand Design.
3. Quality Assurance (QA)
   • Levels: Associate QA Engineer → Consultant QA Engineer → Senior QA Engineer → Lead QA Engineer → QA Manager → Director of Quality → VP Quality
   • Includes: Manual Testing, Automation, Performance Testing, Security Testing.
4. Project Management (PM)
   • Levels: Project Coordinator → Associate Project Manager → Project Manager → Senior Project Manager → Delivery Manager → Director of Delivery → COO
   • Includes: Agile PM, Technical PM, Program Management.

5.2 Business Enablement Families

1. Sales & Business Development
   • Levels: Sales Associate → Sales Consultant → Senior Sales Consultant → Sales Manager → Director of Sales → VP Sales → CRO
   • Includes: Inside Sales, Enterprise Sales, Partnerships, Account Management.
2. Marketing
   • Levels: Marketing Associate → Marketing Consultant → Senior Marketing Consultant → Marketing Manager → Director of Marketing → VP Marketing → CMO
   • Includes: Content, Digital Marketing, Product Marketing, Brand, Events.
3. Operations
   • Levels: Ops Associate → Ops Consultant → Senior Ops Consultant → Ops Manager → Director of Operations → VP Operations → COO
   • Includes: Process, Administration, Facilities, Vendor Management.
4. Human Resources (HR)
   • Levels: HR Associate → HR Consultant → Senior HR Consultant → HR Manager → Director of HR → VP HR → CHRO
   • Includes: Talent Acquisition, HR Business Partnering, L&D, HR Ops, Employee Relations.
5. Finance
   • Levels: Finance Associate → Finance Consultant → Senior Finance Consultant → Finance Manager → Director of Finance → VP Finance → CFO
   • Includes: Accounting, Payroll, FP&A, Compliance, Audit.

5.3 Guidelines for Managers

• Select only from existing families → no ad-hoc families to be created.
• Stay within defined levels → do not create hybrid titles (e.g., “Lead Senior Developer”).
• Use progression examples as guidance, but confirm with HR if designing specialist vs managerial tracks.
• If role overlaps two families, clarify the primary family; secondary skills can be listed in responsibilities.

5.4 Specialist Tracks (Optional but Allowed)

In some functions (especially Development & Design), specialist tracks may exist alongside managerial tracks. Example:

• Technical Track: Senior Developer → Principal Developer → Architect.
• Managerial Track: Senior Developer → Lead Developer → Engineering Manager.

Managers must declare upfront which track applies when designing a role.

6. Examples of Good vs. Poor Role Design

The purpose of these examples is to show managers the difference between a well-structured role (aligned with this guide) and a poorly defined role (unclear, inconsistent, or inflated). Managers are expected to benchmark their drafts against these examples before submitting to HR.

6.1 Role Purpose

• Good Example
• “The purpose of this role is to design and maintain scalable cloud infrastructure that enables customer applications to run reliably with 99.9% uptime.”
• Clear, outcome-focused, and linked to business value.
• Poor Example
• “Responsible for handling cloud-related stuff.”
• Vague, not measurable, lacks link to organizational outcomes.

6.2 Key Outcomes

• Good Example
  • Deliver 2 product features per quarter with zero major production defects.
  • Improve website conversion rate by 10% over 6 months.
  • Achieve 95% SLA adherence for customer support tickets.
• Measurable, time-bound, directly tied to impact.
• Poor Example
  • “Work on features.”
  • “Help sales.”
  • “Handle support.”
• Non-specific, no timeline, no measure of success.

6.3 Core Responsibilities

• Good Example
  • “Design user-friendly interfaces aligned with brand guidelines.”
  • “Lead sprint planning and backlog grooming sessions.”
  • “Develop and maintain automated test scripts for core applications.”
• Clear accountability, action verbs, and enduring relevance.
• Poor Example
  • “Do design tasks as needed.”
  • “Attend meetings.”
  • “Support QA team.”
• Task-oriented, no ownership, too generic.

6.4 Role Title & Level

• Good Example
  • “Associate QA Engineer” (entry-level, mapped to QA family).
  • “Senior Backend Developer” (advanced level, mapped to Development family).
• Uses approved titles and levels, consistent across departments.
• Poor Example
  • “QA Ninja”
  • “Backend Rockstar”
  • “Lead Senior Engineer”
• Non-standard titles, inconsistent with levels, creates confusion in career paths.

6.5 Career Progression

• Good Example
  • Associate → Consultant → Senior → Lead → Manager.
  • Clear specialist track: Senior Developer → Principal Developer → Architect.
• Transparent, logical, aligned to architecture.
• Poor Example
  • “Move up whenever needed.”
  • No defined progression.
• No structure, leaves employees unclear about career paths.

6.6 Reporting Line & Stakeholders

• Good Example
  • Reports to: Lead Designer.
  • Key stakeholders: Product Manager, QA team, and Clients.
• Clear reporting and collaboration lines.
• Poor Example
  • Reports to: “Company.”
  • Stakeholders: “Everyone.”
• Ambiguous, creates confusion in accountability.

6.7 Checklist Reminder for Managers

Before finalizing a role draft, ask yourself:

• Is the purpose linked to business value?
• Are outcomes measurable and time-bound?
• Are responsibilities clear accountabilities, not vague tasks?
• Does the title follow approved conventions?
• Is the career path logical and transparent?

If the answer is “no” to any, the role needs revision before submission.

7. Related Documents

This guide is part of the broader HR & Workforce Planning framework. Managers must use it in conjunction with the following documents:

7.1 Policies

• Workforce Planning Governance Policy – defines overall workforce planning principles, approvals, and compliance requirements.
• Compensation & Benefits Policy – provides banding, pay structures, and allowances linked to levels.
• Performance Management Policy – outlines performance evaluation, promotions, and career progression rules.

7.2 Standard Operating Procedures (SOPs)

• Role Creation/Change Approval SOP – governs the process for approval of new roles or structural changes.
• Talent Acquisition SOP – defines hiring workflows once a role is approved.
• Onboarding SOP – ensures smooth induction of new hires into approved roles.

7.3 Reference Documents

• Role/Level Architecture Document – provides the approved job families, levels, and career paths.
• Recruitment Playbooks / Job Description Templates – practical tools for converting a role draft into candidate-facing JDs.
• Org Structure & Headcount Plan – validates whether the role fits within budgeted workforce numbers.

7.4 Manager’s Quick Navigation

• Start here → Role Design Guide (this document).
• Need approval? → Role Creation/Change Approval SOP.
• Hiring into the role? → Talent Acquisition SOP.
• Need family/level check? → Role/Level Architecture Document.
• Budget concerns? → Finance/Headcount Plan.